12 ms·

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

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 services as part of our build and delivery pipeline. It's a major pain in the butt to monitor and keep Node.js running production-like in even remotely similar ways you would with Java, .NET, Python, or even PHP for that matter. I don't expect such drastically different technologies to be exactly alike for production workloads, but there's usually analogous ways to do X, Y, or Z. You know where Node has been awesome? You land a project with a real tight deadline and its more of a fire and forget project (think interactive 'experience' at a major gaming conference for instance). It needs to run pretty well for a short period of time with a narrow scope of functionality, but some of that functionality is non-trivial. I absolutely love Node for that.

thesmallestcat 10y ago
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.
- stickfigure 10y ago
  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 passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?
  - m1sta_ 10y ago
    If only node had exception handling and functions!
    - sgift 10y ago
      Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.
      - mattmanser 10y ago
        The same problem as C#? You're fighting a very old position. Exception handling in C# is amazingly good, you can't run C# production level apps. It suffers none of the problems that are being discussed above. All you're doing is confusing the discussion with a view point I haven't heard in a decade.
  - manyxcxi 10y ago
    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 running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests. Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).
    - 10y ago
- manyxcxi 10y ago
  Love it or not, at least Python has uWSGI, which certainly helps keep things running through errors, and gives you more robust logging at a higher level, etc. if you lose your Node process it's just poof with no guarantees you'll get a good trace to pinpoint the fault.
  - Can_Not 10y ago
    Huh, that's weird, I've never had a Node process silently die in production without a good trace or robust high level logging. Are you sure you're not just making stuff up?
FajitaNachos 10y ago
pm2 + newrelic = problem solved?
- yagop 10y ago
  Or just Systemd
  - nailer 10y ago
    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).
hota_mazi 10y ago
> 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.
- pyrophane 10y ago
  I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.
  - hota_mazi 10y ago
    You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?
    - mikerybka 10y ago
      You don't need to wait for them to compile.
      - sgift 10y ago
        Unfortunately, modern JS has Transpilers, which you have to wait for, so no, that's not the case anymore. I have not seen any NodeJS project which didn't have to be transpiled (i.e. compiled to a different JS version).
        chrisco255 10y ago
        Totally false. Node.js pre-dates Babel by about 6 years so I wonder how that could possibly be true. Second, most ES6 features are already included natively in latest versions of Node so no need to transpile at all. You can even get async/await out of the box.
technion 10y ago
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 gets written never goes into production. [0] https://github.com/webpack/webpack-dev-server https://github.com/webpack/webpack-dev-server
- Ataraxic 10y ago
  Webpack dev server simply serves up compiled assets for convenience, because it serves new assets as they are compiled and blocks when compiling. It should be fairly trivial to serve up static production assets as needed. I say this as a person who just converted a production rails app to use webpack as first class citizen.
- dspillett 10y ago
  > 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.

thesmallestcat 10y ago

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.

stickfigure 10y ago
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 passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?
- m1sta_ 10y ago
  If only node had exception handling and functions!
  - sgift 10y ago
    Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.
    - mattmanser 10y ago
      The same problem as C#? You're fighting a very old position. Exception handling in C# is amazingly good, you can't run C# production level apps. It suffers none of the problems that are being discussed above. All you're doing is confusing the discussion with a view point I haven't heard in a decade.
- manyxcxi 10y ago
  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 running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests. Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).
  - 10y ago
manyxcxi 10y ago
Love it or not, at least Python has uWSGI, which certainly helps keep things running through errors, and gives you more robust logging at a higher level, etc. if you lose your Node process it's just poof with no guarantees you'll get a good trace to pinpoint the fault.
- Can_Not 10y ago
  Huh, that's weird, I've never had a Node process silently die in production without a good trace or robust high level logging. Are you sure you're not just making stuff up?

FajitaNachos 10y ago

pm2 + newrelic = problem solved?

yagop 10y ago
Or just Systemd
- nailer 10y ago
  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).

hota_mazi 10y ago

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

pyrophane 10y ago
I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.
- hota_mazi 10y ago
  You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?
  - mikerybka 10y ago
    You don't need to wait for them to compile.
    - sgift 10y ago
      Unfortunately, modern JS has Transpilers, which you have to wait for, so no, that's not the case anymore. I have not seen any NodeJS project which didn't have to be transpiled (i.e. compiled to a different JS version).
      - chrisco255 10y ago
        Totally false. Node.js pre-dates Babel by about 6 years so I wonder how that could possibly be true. Second, most ES6 features are already included natively in latest versions of Node so no need to transpile at all. You can even get async/await out of the box.

technion 10y ago

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 gets written never goes into production. [0] https://github.com/webpack/webpack-dev-server https://github.com/webpack/webpack-dev-server

Ataraxic 10y ago
Webpack dev server simply serves up compiled assets for convenience, because it serves new assets as they are compiled and blocks when compiling. It should be fairly trivial to serve up static production assets as needed. I say this as a person who just converted a production rails app to use webpack as first class citizen.
dspillett 10y ago
> 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.