I usually ask people to explain why they picked or like (or dislike) a particular technology and that surprisingly tells quite a bit about their proficiency level.
At least in interviews I found it tells a lot more about their proficiency than say knowing how to invert binary tree in under 20min or solve a digital circuit diagram in with object oriented principles.
Node.js is a technology that raises red flags when someone advocates it. I've heard stuff like "it's async so faster", "it makes things non-blocking so you get more performance not like with threads", "you just have to learn one language and you're done", "...isomorphic something..." When digging in to discover if they knew how event dispatching works or how these callbacks end up called data comes in on a TCP socket, and there is usually nothing.
The other red flag is the community. Somehow Node.js community managed to accumulate the most immature and childish people. I don't know what it is / was about it. But there it was.
Also maybe I am not the only one, but I've seen vocal advocates of Node.js steam-roll and sell their technology, often convincing managers to adopt, with later disastrous consequences. As article mentions -- callback hell, immature libraries, somehow the promised fast performance guarantees vanish when faced with larger amount of concurrent connections and so on. I've seen that hype happen with Go recently as well. Not as bad, but there is some element.
Now you'd think I am 100% hater and irrational. But one can still convince me that picking Node.js was a good choice. One good thing about Node.js is it is Javascript. If there is a team of developers that just know Javascript and nothing else. Then perhaps it makes sense to have a Node.js project. Keep it small and internal. Also npm does have a lot of packages and they are easy to install. A lot of them are un-maintained and crap but many are fine. Python packaging for example used to be worse, so convincing someone with an "npm install <blah>" wasn't hard.
I've been developing public and internal APIs with node.js full-time for the past 3 years. I can see where you are coming from, but nothing you've said explains why the platform itself is not useful. Most of what you complained about is the caliber of developer and the ecosystem. That reminds me a lot of the complaints about PHP.
The truth is that there are good developers using node.js, there is good code in the ecosystem, and someone that's worked with for a while has learned lessons.
I agree with your performance complaints. On my last project we had to spend considerable time reworking components of our application due to those components blocking the event loop with CPU intensive tasks.
I would say that node.js is probably selected more than anything else for speed of getting a project up and running. It's easy to find JavaScript devs. JavaScript doesn't require a compilation step so iterating and debugging small changes is much faster. There's a ton of pre-build frameworks for serving up APIs even with very little code for CRUD apps.
It's not that there's something you can do with node.js you can't do with other languages. There's just less of a barrier to entry.
There's _way_ more bad Perl in the world than good Perl (Matt's Script Archives anyone?), but these day's it's easy to find well written Perl and appropriate and useful Best Practices for Perl projects of any scale.
There's a _lot_ of bad PHP out there - but Facebook and HipHip clearly show that there are sensible, scalable, and well understood ways to write good PHP code.
Nodejs seems to me to be like the Perl world was in '95 or the PHP world in 2000 or the Python world in 2002 or the Java world pretty much forever ;-) There's not enough examples of "Good Nodejs" yet, and all the Google searches show you are "typical" Nodejs code - which as Sturgeon's law dictates "90% of everything is crap" - so most of the Nodejs code that gets seen or discussed is crap. That will _probably_ change as we "forget" all the worst written Node, and upvote, links too, copy, and deploy well written Node.
There's more similarity to PHP that other languages in my opinion too, in that Node _is_ Javascript, and like PHP, it's a fairly easy route into "development" for an html savvy web designer, which means there's a _much_ larger pool of novice Javascript/Node devs with little or no formal training. You don't need 3yrs of CS degree to dive in and start "scratching your own itches" in Javascript - and in "that part of the industry" it's much easier to leverage "a great looking portfolio but no CS degree" into a job offer than in, say, an enterprise Java or DotNet shop (or a GooFaceAmaUber "don't even respond it they don't have a PhD in another field as well as their CS one" reject-a-thon...)
You're touching the reason yourself. When 90% of the code you find is crap, it simply means that the language has a low barrier of entry. When languages like ML/Scheme/LISP variants, Haskell, ect. don't have that much crap, it's because the barrier of entry is higher.
And this goes not just for languages. Frameworks like Akka, is the same. The idea of actors to form the system is simple and elegant, but it's far from simple to get started with.
For Perl and PHP - as well as the low barrier to entry, there was also the almost ubiquitous availability - at least across web hosting platforms in the late '90 and early 2000s. I was a Perl guy through and through back then, but even I wrote some PHP because getting web hosting companies to allow/enablePerl cgi (or even worse fastcgi or mod-perl) was expensive or impossible, where PHP was "just there" and "just worked".
(But yeah, you don't get frustrated pixel-pushers from the coloring in department getting over ambitious and writing up a site backend in Rust or Go... Your typical weekend Haskell hacker is about 100% likely to be able to spell "algorithm" and at least handwave their way through a Big O discussion... No big criticism of talented designer types, but in general they've got as many holes in their understanding of the "S" bit of "CS" as most developers have in their aesthetic abilities...)
Python hasn't got a high barrier to entry (unless you are talking about deploying it to a web server). The code is generally better than PHP or JS code (though I have seen my share of crappy Python code).
Hell just getting PIP installed can be a bear on windows, remembering the damn --upgrade flag, and the whole concept of a virtualenv means that often the casual python hacker doesn't have access to packages in python until they are much further along.
Contrast this with Node where npm is always right there, and installs are local by default means the kid that just sits down with js has access to every package out there and can even publish things his/her first few days.
I'm obviously more comfortable with the NPM ecosystem, and I might just be biased, but it does seem much easier to work with and use.
My understanding is that Facebook has migrated most (all?) of its PHP codebase to Hack, which goes to show you: even the company that built a global empire in PHP can recognize it for the shitty, inadequate language that it is.
<devil's advocate> On the other hand, that shitty inadequate language got them up to their first billion or so users and way past Unicorn stage. If you're optimising your language choices and talent pool for your second or third billion users when you currently don't even have enough users to fund the ramen invoices, you're 100% certainly playing around with "the root of all evil"... ;-)
FB's primary reason for creating Hack was to add type-safety to PHP code. They spoke about how PHP was great for the fast development cycle, but would benefit from more structure if the created codebase was to become long lived. So the new Hack code is the same PHP code, only with types (and the implied benefits such static analysis, optimisations, etc).
Incidentally, this is also why FB created Flowtype - the lack of types is a massive boost during the code's youth, and a massive burden from early adulthood and onwards. Hack/Flow are a clever way to bridge the gap between typed and nontyped languages.
I was going to say the same thing about PHP. I was at a PHP shop who thought all their problems would be solved with NodeJS. They basically created the same problems in Node. The next place I went to was heavily biased to Erlang and OCaml, but the front-end is done in Node. But the code and architectural quality are like comparing night and day.
>I would say that node.js is probably selected more than anything else for speed of getting a project up and running. It's easy to find JavaScript devs.
Writing JavaScript for the browser and writing it for Node.js are different beasts. It's "easy" to find JavaScript devs because most people have tinkered with jQuery and think that qualifies them. Furthermore, since the Node.js explosion in 2012, lots of posers have been trying to get into this scene.
>JavaScript doesn't require a compilation step so iterating and debugging small changes is much faster.
As another commenter pointed out, this is true, but most projects use a Grunt pipeline or something similar at this point, because they'd feel left out if they didn't. Just more groupthink from the Node.js camp.
This isn't a unique property to Node.js. Pretty much everything that isn't Java, C#, or mega-crusty pre-Perl CGI has it. However, compilation is actually pretty useful; it's not something you necessarily want to throw away. Java and C# devs seem plenty capable of training their Alt+Tab / F5 fingers to get tweaked code running fast.
>There's a ton of pre-build frameworks for serving up APIs even with very little code for CRUD apps.
There may be, but the JavaScript ecosystem changes so quickly and integrates so many esoteric, not-supported-anymore-after-next-Tuesday things that it's offputting. My experience with the code quality of a lot of common libraries has not been great either.
I personally detest the Node.js fad and can't wait for it to die out. I have never been able to find someone who can actually give me a good reason for it to exist. At least when RoR was the fad there was a sensible reason behind it: PHP sucked. I really don't know why Node.js even exists except to push buzzwords and execute a really terrifyingly bad idea of making everything JavaScript.
Even Eich admits that JavaScript was a one-week, publish-or-die project that did many things wrong. It's frankly embarrassing that we still use it as the primary language in our browsers 20 years later. I don't know who looks at that and says "Let's take this to the backend, baby!"
Personal ambition is basically the only reason I can think of for Node.js to exist, both in general and in any specific organization. People see it as a tool to colonize parts of their company. That's the only explanation, because they assuredly don't see any technical benefits in it.
I've done quite a lot of C/C++ work. In my experience, getting JS up and running is more exhausting. You might have webpack running, which runs babel, and sass, and a few hundred node processes. It's just bloody insane today. And none of it plays nice at all.
> If there is a team of developers that just know Javascript and nothing else. Then perhaps it makes sense to have a Node.js project. Keep it small and internal.
If you have a team of developers that know just JavaScript and nothing else, you are probably dealing with 100% front-end developers that have little to no understanding of systems programming and what you need to do to be performant and secure outside of a browser.
This leads to a lot of issues with security in the Node.js ecosystem, and is one of the reasons I have a job.
Any developer that only knows one language is carrying around a horrible cognitive bias of how software should be written and they don't even realize it. They are dangerous, keep and eye on them, and for the love of god teach them something new.
Depressing thought of the day; most of the developers I work with only know 1 language and/or framework and have no ambitions to expand. I guess this is just the life of an "enterprise" employee. :(
Honestly, when I mention something like Golang or Rust or Cordova they look at me like I have 2 heads or something. Yes, I don't expect the layperson to know what those are but these are long term application developers (mostly C#) and they have never-ever heard of these things. At first I just thought it was the people I work with but I recently changed jobs and its the same thing there. I really am beginning to think that I'm an anomaly.
ehh, this is just usually shortsightedness for all involved. A front end developer for JavaScript is going to know HTML/HTML5/CSS/JavaScript and the quirks of all browsers and quite possibly complex frameworks on top of all of this. The amount of knowledge to be good at all of this far surpasses the "oh, they only know javascript" naivety that I hear from other developers.
I know Java developers and .net developers who don't know or want to know any other language because they're not just "java" devs, they know the frameworks and have experience to build things.
If all you do is "Scripting" then sure, know a few scripting languages
> The amount of knowledge to be good at all of this far surpasses the "oh, they only know javascript" naivety that I hear from other developers.
No, that's not it at all. I am friends with front end guys and I'm aware at how much work it takes to just keep up with and be good at the framework du jour, Backbone or Angular or React (then Flux, then Redux) and whatever's next from there.
Being good at markup and layout, and being good at a front-end framework, are not skills that are direct analogues to systems-level issues that plague Node.
For example, Node LTS's Buffer() uses UInt8Array on the browser, but a malloc() on the server side that may return insecure memory with leaked information from other parts of the process. libuv's event system is written in C. Socket programming on -nix is nothing like using a WebSocket library in Chrome, and the front-end has no concept of filesystems outside of localStorage or limited WebSQL use. When was the last time a browser had you deal with malloc()?
How many front-end developers understand the performance of writing files to disk with different filesystems, master-slave or master-master replication of databases, building solid server-side deployment workflows, securing their code and their servers from all the things that can go wrong? This skillset generally doesn't exist; it's abstracted away by the Chromium sandbox, or the interpreter. Front-end generally does not require knowledge of the principles of the underlying operating system and architecture to get the job done.
On the backend, all of these problems become apparent. It takes a different way of thinking, and a different understanding of a computer system. My original comment to rdtsc is just that -- a "JavaScript" developer that works on front-end tech only doesn't have an adequate idea of how these things work to build good server-side architectures, and Node.js is not the tool to use for those types of things.
Frankly, if they only know JS, they haven't touched these things at all. Outside of Node and Electron, virtually nothing on a system outside of a browser is written in JS, so you wouldn't have picked up these systems skills in JavaScript.
This seems dishonest. Everything you said happens regardless of language. Being a go developer doesn't mean you know more about how goroutines are handles on your operating system. The very same techniques you use to expose performance metrics and analytics happen in go, java, ruby, python et all that happen in node and i'd wager that node/javascript has an abundance of profiling and performance tooling for people to embrace.
Sure.. some developers may not understand the implications of everything they do, but if the app has implication that impact their performance they will discover them.
Not everything needs to be over optimized, over engineered or overly complex.
As an Ops dude i find it infinitely easier to scale/manage nodejs apps than i do java.. For instance i can solve some issues by scaling out node wider across more machines than having big optimized single machine and an implication of going wider means if some things crash, the others handle it and because i go far/wide i've chosen to optimize on availability/performance in different ways than you.
I may know that a node app crashes after x days for leaky memory and deal with it because i have mesos/marathon watching alive pages and killing/restarting the container and redeploying the app or autoscaling it up and down as need be.
Replace node with anything else and you have the same problems.. we see 100's of jvms released a year.. many versions of go.. many point releases of ruby.. python.. its a never ending battle that has to be fought a lot more deeply than any one person or one developer ever can.
and lets be honest, even the best node app is building something to build the best front end so letting front end developers focus on being front end engineers and helping them solve any issues thereof to fill in the blanks is not a bad way to do business.
Expecting everyone to over optimize and over engineer and over theorize about how things should be is a huge waste of time.
I've never really understood the "one langauge" argument. I'm a good (not great) front-end JavaScript programmer, but I don't think that helps writing node.js. Sure, the syntax is technically the same, but the bulk of a node.js program looks and is written quite differently from front-end js (even js library writing). Surely having similar syntax (which is basically C-like anyway) isn't that big a deal?
It's supposed to mean you can share object declarations. But it's javascript so that doesn't mean much. And it's not like the data format in the database and the gui is ever the same by the end of a project anyway, so two formats end up being needed anyway, so it's a bit of a pipe dream.
The one case I've found where node really makes a lot of sense is if you're trying to build a webapp with a native version using the same code. Then node-webkit is the only game in town that doesn't involve a transpiler. Then again, the component parts are flaky enough that maybe the transpiler isn't so bad afterall.
The one language argument, as far as I can tell began when people tried to share code across the server and the front end, it sort of worked for one persons use case but nobody else really had much success with the endevor (at least that I'm aware of.)
That argument is a pretty bad one and is the one most people like to assume people are talking about so they can make fun of it.
The real argument, at least in my mind is that you can specialise and pretty much run your entire stack completely in js with only a bit of json and some html. Build tools, database access, deploy tools, dependency management, server side code, client side code, its all JS.
For me, I don't agree that it matters, I don't even think having a diverse stack takes much longer to learn. But I do understand the fanfare for it.
I'm still surprised no one has created a JavaScript front-end for Erlang/BEAM, like Elixir or LFE. JavaScript is a decent language with a huge community and Erlang/BEAM could solve Node's deficiencies like async-everything APIs and single-threaded execution.
That's because Erlang developers have good taste ;-)
But Elm is actually moving in that direction, the last release added a process abstraction inspired by Elixir, and I've read they're even considering BEAM as a compile target, in addition to the current JS target and plans for a WebAssembly target.
> JavaScript is a decent language with a huge community and Erlang/BEAM could solve Node's deficiencies like async-everything APIs and single-threaded execution.
While BEAM of course has facilities at the VM level that support that, you'd have to extend javascript to take advantage of them on top of building a JS->BEAM compiler.
At which point, the benefit of using JS rather than a language designed to deal better with concurrency and parallelism is dubious.
Maybe because JS is not really a decent language, just the pile of awfulness that we've had to grin and bear it with to do web front-ends for too long, and Erlang or Elixir is nicer to work with to start with.
At least in interviews I found it tells a lot more about their proficiency than say knowing how to invert binary tree in under 20min or solve a digital circuit diagram in with object oriented principles.
Node.js is a technology that raises red flags when someone advocates it. I've heard stuff like "it's async so faster", "it makes things non-blocking so you get more performance not like with threads", "you just have to learn one language and you're done", "...isomorphic something..." When digging in to discover if they knew how event dispatching works or how these callbacks end up called data comes in on a TCP socket, and there is usually nothing.
The other red flag is the community. Somehow Node.js community managed to accumulate the most immature and childish people. I don't know what it is / was about it. But there it was.
Also maybe I am not the only one, but I've seen vocal advocates of Node.js steam-roll and sell their technology, often convincing managers to adopt, with later disastrous consequences. As article mentions -- callback hell, immature libraries, somehow the promised fast performance guarantees vanish when faced with larger amount of concurrent connections and so on. I've seen that hype happen with Go recently as well. Not as bad, but there is some element.
Now you'd think I am 100% hater and irrational. But one can still convince me that picking Node.js was a good choice. One good thing about Node.js is it is Javascript. If there is a team of developers that just know Javascript and nothing else. Then perhaps it makes sense to have a Node.js project. Keep it small and internal. Also npm does have a lot of packages and they are easy to install. A lot of them are un-maintained and crap but many are fine. Python packaging for example used to be worse, so convincing someone with an "npm install <blah>" wasn't hard.