Hard-won lessons: Five years with Node.js • Hacker News Board

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

#191

Post by rusk » Thu, Apr 20, 2017, 9:27 AM UTC

TheCondor wrote: post #48

lasfter wrote: 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…

"if you don't stay up to date with your depends, things change fast and sometimes they change a lot."

This, was actually one of the things I liked most about Node.js - npm allows a developer to specify all dependencies (`pacakage.json`), versioned, similarly to maven but not as clunky. I was able to get up to speed project very quickly and easily using just `npm install`. I had one or two versioning issues to iron out, but the advice it provides about what is broken and where was very helpful.

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

#192

Post by z3t4 » Thu, Apr 20, 2017, 9:29 AM UTC

The article mentions synchronous performance, but there are no mentions of optimizations. You can do a lot of optimizations in JavaScript and the VM itself is already well optimized. If your naive implementation is slow, my experience says you can speed it up 100x. Then it's not really worth switching to C/C++ assembly for another 10x performance. Then it's better to take the step to pure hardware.

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

#193

Post by jononor » Thu, Apr 20, 2017, 9:39 AM UTC

cnp wrote: post #39

jimmywanger wrote: post #16

Earlier quoted context omitted.

Yeah. I've had production experience with node. It's been the single least productive coding environment of my life. When you're taking care of large systems of backend servers, Javascript is pretty far down on the list of languages I'd pick to use. Add to that Node's explicit handling of asynchronous operations instead of just blocking and waiting. Also, it seems to get worse the more code you have. I'm sure it's po…

> Another subject the author brings up is "the ecosystem". Javascript has so many libraries that keeping up with them, their updates, and using them in a canonical way throughout a large codebase is a full-time job for at least one engineer. I love the language, but this is absolutely true.

Use https://Greenkeeper.io to automatically get PRs on dep changes. Coupled with a good testsuite, it's work very nicely. - happy user

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

#194

Post by rusk » Thu, Apr 20, 2017, 9:41 AM UTC

rapsey wrote: post #158

sgift wrote: 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…

Maven is a "bad example" - it's horrible. Everybody agrees.

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

#195

Post by joekrill » Thu, Apr 20, 2017, 9:42 AM UTC

int_19h wrote: post #113

Daishiman wrote: post #11

Reading up on all these Node.JS posts I'm surprised at just how many gotchas the platform has and how there's no single standardized way to solve them. It's not encouraging stuff. On paper the platform looks decent but aside from a few use cases it seems that there's more hype than it merits.

What really scares me about the Node ecosystem is bugs like these: https://github.com/npm/npm/issues/10999 https://github.com/npm/npm/issues/9633 I have personally hit both while trying to build (not even write!) Node software. The former bug is an example of "broken by design", and it's interesting that it remains open (therefore admitting that it is a problem?), but no solution came yet. Although I believe Yarn doe…

Technically those are NPM bugs, not Node bugs. And Yarn seems to do a much better job these days.

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

#196

Post by z3t4 » Thu, Apr 20, 2017, 9:43 AM UTC

Regarding throw and NaN, when the program throws an error, make sure it's restarted! When JavaScript throws, it stops doing whatever it was doing. But the rest of the program will continue to run like if nothing happened. NodeJS does the right thing by "crashing" / exit.

When you asume something in JavaScript, for example that the second parameter in the function is a callback function make sure it is!

  if(typeof callback != "function") throw new Error("Expected callback=" + callback + " to be a callback function!");

  if(isNaN(someNumber)) throw new Error("someNumber=" + someNumber + " is NaN! someState=" + someState);

  if(something == undefined) throw new Error("something=" + something + " is undefined!");

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

#197

Post by nailer » Thu, Apr 20, 2017, 9:44 AM UTC

yagop wrote: post #159

FajitaNachos wrote: post #56

Earlier quoted context omitted.

pm2 + newrelic = problem solved?

Or just Systemd

Obviously systemd for keeping processes up, but is there a god way to centralise journald logs in one place (and search it). Hoping for something that's pure journald not a syslog equivalent (as I'd rather less software than more).

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

#198

Post by jononor » Thu, Apr 20, 2017, 9:47 AM UTC

thibaut_barrere wrote: post #3

Something I found surprising was the 1.5 GB limit per process when used on Heroku ( https://devcenter.heroku.com/articles/node-concurrency ), which afaik can be circumvented elsewhere ( https://futurestud.io/tutorials/node-js-increase-the-memory-... ). This can be problematic at times if you need to open a very large number of concurrent connections (crawlers, slack connections etc), and can force you to organize a "…

You can have quite a number of concurrent connections in 1GB of RAM, 10k at least? That seems allright for a single node, and scaling horizontally after that. For something like crawling, which has a lot of time spent on CPU intensive parsing and I with unpredictable times (hitting external service) I would throw that in a background worker from the start.

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

#199

Post by nailer » Thu, Apr 20, 2017, 9:47 AM UTC

vacri wrote: post #126

ohstopitu wrote: post #37

Earlier quoted context omitted.

I've used nodeJS at 3 of the past 4 startups I've worked at (currently using PHP). I had a hand in choosing it at all those 3 places and my main reasons boiled down to: 1. most devs know JS (so it's easier to hire & onboard new devs) 2. while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). 3. The community is generally awesome (helps during meetings, online…

> while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs. There are so many modules added using so many files, that we ended up not being able to use our packaged application - extracting the package into a holding dir before moving into place meant that we ran out of inodes on the filesystem (stock 8GB ubuntu ext4 cl…

> watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening.

Deeply nesting packages was specifically designed to fix the issue that other packaging systems have: two dependencies needing different versions of a third dependency.

Flat-where-possible structures (ie, npm v3 and up) were designed to improve this. They're excellent and npm is the only place I've seen them.

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

#200

Post by jononor » Thu, Apr 20, 2017, 9:50 AM UTC

iopq wrote: post #120

Safety1stClyde wrote: post #118

Earlier quoted context omitted.

"I wasn't referring to the specifics, but to the point that every programming language seems to have quirks and hidden rules."

That's just an excuse to say "all programming languages are hard" Which is true, but ultimately useless

Not entirely useless. For low risk, use the language you know instead of new ones - they will have yet-to-be-learned gotchas.