Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

21–30 of 365 posts

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

#21
post #17

I would have like more detail on what they were doing with node. Building lots of small apps or one big one? Green fields or brown?

I've only worked on a large side project, but from that experience I have a theory that it is one of the triggers for microservices as a pattern, because the pain of debugging a Javascript server application seems to scale a lot more than linearly.

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

#22
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'm curious as to the reasons people chose Node.js

Javascript of course ;)

You can leverage the same language for server side stuff and browser programming.

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

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

Check out Typescript!

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

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

Being able to run the same code on the client and server is a boon for web sites - rendering views server side then hooking up client events is a lot more performant than only rendering on the client side.

Also, context switching - the projects I work on tend to be front-end heavy, with a little API access and data storage on the backend. I find it a lot easier to do that backend work with the same language, tools and debugging environment as my client code.

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

#25
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'm curious as to the reasons people chose Node.js Javascript of course ;) You can leverage the same language for server side stuff and browser programming.

But how valuable is that? I hear this a lot but is it really that much of an inconvenience to write backend code in a different language? Especially if there are different engineers working on the frontend and backend.

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

#26
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 only know JavaScript (and I know it quite well). Why learn a whole other language, when Node gets the job done just fine?

Learning a new language will make you a better programmer.

Especially one with different paradigms

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

#27
post #23
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?

Check out Typescript!

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.

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

#28
post #27
post #23

Earlier quoted context omitted.

Check out Typescript!

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.

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

#29

The biggest hard lessons I've had with Node.js have been around handling errors - when I first deployed https://www.findlectures.com , I was shocked to realize that uncaught errors could take down the whole site. Not handling error callbacks is also a big problem - TypeScript has been an awesome solution though, because it can show compilation errors if you screw up function arguments.

That's not Node.js. That's Express or a similar abstraction. You can execute everything inside a promise like with Koa, which amounts to something like: http.createServer((req, res) => { handle(req) .then((response) => res.send(response)) .catch(() => res.send(500)) }) Where `handle` is an async function and thus all your application logic is in async/await space.

It's Node.js - the root of the problem is also Node's strength, which is that there's effectively no stack. You can manage zillions of concurrent connections, but there's no easy way for the system to unwind bad behavior by one of those connections.

In a Java app you except all the way to the request response.

In a Go app you return all the way to the request response.

In a Node app, you have to call your way back to the request response. Or you don't, potentially leaving the whole process in an inconsistent state. The amazing concurrency of node comes at a price.

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

#30
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.
Post reply on HN