"Node.js is one of the worst things to happen to the software industry" (2012) - <AUTHOR> http://harmful.cat-v.org/software/node.js <comment><USER6> 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).

<comment><USER7> 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.

<comment><USER8> 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.

<comment><USER9> 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.

<comment><USER10> 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 :-).

<comment><USER9> 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.

<comment><USER10> 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 :-).

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> 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.

<comment><USER12> 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.

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

<comment><USER14> 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.

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

<comment><USER16> 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.

</comment></comment></comment></comment></comment></comment><comment><USER17> 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.

<comment><USER18>
        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.

<comment><USER19> > 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?

<comment><USER20> 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.

<comment><USER21> 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.

<comment><USER22> _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?

<comment><USER23> It's not a problem, unless you go to higher education looking for CS and end up with that instead.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> 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

<comment><USER25> > 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

<comment><USER24> 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.

<comment><USER25> > 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?

<comment><USER24> 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?

<comment><USER25> > 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.

</comment></comment></comment></comment></comment></comment><comment><USER26> 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.

<comment><USER27> 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.

<comment><USER26> 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.

</comment></comment></comment><comment><USER25> 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.

<comment><USER28> > 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.

<comment><USER25> > 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.

<comment><USER28> 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.

<comment><USER25> > 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.

<comment><USER28> 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.

<comment><USER25> > 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.

<comment><USER28> 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.

<comment><USER25> > 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.

<comment><USER28> 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.

<comment><USER25> > 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.

<comment><USER28> > 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.

<comment><USER25> > 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.

<comment><USER28> > 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.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> 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) - <USER2> 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.

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

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

</comment></comment></comment><comment><USER32> 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

<comment><USER33> 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?

<comment><USER34> > 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)

<comment><USER35> > 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)

<comment><USER36> 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...

<comment><USER35> 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.

</comment></comment></comment></comment></comment></comment><comment><USER37> 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.

<comment><USER38> > 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.

</comment></comment><comment><USER39> 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.

<comment><USER40> you are absolutely right this is a click bait post that should be down-voted.

</comment></comment><comment><USER41> "The async-style of programming is almost entirely inaccessible to my brain"

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

<comment><USER42> More like "the world's worst implementation of asynchronous programming is shitty and didn't learn from its predecessors".

</comment></comment><comment><USER43> 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.

<comment><USER44> 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.

<comment><USER45> Not sure, why this is getting downvoted.. It's very sensible and the poster provides a valid example.

</comment></comment></comment><comment><USER46> "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.

</comment><comment><USER47> 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.

<comment><USER48> >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.

<comment><USER49> 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.

</comment></comment></comment><comment><USER50> 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...

<comment><USER51> 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.

<comment><USER50> 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.

<comment><USER52> 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.

</comment></comment></comment></comment><comment><USER53> 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.

<comment><USER54> 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

<comment><USER55> 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.

</comment></comment></comment><comment><USER56> 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.

</comment><comment><USER57> 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.

</comment><comment><USER58> 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.

<comment><USER59> 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.

<comment><USER39> 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.

<comment><USER60> 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 :(

<comment><USER61> Compiles?

</comment></comment></comment></comment></comment><comment><USER62> 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.

</comment><comment><USER63> 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.

<comment><USER64> 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.

</comment></comment><comment><USER65> > 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.

</comment><comment><USER66> 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.

<comment><USER67> Package management is another typical complaint. Admittedly it's a complaint in nearly every language that has packaging tools.

</comment></comment><comment><USER68> Great line: "The only thing that matters in software is the experience of the user."

<comment><USER69> 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.

<comment><USER70> > 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.

</comment></comment></comment><comment><USER71> "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.

</comment><comment><USER72> The article is not very relevant in 2016. Much of the arguments are not valid anymore.

</comment><comment><USER73> 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.

<comment><USER74> 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.

</comment></comment><comment><USER75> 》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.

</comment><comment><USER76> Node.js solves the problem of "live webpages" w/ Websockets and Polling and chat apps and notifications etcetc.

And that counts. A lot.

<comment><USER77> > Websockets and Polling

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

</comment></comment><comment><USER78> 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 - <USER3> 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.

</comment><comment><USER79> 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)

<comment><USER80> 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?

</comment></comment><comment><USER81> > 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.

</comment><comment><USER82> This whole thread would not exist when async await gets traction

<comment><USER83> 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.

<comment><USER82> You don't need o wrap anything promise based and curretly all major libs deliver promises

<comment><USER84> He talks about events.

</comment></comment></comment></comment><comment><USER85> 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.

</comment><comment><USER86> I see a lot of desktop apps made from electron/CEF using Node. examples are Brackets and Steam.

</comment><comment><USER87> 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.

</comment><comment><USER88> 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 - <USER4> 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.

</comment><comment><USER89> 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.

<comment><USER90> 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.

<comment><USER89> 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.

</comment></comment></comment><comment><USER91> 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.

<comment><USER92> I think that bloated piece of software is one of the worst things to happen.

<comment><USER85> Then try tint [https://github.com/trueinteractions/tint2](https://github.com/trueinteractions/tint2)

<comment><USER92> I only use JavaScript on the browser, there are so much better alternatives outside of it.

</comment></comment></comment></comment><comment><USER36> 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)

</comment><comment><USER93> 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!

</comment><comment><USER94> 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.

</comment><comment><USER95> 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.

</comment><comment><USER96> 4 years old?

</comment><comment><USER71> "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.

</comment><comment><USER97> I rather like JavaScript. ES2015 anyway.

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

<comment><USER98> You're too late. He suicided.

</comment></comment><comment><USER99> Cannot access the site.

</comment><comment><USER100> Can you make it good?

</comment><comment><USER101> Unbelievable, so many up votes for this complete idiot statement..

</comment><comment> Wei-1 cannot agree more, but we still use it.

</comment><comment><USER102> TL;DR:

>I hate almost all software.

</comment><comment><USER103> 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 - <USER5> 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)

<comment><USER104> 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.

<comment><USER105> > 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/)

<comment><USER104> > 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.

</comment></comment></comment></comment><comment><USER106> 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).

<comment><USER98> 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.

</comment></comment><comment><USER107> 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.

<comment><USER108> 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.

</comment></comment><comment><USER109> 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.

</comment><comment><USER110> 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.

</comment><comment><USER111> Yeah. I hate all these great text editors and other cross-platform software that Node brought about.

</comment><comment><USER112> 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?

<comment><USER113> 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.

</comment></comment><comment><USER114> bit of an overstatement if you ask me

</comment><comment><USER115> 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.</comment>