26 ms·

The balance has shifted away from SPAs

486 points by feross 4y ago

scollet 4y ago
I appreciate the accessible aspects, but the browser is not a panacea. Not that the industry is invested in accessibility out of benevolence. I feel like we're holding up the hard/firmware side of things here.
amelius 4y ago
To me it seems more like the balance has shifted to native apps, unfortunately.
- LAC-Tech 4y ago
  really? I barely ever use native apps anymore. even if the mobile webpages nag me to.
  - amelius 4y ago
    I think young people mostly prefer these apps. And there's a reason why companies nag you.
encoderer 4y ago
These are interesting developments in the browser! Still, I don’t think this headline conclusion is supported by the facts in the article. Of course “balance” in this context is basically meaningless but if you replace it with “consensus” it does mean something, and it’s clearly not correct: the article makes clear we are still adding critical support at the browser level. Possibly, this will result in a renaissance of multi page apps, but we have to wait and see.
adamnemecek 4y ago
I have been reading articles like this for the last 10 years. I'm not sure why people complain about SPAs. Guess what, in the mean time as some MPA frameworks have been made, the whole web has been moving towards webassembly. Say goodbye to MPA HTML, say hello to Rust with custom UI based on WebGPU transpiled to webassembly.
- oblak 4y ago
  As a JS developer, I think this is correct and kind of fear for my future. Time for this old dawg to learn something new again. Thing is, I think I am not good enough for system level programming. I've only done rust to the extend of going just a step beyond "hello world". I've also read good things about Go. Decisions, decisions.
  - adamnemecek 4y ago
    > think I am not good enough for system level programming I think that this is the wrong way to think about it, the languages and tools for systems programming suck. I would recommend you check out Rust, it make systems programming really pleasant. Like I have been programming C++ for 25 years and somehow I'm a lot more comfortable with writing Rust even though I have seriously written Rust for only like 1.5 years.
- teg4n_ 4y ago
  It really hasn’t been moving towards web assembly. Web assembly is not magic performance pixie dust and it generally has pretty bad bundle size. You need pretty specific scenarios to get genuine improvements with web assembly over JavaScript.
  - adamnemecek 4y ago
    > magic performance pixie dust It is. I can finally have value types which let me access properties without incurring the overhead of a JIT. > and it generally has pretty bad bundle size For now. So do websites btw.
- Hayvok 4y ago
  > I'm not sure why people complain about SPAs. … say hello to Rust with custom UI based on WebGPU transpiled to webassembly If this is the future, then no wonder everyone is running back to just shipping HTML over the wire. All this has gotten too complicated.
  - 4y ago
nightski 4y ago
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.
TekMol 4y ago
Where are those SPAs everybody is talking about? All sites I use regularly are MPAs: Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub ... Reddits new design is kind of a hybrid. It is MPA when you hop between subreddits and other pages. But it shows a post on the same page when you click on it in a subreddit feed. I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something, that the only "somewhat SPA" I know makes me switch to its MPA version regularly.
- manmal 4y ago
  Was AirBnB not one of the first companies to champion server-side rendering of React apps? I think you’re listing apps that are actually a bunch of SPAs glued together (each page is super complex and an SPA of its own right).
  - TekMol 4y ago
    On AirBnB, you search for a location on the homepage and then you go to a new page, the map page. Which is a bit SPAish because it reloads apartments when you move the map. Then when you click on an apartment, you go to a new page, the apartment page. Overall, I would count that as MPA? The apartment pages seem to be client side rendered. When I CTRL+u and look a the source code, I see a lot of JSON and not much HTML.
  - marcosdumay 4y ago
    Hum... > Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub I don't know about AirBnB. Booking has a little bit of interactivity that is more annoying than helpful¹, like the GP's example for Reddit. None of the others can be described as "applications". 1 - The map is good. The stuff on the map is very good. The map itself is an SPA. For all the rest of the site, if they removed all the Javascript it wold be an improvement.
  - AlchemistCamp 4y ago
    It wasn't React, but Spike Brehm gave a lot of talks about Airbnb moving to "isomorphic JavaScript" with a library he created. It was called Rendr and it basically let you stitch together Backbone and Node and share code between the client and the server. I remember being pretty interested in it at the time. https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-librar/ https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-...
endisneigh 4y ago
So much whining about SPAs. A properly written SPA is very performant and really doesn't have huge differences compared to MPA. If anything the only thing that's changed is people understand how to properly write a SPA and JavaScript web development is finally reaching a period of some level of stability. It really depends on what you're trying to do. Want a fully offline app? Good luck without SPA.
- deleted 4y ago
  [deleted]
- andybak 4y ago
  > A properly written SPA is very performant and really doesn't have huge differences compared to MPA. Maybe true but in the wild the vast majority of websites manage to fall down on one or both of these. So either it's hard to "properly write" an SPA or something else is going wrong.
  - endisneigh 4y ago
    Most sites are generally flawed in some sense. SPA is just a red herring.
- nomilk 4y ago
  > A properly written SPA is very performant SPAs should offer better UX (by reducing full page loads), but at the expensive of developer hours. Curious to hear what the difference in development time is from anyone who made the same app as a MPA and later as a SPA. I'd guess to make the same app as a SPA would take around 2-3 times as long.
  - BackBlast 4y ago
    My experience is the opposite. I say that from a career that is dominated by backend experience. In any application, you have to have a good front end. To most users the app/page is the UI. Having the majority of your concerns in one place will help you develop with smaller teams. Certain SPA architectures can bring nearly ALL of the concerns into the front end. Particularly with databases that are simply port open to the world like say couchdb. Your backend needs almost effectively disappear. If this is a reasonable data model, SPA looks and feels much faster to use and develop. When you attach a backend, you often attach other specialists, languages, techs (python, ruby, Java). Have to deal with separate teams, which often means a formal API and all the handshaking between. This pretty much triples the required work with development and the communication overhead.
randomtwiddler 4y ago
Stop griping about SPAs. Local compute is powerful and lower latency than the data center across the country or world. Page weight isn't that big of a deal, a 2 MB ball of js is nothing compared to the multi megabyte pictures and videos people routinely add to pages. For some use cases MPA is fine, but in many cases it's actively worse and higher dev costs to boot. Service workers are an interesting middle ground I think should see more attention and development. I like to combine service workers with SPAs for fully offline capable web apps.
- deleted 4y ago
  [deleted]
- jhgb 4y ago
  > Page weight isn't that big of a deal, a 2 MB ball of js is nothing compared to the multi megabyte pictures and videos people routinely add to pages. That's a good argument if you're one of the people adding multi megabyte pictures and videos to your pages, but I'd bet that if page size is of concern to you, you're not one of them, so "a 2 MB ball of js" would suddenly become your weakest link.
  - randomtwiddler 4y ago
    You say "weakest link" like there is an optimum. People are regularly downloading 4k video. By choice, they want to be doing this. Amazon is one of the most successful websites ever created and last I checked came in at over 12MB page weight. Mostly highly optimized images. I'm sure they wrangle and agonize what shows up there. There's a limit somewhere, but pointing the finger at a ball of js that compresses to less than 500k isn't particularly reasonable. User experience is more about latency. Be it from local compute or remote compute+network. If your visitors are one and done you must SSR at a minimum. Because that will drive the average latency of the majority of user experience. If they are long term users, you should seriously look at user local data and potentially full offline functionality that can mask even poor 3g performance and spotty networks. Making users suffer long term through an MPA architecture is silly.
- cyral 4y ago
marcthe12 4y ago
I do agree alot with the article. One of the major use case SPAs was optimization hack that service worker can do easily. Service worker are like proxy middleware and are capable of some nifty tricks. Since I am not in web dev that much so I never actually managed to develop a project using it, but I felt that the templating could done fully in service worker. It will be faster as long the templating/transcompiling is not a bottleneck as the on wire format will be smaller. The main issue will be bootstrapping as you need to load a page first to install the service worker. I wonder if there is a good solution to that? (One idea is a service worker middleware on node so you can the service worker in the server side on first time use).
- nolanl 4y ago
  (Author here.) I totally agree and feel that Service Workers are still underexplored in this area. If your main reason for writing an SPA is speeding up navigation (e.g. the Turbolinks approach), then you may be better served by just moving the rendering logic into a Service Worker. It should be possible to build an "MPA" where all the rendering logic lives in the Service Worker. Then you'd get fast navigations without needing to worry about a client-side router and managing focus/scroll/etc. I'm not sure I've seen a great implementation of this though.
  - keybits 4y ago
    Here’s a great example of how this can be done https://instantmultipageapp.com/ https://instantmultipageapp.com/
    - nolanl 4y ago
      Thank you! This is exactly what I had in mind. The streaming aspect of MPA pages is a great example of something you can't really do in an SPA. (Although there are hacks: https://jakearchibald.com/2016/fun-hacks-faster-content/ https://jakearchibald.com/2016/fun-hacks-faster-content/)
throwaway4good 4y ago
For internal apps in the corporate world, all I see now is SPAs based on vue react or angular. For consumer facing websites, where search engine viz is a concern and less is known about the clients browser, maybe it is different.
VWWHFSfQ 4y ago
I think nearly every spa I've ever used was a piece of crap. There is just something off about them. It's almost like it's missing tactile feedback or something. And there's always goofy stuff that just doesn't work half the time. Like middle click to open a link in a new tab. So anyway. Good riddance
- dymk 4y ago
  SPAs are like visual effects. You don't notice the good ones, because they just work. It's when they're poorly implemented that you notice they're SPAs. It's just a form of survivorship bias.
  - cypress66 4y ago
    I assume you meant "You don't notice the good ones"?
    - dymk 4y ago
      Indeed!
matchagaucho 4y ago
"Headless CMS" is simultaneously all the rage (API first content management). If I had to generalize in broad strokes, decoupling the front-end from back-end using SPAs will be far more practical in B2B use cases. While consumer apps will benefit from MPA/SSR (server side render) where one page per product is easier to manage and bookmark.
B1FF_PSUVM 4y ago
What happened to defining acronyms in texts? Any civilians coming across this can't even find out what it is by searching unless they tack "software" after the word.
- deleted 4y ago
  [deleted]
kaycebasques 4y ago
Discussions about website architecture become a lot more productive when you use Jason Miller's holotypes idea [1] as your starting point. "Holotypes" is kinda just a fancy word for the common top-level uses of the web. E-commerce, search, media player, etc. With that foundation it becomes obvious that SPAs make a lot of sense for some holotypes and a lot less sense for others. We waste time when we talk as if MPA or SPA is appropriate for all website architectures because neither are and never will be. The uses of the web are just too broad at this point. [1] https://jasonformat.com/application-holotypes/ https://jasonformat.com/application-holotypes/
- vosper 4y ago
  Thanks for this, I liked it. I’d recommend anyone who’s posted for/against some web practice to read it. Maybe one day we could all collectively acknowledge that people work on different stuff, with different goals and under different constraints, and there isn’t actually one right way to build for the web. It’s such a tiresome part of HN.
  - dylan604 4y ago
    Yes, just like _____ written in [Go|Rust|flavoflav]. However, at the beginning of every project, this conversation should be had. What are the needs of the project, what gets us there fast while still allowing to grow after scopecreep, what is going to allow for maintanence and future needs? Picking the latest tech just because it's a new project and you want to use the NEW on it just for the sake of it will probably mean finding yourself painted in a corner in the future (or maybe not the original dev, but those that are forced to follow).
    - vosper 4y ago
      Of course, a discussion should be had, choices should be weighed. But since you mentioned “new just for the sake of it” I’ll mention that I think that’s overplayed, too. If you picked React when it was new, or GraphQL, or NextJS, then you probably made a pretty good choice. Backbone was the first of the modern MVC frameworks to get traction (someone will correct me on this) and if you’d chosen that when it was new it would also have been a pretty good decision. Kafka’s still around and going strong, wouldn’t have been a bad choice early-on.
mgaunard 4y ago
People fail to realize that these silly one page websites were invented because they're easier to consume on mobile. Just ask yourself who your users are and what workflow makes sense for them, and build something accordingly.
mrtksn 4y ago
SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore. The client devices are very capable and the networks are fast, it's very logical to offload the rendering to the client. I doubt that MPA is coming back but for things that don't need to be SPA in first place, going back to being MPA is reasonable.
- jhgb 4y ago
  > SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore. That feels like creative accounting of code to me. Is the rendering really simpler, or does it merely happen in a different place?
  - mrtksn 4y ago
    Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases. For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.
    - jhgb 4y ago
      > the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). Drawing a circle artificially around a portion of your code and saying "look, now the circled part doesn't need to change!" feels like creative accounting to me as well. If you have multiple clients, the code for multiple clients still has to live somewhere, so it's not like the whole system that you need to build is getting simpler. Pretty much the only actual difference I can see here is the ability to use more of client's CPU time to run your applications. I'm sure there's applications that could profit from that. > For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. But if you don't do your logic in JS but do it in PHP on the server, you don't need a JS person. And if you were using Seaside, you wouldn't need an HTML/CSS person since everything would be just Smalltalk at that point. It's again just moving stuff around, but someone still has to do that. I guess one situation where this argument might apply would be if one of the two language options was difficult to hire for. > You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side. Not even this argument seems any less artificial to me, since if you're ditching something, I'm not quite sure why it matters where you ditch it from -- unless you have no control over one of the sides. In that particular case, I could see this as an argument. If you're forced to do a client for an already existing server, you're obviously justified in doing a pure client-side solution for anything that doesn't exist on the server yet. If you're building your own server, this limitation is removed.
88913527 4y ago
As someone who works on design systems, I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components, and you can use tools like Storybook to run visual regression tests without standing up your full environment. I know I'm speaking tactically here, but a shift away from SPAs seems like a loss for shared UI components and design consistency. I can't just give a CSS file (which is portable across tech stacks) and leave it to engineers to write accessible HTML; there's huge value-add in isolating a11y in something like a React component abstraction.
- bestinterest 4y ago
  My issue with design systems is that inevitably the team using the internal companies design system has to implement custom components (usually early on) and try to match the feel of the design system already in place. I'd rather go custom for a project and semi match the already in place feel of the company's UI standards. Then we're only bottle necked by our internal team and not an external team. Thinking more on this, I'd love the https://tailwindcomponents.com https://tailwindcomponents.com setup for internal design components? Seems like the best of both worlds but does move the base from React/Angular components to Tailwindcss
- adrianmsmith 4y ago
  > I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components That's true, but if your various teams are allowed to use various server-side programming languages and frameworks, what's to say they're not allowed to use various client-side frameworks as well? E.g. one team uses Angular, the other React, the other Vue, etc. Then you're back to having the same problem.
- regularfry 4y ago
  "Everything is simpler if we all use MY tool." I get it, there's a sort of lowest-common-denominator argument going on here, but it is still an enforced consistency which ignores the benefits of giving teams the freedom to choose the best tool for their specific job.
darepublic 4y ago
Yes to static prerendered pages. Yes to performance and functionality on slow networks. No thanks to "hip new frameworks"
- LAC-Tech 4y ago
  Unless by "hip" they mean "smaller, more powerful, better abstractions". Not writing a bloody wrapper over express.js...
jcmontx 4y ago
Can anyone point me in the direction of any SPA framework well integrated with a backend framework that can make me as productive as Django, Laravel or Rails?
- vosper 4y ago
  It’s hard to know hot productive you are in those frameworks, but I’ll take your question at face value: if you were an expert with NextJS, Typescript, and Prisma or Hasura then you’d be pretty dang productive.
- floucky 4y ago
  SPA just use APIs so most of frameworks are compatible
  - Nextgrid 4y ago
    The problem is that you now need to either make resource-oriented APIs for every model in your DB that your frontend may need to access (even if just for internal business logic) or make RPC-style endpoints that do the business logic. That's significantly more work than just doing whatever logic you want on the server to begin with where you have access to all tables directly (they're an ORM call away) and not have to worry about access control because all of this still happens within the trusted environment of the server.
    - hombre_fatal 4y ago
      Perhaps you could elaborate on what you mean, but from my viewpoint there isn't much daylight between DB-queries in most server-rendered apps vs. SPAs. Instead of this: def endpointAB: a = db.getA() b = db.getB() return template('ab.html', {a=a, b=b}) You tend to have this: def endpointAB: a = db.getA() b = db.getB() return json({a=a, b=b}) When I think of ways you may want to generalize over arbitrary queries on the server, I run into the same challenges you'd have in a SPA rather than fewer.
- tpetry 4y ago
Mikeb85 4y ago
I mean, SPAs were overkill for half the shit they were being developed for. Your average web app is a CRUD app and works better as an SSR app. But there's still use cases for them, they're still a great way to build highly interactive cross platform apps.
- hirvi74 4y ago
  In my experience, one of the biggest benefits of SPAs is that the front-end tends to be a bit more decoupled from the back-end when compared to SSR apps. Now, of course MPAs could be built this way, and plenty probably are, but again, it's not something I have personally seen often.
  - mdavidn 4y ago
    Why is this decoupling important to you? Do you use multiple front-ends or backends?
    - mb7733 4y ago
      I definitely do where I work. Multiple web front ends plus mobile apps.
nathias 4y ago
SPAs themselves have come increasingly towards this with SSR. The next step of web is merging both trends into a framwork that can combine the positives of both, which the libraries in OP seem to be. I'd like to see some comparisons. Edit: After some research I think SvelteKit is going to be the best new thing.
- hirvi74 4y ago
  Doesn't vue.js allow for this in some form with it's low barrier to commitment? I thought it could be implemented via a CDN alone without installing anything. Regardless, I have read one of the biggest benefits to vue's low commitment is that you can use it or forgo it whenever a developer wants, can add it to existing projects, etc.. I will admit that I am far from well-versed in vue, so I could be mistaken.
zkirill 4y ago
Our web product went from AngularJS to React to Angular to Angular + Spring. The addition of Spring helped us introduce a useful constraint: if you can build it as an old-school page with Spring, don't put it into the SPA. Angular is reserved for deep core business logic and UI which would be impractical to build anywhere else. One of the biggest benefits is reducing our Angular project complexity, making it easier to keep current with Angular updates. I am happy to hear that SPAs are no longer sexy because this sounds like the landscape has matured. For example, Angular started doing LTS releases.
- dimgl 4y ago
  This sounds needlessly complicated.
  - zkirill 4y ago
    Maybe, shoot me an email if you want to chat about it kirill at getfillet.com
  - arcturus17 4y ago
    Now your design system is probably all over the place and you have to know two ways to build a view, and have to decide every time which one to use.
    - zkirill 4y ago
      You invented a problem. SPA team and Spring team have separate responsibilities. Our customers don’t care how it looks beyond ergonomics and functionality. It took us a long time to shift away from “SPA all the things” mentality.
davnicwil 4y ago
So I don't think this pendulum backswing is all that surprising or interesting on its own - it's been a journey to discover the edges of the SPA paradigm's capabilities and strengths and a retreat to pragmatism mostly. What I do find quite fascinating is that React actually started out pushing this kind of server rendered, pragmatic pieced-together approach from its very first days. Indeed, because that's exactly what the facebook website required - dynamic additions to a php-like fundamentally server-rendered site. I am not sure if I'm always interpreting this correctly but a lot of blogs I read about server rendering (the buzz TLA for which is now SSR) and the general per-page approach for React apps seem to be attributing the idea of the approach to a few of the newer frameworks that have appeared. Those frameworks are great and package up a load of this goodness, but ironically you don't and have never needed any such wrapping, nor any of the learnings of the SPA era, for any of this. It came out of the box in React before it even hit major version numbers. Somehow, the idea just never seemed to catch.
recursivedoubts 4y ago
thesis: web 1.0 hypermedia-based applications (clunky) antithesis: web 2.0 SPAs using JSON Data APIs (slick, but complex and & web-native) synthesis: web 1.5 apps using hypermedia-oriented libraries like htmx or unpoly (slick, web native)
- bestinterest 4y ago
  Lots of credit for yourself with htmx, its great. I think I prefer unpoly myself but htmx is winning the popularity because of how vocal you are! I wish the unpoly creator also did similar! Both great frameworks. Hotwire also! I wish there was deeper comparisons on the big three
  - recursivedoubts 4y ago
    i always try to mention unpoly unless the discussion is specific to htmx because I agree: it is a wonderful library and henning is a great guy in general. Hotwire probably doesn't need my help, I think dhh has a big enough mic. :)
- robertoandred 4y ago
  None of htmx's modal examples are accessible, doesn't give me confidence it can be used for serious projects.
  - recursivedoubts 4y ago
    if you are willing to jump on the discord, we'd be happy to improve them https://htmx.org/discord https://htmx.org/discord
  - benpate 4y ago
    My dude... I made those in like a day, when I was first getting started with htmx. Accessibility has nothing to do with the language or framework you use. It's about the thing you build with it. If you can build it with Javascript, you can build it with htmx. Give this a try, and see if it's any more accessible -- https://benpate.github.io/hyperscript-widgets/modal/ https://benpate.github.io/hyperscript-widgets/modal/ -- I've learned a bit since those first demos, and have followed every W3C guideline I can find on accessibility to make them. One more thing, I'm nowhere near being an accessibility expert, so I'm positive someone who knows more will have suggestions on how to improve this, too. But it has nothing to do with htmx/hyperscript, and everything to do with me being new at accessibility. Bugs/Suggestions/Pull Requests are always welcome. That's what makes htmx fit for "serious projects." Edited to add: Htmx is a JS-based extension of the natural hypermedia patterns your browser already uses, not a widget library. All of the demos on the site are just that -- demos that show you the kinds of things you can build, and not plug-and-play, ready-for-npm widgets you can just drop into your application without a second thought.
nickreese 4y ago
Author of Elder.js (mentioned in the article) and avid lover of both MPA and SPA. Daily I am writing MPAs for SEO assets and SPAs for internal dashboards used to manage the huge amount if data collection our teams do. It really boils down to what you are building. Google is decidedly terrible about indexing JS for sites with a low crawl budget. Why make your life harder. That is why I wrote Elder.js. Statically generate everything, sprinkle in interactivity where needed. But for internal dashboards I developed a internal framework to spit out crud apps based on nothing more than a couple graphql queries and a couple yupjs validations. It is a breeze and adding new data collection fields takes minutes so I and my team can focus on stuff that drives business value… instead of crud. As with everything picking the right tool for the job makes the job a lot easier. Don’t give into the hype one way or another.
11235813213455 4y ago
something still annoying between navigatng pages normally Vs SPA history API is in first case you lose devtools network/console data from previous page (while developing at least)
- bcyn 4y ago
  Look for a setting named "Preserve logs" to prevent the default behavior of clearing console/network log.
deleted 4y ago
[deleted]
FpUser 4y ago
>"There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago. Hip new frameworks like" I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"? The only thing that matters is how much it costs me to develop solution assuming it satisfies all the constrains imposed by client's specs. The difference makes a profit and this is what I am after. I use SPA when I need real business application and it needs to be delivered in a browser. If SPA becomes too big I make it dynamically load a pieces of needed functionality upon request. By nature is is still SPA and dynamically loaded parts tend to stay in browser's cache anyways. When I need a website I make plain website. I do not turn one into the other.
- Nextgrid 4y ago
  > I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"? You are a minority in a sea of crap whose only goal is to extract more money from investors by dazzling them with buzzwords, "growth & engagement" and engineering playgrounds where complexity is a feature to justify hiring more engineers and make an engineering blog to brag about solving (self-inflicted) problems in order to help hire more engineers. When your objective is to make money by solving clients' problems as opposed to dazzling investors to then beg for their money, the "bill of materials" changes significantly.
  - FpUser 4y ago
    >"You are a minority in a sea of crap" I believe there are countless companies like mine, serving needs of various businesses. We just do not make much noise and hence are not written about.
coding123 4y ago
So can we really claim these as MPAs? This is all using the same architecture of SPAs but it moves it to the backend. Technically that's still an SPA that moved the rendering to the server and instead of shipping JSON and telling the browser to update with the new JSON it's the server sending HTML that the browser is told to replace a part of the screen. It's really just the same thing but with a twist. This is not "MPA" tech, it's SPA tech with new bells and whistles. MPA tech (PHP, CGIBIN, etc..) is dead and not coming back. If the author states this, I would be on board - we're shifting to shipping HTML chunks.
MiscIdeaMaker99 4y ago
What's an SPA?
- kayson 4y ago
  Single page app https://en.m.wikipedia.org/wiki/Single-page_application https://en.m.wikipedia.org/wiki/Single-page_application In the early days of the web, pages were static, and changing content required navigation to a new page (url). Then JavaScript took off and you could dynamically change content on a given page, even reload data without navigating/refreshing. In the extreme, frameworks like react were developed, where you no longer have pages at all. The entire website is rendered on the same page using JavaScript to load all the content on the fly.
  - MiscIdeaMaker99 4y ago
    Thank you very much for telling me what SPA means.
andix 4y ago
I think it greatly depends on what kind of thing you’re building. A „website“ like HN shouldn’t be a SPA But an „app“ like Gmail probably should be.
TrispusAttucks 4y ago
SPAs have been shit since the beginning. It was a wrong path. Thank God the new comers have corrected.
olliej 4y ago
I love how this credits the back/forward cache to chrome when it was a webkit feature chrome inherited. Much like almost every other "chrome" feature other than the process architecture (which was also the actual real engineering work they should have got credit for).
- fartcannon 4y ago
  Webkit is just forked KHTML so credit where credit is due.
  - olliej 4y ago
    The back/forward cache is from apple era webkit, as is a large amount of the basic compat work in webkit. KHTML did a lot of work, but they did not do all of the stuff that made WebKit actually practical as a browser engine - webkit had massive rewrites to get compatibility and performance to anything approaching acceptable. That said the problem I had here in this article was that this article is explicitly crediting a specific feature that predates Chrome to Chrome. The bf-cache is one of the vast amounts of work webkit had done to make khtml a practical engine for real browsing. WebKit at the point chrome forked it had already largely rewritten the DOM, JS engine, Rendering engine, and layout engine. Or you can continue searching HN to make glib questionably accurate and definitely misleading comments in response to things I say because you’re unhappy that someone suggested opencl failed because it was a crappy spec.
    - fartcannon 4y ago
      It looks like KDE is still to this day a primary contributor. Isn't giving Apple credit for the work of a large team, the same thing OP was doing with Chrome? Regarding your accusation, I'll make sure to check who I am replying to and not reply to you anymore. I guess you have interesting counter arguments that encourage discourse. Anyways, keep posting, you're doing a great job.
    - emilsedgh 4y ago
      Konqueror/KHTML was more than "acceptable". It was a fine web browsing experience. You'd barely notice anything wrong with it and it was the first browser to pass ACID 2 tests I think. Saying KHTML wasn't viable/acceptable experience is more misleading to be honest.
gherkinnn 4y ago
The MPA/SPA dichotomy as is often presented is nonsensical. Sites built in Next, Remix, or whatever work perfectly well as MPA. Astro merely goes a step further. Pure SPA (as in a literal single route, maybe with horrible # based routing) is exceedingly rare and mainly found in legacy Angular code bases.
gatvol 4y ago
This is not a binary choice - SPA's remain a valid pattern for the right use case. The point is knowing when to apply the pattern. Aside from that they have some great features, including security; ;they largely reduce the attack surface to supply/dep chain, and an API interface - which is a great pinchpoint at which to apply mitigations, monitoring etc.
- ferdowsi 4y ago
  In what way do Javascript heavy SPAs reduce supply chain attacks vs a no-JS solution?
  - upbeat_general 4y ago
    Just taking a guess: supply chain attacks may occur the same (or even more) but they’re less impactful client side. Makes it easier to have more trusted server-side code and less validated client-side JS.
  - gatvol 4y ago
    That was my assertion, I said the surface for attack included supply chain. As another poster pointers out, that is in fact reduced under some circumstances, since the runtime context is browser side.
zmmmmm 4y ago
They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether it's one page or ten but it does simplify things enormously that I can maintain a single model object and not have to persist it in and out of local storage or even worse have all the complex UI state replicated on the server side to maintain continuity, just because the user clicked a button or something. Especially with reactive frameworks where updating the model automatically triggers re-rendering of the UI everywhere it needs to, a whole piece of complexity in your architecture just goes away.
- my69thaccount 4y ago
  SPAs suck at client side state, they barely work with the back button or scroll bar and if they do its because its reimplemented in JS.
  - nighthawk454 4y ago
    Not browser state, but application state. Lot more boilerplate and glue to do that on server side and ferry it back and forth.
    - infogulch 4y ago
      But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.
      - nighthawk454 4y ago
        No? I simply clarified which state op was referring to. The state of the browser is separate to what's being discussed. SPA's can be good at some state and not others.
devwastaken 4y ago
Imagine if a kde, qt or other native desktop application had to contact a remote server for the actual styled content to render to page. An SPA is the same concept of desktop applications, only get the data, and render it locally. It doesn't make sense for some things and makes sense for others.
immigrantheart 4y ago
If you do dashboards and finance applications (like trading app) or any other app that requires real time and heavy interactivity, you need SPAs. There is no other way around it.
- Existenceblinks 4y ago
  That's very easy with Phoenix LiveView because the data is mostly readonly. Buy and Sell button are super simple.
  - immigrantheart 4y ago
    People don’t want to use Elixir
    - Existenceblinks 4y ago
      people don't want to use anything, people want to use anything. That is your point.
Justsignedup 4y ago
I've been using SPAs to handle lots of complex interactions, and react makes a lot of things quite pleasant that I had to fight with in the past. Having said that, I am very very happy to see technology move forward and give us more options. I am excited about the possibilities. Having many options to solve complex problems in simple ways is a great thing, and old down sides of each are disappearing. Overall. Awesome.
nojvek 4y ago
What is an MPA? Multi platform app?
- julianbuse 4y ago
  It's a multi page app.
mbrodersen 4y ago
Different architectures make sense in different contexts. Whether one is used more than another doesn’t matter one bit. It is not a popularity context.
spinaltap 4y ago
Speaking of Rich Harris, is SvelteKit a good framework to build MPAs? If not, what is? I'm planning to learn SvelteKit in my next side-project. As for "Astro, Qwik, and Elder.js" mentioned in the blogpost, I haven't heard about them.
graycat 4y ago
As a Web user, I urge Web site developers to return to "keep it simple". In particular, multi-page applications are better, easier to understand, than single page applications which tend to be confusing. Treat the pages of the site more like the pages of a book -- those pages don't change as I'm trying to read the book. Net, a single page application looks to me like it has no pages at all, just a lot of confusion where I don't know where I stand, what is the state of my visit, something I can't meaningfully copy or save. Use big 100% black fonts on a white background. In particular, note that about 25% of men are partially red-green color blind. So, if insist on using colors, avoid using both red and green on the same page. Have both vertical and horizontal scroll bars. Never omit either the vertical or the horizontal scroll bars. Accept no substitutes. Similarly, never have a row of images or other blocks of content that scroll off and on the screen left or right via little arrows. With that scrolling, there's no real page I can have in mind. Don't have parts of the page moving or coming and going without explicit user requests. Such Web pages are a good reason just to leave the site. Or, maybe I DO want to look at some of that content -- nope, soon it's jerked from me and gone. Bummer. Don't assume that the user will display the pages at full screen -- often can't have that because need other windows open for the purpose of visiting the Web site at all. Don't cover up what I'm trying to read: So, cut way back on popups, pull-downs, overlays, etc. Design the Web page HTML so that I can save the page and later, without an Internet connection, still have my Web browser display the page correctly. Such saving can be crucial for pages where I've done something important, say, pages summarizing a purchase I just made. Conserve the crucial, vertical space: So, get rid of banners that overlay the content, take up a lot of the vertical space, and come and go as I scroll the page up and down. Apparently as people saw how to do that, doing it became popular as if it were a good idea -- it was a fad and a bad idea. Don't do it. Quanta magazine has done a lot with such banners, and it has seriously hurt the usability of their site. Now commonly a lot of Web pages have been done with some fancy work with JavaScript and require me to take several actions just to get to the content. I've had more than enough: When I see such a page, with nearly no exceptions, I just leave the Web site. I'm gone, out'a there. I commonly have the mouse pointer on the content of the page as I scroll the page, and some sites track the mouse pointer and, then, generate lots of popups that cover up the content I'm trying to scroll and read. No matter what, almost certainly, I regard any popup I have not explicitly requested as a big interruption in my work, a big waste of my time, a big frustration, something I really HATE, and a good reason just to leave the site. Tracking my mouse pointer and responding with a popup I didn't request is doing me a favor based on some assumptions: To me, it's not a favor. In general, just do not make assumptions and then do me automatic, unrequested favors by interrupting my effort to read the content of the site. Cut way back on unrequested favors. Wikipedia and Disqus both do a lot of mouse tracking and popup favors, and I hate both of them for it. Just keep it simple, e.g., so I can see the real content the site does have and I came to see. Just because it is possible to insult, interrupt, irritate, infuriate, and frustrate me does not make it a good idea.
farmin 4y ago
SPA movement has given us nice frameworks to build mobile apps in Ionic. I wouldn't build a website with Angular but combine Angular framework and the million libraries in npm gives a pretty powerful ecosystem to quickly build very high functioning apps.
LoveGracePeace 4y ago
At this pace, JavaScript will be gone and we will be back to the joy of making web apps in all Java before I retire.
NikhilVerma 4y ago
I understand that SPAs were being overused in many places. But the pendulum seems to be swinging back way too hard, and people are bashing SPAs as if it's the worst thing in the world. SPAs are cheap to host, as you just need a reverse proxy and with increasing internet speeds, bundle splitting can be almost imperceptible from MPAs
reddec 4y ago
From my point of view, SPA is really good when you need to use one API for different kinds of clients: web, mobile apps, cli etc. Second benefit is predicted relative routing: in case you're serving your web app (with hash router) as one page, you may don't worry about subpaths (ex: page served as /webapp will work properly under /foo/bar)
DeathArrow 4y ago
Even if you want to have a SPA like behavior it's easy to render everything on server and keep it interactive by re-rendering just small parts of the page using HTMX, Alpine.js or handwritten JS. It's trivial to add HTML templating and rendering logic to a WebApp. I'd argue that for somebody equally skilled in backend and frontend frameworks, using server side rendering would be faster than writing a backend and a fronted.
- FranksTV 4y ago
  From a user experience standpoint there's a huge difference on slow connections.
miiiiiike 4y ago
Hello folks and welcome to round 678 of the Least Interesting Conversation on the internet. SPAs are great when they're necessary and MPAs are great at what they do too. Thanks for tuning in, the series stands at 678 ties, see you again tomorrow for rounds 679, 680, and 681.
- danjac 4y ago
  99% of the time the right answer is "use the best tool for the job at hand that matches your team and budget" but that won't generate the clicks.
  - rat9988 4y ago
    Because it is a useless answer. You don't answer "what is the best tool for the job at hand that matches my team and budget" by "use the best tool for the job at hand that matches your team and budget".
    - danjac 4y ago
      No, but you answer with specific analysis rather than generalizing clickbait.
- kulikalov 4y ago
  Why do you think people upvote these discussions?
  - nsonha 4y ago
    Because it's popular? Do you think you've made a point now?
    - kulikalov 4y ago
      That was a genuine question, not sarcasm.
- edanm 4y ago
gandutraveler 4y ago
I don't remember which hotel website(Marriott?),I was using that migrated to MPA and their dev team had no clue that it broke their in-app chat feature. Agent asks me for registration details, I click on the page to get details... Poof, my chat gets disconnected and now I have to wait another 30 minutes for next agent.
tomphoolery 4y ago
> Blog posts are making the rounds listing all the challenges with SPAs: history, focus management, scroll restoration, Cmd/Ctrl-click, memory leaks, etc. I guess? Like, who is implementing all this BS themselves? Every time I've written a SPA, my framework and/or routing library handled all this crap for me. None of these "challenges" were ever problems for me, and this sounds like another case of programmers creating an issue where there actually isn't one. If you use a proper framework or routing library that changes the history state of the URL, it's pretty much impossible for users to tell whether something is a SPA or an "MPA". So who cares?
- nullbytesmatter 4y ago
  And yet, a large portion of big websites using SPAs don't seem to have functioning back buttons. If a billion dollar company can't get it to work properly I doubt anyone else can.
  - presentation 4y ago
    Or maybe that billion dollar company's users don't change their preferences based on back button behavior so they feel no need to fix it.
  - tuyiown 4y ago
    > If a billion dollar company can't get it to work properly I doubt anyone else can. Billion dollars companies rarely delivers high quality software, especially in the UI area.
  - SebastianKra 4y ago
    Back buttons in web apps are hard regardless of SPA or MPA. I've seen many MPAs fail, for example after checkouts or form submissions. The problem is just more prominent with SPAs because they usually feature more complicated navigation. Perhaps for privacy reasons, you don't get much control over the built in history: you can push, replace and pop. Maybe you could implement your own history, but then you need to somehow keep that in sync with the browser. If someone knows a good approach, I'd be interested.
coinbasetwwa 4y ago
Pour one out for all the junior engineers on teams with senior engineers who read this and argue to go back to poorly implemented MPA’s without the engineering talent to drive sensible abstractions.
rdubs333 4y ago
Laravel Livewire!!!
cryptonector 4y ago
> Service Workers – once experimental, now effectively 100% available for those of us targeting modern browsers – allow for offline navigation without needing to implement a client-side router (and all the complexity therein). Ok, sure, but what you're saying is that the code and rendering is still on the client, same as SPAs.
xtat 4y ago
Here comes 17 new frontend frameworks

486 points by feross 4y ago

I appreciate the accessible aspects, but the browser is not a panacea. Not that the industry is invested in accessibility out of benevolence. I feel like we're holding up the hard/firmware side of things here.

amelius 4y ago

To me it seems more like the balance has shifted to native apps, unfortunately.

LAC-Tech 4y ago
really? I barely ever use native apps anymore. even if the mobile webpages nag me to.
- amelius 4y ago
  I think young people mostly prefer these apps. And there's a reason why companies nag you.

encoderer 4y ago

These are interesting developments in the browser! Still, I don’t think this headline conclusion is supported by the facts in the article. Of course “balance” in this context is basically meaningless but if you replace it with “consensus” it does mean something, and it’s clearly not correct: the article makes clear we are still adding critical support at the browser level. Possibly, this will result in a renaissance of multi page apps, but we have to wait and see.

adamnemecek 4y ago

I have been reading articles like this for the last 10 years. I'm not sure why people complain about SPAs. Guess what, in the mean time as some MPA frameworks have been made, the whole web has been moving towards webassembly. Say goodbye to MPA HTML, say hello to Rust with custom UI based on WebGPU transpiled to webassembly.

oblak 4y ago
As a JS developer, I think this is correct and kind of fear for my future. Time for this old dawg to learn something new again. Thing is, I think I am not good enough for system level programming. I've only done rust to the extend of going just a step beyond "hello world". I've also read good things about Go. Decisions, decisions.
- adamnemecek 4y ago
  > think I am not good enough for system level programming I think that this is the wrong way to think about it, the languages and tools for systems programming suck. I would recommend you check out Rust, it make systems programming really pleasant. Like I have been programming C++ for 25 years and somehow I'm a lot more comfortable with writing Rust even though I have seriously written Rust for only like 1.5 years.
teg4n_ 4y ago
It really hasn’t been moving towards web assembly. Web assembly is not magic performance pixie dust and it generally has pretty bad bundle size. You need pretty specific scenarios to get genuine improvements with web assembly over JavaScript.
- adamnemecek 4y ago
  > magic performance pixie dust It is. I can finally have value types which let me access properties without incurring the overhead of a JIT. > and it generally has pretty bad bundle size For now. So do websites btw.
Hayvok 4y ago
> I'm not sure why people complain about SPAs. … say hello to Rust with custom UI based on WebGPU transpiled to webassembly If this is the future, then no wonder everyone is running back to just shipping HTML over the wire. All this has gotten too complicated.
- 4y ago

nightski 4y ago

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.

TekMol 4y ago

Where are those SPAs everybody is talking about? All sites I use regularly are MPAs: Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub ... Reddits new design is kind of a hybrid. It is MPA when you hop between subreddits and other pages. But it shows a post on the same page when you click on it in a subreddit feed. I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something, that the only "somewhat SPA" I know makes me switch to its MPA version regularly.

manmal 4y ago
Was AirBnB not one of the first companies to champion server-side rendering of React apps? I think you’re listing apps that are actually a bunch of SPAs glued together (each page is super complex and an SPA of its own right).
- TekMol 4y ago
  On AirBnB, you search for a location on the homepage and then you go to a new page, the map page. Which is a bit SPAish because it reloads apartments when you move the map. Then when you click on an apartment, you go to a new page, the apartment page. Overall, I would count that as MPA? The apartment pages seem to be client side rendered. When I CTRL+u and look a the source code, I see a lot of JSON and not much HTML.
- marcosdumay 4y ago
  Hum... > Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub I don't know about AirBnB. Booking has a little bit of interactivity that is more annoying than helpful¹, like the GP's example for Reddit. None of the others can be described as "applications". 1 - The map is good. The stuff on the map is very good. The map itself is an SPA. For all the rest of the site, if they removed all the Javascript it wold be an improvement.
- AlchemistCamp 4y ago
  It wasn't React, but Spike Brehm gave a lot of talks about Airbnb moving to "isomorphic JavaScript" with a library he created. It was called Rendr and it basically let you stitch together Backbone and Node and share code between the client and the server. I remember being pretty interested in it at the time. https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-librar/ https://techcrunch.com/2013/04/19/airbnb-open-sources-rendr-...

endisneigh 4y ago

So much whining about SPAs. A properly written SPA is very performant and really doesn't have huge differences compared to MPA. If anything the only thing that's changed is people understand how to properly write a SPA and JavaScript web development is finally reaching a period of some level of stability. It really depends on what you're trying to do. Want a fully offline app? Good luck without SPA.

deleted 4y ago
[deleted]
andybak 4y ago
> A properly written SPA is very performant and really doesn't have huge differences compared to MPA. Maybe true but in the wild the vast majority of websites manage to fall down on one or both of these. So either it's hard to "properly write" an SPA or something else is going wrong.
- endisneigh 4y ago
  Most sites are generally flawed in some sense. SPA is just a red herring.
nomilk 4y ago
> A properly written SPA is very performant SPAs should offer better UX (by reducing full page loads), but at the expensive of developer hours. Curious to hear what the difference in development time is from anyone who made the same app as a MPA and later as a SPA. I'd guess to make the same app as a SPA would take around 2-3 times as long.
- BackBlast 4y ago
  My experience is the opposite. I say that from a career that is dominated by backend experience. In any application, you have to have a good front end. To most users the app/page is the UI. Having the majority of your concerns in one place will help you develop with smaller teams. Certain SPA architectures can bring nearly ALL of the concerns into the front end. Particularly with databases that are simply port open to the world like say couchdb. Your backend needs almost effectively disappear. If this is a reasonable data model, SPA looks and feels much faster to use and develop. When you attach a backend, you often attach other specialists, languages, techs (python, ruby, Java). Have to deal with separate teams, which often means a formal API and all the handshaking between. This pretty much triples the required work with development and the communication overhead.

randomtwiddler 4y ago

Stop griping about SPAs. Local compute is powerful and lower latency than the data center across the country or world. Page weight isn't that big of a deal, a 2 MB ball of js is nothing compared to the multi megabyte pictures and videos people routinely add to pages. For some use cases MPA is fine, but in many cases it's actively worse and higher dev costs to boot. Service workers are an interesting middle ground I think should see more attention and development. I like to combine service workers with SPAs for fully offline capable web apps.

deleted 4y ago
[deleted]
jhgb 4y ago
> Page weight isn't that big of a deal, a 2 MB ball of js is nothing compared to the multi megabyte pictures and videos people routinely add to pages. That's a good argument if you're one of the people adding multi megabyte pictures and videos to your pages, but I'd bet that if page size is of concern to you, you're not one of them, so "a 2 MB ball of js" would suddenly become your weakest link.
- randomtwiddler 4y ago
  You say "weakest link" like there is an optimum. People are regularly downloading 4k video. By choice, they want to be doing this. Amazon is one of the most successful websites ever created and last I checked came in at over 12MB page weight. Mostly highly optimized images. I'm sure they wrangle and agonize what shows up there. There's a limit somewhere, but pointing the finger at a ball of js that compresses to less than 500k isn't particularly reasonable. User experience is more about latency. Be it from local compute or remote compute+network. If your visitors are one and done you must SSR at a minimum. Because that will drive the average latency of the majority of user experience. If they are long term users, you should seriously look at user local data and potentially full offline functionality that can mask even poor 3g performance and spotty networks. Making users suffer long term through an MPA architecture is silly.
cyral 4y ago

marcthe12 4y ago

I do agree alot with the article. One of the major use case SPAs was optimization hack that service worker can do easily. Service worker are like proxy middleware and are capable of some nifty tricks. Since I am not in web dev that much so I never actually managed to develop a project using it, but I felt that the templating could done fully in service worker. It will be faster as long the templating/transcompiling is not a bottleneck as the on wire format will be smaller. The main issue will be bootstrapping as you need to load a page first to install the service worker. I wonder if there is a good solution to that? (One idea is a service worker middleware on node so you can the service worker in the server side on first time use).

nolanl 4y ago
(Author here.) I totally agree and feel that Service Workers are still underexplored in this area. If your main reason for writing an SPA is speeding up navigation (e.g. the Turbolinks approach), then you may be better served by just moving the rendering logic into a Service Worker. It should be possible to build an "MPA" where all the rendering logic lives in the Service Worker. Then you'd get fast navigations without needing to worry about a client-side router and managing focus/scroll/etc. I'm not sure I've seen a great implementation of this though.
- keybits 4y ago
  Here’s a great example of how this can be done https://instantmultipageapp.com/ https://instantmultipageapp.com/
  - nolanl 4y ago
    Thank you! This is exactly what I had in mind. The streaming aspect of MPA pages is a great example of something you can't really do in an SPA. (Although there are hacks: https://jakearchibald.com/2016/fun-hacks-faster-content/ https://jakearchibald.com/2016/fun-hacks-faster-content/)

throwaway4good 4y ago

For internal apps in the corporate world, all I see now is SPAs based on vue react or angular. For consumer facing websites, where search engine viz is a concern and less is known about the clients browser, maybe it is different.

VWWHFSfQ 4y ago

I think nearly every spa I've ever used was a piece of crap. There is just something off about them. It's almost like it's missing tactile feedback or something. And there's always goofy stuff that just doesn't work half the time. Like middle click to open a link in a new tab. So anyway. Good riddance

dymk 4y ago
SPAs are like visual effects. You don't notice the good ones, because they just work. It's when they're poorly implemented that you notice they're SPAs. It's just a form of survivorship bias.
- cypress66 4y ago
  I assume you meant "You don't notice the good ones"?
  - dymk 4y ago
    Indeed!

matchagaucho 4y ago

"Headless CMS" is simultaneously all the rage (API first content management). If I had to generalize in broad strokes, decoupling the front-end from back-end using SPAs will be far more practical in B2B use cases. While consumer apps will benefit from MPA/SSR (server side render) where one page per product is easier to manage and bookmark.

B1FF_PSUVM 4y ago

What happened to defining acronyms in texts? Any civilians coming across this can't even find out what it is by searching unless they tack "software" after the word.

deleted 4y ago
[deleted]

kaycebasques 4y ago

Discussions about website architecture become a lot more productive when you use Jason Miller's holotypes idea [1] as your starting point. "Holotypes" is kinda just a fancy word for the common top-level uses of the web. E-commerce, search, media player, etc. With that foundation it becomes obvious that SPAs make a lot of sense for some holotypes and a lot less sense for others. We waste time when we talk as if MPA or SPA is appropriate for all website architectures because neither are and never will be. The uses of the web are just too broad at this point. [1] https://jasonformat.com/application-holotypes/ https://jasonformat.com/application-holotypes/

vosper 4y ago
Thanks for this, I liked it. I’d recommend anyone who’s posted for/against some web practice to read it. Maybe one day we could all collectively acknowledge that people work on different stuff, with different goals and under different constraints, and there isn’t actually one right way to build for the web. It’s such a tiresome part of HN.
- dylan604 4y ago
  Yes, just like _____ written in [Go|Rust|flavoflav]. However, at the beginning of every project, this conversation should be had. What are the needs of the project, what gets us there fast while still allowing to grow after scopecreep, what is going to allow for maintanence and future needs? Picking the latest tech just because it's a new project and you want to use the NEW on it just for the sake of it will probably mean finding yourself painted in a corner in the future (or maybe not the original dev, but those that are forced to follow).
  - vosper 4y ago
    Of course, a discussion should be had, choices should be weighed. But since you mentioned “new just for the sake of it” I’ll mention that I think that’s overplayed, too. If you picked React when it was new, or GraphQL, or NextJS, then you probably made a pretty good choice. Backbone was the first of the modern MVC frameworks to get traction (someone will correct me on this) and if you’d chosen that when it was new it would also have been a pretty good decision. Kafka’s still around and going strong, wouldn’t have been a bad choice early-on.

mgaunard 4y ago

People fail to realize that these silly one page websites were invented because they're easier to consume on mobile. Just ask yourself who your users are and what workflow makes sense for them, and build something accordingly.

mrtksn 4y ago

SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore. The client devices are very capable and the networks are fast, it's very logical to offload the rendering to the client. I doubt that MPA is coming back but for things that don't need to be SPA in first place, going back to being MPA is reasonable.

jhgb 4y ago
> SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore. That feels like creative accounting of code to me. Is the rendering really simpler, or does it merely happen in a different place?
- mrtksn 4y ago
  Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases. For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.
  - jhgb 4y ago
    > the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). Drawing a circle artificially around a portion of your code and saying "look, now the circled part doesn't need to change!" feels like creative accounting to me as well. If you have multiple clients, the code for multiple clients still has to live somewhere, so it's not like the whole system that you need to build is getting simpler. Pretty much the only actual difference I can see here is the ability to use more of client's CPU time to run your applications. I'm sure there's applications that could profit from that. > For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. But if you don't do your logic in JS but do it in PHP on the server, you don't need a JS person. And if you were using Seaside, you wouldn't need an HTML/CSS person since everything would be just Smalltalk at that point. It's again just moving stuff around, but someone still has to do that. I guess one situation where this argument might apply would be if one of the two language options was difficult to hire for. > You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side. Not even this argument seems any less artificial to me, since if you're ditching something, I'm not quite sure why it matters where you ditch it from -- unless you have no control over one of the sides. In that particular case, I could see this as an argument. If you're forced to do a client for an already existing server, you're obviously justified in doing a pure client-side solution for anything that doesn't exist on the server yet. If you're building your own server, this limitation is removed.

88913527 4y ago

As someone who works on design systems, I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components, and you can use tools like Storybook to run visual regression tests without standing up your full environment. I know I'm speaking tactically here, but a shift away from SPAs seems like a loss for shared UI components and design consistency. I can't just give a CSS file (which is portable across tech stacks) and leave it to engineers to write accessible HTML; there's huge value-add in isolating a11y in something like a React component abstraction.

bestinterest 4y ago
My issue with design systems is that inevitably the team using the internal companies design system has to implement custom components (usually early on) and try to match the feel of the design system already in place. I'd rather go custom for a project and semi match the already in place feel of the company's UI standards. Then we're only bottle necked by our internal team and not an external team. Thinking more on this, I'd love the https://tailwindcomponents.com https://tailwindcomponents.com setup for internal design components? Seems like the best of both worlds but does move the base from React/Angular components to Tailwindcss
adrianmsmith 4y ago
> I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components That's true, but if your various teams are allowed to use various server-side programming languages and frameworks, what's to say they're not allowed to use various client-side frameworks as well? E.g. one team uses Angular, the other React, the other Vue, etc. Then you're back to having the same problem.
regularfry 4y ago
"Everything is simpler if we all use MY tool." I get it, there's a sort of lowest-common-denominator argument going on here, but it is still an enforced consistency which ignores the benefits of giving teams the freedom to choose the best tool for their specific job.

darepublic 4y ago

Yes to static prerendered pages. Yes to performance and functionality on slow networks. No thanks to "hip new frameworks"

LAC-Tech 4y ago
Unless by "hip" they mean "smaller, more powerful, better abstractions". Not writing a bloody wrapper over express.js...

jcmontx 4y ago

Can anyone point me in the direction of any SPA framework well integrated with a backend framework that can make me as productive as Django, Laravel or Rails?

vosper 4y ago
It’s hard to know hot productive you are in those frameworks, but I’ll take your question at face value: if you were an expert with NextJS, Typescript, and Prisma or Hasura then you’d be pretty dang productive.
floucky 4y ago
SPA just use APIs so most of frameworks are compatible
- Nextgrid 4y ago
  The problem is that you now need to either make resource-oriented APIs for every model in your DB that your frontend may need to access (even if just for internal business logic) or make RPC-style endpoints that do the business logic. That's significantly more work than just doing whatever logic you want on the server to begin with where you have access to all tables directly (they're an ORM call away) and not have to worry about access control because all of this still happens within the trusted environment of the server.
  - hombre_fatal 4y ago
    Perhaps you could elaborate on what you mean, but from my viewpoint there isn't much daylight between DB-queries in most server-rendered apps vs. SPAs. Instead of this: def endpointAB: a = db.getA() b = db.getB() return template('ab.html', {a=a, b=b}) You tend to have this: def endpointAB: a = db.getA() b = db.getB() return json({a=a, b=b}) When I think of ways you may want to generalize over arbitrary queries on the server, I run into the same challenges you'd have in a SPA rather than fewer.
tpetry 4y ago

Mikeb85 4y ago

I mean, SPAs were overkill for half the shit they were being developed for. Your average web app is a CRUD app and works better as an SSR app. But there's still use cases for them, they're still a great way to build highly interactive cross platform apps.

hirvi74 4y ago
In my experience, one of the biggest benefits of SPAs is that the front-end tends to be a bit more decoupled from the back-end when compared to SSR apps. Now, of course MPAs could be built this way, and plenty probably are, but again, it's not something I have personally seen often.
- mdavidn 4y ago
  Why is this decoupling important to you? Do you use multiple front-ends or backends?
  - mb7733 4y ago
    I definitely do where I work. Multiple web front ends plus mobile apps.

nathias 4y ago

SPAs themselves have come increasingly towards this with SSR. The next step of web is merging both trends into a framwork that can combine the positives of both, which the libraries in OP seem to be. I'd like to see some comparisons. Edit: After some research I think SvelteKit is going to be the best new thing.

hirvi74 4y ago
Doesn't vue.js allow for this in some form with it's low barrier to commitment? I thought it could be implemented via a CDN alone without installing anything. Regardless, I have read one of the biggest benefits to vue's low commitment is that you can use it or forgo it whenever a developer wants, can add it to existing projects, etc.. I will admit that I am far from well-versed in vue, so I could be mistaken.

zkirill 4y ago

Our web product went from AngularJS to React to Angular to Angular + Spring. The addition of Spring helped us introduce a useful constraint: if you can build it as an old-school page with Spring, don't put it into the SPA. Angular is reserved for deep core business logic and UI which would be impractical to build anywhere else. One of the biggest benefits is reducing our Angular project complexity, making it easier to keep current with Angular updates. I am happy to hear that SPAs are no longer sexy because this sounds like the landscape has matured. For example, Angular started doing LTS releases.

dimgl 4y ago
This sounds needlessly complicated.
- zkirill 4y ago
  Maybe, shoot me an email if you want to chat about it kirill at getfillet.com
- arcturus17 4y ago
  Now your design system is probably all over the place and you have to know two ways to build a view, and have to decide every time which one to use.
  - zkirill 4y ago
    You invented a problem. SPA team and Spring team have separate responsibilities. Our customers don’t care how it looks beyond ergonomics and functionality. It took us a long time to shift away from “SPA all the things” mentality.

davnicwil 4y ago

So I don't think this pendulum backswing is all that surprising or interesting on its own - it's been a journey to discover the edges of the SPA paradigm's capabilities and strengths and a retreat to pragmatism mostly. What I do find quite fascinating is that React actually started out pushing this kind of server rendered, pragmatic pieced-together approach from its very first days. Indeed, because that's exactly what the facebook website required - dynamic additions to a php-like fundamentally server-rendered site. I am not sure if I'm always interpreting this correctly but a lot of blogs I read about server rendering (the buzz TLA for which is now SSR) and the general per-page approach for React apps seem to be attributing the idea of the approach to a few of the newer frameworks that have appeared. Those frameworks are great and package up a load of this goodness, but ironically you don't and have never needed any such wrapping, nor any of the learnings of the SPA era, for any of this. It came out of the box in React before it even hit major version numbers. Somehow, the idea just never seemed to catch.

recursivedoubts 4y ago

thesis: web 1.0 hypermedia-based applications (clunky) antithesis: web 2.0 SPAs using JSON Data APIs (slick, but complex and & web-native) synthesis: web 1.5 apps using hypermedia-oriented libraries like htmx or unpoly (slick, web native)

bestinterest 4y ago
Lots of credit for yourself with htmx, its great. I think I prefer unpoly myself but htmx is winning the popularity because of how vocal you are! I wish the unpoly creator also did similar! Both great frameworks. Hotwire also! I wish there was deeper comparisons on the big three
- recursivedoubts 4y ago
  i always try to mention unpoly unless the discussion is specific to htmx because I agree: it is a wonderful library and henning is a great guy in general. Hotwire probably doesn't need my help, I think dhh has a big enough mic. :)
robertoandred 4y ago
None of htmx's modal examples are accessible, doesn't give me confidence it can be used for serious projects.
- recursivedoubts 4y ago
  if you are willing to jump on the discord, we'd be happy to improve them https://htmx.org/discord https://htmx.org/discord
- benpate 4y ago
  My dude... I made those in like a day, when I was first getting started with htmx. Accessibility has nothing to do with the language or framework you use. It's about the thing you build with it. If you can build it with Javascript, you can build it with htmx. Give this a try, and see if it's any more accessible -- https://benpate.github.io/hyperscript-widgets/modal/ https://benpate.github.io/hyperscript-widgets/modal/ -- I've learned a bit since those first demos, and have followed every W3C guideline I can find on accessibility to make them. One more thing, I'm nowhere near being an accessibility expert, so I'm positive someone who knows more will have suggestions on how to improve this, too. But it has nothing to do with htmx/hyperscript, and everything to do with me being new at accessibility. Bugs/Suggestions/Pull Requests are always welcome. That's what makes htmx fit for "serious projects." Edited to add: Htmx is a JS-based extension of the natural hypermedia patterns your browser already uses, not a widget library. All of the demos on the site are just that -- demos that show you the kinds of things you can build, and not plug-and-play, ready-for-npm widgets you can just drop into your application without a second thought.

nickreese 4y ago

Author of Elder.js (mentioned in the article) and avid lover of both MPA and SPA. Daily I am writing MPAs for SEO assets and SPAs for internal dashboards used to manage the huge amount if data collection our teams do. It really boils down to what you are building. Google is decidedly terrible about indexing JS for sites with a low crawl budget. Why make your life harder. That is why I wrote Elder.js. Statically generate everything, sprinkle in interactivity where needed. But for internal dashboards I developed a internal framework to spit out crud apps based on nothing more than a couple graphql queries and a couple yupjs validations. It is a breeze and adding new data collection fields takes minutes so I and my team can focus on stuff that drives business value… instead of crud. As with everything picking the right tool for the job makes the job a lot easier. Don’t give into the hype one way or another.

11235813213455 4y ago

something still annoying between navigatng pages normally Vs SPA history API is in first case you lose devtools network/console data from previous page (while developing at least)

bcyn 4y ago
Look for a setting named "Preserve logs" to prevent the default behavior of clearing console/network log.

deleted 4y ago

[deleted]

FpUser 4y ago

>"There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago. Hip new frameworks like" I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"? The only thing that matters is how much it costs me to develop solution assuming it satisfies all the constrains imposed by client's specs. The difference makes a profit and this is what I am after. I use SPA when I need real business application and it needs to be delivered in a browser. If SPA becomes too big I make it dynamically load a pieces of needed functionality upon request. By nature is is still SPA and dynamically loaded parts tend to stay in browser's cache anyways. When I need a website I make plain website. I do not turn one into the other.

Nextgrid 4y ago
> I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"? You are a minority in a sea of crap whose only goal is to extract more money from investors by dazzling them with buzzwords, "growth & engagement" and engineering playgrounds where complexity is a feature to justify hiring more engineers and make an engineering blog to brag about solving (self-inflicted) problems in order to help hire more engineers. When your objective is to make money by solving clients' problems as opposed to dazzling investors to then beg for their money, the "bill of materials" changes significantly.
- FpUser 4y ago
  >"You are a minority in a sea of crap" I believe there are countless companies like mine, serving needs of various businesses. We just do not make much noise and hence are not written about.

coding123 4y ago

So can we really claim these as MPAs? This is all using the same architecture of SPAs but it moves it to the backend. Technically that's still an SPA that moved the rendering to the server and instead of shipping JSON and telling the browser to update with the new JSON it's the server sending HTML that the browser is told to replace a part of the screen. It's really just the same thing but with a twist. This is not "MPA" tech, it's SPA tech with new bells and whistles. MPA tech (PHP, CGIBIN, etc..) is dead and not coming back. If the author states this, I would be on board - we're shifting to shipping HTML chunks.

MiscIdeaMaker99 4y ago

What's an SPA?

kayson 4y ago
Single page app https://en.m.wikipedia.org/wiki/Single-page_application https://en.m.wikipedia.org/wiki/Single-page_application In the early days of the web, pages were static, and changing content required navigation to a new page (url). Then JavaScript took off and you could dynamically change content on a given page, even reload data without navigating/refreshing. In the extreme, frameworks like react were developed, where you no longer have pages at all. The entire website is rendered on the same page using JavaScript to load all the content on the fly.
- MiscIdeaMaker99 4y ago
  Thank you very much for telling me what SPA means.

andix 4y ago

I think it greatly depends on what kind of thing you’re building. A „website“ like HN shouldn’t be a SPA But an „app“ like Gmail probably should be.

TrispusAttucks 4y ago

SPAs have been shit since the beginning. It was a wrong path. Thank God the new comers have corrected.

olliej 4y ago

I love how this credits the back/forward cache to chrome when it was a webkit feature chrome inherited. Much like almost every other "chrome" feature other than the process architecture (which was also the actual real engineering work they should have got credit for).

fartcannon 4y ago
Webkit is just forked KHTML so credit where credit is due.
- olliej 4y ago
  The back/forward cache is from apple era webkit, as is a large amount of the basic compat work in webkit. KHTML did a lot of work, but they did not do all of the stuff that made WebKit actually practical as a browser engine - webkit had massive rewrites to get compatibility and performance to anything approaching acceptable. That said the problem I had here in this article was that this article is explicitly crediting a specific feature that predates Chrome to Chrome. The bf-cache is one of the vast amounts of work webkit had done to make khtml a practical engine for real browsing. WebKit at the point chrome forked it had already largely rewritten the DOM, JS engine, Rendering engine, and layout engine. Or you can continue searching HN to make glib questionably accurate and definitely misleading comments in response to things I say because you’re unhappy that someone suggested opencl failed because it was a crappy spec.
  - fartcannon 4y ago
    It looks like KDE is still to this day a primary contributor. Isn't giving Apple credit for the work of a large team, the same thing OP was doing with Chrome? Regarding your accusation, I'll make sure to check who I am replying to and not reply to you anymore. I guess you have interesting counter arguments that encourage discourse. Anyways, keep posting, you're doing a great job.
  - emilsedgh 4y ago
    Konqueror/KHTML was more than "acceptable". It was a fine web browsing experience. You'd barely notice anything wrong with it and it was the first browser to pass ACID 2 tests I think. Saying KHTML wasn't viable/acceptable experience is more misleading to be honest.

gherkinnn 4y ago

The MPA/SPA dichotomy as is often presented is nonsensical. Sites built in Next, Remix, or whatever work perfectly well as MPA. Astro merely goes a step further. Pure SPA (as in a literal single route, maybe with horrible # based routing) is exceedingly rare and mainly found in legacy Angular code bases.

gatvol 4y ago

This is not a binary choice - SPA's remain a valid pattern for the right use case. The point is knowing when to apply the pattern. Aside from that they have some great features, including security; ;they largely reduce the attack surface to supply/dep chain, and an API interface - which is a great pinchpoint at which to apply mitigations, monitoring etc.

ferdowsi 4y ago
In what way do Javascript heavy SPAs reduce supply chain attacks vs a no-JS solution?
- upbeat_general 4y ago
  Just taking a guess: supply chain attacks may occur the same (or even more) but they’re less impactful client side. Makes it easier to have more trusted server-side code and less validated client-side JS.
- gatvol 4y ago
  That was my assertion, I said the surface for attack included supply chain. As another poster pointers out, that is in fact reduced under some circumstances, since the runtime context is browser side.

zmmmmm 4y ago

They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether it's one page or ten but it does simplify things enormously that I can maintain a single model object and not have to persist it in and out of local storage or even worse have all the complex UI state replicated on the server side to maintain continuity, just because the user clicked a button or something. Especially with reactive frameworks where updating the model automatically triggers re-rendering of the UI everywhere it needs to, a whole piece of complexity in your architecture just goes away.

my69thaccount 4y ago
SPAs suck at client side state, they barely work with the back button or scroll bar and if they do its because its reimplemented in JS.
- nighthawk454 4y ago
  Not browser state, but application state. Lot more boilerplate and glue to do that on server side and ferry it back and forth.
  - infogulch 4y ago
    But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.
    - nighthawk454 4y ago
      No? I simply clarified which state op was referring to. The state of the browser is separate to what's being discussed. SPA's can be good at some state and not others.

devwastaken 4y ago

Imagine if a kde, qt or other native desktop application had to contact a remote server for the actual styled content to render to page. An SPA is the same concept of desktop applications, only get the data, and render it locally. It doesn't make sense for some things and makes sense for others.

immigrantheart 4y ago

If you do dashboards and finance applications (like trading app) or any other app that requires real time and heavy interactivity, you need SPAs. There is no other way around it.

Existenceblinks 4y ago
That's very easy with Phoenix LiveView because the data is mostly readonly. Buy and Sell button are super simple.
- immigrantheart 4y ago
  People don’t want to use Elixir
  - Existenceblinks 4y ago
    people don't want to use anything, people want to use anything. That is your point.

Justsignedup 4y ago

I've been using SPAs to handle lots of complex interactions, and react makes a lot of things quite pleasant that I had to fight with in the past. Having said that, I am very very happy to see technology move forward and give us more options. I am excited about the possibilities. Having many options to solve complex problems in simple ways is a great thing, and old down sides of each are disappearing. Overall. Awesome.

nojvek 4y ago

What is an MPA? Multi platform app?

julianbuse 4y ago
It's a multi page app.

mbrodersen 4y ago

Different architectures make sense in different contexts. Whether one is used more than another doesn’t matter one bit. It is not a popularity context.

spinaltap 4y ago

Speaking of Rich Harris, is SvelteKit a good framework to build MPAs? If not, what is? I'm planning to learn SvelteKit in my next side-project. As for "Astro, Qwik, and Elder.js" mentioned in the blogpost, I haven't heard about them.

graycat 4y ago

As a Web user, I urge Web site developers to return to "keep it simple". In particular, multi-page applications are better, easier to understand, than single page applications which tend to be confusing. Treat the pages of the site more like the pages of a book -- those pages don't change as I'm trying to read the book. Net, a single page application looks to me like it has no pages at all, just a lot of confusion where I don't know where I stand, what is the state of my visit, something I can't meaningfully copy or save. Use big 100% black fonts on a white background. In particular, note that about 25% of men are partially red-green color blind. So, if insist on using colors, avoid using both red and green on the same page. Have both vertical and horizontal scroll bars. Never omit either the vertical or the horizontal scroll bars. Accept no substitutes. Similarly, never have a row of images or other blocks of content that scroll off and on the screen left or right via little arrows. With that scrolling, there's no real page I can have in mind. Don't have parts of the page moving or coming and going without explicit user requests. Such Web pages are a good reason just to leave the site. Or, maybe I DO want to look at some of that content -- nope, soon it's jerked from me and gone. Bummer. Don't assume that the user will display the pages at full screen -- often can't have that because need other windows open for the purpose of visiting the Web site at all. Don't cover up what I'm trying to read: So, cut way back on popups, pull-downs, overlays, etc. Design the Web page HTML so that I can save the page and later, without an Internet connection, still have my Web browser display the page correctly. Such saving can be crucial for pages where I've done something important, say, pages summarizing a purchase I just made. Conserve the crucial, vertical space: So, get rid of banners that overlay the content, take up a lot of the vertical space, and come and go as I scroll the page up and down. Apparently as people saw how to do that, doing it became popular as if it were a good idea -- it was a fad and a bad idea. Don't do it. Quanta magazine has done a lot with such banners, and it has seriously hurt the usability of their site. Now commonly a lot of Web pages have been done with some fancy work with JavaScript and require me to take several actions just to get to the content. I've had more than enough: When I see such a page, with nearly no exceptions, I just leave the Web site. I'm gone, out'a there. I commonly have the mouse pointer on the content of the page as I scroll the page, and some sites track the mouse pointer and, then, generate lots of popups that cover up the content I'm trying to scroll and read. No matter what, almost certainly, I regard any popup I have not explicitly requested as a big interruption in my work, a big waste of my time, a big frustration, something I really HATE, and a good reason just to leave the site. Tracking my mouse pointer and responding with a popup I didn't request is doing me a favor based on some assumptions: To me, it's not a favor. In general, just do not make assumptions and then do me automatic, unrequested favors by interrupting my effort to read the content of the site. Cut way back on unrequested favors. Wikipedia and Disqus both do a lot of mouse tracking and popup favors, and I hate both of them for it. Just keep it simple, e.g., so I can see the real content the site does have and I came to see. Just because it is possible to insult, interrupt, irritate, infuriate, and frustrate me does not make it a good idea.

farmin 4y ago

SPA movement has given us nice frameworks to build mobile apps in Ionic. I wouldn't build a website with Angular but combine Angular framework and the million libraries in npm gives a pretty powerful ecosystem to quickly build very high functioning apps.

LoveGracePeace 4y ago

At this pace, JavaScript will be gone and we will be back to the joy of making web apps in all Java before I retire.

NikhilVerma 4y ago

I understand that SPAs were being overused in many places. But the pendulum seems to be swinging back way too hard, and people are bashing SPAs as if it's the worst thing in the world. SPAs are cheap to host, as you just need a reverse proxy and with increasing internet speeds, bundle splitting can be almost imperceptible from MPAs

reddec 4y ago

From my point of view, SPA is really good when you need to use one API for different kinds of clients: web, mobile apps, cli etc. Second benefit is predicted relative routing: in case you're serving your web app (with hash router) as one page, you may don't worry about subpaths (ex: page served as /webapp will work properly under /foo/bar)

DeathArrow 4y ago

Even if you want to have a SPA like behavior it's easy to render everything on server and keep it interactive by re-rendering just small parts of the page using HTMX, Alpine.js or handwritten JS. It's trivial to add HTML templating and rendering logic to a WebApp. I'd argue that for somebody equally skilled in backend and frontend frameworks, using server side rendering would be faster than writing a backend and a fronted.

FranksTV 4y ago
From a user experience standpoint there's a huge difference on slow connections.

miiiiiike 4y ago

Hello folks and welcome to round 678 of the Least Interesting Conversation on the internet. SPAs are great when they're necessary and MPAs are great at what they do too. Thanks for tuning in, the series stands at 678 ties, see you again tomorrow for rounds 679, 680, and 681.

danjac 4y ago
99% of the time the right answer is "use the best tool for the job at hand that matches your team and budget" but that won't generate the clicks.
- rat9988 4y ago
  Because it is a useless answer. You don't answer "what is the best tool for the job at hand that matches my team and budget" by "use the best tool for the job at hand that matches your team and budget".
  - danjac 4y ago
    No, but you answer with specific analysis rather than generalizing clickbait.
kulikalov 4y ago
Why do you think people upvote these discussions?
- nsonha 4y ago
  Because it's popular? Do you think you've made a point now?
  - kulikalov 4y ago
    That was a genuine question, not sarcasm.
edanm 4y ago

gandutraveler 4y ago

I don't remember which hotel website(Marriott?),I was using that migrated to MPA and their dev team had no clue that it broke their in-app chat feature. Agent asks me for registration details, I click on the page to get details... Poof, my chat gets disconnected and now I have to wait another 30 minutes for next agent.

tomphoolery 4y ago

> Blog posts are making the rounds listing all the challenges with SPAs: history, focus management, scroll restoration, Cmd/Ctrl-click, memory leaks, etc. I guess? Like, who is implementing all this BS themselves? Every time I've written a SPA, my framework and/or routing library handled all this crap for me. None of these "challenges" were ever problems for me, and this sounds like another case of programmers creating an issue where there actually isn't one. If you use a proper framework or routing library that changes the history state of the URL, it's pretty much impossible for users to tell whether something is a SPA or an "MPA". So who cares?

nullbytesmatter 4y ago
And yet, a large portion of big websites using SPAs don't seem to have functioning back buttons. If a billion dollar company can't get it to work properly I doubt anyone else can.
- presentation 4y ago
  Or maybe that billion dollar company's users don't change their preferences based on back button behavior so they feel no need to fix it.
- tuyiown 4y ago
  > If a billion dollar company can't get it to work properly I doubt anyone else can. Billion dollars companies rarely delivers high quality software, especially in the UI area.
- SebastianKra 4y ago
  Back buttons in web apps are hard regardless of SPA or MPA. I've seen many MPAs fail, for example after checkouts or form submissions. The problem is just more prominent with SPAs because they usually feature more complicated navigation. Perhaps for privacy reasons, you don't get much control over the built in history: you can push, replace and pop. Maybe you could implement your own history, but then you need to somehow keep that in sync with the browser. If someone knows a good approach, I'd be interested.

coinbasetwwa 4y ago

Pour one out for all the junior engineers on teams with senior engineers who read this and argue to go back to poorly implemented MPA’s without the engineering talent to drive sensible abstractions.

rdubs333 4y ago

Laravel Livewire!!!

cryptonector 4y ago

> Service Workers – once experimental, now effectively 100% available for those of us targeting modern browsers – allow for offline navigation without needing to implement a client-side router (and all the complexity therein). Ok, sure, but what you're saying is that the code and rendering is still on the client, same as SPAs.

xtat 4y ago

Here comes 17 new frontend frameworks