The JavaScript Age

http://metamarketsgroup.com/blog/node-js-and-the-javascript-age/

by hanifvirani • 15 years ago

119 48 15 years 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• 15 years 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.

derleth• 15 years 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!

wladimir2• 15 years 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.

city412• 15 years 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 :)

rplevy• 15 years 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 as a JavaScript dev environment.

dougabug• 15 years 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.

hanifvirani• 15 years ago

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

vog2• 15 years 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?

shantanubala2• 15 years 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.

justincormack2• 15 years 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...

eklovlfjkeos2• 15 years 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.

nevinera2• 15 years 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.

eklovlfjkeos2• 15 years 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.

cpeterso• 15 years 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• 15 years 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). 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• 15 years 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).

mattmanser2• 15 years 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• 15 years 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.

famousactress2• 15 years ago

To be fair.. Gmail is not one - http://googlesystem.blogspot.com/2010/06/gmail-to-use-more-h...

Still... 440k+ isn't small.

gmisra• 15 years 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

famousactress2• 15 years ago

Respectfully, IMHO this comment is a load of nonsense. Is your opinion informed by experience?

Dismissing javascript as a 'play language' is to ignore, well, the internet. Sure, it's imperfect.. maybe more than most languages. But it's also wildly powerful, and there are plenty of ways to make large js codebases quite reasonable (ours is, and we build one of the most complex javascript front ends I'm aware of).

Suggesting that C++ would be a better language for writing web UIs really seems especially ridiculous to me. Have you written GUIs in C++? I have, and I assure you they're no nicer to maintain than javascript ones. In fact both languages require a similar amount of discipline and order to grow maintainable codebases with. The same is true for pretty much everything.. and when it comes down to it.. front-end code of any format can be very hard to keep manageable.

Javascript with tools like google's closure kit is about as reasonable as anything else I've built a front end with.

mattmanser2• 15 years ago

To be honest no-one's ever going to read this as it's 23 hours late, but this is my reply.

Yes, it is informed with experience.

My point is that if javascript were not the only language available in the browser it would have died years ago. Citing the example of the internet is like flogging a straw man. The only reason it's on the internet is that there's NO other language competing with it, apart from vbscript long, long ago which only worked in IE when Netscape Navigator was still around so won by default.

So your point was? Cause I really, really don't get your thing about Dismissing javascript as a 'play language' is to ignore, well, the internet. I already explained that one quite clearly. It's the only player in that space and the only reason why anyone even bothers with it.

The C++ was a semi-joke, but you've got to read it in the context of the article and javascript winning big server side. It's never going to happen. The article is totally fubar.

Javascript is one file. Everyone writes it like that in a single closure to make sure it never interferes with anyone else's namespace. Because of the total joke of variable scope. It's a nightmare when it comes to maintainability.

That's my point. It's not portable, it's not at all transferable. It's not at all appropriate server-side for anything apart from play sites.

I'm sure you've done great things with javascript client side but it's never going to be a great language server side because it's just not maintainable.

Generally speaking against javascript as well, it's a total pita when it comes to reading someone else's code anyway. You can't pick up someone else's code and know what's a constructor, what's static, what's a singleton, what's the actual entry point for the whole thing. There are still competing patterns for just writing a god-damn object constructor (Resig style vs Yahoo style, even though Resig's is clearly superior). And even then it's scattered about like crazy. There's absolutely no logical structure to it.

Anyway, talking to myself now. Signing off...

joubert• 15 years ago

I develop in SproutCore at our startup and find that you can scale a code base to large swathes of functionality and elegant composibility, something enabled by the flexibility of ECMAScript.

leon_• 15 years ago

> 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.

This. JS' success is because of lack of alternatives. It's astonishing that some people actually advocate JS.

city412• 15 years ago

Do you have much experience with JavaScript? My current focus is to learn JS very well, for no other reason at first than how prevalent it has become. I was surprised to find it's actually a pretty enjoyable and expressive language.

tomjen3• 15 years ago

While I would love something that is not javascript, I have to disagree with the assesment that it is too hard to write a big app in.

That would be true if you write it as one would write a C++ program, or even to the sizes one would write C++ programs in.

If you structure your program as a set of responses to events (the user clicked this button, this field lost focus, post/get resquest to this url) you automatically split the program up in many smaller pieces.

In addition a program that would be a million lines of C++ might very well be a lot less in Javascript, since C++ lacks a lot of the features which Javascript has (first class fuctions being one of them).

troels• 15 years ago

""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.""

To say something like that, you must clearly not understand the premise of the language.

Javascript is not a play language - it's a very powerful hybrid of Scheme and Self, with a C-like syntax, which makes it easier for most people to get started with. Using functional programming paradigms, rather than class based ones, makes Javascript scale very well to large applications.

jimmyjazz14• 15 years 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).

sayemm2• 15 years 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

hassy• 15 years ago

That reason is likely to be jQuery included in every other project on Github.

sayemm2• 15 years 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• 15 years 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• 15 years ago

> For both of these roles, node.js is an ideal serving architecture.

Two "pro" points, no comparsions, and it is declared "ideal"?

nathanwdavis• 15 years 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• 15 years 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• 15 years ago

I read a similar article which was written five days earlier: 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.

The JavaScript Age

Related Stories