What you seem to be pointing out here is that there are still unsolved problems out there. Problems where Node tried and failed to deliver. We used to write web applications completely in C, and that was shown to not work either. It doesn't mean those people were wrong to try using C. It just was proven, by actually trying it, that it is not the right tool for the job.

It's not really a shortcoming of Node or its hype, it's simply the process we use to eventually find what does work. If you don't try, you'll never know.

Yes you can. There was no hype around asyn java libs (netty , grizzly, mina), however the chance of java folks having these problems is way higher than for javascript front end devs (the main audience of node).

However, creating a working solution does not free you of problems. Being bound to an obtuse language or API, for instance, is still a problem. One that will continue to haunt you for as long as the application lives.

Java Struts was, once upon a time, the framework of choice for web development. While it solved some problems, it created a whole new set of its own. A little known character, DHH, laughed at it and set out to build something better. While Java can produce a web application as well as any other, Rails became a big hype machine because it solved problems people had on the implementation side.

I recall EventMachine had a little bit of hype before Node came along, but it didn't solve the problem very well. Few supporting libraries supported asynchronous operation and the language just didn't feel right. I imagine your Java libraries suffer the same problem, and that is why they never saw much hype either.

Javascript, on the other hand, was designed to be asynchronous from the beginning. It had the perfect expressiveness for the job, and the libraries were all built to work in the environment. That is what made Node interesting, and why the hype followed. It solved peoples problems.

This is a bit of an overstatement, as we've seen since node became popular JS really doesn't have the appropriate amount of expressiveness. There are so many libraries that try to remove callback-hell from JS code (Step, node-fibers) but they all have their little issues and quirks because you just can't solve the problem well in JS. Now TameJS and IcedCoffeeScript are trying to attack the problem by implementing the solutions outside JS and compiling to it.

PS. Could you point out a few egregious examples of the node community overhyping Node.js?

https://twitter.com/#!/ryah/status/8519974729

Also, I regularly see people making claims like "You can’t shoot yourself in the foot in any way" (http://venturebeat.com/2012/01/24/node-at-google-mozilla-yah...) and other variations involving issues around performance and concurrency.

I think it stems from some very smart people talking about why Node is better, then others trying to articulate the same thing without completely understanding what they're saying.

I'm looking for examples such as people actively promulgating Node adoption with ridiculous claims, people advising folks to use Node for specific tasks where it's completely unsuitable, people selling Node based technologies that aren't that good, people making the claim that Node is a silver bullet very publicly to a large audience, etc.

You could have used any other language, for literally decades prior to Node's existence, to build the same things. Even if you didn't want to build a totally evented system, judicious use of select/epoll allows you to reap the benefits of asynchronous I/O without locking your whole application into the event loop.

Node.js programmers are building concurrent applications on a platform without coroutines, without fork/join, without threads, indeed without any parallelism, without scheduler priorities, hell without integers--and claiming it's a new paradigm in computing.

I consider that a joke.

Another issue is that Node is actually using Javascript, meaning it get a broader community than any new general language. But this community isn't by definition well familiarized with threading or async situations. These developers can easily slide into the "silver bullet thing".

Explaining the core notions behind event-based solutions and threading ones to a "nodejs hipster" usually allow him to understand the right uses cases for it, at least from my experience.

http://news.ycombinator.com/item?id=3292806

There is a certain class of problem that often appears on the web presentation layer -- the interaction between the browser and a cornucopia of back-end sources and systems -- where nodejs is often a very good fit, and it is almost always what enthusiasts of the platform are speaking of.

That's it. Nothing more.

I've seen various angry retorts that opine that become it isn't suitable for various very unsuitable purposes (see - calculating prime numbers, etc), it sucks. Such misdirection has no place in this industry.

I like Node a lot. I think it solves some hard problems, but just like NoSQL, TDD, and a bevy of other things, they're not silver bullets even if they're painted like one.

That doesn't show that there was too much hype. That just shows there is enough popularity for an inexperienced developer to find it on their radar.

If it was overly hyped, you'd find a lot of experienced developers blogging about how they were horribly mislead and that node doesn't do what it advertises.

The FB engineer in his interview (http://news.ycombinator.com/item?id=3527419) says it just about right that "Technology is a great servant but a terrible master"!

Don't throw node and redis in the same bucket please.

A considerable percentage of HN's visitors deal in exactly the realm that node.js serves: that gooey layer between browser and back-end systems. This is like complaining that coffee enthusiasts are interested in burr grinders when it's entirely unsuitable for chipping tree branches. There is no surprise that many HNers find node.js interesting and exciting.

Likewise, another 10-20% is people converting working code from a perfectly suitable technology to Node.js because it's the new cool thing.

It's not that either of these cases is "wrong." They know their problems better than I do. But I've been doing web development for about 10 years, I've seen this cycle a few times, and I know that every new tech has ridiculous adherents that do that stuff (e.g., Rails went through the same cycle except for "productivity reasons"). Everything looks like an old and busted nail when you have a new and shiny hammer I guess.

Let me put it this way: Why do we hear so much about Node when it's just another event-based single-threaded "asynchronous" execution environment running on a dynamic language, like half-a-dozen others that preceded it? Basically, it won the hype lottery. Whatever nice things you may have to say about it apply reasonably well to the half-dozen predecessors, too.

I think a lot of the criticism about people getting into it thinking that they can just port their client side experience to the server is valid. But the tone of so many seemingly anti-node posts turns a lot people off. I read more critical posts about node than I do positive ones because I know I will learn more. But sometimes it is not easy to cut through all the ego thumping and noob bashing. It would be nice to see the tone of the discussion shift, which I think it is starting to do, to what node is actually good at (in my opinion it seems to be acting as a glue for applications that require real-time).

Regardless, it works. I've started using Trello and I love it. Best organizational app I have used. Built in node. It works and I have not had a single problem with after two weeks of pretty heavy use.

So I don't think it just won the hype lottery, it has distinct advantages over Twisted and EventMachine, even if many of those advantages just have to do with relative accessibility and the ease of access provided by NPM.

It has hype because it has an involved and open community. Not just because it was lucky.

All languages, platforms, frameworks etc have strengths and weaknesses. There are lots of factors that contribute to a certain solution being "really good" for a problem as opposed to "serviceable but not great". Engineers look for great solutions to problems. They don't stick with ones that are sub-par just to avoid explaining to nay-sayers why they decided to switch.

Being able to standardize and coalesce the two sides of the web pipeline -- regardless of what magic happened at the other layers -- has obvious merits.

I'll save you some time: none.

I will concede that JavaScript supports programming in a functional style. However, if one uses that as the definition of a functional language, the term becomes nearly useless, basically excluding only Java.

    functional: adj, produces a correct result
      example usage: Despite its many warts, inadequacies,
        somehow JavaScript is actually functional.

Sources