4 ms·

It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts. Stop building SPA, go back to HTML.

It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts. Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.

doix 14d ago
There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot. Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc. But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.
- phoghed 14d ago
  These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past. Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.
  - cryptonym 13d ago
    Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework. Use the appropriate technology, everything doesn't have to be a SPA.
    - phoghed 13d ago
      And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.
      - cryptonym 13d ago
        Yet you can look at RUM data (http archive tech report or other) and start noticing it's not just management.
- cryptonym 14d ago
  You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse. If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.

doix 14d ago

There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot. Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc. But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.

phoghed 14d ago
These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past. Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.
- cryptonym 13d ago
  Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework. Use the appropriate technology, everything doesn't have to be a SPA.
  - phoghed 13d ago
    And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.
    - cryptonym 13d ago
      Yet you can look at RUM data (http archive tech report or other) and start noticing it's not just management.
cryptonym 14d ago
You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse. If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.