5 ms·

If you still think "the edge" is a fad in 2022, I'd recommend spending more time learning about it. It's not just JavaScript. Ironically, this architecture is t

If you still think "the edge" is a fad in 2022, I'd recommend spending more time learning about it. It's not just JavaScript. Ironically, this architecture is the solution to the web's JavaScript problem, and will be the demise of heavy clients and SPAs. This appears to be self contridictory. Putting things on the edge means downloading more code to the client and heavy client code and more logic on the client side, and things more like full-fledged apps (I'm avoiding saying Single Page App here because the concept of "single page" is related to website navigation). I don't see how this solves "the web's JavaScript problem", whatever it is you mean by that. Can you expound upon this part of your comment more?

rgbrgb 4y ago
I think he's talking about edge computing rather than CDNs. There's a new crop of web frameworks that are building around the idea that you can make navigation in server-rendered apps feel comparably fast to SPA's (and faster in some cases because SPA payloads are often huge) by putting the server very close to the user. In this model, you just have the client download HTML for the current page and the browser sees way less JS. Here's a web framework that is focused on this architecture: https://remix.run/ https://remix.run/ Here's a PaaS that is focused on this architecture with wide language support: https://fly.io/ https://fly.io/
- thwarted 4y ago
  the idea that you can make navigation in server-rendered apps feel comparably fast to SPA's (and faster in some cases because SPA payloads are often huge) by putting the server very close to the user. Despite all the rhetoric that makes this claim, I continue to fail to see that server-rendered apps are somehow less interactive and have slower response time (both time to first byte and time to first interaction) than SPAs. I don't think I've ever seen a single page app respond faster and achieve interactivity sooner than an completely server side HTML templated site, but we say it feels faster for some reason. The Linux kernel cgit served interface¹ beats the pants off of almost everything else and it has way more data in its backing store (a git repo containing the Linux kernel) than many sites. Admittedly, there's little to no per-user custom state management there, but that's not something that gets removed by having the server closer to the user or only sending page patials anyway. I feel like we spend, on average, more time staring at spinning circle gifs waiting for SPAs to request their data and document fragments than we want to admit. (Yes, yes, I used some hyperbole here to make a point) ¹ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - rgbrgb 4y ago
    > we spend, on average, more time staring at spinning circle gifs waiting for SPAs to request their data and document fragments Definitely. I think that's the core problem remix is trying to solve (simple server rendering with the nice devex of our modern react toolkits). It will be interesting to see if the approach can works at scale and if the edge computing part of it remains a big selling point.

rgbrgb 4y ago

I think he's talking about edge computing rather than CDNs. There's a new crop of web frameworks that are building around the idea that you can make navigation in server-rendered apps feel comparably fast to SPA's (and faster in some cases because SPA payloads are often huge) by putting the server very close to the user. In this model, you just have the client download HTML for the current page and the browser sees way less JS. Here's a web framework that is focused on this architecture: https://remix.run/ https://remix.run/ Here's a PaaS that is focused on this architecture with wide language support: https://fly.io/ https://fly.io/

thwarted 4y ago
the idea that you can make navigation in server-rendered apps feel comparably fast to SPA's (and faster in some cases because SPA payloads are often huge) by putting the server very close to the user. Despite all the rhetoric that makes this claim, I continue to fail to see that server-rendered apps are somehow less interactive and have slower response time (both time to first byte and time to first interaction) than SPAs. I don't think I've ever seen a single page app respond faster and achieve interactivity sooner than an completely server side HTML templated site, but we say it feels faster for some reason. The Linux kernel cgit served interface¹ beats the pants off of almost everything else and it has way more data in its backing store (a git repo containing the Linux kernel) than many sites. Admittedly, there's little to no per-user custom state management there, but that's not something that gets removed by having the server closer to the user or only sending page patials anyway. I feel like we spend, on average, more time staring at spinning circle gifs waiting for SPAs to request their data and document fragments than we want to admit. (Yes, yes, I used some hyperbole here to make a point) ¹ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- rgbrgb 4y ago
  > we spend, on average, more time staring at spinning circle gifs waiting for SPAs to request their data and document fragments Definitely. I think that's the core problem remix is trying to solve (simple server rendering with the nice devex of our modern react toolkits). It will be interesting to see if the approach can works at scale and if the edge computing part of it remains a big selling point.