6 ms·

I build internal apps for my clients and this ship has sailed. They love the interactivity and quickness of a SPA. For a while I was doing application per pag

I build internal apps for my clients and this ship has sailed. They love the interactivity and quickness of a SPA. For a while I was doing application per page type of apps and it worked fine. But honestly maintenance has become a lot easier just making it a SPA. I have no idea why I'd go back to having to maintain a JS entry point per page instead of just one for no benefit whatsoever. Reading HN you'd think 99% of development is landing pages and blogs. Maybe it is? lol. But I have a feeling many here develop a lot more sophisticated applications including but definitely not limited to data analysis, charting, workflows and business processes, statistical analysis, optimization, and having a reload on every little operation makes things significantly slower from a user experience perspective.

timw4mail 4y ago
When is a SPA quick? I still have yet to see this claim EVER be true.
- kkirsche 4y ago
  Define what quick means to you. They can be extremely good at responsiveness and background updates once the bundle has been loaded
- sibit 4y ago
  I've spent the last 2 years building B2B SPAs and, like everything in software, they can be fast or slow depending on how you build the app and what tools you use. I usually leverage lit-html, esmodules, and the dynamic import syntax. If you only fetch the business logic and views when you need them you can have an app that renders in seconds with an initial payload of ~15kb. I usually also set up a service worker to prefetch and cache the rest of the site while cache busting specific files on subsequent visits. Personally I use SPAs for offline support and MPAs for "portals" and brochure/marketing websites or blogs.
  - treis 4y ago
    >that renders in seconds That's really long.
    - sibit 4y ago
      Oh geese, I didn't realize that I forgot to add "on slow-3g". We usually aim for <1s FCP & <2s LCP. If it's ever above 5s on slow-3g we set aside time to optimize/refactor. Since our SPAs are offline-first the return visits (usually 3-5 times a day based on the customer) is on the scale of milliseconds.
      - treis 4y ago
        Even still. A 3g connection is a bit under half a MB a second. That's a lot of data for something that is mostly text.
        sibit 4y ago
        I feel like we're just spinning in circles trying to define "fast" and what speeds are "acceptable" when the main point was: > SPAs for offline support and MPAs for everything else You could build MPAs that offer offline support (and I have) but I find that you spend a lot of time writing the same render logic twice. Things might be different now with Next/Nuxt but when you're using PHP or C# it sucks to write the view render logic twice.
- steve_adams_86 4y ago
  Prefetching content means you can literally load a new page instantly without rendering anything but the new content. It is inherently faster once the initial page has loaded, and the JS no longer needs to be all that large to accomplish it. Like any technology, using it in the right place helps. This is great for documentation where the template and content slots are super consistent, for example. There are places it’s not a great choice. It isn’t inherently worse, though.
  - rcxdude 4y ago
    This is the theory, and yet in practice my experience is almost always the opposite: MPAs load and render quickly and are responsive during use, SPAs are slow to load and render and often chug substantially. Some of the better SPA manage to beat mediocre MPA implementations, but it's not super common. I don't know how it so frequently gets screwed up so badly, but it's a really consistent trend (and this is across fast desktops with a good internet connection to mobile devices with not-so-great signal). For example, hacker news is way, way more usable to me than new reddit (which actually renders my browser unusable on a high end machine after some use).
    - hinkley 4y ago
      The impedance mismatch always seems to boil down to the fact that we have been told umpteen million times that most people end up on your website with a nearly completely evicted cache, and we (or at least, the people who resist) don't seem to believe it. This is pretty much the default and a given for everyone who visits your site... except you. As the author, you likely use your application more than most users, you use it on a work machine (which has a smaller, more niche browser history), and you use it with the sort of network connection that software developers demand: you know, excessive. We see what we expect to see, what we want to see, and most of us don't challenge that, or only do it perfunctorily. And if someone else does? Well that's just crazy talk. See? Everything is fine.
  - tatersolid 4y ago
    Our B2B SaaS apps are SPA and preload static assets in the background on the login screen, including the top 90% of used js, templates, and icons (simple to find via http log analysis). This improves the end-user perception of performance dramatically. Accessibility with said SPAs is still a pain though. Even when you use correct semantic elements instead of DIV soup, the DOM usable by screen readers changes “out-of-order” frequently in SPAs, requiring lots of extra work to ensure an accessible experience.
- robertoandred 4y ago
  https://reactjs.org/docs/getting-started.html https://reactjs.org/docs/getting-started.html is a fast SPA
  - exodust 4y ago
    It's just text.
jabart 4y ago
If your non-spa app requires a page load per an operation, my opinion is someone built it wrong. You can do a lot with < 200 lines of JS to make a page interactive. Legacy apps were rebuilt as SPAs and rebuilding them made them faster. "Spinning wheel of doom" is used by users now to describe delays in both SPA and non-spa web applications. Same tricks to make a SPA feel responsive work for both styles.
- cjbgkagh 4y ago
  I find the more interactions I add to a non-SPA the more SPA like it becomes.
  - sanderjd 4y ago
    Yep, but with ever-more wheel reinvention.
- dymk 4y ago
  In 200 lines of JS, you can add maybe an interactive file uploader, or a tooltip implementation, and some form validation. But good luck doing anything of "business-tool" complexity in 200 lines that constitutes an application.
  - Spivak 4y ago
    Yeah I’m so confused what people think “interactivity” even means, like do people think interaction ends at “make the hamburger menu open and close?”
    - TedDoesntTalk 4y ago
      Dynamically replacing a div, based on a DOM event, with results of a fetch call can be done in way less than 200 lines of JS. But why you’d do that instead of using 10 MB of React code, I don’t know.
      - dymk 4y ago
my69thaccount 4y ago
Do your clients have any accessibility needs?
- Etheryte 4y ago
  Accessibility has nothing to do whether your page is cut up in one way or another. You can build accessible pages that are SPA and unaccessible pages in any other way all the same. Most if not all accessibility issues stem from lack of education on the matter, rather than technical limitations.
  - my69thaccount 4y ago
    SPAs are inaccessible by default.
    - azemetre 4y ago
      Could you expand upon this? Do you mean the lack of routing or something else?
      - my69thaccount 4y ago
        SPAs reimplement accessibility features in JavaScript to the best of their ability. This has created an arms race where screen readers need to execute JavaScript and use heuristics to determine what's on the a page. Everyone who down voted me is a total idiot.
        shitlord 4y ago
        I worked at a large tech company replacing an internal MPA website with a SPA replacement. The MPA website was built in the 2000s, it was unmaintainable, and it was generally duct-taped together. The SPA website was new, shiny, and build on the hottest technologies at the time. But screen readers had a hard time understanding the SPA. Where the MPA favored simplicity and used <select> elements for its dropdowns, the SPA used a custom component that consisted of <div> soup with some JS. It took considerable effort to make the SPA friendly to screen readers. I'm not convinced that the SPA architecture was the source of the problem. A MPA with <div> soup everywhere would have had the same problem. However, these sorts of issues seem to be more common in SPA than MPA. There might be some correlation between using SPA architecture and reckless overindulgence.
andybak 4y ago
> Reading HN you'd think 99% of development is landing pages and blogs. I would have said "Reading HN you'd think 99% of web sites are web apps". Most of the web is content with a light smattering of interactivity > They love the interactivity and quickness of a SPA. It's very easy to avoid the full page load without needing to go full-on SPA. > I have no idea why I'd go back to having to maintain a JS entry point per page I'm not sure what you mean here. "Progressive enhancement" was an excellent idea that didn't stick around for long enough.
- rahilb 4y ago
  The grand parent comment is likely referring to ‘deep web’ apps that you or I will never see, which probably replace a series of excel spreadsheets and email conversations.
- ebiester 4y ago
  This is where I think the confusion lies. When I think of the tools that my teams build, they effectively are internal and external tools that happen to use the browser as a platform because nobody was able to converge on a universally-installed tool like java web start. Web applications proliferate because it entirely circumvented the problems of installing software. The places people are most enamored with SPAs are tools that effectively replace desktop applications. Consider Jira or Trello. These are effectively applications that happen to live in the browser. If you built progressive enhancement on trello, it would effectively mean building a parallel application. Multiple page applications do not have the ecosystem to make these tools easier to build. I have built these applications before SPAs became the dominant modality and after. The MPA has a long way to go to make this a good experience. Now I think it's great that content apps are moving away from SPAs. I think the only reason that people did this was to avoid the white flash, frankly, and I'm glad that chrome has solved this. I hope nobody is using react to build their content in 2022. However, we have a long way to go before MPAs could replace SPAs in web applications. (And frankly, that time would have been better spent in building a tool that is truly fit for purpose rather than overloading the browser DOM, but I fear that ship has sailed.)
  - 4y ago
eyelidlessness 4y ago
You should take a look at the frameworks mentioned in the article. They each address some or all of your concerns. The distinction here isn’t going back to “old school” MPA development, but a trend in component frameworks towards shipping more truly static HTML and less unnecessary JS. For the landing page/blog type experience, Astro is a great fit. Qwik is probably a better fit for your use cases as it’s intended for more interactive apps. But both can span that interactivity spectrum. I can’t speak to where Elder fits on that spectrum, not having used it and having little experience with Svelte. I’m disappointed not to see Marko mentioned, as it’s been in this category for years and used at scale at eBay. It fits very well in the middle of the interactivity spectrum. Anyway, it’s worth checking all of them out just to even see what’s happening in the ecosystem. I’m personally very interested in Qwik‘s familiar React-like DX with what they call “resumability”: their alternative to hydration; components compile to fine grained chunks and resume from state serialized to HTML, rather than re-running the original component on load.
- BigJono 4y ago
  No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. People need to stop bringing in that complexity when they don't need server rendering. This is basic software engineering shit, and it boggles me that the industry can't get it right. Same kind of code goes in the same place and runs in the same context unless you specifically need to do otherwise. No reason not to route and render on either the client or the server unless you absolutely need both. Trying to get fancy is how you end up with a truckload of bugs you wouldn't have otherwise had. I've been on like 5 projects that have spent months dicking around with Next or Nuxt or Gatsby or whatever rubbish, lighting client money on fire, for a portal behind a login that doesn't need to be indexed and would work totally fine as an SPA.
  - eyelidlessness 4y ago
    > No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. Should was probably too strongly phrased, shouldn’t definitely is. The suggestion wasn’t “hey go learn a new framework, your current solution isn’t up to date” or whatever. It was really, very sincerely, “the frameworks discussed in article agree with you, you oughta keep an open mind”. Encouraging both a general, and clear area of interest, spirit of curiosity. I don’t get the sense that you have or want that curiosity on the topic, by all means stick with what’s working and carry on. If your comment was paired with downvote, I do want to thank you for the comment. It’s refreshing to get a perspective on why someone didn’t like something I said, when I wouldn’t have that insight otherwise.
baisq 4y ago
SPAs are quicker because you use slow server-side languages that take a century to render an HTML template.
linkjuice4all 4y ago
I've been mixing React with static exports from WordPress. It's unbelievable to say that I actually like this solution after spending years and years with PHP, custom JS front ends, then jQuery and the backend frameworks. React continues to get better and is great for highly interactive and customized experiences. Browsers are also making it more usable so it's just up to the front end devs to make sure history state and other stuff is accounted for. WordPress continues to be terrible but accessible to the masses for your landing page and blog stuff. That means your design and content team don't get bogged down in the app dev process and you don't have React slinging fixed/static content. They can just bash stuff around in WordPress and export the static pages for a quick deploy.
- purplerabbit 4y ago
  What do you mean by “static exports from WordPress”? (never used WordPress before)
  - linkjuice4all 4y ago
    The Simply Static[0] plug-in exports all of your WordPress pages and assets into a directory that you can deploy. It basically renders the entire site and takes a snapshot of the rendered HTML. You'll lose dynamic features (but ideally you'll be doing that stuff in your React app) but the static site is very quick and you'll avoid some of the security headaches of a public WordPress instance. [0] https://wordpress.org/plugins/simply-static/ https://wordpress.org/plugins/simply-static/
deleted 4y ago
[deleted]
jhgb 4y ago
Are you sure that something like PJAX wouldn't bring you like 80% along the way from MPAs to SPAs, as far as "interactivity and quickness" is concerned? Or did you already try that?
sanderjd 4y ago
I relate to this so hard. It's hard to know what other people work on, but I haven't worked on a web site in over a decade, and it's just honestly hard for me to relate to people who can't understand the user experience benefits of within-page interactivity.

timw4mail 4y ago

When is a SPA quick? I still have yet to see this claim EVER be true.

kkirsche 4y ago
Define what quick means to you. They can be extremely good at responsiveness and background updates once the bundle has been loaded
sibit 4y ago
I've spent the last 2 years building B2B SPAs and, like everything in software, they can be fast or slow depending on how you build the app and what tools you use. I usually leverage lit-html, esmodules, and the dynamic import syntax. If you only fetch the business logic and views when you need them you can have an app that renders in seconds with an initial payload of ~15kb. I usually also set up a service worker to prefetch and cache the rest of the site while cache busting specific files on subsequent visits. Personally I use SPAs for offline support and MPAs for "portals" and brochure/marketing websites or blogs.
- treis 4y ago
  >that renders in seconds That's really long.
  - sibit 4y ago
    Oh geese, I didn't realize that I forgot to add "on slow-3g". We usually aim for <1s FCP & <2s LCP. If it's ever above 5s on slow-3g we set aside time to optimize/refactor. Since our SPAs are offline-first the return visits (usually 3-5 times a day based on the customer) is on the scale of milliseconds.
    - treis 4y ago
      Even still. A 3g connection is a bit under half a MB a second. That's a lot of data for something that is mostly text.
      - sibit 4y ago
        I feel like we're just spinning in circles trying to define "fast" and what speeds are "acceptable" when the main point was: > SPAs for offline support and MPAs for everything else You could build MPAs that offer offline support (and I have) but I find that you spend a lot of time writing the same render logic twice. Things might be different now with Next/Nuxt but when you're using PHP or C# it sucks to write the view render logic twice.
steve_adams_86 4y ago
Prefetching content means you can literally load a new page instantly without rendering anything but the new content. It is inherently faster once the initial page has loaded, and the JS no longer needs to be all that large to accomplish it. Like any technology, using it in the right place helps. This is great for documentation where the template and content slots are super consistent, for example. There are places it’s not a great choice. It isn’t inherently worse, though.
- rcxdude 4y ago
  This is the theory, and yet in practice my experience is almost always the opposite: MPAs load and render quickly and are responsive during use, SPAs are slow to load and render and often chug substantially. Some of the better SPA manage to beat mediocre MPA implementations, but it's not super common. I don't know how it so frequently gets screwed up so badly, but it's a really consistent trend (and this is across fast desktops with a good internet connection to mobile devices with not-so-great signal). For example, hacker news is way, way more usable to me than new reddit (which actually renders my browser unusable on a high end machine after some use).
  - hinkley 4y ago
    The impedance mismatch always seems to boil down to the fact that we have been told umpteen million times that most people end up on your website with a nearly completely evicted cache, and we (or at least, the people who resist) don't seem to believe it. This is pretty much the default and a given for everyone who visits your site... except you. As the author, you likely use your application more than most users, you use it on a work machine (which has a smaller, more niche browser history), and you use it with the sort of network connection that software developers demand: you know, excessive. We see what we expect to see, what we want to see, and most of us don't challenge that, or only do it perfunctorily. And if someone else does? Well that's just crazy talk. See? Everything is fine.
- tatersolid 4y ago
  Our B2B SaaS apps are SPA and preload static assets in the background on the login screen, including the top 90% of used js, templates, and icons (simple to find via http log analysis). This improves the end-user perception of performance dramatically. Accessibility with said SPAs is still a pain though. Even when you use correct semantic elements instead of DIV soup, the DOM usable by screen readers changes “out-of-order” frequently in SPAs, requiring lots of extra work to ensure an accessible experience.
robertoandred 4y ago
https://reactjs.org/docs/getting-started.html https://reactjs.org/docs/getting-started.html is a fast SPA
- exodust 4y ago
  It's just text.

jabart 4y ago

If your non-spa app requires a page load per an operation, my opinion is someone built it wrong. You can do a lot with < 200 lines of JS to make a page interactive. Legacy apps were rebuilt as SPAs and rebuilding them made them faster. "Spinning wheel of doom" is used by users now to describe delays in both SPA and non-spa web applications. Same tricks to make a SPA feel responsive work for both styles.

cjbgkagh 4y ago
I find the more interactions I add to a non-SPA the more SPA like it becomes.
- sanderjd 4y ago
  Yep, but with ever-more wheel reinvention.
dymk 4y ago
In 200 lines of JS, you can add maybe an interactive file uploader, or a tooltip implementation, and some form validation. But good luck doing anything of "business-tool" complexity in 200 lines that constitutes an application.
- Spivak 4y ago
  Yeah I’m so confused what people think “interactivity” even means, like do people think interaction ends at “make the hamburger menu open and close?”
  - TedDoesntTalk 4y ago
    Dynamically replacing a div, based on a DOM event, with results of a fetch call can be done in way less than 200 lines of JS. But why you’d do that instead of using 10 MB of React code, I don’t know.
    - dymk 4y ago

my69thaccount 4y ago

Do your clients have any accessibility needs?

Etheryte 4y ago
Accessibility has nothing to do whether your page is cut up in one way or another. You can build accessible pages that are SPA and unaccessible pages in any other way all the same. Most if not all accessibility issues stem from lack of education on the matter, rather than technical limitations.
- my69thaccount 4y ago
  SPAs are inaccessible by default.
  - azemetre 4y ago
    Could you expand upon this? Do you mean the lack of routing or something else?
    - my69thaccount 4y ago
      SPAs reimplement accessibility features in JavaScript to the best of their ability. This has created an arms race where screen readers need to execute JavaScript and use heuristics to determine what's on the a page. Everyone who down voted me is a total idiot.
      - shitlord 4y ago
        I worked at a large tech company replacing an internal MPA website with a SPA replacement. The MPA website was built in the 2000s, it was unmaintainable, and it was generally duct-taped together. The SPA website was new, shiny, and build on the hottest technologies at the time. But screen readers had a hard time understanding the SPA. Where the MPA favored simplicity and used <select> elements for its dropdowns, the SPA used a custom component that consisted of <div> soup with some JS. It took considerable effort to make the SPA friendly to screen readers. I'm not convinced that the SPA architecture was the source of the problem. A MPA with <div> soup everywhere would have had the same problem. However, these sorts of issues seem to be more common in SPA than MPA. There might be some correlation between using SPA architecture and reckless overindulgence.

andybak 4y ago

> Reading HN you'd think 99% of development is landing pages and blogs. I would have said "Reading HN you'd think 99% of web sites are web apps". Most of the web is content with a light smattering of interactivity > They love the interactivity and quickness of a SPA. It's very easy to avoid the full page load without needing to go full-on SPA. > I have no idea why I'd go back to having to maintain a JS entry point per page I'm not sure what you mean here. "Progressive enhancement" was an excellent idea that didn't stick around for long enough.

rahilb 4y ago
The grand parent comment is likely referring to ‘deep web’ apps that you or I will never see, which probably replace a series of excel spreadsheets and email conversations.
ebiester 4y ago
This is where I think the confusion lies. When I think of the tools that my teams build, they effectively are internal and external tools that happen to use the browser as a platform because nobody was able to converge on a universally-installed tool like java web start. Web applications proliferate because it entirely circumvented the problems of installing software. The places people are most enamored with SPAs are tools that effectively replace desktop applications. Consider Jira or Trello. These are effectively applications that happen to live in the browser. If you built progressive enhancement on trello, it would effectively mean building a parallel application. Multiple page applications do not have the ecosystem to make these tools easier to build. I have built these applications before SPAs became the dominant modality and after. The MPA has a long way to go to make this a good experience. Now I think it's great that content apps are moving away from SPAs. I think the only reason that people did this was to avoid the white flash, frankly, and I'm glad that chrome has solved this. I hope nobody is using react to build their content in 2022. However, we have a long way to go before MPAs could replace SPAs in web applications. (And frankly, that time would have been better spent in building a tool that is truly fit for purpose rather than overloading the browser DOM, but I fear that ship has sailed.)
- 4y ago

eyelidlessness 4y ago

You should take a look at the frameworks mentioned in the article. They each address some or all of your concerns. The distinction here isn’t going back to “old school” MPA development, but a trend in component frameworks towards shipping more truly static HTML and less unnecessary JS. For the landing page/blog type experience, Astro is a great fit. Qwik is probably a better fit for your use cases as it’s intended for more interactive apps. But both can span that interactivity spectrum. I can’t speak to where Elder fits on that spectrum, not having used it and having little experience with Svelte. I’m disappointed not to see Marko mentioned, as it’s been in this category for years and used at scale at eBay. It fits very well in the middle of the interactivity spectrum. Anyway, it’s worth checking all of them out just to even see what’s happening in the ecosystem. I’m personally very interested in Qwik‘s familiar React-like DX with what they call “resumability”: their alternative to hydration; components compile to fine grained chunks and resume from state serialized to HTML, rather than re-running the original component on load.

BigJono 4y ago
No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. People need to stop bringing in that complexity when they don't need server rendering. This is basic software engineering shit, and it boggles me that the industry can't get it right. Same kind of code goes in the same place and runs in the same context unless you specifically need to do otherwise. No reason not to route and render on either the client or the server unless you absolutely need both. Trying to get fancy is how you end up with a truckload of bugs you wouldn't have otherwise had. I've been on like 5 projects that have spent months dicking around with Next or Nuxt or Gatsby or whatever rubbish, lighting client money on fire, for a portal behind a login that doesn't need to be indexed and would work totally fine as an SPA.
- eyelidlessness 4y ago
  > No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. Should was probably too strongly phrased, shouldn’t definitely is. The suggestion wasn’t “hey go learn a new framework, your current solution isn’t up to date” or whatever. It was really, very sincerely, “the frameworks discussed in article agree with you, you oughta keep an open mind”. Encouraging both a general, and clear area of interest, spirit of curiosity. I don’t get the sense that you have or want that curiosity on the topic, by all means stick with what’s working and carry on. If your comment was paired with downvote, I do want to thank you for the comment. It’s refreshing to get a perspective on why someone didn’t like something I said, when I wouldn’t have that insight otherwise.

baisq 4y ago

SPAs are quicker because you use slow server-side languages that take a century to render an HTML template.

linkjuice4all 4y ago

I've been mixing React with static exports from WordPress. It's unbelievable to say that I actually like this solution after spending years and years with PHP, custom JS front ends, then jQuery and the backend frameworks. React continues to get better and is great for highly interactive and customized experiences. Browsers are also making it more usable so it's just up to the front end devs to make sure history state and other stuff is accounted for. WordPress continues to be terrible but accessible to the masses for your landing page and blog stuff. That means your design and content team don't get bogged down in the app dev process and you don't have React slinging fixed/static content. They can just bash stuff around in WordPress and export the static pages for a quick deploy.

purplerabbit 4y ago
What do you mean by “static exports from WordPress”? (never used WordPress before)
- linkjuice4all 4y ago
  The Simply Static[0] plug-in exports all of your WordPress pages and assets into a directory that you can deploy. It basically renders the entire site and takes a snapshot of the rendered HTML. You'll lose dynamic features (but ideally you'll be doing that stuff in your React app) but the static site is very quick and you'll avoid some of the security headaches of a public WordPress instance. [0] https://wordpress.org/plugins/simply-static/ https://wordpress.org/plugins/simply-static/

deleted 4y ago

[deleted]

jhgb 4y ago

Are you sure that something like PJAX wouldn't bring you like 80% along the way from MPAs to SPAs, as far as "interactivity and quickness" is concerned? Or did you already try that?

sanderjd 4y ago

I relate to this so hard. It's hard to know what other people work on, but I haven't worked on a web site in over a decade, and it's just honestly hard for me to relate to people who can't understand the user experience benefits of within-page interactivity.