Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

261–270 of 365 posts

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

#261

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…

I for one consider that a feature - it is easy enough to write bad code in JS as it is, so anything that encourages defensive coding and solid unit/functional tests is very appropriate for this particular language.

A crash certainly draws attention to a problem much better than an error in a log that no one usually looks at.

Yes it's a pain, but you deserve it for writing buggy code and then not catching it in testing (that's what I keep saying to myself, anyway). ;)

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

#262
post #163

Earlier quoted context omitted.

> So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!" You misunderstand my point completely. I was trying to say the Java ecosystem is complicated and the only way it works is by using large IDEs. Saying how awe…

Most Java people I know use IDEs mostly just to edit and debug the code, and does the builds/runs/tests from the command line.

What do you mean with "just to edit"? Aren't there any (compilation) errors, warnings displayed anywhere?

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

#263

This looks like how I used to work with BASIC back in the 80s: > I finally added extremely verbose logging ... started adding logging ... Verbose logging to the rescue ... I had the right logging in place ... My first step was to jump in and add some key logging statements ... added extremely verbose logging Weird to see people happy to be limited to such stone-age work-flows when fully capable debuggers have existed…

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand are lacking, and happy with a with whatever they can get running.

Comments like this are not the problem with HN.

The fact that they get voted, literally, to the top, is.

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

#264
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'm a huge proponent of using the same language in front and back end. My best teams had C++ front & back, or C# front and back, even Java front and back. Even though one language/platform isn't ideal for both ends, the benefit of getting everyone on the same tools, libraries, processes and way of thinking is invaluable.

So these days where most front ends are JS, it makes a lot of sense to have a JS back end too.

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

#265
post #91

Earlier quoted context omitted.

> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. What languages are you comparing against? It seems like asynchronous code is more difficult to write in NodeJS than in C#, Go, or Rust, and about the same as Java. I can write code in Java in a style similar to promises using ListenableFuture (Google…

that's a lot of text you wrote for something that will get automatically disregarded by anyone with a brain for having mentioned plaintext response benchmarks

what would be wrong with that?

secondly, what do non-plain-text benchmarks give us?

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

#266
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 do not like javascript. I am using it on my server because of performances. It has about the same execution speed as java, a slightly smaller memory footprint, but with the async io, it ensures best use of cpu with none of the hassles of multithreads. No need of apache or nginx, with a single process, you can serve hundreds of simultaneous users with blazing performances

There are quite a few Netty-based web frameworks faster than Node.js

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

#267

Earlier quoted context omitted.

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…

> Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Ain't nobody is going to compare performance against Erlang for numerical number crunch. It was never built for that. It's not even a fair comparison. It's like comparing a race car against a hybrid prius and saying the race car suck at mpg. They're built for different purposes. Ilk implies as if Erlang is some crap flavor flav tech. It is no…

The only difference, of course, is that nobody uses Erlang.

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

#268

This looks like how I used to work with BASIC back in the 80s: > I finally added extremely verbose logging ... started adding logging ... Verbose logging to the rescue ... I had the right logging in place ... My first step was to jump in and add some key logging statements ... added extremely verbose logging Weird to see people happy to be limited to such stone-age work-flows when fully capable debuggers have existed…

>Weird to see people happy to be limited to such stone-age work-flows when fully capable debuggers have existed for almost all proper languages out there the last 30 years.

Even though node has a debugger with breakpoints, etc., an effective programmer will still use logging in situations like the ones in the article. Taking the first example, before he knew that NaNs were causing the problem, setting a breakpoint would have taken forever to reveal anything. You can't set a conditional breakpoint until you know what the condition is. Logging was the fastest way to get useful clues.

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

#269

This looks like how I used to work with BASIC back in the 80s: > I finally added extremely verbose logging ... started adding logging ... Verbose logging to the rescue ... I had the right logging in place ... My first step was to jump in and add some key logging statements ... added extremely verbose logging Weird to see people happy to be limited to such stone-age work-flows when fully capable debuggers have existed…

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand are lacking, and happy with a with whatever they can get running. Comments like this are not the problem with HN. The fact that they get voted, literally, to the top, is.

Freshness also raises comments higher, not just voting. In time this one will drop.

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

#270
post #138
post #127

Earlier quoted context omitted.

> 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 Java guys always say how they have really developed tooling and look down on other languages. The problem is those nice tools have become a hindrance as well. You can't develop in Java/Kotlin if you don't use those huge complicated tools. I can't speak for all, but at least…

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

Getting a node server running the first time is actually very difficult. The libraries constantly change so fast tutorials frequently don't work. It was easy once I understood everything, but it wasn't easy the first time at all.
Post reply on HN