Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

51–60 of 365 posts

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

#51
post #28
post #27

Earlier quoted context omitted.

I actually have, but it doesn't alleviate my biggest issue with Javascript, which is its async story. Also I've had experiences with Typescript code compiling with an error then immediately recompiling without any errors. Then errors when I switch to my browser. The immediate recompilation is probably just webpack but it doesn't inspire confidence when errors are non-deterministic.

Typescript plus async/await is a beautiful solution to both the async story and typing story.

The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question.

Is there any better workaround to that these days?

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

#53
post #19

> Verify All Assumptions When you have to worry about the environment unexpectedly reusing internal variables, when is it considered foolish to use a framework where you have to question every relationship between every concept? Just stop using it.

Or one could learn how `this` works, which is that example is really talking about. I was unimpressed by these lessons. There are no dark corners of Node, or JS in general, here. It's more of a narration of the author's growth as an engineer. The "call the callback last" recommendation is particularly odd.

The counterintuitive behavior of "this" in JavaScript doesn't need any defending. I've never heard a justification for this or any other of JavaScript's quirks that wasn't just a thinly veiled lecture on how it works.

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

#54
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…

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.

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

#55
post #28

Earlier quoted context omitted.

Typescript plus async/await is a beautiful solution to both the async story and typing story.

The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question. Is there any better workaround to that these days?

Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface.

Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.

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

#56
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've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal ser…

pm2 + newrelic = problem solved?

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

#57
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've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal ser…

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

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

#58
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?

So I felt this way until about...oh...a month ago. Because my JavaScript experience was mostly ES5. And ES5 is a roiling piece of shit that I wouldn't wish on my worst enemy. ES6, however? ES6 is tolerable. Getting it set up isn't as bad as you'd think and the language does as much as a Ruby or a Python in not shooting yourself in the foot. I'd trade async/await for actual threads, because I am capable of writing code with threads without hurting myself, but async/await are fine for get-it-out-the-door web services and that kind of thing. So I don't worry about it that much.

I'd still go reach for the JVM and languages like Java or Kotlin if I was going to be hammering on a piece of code on an everyday basis for two or three years. But in 2017 (and probably 2016, but 2017 was when I got to it), it just became good enough to get it out the door with.

(Regarding TypeScript: I feel like it's an incomplete thing and I'm happy that it exists, but for the stuff I use ES6 for I can hold the entirety of it in my head and I'm not worried about typing. For things that matter to me...well, I wouldn't be using ES6 in the first place.)

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

#59

Earlier quoted context omitted.

It's common for people to complain about something like a syntax error taking down their whole process, so that's how I read it -- that you're trying to do "too much" catching.

I'm not an expert with​ deploying application servers but shouldn't part of handling lifecycle include the ability for a service to crash and be respawned? Ie. Be okay if a syntax error crashes your server.

In a "one request per process" model, sure. But if you are handling 1000s of concurrent connections, a syntax error crashing your server means all of those connections error.

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

#60
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?

JavaScript is a scripting language. So is Python and Ruby. As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. Now, in terms of bindings, bindings to libuv are also fast. So node is not so much of a problem in itself. However the problem is how the language is being used: To say you can write a serious library or server code because you kno…

> As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python.

This makes no sense.

They're all dynamically typed languages (avoiding the term "scripting languages" since it's pretty vague).

The only reason for the difference in speeds between these languages is due to the quality of their interpreters, not the languages themselves.

Post reply on HN