3 ms·

There are many reasons why having SPA and rendering your site on the client is a bad idea. First, you are basically breaking the concept of the web, a collecti

There are many reasons why having SPA and rendering your site on the client is a bad idea. First, you are basically breaking the concept of the web, a collection of documents, not a collection of code that must be executed to get a document. That has many bad effects. Browsing is slower, you have to download the code of the whole application and wait for it to execute other API calls to the server before the page is usable. That can take a couple of seconds, or even more on slower connections. With the old pages rendered server side not only you didn't have this effect, but also the browser could start to render the page even it was not fully received (since HTML can be parsed streamed). Not everyone has a fast connection available at all time, and it's frustrating when you have only a 2G network available and you cannot do basically anything on the modern internet. It's less secure, since you are forcing the user to execute some code on its machine just to look at an article in a blog. And JavaScript engines in browsers are one of the most common source of exploits, given their complexity. Also JavaScript can access information that can fingerprint your browser to track you, without particular permissions. Ideally in a sane world most of the websites don't require JavaScript, and the browser would show you a popup to allow the website to execute code (just like they as you access to the camera). It breaks any other tools that are not a browser. In the old days you could download with wget entire sites on your hard driver to consult them offline, with "modern" SPA is impossible. Of course that implies that it breaks things like the Wayback machine and thus history is not preserved. And serach engines penalizes sites that are not a clean static HTML. It's also less accessible, since most SPA don't respect the semantic of HTML, everything is a div in a div in a div. And of course you still need a browser, while with HTML documents you could process them with any software (why a blind person need to render the page in a browser? While a screen reader could have simply parsed the HTML of the page without rendering it on screen...). It breaks navigation in browser, the back button no longer works as you expect, reloading a page could have strange effects, and so on. I can't reliably look at the address bar to know the page I'm in. Finally it's less robust. SPA are a single point of failure. If anything goes wrong the whole site stops working. While a bug on a page on a classical server side rendered website breaks only that particular page. Also error handling is not present on most SPA, for example what happens if an HTTP request fails? Who knows. Look at submitting a form, most of the time there is no feedback. On a classical server side rendered application if I submit a form I either get a response from the server, or the browser informs me that request had failed and I can submit the form again.

BackBlast 6y ago
Some of these stated issues aren't universal. There are frameworks that pair a server side rendered page with a switchover to SPA. Providing the user with a pre-rendered page with a follow on JS bundle that loads the SPA and the switch is seamless. It's a bit of extra work so I don't always use it, but it exists. This also removes the incompatibilities with non-browser tooling/bots/etc. (Example: quasar.dev) 2G is being phased out (at least where I live), it no longer works here. Chromium browsers have a slow-3g network effect to test your code/sites. I use it frequently. Sometimes it reveals problems, other times it's a shrug. Some features just require bandwidth and there is no reasonable way to avoid it. I do try to reduce page weight as much as I reasonably can. Lots of features of the modern browser will leak finger-printable information. The JS engine is hardly the only problem piece. I guess your general complaint here is to indicate the world is insane. I tend to agree, but I don't think this is the principle reason why :) Screen readers are notoriously difficult to make work correctly. In my experience, this is a universal issue with the web generally and isn't unique to SPAs. If we're serious about audio accessibility we need an actual standard instead of this guesswork. Breaking navigation is a pet peeve of mine too, poorly behaved front-end routers are terrible. I always target working urls into any part of the app as refreshing the page is a common operation. And I must have a properly functioning back/forward for my own sanity in development if nothing else. I will beg to differ on the point of failure. SPAs can also be apps, paired with a service worker and a local data set they can continue to function even if you are completely offline, or the server is completely offline. Obviously if your web app is just broken, yeah, nothing's going to work. But in the case of SSR, that's also true if your network is down (locally or remotely), or the server is down/broken. A well built offline-first SPA will reduce the total number of single point failures that kill all functionality. Also, offline-first SPAs have the side effect of masking some of the latency over a slow 3G link - which can improve the user experience significantly.
xtracto 6y ago
>First, you are basically breaking the concept of the web, a collection of documents, not a collection of code that must be executed to get a document I think this ship has sailed a long time ago. Nevertheless, I still think that current SPA frameworks are overblown. I am partial to Javascript/HTML + WebComponents. However, I put the blame into the influx of "coderz" that in the last 10 years have arrived to do FrontEnd development. It is very similar to the use of thick frameworks in the backend (LoopBack, Ruby on Rails, etc): There's people who do not have a clue about what they are doing but they still build SPA websites by changing some code here and there after an "npm create-react-app-shopping-cart" script. I've interviewed hundreds of "Frontend Developers" and for the majority of them, once you start entering into the concepts of HTTP headers, why do we have CSS? why do we use font-icons and image sprites, CDN, JavaScript closures, JavaScript this/that issues, let/var differences, etc, they stare me with blank eyes.

BackBlast 6y ago

Some of these stated issues aren't universal. There are frameworks that pair a server side rendered page with a switchover to SPA. Providing the user with a pre-rendered page with a follow on JS bundle that loads the SPA and the switch is seamless. It's a bit of extra work so I don't always use it, but it exists. This also removes the incompatibilities with non-browser tooling/bots/etc. (Example: quasar.dev) 2G is being phased out (at least where I live), it no longer works here. Chromium browsers have a slow-3g network effect to test your code/sites. I use it frequently. Sometimes it reveals problems, other times it's a shrug. Some features just require bandwidth and there is no reasonable way to avoid it. I do try to reduce page weight as much as I reasonably can. Lots of features of the modern browser will leak finger-printable information. The JS engine is hardly the only problem piece. I guess your general complaint here is to indicate the world is insane. I tend to agree, but I don't think this is the principle reason why :) Screen readers are notoriously difficult to make work correctly. In my experience, this is a universal issue with the web generally and isn't unique to SPAs. If we're serious about audio accessibility we need an actual standard instead of this guesswork. Breaking navigation is a pet peeve of mine too, poorly behaved front-end routers are terrible. I always target working urls into any part of the app as refreshing the page is a common operation. And I must have a properly functioning back/forward for my own sanity in development if nothing else. I will beg to differ on the point of failure. SPAs can also be apps, paired with a service worker and a local data set they can continue to function even if you are completely offline, or the server is completely offline. Obviously if your web app is just broken, yeah, nothing's going to work. But in the case of SSR, that's also true if your network is down (locally or remotely), or the server is down/broken. A well built offline-first SPA will reduce the total number of single point failures that kill all functionality. Also, offline-first SPAs have the side effect of masking some of the latency over a slow 3G link - which can improve the user experience significantly.

xtracto 6y ago

>First, you are basically breaking the concept of the web, a collection of documents, not a collection of code that must be executed to get a document I think this ship has sailed a long time ago. Nevertheless, I still think that current SPA frameworks are overblown. I am partial to Javascript/HTML + WebComponents. However, I put the blame into the influx of "coderz" that in the last 10 years have arrived to do FrontEnd development. It is very similar to the use of thick frameworks in the backend (LoopBack, Ruby on Rails, etc): There's people who do not have a clue about what they are doing but they still build SPA websites by changing some code here and there after an "npm create-react-app-shopping-cart" script. I've interviewed hundreds of "Frontend Developers" and for the majority of them, once you start entering into the concepts of HTTP headers, why do we have CSS? why do we use font-icons and image sprites, CDN, JavaScript closures, JavaScript this/that issues, let/var differences, etc, they stare me with blank eyes.