
“Node.js is one of the worst things to happen to the software industry” (2012) - behnamoh
http://harmful.cat-v.org/software/node.js
======
Jemaclus
Disclaimer: I worked with Node.js full-time for about 14 months, ending about
9 months ago. I'm willing to admit that the following complaints may or may
not be out of date, especially with ES6 and newer Node versions. Proceed with
grains of salt at the ready.

There are a lot of things to like about Node.js, but the primary thing that
bothers me about it is the obsession with async. It's a language/framework
designed to make pretty much everything async.

In the real world, almost everything is synchronous, and only occasionally do
you really want async behavior. By that I mean, you almost always want A, B,
C, D, E, F, G in that order, and only occasionally would you say that you want
async(H,I). But with Node, it's the other way around. You assume things are
async, and then specify synchronous behavior.

Instead of assuming A; B; C; D; E; F; G;, you wind up with a ton of code like
A.then(B).then(C).then(D).then(E).then(F).then(G);

...I know that's a contrived example, and I know you don't really need to do
it that way, but so many people do, and it really illustrates the point. In
Node.js, you are explicitly synchronous / implicitly async. Most other coding
paradigms (including Go) better match what I consider reality, which is that
everything is implicitly synchronous, and you specify async behavior when you
need it.

Basically, I think it's backward. But perhaps like the OP, I just can't wrap
my head around it.

The NPM stuff... well, I think all ecosystems have their pros and cons. I'm
not a huge fan of NPM, but it does the job for the most part, and I'm curious
as to how people would actually improve it, rather than just complain about it
all the time. I don't really have any good ideas (knowing nothing about how
package management actually works under the hood).

~~~
marssaxman
Well.... no, not really. Processors really are fundamentally asynchronous.
They are state machines which react when external signals impinge upon them.
Synchronous behavior is a useful illusion, a convenient reasoning tool for
some kinds of tasks, and our traditional notations for describing
computational processes are all based on this model of how computing might be
done - but it hasn't _actually_ been done that way since the batch-processing
era.

I learned this as I dove into low-level hardware work - drivers and embedded
systems. When you're dealing with hardware, life is fundamentally driven by
interrupts. Processors spend most of their time asleep. When something
happens, the signal level of an input pin changes, and the processor reacts:
it wakes up, it starts executing the interrupt handler for that signal, it
does things, it sends messages, and then - its job done - it goes back to
sleep.

So what, we're talking about normal computers here, you say, surely they're
different, right? But no, they really aren't; it's the same process of signal,
interrupt, handler, return, all the time. Every context switch, every packet
receipt or transmit completion, every timer tick, all of it, it's all driven
asynchronously; the system is a hierarchy of event handlers waiting for their
opportunity to respond to some external signal.

If you're trying to build an IO system, then, the synchronous model is an
expensive illusion. You can force it, but it isn't reality. You spend time
waiting, you spend time blocking, you build complex APIs that pretend to poll
arrays of connections in parallel; and all you're doing is forcing that
illusion of synchrony onto a fundamentally asynchronous world.

It's backwards, all right, but it's backwards because our traditional way of
describing computation is backwards, especially the languages which follow the
imperative tradition. Functional languages have gained popularity in part
because the mental model works better for asynchrony; instead of describing a
series of steps to follow, and treating the interrupt as the exception, you
describe the processes that should be undertaken in certain circumstances; you
effectively construct a state-machine instead of describing a process, and
then you leave that state-machine to be poked and prodded by whatever external
signals come along to drive it.

~~~
tigershark
Mainstream processors _are_ synchronous. For this reason there is a global
clock needed to synchronise all (most) the chip parts. I remember there was
some research on asynchronous CPUs but I don't think it ever yielded anything
commercial.

EDIT: Wikipedia link:
[https://en.m.wikipedia.org/wiki/Asynchronous_circuit](https://en.m.wikipedia.org/wiki/Asynchronous_circuit)

What you are saying is that they react to interrupts asynchronously, but this
has nothing to do with the synchronous nature of a CPU. Moreover I think that
if you have a CPU that doesn't respect the barriers and reorders the
instructions to execute them in parallel, then it's a bugged CPU.

~~~
the_duke
That's besides the point.

The things that are synchronous within the processor are also synchronous in
Javscript.

What is async in JS and Node (unless you use the sync alternatives) is any
kind of IO (disk, network). That is also async for the CPU.

And even the things that you would expect to be synchronous inside the CPU are
really NOT for modern, out of order CPUs. They do a lot of complicated things
to make code run faster, use branch prediction to predict the code path taken
and execute (apparently synchronous) instructions in parallel.

~~~
notalaser
But that only happens when the result is _the same_ as if the instructions
were ran synchronously, and synchronization primitives are still needed at the
end of these sections.

Even if they weren't, the abstraction layer that you work at with Node is far,
far above the point where you care about instruction reordering. If
synchronicity is an inherent property of the process that you're implementing
(e.g. you want to insert something in the database _and then_ log an event)
then no amount of shuffling will alleviate the fact that the logging has to
happen _after_ the database insertion.

Edit: the fact that deep down they reorder instructions is a bit scholastic,
but if we are to go into these details, it's worth remembering that _even the
instruction reordering_ happens synchronously, and that even asynchronous
events, like input from an off-chip peripheral, are treated synchronously. The
turtles are synchronous all the way :-).

~~~
the_duke
Haha yeah, sure. Reading the input from an IO device _once it 's been
delivered_ is synchronous.

But IO is not handled in an synchronous fashion. If CPU cores just waited
around idling until a hard drive is done fetching the data (for example), our
computers would be very slow indeed.

That was my main point.

~~~
notalaser
Ah, certainly. In a similar manner, what I meant is that oftentimes it's the
process itself that's synchronous, and if the semantics of a language or a
toolkit make it difficult to manipulate this sort of flow, people complain.

I've done too little work with Node to have a constructive opinion on it, but
I've occasionally had similar complaints about Qt, which I've used a lot more.
It uses a signal-slot paradigm where you basically say "when this event is
triggered, this function gets called" (in a callback-like, but somewhat more
powerful and flexible fashion). It's great for a lot of things, but makes it
hard to read and reason about synchronous operations that have to be fit into
this form.

Ultimately, though, people cope with it and write working software with it. I
imagine it's the same with Node :-).

------
rdtsc
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.

~~~
Osiris
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.

~~~
bigiain
This is an age old story.

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...)

~~~
hvidgaard
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.

~~~
collyw
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).

~~~
Klathmon
IMO python has a much higher barrier to entry.

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.

------
leonroy
I've been a software dev for 10 years. When I started I saw the transition
from Perl to PHP and a lot of snobbishness from the former towards the latter.
Seeing the changing of the guard in web languages was pretty instructional and
it's something I see again and again.

I think basic CompSci courses should really have a course or two on managing
software projects and handling the problems of _what framework do I use to
build my new software app?_ Because fundamental language or framework
decisions have both a technical and a business component and even as a front
line programmer it helps to be aware of both.

Node.js is a great environment for getting a server side app going _fast_ and
it has very good tooling thanks to the rest of the JS community with additions
like npm, gulp, bower, express etc. There's obvious benefit in having
shareable libraries between client and server side and most importantly (to
software companies) hiring coders who can work with it is far, far easier than
say finding that rarest of unicorns - an experienced Haskell developer.

If (and it's a damn big if) you outgrow Node.js you're doing well. Then (and
only then) look at the alternatives like Play Framework, Spring Boot, Vert.x
or whatever else floats your boat.

Rants can be useful in giving a kick up the asses of the relevant community to
go address certain bug bears. This rant though is so damn generic it reminds
me of those Perl developers at college pouring cold water over the idea of
using PHP because they felt threatened by it.

~~~
ido

        I think basic CompSci courses should really have a
        course or two on managing software projects and handling
        the problems of what framework do I use to build my new
        software app
    

The problem (if it's a problem, depends on who's asking) is that undergrad CS
courses mainly train you to be a CS graduate student (which in turn train you
to be a CS academic), but most students choose to major in CS because they
want to become professional programmers (aka Software Engineers).

I've done both bachelor and master level CS studies and job-preparation-wise
would probably have gotten as much (or more) from a 1-1.5 years (2-3
semesters) vocational training than I did from 8 years of university.

Probably the most apparent perk my studies have gotten me career-wise was
being invited to interviews at major tech companies like google and amazon.

~~~
jalanb
> most students choose to major in CS because they want to become professional
> programmers (aka Software Engineers)

Then why not major in Software Engineering? Is that not an option in American
universities?

~~~
duncanawoods
One problem is that it does not have the standing of a pure subject like math,
engineering or CS.

Its more vocational, isn't offered by top-tier universities (in the UK) and
therefore has lower status e.g. its like taking Media Studies at an ex-poly
vs. reading English at Oxford.

~~~
ENTP
It was very much seen that way back in the day at Birmingham University. We
wrote an x11 window manager with audio and graphics processor apps for our
first term in 2nd year. I saw academia start to go down the pan at college
with the introduction of "ICT". To me, this was nothing but subsidised
Microsoft training.

~~~
dagw
_this was nothing but subsidised Microsoft training._

"Subsidized Microsoft training" is what most people actually want and need to
get the sort of job they aspire to. People with this "Subsidized Microsoft
training" are also what many companies are looking to hire. So why is it such
a bad thing to offer people this option?

~~~
mellett68
It's not a problem, unless you go to higher education looking for CS and end
up with that instead.

------
JDiculous
Anybody can criticize a language or platform, but it doesn't mean much if
there aren't any better alternatives.

This article presents an extreme conclusion without much supporting evidence,
so it's pretty pathetic that this made the front page. Nobody even uses
callbacks anymore now that we have Promise and async/await.

Yes, Javascript isn't the best language (though ES6 improves tremendously on
ES5). But right now it's the only language you can use in the browser (aside
from languages like Clojurescript that compile to Javascript). The biggest
advantage of Node.js is that you can reuse the same code on the client and
server, and thus it's ideal for creating universal single-page web apps. Being
able to reuse the same code on the client and server is a massive advantage
that can't be understated.

Also, Node.js with Nginx is more scalable out of the box than Ruby on Rails,
Python/Django, PHP, etc. Hell it's comparable to Java, which is incredible for
a dynamic language. The difference is, you can write a Node.js web application
10x faster than the equivalent application in Java, and with a drastically
smaller codebase (less code = less code to maintain). These days developer
time is the biggest cost.

These rants come off as coming from either (1) back-end developers who never
touch UI code or anything on the client-side (not where Node.js thrives) (2)
armchair commentators who don't actually have to get shit done in terms of
building and deploying web apps on deadlines, and thus have the luxury of
criticizing everything without presenting realistic alternatives.

> "There are only two kinds of languages: the ones people complain about and
> the ones nobody uses." -Bjarne Stroustrup

~~~
imagist
> he biggest advantage of Node.js is that you can reuse the same code on the
> client and server, and thus it's ideal for creating universal single-page
> web apps. Being able to reuse the same code on the client and server is a
> massive advantage that can't be understated.

This advantage is totally overblown, and in fact I am not sure it even is an
advantage. It definitely makes things easier in the short run, but it always
comes around to bite you in the ass. The fact is, objects on the server and
objects on the client are different things, and while you write less code up-
front because the differences aren't always immediately obvious, you end up
writing a lot more code later because you didn't think about the very
important differences. Representing them as the same thing enables shoddy
programmers to not think about the context of where their code will be run.

> "There are only two kinds of languages: the ones people complain about and
> the ones nobody uses." -Bjarne Stroustrup

"[A] quotation is a handy thing to have about, saving one the trouble of
thinking for oneself, always a laborious business." \-- A. A. Milne

~~~
JDiculous
I'm guessing you've never written a universal/isomorphic single-page
application?

If you try to write one without Node.js, you're going to be writing a lot of
the same code twice - once in Javascript to run on the client-side, and twice
to run the same exact logic on the server-side (eg. fetching data on the
server to pre-render a page and parsing that data, making an AJAX call for the
same data on the client and parsing that data in JS).

One codebase is easier to maintain than two codebases in two different
languages.

~~~
imagist
> I'm guessing you've never written a universal/isomorphic single-page
> application?

You guessed wrong.

> If you try to write one without Node.js, you're going to be writing a lot of
> the same code twice - once in Javascript to run on the client-side, and
> twice to run the same exact logic on the server-side (eg. fetching data on
> the server to pre-render a page and parsing that data, making an AJAX call
> for the same data on the client and parsing that data in JS).

> One codebase is easier to maintain than two codebases in two different
> languages.

Sure, until you realize that they _aren 't_ the same objects, because context
matters. But then it's too late because you've so fundamentally coupled the
front-end to the back-end that they're inseparable. So you throw in ifs and
switches to handle the difference, and eventually your code becomes an
unmaintainable mess, and you can't get time from your boss to clean it up
because deadlines.

So you quit and get a new job and starting that new project with Node is so
easy, and you don't see the problem because you never stick around to actually
maintain your code. Your previous business will go out of business when they
try to rewrite the app because development has ground to a halt, but that's
not your problem, now is it?

~~~
JDiculous
In my experience, having to write the same code twice in two different
languages is a hell of a lot more work both from a creation and maintenance
perspective than just writing it once. I haven't really had to deal with many
of those edge cases you're talking about.

So what do you prefer to Node.js for universal single-page apps then?

~~~
imagist
> In my experience, having to write the same code twice in two different
> languages is a hell of a lot more work both from a creation and maintenance
> perspective than just writing it once. I haven't really had to deal with
> many of those edge cases you're talking about.

Cool, I hope for your sake that your luck continues.

> So what do you prefer to Node.js for universal single-page apps then?

To be honest, I prefer not to write single-page apps, as they break some
fundamental ways the internet works, with no real benefit. I have started
using React for in-page responsive components, which are composable and
reusable independent of the app.

I prefer Flask for the backend, although I've used Django w/ Django Rest
Framework and that has also been a good experience.

------
sebringj
The number one issue I've found with Node.js is when developers make things
overly complicated for no apparent reason. The bar may be too low to get in so
possibly you'll get a higher degree of poor design decisions.

The second would be the overuse of build scripts in that the build seems more
complicated than the app in both time to get the thing up and complicated
chaining steps. I've not had much fun debugging grunt, gulp or webpack in some
of these fortune 1000 projects and I have a hard time wanting to give a shit
about knowing them in great detail as the app should be the focus.

The parts of node that I most like are the core libraries that come with the
install. When I try to stick with those as much as possible rather than using
some half-baked npm module for every whim, I have a very pleasurable
experience.

The async/wait and promises, etc along with piping streams are quite elegant
in how modules can be snapped together like lego pieces but I find that people
fuck it up terribly when they half know it as I initially did and it becomes
akin to the messiness of es5 callbacks.

It does take some time to really utilize async well so I would recommend to
read up on those concepts in great detail prior to jumping in.

Please npm responsibly.

~~~
nodenope
Everything in node is just slapped together with no rhyme or reason. npm
module quality is piss poor - even the flagship express web server where
nothing works out of the box. God help you if you find a bug in a node core
library - the typical reaction is that developers now depend on the buggy
behavior and as result it won't be fixed. I've returned to sane programming
languages after using node for years and I don't miss node's async nonsense
where you can't perform a computation without halting all users of your
application without performing major programming gymnastics.

~~~
sebringj
That comment reminds me of those informercials where people can't open a
carton of milk without pouring it all over themselves so they need some fan
dangled gadget for $19.95 to help them do it. Node has many issues but for me
its just really easy to use, maybe because I only use it in a minimal sense,
similar to lambda scale as you can see on my sebringj github repos.

------
imagist
It's telling that none of the posts defending Node.js are talking about it's
technical merits. They're all saying:

1\. Attacks on people--you're being too negative, you're saying this to feel
superior.

2\. Choosing Node.js is a tradeoff! We can't really say what you get in
exchange for using this crappy ecosystem, but "tradeoff" sounds good even if
you're trading using a reasonable ecosystem for nothing.

If you really think Node.js isn't a flaming pile of crap, I challenge you to
come up with something it does that isn't done far better in another
ecosystem.

~~~
geofft
> I challenge you to come up with something it does that isn't done far better
> in another ecosystem.

A single, standard event loop that literally every library in the ecosystem
uses so you don't have to worry about it.

The other options are compiled languages (Windows message pump, Qt or GTK+
event loop, etc.), which aren't what people seem to want for Node's use case,
or things like Twisted. For all of those options other than maybe Windows, you
don't get to assume that the entire ecosystem speaks the same event loop
protocol. And I don't think any of these options do it _far_ better than Node
does. Twisted is pretty good, probably a little better, but Node is just fine
too.

Note that I am not a Node.js programmer. I can kind of work with existing apps
in Node because I can kind of write JS sometimes (I'm really more of a C
person). I just know what other technologies are good at.

~~~
imagist
> A single, standard event loop that literally every library in the ecosystem
> uses so you don't have to worry about it.

Using an event loop with all the other threading models available out there is
like bringing a knife to a gunfight. I could maybe argue that JavaScript's
event loop isn't as good as other event loops, but while actor models exist,
I'm not sure why we'd even talk about event loops.

~~~
geofft
Actor models don't solve the problem of getting a good-sized ecosystem going.
If you have production-ready actor-model libraries for all the random things I
might want to connect to, great, but I'm not currently aware of such things
existing. (Maybe that's a failure of listening on my part!) If you want to
_develop_ that ecosystem, awesome, and I totally support that.

But I would much rather bring a knife to a gunfight than some totally awesome,
straight-from-the-laboratory gun that's never been tested in combat.

~~~
imagist
> If you have production-ready actor-model libraries for all the random things
> I might want to connect to, great, but I'm not currently aware of such
> things existing.

If you have production-ready event loop libraries for all the random things I
might want to connect to, great, but I'm not currently aware of such things
existing.

Part of the problem with the Node ecosystem is that the bar for "production
ready" is very, very low. For example, _literally nothing_ in NPM is
production ready where security matters, because the package system is
fundamentally insecure. left-pad broke builds everywhere--what if instead of
failing to download, it introduced a backdoor? And even if you assume all the
randos who maintain NPM packages are trustworthy, there's no signature
verification on code, so any of them could have their accounts compromised and
there would be no way to tell. This is the code you want me to run on my
server? Really?

Node has a large ecosystem, but the subset of Node's ecosystem which is
actually quality software is quite small.

> But I would much rather bring a knife to a gunfight than some totally
> awesome, straight-from-the-laboratory gun that's never been tested in
> combat.

Me too, but I'm exceedingly surprised to hear you quote this as a _positive_
of Node.

~~~
geofft
I am not really familiar with how to deploy Node in production, having never
done so, but aren't there relatively easy ways to mirror NPM locally? Or can't
you just check node_modules into version control (possibly a separate branch
or something)?

Honestly if I had to deploy Node in production I'd be inclined to see if I can
just use those Node libraries that are packaged for Debian. I do the same
thing for deploying Python, Perl, C, etc. in production.

~~~
imagist
> I am not really familiar with how to deploy Node in production, having never
> done so,

Maybe don't form uneducated opinions on things you don't have any experience
with, then.

~~~
geofft
I phrased it that way to be polite, but if you're not interested: I know that
these tools exist. I was giving you an opportunity to save face for _your_
uneducated and factually incorrect claims. The left-pad incident broke CI
tools that intentionally referenced public NPM, not competent internal
deployments. It broke incompetent internal deployments, yes, but every other
language ecosystem can be deployed incompetently.

If you're relying on the availability and correctness of a public service for
deployments, whether or not it's signed or allows packages to be removed,
you're doing it wrong. This is as true for NPM as it is for Debian.

~~~
imagist
> I phrased it that way to be polite,

Unless you were just outright lying, not having ever deployed Node in
production isn't just being polite, it's literally admitting you have no
practical knowledge of the technology you're defending.

I can see some value in the feedback of someone who has only worked with Node
3 months or so--newcomer reactions give some impression of the learning curve
of the technology, which matters. But you've done what, read a blog post? Your
opinion on this subject is worthless.

> I know that these tools exist.

As do I, and what's more, I've _used_ those tools.

> I was giving you an opportunity to save face for your uneducated and
> factually incorrect claims.

Which ones were those exactly?

> The left-pad incident broke CI tools that intentionally referenced public
> NPM, not competent internal deployments. It broke incompetent internal
> deployments, yes, but every other language ecosystem can be deployed
> incompetently.

Yes, you can use NPM shrinkwrap (and I do) but let's be clear: that means you
get to devote perhaps a week out of every year updating everything manually.
"Competent" deployments with NPM involve enough of a pain in the ass that,
after a few years of doing this, I'd actually prefer to manually import
dependencies. But that's not really a viable option.

If you're going to claim this is just incompetence, I am inclined to agree
with you. But that means that an inordinate portion of the Node community is
incompetent, so I'm not sure this can be represented as a defense of Node.

> If you're relying on the availability and correctness of a public service
> for deployments, whether or not it's signed or allows packages to be
> removed, you're doing it wrong.

If that's the case, then I don't know of ANYONE who is using NPM correctly,
because to avoid relying on whether or not things are signed, you'd have to
audit literally everything pulled down by NPM, which even for simple projects
can be half a million lines of code. Shrinkwrap means you only have to do it
once, but that's still more time than anyone I know of has.

~~~
geofft
None of this is different in any other language, including C. If you run a C
app that uses outside libraries, or a Python app that uses outside libraries,
or anything else, you either devote well more than a week out of every year to
updating libraries, or everything is super old and frozen and impossible to
change, or everything risks breaking when you upgrade your OS distribution (or
other source of packages). That's how production software works.

If you want to claim that the state-of-the-art in every single environment
isn't production-ready, you're using the term "production-ready" in a very
different way from its common meaning.

Can you present an ecosystem that does this better? All I've heard you claim
is that Node is bad, in ways that are not specific to Node.

~~~
imagist
> None of this is different in any other language, including C.

Really? Because NPM is the only dependency system I know of that doesn't
verify packages in any way.

> If you run a C app that uses outside libraries, or a Python app that uses
> outside libraries, or anything else, you either devote well more than a week
> out of every year to updating libraries, or everything is super old and
> frozen and impossible to change, or everything risks breaking when you
> upgrade your OS distribution (or other source of packages).

This hasn't been my experience. Unlike the Node community, the C community
tends to feel strongly about reverse compatibility. The Python community has
become a bit more diluted in recent years, but as long as you stick with
mature libraries, upgrades are usually no more than updating some version
numbers in the `requirements.txt` and running `pip install -r`. In cases where
Python packages break dependencies, they're usually pretty decent about giving
deprecation warnings.

In NPM, mature libraries break backwards compatibility without warning all the
time, sometimes without even a version number change (by virtue of the
dependency's dependencies).

Can you point me to an example of a mature library in Python breaking like
Babel did when left-pad happened?

> Can you present an ecosystem that does this better? All I've heard you claim
> is that Node is bad, in ways that are not specific to Node.

The ways I mentioned are absolutely specific to Node.

~~~
geofft
> Really? Because NPM is the only dependency system I know of that doesn't
> verify packages in any way.

npm verifies the SSL cert on its connection to the registry. pip does the same
thing. Neither verifies signatures on the packages, or anything else.

Both of which are better than C build scripts that involve downloading
tarballs from SourceForge and running `make install`.

> This hasn't been my experience.

Then you're not running C in production, sorry. Or you're ignoring the
friendly build engineers and distro packagers (like myself) who spend their
days solving these issues so you don't have to notice. Which is great, we
solve these problems so you don't have to, but you really need to defer to the
people with expertise.

> Can you point me to an example of a mature library in Python breaking like
> Babel did when left-pad happened?

Sure. Babel didn't break when left-pad happened. _A certain way of installing
Babel_ did. I have no idea how you keep conflating a method of installing
packages (that isn't even what serious production users use) with code. So,
"all of them."

I can give you countless examples of mature libraries and software packages in
C, Python, or many other languages where `./build.sh` or equivalent, that
wgets some crap from SourceForge, stopped working in the same way. But if
you're doing `./build.sh` as part of your regular production workflow, you
know that it's going to break and that you have better options.

~~~
imagist
> npm verifies the SSL cert on its connection to the registry. pip does the
> same thing. Neither verifies signatures on the packages, or anything else.

The top result from Google:
[https://pypi.python.org/security](https://pypi.python.org/security)

> Both of which are better than C build scripts that involve downloading
> tarballs from SourceForge and running `make install`.

True, but I thought you were the one who wanted to limit our conversation to
competent installations?

> Sure. Babel didn't break when left-pad happened. A certain way of installing
> Babel did. I have no idea how you keep conflating a method of installing
> packages (that isn't even what serious production users use) with code. So,
> "all of them."

Really? So how do you install Babel the first time in order to shrinkwrap it?

> I can give you countless examples of mature libraries and software packages
> in C, Python, or many other languages where `./build.sh` or equivalent, that
> wgets some crap from SourceForge, stopped working in the same way.

Okay, give me countless examples.

~~~
geofft
> The top result from Google:
> [https://pypi.python.org/security](https://pypi.python.org/security)

I'm not sure what this has to do with anything. Yes, you may sign your
uploads. Nobody verifies them on download.

Since you seem to be a fan of Google, try Googling 'pip signature
verification' and reading the results. Here's one place to start:
[https://github.com/pypa/twine/issues/157](https://github.com/pypa/twine/issues/157)

> Really? So how do you install Babel the first time in order to shrinkwrap
> it?

The same way you install anything else from any other ecosystem? The packages
have to be up and online _when you initially retrieve them_ , yes. I have no
idea how you think that's NPM-specific. If you would like to download some
code, you have to have somewhere to download it from.

------
spion
The pot is calling the kettle black.

Its always funny to read something like this coming from proponents of Go. Now
thats a language that threatens to single-handedly bring us back 30 years in
the past. A typed language invented in 2009 lacking generics and algebraic
data types, and being proud of it (or at least its users being proud) - thats
pretty much at the exact same level as JS "reinventing" callback-based async
programming in 2009. And its users were similarly proud of this in 2010-2011.

At least Brendan Eich is modest enough to apologise for JavaScript's flaws and
push as much as possible for fixes without backward compatibility breakage of
the web.

~~~
geodel
How can one language not even in top 10 bring us back 30 years? Has it been
made compulsory to be used by developers?

~~~
pswilson14
Not OP, and I don't have an opinion on Go, but I think that's why he used the
words "threatens to".

------
lootsauce
There is an easy sense of superiority that comes with derision of "X" and the
authoritative sounding romanticization of idealized "Y" seemingly adds weight
to the argument. Clearly these "Y" people are smarter and better than all
those "X" people.

Look at all this horrible code! So sad that all these people are not as smart
as me. Look at this horrible language! So sad the people that created it are
not as intelligent as me!

Really? There is no more "problem" with Node.js than there is a "problem" with
any other platform. There is no more problem with JavaScript/ES-(name your
flavor) than there is with any programming language. Different languages are
different. Different platforms are different. Of course every system has its
own problems. Sometimes people who appreciate them call these "tradeoffs" or
the superior types call them idiotic.

The cliche´ of hacker news haters is really really really getting old. So here
are some things that are actually good.

As much of a pile of hot steaming code as it is, Babel as an idea (AKA
transpiling one language to another) is pretty cool. Of course you can do this
in other places but its featuring prominently in the JS community leading to
an interesting result. The language and its features become configurable, easy
to adapt and change and evolve over time and suit to your liking. This is
interesting!

Finally as opposed to what others may have said about the community being
childish I have found the opposite. I find it to be very welcoming and
supportive, friendly and honestly creative. Of course there are lots of
negatives, lots of horrible code, lots of mistakes happening. But what is
missed in all of this? Theres A LOT of stuff happening that is good even
great! It's beautiful chaos! So go on hating, but I see lots of great stuff
out there. As one great systems and iOS developer told me the other day "Have
you tried Express? Its awesome!" HA yeah. But he just tried it, and loves it!

Oh but look at that callback YUCK! Cmon

~~~
fauigerzigerk
No, I think criticism is a good thing. Rants are good. They highlight issues
with our current tools and over time that's what leads to progress. Using a
plow isn't just different from digging in the dirt with a stick. It's better.

For instance, nulls are clearly a problem. After countless rants we're seeing
languages that have better ways to deal with missing or optional values enter
the mainstream (Swift, Scala, Rust).

J2EE's original idea to configure a system through separate XML files was
heavily criticised for being too bureaucratic. After countless rants we got
configuration by convention, better defaults and annotations as part of the
source language.

Of course progress is not a straight line and quite often it's not clear what
is and isn't progress because there are many trade-offs. But where would we be
without a constant process of criticising our tools?

~~~
gravypod
> For instance, nulls are clearly a problem. After countless rants we're
> seeing languages that have better ways to deal with missing or optional
> values enter the mainstream (Swift, Scala, Rust).

No they are not. They are a state of an object. What is the problem is a lack
of documentation.

One thing I've seen coming up, at least in some code I've looked at, is the
@Nullable and I've not seen any complaining about null from those who use this
tag.

The idea is to always document when a variable or type can be null. This way
you know, with 100% certainty (given a strict type system adherence) that
you're not going to erroneously see a null object where it isn't expected.

From this, you have a huge benefit: a performant error state or a better
method of representing an issue without throwing an exception.

Riddle me this, how would a Map be implemented if Null was stripped from Java?
Should it throw an exception if a key is not found? If that is the case, then
you should always need to check for this exception, otherwise you're prone to
bugs. You've also increased the execution time of your code by in some a huge
performance hit [0] that is more cumbersome.

This is why I think rants are a big problem. They don't describe the
opposition to a statement accurately. They are one person's opinions and after
reading them, if it all sounds nice, you're usually willing to take it all as
fact. "Hey, they're writing an article! They must be smarter then me. I'll
take their word for it." As a result, our communities don't really evolve we
just spew memes back and fourth dictating what someone else thought.

What really matters, in every sense, is reading a discussion had between two
experts in opposing camps. That way you can see both sides of the arguments,
their weak points, and make an educated choice on what side to agree with.

That being said, what do you think of my points? Can you address them? My
oppinion is that NPEs can be easily avoided by using very simple measures AND
null more closely resembles most problems while being more performant and less
cumbersome then throwing exceptions willy nilly. I'd love to hear how you feel
about this.

Also...

> J2EE's original idea to configure a system through separate XML files was
> heavily criticised for being too bureaucratic. After countless rants we got
> configuration by convention, better defaults and annotations as part of the
> source language.

I'd say that is a good example of discussion, brain storming, and coming up
with a much more accurate representation of the ideas we are trying to convey
(the use of annotations to configure methods).

[0] - [http://stackoverflow.com/a/299315](http://stackoverflow.com/a/299315)

~~~
galdosdi
> Riddle me this, how would a Map be implemented if Null was stripped from
> Java?

Obviously you would use an Optional<T> (for a Map<K,T>)

See
[https://docs.oracle.com/javase/8/docs/api/java/util/Optional...](https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html)

~~~
Roboprog
Which would have been a _great_ idea if it had been in Java 1.0 :-(

Alas, the horse has left the barn.

Much like immutability: if it had been the default, with a "DANGER: mutation
ahead" keyword required otherwise, that would arguably have been good. But
it's too late, now. (Java) Beans, beans, the magical fruit...

~~~
galdosdi
Yeah, it's a bummer dealing with backwards compatibility. Don't get me started
on guava Optional vs JDK8 Optional.

But at least you can stick to just using Optional and no nulls in new code you
write, and only using nullables to communicate with existing libraries.

------
jondubois
I don't see anything wrong with Node's approach to concurrency. It uses IPC
which is much more scalable than threads and mutexes. Also, you don't have to
use callbacks anymore, now we have Promises and there are tons of libraries
that allow you to do reactive programming so you can just wire-up streams of
data together in complex sequences.

This article is just inflammatory and illogical.

I think Node.js is one of the best backend engines which was ever created -
And I've programmed in everything including AVR Assembly Python, PHP, C#,
C/C++, Java and many others. I like Node.js the most.

And yes, you're right, the Node.js community isn't a 'proud' community - We're
more interested in constantly improving than sitting there being satisfied
with ourselves whilst bashing other tools.

There is no perfect tool/stack; they all have pros and cons. It's all about
personal preferences.

~~~
signa11
> I don't see anything wrong with Node's approach to concurrency.

to me, erlang's model seems to be the best one that is around. without a
runtime scheduler, message boxes + selective receive etc., i don't really
think it is possible to do justice to the whole csp thingy.

you can have approximations to it, but that doesn't go very far.

for example, in erlang, i can start processes etc. and have them run
essentially

    
    
        while(1) {
            
        }
    

and nothing really bad happens to other concurrently running threads.

------
wyqydsyq
All the points in the first (Uriel) rant are attacking JavaScript itself, and
most if not all those points are remedied by using ES2015 and FRP.

All the points in the second (Ryan) rant are attacking bloated/poorly-scoped
software and abstractions, and none of the points (except mentioning
$NODE_PATH) have any relevance at all to Node.js.

So really none of this is relevant to Node.js (or JavaScript) being inherently
bad, it's just pointing out that people can use it for bad things, which is no
different to any other language or runtime.

~~~
a_j_s
you are absolutely right this is a click bait post that should be down-voted.

------
ralusek
"The async-style of programming is almost entirely inaccessible to my brain"

Proceeds to write article shitting on language which relies on this.

~~~
PeCaN
More like “the world's worst implementation of asynchronous programming is
shitty and didn't learn from its predecessors”.

------
bryanrasmussen
I am certainly willing to entertain the notion that async models do not map
naturally to most peoples' brains and as a consequence the callback style of
concurrency might just be really difficult to handle. On the other hand the
writer admits it may just be them not being able to understand it, which I
think is also reasonable given that many people have managed to do more
complicated stuff in much less than 2 months.

This post is a land of contrasts, in short.

~~~
catnaroek
You can interpret the question of whether an abstraction “map naturally to
most people's brains” in two different ways:

(0) Is it easy to understand how the abstraction works in principle?

(1) Is it easy to actually use the abstraction to build large robust systems?

Clearly, (0) is a necessary precondition for (1). But it's not sufficient.
Pointer arithmetic is an example of an abstraction that's easy to understand
“in principle”, yet hard to use right (for “most people”, anyway). I'm afraid
the same is true of explicit continuation (“callback”) passing. Programming
with tools that only work “in principle” is hell.

~~~
aangjie
Not sure, why this is getting downvoted.. It's very sensible and the poster
provides a valid example.

------
moonshinefe
"processes orchestrated with C. It’s a beautiful idea."

That's all well and good until programmers don't know how to manually manage
their memory properly or use pointers and it creates massive security holes
and bugs in general. Which is unfortunately very, very often.

Apparently this guy disagrees and that's fine, but in my experience he's wrong
to bash complexity and praise C. I've read many large C projects' code, and
it's about as complicated / messy as it gets.

Some good points in the article other than that.

------
yoshuaw
Here's the post by Ry that was supposedly deleted:
[http://tinyclouds.org/rant.html](http://tinyclouds.org/rant.html)

The point I took away from the post is that all abstractions carry a cost, no
matter how elegant. Not "Ryan Dahl hates Node.js". But sure.

Seems the author is intent on complaining and that's cool with me, but if
you're doing Node then yeah don't let people like this get you down. Node's
fast, Node's flexible and has so many users that virtually any abstraction you
like is available through npm. Callbacks are part of core because it's the
lowest common abstraction for Async. Node is not Python.

Tired devs can complain all they like, but that doesn't make them right.

~~~
oolongCat
>Tired devs can complain all they like, but that doesn't make them right.

But don't you think this is the very reason why we need to worry about these
issues. Us developers are tired, its not right, this is something we all love
doing, and I want more people to love this industry and we cant afford to
throw simplicity in the garbage, we need to spend some effort in to making
things easier for the people who will come after us.

~~~
sotojuan
If you're gonna fall of the cat-v bait and try to "make things right" then you
pretty much can't use any language except minimal C or Go. Their page on Java
(what people in this thread propose) is way longer.

------
partycoder
JavaScript in Web browsers has a lot of sandboxing (i.e: babyproofing). Node
on the other side doesn't. If you are an experienced developer, chances are
you won't do something lousy like coding by trial and error and playing with
concepts you don't understand and copying and pasting from StackOverflow.

If you follow the golden rule of not touching anything you don't understand,
you should be in a safe spot. But that's not the culture in the node
community. The node community is all about sharing lousy snippets of code
without error handling, without input validation, and without any regard for
any non-functional requirement in poorly written blogs and npm. A community of
excessive optimism and irrational risk taking.

Floating point numbers, for instance. Every number in JavaScript is a floating
point number, and 99% of node developers don't understand a basic thing like
how to compare 2 floating point numbers. And that's just the basics... let's
not even discuss concurrency, parallelism, how to deal with files, memory,
I/O...

~~~
wwalser
Is this advocacy for safer development environments or just mud slinging at
the Node community? You called a critical security layer that protects
literally billions of users every day "babyproofing". No only Javascript but
most features of web browsers are sandboxed as well, is that babyproofing or
smart(prudent?) design?

Infantilizing programming communities. I'm ready to move on from this drivel.
People make choices based on their contexts and while some large amount of
those contexts differ only slightly from my own, I find it impossibly
difficult to pass judgement on those who have made different decisions than
me.

~~~
partycoder
I said very clearly that node.js is a serious technology, and so are web
browsers. The problem is that the community at a large and companies today
have been influenced by a mindset that does work in sandboxed environments but
not in actual server-side software.

~~~
supernovae
This could be said about everything.

BUT, lets be real. Operations people love Node because i can run 100
containers of a node app behind a load balancer. If a single node app dies the
orchestration system re-starts it. If developed well you have a
reporting/analytics/metrics platform and tracing tool that allows you to
capture failures, fix them and deploy new code.

I'd wager that for the majority of the world, no matter the language used,
most people are implementing patterns/behaviors because that is what they need
to do something. Very rarely do people create something / invent something
novel thus the level of developer abilities you seem to project don't need to
be the standard abilities and that is ok.

------
jtolmar
So what do people use as a server these days?

All I want is to annotate some function calls with paths and have something
handle http requests and mangle the input and output into json for me.
Preferably in a boring safe language. Preferably in Java, the boringest safest
language.

If I have to call a method on a provided object instead of returning in the
name of async, great, that's fine too.

~~~
angryasian
Take a look at spring boot - [http://projects.spring.io/spring-
boot/](http://projects.spring.io/spring-boot/)

its incredibly easy these days to do what you're suggesting in Java

~~~
ganeshkrishnan
And if you want to add icing to the cake I suggest Jhipster. It has made my
life considerably easy with it's angular JS support and spring boot /JSON/ API
support.

I could create an e-commerce website
[http://www.haggell.com](http://www.haggell.com) in a space of month using
jhipster & angular.

------
coldtea
What those repeating "async is good" don't seem to get is that we have had
better ways to do async than what Node.js offers for decades.

Better as in, all of: faster, easier to reason about, better implemented, more
robust.

Erlang is but one example.

------
soupdujour
I don't understand why people think node doesn't scale or that you need to use
something else when it's time to "get serious". I can't get into specifics,
but I recently worked on an app for a rather large company that had 10s of
millions of daily users. The app written in node needed 3x fewer cpus than a
java app running in the same system and they were performing similar tasks
with almost identical usage. The team maintaining the node app was also 4x
smaller than the team maintaining the java app.

The main difference was that the node app was thoughtfully architected and
written and the java app was not. It didn't have anything to do with language
or tooling. It had to do with good software engineering.

------
Ericson2314
I dislike shitty languages and successfully avoid using them myself, but I do
have to be a bit happy with NPM ecosystem teaching people to reuse more code.

~~~
wvenable
I think NPM has finally shown that you can, in fact, have too much code reuse.
The representative example for me is this actual isPositiveInteger module:

    
    
      var passAll = require('101/pass-all')
      var isPositive = require('is-positive')
      var isInteger = require('is-integer')
      module.exports = passAll(isPositive, isInteger)
    

You don't even want to know what the is-positive and is-integer modules look
like.

Software pundits have been saying how modern programming is just wiring
together existing components for years; the node ecosystem has taken that to
its illogical extreme.

~~~
wyqydsyq
The thing is, nobody is forcing you to use excessively small modules.

If you use an excessive amount of small modules, that's an error of the
developer, not an inherent flaw in the platform/ecosystem.

~~~
ramchip
My app does not use small modules... but its dependencies do, and the
dependencies' dependencies, so in the end my node_modules folder has hundreds
of packages and everything compiles slow like molasses :(

~~~
iends
Compiles?

------
agentultra
The _worst_ thing is a gross exaggeration. I've been guilty of these at times.
It seems common. You have to be a very passionate person to care deeply enough
to master programming. These are infuriating machines operating in the domain
of discrete maths... one error and the entire building comes down.

That being said sometimes, when there's no one else you can kvetch with, a
good rant is just what you need. Computers are stupid. Programming is
horrible. Everything is terrible.

But Node.js is hardly the worst thing. Some perspective is required.

------
tgarma1234
Well I am by no means a great computer programmer or anything so I can certain
accept other people saying node is crap but as someone who has used node my
reasoning was simple: if you are going to use javascript in the browser and
pretty much everything about the "app" depends on what happens in the browser
then why use some other language on the server for models and controllers with
javascript in the views? Why not just make it javascript all the way down?

Sure, smarter people than me might know why I shouldn't use javascript for
everything but for me I do not find it useful to try to figure out how to do
so much work in Rails or Django AND THEN ALSO end up using javascript in the
views every time anyway. I would rather skip using Rails or Django and just
get to the fun part of figuring out what happens next when this button is
clicked on the website. I don't think I am alone in that. Rails and Django
were a means to an end but they set the bar too high in terms of "programming"
and require a lot of programming knowledge that I don't actually need to know
to do what I want to do now with node. Sure, my code might suck but unless you
are working in some super professional environment with highly skilled
managers, pretty much everyone's code sucks. It's about getting the
functionality you want with the least amount of effort. Node makes that
possible.

~~~
davidgrenier
You do everything you can to use something other than JavaScript in the
browser.

The list of good languages that targets the browser is long, the last of bad
languages better than javascript that targets the browser is even longer.

I personally used WebSharper and it's excellent. All these sophisticated
frameworks (thinking Angular foremost) have nothing on WebSharper.

------
zumu
> As soon as I wanted to write any non-trivial code to read stuff from a
> database and do something with it, I got stumped - I didn’t know how to
> proceed. I could write some code, but it would turn out very ugly. I
> couldn’t write code that was pleasing to read (and it certainly wasn’t
> pleasant to write).

When this was written, he had point, but with es6 I don't think this is a
problem anymore.

Accordingly, I don't think this stands

> You lose expressiveness

Arrow functions and destructuring cut down on boiler plate significantly.

------
k__
What I find interesting is, that everyone has rather hard feelings for any
language but Python.

There seem only 2 things people complain about Python, performance and the two
major versions out there.

Overall I have the feeling most devs thing it's pretty okay.

~~~
detaro
Package management is another typical complaint. Admittedly it's a complaint
in nearly every language that has packaging tools.

------
aaronpk
Great line: "The only thing that matters in software is the experience of the
user."

~~~
dschiptsov
This is exactly how you get professionally marketed crap like Mongo, Node,
Hadoop, you name it.

It is a fast-food way of building software - cheapest processed shit wrapped
in a good SEO and naive user experience (quick and rewarding installation and
effortless bootstrapping of a meaningless hello-world - I am so clever meme).

What matters in software in the long run, be it an application or even a
programming language, is appropriate design decisions and strong emphasis on
design around protocols (by duck-typed interfaces), using declarative (instead
of imperative) mostly-functioal paradigm, bottom-up process with focus on
modularity and code reuse, while sticking to the standard idioms and principle
of less astonishment. This is what is still being taught at MIT, and this is
how the internet works as a whole.

99% of Node or PHP code is a toxic amateurish crap, precisely due to ignorant
over-confidence of the coders and lacking of proper CS education about right
principles and programming paradigms, importance of louse coupling and proper
encapsulation, which leads to modular, share-nothing, mostly functional
designs with emphasis on immutability and persistence (that's why Clojure is
so good - it has been, like Erlang, well-researched with tons of good stuff
borrowed form Common Lisp).

Erlang or Haskell or Scala or Swift or Golang are on another side of the
spectrum, which could be characterized by discipline of sticking to the right
principles and rigorous attention to details (of which Haskell might be a bit
too strict, but Erlang or Scala just right).

BTW, these observations about the impact of a proper design, based on right
principles, which have been made almost 20 years ago still holds -
[http://norvig.com/java-lisp.html](http://norvig.com/java-lisp.html) Today we
could state the same for Python3.5+, which, finally, evolved to be so
carefully refined as old school Lisps, but emphasizing that Python3 is _a
prototyping language_ , while CL is _both_ prototyping and implementation
language.

No sane person should even touch PHP or Javascript or any other crap with
implicit coercions, error supressions, etc, designed by amateurs (hello,
MySQL, Mongo, Hadoop!) like one avoid chap processed junk food or drugs.

~~~
ex_amazon_sde
> ignorant over-confidence

Believe me or not, Node and PHP are the laughing stock across many Googlers
and Amazonians I know. Not just the languages but the behavior of the
communities. I think you just summarized the problem in few words.

------
tim9009
"The only thing that matters in software is the experience of the user." "if
you add unnecessary hierarchies in your code directories, if you are doing
anything beyond just solving the problem - you don’t understand how fucked the
whole thing is."

Oh really? So making the code easily maintainable and easy to comprehend is
just a waste of time and simply ads complexity? Comments like that makes this
hard to take seriously.

------
kabes
The article is not very relevant in 2016. Much of the arguments are not valid
anymore.

------
aaronbrethorst
Quasi-related, one of my favorite programming language essays of all time:
[https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
design/](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)

From what I've observed, I feel like Node is where hipsters who decided that
PHP was "icky" ended up.

~~~
louhike
I would like to read what is your definition of "hipster". It's used for
everything nowadays and mostly to describe negatively people someone do not
like.

------
mcs_
》There will come a point where the accumulated complexity of our existing
systems is greater than the complexity of creating a new one. When that
happens all of this shit will be trashed.

I think it applies to bank system, politics, and more in general to anything
that can be improved and where there are enough money to think about re-
design. At that point yes, another life cycle will starts.

------
everydaypanos
Node.js solves the problem of "live webpages" w/ Websockets and Polling and
chat apps and notifications etcetc.

And that counts. A lot.

~~~
6nf
> Websockets and Polling

Those have nothing to do with Node, you can implement them with just about any
server-side stack.

------
Anagmate
I feel like a large part of the negativity around Node.js comes from the
callback hell and almost everything being async.

Solution to these two problems (an ingenious one I think) is async/await (and
there is an awesome polyfill on npm) - if you want, you can enclose your whole
code in one async block and effectively make everything synchronous. Or you
use it to its full potential and remain synchronous in all parts of the code
that need it while retaining the benefits of async (other parts of code can
run while the current one is waiting for a result.

The only caveat I've encourtered (a manageable one, at least for me) is that
you must keep in mind that the underlying code IS async, so you can only
guarantee synchronous behaviour in the single asynced block od code - so
sometimes, race conditions could happen between some parts of your program,
but with proper scoping (and ideally, using pure functions), you can avoid it
all together.

------
punnerud
NASA is using Node.js for its Mission Control Framework
[https://nasa.github.io/openmct/](https://nasa.github.io/openmct/)
[https://github.com/nasa/openmct](https://github.com/nasa/openmct)

~~~
1_listerine_pls
It's a Non-technical argument in a technical discussion.

Is a framework necessarily better/good because it was picked by the SE team at
a large company?

------
lllorddino
> better alternatives around with much more sound models and environments,
> Erlang and Go

Node.js makes it extremely fast to build robust and fully featured web apps
quickly. I'm using Go currently for the backend and it's a pain since
everything has to be written from scratch. I still enjoy it since the language
is simple.

------
arisAlexis
This whole thread would not exist when async await gets traction

~~~
Rapzid
There will be new threads about how the streams and other standard classes
dealing with IO need to be rewritten/expanded to work well with async. I've
been using async/await for about a year now(in node.js, much longer in C#) and
took to wrapping them when needed; you find various levels of difficulty
depending on how much eventing is involved. All the information hidden away in
non-public properties/api's doesn't help. MS had to go through and expand out
all their stuff with Async methods. I wonder how long the node.js maintainers
will take..

Async/await, let, and TypeScript have made node.js bearable for me but, TBH,
I'd rather be working with Go or C# more. Owell, right tool for the job and
all which has a temporal component as well.

~~~
arisAlexis
You don't need o wrap anything promise based and curretly all major libs
deliver promises

~~~
elmigranto
He talks about events.

------
tflinton
I've done a fair amount of messing around with javascript.

1\. Recompiled webkit into javascript using emscripten/asm.js (webkit.js) 2\.
Created a desktop version of node (tint2) using FFI calls for OSX/Windows 3\.
Reconstructed much of the oracle o5login/tns/tti protocol for giggles (and if
you want to see a very head scratching way of packing 64 bit signed ints, look
no further than 11g).

What I can say is it isn't perfect. But it has one gigantic advantage is you
don't need to build or compile to run, but still get nearly the same
performance from compile time languages.

It's a near perfect prototyping language, and for most peoples use (e.g., 99%
of crud/general business humdrum logic) it's perfectly fine.

Just stay away from relying on too many npm modules.

------
rv11
I see a lot of desktop apps made from electron/CEF using Node. examples are
Brackets and Steam.

------
api
Meh. It works. Npm is okay if you exercise quality control over what packages
you use and keep dependencies down. The language is decently productive for
scripting and everyone knows it so it's easy to find maintainers. It performs
well and can be multithreaded just fine by running many concurrent node
workers and using a good database and cache.

Go may be better but has a less rich ecosystem of turn key solutions and easy
integrations. Java is a decent language but has an outdated ecosystem. .NET
going OSS is interesting.

Ultimately what you do with languages and tools is more important than which
ones you use.

------
_c_
From Rob Pike quote at the end, after the Ryan Dahl quote: "... the
UNIX/POSIX/Linux systems of today are messier, clumsier and more complex than
the systems the original UNIX was designed to replace."

"Messier, clumsier and more complex" are adjectives that could describe almost
all of today's software vis a vis software from the 1970's. This is not a
criticism of today's software it is just the evolution (or devolution) as it
happened, an objective observation.

By and large, programmers do not attempt to make software more clean, more
efficient or less complex. Most do not spen all their time cleaning up messy
code, fixing bugs, or sacraficing inefficiency at the expense of usability or
abundance of "features". And almost none spend time removing code and reducing
complexity.

They do the opposite: add features, pursue "ease of use" at the expense of
common sense and _incessantly_ generate and commit code believing that any
decline in commits or "software updates" signals a project is "dead", not
"modern" and probably in need of a "replacement". Again, I'm not critiquing
this, I am just stating the facts. This is what they do.

Not sure about Pike, but the reason I think some older software is higher
quality than most newer software is not because it was or is high quality in
an objective sense. It's because today's software is so low in quality and in
too many cases worse than yesterday's. Indeed, it's "messier, clumsier and
more complex."

In an objective sense, 1970's UNIX is nothing to celebrate. But compared to
the then-alternatives, what came afterwards, and what we use today, it can be
held in high regard. It's only good in a relative sense. Everything else was
and still is so bad. (Why is anyone's guess.)

 _Avoiding the hassles_ Dahl alludes to[1] brings me a certain feeling of
satisfaction. My language of choice is Bourne shell. And if I am just working
with text, such as reading and writing, I do not use a graphics layer - no
X11.

The question is: Does Pike's comment apply to Plan 9?

1\. Not to mention avoiding the needless complexity and obscurity of Microsoft
Windows.

------
diegoperini
Facts are nouns, adjectives are subjective. A subjective analysis is hard to
trust. I hate Java, because I choose to do so. Java being a bad language
cannot be proven by my personal opinion. People do amazing things with it,
Minecraft was initially Java, Android apps run on JVM etc etc.

This article has more than 10 adjectives (many have adverbs attached to them
or written like "... much more sane and reasonable language like Python ...")
in its first five sentences. Thanks for the effort but no, I cannot trust any
of it.

~~~
klodolph
That's a weird metric. "Java is an abomination" uses nouns but is entirely
subjective, "Java is class-based and garbage-collected" uses adjectives and is
objectively true.

~~~
diegoperini
I'd try to save my argument here but I know I'll fail hard. Let's try :)

"Abomination" implies disgust, so your example can be paraphrased as "Java is
disgusting.".

To fail harder, let's paraphrase further.

"Java programs are built with classes and collect their garbage."

At least I've tried. My own comment actually has adjectives too (like
"subjective") but this is getting too meta.

------
cdevs
I used "callbacks" when needed in objective-C in my app days and got sh#t done
just fine. I think the best thing to come from node is the ability for a
younger crowd to jump into proton/electron desktop apps without needing to get
into sdl, qt, or some platform specific language like objective c or the .net
C# whatever family. Nose might not be the finally language to take us to that
area but it's a start and a ton of awesome open source apps came out of the
scene quickly.

~~~
pjmlp
I think that bloated piece of software is one of the worst things to happen.

~~~
tflinton
Then try tint
[https://github.com/trueinteractions/tint2](https://github.com/trueinteractions/tint2)

~~~
pjmlp
I only use JavaScript on the browser, there are so much better alternatives
outside of it.

------
Roboprog
Async I/O -

CON: I hate having to set up callbacks (even with promise syntactic sugar),
whether I need them or not. But of course I _do_ need them when I am coding a
U/I.

PRO: the "promise-all" trick is pretty useful if you have several queries that
all need to be completed before you can continue with their results. I have
some Java code that might benefit from this since it does several queries to
generate a PDF. (then again, caching might make this moot - YMMV)

------
supergetting
I embrace change in life in general, such a view translates over to the
complex ecosystems in technologies, I embrace and accept the complexity of
every single technology, honestly it is quite amazing. It's good that we try
abstracting away many things and make them more simple and less complex, but
sometimes inevitably leads to more complexity and more shit, and I like it and
it's fun to be part of such journey!

------
progrocks9
NodeJS works great as a simple web or network container, if you're trying to
create a complex enterprise app in Node, basically you're doing it wrong.
Simply it's difficult to design complex nested logic or algorithms in a clean
manner. It's possible but it's harder than other languages.

------
annasaru
J2EE is up there.. We have a generation of corporate Java programmers who love
boilerplate code and obfuscation.

High-School teachers inflicting Java on teens - cringe-worthy. Many public
schools only offered Java if you elected programming/CS (in High School). Only
recently has Python made inroads.

------
SimeVidas
4 years old?

------
tim9009
"The only thing that matters in software is the experience of the user." "if
you add unnecessary hierarchies in your code directories, if you are doing
anything beyond just solving the problem - you don’t understand how fucked the
whole thing is."

Oh really? So making the code easily maintainable and easy to understand is
just a waste of time? Comments like that makes it hard to take the rest of
what he says seriously.

------
andrewstuart
I rather like JavaScript. ES2015 anyway.

------
Jean-Philipe
Uriel didn't quite explain why PHP is any better than nodejs. I'd be even
interested to hear!

~~~
SixSigma
You're too late. He suicided.

------
narendraj9
Cannot access the site.

------
neelkadia
Can you make it good?

------
phazelift
Unbelievable, so many up votes for this complete idiot statement..

------
Wei-1
cannot agree more, but we still use it.

------
ComodoHacker
TL;DR:

>I hate almost all software.

------
YeGoblynQueenne
So, this is totally an ad hominem but the OP webpage has a post category
titled "Political Correctness" [1] with one post titled "Claims that sexisim
drives girls away from Computer Science are feminist bullshit." [2] and one
link to an external site titled "Sex Differences in Mathematical Aptitude - By
La Griffe du Lion." (a.k.a. "Lion's Claw") [3] starting off with this bit,
styled like a research paper abstract (you know, to make it look seintifikal):

 _Mathematics is a man 's game. A gender gap appears early in life, blossoms
with the onset of puberty and reaches full bloom by mid-adolescence. It
indelibly shapes women's prospects for doing significant mathematics. In this
account of cognitive sex differences, Prodigy shows how sex-differentiated
ability in 15 year-olds accounts for the exiguous female representation at the
highest levels of mathematical research. A female Fields Medalist is predicted
to surface once every 103 years._

I stress again that this is essentially an ad homimem: I'm absolutely flagging
up this dude as a sexist baboon with brains the size of a small, frozen pea.
And because I have much better things to do with my poor feminine brain (say,
finish off my MSc dissertation, on a novel grammar induction algorithm) I'm
not reading a single word of the OP.

________________________________

[1] [http://harmful.cat-v.org/political-
correctness/](http://harmful.cat-v.org/political-correctness/)

[2] [http://harmful.cat-v.org/political-correctness/girls-in-
CS](http://harmful.cat-v.org/political-correctness/girls-in-CS)

[3]
[http://www.lagriffedulion.f2s.com/math.htm](http://www.lagriffedulion.f2s.com/math.htm)

~~~
staticelf
Not that I agree with this persons opinions at large, I do recognize that he
got some points. Perhaps he may be a bit sexist but so are most people and
feminists at large are extremely sexist at large in my opinion.

A quote from the second link:

"The whole issue is being overcompensated now. On some technical forum I’ve
seen somebody ask for advice on whatever. Another user replied with a link to
women.debian.org. What the fuck? Do we have “men.debian.org”? If you’re no
different wrt. technical matters, then you need no different website. If you
need different treatment, then don’t be surprised if you’re treated
differently."

Couldn't agree more on that point and matter, I do think we should treat each
other with respect and integrity but why treat people differently because of
their gender? Can't we just treat everyone the same?

Honestly, that is not what society is doing and especially not so in the IT
sector. I think this is one of the points the OP is making with his post. Just
because he has these views does not necessary render his views on nodejs or
whatever else nil.

~~~
mritterhoff
> but why treat people differently because of their gender? Can't we just
> treat everyone the same?

This is one of those well-intentioned questions that makes a lot of hidden
assumptions. Since straight white men founded this country, wrote the laws,
and hold a disproportionate number of positions as presidents, congressmen,
CEOs, etc, this means that the directive to "treat everyone the same" in
practice becomes "treat everyone like a straight white man"

Men and women and non-binary folks have different needs and are oppressed to
varying degrees. Trying to treat them all the same ignore these important
differences. This post discusses how conventional city planning of treating
everyone the same is less effective than bringing those differences to the
forefront: [http://www.citylab.com/commute/2013/09/how-design-city-
women...](http://www.citylab.com/commute/2013/09/how-design-city-women/6739/)

~~~
staticelf
> This is one of those well-intentioned questions that makes a lot of hidden
> assumptions. Since straight white men founded this country, wrote the laws,
> and hold a disproportionate number of positions as presidents, congressmen,
> CEOs, etc, this means that the directive to "treat everyone the same" in
> practice becomes "treat everyone like a straight white man"

I am sorry, but the last part just doesn't make any sense. First of, I am
probably not from the same country as you are and treating everyone according
to the golden rule doesn't mean treating everyone like a straight white man.
You are accusing me of making assumptions when the irony is that you are
making the assumptions.

I don't really believe that cities generally are being designed for any
specific gender and I do not believe any gender is being oppressed in my
country. But at last, I don't see how this is relevant at all for this
discussion, I was simply talking about treating everyone the same and for sure
if you can make data supported general statements about specific needs for men
or women go ahead and design a better city.

------
dang
This post is baity but the thread turned out to be rather good, so let's try
turning off the flags on it. If it ends up a flamewar we'll have to put them
back on, so if you comment here, please keep the discussion thoughtful!

Btw, the top bit of the article is an HN comment by uriel from 2012:
[https://news.ycombinator.com/item?id=4495305](https://news.ycombinator.com/item?id=4495305),
and the other part had a major thread in 2011:
[https://news.ycombinator.com/item?id=3055154](https://news.ycombinator.com/item?id=3055154).

~~~
SixSigma
You can't flamewar with Uriel any more. He suicided.

Sodium pentothal bought online from China. Every time my Skype starts is has
"Hey Uriel, don't drink the wrong drink" in my recent messages. That crazy
bastard.

------
andrewmcwatters
As much as I love Node.js, I also love this post. It screams the ever-repeated
viewpoints of the experienced and tired developer.

There isn't enough of this on HN.

~~~
vpb
Almost all pages of cat-v.org read like that. It's a good read. Most should be
taken in a light hearted way - it's just software, after all. People
unfortunately tend to get outraged by it. Also unfortunately, the original
author, Uriel, passed away a few years ago. If you enjoy it, try taking a look
at suckless.org

Most pages in cat-v (and suckless) tend to favor the Unix way, small
connecting components communicating through pipes. It seems sensible to me.
It's comprehensible, it's easy to break down and analyze stuff when it's
breaks. I never dabbled in Node.js - js is not my favorite language - but it
does looks like complex and hard to understand its internals. Maybe it's not.

------
nilved
I try to understand why people would write JavaScript but I just can't. The
only explanation to me is that they're not aware of what they're missing out
on, or the deficiencies of their own platform, in a Dunning-Kruger sort of
way.

I would be interested in hearing from some JavaScript developers about why
they use JavaScript, but I have probably heard and refuted it before.
Especially after Ryan Dahl disavowed Node, I think it's time to reconsider
your viewpoint.

------
clifanatic
Well... all the things like DBus and /usr/lib and Boost and ioctls and SMF and
signals and volatile variables and prototypal inheritance and C99FEATURES_ and
dpkg and autoconf that he's complaining about were originally conceived as a
way to simplify something that their respective authors considered too complex
in the first place. I'm not holding my breath that the next attempt to
simplify all of those doesn't just add yet more complexity.

On the plus side, job security.

------
yAnonymous
Yeah. I hate all these great text editors and other cross-platform software
that Node brought about.

------
myf01d
I am interested. What is Node.js people opinions about Django in 2016? I am a
newbie and I chose Django for a somewhat serious personal project. Is it
really bad to use django for a new project in 2016?

~~~
OOPMan
Nothing wrong with Django, it's a perfectly decent web framework.

Not every system requires the async paradigm of Node in order to be useful.

For those that do, the ecosystem is more diverse than just Node anyway. On the
Python side, for example, you can use Crossbar or Django-Channels. Personally,
I prefer the former but the latter is also usable.

------
sownkun
bit of an overstatement if you ask me

------
greendestiny_re
I'd just like to point out the linguistic paradox of the "one of the worst"
syntagm, as only one thing can be the worst, and "one of" implies a multitude
of such things; if 20 things are the worst, then none of them are. In short,
this is a lazy way for the writer to express his opinion but label it as a
fact.

