11 ms·

The JavaScript Age

119 points by hanifvirani 16y ago

simonsarris 16y ago
I think the article is a little over-the-top but essentially right. 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. "use strict"; Cannot come fast enough.
- mberning 16y ago
  Agreed. To me the most hateful thing about using javascript is that I typically write it to be executed in a browser. It's an absolutely a terrible environment to develop, test, and debug in. Plugins make this better, but it is still problematic. Server side javascript is a decidedly better development experience.
  - city41 16y ago
    > It's an absolutely a terrible environment to develop, test, and debug in. For large, essential apps I can see that. Although there are tools that make the experience much better. But man do I love what JavaScript and browsers have blossomed into. I've always wanted a really nice, simple environment where I can just write a small, self contained app with little overhead, little fuss, and wide ability for it to be adopted. JavaScript plus the new HTML5 goodies fulfills that wish far better than anything else in the past. I've grown to really fall in love with the little bastard language :)
  - derleth 16y ago
    Server-side JS exposes the strengths of the language; in-browser JS exposes the weaknesses of browsers. How much difference a platform can make!
    - deleted 16y ago
      [deleted]
    - ggoodale 16y ago
      Very, very true. Client-side javascript suffers a debilitating flaw: it's largely used to manipulate the DOM, which is sadly still an ugly task despite over a decades' worth of effort. Provided you can sandbox that part of your code away from the rest, client-side javascript is every bit as palatable as the rest.
  - wladimir 16y ago
    I find that with firebug, client-side javascript development is pretty comfortable. Most frustrating is debugging a script that works in Firefox, but doesn't work in IE. I haven't used JS server side so I don't have a comparison, though.
    - geuis 16y ago
      http://jsonlint.com http://jsonlint.com I find this immensely helpful when testing json data. There's something that happens in jQuery I ran into where $.get() on a relative json resource was being retrieved, but the callback function wasn't executing. The data was retrieved according to the network analyzer, and ajaxError() was firing, but that was it. Ran the json file through jsonlint and found some problems I needed to fix. Then it worked.
    - jerf 16y ago
      "Most frustrating is debugging a script that works in Firefox, but doesn't work in IE." Delete the trailing comma in your object literal.
      - wladimir 16y ago
        Yeah, those are pretty easy to find using JSlint.
        beej71 16y ago
        Closure Compiler just errors out. "This won't run on IE, and you don't want it."
      - geekuskhan 16y ago
        I created an account just to say amen. I can't tell you how many times this has frustrated me in IE. Seems like I would learn.
  - rplevy 16y ago
    I agree, JavaScript development can be maddening, even with (and because of!) helpful plug-ins like Firebug. Lispers spoiled by swank/slime in emacs may like https://github.com/ivan4th/swank-js https://github.com/ivan4th/swank-js as a JavaScript dev environment.
- dougabug 16y ago
  While I've said pretty much everything in the article to my friends and co-workers over the past several months... I'd still say at this point it qualitifes as FUD.
deleted 16y ago
[deleted]
- Gorm-Casper 16y ago
  Did so for me too at first. Kind of ironic actually :)
  - joeraii 16y ago
    actually, we were serving the blog off of a tiny, poorly configured apache instance :)
hanifvirani 16y ago
Looks like we killed the poor guy's website. I mirrored the text here: https://gist.github.com/910648 https://gist.github.com/910648
- vog 16y ago
  Why do so many blogs fail to perform the most basic thing on the web? Why do they fail to deliver dead-simple, small, static content?
  - shantanubala 16y ago
    Because most people don't expect a ton of traffic, and generating every page dynamically works until they're surprised to have hundreds of visitors in a short period of time.
    - vog 16y ago
      So programmers of Blog software think that lots of page visits are some kind of accident? I hope not! Also, handling lots of requests for small, static content is note exactly a tough problem. (Although it requires a minimum of care.) To any author who cares about what he writes (publishes), being read by many people is a great chance. However, crappy blog software deliberately destroys all those nice opportunities in advance.
      - shantanubala 16y ago
        Exactly my point. People don't realize the flaws in the blog software they use until they encounter a bunch of traffic.
  - justincormack 16y ago
    Wordpress. The database backed era this post talks about didnt really use web architecture well, or good software architecture to perform. Aimed at ease of use instead. Mind you I am not convinced that event driven js is going to deliver high performance blogs either. Must move my blog off Wordpress before getting featured here...
eklovlfjkeos 16y ago
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. 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. Thirdly, I still prefer languages such as Python or PHP to JavaScript.
- nevinera 16y ago
  >Secondly, search engines don't play too well with the Ajaxy web apps. Search engines are for finding content, not for apps. If you have data in your app that a search engine could reasonably want to index, give it a resourceful route of some kind, and tell engines where to look - if that doesn't make sense, it's probably not a resource an engine would be interested in.
  - eklovlfjkeos 16y ago
    > Search engines are for finding content, not for apps I agree, and one of the points that I forgot to write above is that the article seems to focus too much on apps. A lot of web development isn't about apps.
    - justincormack 16y ago
      The article is claiming that we are removing from resources (http, rest) to events, ie apps, for everything. I do think there is still space for the other style done well, with content, but a lot of people seem not to. One of the facets of the web/app war.
      - nevinera 16y ago
        If that's the case (and I don't think that's really what he said), it would be a foolish claim. Resources are fundamental to the human experience. On the web most things are just data, but if that data has value to anyone, it's a resource. Events are fundamental too, and I'm quite happy that the web seems to be evolving to handle them as well.. But resources will always exist, and any 'event' that has enough data for an engine to be interested in indexing it is carrying a resource.
deleted 16y ago
[deleted]
deleted 16y ago
[deleted]
cpeterso 16y ago
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.
asnyder 16y ago
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. 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 (http://www.noloh.com http://www.noloh.com). 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. 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. Disclaimer: I'm a co-founder of NOLOH [Edited: spelling and clarity]
phatbyte 16y ago
God dammit... we had the rails fanboys, most recently the django fanboys and we have....node.js fanboys...come on really ? 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. Besides, we all know what "drinking the cool aid" sometimes does don't we (I'm looking at you twitter).
mattmanser 16y ago
Ugh, this article is a load of nonsense. 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! So it's not going to be the next big thing. It's a play language and always will be. Unfortunately it's the only choice we have in the browser. If we had any other major language in the browser, even c++, it would have died long, long ago. We wouldn't even be talking about it today.
- ivank 16y ago
  Have you seen Closure Library and Closure Compiler? It's definitely feasible to write a million-LOC JavaScript application (Gmail is one). Your JavaScript doesn't have to be a mess.
  - famousactress 16y ago
    To be fair.. Gmail is not one - http://googlesystem.blogspot.com/2010/06/gmail-to-use-more-html5-features.html http://googlesystem.blogspot.com/2010/06/gmail-to-use-more-h... Still... 440k+ isn't small.
    - abraham 16y ago
      While unlikely it is possible that Gmail has added 550k in the (almost) year since.
- gmisra 16y ago
  Might be interesting to think about why we don't have any other major languages in the browser? Javascript suffers from a lot of historical baggage and a lot of bad javascript on the web. One of the most helpful developments in the past few years has been the emergence of a "better" subset of js, led by Douglas Crockford's mafia, jslint, jshint, jsonlint etc. It's hard to argue that any language+platform has a more vibrant ecosystem right now than js+node.js
- famousactress 16y ago
jimmyjazz14 16y ago
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 (http://news.ycombinator.com/item?id=1934021 http://news.ycombinator.com/item?id=1934021).
sayemm 16y ago
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 - https://github.com/languages https://github.com/languages
- hassy 16y ago
  That reason is likely to be jQuery included in every other project on Github.
  - sayemm 16y ago
    That only proves the point. I don't fully agree w/ the post, but JS is definitely making a big shift on the web.
BasDirks 16y ago
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.
drdaeman 16y ago
> For both of these roles, node.js is an ideal serving architecture. Two "pro" points, no comparsions, and it is declared "ideal"?
nathanwdavis 16y ago
> Its asynchronous, non-blocking architecture means it’s incredibly fast. 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.
- FooBarWidget 16y ago
  I've actually found evented servers to be slower than threaded servers in microbenchmarks. This is because evented servers have their own share of overhead: - an I/O multiplexor syscall must be called from time to time. Select/poll/kqueue/etc. These extra syscalls introduce overhead on top of the already required read/write calls. - the event loop has some overhead too. - the fact that read never blocks means that the kernel can't apply certain optimizations such as having the peer directly write to the receiver's read buffer instead of copying things though multiple buffers. That said, I think microbenchmarks like this are bullshit. The overhead is so small that you never notice a difference in production. The benefits of evented architectures are clear: you can handle a much larger concurrency level and you use less memory thanks to not having to reserve so many threading resources. However too many people seem to be ignorant about this and think microbenchmakrs mean something. All they care about is that 10000 req/sec > 8000 req/sec. I am actually looking into switching Phusion Passenger to an evented architecture, but I'm a little reluctant to do so because I fear people would microbenchmark it, see that it's slower and conclude that Passenger X sucks and is slower than Passenger X-1 or $COMPETITOR.
brs 16y ago
I read a similar article which was written five days earlier: http://www.richardrodger.com/2011/04/05/the-javascript-disruption/ http://www.richardrodger.com/2011/04/05/the-javascript-disru... 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.

119 points by hanifvirani 16y ago

I think the article is a little over-the-top but essentially right. 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. "use strict"; Cannot come fast enough.

mberning 16y ago
Agreed. To me the most hateful thing about using javascript is that I typically write it to be executed in a browser. It's an absolutely a terrible environment to develop, test, and debug in. Plugins make this better, but it is still problematic. Server side javascript is a decidedly better development experience.
- city41 16y ago
  > It's an absolutely a terrible environment to develop, test, and debug in. For large, essential apps I can see that. Although there are tools that make the experience much better. But man do I love what JavaScript and browsers have blossomed into. I've always wanted a really nice, simple environment where I can just write a small, self contained app with little overhead, little fuss, and wide ability for it to be adopted. JavaScript plus the new HTML5 goodies fulfills that wish far better than anything else in the past. I've grown to really fall in love with the little bastard language :)
- derleth 16y ago
  Server-side JS exposes the strengths of the language; in-browser JS exposes the weaknesses of browsers. How much difference a platform can make!
  - deleted 16y ago
    [deleted]
  - ggoodale 16y ago
    Very, very true. Client-side javascript suffers a debilitating flaw: it's largely used to manipulate the DOM, which is sadly still an ugly task despite over a decades' worth of effort. Provided you can sandbox that part of your code away from the rest, client-side javascript is every bit as palatable as the rest.
- wladimir 16y ago
  I find that with firebug, client-side javascript development is pretty comfortable. Most frustrating is debugging a script that works in Firefox, but doesn't work in IE. I haven't used JS server side so I don't have a comparison, though.
  - geuis 16y ago
    http://jsonlint.com http://jsonlint.com I find this immensely helpful when testing json data. There's something that happens in jQuery I ran into where $.get() on a relative json resource was being retrieved, but the callback function wasn't executing. The data was retrieved according to the network analyzer, and ajaxError() was firing, but that was it. Ran the json file through jsonlint and found some problems I needed to fix. Then it worked.
  - jerf 16y ago
    "Most frustrating is debugging a script that works in Firefox, but doesn't work in IE." Delete the trailing comma in your object literal.
    - wladimir 16y ago
      Yeah, those are pretty easy to find using JSlint.
      - beej71 16y ago
        Closure Compiler just errors out. "This won't run on IE, and you don't want it."
    - geekuskhan 16y ago
      I created an account just to say amen. I can't tell you how many times this has frustrated me in IE. Seems like I would learn.
- rplevy 16y ago
  I agree, JavaScript development can be maddening, even with (and because of!) helpful plug-ins like Firebug. Lispers spoiled by swank/slime in emacs may like https://github.com/ivan4th/swank-js https://github.com/ivan4th/swank-js as a JavaScript dev environment.
dougabug 16y ago
While I've said pretty much everything in the article to my friends and co-workers over the past several months... I'd still say at this point it qualitifes as FUD.

deleted 16y ago

[deleted]

Gorm-Casper 16y ago
Did so for me too at first. Kind of ironic actually :)
- joeraii 16y ago
  actually, we were serving the blog off of a tiny, poorly configured apache instance :)

hanifvirani 16y ago

Looks like we killed the poor guy's website. I mirrored the text here: https://gist.github.com/910648 https://gist.github.com/910648

vog 16y ago
Why do so many blogs fail to perform the most basic thing on the web? Why do they fail to deliver dead-simple, small, static content?
- shantanubala 16y ago
  Because most people don't expect a ton of traffic, and generating every page dynamically works until they're surprised to have hundreds of visitors in a short period of time.
  - vog 16y ago
    So programmers of Blog software think that lots of page visits are some kind of accident? I hope not! Also, handling lots of requests for small, static content is note exactly a tough problem. (Although it requires a minimum of care.) To any author who cares about what he writes (publishes), being read by many people is a great chance. However, crappy blog software deliberately destroys all those nice opportunities in advance.
    - shantanubala 16y ago
      Exactly my point. People don't realize the flaws in the blog software they use until they encounter a bunch of traffic.
- justincormack 16y ago
  Wordpress. The database backed era this post talks about didnt really use web architecture well, or good software architecture to perform. Aimed at ease of use instead. Mind you I am not convinced that event driven js is going to deliver high performance blogs either. Must move my blog off Wordpress before getting featured here...

eklovlfjkeos 16y ago

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. 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. Thirdly, I still prefer languages such as Python or PHP to JavaScript.

nevinera 16y ago
>Secondly, search engines don't play too well with the Ajaxy web apps. Search engines are for finding content, not for apps. If you have data in your app that a search engine could reasonably want to index, give it a resourceful route of some kind, and tell engines where to look - if that doesn't make sense, it's probably not a resource an engine would be interested in.
- eklovlfjkeos 16y ago
  > Search engines are for finding content, not for apps I agree, and one of the points that I forgot to write above is that the article seems to focus too much on apps. A lot of web development isn't about apps.
  - justincormack 16y ago
    The article is claiming that we are removing from resources (http, rest) to events, ie apps, for everything. I do think there is still space for the other style done well, with content, but a lot of people seem not to. One of the facets of the web/app war.
    - nevinera 16y ago
      If that's the case (and I don't think that's really what he said), it would be a foolish claim. Resources are fundamental to the human experience. On the web most things are just data, but if that data has value to anyone, it's a resource. Events are fundamental too, and I'm quite happy that the web seems to be evolving to handle them as well.. But resources will always exist, and any 'event' that has enough data for an engine to be interested in indexing it is carrying a resource.

deleted 16y ago

[deleted]

deleted 16y ago

[deleted]

cpeterso 16y ago

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.

asnyder 16y ago

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. 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 (http://www.noloh.com http://www.noloh.com). 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. 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. Disclaimer: I'm a co-founder of NOLOH [Edited: spelling and clarity]

phatbyte 16y ago

God dammit... we had the rails fanboys, most recently the django fanboys and we have....node.js fanboys...come on really ? 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. Besides, we all know what "drinking the cool aid" sometimes does don't we (I'm looking at you twitter).

mattmanser 16y ago

Ugh, this article is a load of nonsense. 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! So it's not going to be the next big thing. It's a play language and always will be. Unfortunately it's the only choice we have in the browser. If we had any other major language in the browser, even c++, it would have died long, long ago. We wouldn't even be talking about it today.

ivank 16y ago
Have you seen Closure Library and Closure Compiler? It's definitely feasible to write a million-LOC JavaScript application (Gmail is one). Your JavaScript doesn't have to be a mess.
- famousactress 16y ago
  To be fair.. Gmail is not one - http://googlesystem.blogspot.com/2010/06/gmail-to-use-more-html5-features.html http://googlesystem.blogspot.com/2010/06/gmail-to-use-more-h... Still... 440k+ isn't small.
  - abraham 16y ago
    While unlikely it is possible that Gmail has added 550k in the (almost) year since.
gmisra 16y ago
Might be interesting to think about why we don't have any other major languages in the browser? Javascript suffers from a lot of historical baggage and a lot of bad javascript on the web. One of the most helpful developments in the past few years has been the emergence of a "better" subset of js, led by Douglas Crockford's mafia, jslint, jshint, jsonlint etc. It's hard to argue that any language+platform has a more vibrant ecosystem right now than js+node.js
famousactress 16y ago

jimmyjazz14 16y ago

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 (http://news.ycombinator.com/item?id=1934021 http://news.ycombinator.com/item?id=1934021).

sayemm 16y ago

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 - https://github.com/languages https://github.com/languages

hassy 16y ago
That reason is likely to be jQuery included in every other project on Github.
- sayemm 16y ago
  That only proves the point. I don't fully agree w/ the post, but JS is definitely making a big shift on the web.

BasDirks 16y ago

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.

drdaeman 16y ago

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

nathanwdavis 16y ago

> Its asynchronous, non-blocking architecture means it’s incredibly fast. 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.

FooBarWidget 16y ago
I've actually found evented servers to be slower than threaded servers in microbenchmarks. This is because evented servers have their own share of overhead: - an I/O multiplexor syscall must be called from time to time. Select/poll/kqueue/etc. These extra syscalls introduce overhead on top of the already required read/write calls. - the event loop has some overhead too. - the fact that read never blocks means that the kernel can't apply certain optimizations such as having the peer directly write to the receiver's read buffer instead of copying things though multiple buffers. That said, I think microbenchmarks like this are bullshit. The overhead is so small that you never notice a difference in production. The benefits of evented architectures are clear: you can handle a much larger concurrency level and you use less memory thanks to not having to reserve so many threading resources. However too many people seem to be ignorant about this and think microbenchmakrs mean something. All they care about is that 10000 req/sec > 8000 req/sec. I am actually looking into switching Phusion Passenger to an evented architecture, but I'm a little reluctant to do so because I fear people would microbenchmark it, see that it's slower and conclude that Passenger X sucks and is slower than Passenger X-1 or $COMPETITOR.

brs 16y ago

I read a similar article which was written five days earlier: http://www.richardrodger.com/2011/04/05/the-javascript-disruption/ http://www.richardrodger.com/2011/04/05/the-javascript-disru... 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.