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.
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.
Amen. I'd add that while JS is great for form validation, trying to make it into a first class language is a bit laughable. For example, if you want to define a function in a namespace, it's up to you which half dozen "patterns" you use to emulate namespaces in the language that lacks them. Same goes for private method/variables, continuations, classes... or more features of other common language. Add to that the type coercion cluster and the ability for attackers to redefine core language types (make 1 evaluate to false) and JS is still a bit of a anything goes wild west of a language (first class functions are fun).
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.
> while JS is great for form validation, trying to make it into a first class language is a bit laughable
FWIW, I've written a few 100KLoC of production JS code
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.
Various large enterprise one page apps mainly in ExtJs (i.e. 70KLoC per app), predating the many new Xjs libs. Admittedly, they are likely terser these days than a few years back. However, I like to stick to GWT now and write JS compiler plugins to get the JS I need. :)
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 :)
Type annotations are indeed useful for maintaining large projects. Even in dynamic languages, a lot of maintaining a large project is effectively type discipline.
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.
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!
What did you switch to after abandoning Rails? I consider the tooling and rails ecosystem to be the best for small, agile projects and I'm really interested in the alternatives.
I switched to node.js because it was the trendy new thing and I could charge 3x the rate of boring mainstream programmers to deliver the same product, except worse (because it's node.js).
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.
We see more apps being developed for the web with heavy javascript UIs. I've worked on a number of "enterprise" apps that are simply rest client SPAs. I could see a huge benefit to having a unified build/CI process for the UI and backend which makes a javascript runtime particularly unique.
OpenResty consistently handles 5 times more connections than Node.js, without requiring any of the continuation passing nonsense. As usual, popularity doesn't reflect upon quality at all -- Node.js is the Kim Kardashian of web frameworks.
OpenResty is fine for just that... REST interfaces.
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.
I do hear people saying that code can be reused across client and server but I don't find many examples of it. I understand that using one programming language for both client and server is really good as there is no context switch but I don't think that there can be much code can be shared between client and the server.
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?
I discovered openresty a few weeks back and I must say that I am very impressed by it. I think it is one of those frameworks that can be immediately useful to everyone who is already using nginx as it provides a better way to work with nginx than the default configuration rules.
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.
> 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.
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]
Yeah, of course the thing was faster. I would be upset if you didn't get this result after rewriting from a crufty old system that was never intended for the purpose it's serving into new code that uses appropriate technologies and benefits from all of your experience.
Other than Rails vs. Node as an appropriate platform for proxying slow api requests, the technology involved is basically irrelevant here.
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.
I thought that was pretty funny line as well. Say what you will about Facebook, but next to Paypal Facebook looks like one of the most innovative companies in tech. Who cares what you are programming in if the product isn't exciting. Heck even Elon flat out called paypal a dinosaur recently.
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.
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.
...I'm not sure you're understanding the point of those objections.
> 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.
But... if you're going to bolt on an "async" library, bolt on threading, and bolt on strict typing, why not use something that starts with that stuff? And ends up doing it better since it was actually created with that stuff in mind, instead of aftermarket bolt-ons?
Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.
Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting
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.
Bolting reusable libraries together is great for some things, not so much for others. How much of that large package repository uses different (or worse, conflicting) solutions for abstracting async programming? Some batteries really are better off being included.
And I'd observe that all three of the things I mentioned ("async", threading, static typing) are firmly in the "not" camp.
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.
It is true though that many js deficiencies have turned out to be factors contributing to node's popularity. A lack of namespaces, standard library and import/require come to mind.
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.
"a) A small core API instead of a sprawling standard class library"
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.
I think my point is clear when you read what I wrote as a whole instead of dissecting parts. I'm allowed to editorialize a bit, am I not? I'm not a robot nor am I writing my thesis on the subject, we're just talking here.
I view async style wrappers not really getting away from callback hell. Calling it async doesn't make it better.
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.
Another upcoming method to avoid callback hell that is my personal favorite is harmony generators and yield. Reminds me so much of C# async. Two great libraries can handle it today on beta versions of node [1,2]. I have only used suspend. See this gist for comparison https://gist.github.com/codystebbins/a2c354d25ce28879bfe1.
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.
>> Strict typing won't make you a better developer
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.
But, of course, the "if we don't like Node.JS, we just don't understand the true way(tm) of using it" card.
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 reason to be in callback hell if you use an asynchronous control flow library"
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.
The whole point is that nothing new is being said here. Node is obviously a polarizing issue, and if you look at my comment, I was careful not to make the claim that its good for everything. "JS isn't without its flaws," I said.
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...
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 excellent 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.
Unfortunately its not a startup topic. Decades ago we used to absolutely dread seeing a non-technical manager walk into a meeting with a copy of PC Magazine or similar, knowing that we're about to be lectured about "how it really is" and "the right way to do everything".
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.
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.
Do you know of a way to use libevent to make concurrent queries to mysql? Or mysqli to do this? I mean hitting MULTIPLE database servers / shards.
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!
IO related PHP API are a problem, one needs non-blocking functions for optimal performance.
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?
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.
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.
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:
"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."
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.
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.
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.
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.
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.
https://news.ycombinator.com/item?id=7401564
https://news.ycombinator.com/item?id=7397637