
The JavaScript Age - hanifvirani
http://metamarketsgroup.com/blog/node-js-and-the-javascript-age/
======
phatbyte
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).

------
asnyder
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]

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

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

~~~
jerf
"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
Yeah, those are pretty easy to find using JSlint.

~~~
beej71
Closure Compiler just errors out. "This won't run on IE, and you don't want
it."

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

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

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

~~~
vog
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
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
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
Exactly my point. People don't realize the flaws in the blog software they use
until they encounter a bunch of traffic.

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

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

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

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

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

------
brs
I read a similar article which was written five days earlier:
[http://www.richardrodger.com/2011/04/05/the-javascript-
disru...](http://www.richardrodger.com/2011/04/05/the-javascript-disruption/)

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.

------
sayemm
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
That reason is likely to be jQuery included in every other project on Github.

~~~
sayemm
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
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
> For both of these roles, node.js is an ideal serving architecture.

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

