4 ms·

I see quite a few blogs and informational sites with this described setup where the base html has none of the content and everything is client-side rendered. I

by tyingq 5y ago

I see quite a few blogs and informational sites with this described setup where the base html has none of the content and everything is client-side rendered. I'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)

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.
ArtTimeInvestor 5y ago
It has a certain appeal to developers because it makes separation of concerns easier. If your backend only takes in requests and spits out data, you can build the backend without spending any thoughts on user experience, layout, templates etc. All you do is design a database structure and API endpoints.
- BiteCode_dev 5y ago
  Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed. Because you can then derived a good architecture from that, but never the other way around. But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers. As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...
- tyingq 5y ago
  I suppose, but it wouldn't be that different to then render that on the server side instead of the browser.
  - ArtTimeInvestor 5y ago
    How so? Say the backend developer coded a bunch of Django views where they output json data. They say "Job done. There are API endpoints for everything now.". Now how does the frontend developer bring their templates into play so the json gets rendered "on the server side"?
    - tyingq 5y ago
      If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?
shadowgovt 5y ago
Usually, I see it done when the blog owner doesn't have a robust server or the savvy to run some shell scripts. Many small blogs are hosted in servers with pre-configured static document sharing that won't let any server-side dynamic code run beyond "Fetch the static document at path X and echo it." In that context, you either need to run a framework that will assemble your dynamic page client-side, or you need to run a script that will pre-chew your blog from some more convenient format into a rich static HTML document and post it to the server. A remarkable number of bloggers would consider that second option a bridge too far.

by tyingq 5y ago

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.

ArtTimeInvestor 5y ago

It has a certain appeal to developers because it makes separation of concerns easier. If your backend only takes in requests and spits out data, you can build the backend without spending any thoughts on user experience, layout, templates etc. All you do is design a database structure and API endpoints.

BiteCode_dev 5y ago
Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed. Because you can then derived a good architecture from that, but never the other way around. But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers. As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...
tyingq 5y ago
I suppose, but it wouldn't be that different to then render that on the server side instead of the browser.
- ArtTimeInvestor 5y ago
  How so? Say the backend developer coded a bunch of Django views where they output json data. They say "Job done. There are API endpoints for everything now.". Now how does the frontend developer bring their templates into play so the json gets rendered "on the server side"?
  - tyingq 5y ago
    If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?

shadowgovt 5y ago

Usually, I see it done when the blog owner doesn't have a robust server or the savvy to run some shell scripts. Many small blogs are hosted in servers with pre-configured static document sharing that won't let any server-side dynamic code run beyond "Fetch the static document at path X and echo it." In that context, you either need to run a framework that will assemble your dynamic page client-side, or you need to run a script that will pre-chew your blog from some more convenient format into a rich static HTML document and post it to the server. A remarkable number of bloggers would consider that second option a bridge too far.