Node.js isn't a silver bullet, but it's still a bullet.
crgwbr.com
crgwbr.com
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.
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.
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.
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.
Don't throw node and redis in the same bucket please.
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"!
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.
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.
functional: adj, produces a correct result
example usage: Despite its many warts, inadequacies,
somehow JavaScript is actually functional.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.
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.
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.
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.
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.
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.
Sources
The real argument here seems to be that people are tired of "node hipsters" and "hype".
Get over it.
What's the point in wasting time being angry about what other developers are thinking or doing? If they're wrong, they'll figure it out eventually.
It's the online equivalent of bitching about everyone that wears skinny jeans and shemagh scarves.
Then, just to set things straight, people have to come along and write reasonable posts (like this one) in response.
Keep the anger to yourself, so the rest of us can get on with it and use whatever tools are right for our job.
You try to use Node as a production solution and it(or you) fell short somewhere? Great, you just learned something and are a better programmer because of it.
It's naive, but I always felt the annoyance comes from the fact that people like a meritocracy and hype being such a large part is irritating. Luck you can deal with, you know its isn't going away. It's harder to internalize that the hype aspect is natural human behavior and it isn't going away either.
What I don't get is people who take that fact and decide it's not worth trying to do things better.
As long as things stay out of the snake oil zone I think it's ok. And that applies to NoSQL, "cloud" computing, mobile apps, etc.
The article argues that node's sweet-spot is: "to enable real-time propagation of events and state-changes between clients. You could do the same thing with long-polling ajax or even frequent polling, but those both come with the cost of tying up unnecessary worker threads on the server and dealing with extra requests."
yes we all know that, that is why no one is suggesting that. the better comparison would be to put it up against twisted or event machine, which also use an event loop to do non-blocking IO. but you dont have to deal with callback hell, and even as a javascripter myself, I would say that I would rather code in python or ruby.
you dont have to use node to do real time, web sockets, etc.
Twisted's website, on the other hand, fills the front page to use verbose, boilerplate-heavy code examples. They mention an "event-driven web server" but don't say why I'd want that. If I'm still interested and click through to their example's I see stuff like "pbsimple.py - simplest possible PB server" or "ampserver.py - do math using AMP". Thrilling.
It's quite a solid framework - with possibly the worst marketing in software history.
For the client-server communication, by default backbone.sync on the client uses restful cruddy urls (for rails), which would need to be handled in a node.js router. There's a lot of boilerplate-type stuff out there to help handle routing those urls, building on e.g. express.js. It seems to be more straightforward on rails which already established conventions.
That's probably why a lot of the backbone/node demos and tutorials forego the restful server interface. Its simpler to just do client-server communication using a real-time pipe like socket.io (which itself is shared code on the server the client). not restful but comes with an added wow factor.
Node is great for building services. Not so much for software that consumes those services.
The majority of software like a CMS is not self-sufficient. It needs a database, a filesystem, it talks to the http server, it might talk to a dozen other services (generate thumbnails, upload some files to a CDN, scan for viruses in an upload, etc. etc.). You get the idea.
Each external dependency is a blocking dependency. You need to handle it and it isn't easy. Node provides you the tools, but unlike in our first example, where the only thing that blocks is the filesystem, here you have dozens of services that block, with hundreds of pain points. Writing code becomes a chore that is very unpleasant.
That's not the worst of it.
If you miss a blocking operation and don't handle it properly in node, which is very easy, your entire server will go down. In a thread-based or multi-process server-side language mistakes are painful, but not fatal. In node, missing a blocking operation is fatal.
The node guys get this. That's why they're busy trying to cook up a solution around this problem. But they don't talk about it or advertise it.
As of right now, node is definitely not a general purpose solution. It is, however, an excellent solution where you don't have a lot of dependencies that block.
I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. Do you have some inside information? :) I do agree that it is a solvable problem, however.
A blocking operation is essentially anything that takes a while to complete. It blocks everything, because node is focused on doing that one thing. Usually this happens with external services, where node requests something and then waits for a response. Those are easy to spot. But you can write code in any language that takes a while to do something. And it's very easy to do so and miss your mistake =)
> I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it.
I don't mean it's a secret or something. They talk about it on Google Groups and in change logs. I'm saying that's something that should be on their front page of their website explaining things. Maybe have a nice little chart of dos and don'ts.
As soon as you code an endless loop in a function it blocks the server forever. Do a long calculation: it blocks for the time running. Node is no magic dust which turns everything it touches into asynch high speed code.
Node is asynch only when it comes to operations that are external to your code. (network, file system) . One could even argue that CPU intensive code being external to node but running on the same server could block if it's not running on a different CPU altogether.
The alternatives are to run everything in its own process, which uses too much RAM or to use threads, which are very difficult to reason about. (Did you really acquire locks in an order that guarantees you will never deadlock? Is your date formatting library threadsafe?) Finally, there is threads and STM, but STM adds overhead and retrying transactions wastes resources.
None of those solutions are very good, and node is in the same place: it is another not very good solution to concurrency. Right now, nobody in the world can come up with anything better. To do concurrency right, you have to be very careful, and those caveats apply to all the other concurrency mechanisms. node's event model is basically equivalent to the other mechanisms; fatal if done wrong. Doing one thing in one place makes the process model work. Not having any state shared between application operations makes threads work. Event-driven systems are a compromise between the two: you can share state between logical threads of execution, but the order in which state updates occur is deterministic.
Every model has its strengths and weaknesses, and node has strengths and weaknesses.
Common Node (https://github.com/olegp/common-node/) gives you the best of both worlds: it's easy to develop in & debug just like Ringo yet has low memory usage and is easy to integrate with existing Node libraries.
Here's a very simple CMS I wrote in it: https://github.com/olegp/mcms
Here's a canonical blog example that also shows the use of the synchronous Mongo driver: https://github.com/olegp/notes
Cheating! It's not in core. Yes, it largely solves the problem at hand, but we're not talking about node + fibers or even the node + features they're currently working on. We're talking about node. Node doesn't have fibers. Although I wish it did! Fibers really don't belong in the user-space ...
Also, even if one opposes the idea of co-routines due to the problem of not knowing which function will yield, there's no denying that they provide one of the best current solutions to the flow control issues with a clean upgrade path to generators when those become available in V8 in 18 months or so.
My latest project runs Python/Pyramid and MongoDB for the more traditional computational stuff. We have a notification architecture running through node.js/socket.io sending real-time events down to the browser.
It works beautifully.
All of that COULD have been implemented within the Pyramid layer (or Twisted..or whatever), but it would have been much more difficult and time-consuming to do.
I could have done it in PHP, but it would have been an absolute nightmare.
As for your second point, client side programming (GUI in general) is very event driven so a lot of people coming to node because they have javascript experience have event driven programming experience. And as far as I know (I may just be ignorant of it, and would love to know if I am wrong) there is no go-to text on event driven frameworks, nor has there been anything as popular as node that has been so focused on events besides tcl/tk which there isn't really a wealth of readily accessible knowledge about.
Again, I could be totally wrong, but unless you can point towards where someone working with node can learn these lessons I am gonna go on ahead thinking that node and it's community are doing well. There is after all a wealth of community driven documentation and tutorials being assembled already. I would hazard a guess that the amount of information available to someone new to node is more robust than many older frameworks/languages/programming technologies in general.
I don't know what books would be best to learn event driven programming. That would be a good question to have an answer to. My point in suggesting a book is that it's the concepts here that matter, not that you are using a Javascript, Python, Ruby, or C# implementation, or a language built around the idea like Erlang. Once you know the concepts, you can quickly and easily pick up or even build a framework in any language.
I don't think anyone is suggesting that Node and the community isn't doing well. It's just that many of us are quite confused by the massive hype around it. Javascript might be a fine choice in some situations, but in general, on the server side you have many different languages to choose from and many (most?) of them also have competent event driven frameworks available. It would surprise me if most development shops didn't have server side developers who work daily with a language other than Javascript.
I agree its the concepts that matter, it is just that whenever I hear this argument no one (who is making it) can actually point out exactly what those concepts are or even point to any reason why another event driven framework would be better (besides the obvious I already know the language gambit which applies to node equally, if not more). Many people cant even point out the obvious frameworks that do similar stuff, with maybe twisted being the exception.
I would be incredibly surprised if even a handful of dev shops have server side devs who only work in node. But I don't really see what that has to do with anything.
I get that this is mostly about the 'hype,' but if Node and the community are doing well, have good documentation and we are seeing the technology used to implement some cool stuff (trello for example) then how is the hype confusing? That is the thing that I don't get. Node is now a cross-platform environment that fits easily into PaaS and SaaS concepts, is gaining hosting options by the day (heroku, azure, etc) has a huge library of third party modules, and the majority of people using it seem to understand what it is and is not. It seems obvious to me that any new technology, or new implementation of a technology if that makes you feel better about the terminology, that has all those things going for will generate a certain amount of hype.
Silver's way more expensive than lead and offers little or no improvement unless you're shooting at werewolves.
A while back, I had an application which needed to do some fairly complicated string manipulation, both on the client side and the server side, and by using Node, I was able to write and debug that code once. There are good use cases here.
I could be wrong, I have no reference or even a memory of learning this so I have either forgotten or I just made this up.
This happens with every popular new tech that does things differently from how its been done before. Since I've been developing I've seen it happen with
PHP
Rails
mongodb
now node.js
As long as there is a critical mass of developers that want to use a certain technology, there is nothing that anyone can do to stop it. They'll keep making it better and better until the naysayers have little or nothing they can criticize, and then it won't matter because everyone will be using it anyway.
Its great to see people stepping out to tamp down the hype though, that's the necessary next step in the evolution of any new tech.
In fact, I would say that node has simply passed the "Peak of Inflated Expectations" and is/has-been descending into the "Trough of Disillusionment".
This is because your list is missing Java. During the mid to late 90s Java was Jesus. It was the solution to every possible computing problem imaginable. The amount of hype surrounding Java puts anything we've seen since to shame, even NoSQL, "cloud" computing, social networking, etc. It was infuriating. And it took a few years of everyone and their mother banging away at Java development before people realized that it wasn't the Messiah, it was just a technology with a few advantages as well as some disadvantages, and that it was a good idea to only use it sometimes and keep using other languages when appropriate.
Remember that JavaScript has absolutely nothing to do with Java except the name was changed and some of the syntax was changed to make it more closely resemble Java merely out of a crass marketing attempt on Netscape's part.
This phrase actually captures, succinctly, a big reason for Node's success: If you decide not to use a JavaScript-based tool you have to decide what to use instead. The ensuing debate will often take three times longer than just using Node.
Everyone who touches the web needs to know JavaScript, so apart from any other consideration there's an automatic tendency to try the thing that's written in JavaScript before trying anything else.
But there will be backlash if too many of those novice supporters go overboard in their enthusiasm without any experience to put it in context.
Maybe it's a sign that the hipsters are rising as the neckbeads retire.
Geeks love to debate technical stuffs.
Node.js is nothing different, it has its pros and cons. You simply cannot tag it as 'good' or 'bad'. You are smart if you use it where it suits you. You are silly if you just try to trash it.