Ajax is…Dead?
October 4th, 2007One of Joel’s recent posts has been tumbling around in the back of my head. His observations are, as always, excellent. But unlike his usual posts, the conclusions drawn in this one mystify me. I see his point, but it feels…crazy.
One important truth he reveals is that software projects need not run optimally on today’s hardware; Moore’s law and the passage of time guarantee that when your product hits its prime market share, the hardware will be capable of supporting it.
Apply this maxim to development platforms, flip things around a bit, and we get this:
Any software development platform incapable of fully utilizing its hardware will surely fail.
This is true because there will always be some other platform that is capable of soaking up all that power, and that platform is going to have whiz-bang features that everyone’s gotta have right now that can’t be done in the old-fashioned turtle-speed platform.
Java is a great example. For those of us who used it back in the mid-90’s when it was brand new, it was slooooow. It was hard to believe that this was a “real” development platform. But it had some great features that outweighed the perf issues. And 10 years later, after 5 or so revs of Moore’s law and some nice optimization, Java is king. (Or at least queen.)
Case study #2: Ajax. Remember Ajax back in 2000? Yeah, I do too. If there’s a lesson to be learned from Java and Ajax, it’s this: your development platform should aim to run on tomorrow’s hardware. Worried that RoR is too CPU intensive? Relax, Moore’s Law will take care of it.
But…
Moore’s law isn’t quite the same as it used to be, now is it? As you might have heard (sarcasm), the multi-core world is coming, and a few people are a bit riled up about it.
Back to Joel and Ajax. Ajax depends on JavaScript, and JavaScript — as currently spec’d and implemented in browsers — is a single-core beast. The new version — supercharged kitchen-sink-of-features, still in its final spec’ing stages — will probably appear in the wild sometime late 2008. And what’s the new version doing to integrate well into the new multi-core world?
Well, nothing really. And it’s too late to change that.
So now we’re looking at version 3 of JavaScript before multi-core deficiencies will be addressed. Meanwhile it’s at least a few years before version 2 is established enough for Ajax apps and frameworks to depend on its features. Lather, rinse, repeat, it’s another couple years after that before theoretical multi-core Ajax apps are viable.
Repeat: the performance of Ajax apps will remain little-changed for the at least the next 3 to 5 years, unable to utilize multi-core processing power. (Same thing applies to Flash too, you’ll notice.) By that time, current processors will likely have 16+ cores. That’s a whopping amount of processing power lying dormant.
Do you think 5 years enough time for someone to build a platform that contains all the benefits of Ajax, plus some new great stuff, that lets developers soak up all the processing power in those extra cores, and deploy it to 90%+ of machines out there? Do you think maybe some of the big players have efforts in this space already underway? (hint: Gears is a start.) It’s just a question of who and how soon.
So what does this mean for Ajax? For one thing, it means that Ajax — as it currently exists is — will have to evolve for the long term. One of the major browser vendors is going to have break ranks and extend the browser platform to go multi-core (it won’t happen in lock-step — design-by-standards-committee is too slow and will inevitably lead to a back-stab). Either that or something new will emerge. (Or more likely, many new things will emerge.)
Get ready to brush up your skills…
October 5th, 2007 at 1:15 am
“[Joel's] conclusions drawn in this one mystify me. I see his point, but it feels…crazy.”
That’s a good summary of his whole blog, as far as I’m concerned. It drives me batty: observant and smart, yet subtly, pervasively wrong — missing key details, drawing skewed conclusions.
October 5th, 2007 at 9:38 am
Honestly I don’t agree. The force that drives web technologies is ease of deployment not processing power.
However better networking will affect them more than processing power and if you apply Moore’s law there you might me somehow right.
I think for instance that office tools are no longer affected by the Moore’s law. This goes for music players, chat programs, web browsing etc. and it still affects games, portals and movie editing.
October 5th, 2007 at 4:13 pm
I’m not sure about Moore’s law lifting Java - certainly in my line of work (primarily modelling and simulation, though I often end up doing the plumbing for distributed systems, or the front end, so that also puts me in web application/REST service land), people only took Java seriously when it was competitive on the same platform, and Moores’s law always got used to do more stuff, not to run slower code.
October 7th, 2007 at 8:26 pm
Is JS3 necessary to utilize multiple cores? JS is a high enough level language that isn’t it possible for some of the low level processing that goes into running JS (and the DOM, and rendering), parallizable? I believe that Firefox does already use multiple threads to do some work in the background to a very small degree. I am not convinced that browsers that use a language that guarantees thread-safe behavior dooms the entire browser to single core. But, of course, I have never written a VM, so what do I know…
October 9th, 2007 at 2:52 pm
Browser? We are still talking about browsers? Gears is a step in, what I feel, is the new direction. Also take into account the work Adobe has put into their AIR product. AJAX is not dead, but the browser (as we currently know it) is getting closer to expiration.
October 26th, 2007 at 10:03 pm
I never tire of reading about how the browser is about to die.
Kris: you are right that browsers can exploit hardware parallelism without imposing any concurrent programming chores on JS hackers. We’re working on this for Mozilla, in the Mozilla 2 timeframe.
Neil is right to cite Google Gears, but there’s nothing new and impossible to fit in the browser about the direction they point. The WHAT-WG is likely to standardize JS worker pools quickly. Shared-nothing is the simplest hardware-parallelizable concurrency model to try to add to the current browser programming world.
Good for Google for adding them. From what was said at their developer day, the impetus was concealing SQLite hard drive seek/write latencies. Foreground JS can starve the UI, and setTimeout is not enough.
/be
October 27th, 2007 at 11:43 am
Brendan: I didn’t say anything about the browser (nor would I — it’s here to stay). I did, however, point out that Ajax as a development platform is vulnerable for (at least) the next 5 years to platforms built from the ground up to natively support multi-core processing. Surely you understand the distinction? And surely someone is already aiming to take advantage of that vulnerability.
You’ve stated before that “JS3 will be ready for the multicore desktop workload.” I fully believe that. What I’m pointing out is that it may not be here soon enough.