6 ms·

> Node What's your reasoning behind this? Just being able to run the same code on frontend and backend?

barrell 2y ago
When node first came out, it was pretty revolutionary. Being able to almost instantly start a JavaScript thread from a single file that could support realtime experiences (a la socket.io et al) without a build step felt pretty paradigm shifting
- ffsm8 2y ago
  > could support realtime experiences Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free thread after the timer relapsed - which entirely depends on the load of the system
  - anon7000 2y ago
    Realtime in this context probably just refers to the end user experience — multiple people connecting over web sockets to the same backend and seeing the same thing in “real time”.
  - Jarwain 2y ago
    Theres discussion distinguishing hard real-time (what you describe), firm real-time (infrequent deadline misses are problematic but managable), and soft real-time (missing deadlines aren't a big deal). Node does a pretty hood job with soft real-time.
    - Rohansi 2y ago
      What games do you know that are hard or firm real-time? Real-time in this context is more like real-time communication rather than process scheduling.
      - Jarwain 2y ago
        I think we've diverged from the game context, towards discussion "universal brain reorganizing technologies", nodejs being considered one, and what real-time means in the context of node. That said, real-time communication _is_ a soft real-time system.
    - hdjrudni 2y ago
      Ya'all are very strict in your definitions then. My definition is "does it feel laggy" or "do I have to walk away and come back when this thing is done". Basically like 24 FPS or higher is real-time. Even that'd be laggy for a game but not unplayable. I choose this specifically because that's what movies typically use and they're very watchable.
      - nilamo 2y ago
        That definition of real time is not good enough for things like pacemakers, where real time really does actually matter.
        beaudidly 2y ago
        [dead]
      - bobnamob 2y ago
        https://en.wikipedia.org/wiki/Real-time_computing https://en.wikipedia.org/wiki/Real-time_computing Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry. Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.
        hansworst 2y ago
        But in gaming, real time means something different: https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time Context matters.
        meheleventyone 2y ago
        In game development we still care about the distinction between soft and hard realtime. Almost all games are soft realtime, even if the gameplay itself is turned based as we're processing user input, updating UI, animating things and so on.
  - timewizard 2y ago
    Did they simply mean "non blocking?"
  - 1oooqooq 2y ago
    you're making the common mistake of assuming js devs know anything about core concepts. they are vibe coding since the beginning.
- Swannie 2y ago
  Yeah, nah. I worked on telco grade systems running on Rhino, in interpreted mode, in 2006. Leveraging Java to JS bindings. Responding to HTTP/JMS/etc.
- cess11 2y ago
  How would that differ from PHP?
  - Inviz 2y ago
    Async io?
    - cess11 1y ago
      At the time, if you needed it, and you typically didn't due to FCGI, you'd use a threading library from PECL.
  - sroussey 2y ago
    Websockets et al
    - cess11 1y ago
      Node launched before Chrome got WebSocket support. Soon after Google published their own PHP WebSocket server and people had been building their own.
aeturnum 2y ago
Like, if you decide to do your backend in rust or python you can choose async or synchronous approaches - but Node locks you into async. I'm not a node developer so I can't sing the praises of what you get, but being locked into JavaScript's process model, VM, and type system is certainly a downside (for which you get the whole JS world). It's another example of...if you are architecting your service and you pick this you are picking some built in trade-offs.
- efilife 2y ago
  maybe I don't understand something but most if not all node methods have their sync counterparts
  - aeturnum 2y ago
    You're thinking about JavaScript but I am talking about Node, which fundamentally uses a single-threaded approach[1] to great effect. [1] https://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded https://stackoverflow.com/questions/17959663/why-is-node-js-...

When node first came out, it was pretty revolutionary. Being able to almost instantly start a JavaScript thread from a single file that could support realtime experiences (a la socket.io et al) without a build step felt pretty paradigm shifting

ffsm8 2y ago
> could support realtime experiences Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free thread after the timer relapsed - which entirely depends on the load of the system
- anon7000 2y ago
  Realtime in this context probably just refers to the end user experience — multiple people connecting over web sockets to the same backend and seeing the same thing in “real time”.
- Jarwain 2y ago
  Theres discussion distinguishing hard real-time (what you describe), firm real-time (infrequent deadline misses are problematic but managable), and soft real-time (missing deadlines aren't a big deal). Node does a pretty hood job with soft real-time.
  - Rohansi 2y ago
    What games do you know that are hard or firm real-time? Real-time in this context is more like real-time communication rather than process scheduling.
    - Jarwain 2y ago
      I think we've diverged from the game context, towards discussion "universal brain reorganizing technologies", nodejs being considered one, and what real-time means in the context of node. That said, real-time communication _is_ a soft real-time system.
  - hdjrudni 2y ago
    Ya'all are very strict in your definitions then. My definition is "does it feel laggy" or "do I have to walk away and come back when this thing is done". Basically like 24 FPS or higher is real-time. Even that'd be laggy for a game but not unplayable. I choose this specifically because that's what movies typically use and they're very watchable.
    - nilamo 2y ago
      That definition of real time is not good enough for things like pacemakers, where real time really does actually matter.
      - beaudidly 2y ago
        [dead]
    - bobnamob 2y ago
      https://en.wikipedia.org/wiki/Real-time_computing https://en.wikipedia.org/wiki/Real-time_computing Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry. Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.
      - hansworst 2y ago
        But in gaming, real time means something different: https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time Context matters.
        meheleventyone 2y ago
        In game development we still care about the distinction between soft and hard realtime. Almost all games are soft realtime, even if the gameplay itself is turned based as we're processing user input, updating UI, animating things and so on.
- timewizard 2y ago
  Did they simply mean "non blocking?"
- 1oooqooq 2y ago
  you're making the common mistake of assuming js devs know anything about core concepts. they are vibe coding since the beginning.
Swannie 2y ago
Yeah, nah. I worked on telco grade systems running on Rhino, in interpreted mode, in 2006. Leveraging Java to JS bindings. Responding to HTTP/JMS/etc.
cess11 2y ago
How would that differ from PHP?
- Inviz 2y ago
  Async io?
  - cess11 1y ago
    At the time, if you needed it, and you typically didn't due to FCGI, you'd use a threading library from PECL.
- sroussey 2y ago
  Websockets et al
  - cess11 1y ago
    Node launched before Chrome got WebSocket support. Soon after Google published their own PHP WebSocket server and people had been building their own.

aeturnum 2y ago

Like, if you decide to do your backend in rust or python you can choose async or synchronous approaches - but Node locks you into async. I'm not a node developer so I can't sing the praises of what you get, but being locked into JavaScript's process model, VM, and type system is certainly a downside (for which you get the whole JS world). It's another example of...if you are architecting your service and you pick this you are picking some built in trade-offs.

efilife 2y ago
maybe I don't understand something but most if not all node methods have their sync counterparts
- aeturnum 2y ago
  You're thinking about JavaScript but I am talking about Node, which fundamentally uses a single-threaded approach[1] to great effect. [1] https://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded https://stackoverflow.com/questions/17959663/why-is-node-js-...