Why are people still afraid of JavaScript?

The recent introduction of the Google Web Toolkit, which allows you to write your JavaScript in Java put a thought back into my conciousness: why are people going so far out of their way to avoid writing JavaScript today?

To their credit, the Google Web Toolkit provides some distinct reasons to choose it over hand-coded JavaScript: static typign (for those who like that kind of thing) and the ability to use the IDE you know and love.

And I’m certainly not opposed to encapsulating JavaScript into features that are native to your server-side toolkit’s language. Reducing the amount of code you need to write is always a good thing. (And TurboGears widgets do that very thing).

The part that I have trouble grokking is the various projects that implement Dynamic Language X (say Python or Ruby) to JavaScript conversions. Yes, JavaScript is prototype-based rather than class-based. But, otherwise it’s not a big leap to go from Python or Ruby to a language like JavaScript. Adding a layer that converts Python to JavaScript seems to me that it just introduces another place to fail, and a somewhat difficult one to troubleshoot at that since the execution environment is quite different from the environment in which you’re writing your code. If you run into problems with that conversion, you’ve got to learn the JavaScript and the JavaScript debugging tools and then also figure out what’s wrong with the translation!

For a dynamic language user, I just don’t see the benefit as being with the risk at this point.

You should certainly use a JavaScript library of some sort to ease common programming tasks. JavaScript-the-language is easy enough to follow, but there are certainly inconveniences in the built-in library and pitfalls in browser compatibility which any one of a number of great toolkits will help you deal with.

This is not a rant, by the way. I’m genuinely curious to hear why people who are already using a dynamic language feel that it’s a big leap to go to JavaScript. Or, if you don’t feel it’s a big leap, what other reasons are there to use Language Foo -> JavaScript translators.

12 thoughts on “Why are people still afraid of JavaScript?”

  1. The compiling alone will save me a ton of time. I’m forever getting these “has no value” errors, which usually means tracking down some silly typo somewhere that a compiler would have caught.

  2. One reason is that it allows you to keep the code “together” in one common language (for the most part).

    Also allows you to work at a higher level of abstraction that writing native Javascript.

  3. Keep in mind that I wasn’t advocating usnig “straight JavaScript”… I wouldn’t want to do without MochiKit or Dojo to deal with browser issues.

  4. I think it has less to do with JavaScript itself so much as the browser as a platform. It’s notoriously difficult to debug JS and there are tons of little quirks that can bite you (even if you use a toolkit like MochiKit). Writing cross-browser can be just as difficult as writing cross-platform, except the browser remains hopelessly primitive as a development platform compared to writing traditional software.

  5. I didn’t have time when I wrote that last comment to comment fully.

    Stepping back for a moment though: tools like GWT don’t eliminate JavaScript. If you’re hand-writing JavaScript and using Dojo or MochiKit, you’re expecting those toolkits to smooth over the browser issues. My experience with writing my own JavaScript to string together competently written, cross-browser-tested JavaScript tools has been positive.

    When you use a Language X->JavaScript tool, you’re still relying on a toolkit to smooth over the browser differences for you. The only trouble is that you’re one step removed… if you run into a problem you are totally at the mercy of the toolkit writer if you’re not at all familiar with JavaScript. And my point was that the benefit of using your “native” dynamic language vs. JavaScript was not high.

    The “Compiler caught errors” case was one that I was originally thinking applied only to Java->JavaScript, but I can imagine a Python->JavaScript converter having a bit of extra smarts to catch and prevent common errors.

    One of these days, I should give Crackajax a try and form a better firsthand opinion. But, speaking as someone who is far from a JavaScript guru, I’ve found that working with modern browsers and modern toolkits hasn’t been *that* painful. (Most of the pain has been absorbed by the toolkit writers.)

  6. Dynamic language users probably just don’t want to learn a new lexical convention and new libraries. Especially since the semantics of javascript is so close to Python and Ruby, using another notation and slightly different library calls just seem like extra work.

    The attraction for “enterprise programmers” who enjoy writing a GUI in Visual Basic or coding Java in eclipse is even more clear. Creating a simple UI element just got easier.

    When “compile-to-javascript” compilers get more mature, debugging the generated code may not be more of an issue than having to learn C programming to debug the CPython interpreter.

    For programmers who haven’t already learned a library like Mochikit and familiarized themselves with javascript development tools writing javascript is still major pains.

  7. I haven’t tried GWT, but Links (http://groups.inf.ed.ac.uk/links/) seems promising to me. Not because I’m afraid of JavaScript, but because it lets one to program everything in one (apparently statically typed?) functional language, which is specifically designed for the problems of web programming. (I’m not sure if the language is statically typed, because you can’t tell from the example source code. The authors seem to have plenty of experience in Haskell and as far as I can tell, the example programs could be fully type-inferenced.)

    Perhaps the greatest thing about Links is that functions are just declared to be either server or client -side functions. If client-function calls a server function, then a remote call is made. Moreover, it seems that if the result of server function is fed to another server-function, the compiler takes care that only server-call is made. No more worries about how to marshall calls etc. — you just make a function call and compiler takes care of rest.

    Moreover, the first-class support for database queries and XML/HTML -trees in code seems nice. (Not that Links is the only language to support this.) I’ve been inclined to believe that these sort of things would be better left to libraries, but when your domain is web programming, it could be beneficial to have a language that understands the concepts that occur all the time.

    That said, I haven’t done any work using Links, since it hasn’t been released yet.

  8. Scott: Excellent point about the quality of the compilers and the analogy with having to debug CPython (something I’ve never had to do in over 10 years of Python programming).

  9. An alternative question might be: Why are we still stuck with (essentially) just javascript as a web client programming language?

    What would people say would be the ideal replacement for javascript in the
    web client? One of the other better O-O scripting languages minus a bunch of
    extraneous libraries, and plus a dom manipulation library? Or what?

  10. So what exactly is wrong with dynamic typing? Is it all about “has no value” errors? How come i never seem to get those…

Comments are closed.