Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

Post reply on HN
Print view View original

221–230 of 365 posts

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

#221

Post by foldr »

mattmanser wrote: post #201
skolsuper wrote: post #124

Earlier quoted context omitted.

> It's only fast because you already have the knowledge. No, when I said "from zero" I meant from zero knowledge. > You have similar concerns with node (What's npm? etc...) What's the "etc..."? Install node and you get npm with it. Writing a REST service IS simpler with Node when going from zero, I know because I have done (or at least attempted) both from zero in the recent past. > The idea that it's a faster to ach…

This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".

I don't think so. Npm is included with node and is very simple to use.

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

#222

Post by dspillett »

technion wrote: post #88
manyxcxi wrote: post #35

Earlier quoted context omitted.

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…

I've had several experiences with Node.js contractors handing over "finished" applications that were only configured to run under webpack-dev-server[0] It clearly tells you in the README it's not for production, but I have this recurrent discussion with developers who tell me they have only ever run Node.js this way. What that tells me is there is quite a trend a towards exactly what you describe, where a lot of what…

> in the README [that it is] not for production but ... who tell me they have only ever run Node.js this way. What that tells me is there is quite a trend towards ... a lot of what gets written never goes into production.

No, it is worse than that I would have thought. The cynic in me (who is more often right then wrong) suggests that is means there is a lot of "proof of concept" level of code out there in production environments potentially running important things.

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

#223

Post by acdha »

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…

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

I've heard that a lot but advocacy always seems to be based on artificial benchmarks. Most server apps are I/O bound and the ones which aren't tend to bottleneck in native code – i.e. a gzip implementation would run faster in V8 than python, ruby, etc. but since they're just calling a C library, it's a question of whether V8 is faster than GCC/Clang.

One area where this is more interesting is async support, but the argument then is that it's easier to write async code in JS than other languages and reasonable people disagree on that point.

I'm not saying that V8 isn't an impressive bit of work, just that most of the advocacy I've seen has reminded me of the JVM hype cycle before most people learned that a JIT mattered a lot less than their architectural choices.

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

#225

Post by JdeBP »

manyxcxi wrote: post #179
stickfigure wrote: post #121

Earlier quoted context omitted.

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…

If one is spending any time hand-crafting the program to daemonize itself on a Unix or a Unix-alike, one is doing things wrongly. On those operating systems, since the advent of the System Resource Controller in 1992 the right way to write a program that runs under a service manager is to write a program that runs in the normal way. No "daemonization" needed.

* http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht...

* http://jdebp.eu./FGA/systemd-house-of-horror/

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

#226

Post by reacweb »

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?

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

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

#227

Post by empthought »

foldr wrote: post #221
mattmanser wrote: post #201

Earlier quoted context omitted.

This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".

I don't think so. Npm is included with node and is very simple to use.

So your main argument is that you have to make two downloads with Java (JDK and Maven) but with Node you need to make one? Seems pretty weak.

It can't be anything else, because after you have Maven, it is literally a single command to set up a REST project using Dropwizard.

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

#228

Post by z3t4 »

dahauns wrote: post #209
z3t4 wrote: post #190

Earlier quoted context omitted.

If you are using a web framework, and are considering switching to a systems language, and your developers already have a lot of experience in JavaScript, that's when you should consider NodeJS! I had a lot of JavaScript experience before switching to NodeJS, but it still was a huge step, you have to learn systems architecture, and distributed systems (async programming). I think JavaScript is easier then Java and C/…

I have a hard time really seeing this as a net win. There are huge upsides to having the same language on both sides - but the big downside is that javascript simply isn't a very good backend language . Node.js/v8 is incredibly impressive for what it is. But it still has "shoehorned" written all over it. (For the record: I wouldn't consider Java the Language a pinnacle either.)

I agree that JavaScript isn't very good, but what are the alternatives !? I can not think of any language where a non-engineer with little computer science knowledge, can get productive withing minutes. And it only gets better the more you use it. For example, the other day I wanted to take a screen-shot of a web page, make a visual diff, then email me if something changed with the changes highlighted. I basically glued three different NodeJS modules together, and it took less then a hour. Try to do that in any other language.

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

#229

Post by foldr »

empthought wrote: post #227
foldr wrote: post #221

Earlier quoted context omitted.

I don't think so. Npm is included with node and is very simple to use.

So your main argument is that you have to make two downloads with Java (JDK and Maven) but with Node you need to make one? Seems pretty weak. It can't be anything else, because after you have Maven, it is literally a single command to set up a REST project using Dropwizard.

Well, to an extent this is a subjective question. With node, you get npm with it, npm is what everyone uses, and npm is clearly what you should be using too. Moreover, the basic functionality of npm is very very easy to understand.

I find the Java ecosystem terrifying by comparison. I have no idea whether Maven is what I should be using or if I should be using something else instead -- having it as a separate download makes a big difference in that regard -- and I have no idea by looking at a typical Maven config file what it does.

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

#230

Post by NoInkling »

manyxcxi wrote: post #179
stickfigure wrote: post #121

Earlier quoted context omitted.

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…

Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however.

Also I thought something like PM2 (https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever) was pretty much standard for production Node apps?

Post reply on HN