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.
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.
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.
> 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.
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.
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.
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.)
I think there is a mismatch between the types of web content that the general public most interacts with and the types of web content which tend to have lots of development resources devoted to them. The ratio of SWEs to users is much, much higher for niche (typically B2B or internal business line) applications, which often require a fair amount of interactivity and custom logic. Whereas the vast majority of random web content used by the general public probably can just be hosted as static sites or server-side rendered apps with better performance and lower cost. HN then just reflects the underlying demographics of the industry and has a disproportionate number of people who work on niche applications where SPAs are still the more appropriate tool.
Which makes sense given the economics. Consumer facing content is generally free to users and funded by ads so the dev costs need to be amortized across more content, which tends toward a lower touch, more scalable approach like static pages where there isn’t much if any custom logic on any given page of content. Businesses on the other hand are willing to fork over cash directly to solve their problems so you get higher touch, more custom solutions where SPAs are relatively more useful.
Also software engineering by its very nature automates routine tasks, reducing their costs and manual complexity dramatically over time to the point that a SWE isn’t needed to carry them out. So none of us work on static sites because at this point it doesn’t take a highly skilled engineer to set up, host, and scale one. One day SPAs and cloud native and k8s and all the latest fads may reach the same level of simplicity, and we will all be working on tuning hyper parameters on ML models or whatever else becomes the de facto cutting edge for the field.
I mean why wouldn’t you? Degenerate React — a mostly static content “chrome” replacing the “layout.html.erb” and a component to render content from an API based entirely on the route replacing “article.html.erb” still is way faster than your average site. Slower then the equivalent SSR but ehh.
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.
Most of the web is content, but websites rarely are SPAs. If you only consume content you would hardly know about the concept of SPAs.
I think it's weird to compare websites with web apps. Instead web apps should be compared to desktop applications. So many applications in the corporates have been replaced by web apps. In the company I work for there are 0 "desktop" applications other than Office, and even those applications you can use using a web browser. Then you see a massive shift and that balance is not shifting away at all.
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.
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.
Not really. IMO, people are using large dependencies for things that can be implemented with a few lines of JS or even no JS at all. Doing things for the sake of complexity. The whole point is that X, Y and Z aren't needed.
What is the point? Optimizing for lines of code is a wasteful target. I thought we all knew that by now? Great that you can demonstrate that you can do something without React where others are using React, but that's not the point at all.
If you do more than a few asynchronous calls you will quickly find yourself developing your own DOM abstraction. That's a waste of time because React and Vue already exist, and have existed for years, and are battle tested.
SPA frameworks also give you the ability to write your applications in a declarative way, which is _far_ easier and way less error prone, thus easier to test, than imperative DOM modifications.
Its more like the time to become interactive. Even if internet and smarphones are fast. Sometimes it's pretty annoying to click an unresponsive page... just because it's loading-starting a lot of js
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.
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?
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.
Agreed. One of our employees is visually impaired, and it is shocking how many Spas are entirely incompatible with a screen reader and standard keyboard nav. With a MPA, most of the things that a screenreader needs come for 'free' just by being standard components. When everything is wrapped in JS and is slightly different for each page, it's frustrating.
We have changed quite a bit of our software systems in the past 1.5 years, and I have dropped multiple vendors from consideration over accessibility. Many B2B SaaS salespeople just give you a blank look if you ask about usability for a blind user.
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.
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.
Every mainstream desktop ui framework out there has standard, evolving out-of-box set of controls and layout widgets that do not suck. Guess what, you can build Gtk, Qt or Wx app without wrapping inputs into stacks of divs, which aren’t there for layout. People even barely know how to create new controls or containers. The deepest container depth for a regular app is like 5-7 there, and that’s a complex layout already with bells and whistles. Web does suck a lot in this regard, so people reimplement this functionality in javascript and div soup, as the other commenter mentioned. While your statement is true, the idiots here are the web standards which stuck in 1990s and never realized that this “apps” thing everyone’s running around with for a decade or soon two is something more than a printable document with font sizes and empty fields split into sections and paragraphs. If web did care, it would at least add accessibility-only tags (or a separate structure like css does) denoting what’s where and how to interact with it or how to dumb it down to whatever plain set of controls would be there, if the web ui model didn’t suck. The stockholm syndrome it induced in software development is truly tremendous.
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.
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.
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.
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.
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).
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.
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.
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.