5 ms·

It's called "single page application" and my guess is the most reason is "responsiveness" (which is however not true, you can lazy load anything with traditiona

by ktpsns 5y ago

It's called "single page application" and my guess is the most reason is "responsiveness" (which is however not true, you can lazy load anything with traditional HTML and a few lines of JS) and "smooth" transitions from one "virtual" page to the other. Honestly I never understood this trend. From a developer side, the engineering easily costs two times compared to a traditional site.

nerdponx 5y ago
It's also usually a lot less responsive for something as simple as a blog. It makes sense for complicated text/media hybrid pages with animations, embedded images and video, etc. There are so many "plain text" websites that simply do not load without JavaScript. Is this a consequence of using a framework like React? I feel like the world needs a "component-based" framework, but one that can gracefully degrade if JS isn't available.
- KronisLV 5y ago
  > It's also usually a lot less responsive for something as simple as a blog. It depends on how much JS is used and what it actually does. Sending and receiving data in a JSON format as opposed to receiving HTML? Could be marginally faster and would also allow integrating the API for fetching data with other front ends or other consumers easily. What causes the actual slowdown most of the time is framework code which cannot have the unused bits removed efficiently because of how dynamic most of the languages that we use are, even if there are tree shaking advancements that you hear about every now and then. That said, it's not entirely hopeless - you certainly can use something like react-snap to pre-render your site and then hydrate it with dynamic content and JS if supported by the user: https://web.dev/prerender-with-react-snap/ https://web.dev/prerender-with-react-snap/ Of course, degradation won't necessarily be graceful - everything that depends on JS simply won't work, as opposed to have some theorethical server-side fallback component, as nice as that would be. I've also heard of server side rendered React, however, even though i haven't personally used it: https://www.digitalocean.com/community/tutorials/react-server-side-rendering https://www.digitalocean.com/community/tutorials/react-serve... To be honest, trying to achieve such wide support for technologies and graceful fallback logic is a can of worms in of itself, so many simply choose to require JS functionality for their app and don't attempt to support other configurations, which is a shame.
  - timw4mail 5y ago
    I've come to think that such performance increases, if they exist, are not worth the amount of effort compared to a much simpler sever-side render. Also, if your website just happens to have that one bit of information I care about, and I don't view other pages, rendering with Javascript is a complete waste.
  - Karrot_Kream 5y ago
    Svelte [1] is a framework that's all about trying to make interactivity viz. JS a lighter process. It pre-compiles all the code so there's no shadow DOM or similar stuff going on. [1]: https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity
BiteCode_dev 5y ago
> the engineering easily costs two times At first. But if you setup a lot of cool plugins with the newest bundler, add modern libraries and make good use of web workers and graphql, in a few months you can get your costs up to 5 or 6 times!
- zinekeller 5y ago
  > At first. Wait, it makes it easier? > But if you setup a lot [of libraries] ... in a few months you can get your costs up to 5 or 6 times! Ah, lol! But in all, SPA for SPAs makes sense, but for documents it's counterintuitive. I mean I can see a case where it might be worth it, but looking at Wikipedia maybe it's not justifiable for the increased maintenance. Of course while the usual cause of rendering slowness in applications is emphasised (which is what I hear as a reason in favour of SPAs), but it tells me that your CSS isn't really optimized for your case.

by ktpsns 5y ago

nerdponx 5y ago

It's also usually a lot less responsive for something as simple as a blog. It makes sense for complicated text/media hybrid pages with animations, embedded images and video, etc. There are so many "plain text" websites that simply do not load without JavaScript. Is this a consequence of using a framework like React? I feel like the world needs a "component-based" framework, but one that can gracefully degrade if JS isn't available.

KronisLV 5y ago
> It's also usually a lot less responsive for something as simple as a blog. It depends on how much JS is used and what it actually does. Sending and receiving data in a JSON format as opposed to receiving HTML? Could be marginally faster and would also allow integrating the API for fetching data with other front ends or other consumers easily. What causes the actual slowdown most of the time is framework code which cannot have the unused bits removed efficiently because of how dynamic most of the languages that we use are, even if there are tree shaking advancements that you hear about every now and then. That said, it's not entirely hopeless - you certainly can use something like react-snap to pre-render your site and then hydrate it with dynamic content and JS if supported by the user: https://web.dev/prerender-with-react-snap/ https://web.dev/prerender-with-react-snap/ Of course, degradation won't necessarily be graceful - everything that depends on JS simply won't work, as opposed to have some theorethical server-side fallback component, as nice as that would be. I've also heard of server side rendered React, however, even though i haven't personally used it: https://www.digitalocean.com/community/tutorials/react-server-side-rendering https://www.digitalocean.com/community/tutorials/react-serve... To be honest, trying to achieve such wide support for technologies and graceful fallback logic is a can of worms in of itself, so many simply choose to require JS functionality for their app and don't attempt to support other configurations, which is a shame.
- timw4mail 5y ago
  I've come to think that such performance increases, if they exist, are not worth the amount of effort compared to a much simpler sever-side render. Also, if your website just happens to have that one bit of information I care about, and I don't view other pages, rendering with Javascript is a complete waste.
- Karrot_Kream 5y ago
  Svelte [1] is a framework that's all about trying to make interactivity viz. JS a lighter process. It pre-compiles all the code so there's no shadow DOM or similar stuff going on. [1]: https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity

BiteCode_dev 5y ago

> the engineering easily costs two times At first. But if you setup a lot of cool plugins with the newest bundler, add modern libraries and make good use of web workers and graphql, in a few months you can get your costs up to 5 or 6 times!

zinekeller 5y ago
> At first. Wait, it makes it easier? > But if you setup a lot [of libraries] ... in a few months you can get your costs up to 5 or 6 times! Ah, lol! But in all, SPA for SPAs makes sense, but for documents it's counterintuitive. I mean I can see a case where it might be worth it, but looking at Wikipedia maybe it's not justifiable for the increased maintenance. Of course while the usual cause of rendering slowness in applications is emphasised (which is what I hear as a reason in favour of SPAs), but it tells me that your CSS isn't really optimized for your case.