Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

171–180 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#171
post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

I replied in a sister thread, but here are some new points that are specific to your questions. Node was decided upon before I joined the team, because some of the senior developers on the team were big members of the node team, and they also wanted to crank out something new in this greenfield project. In retrospect, and in my reading of the history, Node was sufficiently different and new enough that it was "ooh, s…

>For large production systems that need to be supported and maintained, it's awful

I don't think it's changing as quickly as you say, especially over the time since ES6 released/acquired first-class support, but you are right, this has been an issue.

>Javascript itself basically has objects that are just JSON objects. When you're passing them back and forth, you get the irresistible urge to add "optional" fields...

You use classes incorrectly / refuse to use classes and then complain when they don't behave like classes?

And then you blame the language?

Honestly, your two points preceding this were pretty reasonable. But I really think your bias starts to show yourself in the next ones.

>Libraries are often half-baked

You're really going to need to flesh this one out. React is half-baked, and so is the create-react-app surrounding it? Express is half-baked? Loopback is half-baked?

I won't deny shitty packages exist; Javascript has a low barrier to entry, and things can be mildly functional and kinda broken pretty easily. But I mean, it's obvious which packages don't suck if you just look at the amount they've been downloaded off npm and their issue lists on github.

>I can't stand NPM. A lot of times, two libraries that you want to include will depend on incompatible versions of another, shared library

In the last 18 months of developing in Node.js, I have not run into this issue once. Before that, sure, but I don't really see that as an issue lately.

>It's very difficult to reason about code

Promises or async/await fix all those issues. Again, this seems like a complaint 18 months out of date

There's issues with JS as a backend, to be certain. It's not nearly as performant as Java/Go/whatever language you fancy is capable of and it's single-threaded.

However, I don't think it's changing as rapidly as you think lately. I honestly must say that you sound like you had the issues of 2 years ago that have been improved on a lot by ES6 and a little maturation of the ecosystem.

The language is very flexible, and that definitely lent itself to a rapidly changing ecosystem at first. But if you want to take that flexibility and see how far you can bend it, then complain when it breaks, it's not a good look for a criticism of the language.

Anyways, this is a strangely impassioned defence, which I guess stemmed from the fact that your first two points resonated with me, but then your following points came up a bit short. I think you maybe haven't looked on the language with fresh eyes for a while, and will find it is not quite as easy to criticize these days.

Re: Hard-won lessons: Five years with Node.js

#172
post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments. JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reac…

> V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick.

Not to nitpick details, but V8 is a runtime, not a compiler.

A compiler checks your code and tells you if it contains errors before you run it. V8 does not.

Re: Hard-won lessons: Five years with Node.js

#173
post #158
post #138

Earlier quoted context omitted.

> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause…

No I want to use the command line. https://maven.apache.org/guides/getting-started/maven-in-fiv... Maven quick start first command: > mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false Then it generates stupidly deep Java structure. and next you have to write a verbose xml. They even say: > The POM is huge and can be daunting…

> The POM is huge and can be daunting in its complexity

Because they are honest. Maybe it is because I'm more accustomed to poms, but the package.json/babelrc mix and webpack.config.jsons are daunting to me too.

Re: Hard-won lessons: Five years with Node.js

#174
post #54

Earlier quoted context omitted.

I see some merits. I am not sure I buy using JavaScript based on performance/dev speed ratio though. Lua is even faster, lighter weight and has clean, logical semantics. I guess I'm just trying to decide if having a large talent pool and tons of modules is good enough.

I would watch it with that "large talent pool". As is typical in the language du jour, there are tons of worthless imposters going around selling Node.js skills. However, it's even worse in the case of JavaScript because since it uses the "same language", some people assume that light front-end scripting qualifies as real backend development experience. "Tons of modules" is also a misnomer, because a much larger than…

I've had some trouble finding explicit node backend jobs, as someone who'd consider themselves a relative specialist in it. Most places want a full stack developer well versed in common frontend frameworks and maybe a tiny bit of services on the backend. Most backend focused jobs (rightly, probably) focus on more traditional stacks or go. There's amazing things one can do very quickly with node exp (serverless/Faas services for one) but I've been struggling to find positions reliably.

Re: Hard-won lessons: Five years with Node.js

#175
post #173
post #158

Earlier quoted context omitted.

No I want to use the command line. https://maven.apache.org/guides/getting-started/maven-in-fiv... Maven quick start first command: > mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false Then it generates stupidly deep Java structure. and next you have to write a verbose xml. They even say: > The POM is huge and can be daunting…

> The POM is huge and can be daunting in its complexity Because they are honest. Maybe it is because I'm more accustomed to poms, but the package.json/babelrc mix and webpack.config.jsons are daunting to me too.

Web ecosystem is a mess as well. What I meant was Rust, Elixir, Erlang build/project files. Those are trivial.

Re: Hard-won lessons: Five years with Node.js

#176
post #138

Earlier quoted context omitted.

> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause…

You don't need a build step for Node.js, 93% of ES6 features are already included in the latest version. Babel is more for client side than anything and that's because browser vendors take a while to implement new standards, so yeah JS has unique challenges and constraints as the de facto language of the web.

Or typescript frequently.

Re: Hard-won lessons: Five years with Node.js

#177

Earlier quoted context omitted.

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

You know what isn't as quick? Websockets, non-trivial asynchronous code, boilerplate, and build times. The vast majority of my company is built on Java and we're not encumbered by legacy code, so we get to play with all the new stuff. I don't need to be convinced that Java (or even more specifically the JVM) is a good choice for many practical reasons. I live in IntelliJ and Gradle (and Maven too) all day, you're pre…

Do you have any particular reasons to prefer Node (assuming Javascript) to Clojure/Groovy?

Asking, because I do most of my development in Clojure and find it much nicer than Node both for POC and production. There's also self-hosted Clojurescript now that runs without a dependency on JVM.

Re: Hard-won lessons: Five years with Node.js

#178
post #158
post #138

Earlier quoted context omitted.

> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause…

No I want to use the command line. https://maven.apache.org/guides/getting-started/maven-in-fiv... Maven quick start first command: > mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false Then it generates stupidly deep Java structure. and next you have to write a verbose xml. They even say: > The POM is huge and can be daunting…

You don't have to use maven directly. Something like https://github.com/bodar/jcompilo would be much simpler and faster for a small project.

Re: Hard-won lessons: Five years with Node.js

#179

Earlier quoted context omitted.

Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java have more tooling, but I haven't noticed a difference between keeping a Node process up as opposed to a Python one. Hard to compare to stateless PHP.

The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms. Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try…

You nailed it. Three major things I care about for my application:

- Logging

- Metrics/Instrumentation/Tracing (memory usage, transactional performance monitoring, etc)

- Surviving exceptions

All of these are either very immature in Node or simply so far behind they may as well not exist. By nature of running in an application server, you do get a lot of benefits right off the bat for all of those, but even if you're running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests.

Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).

Re: Hard-won lessons: Five years with Node.js

#180
post #177

Earlier quoted context omitted.

You know what isn't as quick? Websockets, non-trivial asynchronous code, boilerplate, and build times. The vast majority of my company is built on Java and we're not encumbered by legacy code, so we get to play with all the new stuff. I don't need to be convinced that Java (or even more specifically the JVM) is a good choice for many practical reasons. I live in IntelliJ and Gradle (and Maven too) all day, you're pre…

Do you have any particular reasons to prefer Node (assuming Javascript) to Clojure/Groovy? Asking, because I do most of my development in Clojure and find it much nicer than Node both for POC and production. There's also self-hosted Clojurescript now that runs without a dependency on JVM.

Honestly, because I'm pretty good w/ Node (or just JS in general) and haven't invested the time to get good w/ Groovy or Clojure at this point.

I've only just played around with Clojure and I've written a middling amount of Groovy, but the vast majority of it involved Jenkins build pipelines, so I don't really count it.

Post reply on HN