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.
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.
Just my 2cents...
FWIW, I've written a few 100KLoC of production JS code, but man, I'd really rather use Java/C#/PHP as everyone in JS land has to bend over backwards to try to have the features that are standard out of the box in other languages.
Having written a few KLoC of js with angular.js and about the same in tests on it, it definitely is a first class language now ... for the browser. On the server, you have other better options with types, threads and the whole works.
Also, if you've actually written over 100KLoC of javascript, then either you work on high-end web apps for google and co, or you're coding badly wrong.
I say PERL advisedly, since the Perl I write in is nothing like the horrors perpetrated circa 2001.
I have friends in the ruby community who're also looking forward to the uncaring hordes stampeding elsewhere. After all, these are people who managed to make PHP4 look like a worse language than it actually was :)
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!
> 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.
[0]: http://ikaisays.com/2012/10/04/clearing-up-some-things-about...
Other than Rails vs. Node as an appropriate platform for proxying slow api requests, the technology involved is basically irrelevant here.
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?
JS isn't without its flaws, but can we at least put a few fallacies to rest:
> callback hell
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].
> single-threaded
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.
> lack of strict typing
Strict typing won't make you a better developer, and you can enforce some degree of type correctness with Closure compiler annotations.
[1] https://github.com/caolan/async [2] https://github.com/caolan/async#auto [3] http://nodejs.org/api/child_process.html
Provides a couple of big name companies and essentially zero evidence.
This is fluff at best.
But that applies to a lot of topics on HN.
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.
I can't imagine what sort of enterprise cruft will layer on when people are doing that with callbacks, etc.
Facebook developers can sometimes outperform Google developers, although the comparison has a lot of extaneous variables here :)
Where Node.js shines is Web Sockets and similar things. But one can use libevent with PHP (though not as easy).
I found some useful comparision benchmarks on that site: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...
That would speed up my php by a lot. I an cache results of queries in PHP but can't batch things together before they are sent. In JS I can wait for 50msec to do requests in batches. That lets higher lawyers (ViewModels) query the model without worrying about batching!
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.
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.
Not sure how I feel about enterprise node.js.
"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."
[/me searching job postings for Node.js]
NOT!!!
But hey, the more developers jump ships to Node the more money I make. Look at the Cobol guys and their salaries.
This sort of convergence is why node is so popular.
Pretending like this is some sort of fashionable trend like bell-bottoms is just plain silly.
That sounds good, however in practice it's not that much.
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.
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.
Quite possibly the most arrogant tag line I've ever read.
Java is dead. Long live Java!
I need a new thing though, since apparently node.js is getting too mainstream. Maybe if I can convince enough businesses that they NEED clojure, then I can go that route.
If you're making an entire web application with a lot of front-end code that is already written in Javascript it is an added cost to also support C and Lua.
A lot of important development time can be retained by not having to write the same functionality in multiple languages.
A module can be written in Javascript and used on both the client AND the server.
Don't conflate mainstream media fashion with the sort of pragmatic convergence that has been a big part of driving the adoption of node.
"Raw speed" over everything else is the Yngwie Malmsteen of programming language metrics.
And the best part is it is 100% compatible with nginx config file. So all your default locations and blocks that already work with nginx are going to work with open resty. You can now organize and program it better.
> callback hell
It's great that there are better options out there for handling async programming, but at the end of the day you're still using callbacks for control flow. Having to partition out application logic across I/O events sucks, and picking a model where that is the only option is going to raise some objections. Especially when you have languages like Lua that use coroutines to manage the exact same performance guarantees without the code organization headaches.
> single-threaded
The complaint about single-threaded evented servers is that the performance of the whole system relies on you correctly answering the "will this piece of code perform extensive computation" question at every point in your program. That's not an impossible challenge, but I don't think it's an unreasonable one to complain about.
> lack of strict typing
No, strict typing won't make you a better developer, but it certainly will help save you from yourself. Again, writing extensive amounts of application code in a tool that comes just short of actively hindering correctness is an exercise in frustration. You shouldn't be surprised that people object to this.
I think it's great when people look at all of these issues and decide that Node is still valuable for their use case despite them. It seems like there are a lot of bandwagoneers who aren't making that kind of evaluation, and I think it's a good idea to keep hammering away on these downsides until they do.
Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.
a) A small core API instead of a sprawling standard class library
b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1)
c) The fastest growing and soon to be largest community repository of packages (2)
d) asynchronous by default stack and ecosystem.
With those things in hand, "bolting on" is a virtue and not a disadvantage. That Node is general-purpose - you can build cross-platform desktop applications, streaming servers, web applications, console utilities, etc - and does not impose its package opinions are major factors in its success.
1) http://blog.izs.me/post/1675072029/10-cool-things-you-probab...
Python's Twisted has been around for ages with world class "async" and it is a pain to work with in large code base. Callbacks and async does work for demos and toy projects, which is I think one reason they got some adoption.
Representing concurrency contexts as a chain of callback functions or promises/futures/yields I posit is usually worse than a green thread or actor that gets and sends messages. It doesn't mean it cant' be done but if feels like why go through that pain when there are real threads/goroutines/tasks/Erlang processes.
> 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.
I can do that with regular OS processes what does Node.js give me then? I can spawn processes from C, Python, anything.
> lack of strict typing
Weak typing is insane. This is 2014, there is not reason to silently turn "5"+[]+5 into anything except an exception. This isn't about a better developer, this is about sanity. Now I like use dynamic typing a-la Python and Erlang. But those have strong types. Adding a 5 to a string will blow up.
With generators try/catch can be used, avoiding a lot of the redundant error handling. Crabdude's library can avoid the overhead of try/catch [3].
And if developers want static typing, they should check out TypeScript. Works great with node.
[1] https://github.com/jmar777/suspend [2] https://github.com/visionmedia/co [3] https://github.com/CrabDude/trycatch
It won't make you a worse developer either. Loose typing can make you a worse developer because it's easier to make mistakes that sometimes aren't caught until after it's in production.
Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X".
I've seen this too many times.
I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology.
No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects.
I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.
There's no good reason to pile flawed layers on top of eachother. If you have a fully yieldable/resumable VM (e.g. Lua), you can just solve the problem properly in the first place, in a way that doesn't then require a second or third layer of workarounds to be usable.
Sorry, as HHVM doesn't expose libevent yet (at least last asked the devs on IRC), I moved some portions of my code to node.js for now. (plus HHVM relies itself on the older libevent 1.4, instead of the 2.x that PHP exposes as API)
I would be interested in the answer too. Maybe ask it on stackoverflow.com or so?
Also you don't need to program entire application in open resty. Just the idea of using lua instead of nginx mini- language for the config files can be a good enough reason to give it a try. Every body uses nginx anyways for their front end, no?
And yet, I see "platitudes", "if you can't bother to do basic research", "can only induce laughter", "pile flawed layers on top of each other", and "amounts to an admission that you shouldn't have started with Node in the first place".
And the meaningful comments have the "reply" link disabled for me, so...
If the Node community admits these are desirable characteristics of a programming development environment, then they've lost, because they can not compete on any of those three fronts. The entire value proposition of Node was basically that those three things weren't important. If they are, Node's arrogant swagger turns into a frantic attempt to cobble together enough functionality to pretend to have the features that exist better elsewhere.
Don't think you can sell me on fundamental weaknesses in your language of choice being features, twerquie. I've got too much experience in too many environments to fall for that.
Why, it's almost as if Node is built on fundamentally 1990s scripting technology based on fundamentally 1970s event-based ideas or something, instead of being the radical revolutionary departure we all know it really is.
I'm not interested in arguing about technical superiority, I'm sure node is no where close to ideal. But, like javascript itself, it's popular, interesting, useful, and here to stay. From my perspective, for better or worse, javascript is the most important programming language of the decade.
ES6 standard promises have landed in v8 (https://code.google.com/p/v8/source/browse/trunk/src/promise...) so it's only a short matter of time until the "batteries included" solution is available.
But that doesn't mean people will be forced to use them.
Using adjectives to accentuate, does not an argument make. "small/core" and "sprawling" all have loaded meanings. And if you wish to convert anyone but the already-converted sub-culture inhabitants, you should probably quantify what you mean and why it's a benefit.