Node.js isn't a silver bullet, but it's still a bullet.(crgwbr.com)
crgwbr.com
Node.js isn't a silver bullet, but it's still a bullet.
http://crgwbr.com/details/41/nodejs-isnt-a-silver-bullet-but-still-a-bullet/
109 comments
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.
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.
"You cannot build hype out of nothing. "
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).
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.
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.
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.
The "cloud" has been overhyped up the wazoo for years. That doesn't make PaaS meaningless or less useful.
PS. Could you point out a few egregious examples of the node community overhyping Node.js?
PS. Could you point out a few egregious examples of the node community overhyping Node.js?
Well, to quote Ryan Dahl: "i wish for less #nodejs hype."
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.
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.
"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 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 consider that a joke.
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.
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.
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.
IMO, this humorous comment on HN sums it up best.
http://news.ycombinator.com/item?id=3292806
http://news.ycombinator.com/item?id=3292806
What hype? Whose hype? I think it's a strawman.
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.
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.
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.
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.
And then you get blogposts like this: http://teddziuba.com/2011/10/node-js-is-cancer.html
Which amounts to "I don't like javascript, I don't like things that don't work the way I like to work, and I love strawmen."
I endorse your view. Its puzzling to see how in a very silly manner, so many people just want to be "fashionable" when it comes to use of tech.
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"!
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"!
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.
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.
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.
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 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 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.
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?
I'll save you some time: none.
I'll save you some time: none.
I don't generally like to say sort of stupid things, but I would call a language functional if it has first class functions and closures.
Provide a concise, objective definition for functional languages which Lisp, Scala, Haskell, and Lua satisfy but Javascript does not.
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.
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.
You are correct in saying that functional programming has a vague meaning. For JavaScript, I'll accept the meaning:
functional: adj, produces a correct result
example usage: Despite its many warts, inadequacies,
somehow JavaScript is actually functional.There is lots of enthusiasts who post hyperbole like
https://twitter.com/travisglines/status/163735891964203008
> 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.
Sources
Sources
So far, everyone seems to agree that every project has unique problems and solutions, and that node.js has a place.
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.
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.
Plus all the hype just makes programming better. More eyes, more research, more usage, more knowledge, more code-as-art projects. I don't use node, but I'm envious of the people who have all that time to play around with it. Is it the best solution for any problem? That's up to no one but your own expert opinion. It really doesn't matter. What matters is people are programming and they're having fun doing it.
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.
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.
I partly agree, but surely the annoyance at things like this is because those eyes and research could have been on better potential projects that didn't get the hype.
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.
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.
To be honest, in the case of node.js I don't think there's an overabundance of hype. There is some hype, to be sure, but mostly there's just a lot of buzz from people who are using node and enjoying it.
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.
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.
Just wanted to point out the apples to oranges comparison being made:
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.
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.
Node.js has much better marketing. From the outset Node made a big deal of its event driven architecture and why I should want to use it.
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.
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.
I haven't used twisted in ages, but I have to second that.
It's quite a solid framework - with possibly the worst marketing in software history.
It's quite a solid framework - with possibly the worst marketing in software history.
There's other reasons to like node besides the non-blocking IO. For me, its being able to reuse code on the client and the server. Not sure why the node bashers seem to overlook that one.
Serious question: What might you want to reuse on the client side?
The model. For example, including a backbone.js collection/model definition in the server-side node environment and serving the same model code to the client. The controller-y stuff will be different on each: on the node server the model is persisted by overwriting backbone.sync backbone-redis, and the client could choose to do local caching by extending the sync function with a localstorage plug-in.
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.
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.
The problem with Node.js is that it's very good at it's original purpose and terrible at everything else. Node.js is excellent for building network services. It is terrible at general server-side computing. If you need a server that consumes websocket connections, it's great. If you need to build a CLI script that installs and upgrades various software packages, not so much. If you need a chat server, it's great. If you need to build a CMS, not so much.
Node is great for building services. Not so much for software that consumes those services.
Node is great for building services. Not so much for software that consumes those services.
I've found the traditional synchronous approach I am familiar with from Ringo (http://ringojs.org) a better fit for general purpose server side work, so I've made it possible on Node with the help of node-fibers.
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
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
> I've made it possible on Node with the help of node-fibers
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 ...
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 ...
They work in user-space and are portable, so I don't see the problem.
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.
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.
I'm not sure why it is bad for building a CMS. Admittedly, node isn't all that mature so doing so might be a little lower level right now than doing the same with, say, Rails. But it has one huge advantage which is that any modern CMS is going to have a good chunk of client side code, and there are immense advantages to having the same language on the client and server.
The majority of services out there are self-sufficient. Take a very simple http server. It needs to talk to the local filesystem and serve the content requested. The only thing in that equation that might block is the filesystem. Node provides you the tools to deal with that and more. Building an http server in node is enjoyable, easy, and the end result performs well.
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.
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 disagree with this. Handling one blocking operation is as easy as handling n blocking operations. Yes, you have to handle them, or they will block.
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.
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.
That makes sense, mostly, but I'm a bit confused as to what you mean by saying it is easy to "miss" a blocking operation such that it will take down your server. It seems pretty hard to have any operation be blocking in node. To my knowledge everything I can do in node is asynch (with exception of a few blocking file functions, but I don't use those as there are asynch versions which are recommended anyway)
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.
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.
> It seems pretty hard to have any operation be blocking in node.
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.
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.
> It seems pretty hard to have any operation be blocking in node ... To my knowledge everything I can do in node is asynch
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.
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.
If you integrate to an external native library it might block.
Yep...and if you use it for that it's brilliant.
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.
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'm doing something similar, only with PHP + MySQL for the more traditional stuff. Node.js runs a websocket server + http + fastcgi. Browsers connect as clients. PHP connects as a client too when it needs to. Node.js facilitates the back and forth.
I could have done it in PHP, but it would have been an absolute nightmare.
I could have done it in PHP, but it would have been an absolute nightmare.
You can run pyramid through gevent wsgi and use gevent-websockets to get the same functionality. Highly performant, no callback soup, and all one stack.
Thanks dude, that's probably the best introduction to Node, I would put it to Node's front page ,really.
bullshit
Using node.js for server side programming is a new trend which is common around people who only know Javascript, and choose node.js because it's a language they know. This is a HUGE problem, because even though node.js has a huge community, it seems they do not learn from the mistakes of older and more experienced languages. They just try to re-invent everything, which results in crappy systems.
Isn't that just part of the process of exploring the new technology though? Sure a lot of that will fail, but people will learn from what works and what doesn't. I think it is less of a problem that people who know javascript are choosing node because they know js (like myself), and more of a problem that there are so many posts complaining about people wanting to expand their horizons instead of trying to actually educate those people.
I guess the take home here is that Node.j is not new technology. It is old technology reimplemented in a new language. In that sense, rather than fumble through the same mistakes and rediscover the same limitations others have, why not read a book on event driven programming instead?
That is sort of like saying a smart phone is not new technology. In a sense it is not. It is the combination of two already existing technologies, but isn't that pretty much what all new technologies are? On top of that it is a new language and each language is going to be better or worse at doing certain tasks. It is also frequently more beneficial to actually learn something for yourself.
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.
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.
No, there are sometimes genuinely new technologies: ideas or frameworks that have not been previously explored. Google's PageRank algorithm is a good example. It's not often that you see genuinely new ideas in programming languages, although it does happen occasionally. Javascript as a language doesn't push any boundaries, although it's an alright language overall.
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 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.
Most technologies are made up components of older technologies or ideas, I am not saying that you cannot do something genuinely new. But I am also sure that if you talk to the guys who built pagerank they probably had some inspirations and stuff they took ideas from. It is all perspective.
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.
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.
To extend the metaphor, Node is a silver bullet.
Silver's way more expensive than lead and offers little or no improvement unless you're shooting at werewolves.
Silver's way more expensive than lead and offers little or no improvement unless you're shooting at werewolves.
But when you are shooting at werewolves, silver bullets are definitely the thing to use.
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.
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.
Exactly! I'm frankly not sure how “silver bullet” came to mean a general solution…
I always thought that it was because in the metaphor the "werewolf" was "programming is hard". There is no silver bullet to kill the "I have to make trade-offs as this gets more complex!" monster.
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.
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.
First they ignore you, then they laugh at you, then they fight you, then you win
--- Gandhi
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.
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.
I'm going to make a guess at your age based on this list, I predict you are less than 30 years old.
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 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.
I think the hype cycle[1] is more apt than the Gandhi quote in several of the cases you mentioned.
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".
[1]: https://en.wikipedia.org/wiki/Hype_cycle
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".
[1]: https://en.wikipedia.org/wiki/Hype_cycle
I agree with you completely. I thing it so important to remember both the value of criticism and that the technology is still growing and adapting.
Node (or the people hyping it) suffers the expertise projection symptom. When people seeing Node is great for doing one thing (async network handling), they automatically project it to be great for other stuffs. That's where the hype falls apart.
Node was the best choice for our service, I'm willing to go to court with this. We need a fast fire and forget server to talk with Redis continuously, what's a better option? Erlang? I think there are ~3.6 developers in Israel that know Erlang.
Tornado.
And you just need a Python programmer and 1 day of work.
Sinatra?
Why? we have two routes (twitter-connect, facebook-connect), socket.io and redis pub/sub. that's it.
For no reason other than it would be a fine alternative. I'm sure your Node solution is performant and simple, and you should stick with that but no doubt a simple server written in ruby or haskell or python or anything really would get the same job done.
ruby or Haskell or python or anything really
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.
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.
I considered EventMachine and Twisted and decided to go with Node. 90% of the requests to the server will be "take this and push it to redis". Another factor in the decision was the other programmer on the project doesn't know Ruby or Python. Another factor was that I'm young, not constrained, and I want to learn everything I can get my hands on.
Sure, that all sounds great. I'm not trying to say you made a bad decision. You're original comment, though, came off as overly forceful, and a mild-bit condescending to the erlang community for no apparent reason and I decided to put my 2 cents in about it. There's no reason why your exact service couldn't be written in another language other than pure personal preference. And thats fine but you need to loosen up a bit about it.
I have more bad things to say about Node :) There are just not enough Erlang hackers around here to consider it, same for Haskell. Even Ruby isn't wildly used around here.
[deleted]
Languages are tools. Good carpenters use the right tool for the right job. Can you use sand paper to sand a door down to fit the space? Sure...but there is a reason the plane was invented.
But what if Node isn't the right tool for any job? What if everything Node does well has already been done even better and years earlier by Erlang?
That's clearly not the case. Sure, other event-based web frameworks exist, but Node definitely makes it easier than ever to write event-based apps. Additionally, being able to share code between the server and client is a very interesting and useful feature. Finally, Javascript is unlike really any other language in existence. It has many of the benefits of a functional language, without being nearly as intimidating as something like Haskell. Node certainly has its place.
Ease of novice development is definitely a worthy goal and a valuable niche to carve out (like PHP).
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.
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.
This statement without any kind of explanation, is totally meaningless. Please explain.
[deleted]
I like the smartness of today's blogger: write something that attack another popular internet rant. You'll get instant pageviews.
It's been going on since at least news papers. Go to the grocery-store and take a look at the magazines in the checkout isle. Humans love to watch unfold what they think is a controversy. It's entertainment.
[deleted]
People love new things and the story of the new guy overtaking the evil status quo. Node and JS in general seems very hyped right now. Every day there is a new blog about accomplishing something in these technologies that was entirely possible with alternatives for the last many years. But its new and exciting and blogged about. Because it is so new, there are not really any accounts of what a Node architecture does to your maintenance, refactoring, upkeep on a 5 year old application that no one cares about anymore (and the team that built it left).
Maybe it's a sign that the hipsters are rising as the neckbeads retire.
Maybe it's a sign that the hipsters are rising as the neckbeads retire.
Good article. I never get why people of one language bash another language. No language is perfect for every task. Use what is good for you and works. Don't bash others because you don't use it.
That's what geeks do. Seriously.
Geeks love to debate technical stuffs.
Geeks love to debate technical stuffs.
You start getting into some deep philosophical stuff going down that path. Why is there such a huge Android vs iOS debate? Because people define themselves by what "team" they're on. Be it computers, phones, programming languages, sports, politics, etc. It's "us" vs "them".
Each language fills a void, a different way of doing something, just because it can be done. Because it is possible. And there are always uses for every way something can be done.
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.
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.
I get what the author is saying, but don't we all know that all languages are "bullets" but non-silver bullets aren't going to slay the beast (metaphorically, software design/management).
In other words: if you're rendering HTML with node, you're probably doing it wrong.
[deleted]
I couldn't agree more with the author.
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.