The JavaScript Age

God dammit... we had the rails fanboys, most recently the django fanboys and we have....node.js fanboys...come on really ?<p>I love all the above technologies, but nothing is dead, everything is evolving, and I currently look at node.js a really great software toy that has a very prosper future, but that's it. It still needs to mature.<p>Besides, we all know what "drinking the cool aid" sometimes does don't we (I'm looking at you twitter).

While I agree with the premise that the web should and is moving towards events. I think the author mistakenly anchors event-based development to JavaScript and NodeJS.<p>Since 2005 (available to the public in 2008), we've (along with numerous other platforms) been offering event-based websites and WebApps, via PHP with NOLOH (<a href="http://www.noloh.com" rel="nofollow">http://www.noloh.com</a>). In NOLOH, you the developer worry about writing your application, what it should do, how it should look, etc. and specify events on things, such as click, or your own custom events, and NOLOH takes care of the rest. In the case of a JavaScript enabled client, it'll render only the necessary JavaScript and DOM elements for that device at that given point in time and handle all the AJAX (and Comet where applicable), for search engines it will generate a semantically rich and standards compliant HTML version along with links to normally "non-crawlable" content. Similarly for text-based browsers, or non-JavaScript clients it'll output HTML. Furthermore, in the case of mobile devices, or slate devices, it'll output the correct code so that your app along with its clicks and drags still work. In all the above cases, the developer writes no JavaScript, nor does he even need to know that the client exists, he simply writes his app and it works. He/She can of course still use JavaScript if they please, but in most cases it's unnecessary, unless you're dealing with legacy code, or existing JavaScript widgets, and even in those cases, we abstract it out so that you can bind and sync without getting down into the nitty gritty.<p>So I don't believe the premise that we're in the JavaScript age is correct, as in many cases, you don't even render JavaScript, however, I do believe that the premise that we're in an event-based age is correct, I would even go so far as to suggest we're heading towards a platform or unified language age, as that's really the only way the craziness of the web is really manageable for rapid development, whether it's JavaScript, NOLOH in PHP, or something else, and I thought so in 2005.<p>Disclaimer: I'm a co-founder of NOLOH<p>[Edited: spelling and clarity]

I think the article is a little over-the-top but essentially right.<p>I used to hate JavaScript, but now that I've spent so long working with it and Canvas I enjoy it a lot. Obviously it is not the best possible language for the future of browser applications, but it's here already, and it will do.<p>"use strict"; Cannot come fast enough.

I completely disagree that the "normal" way of doing web development (frameworks such as Rails, Django, and the PHP frameworks) is obsolete. First of all, these frameworks can easily be used to build the Ajax-heavy web apps that the author(s) of the article talk about.<p>Secondly, search engines don't play too well with the Ajaxy web apps. It's not that you can't make them search engine friendly, it's just that once you do that, there's a bigger need for the "normal" frameworks.<p>Thirdly, I still prefer languages such as Python or PHP to JavaScript.

I'm not knocking on Javascript because its really not all that bad but, some very smart people are doing very interesting things with languages these days so its unfortunate to me that developers are being limited to Javascript in the browser just because its to the only choice available. Personally I liked the idea of a common bytecode language for the browser which has been raised here on HN before (<a href="http://news.ycombinator.com/item?id=1934021" rel="nofollow">http://news.ycombinator.com/item?id=1934021</a>).

Looks like we killed the poor guy's website. I mirrored the text here: <a href="https://gist.github.com/910648" rel="nofollow">https://gist.github.com/910648</a>

&#62; Its asynchronous, non-blocking architecture means it’s incredibly fast.<p>Those characteristics mean it can handle more simultaneous connections, but don't directly lead to more speed. I feel that is worth nitpicking about. Nodejs is pretty fast, but I think that has more to do with V8, libev, libio, and Ryan's http parser being really fast.

Ugh, this article is a load of nonsense.<p>Javascript is impossible to scale past the trivial application at the moment. Trying to read someone else's non-trivial source code in javascript is a total nightmare. It's too hard to write a big app in!<p>So it's not going to be the next big thing. It's a play language and always will be.<p>Unfortunately it's the only choice we have in the browser. If we had <i>any</i> other major language in the browser, even c++, it would have died long, long ago. We wouldn't even be talking about it today.

Given the increasing importance of JavaScript, I'm surprised there has not been more research into static type inference of JavaScript code (for compile-time type checking, not JIT code generation). I've only seen a couple academic papers on the subject. I see now that Unity 3D's game tools and Google's "Closure Compiler" support some type inference.

I read a similar article which was written five days earlier: <a href="http://www.richardrodger.com/2011/04/05/the-javascript-disruption/" rel="nofollow">http://www.richardrodger.com/2011/04/05/the-javascript-disru...</a><p>The author points out that Douglas Crockford's writings have played a big part in the language's resurgence - his book "The Good Parts" was what turned me, and I suspect a lot of others, back on to Javascript.

This post does sound a bit over-the-top and very node.js biased by calling LAMP architectures obsolete today. But on the other hand, there is a reason why JavaScript is the #1 language on Github - <a href="https://github.com/languages" rel="nofollow">https://github.com/languages</a>

It's like saying the arrangement of a plate is more important than what is on it. No need to hate on JS though just because it's the favorite rape-victim of amateurs.

&#62; For both of these roles, node.js is an ideal serving architecture.<p>Two "pro" points, no comparsions, and it is declared "ideal"?