jump to navigation

Why I Really, Really Dislike Javascript May 29, 2015

Posted by PythonGuy in Javascript.
Tags:
4 comments

In an earlier post, I said I dislike Javascript and I like Python. Now it’s time to list many of the ways I dislike Javascript.

First, Javascript is a joke compared to other languages. It was a scripting language added to a browser that happened to be the most powerful browser at the time. You simply can’t design a good language in a few weeks. Other languages were carefully designed and planned, and have countless developer-years behind them, refining them into the ideal language for its role. Javascript? Not so much. The second browser to implement Javascript did their own little spin of it. If you wanted cross-compatible Javascript, you had to know which things would work across the various browsers. That is still true today. Javascript isn’t defined by smart people, it’s an intersection of what smart people come up with as they try to get everyone to use only their product.

For a very long time, and to some degree, even today, the different Javascript implementations were substantially different. Even today, you have to be careful to program to a version of Javascript that will support all the people who will load your code. You have no control over the version of Javascript they are running. The idea that you could actually deliver a product that you could put your reputation behind in that kind of environment is laughable. The idea that your code will still run 10, 20 years from now — an impossible dream. In most other languages, you tie your program to a specific version of the language. Old C code still compiles, for instance. We’re still running Cobol and Fortran. Javascript will hopefully disappear.

There is no integer in Javascript. All numbers are floats. How do you do accounting with floats? You can’t. If you think you can, you shouldn’t be writing any software that ever does anything with any currency. Pass the currency into Javascript as a string, and don’t let Javascript do any math, unless you really understand the problems with floats.

The language is very clunky, from a typing and reading perspective. You mean I have to type “function” every time I want to make a function? And whoever uses “function fubar()” syntax? No one. It’s always “fubar = function() { }”. (At least they got the idea of a function being a first-class object right.)

Exceptions are an afterthought and mostly useless. Most javascript programmers I know avoid them like the plague rather than embrace them as a way to handle exceptional cases. It’s really a mystery how it all works in the end.

Don’t get me started on the object system. The system it comes with is so useless, every framework I’ve seen builds a completely new object system on top of it. You’d think they would standardize on a common object system so that learning one would transfer to another framework but…

There is no good way to “include” other bits of code into your javascript program. This makes it difficult to share code between projects. Yes, there are solutions out there, but it seems every framework has its own ideas of what the right way should be and no two systems are compatible. This is why there is no standard library for Javascript, why people are not working together to extend Javascript, and why you always feel like you are coding alone in a vacuum. Every new Javascript project means talented developers are no longer working on your code.

The API and libraries are a mess of half-useful methods. For instance, if I wanted to split a string into two strings around the first space in the string. In most languages, you have something that will split a string, and there is usually a parameter to limit the number of times it will split. In Javascript, they chose to add a parameter to limit the number of times it will split but it throws away the rest of the string. This sort of thing is all over the place. Go poke at the date and time system and tell me how I am supposed to calculate practically anything successfully.

The “arguments” parameter is not an Array. It is its own object that looks like an Array for the most part, but there are subtle but important differences.

Quick, what is the difference between “undefined” and “null”? Why do they even have two separate “null” objects? Oh, because…

Objects are not hashtables. Well, they are, but there are limitations and caveats. Hashtables do not exist in the basic language. Don’t kid yourself. You will get burned.

I really love dynamic typing, but Javascript is a very, very bad implementation of it. That’s why I like to tell people Python is a strongly, dynamically typed language and Javascript is something else. The less people associate Python’s object system with Javascript’s, the better.

You can’t control how your functions are called. Your function has to accept 0 arguments, 1 argument, or any number of arguments, no matter what you specify for the signature. If you are going to be careful, you should check the arguments as they come in, to make sure it was called properly, because Javascript does not do this for you.

There is no parallel assignment as in many languages. IE, “a, b = 1, 2”. This is an extremely useful feature.

How are you supposed to detect if you have an empty string anyway? In Python, it’s trivial. In Javascript, you have to write much more code to do it right. The same goes for 0 and other things.

How are you supposed to compare two objects? And why does the order matter? This causes no end of problems, making simple comparator objects almost useless.

Event-based programming is good, but sometimes, you really want threads or subprocesses. Not having these things forever condemns Javascript to give all “scripting” languages a bad name.

There is only one for-loop, the C kind. Which sucks. Newer versions have additional operations, but are plagued by the bad API problems. If you’re calling a function to get your forEach, how do you do “next”/”continue” and “break”?

There are language features which should be cool and useful, but have problems that make them useless. And not just a few. Actually, pretty much every language feature has huge caveats and you have to know them all. It reminds me of PHP, a language that gives you the same feeling as a soldier trying to cross a minefield. It’s not a question of if, it’s a question of when you will encounter a huge problem and have to backtrack. And every time you try to do anything, you have to remember the dance necessary to avoid the mines to do it right.

At some point, you will want to test and debug your code on every platform that will run it. But you can only debug it on some platforms, and you have to learn a completely different tool for each of them. This used to be a lot worse in past years, but it’s still bad. If the implementations of Javascript actually lived up to their promises, you should be able to run and test on a single platform and have it run on all of them properly. But that’s not the world we live in, and it never will be until one browser completely dominates the others on every single operating system and drives them all out of business. Or until we get a group that is strong enough to force people to actually write their browsers to a specification and prevent them from unleashing it on the public until it is consistent with others.

No development can ever, ever happen in Javascript because of the above.

In short, unless you know every nook and cranny of Javascript and every wart it has, you really shouldn’t be writing Javascript. Find another language that compiles into Javascript, and just avoid it altogether. Javascript will never get better. There’s just no way. So don’t do Javascript, and warn others to avoid it as well. That’s my professional opinion.

One day, asm.js will save us all. asm.js will run any code. Download speeds and caching will be advanced enough so that we can have our users download Python and run our code against that, rather than JS, and it should even perform faster than it would natively.

Advertisements

Why I Choose Python over Node.js May 27, 2015

Posted by PythonGuy in Javascript, Node.js.
Tags: , , ,
12 comments

I’ve been reading about Node.js. It seems pretty cool. Certainly, the allure of writing Javascript on both the front end and back end of a webservice is enticing.

Using Google’s v8 engine, it looks even more enticing. Google’s engine makes javascript very, very fast!

But then I am reminded of some things.

First, Python is so much fun to program in.

Second, I really hate Javascript.

Third, Python has SQLAlchemy.

That pretty much seals the deal for me. I mean, whenever I do database work, I want to have SQLAlchemy available to me. I can’t live without it. Well, I can, but I get frustrated and end up throwing things when I realize how much easier life is with SQLAlchemy.

To really understand what I am saying, consider this snippet: https://gist.github.com/cgbystrom/724208

Do you really want to write that much code in that convoluted manner when you can just write Python and get it done? I mean, if all you know is Javascript, it doesn’t look too bad, but when you know Python, you have to bite your tongue just to get the work done.

Python’s community has revolved around the idea that there is one way to do it right. And the right way is to make life as easy as possible for the developer. We take all of the great ideas out there and put them together into a cohesive whole. Then we have so much fun coding in Python that we end up with a zillion different alternatives.

PyPI is making tremendous improvements. Nowadays, it is a viable alternative in many cases. LLVM is also exciting. Sure, Python programmers aren’t really pouring their resources into making Python beat Google’s v8 engine. But it’s not hard to understand why: Programming in python is just too much fun.

Closures, not Classes in Javascript May 25, 2011

Posted by PythonGuy in Javascript.
add a comment

Sometimes, closures are so cool that you think you can do everything with them. And then you realize that you can.

I was programming up a little widget in Javascript. I had one line of code that made an HTML element and stored. And then another that made a child element and stored it. Then it put it together. Inside that function, I had created a constructor of sorts.

When I went to connect up signals (such as “onclick”) to the internal elements, I simply put the functions inside the bigger function. Now it had full access to all the internal elements of the “class”. It could manipulate the elements as needed.

This is a pretty common paradigm in languages like Scheme and Lisp. In Javascript, it’s downright beautiful.

I don’t much like Javascript’s prototyping. Just when I thought I found a use for it, it turns out plain old classes were better. I don’t much like javascript’s quirks either. But the closures and ease of defining new functions makes everything else OK.

Still, every once in a while I take a peek at Pyjamas, and wonder if I am better off writing everything in Python the first time.