4 ms·

And yet, most frontend frameworks barely on even the simplest of sites. This is not only well documented, but most of them have now moved towards some sort of S

by nchmy 1y ago

And yet, most frontend frameworks barely on even the simplest of sites. This is not only well documented, but most of them have now moved towards some sort of SSR hybrid - at great complexity cost.

afavour 1y ago
I disagree with “most”. 99% of the sites featured on HN do just fine. OP is a talented developer that wrote a backend capable of surviving a ton of traffic. Other developers on the internet have written backends that cannot sustain a ton of traffic. The choice of frontend framework is separate from both. You can write a performant web app that uses React. I’m sure you can write one that falls over immediately with Datastar.
- andersmurphy 1y ago
  Thank you for the kind words. I think for me the key thing is Datastar lets me keep most of my state on the backend, which makes the backend much simpler to write. It also lets me do immediate mode streaming of the HTML, which again is non trivial in something like react without a lot of added complexity. So it's an enabler in that sense. But, yes it's totally possible to write a backend that falls over with datastar like any technology. I also agree, that Datastar does benefit from backend experience and if you don't have that experience it can to some extent feel like: "Draw some circles. Now draw the rest of the Owl".
- nchmy 1y ago
  That's a fair point. But I think that the real point that /u/andersmurphy was trying to convey was that hypermedia is VERY performant because immensely talented C++ engineers have optimized precisely this, for decades. The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous, and is one of the primary things that datastar and hypermedia approaches in general are trying to combat. In fact, he openly states elsewhere how the sites' backends are actually done in a deliberately dumb, unperformant way, where the backend streams the ENTIRE DOM with each sse message, which gets morphed into the DOM. He could have done something more granular, like streaming only the checkboxes that have changed, but it wasn't at all necessary because the dumb way worked well. Moreover, the SSE streams benefit from immense compression ratios because somehow the compression window overlaps across messages. Something like 95+%, IIRC.
  - afavour 1y ago
    > The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous The idea that UI state should be managed locally is ridiculous now?
    - nchmy 1y ago
      Its interesting, and telling, that that's the only part of my comment that you replied to... Anyway, browsers are built specifically to render HTML. And html/hypermedia is specifically meant to manage and transfer state. The web has lost its way. If you want to read more about this, this free book is a great start: https://hypermedia.systems/book/contents/ https://hypermedia.systems/book/contents/ Or the essays at HTMX https://htmx.org/essays/ https://htmx.org/essays/ Good luck to you
      - afavour 1y ago
        I don’t feel the rest was really worth engaging with. SSE is a really interesting technology but again, it’s frontend agnostic. You can build a great SSE solution with any other framework. I read about approaches like this and I still don’t see the reason to do them, beyond “because you can” and “JavaScript is bad”. The separation of data and display logic between server and client is a sensible separation of concerns. It’s the way any non-web solution does it and I don’t really see what would make the web so special that a different approach is worth it.
        nchmy 1y ago
        The entire point of frameworks is so that you dont have to engage with lower level things... D* makes it exceptionally easy to work with SSE and all sorts of web APIs. that's fine that you dont see any reason to use the web as it was designed to be used. But I dont see any reason for me to engage any further with you.
        array_key_first 1y ago
        You do it to reduce complexity. The problem with JS heavy frontend is you now have TWO applications. The real application, on the backend, which makes all the decisions, and the frontend application. You have TWO states which are being mutated independently that you now have to sync.
anthonylevine 1y ago
>This is not only well documented Please, I'm begging you to share this "well documented" fact that most frontend frameworks barely "handle" on the simplest of sites.
- nchmy 1y ago
  Certainly! Here's a good start (React is the main focus, but it extends to many other frameworks) https://infrequently.org/2024/11/if-not-react-then-what/ https://infrequently.org/2024/11/if-not-react-then-what/ (there's MUCH more at this site as well) https://www.zachleat.com/web/react-criticism/ https://www.zachleat.com/web/react-criticism/
  - albedoa 1y ago
    The HN comments for that first one gave us the worst "advice" that this site has ever seen and might ever see [1]: > Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. The commenter septupled down and eventually blamed trolls :D 1. https://news.ycombinator.com/item?id=42285326 https://news.ycombinator.com/item?id=42285326
    - nchmy 1y ago
      Sorry, I'm not understanding what relevance some HN comments have to do with the link I shared...? Though, for the record, I agree with everything that person - and other sibling commenter - wrote. It is quite obvious the people were not reading and replying in good faith.
      - albedoa 1y ago
        Okay! That is a wild thing to admit!
  - anthonylevine 1y ago
    So well documented is......2 sites? lol

by nchmy 1y ago

And yet, most frontend frameworks barely on even the simplest of sites. This is not only well documented, but most of them have now moved towards some sort of SSR hybrid - at great complexity cost.

afavour 1y ago

I disagree with “most”. 99% of the sites featured on HN do just fine. OP is a talented developer that wrote a backend capable of surviving a ton of traffic. Other developers on the internet have written backends that cannot sustain a ton of traffic. The choice of frontend framework is separate from both. You can write a performant web app that uses React. I’m sure you can write one that falls over immediately with Datastar.

andersmurphy 1y ago
Thank you for the kind words. I think for me the key thing is Datastar lets me keep most of my state on the backend, which makes the backend much simpler to write. It also lets me do immediate mode streaming of the HTML, which again is non trivial in something like react without a lot of added complexity. So it's an enabler in that sense. But, yes it's totally possible to write a backend that falls over with datastar like any technology. I also agree, that Datastar does benefit from backend experience and if you don't have that experience it can to some extent feel like: "Draw some circles. Now draw the rest of the Owl".
nchmy 1y ago
That's a fair point. But I think that the real point that /u/andersmurphy was trying to convey was that hypermedia is VERY performant because immensely talented C++ engineers have optimized precisely this, for decades. The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous, and is one of the primary things that datastar and hypermedia approaches in general are trying to combat. In fact, he openly states elsewhere how the sites' backends are actually done in a deliberately dumb, unperformant way, where the backend streams the ENTIRE DOM with each sse message, which gets morphed into the DOM. He could have done something more granular, like streaming only the checkboxes that have changed, but it wasn't at all necessary because the dumb way worked well. Moreover, the SSE streams benefit from immense compression ratios because somehow the compression window overlaps across messages. Something like 95+%, IIRC.
- afavour 1y ago
  > The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous The idea that UI state should be managed locally is ridiculous now?
  - nchmy 1y ago
    Its interesting, and telling, that that's the only part of my comment that you replied to... Anyway, browsers are built specifically to render HTML. And html/hypermedia is specifically meant to manage and transfer state. The web has lost its way. If you want to read more about this, this free book is a great start: https://hypermedia.systems/book/contents/ https://hypermedia.systems/book/contents/ Or the essays at HTMX https://htmx.org/essays/ https://htmx.org/essays/ Good luck to you
    - afavour 1y ago
      I don’t feel the rest was really worth engaging with. SSE is a really interesting technology but again, it’s frontend agnostic. You can build a great SSE solution with any other framework. I read about approaches like this and I still don’t see the reason to do them, beyond “because you can” and “JavaScript is bad”. The separation of data and display logic between server and client is a sensible separation of concerns. It’s the way any non-web solution does it and I don’t really see what would make the web so special that a different approach is worth it.
      - nchmy 1y ago
        The entire point of frameworks is so that you dont have to engage with lower level things... D* makes it exceptionally easy to work with SSE and all sorts of web APIs. that's fine that you dont see any reason to use the web as it was designed to be used. But I dont see any reason for me to engage any further with you.
      - array_key_first 1y ago
        You do it to reduce complexity. The problem with JS heavy frontend is you now have TWO applications. The real application, on the backend, which makes all the decisions, and the frontend application. You have TWO states which are being mutated independently that you now have to sync.

anthonylevine 1y ago

>This is not only well documented Please, I'm begging you to share this "well documented" fact that most frontend frameworks barely "handle" on the simplest of sites.

nchmy 1y ago
Certainly! Here's a good start (React is the main focus, but it extends to many other frameworks) https://infrequently.org/2024/11/if-not-react-then-what/ https://infrequently.org/2024/11/if-not-react-then-what/ (there's MUCH more at this site as well) https://www.zachleat.com/web/react-criticism/ https://www.zachleat.com/web/react-criticism/
- albedoa 1y ago
  The HN comments for that first one gave us the worst "advice" that this site has ever seen and might ever see [1]: > Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. The commenter septupled down and eventually blamed trolls :D 1. https://news.ycombinator.com/item?id=42285326 https://news.ycombinator.com/item?id=42285326
  - nchmy 1y ago
    Sorry, I'm not understanding what relevance some HN comments have to do with the link I shared...? Though, for the record, I agree with everything that person - and other sibling commenter - wrote. It is quite obvious the people were not reading and replying in good faith.
    - albedoa 1y ago
      Okay! That is a wild thing to admit!
- anthonylevine 1y ago
  So well documented is......2 sites? lol