The problem was the hype. It was hyped as a silver bullet, and we even have issues like people who have drunk too much Node Kool-Aid thinking that Node has the absolute best multithreading solution, and anything else that doesn't work exactly like Node is therefore worse, when Node in fact merely has a polished-but-old-school approach to the problem.
If people are upset that Node isn't a silver bullet, it's because the Node community never worried too much about making sure that people knew it wasn't one. It's why I've been saying that when I actually come onto HN here and try to puncture the hype, I'm actually doing Node a favor, by calibrating expectations closer to reality.
Node isn't useless, but the problems with the Node approach are well-understood since it's an approach the greater programming community has about 20 years of experience with, as are the potential workarounds, and even just how far the workarounds can be taken before you run into problems with the fact the underlying language is only so powerful. This sort of event-based approach just intrinsically scales poorly as program size increases, even with all the grease and goop you can muster up in a language that has closures.
You cannot build hype out of nothing. The reason Node saw the hype it did was because it attacked and reasonably solved real problems that people were having.
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).
Perhaps I did not clearly explain myself. It is no secret that you can write a async server in just about any language. Node's creator spent considerable time doing just that in C and Ruby before starting on Node, in fact.
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.
> 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.
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.
"You can’t shoot yourself in the foot in any way" is a pretty silly thing to say, but that seems to be an off-hand, casually made comment. None of this seems particularly egregious.
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.
I'm not impressed by this example. You could use the same words to describe nginx to some degree. "Do something that hasn't been done before" isn't a crazy amount of hype, in my opinion.
Event loops and asynchronous reactor patterns have been around since what, the late 70s? Node "callback soup" is isomorphic to the structured programming models of dataflows and transactional architectures. Event-reactor systems with asynchronous libraries have been present in almost every language I've ever encountered--hell, even Modula-2, a fucking ancient Pascal derivative, had coroutines which supported exactly this kind of interleaved or reacted control flow.
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 agree but I don't think event-based approach is poor as you're stating. Twisted or EventMachine use that approach and are pretty well known for that. It looks like it works wonderfully well in a couple of particular cases but Node as every new language got its couple of pioneers running to create the new "Rails/Django" in that language asap. This is in my humble opinion the issue there.
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.
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.
If you've spent any appreciable amount of time on Hacker News, you'd know that there has been pretty big hype behind Node.js. If you don't see it, you're not paying attention. Anecdotally, I work with a lot of fairly inexperienced developers with my clients, and I honestly can't tell you how many times they've suggested we "rewrite (x) in Node.js because it's faster" or "let's switch this to Redis" with no real reason behind it. When one digs down, we eventually arrive at "I read a blog post that said it was real fast and stuff."
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.
A lot of buzz about Node shouldn't be confused with a lot of "hype". If people are talking about something a lot and using it for very specific projects that's very different from people evangelizing it as a silver bullet solution for everything.
A lot of buzz can qualify has "hype" in my opinion. Node has gotten a lot of attention over the past year, just like Erlang got a few years before and Haskell in there too. The only difference people actually started using Node.
"When one digs down, we eventually arrive at "I read a blog post that said it was real fast and stuff.""
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.
If you've spent any appreciable amount of time on Hacker News, you'd know that there has been pretty big hype behind Node.js
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.
Sure, like I said, it solves some really hard problems and makes some architectures easier to execute on. But frankly, about 20-30% (probably made up percentage alert :)) of the stuff I people using Node.js for on HN is really just tech wankery. There's no real reason to be using Node.js for it, even though they will tell you that it's the only thing that worked for that possible problem!
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.
If you do not already think it has been hyped, I am at a loss as to how to prove it to you.
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.
Because it is inherently attractive to people who have worked client side in javascript and want to expand. Like me. I'm relatively new to the industry. I know javascript fairly well and while I might not be as familiar with the sort of problems that have to be solved on the server I am learning.
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.
I did not have much experience with frontend code and more or less had to learn JavaScript to use Node. I think one reason Node has become so popular is that it is relatively simple to understand (in part because JavaScript is), the documentation is excellent, and it works well. Twisted has similar goals, but it was harder for me to learn what was going on, even though I have prior Python experience.
I would definitely agree with you there. The documentation, as well as the number of tutorials and ebooks, is one of the big reasons for the so called 'hype.' I tried looking at twisted, I know enough python to be able to throw together some simple scripts and work with tools written in it I'm no pro though, and felt totally lost.
I don't think you've taken the time to ask how it might be different from even the other evented systems that have come before. When something that looks similar to what has come before seems to get undo attention, you should perhaps ask if you're missing something.
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.
All else isn't the same. For one, this event-based, single-threaded "asynchronous" execution environment running on a dynamic language uses javascript, which is a surprisingly powerful functional language that just happens to run on the other side of the web server conversation in the context that we are discussing.
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.
Calling JavaScript a functional language on the pure basis that it has first class functions and closures is sort of stupid. Aside from that, what other properties does JS enforce that are deemed functional?
The language uses functions as the primary mechanism for implementing core language design features, such as abstraction, modularity, code re-use, and configurable behavior. Lisp, Scala, and Haskell use functions as their go-to tool, supported by macros and/or types. JavaScript uses objects and its object system as its primary tool, with functions in a supporting role.
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.
You might add that Lisp (well Scheme and some Common Lisps), Scala, and Haskell provide mechanisms to make recursion equivalent to iteration without explicit looping constructs that require mutation (tail recursion).
My interest in having a boring argument with a language bigot approaches nil. But yes, aside from the very namesake of functional programming (a vague language grouping with no disciplined definition), yeah there's nothing else there...groan.
> The problem was the hype. It was hyped as a silver bullet, and we even have issues like people who have drunk too much Node Kool-Aid thinking that Node has the absolute best multithreading solution, and anything else that doesn't work exactly like Node is therefore worse, when Node in fact merely has a polished-but-old-school approach to the problem.
If people are upset that Node isn't a silver bullet, it's because the Node community never worried too much about making sure that people knew it wasn't one. It's why I've been saying that when I actually come onto HN here and try to puncture the hype, I'm actually doing Node a favor, by calibrating expectations closer to reality.
Node isn't useless, but the problems with the Node approach are well-understood since it's an approach the greater programming community has about 20 years of experience with, as are the potential workarounds, and even just how far the workarounds can be taken before you run into problems with the fact the underlying language is only so powerful. This sort of event-based approach just intrinsically scales poorly as program size increases, even with all the grease and goop you can muster up in a language that has closures.