5 ms·

This is an "um ackshually" reply. Nobody used LiveWire and it died a swift death. And don't "um ackshually" me about saying "nobody." You know what I mean.

rileymat2 4y ago
Classic asp also supports JavaScript, it is old and wide spread in the bowels of legacy sites. I thought of node as a victory for async more than anything else.
- Cyberdog 4y ago
  > I thought of node as a victory for async more than anything else. In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. I can see the application for something like websockets but I presume most Node sites aren't using those. I figured its success was due to V8 being reasonably fast, plus a generation of front-end-centric developers coming along who had learned to use JS quite heavily on the front end and didn't realize or didn't care that better options already existed on the back end.
  - eyelidlessness 4y ago
    > In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. This is precisely why async (well, cooperative concurrency generally) is useful, whether on a server or otherwise. Blocking for things you can’t do yet is a waste of idle resources. There are plenty of other concurrency models which are also useful, but yielding/suspending when idle is almost always better than not. And the cases where it’s not generally have other problems.
    - Cyberdog 4y ago
      I don't understand. What can a Node app do in between making a database request and when the response arrives?
      - eyelidlessness 4y ago
        Make other database requests, or return the responses derived from prior requests. Or just anything else waiting in the event loop queue, including queueing more work. You can think of the concurrency model like green threads with only one thread available, or actors in a single system process. Edit to elaborate: yield/suspend is key here. The way it works is yielding/suspended calls have their outstanding work put behind the extant queue which proceeds until each next queued routine suspends or returns, and once that set of blocking work completes the routine which suspended can proceed until it yields again or returns. The obvious pathological case is long running work which doesn’t suspend. Which if it’s I/O or idle-heavy should be refactored to yield, if it’s compute-heavy it should be treated as an optimization or scaling target.
        Cyberdog 4y ago
        I'm trying to envision a situation where you'd want to make more than one database request at the same time. Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my instincts to kill a request as quickly and directly as possible if something can't be accessed. I don't know, I'm willing to accept that maybe I'm just not used to thinking of developing back-end web apps that way. But async still just doesn't seem as useful as it would in a GUI desktop app.
        eyelidlessness 4y ago
        > I'm trying to envision a situation where you'd want to make more than one database request at the same time. Because I have two requests active at the same time and the second one which arrived shouldn’t wait for me to stand around doing nothing while I wait for the database to serve the first. > Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my instincts to kill a request as quickly and directly as possible if something can't be accessed. Here one user represents 2+ events, both of which should fail. This wasn’t part of my original explanation but yielding does give you the opportunity to fail both simultaneously. Albeit in this case it’s just concurrency broadly. Why is that against your instincts, if you know that one request’s failure implies the other will also fail? Why should that user wait in line to get the same error after another cycle of the same trial? > I'm just not used to thinking of developing back-end web apps that way. But async still just doesn't seem as useful as it would in a GUI desktop app Yep I get that. And async takes a bit to get used to in general. The way I think of it is: I have two kinds of work which need to be done, and a long line asking me to work. Some of the work needs labor (CPU), some needs patience and communication (IO). Everyone in line needs some of both. If I do the first person’s immediate labor and wait for further communication, persons 1 and 2 are waiting for me to proceed. If I do the first person’s labor, send off an asynchronous request for feedback on that, I can do N people’s labor before I get any response. As long as no one spends too long making anyone else wait in queue everyone moves as fast as the queue’s capacity.
  - tannhaeuser 4y ago
    > Async is rather useless on the server side [...] its success was due to [...] a generation of front-end-centric developers [who] didn't realize [...] that better options already existed You'd be wrong, again. According to Ryan Dahl, creator of Node.js [1]: > I think the combination of Chris Neukirchen’s rack plus how Nginx structured its web server with non-blocking IO led me to start thinking about how those two things could be combined. [...] So, when V8 came out, I started poking around with it, and it looked fascinating [...] and suddenly, I clicked that: oh! Javascript is single-threaded, and everybody is already doing non-blocking. [...] I think JavaScript plus asynchronous IO plus some HTTP server stuff would be a cool thing. And I was so excited about that idea that I just worked on it non-stop for the next four years. [1]: https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://mappingthejourney.com/single-post/2017/08/31/episode...

rileymat2 4y ago

Classic asp also supports JavaScript, it is old and wide spread in the bowels of legacy sites. I thought of node as a victory for async more than anything else.

Cyberdog 4y ago
> I thought of node as a victory for async more than anything else. In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. I can see the application for something like websockets but I presume most Node sites aren't using those. I figured its success was due to V8 being reasonably fast, plus a generation of front-end-centric developers coming along who had learned to use JS quite heavily on the front end and didn't realize or didn't care that better options already existed on the back end.
- eyelidlessness 4y ago
  > In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. This is precisely why async (well, cooperative concurrency generally) is useful, whether on a server or otherwise. Blocking for things you can’t do yet is a waste of idle resources. There are plenty of other concurrency models which are also useful, but yielding/suspending when idle is almost always better than not. And the cases where it’s not generally have other problems.
  - Cyberdog 4y ago
    I don't understand. What can a Node app do in between making a database request and when the response arrives?
    - eyelidlessness 4y ago
      Make other database requests, or return the responses derived from prior requests. Or just anything else waiting in the event loop queue, including queueing more work. You can think of the concurrency model like green threads with only one thread available, or actors in a single system process. Edit to elaborate: yield/suspend is key here. The way it works is yielding/suspended calls have their outstanding work put behind the extant queue which proceeds until each next queued routine suspends or returns, and once that set of blocking work completes the routine which suspended can proceed until it yields again or returns. The obvious pathological case is long running work which doesn’t suspend. Which if it’s I/O or idle-heavy should be refactored to yield, if it’s compute-heavy it should be treated as an optimization or scaling target.
      - Cyberdog 4y ago
        I'm trying to envision a situation where you'd want to make more than one database request at the same time. Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my instincts to kill a request as quickly and directly as possible if something can't be accessed. I don't know, I'm willing to accept that maybe I'm just not used to thinking of developing back-end web apps that way. But async still just doesn't seem as useful as it would in a GUI desktop app.
        eyelidlessness 4y ago
        > I'm trying to envision a situation where you'd want to make more than one database request at the same time. Because I have two requests active at the same time and the second one which arrived shouldn’t wait for me to stand around doing nothing while I wait for the database to serve the first. > Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my instincts to kill a request as quickly and directly as possible if something can't be accessed. Here one user represents 2+ events, both of which should fail. This wasn’t part of my original explanation but yielding does give you the opportunity to fail both simultaneously. Albeit in this case it’s just concurrency broadly. Why is that against your instincts, if you know that one request’s failure implies the other will also fail? Why should that user wait in line to get the same error after another cycle of the same trial? > I'm just not used to thinking of developing back-end web apps that way. But async still just doesn't seem as useful as it would in a GUI desktop app Yep I get that. And async takes a bit to get used to in general. The way I think of it is: I have two kinds of work which need to be done, and a long line asking me to work. Some of the work needs labor (CPU), some needs patience and communication (IO). Everyone in line needs some of both. If I do the first person’s immediate labor and wait for further communication, persons 1 and 2 are waiting for me to proceed. If I do the first person’s labor, send off an asynchronous request for feedback on that, I can do N people’s labor before I get any response. As long as no one spends too long making anyone else wait in queue everyone moves as fast as the queue’s capacity.
- tannhaeuser 4y ago
  > Async is rather useless on the server side [...] its success was due to [...] a generation of front-end-centric developers [who] didn't realize [...] that better options already existed You'd be wrong, again. According to Ryan Dahl, creator of Node.js [1]: > I think the combination of Chris Neukirchen’s rack plus how Nginx structured its web server with non-blocking IO led me to start thinking about how those two things could be combined. [...] So, when V8 came out, I started poking around with it, and it looked fascinating [...] and suddenly, I clicked that: oh! Javascript is single-threaded, and everybody is already doing non-blocking. [...] I think JavaScript plus asynchronous IO plus some HTTP server stuff would be a cool thing. And I was so excited about that idea that I just worked on it non-stop for the next four years. [1]: https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://mappingthejourney.com/single-post/2017/08/31/episode...