6 ms·

My gripes with JavaScript

60 points by fholm 15y ago

mrspeaker 15y ago
I'm sure you'll be happy to know that all your gripes are de-griped in js.next (http://wiki.ecmascript.org/doku.php?id=harmony:harmony http://wiki.ecmascript.org/doku.php?id=harmony:harmony - and strawman) - and with the speed of browser upgrades they'll hopefully be here the "reasonably close" future. Hopefully.
- fholm 15y ago
  I'm well aware of js.next/harmony/whateveryouwannacallit. Come back to me in 10 years when it's implemented everywhere and everyone that was on an old version of browser X has upgraded to one with those features.
  - olavk 15y ago
    Or use a tool that compiles js.next to lowest-common-denominator-javascript.
    - fholm 15y ago
      Yay a dynamic language with a compiler step.
      - olavk 15y ago
        Python has a compiler step - source files (.py) are compiled into bytecode (.pyc) files. It just happens transparently. Doesn't make the language less dynamic IMHO.
      - true_religion 15y ago
        Smalltalk, one of the seminal, dynamic languages has a compilation step. It happens inline everytime you save a method. Lisp can both be dynamic and compiled. Many dynamic languages---Python, Ruby, et all--on JVM or CLR have a compilation step. They compile to byte code that the VM then runs.
    - edtechdev 15y ago
      http://code.google.com/p/traceur-compiler/ http://code.google.com/p/traceur-compiler/
- georgemcbay 15y ago
  "Hopefully" indeed -- I had a lot of hope for ECMAScript 4 back in 2007, and look how that turned out. As with most "next gen" web browser technology (for whatever your 'current gen' may be, back to Netscape 2.0), until I see it actually shipping in a majority of browsers I will remain skeptical.
Spines11 15y ago
JavaScript is definitely very easy to mess up, but if you follow best practices, I think it can actually be a pretty nice language.
billybob 15y ago
There seems to be agreement that Javascript is a messy language which is popular by default: it was included in Netscape, then other browsers picked it up. Now we're stuck with it. I realize this would be very difficult and introduce horrible compatibility issues for a while, but sometimes I think, "what if we could start over?" What if Chrome and Firefox started supporting Python or Ruby or a custom, well-designed language for web scripting? Could it gain enough momentum to replace Javascript? Actually, the easiest candidate would be for browsers to start natively supporting Coffeescript. But imagine a "dream team" designing a language just for the web, from scratch: Douglas Crockford, John Resig, Guido van Rossum, Yukihiro Matsumoto... Is this a "it's crazy but it just might work" scenario, or is it just crazy?
- protomyth 15y ago
  If we started over, we should pick a VM, not a language.
  - vmind 15y ago
    Some kind of flexible bytecode implemented across browsers would be fantastic, and you could always implement a fallback interpreter in javascript (or if feeling fancy, a decompiler).
    - windsurfer 15y ago
      Isn't Javascript a flexible bytecode?
      - vmind 15y ago
        Well, yes, but it comes with all the overhead of being a (partly) flawed language. Having a bytecode that allows, for instance, optional static and dynamic types would be much more direct than relying on type inference or separate native APIs (as are being introduced). Of course we have javascript now, so pragmatically languages should be compiled to it if we want them, but if there were to be an additional web bytecode, there would be many areas for improvement in terms of performance and safety.
franze 15y ago
i never thought that one day i will be the quy who posts this: try coffeescript, it really really helps (i would not believe it at first, either)
- fholm 15y ago
  I'm not a fan of CoffeScript, it fixes the wrong problems. It's not the syntax that's the REAL issue, it's the fragmentation, lack of module system, etc.
  - gmac 15y ago
    CoffeeScript doesn't do much to fix the bad bits -- it's still JavaScript, after all -- but it does make the good bits way more fun.
  - franze 15y ago
    i agree, the biggest fix of coffeescript is not the syntax ( i never saw the JS syntax as the issue), the biggest fix / benefit of CS is: Everything is an Expression (at least, as much as possible) a lot of the hassles with JS just disappear with this "small" change (if applied extensivly)
jerf 15y ago
The other problem I would see is obvious if you continue with something like the following logic: All successful languages passed through a phase in which they had a broadly similar list of problems. How did they escape from that phase? Because somebody had the power to move the language forward. Somebody (or small set of somebodies) could say "yes" to that idea and "no" to the other idea, and implement them, and have them out for use in a matter of months, gather feedback on the results, and after ten years of repeating that, create a credible platform. Javascript's root problem is that there is nobody who plays that role. The language has now been around for ~15 years, but it has hardly changed in the meantime. Not zero, I know that, but compared to the advances that any other language made over the same period of its life, Javascript has hardly moved at all. Not since Netscape lost the ability to unilaterally move the language forward by virtue of having the de facto only implementation has the language been able to move much. So not only does the language have problems, right now, there is no effective path for those problems to be fixed in any reasonable period of time. We know this, because js.next shouldn't be "something we hope to see in a few years" but rather something that should have been done ~2002/2003, if the whole improvement process wasn't so broken. (BTW, remember to separate "the language" from "the bindings". XMLHTTPRequest was not a Javascript change, for instance, just a new binding that all browsers had.) Even the standardization process is slow, somewhat disconnected from implementation, and is still essentially focused on fixing syntax problems that have been dangling for a decade now. If js.next somehow successfully manifests in the next few years, we still have a lot of problems in the library department, for instance. Server-side JS will probably face a decision point at some point in the not-very-near future, where the decision will have to be made as to whether it sticks as close to client-side, browser JS controlled by a effectively-leaderless process running at vanishing fractions of the rate of improvement of any other language, or if it runs off to start creating its own improvements, probably by paving over the cowpaths. I actually favor the latter, because it would create some set of people who can say yea or nay, restore an actual feedback loop, and create progress which could then be propagated back to clients as appropriate.
- fholm 15y ago
  Very well put, pretty much agree with it completely.
- 15y ago
BasDirks 15y ago
I used to hate JS. In fact, like the over-opinionated teenager I was I wouldn't waste any decent opportunity to make this known to my friends and the rest of the world: "Real hackers use C, Haskell, Python or LISP!1". But then as I started doing design work for web, I inevitably came in contact with JS, and lots of it. And hey, you could actually build stuff with this shit. Then, being as obsessed as I am with aesthetics and thus coding style and best practices, I found out that it's actually possible to write good (looking) programs with JavaScript. Add some CoffeeScript and underscore to the mix, and I could even write them with pleasure. This touching lifestory isn't meant to convince you that JS is any good, but it should illustrate why/how certain individuals come to join the dark side.
deleted 15y ago
[deleted]
MrNibbles 15y ago
ES6 Will improve things, see the presentation by Dimitry Soshnikov here: http://www.slideshare.net/dmitrysoshnikov/falsyvalues-dmitry-soshnikov-ecmascript-6 http://www.slideshare.net/dmitrysoshnikov/falsyvalues-dmitry... Note the modules implementation ;) While it will take a while for legacy browsers (IE 6-8) to die out, we are quickly moving to a regular automatic update process for browsers which will help us rev javascript quickly. I agree, right now it has problems. But, on the server side we can implement these new features as soon as they are written into the interpreters. Less of a problem.
kragen 15y ago
His main point: "there are a couple of critical problems with JavaScript that prevents it from ever being a viable alternative as development platform for server application development." But then he goes on to list things like "Lack of language defined modules and namespaces" (which it has in common with COBOL, C, and PHP), "null vs. undefined" (JS has eight kinds of nothingness — '', false, null, undefined, NaN, 0, [], and {} — as opposed to a usually slightly smaller number, although Python has nine: '', None, [], {}, (), NaN, 0, 0.0, and False), etc. I think he has failed to prove his point.
pnathan 15y ago
Javascript is a really lousy language thrown together in two weeks or so. What ideally should happen is browsers should expose the VM and an entry point for interpreters to use and configure JS on the VM. That way other languages could be used against the VM-in-browser. I suspect Google is trying to move in this direction, but IDK.
david_a_r_kemp 15y ago
The author strikes out at the "same language on the server and client" claim, which I think is a bit unfair. one of the great things about node.js for me is that it is (mostly) js, so I can crank it open and understand what's going on - this is especially true for libraries. I know js pretty well (and most of the syntax hacks), so this is pretty straight forward. If I try and do the same thing with django or rails, then I find myself investing serious amounts of time just understanding the syntax (the splat operator is a good example). Using the same language (not necessarily the same environment) that you already know on the server does have genuine benefits, even if you do have to treat it differently.

60 points by fholm 15y ago

I'm sure you'll be happy to know that all your gripes are de-griped in js.next (http://wiki.ecmascript.org/doku.php?id=harmony:harmony http://wiki.ecmascript.org/doku.php?id=harmony:harmony - and strawman) - and with the speed of browser upgrades they'll hopefully be here the "reasonably close" future. Hopefully.

fholm 15y ago
I'm well aware of js.next/harmony/whateveryouwannacallit. Come back to me in 10 years when it's implemented everywhere and everyone that was on an old version of browser X has upgraded to one with those features.
- olavk 15y ago
  Or use a tool that compiles js.next to lowest-common-denominator-javascript.
  - fholm 15y ago
    Yay a dynamic language with a compiler step.
    - olavk 15y ago
      Python has a compiler step - source files (.py) are compiled into bytecode (.pyc) files. It just happens transparently. Doesn't make the language less dynamic IMHO.
    - true_religion 15y ago
      Smalltalk, one of the seminal, dynamic languages has a compilation step. It happens inline everytime you save a method. Lisp can both be dynamic and compiled. Many dynamic languages---Python, Ruby, et all--on JVM or CLR have a compilation step. They compile to byte code that the VM then runs.
  - edtechdev 15y ago
    http://code.google.com/p/traceur-compiler/ http://code.google.com/p/traceur-compiler/
georgemcbay 15y ago
"Hopefully" indeed -- I had a lot of hope for ECMAScript 4 back in 2007, and look how that turned out. As with most "next gen" web browser technology (for whatever your 'current gen' may be, back to Netscape 2.0), until I see it actually shipping in a majority of browsers I will remain skeptical.

Spines11 15y ago

JavaScript is definitely very easy to mess up, but if you follow best practices, I think it can actually be a pretty nice language.

billybob 15y ago

There seems to be agreement that Javascript is a messy language which is popular by default: it was included in Netscape, then other browsers picked it up. Now we're stuck with it. I realize this would be very difficult and introduce horrible compatibility issues for a while, but sometimes I think, "what if we could start over?" What if Chrome and Firefox started supporting Python or Ruby or a custom, well-designed language for web scripting? Could it gain enough momentum to replace Javascript? Actually, the easiest candidate would be for browsers to start natively supporting Coffeescript. But imagine a "dream team" designing a language just for the web, from scratch: Douglas Crockford, John Resig, Guido van Rossum, Yukihiro Matsumoto... Is this a "it's crazy but it just might work" scenario, or is it just crazy?

protomyth 15y ago
If we started over, we should pick a VM, not a language.
- vmind 15y ago
  Some kind of flexible bytecode implemented across browsers would be fantastic, and you could always implement a fallback interpreter in javascript (or if feeling fancy, a decompiler).
  - windsurfer 15y ago
    Isn't Javascript a flexible bytecode?
    - vmind 15y ago
      Well, yes, but it comes with all the overhead of being a (partly) flawed language. Having a bytecode that allows, for instance, optional static and dynamic types would be much more direct than relying on type inference or separate native APIs (as are being introduced). Of course we have javascript now, so pragmatically languages should be compiled to it if we want them, but if there were to be an additional web bytecode, there would be many areas for improvement in terms of performance and safety.

franze 15y ago

i never thought that one day i will be the quy who posts this: try coffeescript, it really really helps (i would not believe it at first, either)

fholm 15y ago
I'm not a fan of CoffeScript, it fixes the wrong problems. It's not the syntax that's the REAL issue, it's the fragmentation, lack of module system, etc.
- gmac 15y ago
  CoffeeScript doesn't do much to fix the bad bits -- it's still JavaScript, after all -- but it does make the good bits way more fun.
- franze 15y ago
  i agree, the biggest fix of coffeescript is not the syntax ( i never saw the JS syntax as the issue), the biggest fix / benefit of CS is: Everything is an Expression (at least, as much as possible) a lot of the hassles with JS just disappear with this "small" change (if applied extensivly)

jerf 15y ago

The other problem I would see is obvious if you continue with something like the following logic: All successful languages passed through a phase in which they had a broadly similar list of problems. How did they escape from that phase? Because somebody had the power to move the language forward. Somebody (or small set of somebodies) could say "yes" to that idea and "no" to the other idea, and implement them, and have them out for use in a matter of months, gather feedback on the results, and after ten years of repeating that, create a credible platform. Javascript's root problem is that there is nobody who plays that role. The language has now been around for ~15 years, but it has hardly changed in the meantime. Not zero, I know that, but compared to the advances that any other language made over the same period of its life, Javascript has hardly moved at all. Not since Netscape lost the ability to unilaterally move the language forward by virtue of having the de facto only implementation has the language been able to move much. So not only does the language have problems, right now, there is no effective path for those problems to be fixed in any reasonable period of time. We know this, because js.next shouldn't be "something we hope to see in a few years" but rather something that should have been done ~2002/2003, if the whole improvement process wasn't so broken. (BTW, remember to separate "the language" from "the bindings". XMLHTTPRequest was not a Javascript change, for instance, just a new binding that all browsers had.) Even the standardization process is slow, somewhat disconnected from implementation, and is still essentially focused on fixing syntax problems that have been dangling for a decade now. If js.next somehow successfully manifests in the next few years, we still have a lot of problems in the library department, for instance. Server-side JS will probably face a decision point at some point in the not-very-near future, where the decision will have to be made as to whether it sticks as close to client-side, browser JS controlled by a effectively-leaderless process running at vanishing fractions of the rate of improvement of any other language, or if it runs off to start creating its own improvements, probably by paving over the cowpaths. I actually favor the latter, because it would create some set of people who can say yea or nay, restore an actual feedback loop, and create progress which could then be propagated back to clients as appropriate.

fholm 15y ago
Very well put, pretty much agree with it completely.
15y ago

BasDirks 15y ago

I used to hate JS. In fact, like the over-opinionated teenager I was I wouldn't waste any decent opportunity to make this known to my friends and the rest of the world: "Real hackers use C, Haskell, Python or LISP!1". But then as I started doing design work for web, I inevitably came in contact with JS, and lots of it. And hey, you could actually build stuff with this shit. Then, being as obsessed as I am with aesthetics and thus coding style and best practices, I found out that it's actually possible to write good (looking) programs with JavaScript. Add some CoffeeScript and underscore to the mix, and I could even write them with pleasure. This touching lifestory isn't meant to convince you that JS is any good, but it should illustrate why/how certain individuals come to join the dark side.

deleted 15y ago

[deleted]

MrNibbles 15y ago

ES6 Will improve things, see the presentation by Dimitry Soshnikov here: http://www.slideshare.net/dmitrysoshnikov/falsyvalues-dmitry-soshnikov-ecmascript-6 http://www.slideshare.net/dmitrysoshnikov/falsyvalues-dmitry... Note the modules implementation ;) While it will take a while for legacy browsers (IE 6-8) to die out, we are quickly moving to a regular automatic update process for browsers which will help us rev javascript quickly. I agree, right now it has problems. But, on the server side we can implement these new features as soon as they are written into the interpreters. Less of a problem.

kragen 15y ago

His main point: "there are a couple of critical problems with JavaScript that prevents it from ever being a viable alternative as development platform for server application development." But then he goes on to list things like "Lack of language defined modules and namespaces" (which it has in common with COBOL, C, and PHP), "null vs. undefined" (JS has eight kinds of nothingness — '', false, null, undefined, NaN, 0, [], and {} — as opposed to a usually slightly smaller number, although Python has nine: '', None, [], {}, (), NaN, 0, 0.0, and False), etc. I think he has failed to prove his point.

pnathan 15y ago

Javascript is a really lousy language thrown together in two weeks or so. What ideally should happen is browsers should expose the VM and an entry point for interpreters to use and configure JS on the VM. That way other languages could be used against the VM-in-browser. I suspect Google is trying to move in this direction, but IDK.

david_a_r_kemp 15y ago

The author strikes out at the "same language on the server and client" claim, which I think is a bit unfair. one of the great things about node.js for me is that it is (mostly) js, so I can crank it open and understand what's going on - this is especially true for libraries. I know js pretty well (and most of the syntax hacks), so this is pretty straight forward. If I try and do the same thing with django or rails, then I find myself investing serious amounts of time just understanding the syntax (the splat operator is a good example). Using the same language (not necessarily the same environment) that you already know on the server does have genuine benefits, even if you do have to treat it differently.