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-01 06:17 pm (UTC)I have heard that CoffeeScript v 1.4 will add sourcemap support. I am really looking forward to that as I spend a large part of most days doing coffeescript.
(no subject)
Date: 2012-05-01 06:25 pm (UTC)CoffeeScript and Sourcemaps
Date: 2012-05-02 02:54 am (UTC)The other nice thing about CS is that the compiler is pretty simple so a lot of people have forked it to add new features. There was one that added types similar to haskell to it for example.
Now I need to figure out if there is a version of the Selenium IDE for Chrome, as it is the one piece of my workflow that is as far as I know firefox only. I find that Selenium makes a great macro recorder for web development.
Re: CoffeeScript and Sourcemaps
Date: 2012-05-02 06:18 pm (UTC)True, but unfortunately of limited use for the purposes of large-scale product development, where platform maturity is crucial. You can't have your product depend on someone's cobbled-together plugin, and building your own can turn into a maintenance headache.
This is, I should note, one of the reasons why Scala's new macro system is so exciting: it takes an area of functionality that previously depended on compiler plugins, and turns it into a first-class part of the language. This means that a lot of the fancy extensions can now be expressed as simply part of your libraries, rather than part of your development environment; that's likely to work much better from a maintenance POV.
Re: CoffeeScript and Sourcemaps
Date: 2012-05-03 02:47 am (UTC)I use CoffeeScript as I think it is a big enough improvement on Javascript to be worth it but close enough that I can bring someone new up to speed on it pretty quickly. Plus I have not gotten around to learning Clojure yet, its on my list but behind about 2 other languages. (Ruby and Haskell)
Re: CoffeeScript and Sourcemaps
Date: 2012-05-03 01:23 pm (UTC)And Haskell is the grand-daddy of modern functional programming, the language from which everybody else is taking their ideas. (Plus, Learn You a Haskell For Great Good is the best language tutorial *ever*, and makes the process relatively pleasant.)
But yeah, I'm pretty much sold on CoffeeScript as at least the right tool for now. I suspect that my own personal projects are going to start using it soon...
Re: CoffeeScript and Sourcemaps
Date: 2012-05-04 03:16 am (UTC)As for Haskell it seems to be where all the interesting ideas start which is reason alone to learn it.
This will also be a good year for books on Functional programming, I know of at least 1 on Haskell, 6 on Erlang, Real World OCaml, as well as books on Clojure and F# and a book on doing Monads in Javascript (examples mostly in CoffeeScript)
Re: CoffeeScript and Sourcemaps
Date: 2012-05-04 02:14 pm (UTC)I'm also currently (very slowly, in my spare moments) working through "Real-World Functional Programming With Examples in F# and C#", which is a nicely useful introduction to the subject for the .NET world. It's a bit slow, since it is starting from first principles, but not bad...
Re: CoffeeScript and Sourcemaps
Date: 2012-05-05 05:44 pm (UTC)I will admit that I have only partly wrapped my brain around monads and was using the book as a way to force myself to go the rest of the way.
The book I just shipped to the copy editing/production process on friday is "Building Web Applications in Erlang" which I am actually quite happy with.
Re: CoffeeScript and Sourcemaps
Date: 2012-05-06 07:53 pm (UTC)Re: CoffeeScript and Sourcemaps
Date: 2012-05-09 12:08 pm (UTC)Re: CoffeeScript and Sourcemaps
Date: 2012-05-09 01:26 pm (UTC)(no subject)
Date: 2012-05-01 09:34 pm (UTC)Ditto if you are coding for anything somebody is going to use from an iDevice.
(no subject)
Date: 2012-05-02 06:22 pm (UTC)For my purposes it hasn't been relevant anyway: I've been building data-intensive UIs that would be -- well, saying that making them accessible would be "challenging" is probably the understatement of the year. They're so chart-dependent that I can't even imagine how to make them work accessibly.
But the point is a fair one -- regardless of how challenging or not Flash is for building accessible interfaces, in practice it just doesn't happen...
(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