4 ms·

I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the I

by pan69 8y ago

I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically a programmable socket server and it's main feature is "websockets". Writing software applications in NodeJS is the most awkward experience due to it's async nature. Business logic is inherently sync, not async. Most of NodeJS's existence has been trying to find an elegant solution to make this async behaviour look like it's sync, from callbacks, to promises and now actual language features added to JavaScript itself (async/await). The problem with Javascript on the server is not Javascript, but the runtime in which it's executed. I think it would be interesting to have an sync version of NodeJS that acts more like traditional Ruby and Python next to the async variant that we currently have. Both types could then be used along side each other, each solving the problem for which it is best suited.

gcommer 8y ago
https://github.com/laverdet/node-fibers https://github.com/laverdet/node-fibers Is a project that enables writing code this way. It's used, for example, in webdriver.io so that you can write synchronous test code that transparently (ie, without `await`) calls out to async helpers.
tree_of_item 8y ago
This is a solved problem. async/await makes your async code look sync. This is a strange thing to focus on IMO.
always_good 8y ago
I'd say your intel is far out of date. Async-everything + async/await makes Node more elegant than the same programs in Ruby/Python. Even little things like "make these two database requests in parallel and wait on them both" or "process these urls but only have 8 requests in flight at a time."
- tgtweak 8y ago
  I'm always impressed at what one thread can do with non blocking io. I think node strikes a decent balance on parallel programming without the pitfalls of threading. GO is undoubtedly better at lightweight threading, but it's not as simple to grok (or debug)
- davedx 8y ago
  > "process these urls but only have 8 requests in flight at a time." What's the state of the art solution to this in node.js?
  - cloverich 8y ago
    There's many ways to do this, but at its simplest because Node is single threaded, you can have a shared array of URL's and then a pool of workers who .pop() a URL off and stop when there are none left. Each worker's http request runs async, so with the `async` keyword at the start of their signature, and `await fetch(url)` inside, the code reads (and in some ways behaves) like regular synchronous iteration but runs (mostly) concurrently.
  - always_good 8y ago
    const results = await Promise.map(urls, url => process(url), { concurrency: 8 }) You can find a "map with concurrency limit" implementation in Bluebird (shown) or standalone on NPM. For example, off the top of my head this would probably take me 40 lines of ungeneral wait group code in Go.
pdeuchler 8y ago
Except javascript's design is completely antithetical to those use cases. It has no type system, its performance is hard to profile and reason about, single threaded (unless you want to start forking and managing threads in javascript...), weird edge cases, piss poor numeric computation, etc etc.
wruza 8y ago
>Writing software applications in NodeJS is the most awkward experience due to it's async nature. Business logic is inherently sync, not async. The first thing I did for a latest project in node was a sync =>{done()} queue for ws requests. There is a room for fine-graining, but it is a routinely job of determining parallel cases that don’t hit db “ci” in acid much. Not a big deal. The choice for node was obvious in that it has most straightforward installation and maintaining on windows boxes (I’m language and OS agnostic [except js allergy], but peers aren’t). I think that async is yet another hipster bullet, since our to-profit businesses rarely need much traffic and those that need are barely fit for 10kloc of js. It’s awkward personally not so because it’s async, but because it’s too low level and npm doesn’t feel like a well-documented and thorough module set. It lacks unixlike formality and strictness in phrasing, oriented on beginners, but not on -pedantic needs. It’s hackerish and cool until you meet borders that are required beyond the “move fast” thing — it slows you down. And I didn’t meet a good abstraction over ws and db layer yet. It feels like a bicycle and a shovel when you have to dig a career (pun intended).
bschwindHN 8y ago
> NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS What part of it is really hard to do without NodeJS? You can do this easily in Go, Elixir, C++, Rust, etc.
- pjmlp 8y ago
  JavaScript everywhere mentality?
- aphexairlines 8y ago
  The nice thing about Node.js's design is that (almost) all IO is non-blocking by design, so developers can't block their programs on IO by accident. In other platforms developers need discipline to choose non-blocking APIs over blocking ones, or to wrap their blocking calls in async execution contexts like threads or coroutines.
  - bschwindHN 8y ago
    I'm just disagreeing that it's "really hard" for languages besides JavaScript. Concurrency in Go is stupid easy, it's built into the language. Pretty sure Elixir is the same story. C++ and Rust are slightly more difficult but still nowhere near "really hard" when it comes to making a socket server that can serve hundreds of thousands. Here's a nice WebSocket server in C++: https://github.com/uNetworking/uWebSockets/blob/master/README.md https://github.com/uNetworking/uWebSockets/blob/master/READM...
  - Rapzid 8y ago
    All the "sync" commands are blocking. In my experience developers need discipline to avoid using those and blocking the whole app. Of the languages mentioned I believe Go is actually closest to all io being non blocking by default; with the caveat that you are using multiple go routines.

by pan69 8y ago

gcommer 8y ago

https://github.com/laverdet/node-fibers https://github.com/laverdet/node-fibers Is a project that enables writing code this way. It's used, for example, in webdriver.io so that you can write synchronous test code that transparently (ie, without `await`) calls out to async helpers.

tree_of_item 8y ago

This is a solved problem. async/await makes your async code look sync. This is a strange thing to focus on IMO.

always_good 8y ago

I'd say your intel is far out of date. Async-everything + async/await makes Node more elegant than the same programs in Ruby/Python. Even little things like "make these two database requests in parallel and wait on them both" or "process these urls but only have 8 requests in flight at a time."

tgtweak 8y ago
I'm always impressed at what one thread can do with non blocking io. I think node strikes a decent balance on parallel programming without the pitfalls of threading. GO is undoubtedly better at lightweight threading, but it's not as simple to grok (or debug)
davedx 8y ago
> "process these urls but only have 8 requests in flight at a time." What's the state of the art solution to this in node.js?
- cloverich 8y ago
  There's many ways to do this, but at its simplest because Node is single threaded, you can have a shared array of URL's and then a pool of workers who .pop() a URL off and stop when there are none left. Each worker's http request runs async, so with the `async` keyword at the start of their signature, and `await fetch(url)` inside, the code reads (and in some ways behaves) like regular synchronous iteration but runs (mostly) concurrently.
- always_good 8y ago
  const results = await Promise.map(urls, url => process(url), { concurrency: 8 }) You can find a "map with concurrency limit" implementation in Bluebird (shown) or standalone on NPM. For example, off the top of my head this would probably take me 40 lines of ungeneral wait group code in Go.

pdeuchler 8y ago

Except javascript's design is completely antithetical to those use cases. It has no type system, its performance is hard to profile and reason about, single threaded (unless you want to start forking and managing threads in javascript...), weird edge cases, piss poor numeric computation, etc etc.

wruza 8y ago

>Writing software applications in NodeJS is the most awkward experience due to it's async nature. Business logic is inherently sync, not async. The first thing I did for a latest project in node was a sync =>{done()} queue for ws requests. There is a room for fine-graining, but it is a routinely job of determining parallel cases that don’t hit db “ci” in acid much. Not a big deal. The choice for node was obvious in that it has most straightforward installation and maintaining on windows boxes (I’m language and OS agnostic [except js allergy], but peers aren’t). I think that async is yet another hipster bullet, since our to-profit businesses rarely need much traffic and those that need are barely fit for 10kloc of js. It’s awkward personally not so because it’s async, but because it’s too low level and npm doesn’t feel like a well-documented and thorough module set. It lacks unixlike formality and strictness in phrasing, oriented on beginners, but not on -pedantic needs. It’s hackerish and cool until you meet borders that are required beyond the “move fast” thing — it slows you down. And I didn’t meet a good abstraction over ws and db layer yet. It feels like a bicycle and a shovel when you have to dig a career (pun intended).

bschwindHN 8y ago

> NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS What part of it is really hard to do without NodeJS? You can do this easily in Go, Elixir, C++, Rust, etc.

pjmlp 8y ago
JavaScript everywhere mentality?
aphexairlines 8y ago
The nice thing about Node.js's design is that (almost) all IO is non-blocking by design, so developers can't block their programs on IO by accident. In other platforms developers need discipline to choose non-blocking APIs over blocking ones, or to wrap their blocking calls in async execution contexts like threads or coroutines.
- bschwindHN 8y ago
  I'm just disagreeing that it's "really hard" for languages besides JavaScript. Concurrency in Go is stupid easy, it's built into the language. Pretty sure Elixir is the same story. C++ and Rust are slightly more difficult but still nowhere near "really hard" when it comes to making a socket server that can serve hundreds of thousands. Here's a nice WebSocket server in C++: https://github.com/uNetworking/uWebSockets/blob/master/README.md https://github.com/uNetworking/uWebSockets/blob/master/READM...
- Rapzid 8y ago
  All the "sync" commands are blocking. In my experience developers need discipline to avoid using those and blocking the whole app. Of the languages mentioned I believe Go is actually closest to all io being non blocking by default; with the caveat that you are using multiple go routines.