This article is promotional fluff. It has also been submitted more than once before. We're going to bury the post. Please don't post it again.<p><a href="https://news.ycombinator.com/item?id=7401564" rel="nofollow">https://news.ycombinator.com/item?id=7401564</a><p><a href="https://news.ycombinator.com/item?id=7397637" rel="nofollow">https://news.ycombinator.com/item?id=7397637</a>
And then as soon as Derpys Mansion new language comes out all the newcomers will flock to that and you're entire staff will leave to go work for some startup.<p>The reason why "Enterprise" uses the software they do is not because it's the fastest, or most suitable for the job. It's that it's been in production for many years and has a large ecosystem and strong commercial backing. Along with a strong workforce that isn't going anywhere.<p>Not that I don't think NodeJS awesome. The javascript language is just a bit meh for Enterprise development. I'm not sure if you've ever seen "Enterprise Javascript" but I sure as hell would not want to see "Enterprise NodeJS" I would much rather see a strong typed compiled language that requires things to be done a certain way. Rather then the clusterfuck of libraries NodeJS comes with.<p>Just my 2cents...
These stories about switching to node are pretty funny: "I switched from a dump truck to a motorbike and now I can drive way faster!" Node.js isn't really faster than most other popular languages with an evented library, but if switching to Node involves scrapping years of enterprise cruft, then maybe it's worth it.<p>By the way, enterprise adoption of Node is surely a sign that we need to jump ship. Glad I got out of Rails before enterprise adopted it!
<p><pre><code> > The old story of linkedin where moving to Node.js from Rails
> for their mobile traffic, reducing the number of servers from 30 to 3
>(90% reduction) and the new system was up to 20x faster.
</code></pre>
It isn't as simple as that. There was a great article from a former linkedin engineer about why the original API server was so slow. [0]<p>[0]: <a href="http://ikaisays.com/2012/10/04/clearing-up-some-things-about-linkedin-mobiles-move-from-rails-to-node-js/" rel="nofollow">http://ikaisays.com/2012/10/04/clearing-up-some-things-about...</a>
Trying to sell Node using soft arguments: "Argumento ad populum" and "Argumento ad novitatem", which BTW are fallacies. No technical arguments, no polls, no facts. Just fallacies.
“Why go to Facebook and do PHP when you can go to PayPal and do Node.js”<p>Why choose the company you work for based on technology when you can choose the company you work for based on the company you will be working for?
It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS.<p>JS isn't without its flaws, but can we at least put a few fallacies to rest:<p>> callback hell<p>There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard style of function signatures. I love @caolan's async [1]. In particular, there's a control flow pattern called `auto` that really (IMO) demonstrates some of the power of async programming: it's a full dependency graph resolver [2].<p>> single-threaded<p>There's the cluster module, but nevermind that -- you can always just use the child_process library [3] to access spawn() and fork(). Remember those? Processes are a more nautral match for distributed computing than threads anyway.<p>> lack of strict typing<p>Strict typing won't make you a better developer, and you can enforce some degree of type correctness with Closure compiler annotations.<p>[1] <a href="https://github.com/caolan/async" rel="nofollow">https://github.com/caolan/async</a>
[2] <a href="https://github.com/caolan/async#auto" rel="nofollow">https://github.com/caolan/async#auto</a>
[3] <a href="http://nodejs.org/api/child_process.html" rel="nofollow">http://nodejs.org/api/child_process.html</a>
"the main backend node.js consulting company in Europe" asserts that Node.js is becoming the go-to technology in Enterprise.<p>Provides a couple of big name companies and essentially zero evidence.<p>This is fluff at best.
The article says "good developers like to learn new things and to use new technologies" ... therefore the language that's briefly cool this year is an <i>excellent</i> bet for your enterprise's long-term future. Right.
Somebody should start a "Vogue for Developers", so we can just stop pretending. Most of this article and most of this thread is about fashion, not technology.<p>But that applies to a lot of topics on HN.
I had used node.js for about two years, and it's not without its share of pain. Trying to find some way out of callback hell, and then finally adopting a rack-like way of writing the controllers, it's somewhat manageable.<p>It takes quite a bit of getting use to, think and write in promises, futures, or whatever other shenanigans we come up with to deal with callbacks. I suspect it's a weakness of the language design, bent to the will of the reactor pattern.<p>I can't imagine what sort of enterprise cruft will layer on when people are doing that with callbacks, etc.
Actually with HHVM, PHP is faster than Node.js!<p>Facebook developers can sometimes outperform Google developers, although the comparison has a lot of extaneous variables here :)
I develop with Node since it is 0.4, and I can safely say that Node is as good as your abilitiy to manage callback hell. If you can, it is pretty awesome, however you need to study some patterns for that, otherwise it is messy.
I'm currently a tangential part of a project that just went from being a Java backend/middleware project with a Flash front end, to a Java backend with and HTML/JS/CSS frontend with a node-ecosystem build/package tools.<p>Two weeks ago I complained that we have two build tools (ant and grunt) and three package managers (ivy, bower, and npm) involved... but doing a build/deploy is a 5-step manual process that results in dependency errors.<p>This week things have improved -- the first build is a dozen manual steps, subsequent builds are only 2-3 steps, and though the deployment seems to be botched, there are no dependency errors.<p>Not sure how I feel about enterprise node.js.
There are some good points in the piece, but aside from "You can easily hire people to work on the latest hot thing" the benefits boil down to some back-end architectural patterns that make good sense, and are achievable on many different stacks. We too build "small modules piped together" however we use python, java, and redis or rabbitMQ for the plumbing. I have some problems with python as an enterprise development language, but many more with JS. Lately my colleagues and I have been talking about Go a bit, so we'll see where that... um... goes.
Arithmetic has a uniform syntax. Here’s an argument for standardizing the syntax of well understood programming concepts:<p>"Node.js programs are developed using JavaScript, this means that the silos that existed between frontend developers and backend developers are now broken down, and this results in significant efficiencies in the development process. With Node.js it’s possible to merge web and backend teams into one unit which makes things much more efficient."
Really?<p>[/me searching job postings for Node.js]<p>NOT!!!<p>But hey, the more developers jump ships to Node the more money I make. Look at the Cobol guys and their salaries.
I frequently write modules that I use on both the client and server side of a web application because I'm writing in the same language on both the client and server.<p>This sort of convergence is why node is so popular.<p>Pretending like this is some sort of fashionable trend like bell-bottoms is just plain silly.
On the bright side, if Node.js is adopted for "enterprise programming", all the hipsters that write blog posts about how great Node.js will abandon it overnight.
> With Node.js it’s possible to merge web and backend teams into one unit which makes things much more efficient.<p>That sounds good, however in practice it's not that much.
Depends on the purpose, I always find rails more fun due to large community contribution and huge number of gems that work well, very convenient active record etc.
The real reason is quite simple. And I'm not trying to be bitter or anything, rather think like a businessman.<p>The reason is... it's full of JavaScript kids out there, and because they're so many, they're all replaceable, and cheap. Like the commodity hardware servers they're programming.<p>It's neat to cast this as "easy to attract and retain talent", but "rapid innovation" and "developer happiness" (especially considering the lack of strict typing, lack of basic primitives, single threaded-ness and callback hell of Node.JS) are just B.S. reasons of the kind a Node.JS consulting company would add so it doesn't all look so cynical.