Javascript Technology Update [long]
May. 1st, 2012 12:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeur[I just sent a version of this around to my group at work, and figured that it may be generally interesting to folks here. This is an extensive braindump of a lot of related stuff I’ve been reading into in the past month as it comes across my RSS feeds. There are many links below, and they’re worth reading if you are interested in where the Web is going, but it’ll take some time to read through all of them. It basically expands on my post from yesterday about ClojureScript.]
In my work, ever since the year I spent on CommYou, I've been tending to favor Flash and Actionscript for serious UI development. That has nothing to do with HTML (HTML5 is pretty sweet) – it’s because Javascript is pretty much a disaster for trying to build sophisticated UIs. It works okay for simple projects, but as a tool evolves it turns into a gigantic maintenance headache.
This isn’t exactly a minority view: especially over the past year, there’s been a growing sense (I don’t know if I’d quite call it a “consensus” yet, but it’s getting there) that Javascript is the main impediment to Web development. Libraries like jQuery help, but can only do so much to paper over the weaknesses of a language that hasn’t meaningfully evolved in over a decade. So the open-source community, characteristically, has started to treat this as a bug and work around it.
This is mostly manifesting in the form of Javascript compilers: that is, new languages and tools that target Javascript as the *output*. Especially since Google turned Javascript execution speed into the front line of the browser wars, execution speed has improved dramatically – by orders of magnitude relative to IE6. The result is that pretty much all modern browsers (even recent versions of IE) execute Javascript blazingly fast. That allows people to start treating it as, essentially, machine language, and simply compile better languages to it.
That trend has picked up a *lot* of steam lately. I’d say that CoffeeScript is the only reasonably mature compiles-to-Javascript language, and it’s one of the most conservative – not a fancy state-of-the-art language, but good enough to make development much faster than raw Javascript – but there are tons of other options in the works. Here’s a look at a few.
One of the most intriguing projects in the works in Google’s Traceur compiler. Traceur basically compiles ECMAScript 6 – Javascript.Next, essentially, the dialect currently under discussion – into ordinary ECMAScript 3 (what’s actually implemented in all the browsers). Their theory, I believe, is that this will allow people to begin using the new version of the language immediately, without trying to achieve a now-impossible consensus for putting it into the browsers. The Traceur compiler is new and very experimental, and changing frequently (reflecting the arguments raging in the standards committees). But in the long run, this is likely to become an enormously helpful evolutionary tool, allowing the next-generation standard to actually be used in real browsers.
More crucially, Google also has the Closure Compiler, which is increasingly accepted as one of the central tools for serious web development. Closure is an odd tool: it compiles Javascript to *better* Javascript, doing optimization and minimizing as it goes. As such, it gets used as the end-stage for many companies and tools these days: whatever else you are starting with, you tend to finish by running your code through Closure, so that the end result is quicker to load and run.
Of course, Closure (and indeed, many of these tools) result in entirely unreadable Javascript. That’s where the new movement towards Source Maps comes in. Source Maps are essentially PDB files for the web: mappings from the “object” files (the compressed final Javascript) back to the original sources. This allows web debuggers to work much the same way as traditional ones do: as you work your way through an executing program, it shows you the original source code that your current state corresponds to.
The Source Map model seems to be quickly turning into a de facto standard, and Google is building support for it directly into Chrome Canary, the bleeding-edge version of their browser. (Essentially the development stream of Chrome. And I’ve seen some evidence that this feature has been promoted into Chrome proper, although I’m not certain of that.) Right now, I believe that only supports Javascript as the source language, but the standard is deliberately language-neutral, and folks are talking about using the technology to support many of these compiled-to-Javascript environments.
ClojureScript came to my attention a couple of days ago. Clojure is one of the two primary next-generation languages in the JVM – the languages that are likely to take over as Java (which is now horribly out of date) gradually gets dropped by the cutting-edge engineering community. I’ve burbled about Scala before -- that’s the ML descendent in this competition, whereas Clojure is the Lisp descendent. As such, it’s not going to be everybody’s cup of tea, but it’s an extremely powerful, cutting-edge functional language, and is one of the major up-and-coming languages. ClojureScript is basically a Clojure-to-Javascript compiler, and comes with a nice set of libraries that do things like wrap jQuery in idiomatic ClojureScript classes.
(ClojureScript is also the basis for Light Table, an extraordinary new tool under development for developing web apps. LT is a radical rethink of the IDE, throwing away all the persistent menus and windows in favor of a clean work table and a remarkably interactive environment that encourages test-as-you-go programming by showing you the state of your program as you execute tests. It incorporates the Code Bubbles concept, but carries it much further. Fascinating stuff, and a real vision of the future of programming.)
Anyway, this is just scratching the surface of a very large topic. For many, many more pointers, take a look at these lists:
http://altjs.org/
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
Those include compilers for Ruby, Python, Perl, Java, Scala and even C# into Javascript, and many more.
There are caveats here, of course. All of these depend on having a modern standards-friendly browser to run on, and IE really only got to fitting that description in IE9. The vast majority of these tools are open-source and at best community-supported, and most of them are pretty immature. It’s going to be a while before we know which of them shake out to become mature environments that you can safely use for product development. But things are moving very quickly now, so odds are that within the next year some of them will start to firm up, and some (especially Closure and CoffeeScript) are now so widespread that one has to consider them decently mature.
So it’s increasingly clear that this is the way the wind is blowing. Javascript as a development language is beginning to die off, the same way assembly language did. Instead, it’s becoming the super-fast substrate to which better languages get targeted. The only question now is really which of these higher-level languages and environments will gain enough traction for serious commercial use…
In my work, ever since the year I spent on CommYou, I've been tending to favor Flash and Actionscript for serious UI development. That has nothing to do with HTML (HTML5 is pretty sweet) – it’s because Javascript is pretty much a disaster for trying to build sophisticated UIs. It works okay for simple projects, but as a tool evolves it turns into a gigantic maintenance headache.
This isn’t exactly a minority view: especially over the past year, there’s been a growing sense (I don’t know if I’d quite call it a “consensus” yet, but it’s getting there) that Javascript is the main impediment to Web development. Libraries like jQuery help, but can only do so much to paper over the weaknesses of a language that hasn’t meaningfully evolved in over a decade. So the open-source community, characteristically, has started to treat this as a bug and work around it.
This is mostly manifesting in the form of Javascript compilers: that is, new languages and tools that target Javascript as the *output*. Especially since Google turned Javascript execution speed into the front line of the browser wars, execution speed has improved dramatically – by orders of magnitude relative to IE6. The result is that pretty much all modern browsers (even recent versions of IE) execute Javascript blazingly fast. That allows people to start treating it as, essentially, machine language, and simply compile better languages to it.
That trend has picked up a *lot* of steam lately. I’d say that CoffeeScript is the only reasonably mature compiles-to-Javascript language, and it’s one of the most conservative – not a fancy state-of-the-art language, but good enough to make development much faster than raw Javascript – but there are tons of other options in the works. Here’s a look at a few.
One of the most intriguing projects in the works in Google’s Traceur compiler. Traceur basically compiles ECMAScript 6 – Javascript.Next, essentially, the dialect currently under discussion – into ordinary ECMAScript 3 (what’s actually implemented in all the browsers). Their theory, I believe, is that this will allow people to begin using the new version of the language immediately, without trying to achieve a now-impossible consensus for putting it into the browsers. The Traceur compiler is new and very experimental, and changing frequently (reflecting the arguments raging in the standards committees). But in the long run, this is likely to become an enormously helpful evolutionary tool, allowing the next-generation standard to actually be used in real browsers.
More crucially, Google also has the Closure Compiler, which is increasingly accepted as one of the central tools for serious web development. Closure is an odd tool: it compiles Javascript to *better* Javascript, doing optimization and minimizing as it goes. As such, it gets used as the end-stage for many companies and tools these days: whatever else you are starting with, you tend to finish by running your code through Closure, so that the end result is quicker to load and run.
Of course, Closure (and indeed, many of these tools) result in entirely unreadable Javascript. That’s where the new movement towards Source Maps comes in. Source Maps are essentially PDB files for the web: mappings from the “object” files (the compressed final Javascript) back to the original sources. This allows web debuggers to work much the same way as traditional ones do: as you work your way through an executing program, it shows you the original source code that your current state corresponds to.
The Source Map model seems to be quickly turning into a de facto standard, and Google is building support for it directly into Chrome Canary, the bleeding-edge version of their browser. (Essentially the development stream of Chrome. And I’ve seen some evidence that this feature has been promoted into Chrome proper, although I’m not certain of that.) Right now, I believe that only supports Javascript as the source language, but the standard is deliberately language-neutral, and folks are talking about using the technology to support many of these compiled-to-Javascript environments.
ClojureScript came to my attention a couple of days ago. Clojure is one of the two primary next-generation languages in the JVM – the languages that are likely to take over as Java (which is now horribly out of date) gradually gets dropped by the cutting-edge engineering community. I’ve burbled about Scala before -- that’s the ML descendent in this competition, whereas Clojure is the Lisp descendent. As such, it’s not going to be everybody’s cup of tea, but it’s an extremely powerful, cutting-edge functional language, and is one of the major up-and-coming languages. ClojureScript is basically a Clojure-to-Javascript compiler, and comes with a nice set of libraries that do things like wrap jQuery in idiomatic ClojureScript classes.
(ClojureScript is also the basis for Light Table, an extraordinary new tool under development for developing web apps. LT is a radical rethink of the IDE, throwing away all the persistent menus and windows in favor of a clean work table and a remarkably interactive environment that encourages test-as-you-go programming by showing you the state of your program as you execute tests. It incorporates the Code Bubbles concept, but carries it much further. Fascinating stuff, and a real vision of the future of programming.)
Anyway, this is just scratching the surface of a very large topic. For many, many more pointers, take a look at these lists:
http://altjs.org/
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
Those include compilers for Ruby, Python, Perl, Java, Scala and even C# into Javascript, and many more.
There are caveats here, of course. All of these depend on having a modern standards-friendly browser to run on, and IE really only got to fitting that description in IE9. The vast majority of these tools are open-source and at best community-supported, and most of them are pretty immature. It’s going to be a while before we know which of them shake out to become mature environments that you can safely use for product development. But things are moving very quickly now, so odds are that within the next year some of them will start to firm up, and some (especially Closure and CoffeeScript) are now so widespread that one has to consider them decently mature.
So it’s increasingly clear that this is the way the wind is blowing. Javascript as a development language is beginning to die off, the same way assembly language did. Instead, it’s becoming the super-fast substrate to which better languages get targeted. The only question now is really which of these higher-level languages and environments will gain enough traction for serious commercial use…
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2012-05-02 08:15 pm (UTC)(I am assuming this is what you meant by charts. If not, apologies.)
(no subject)
Date: 2012-05-02 08:58 pm (UTC)The info is available in tabular form, but it's so voluminous as to be nearly useless. The point of the UI is to be able to provide a gestalt of a huge amount of data in condensed form, so you can see how this one item is just sort of *wrong*.
(Not to mention that the *other* primary thing you are doing in this app is on-the-fly handwriting analysis, comparing two signatures and making an educated guess about whether one of them is forged.)
Seriously, when I say that this app is hard to make accessible, I mean it's one of the hardest such problems I've ever seen. I suspect it's Ph.D level work to come up with a workable model for each individual element...
(no subject)
Date: 2012-05-02 09:24 pm (UTC)If any of