39 ms·

SPAs Were a Mistake

• frabjoused 5y ago
  I can't agree with this. That list of 9 complexities are well abstracted by the most common library or framework for SPAs. Having done a lot of SPA development I can say routing is not anywhere up on the list of trouble spots you do encounter. State management is another story.
• thex10 5y ago
  My dev was asserting that a modest change to how a certain form control works would be "easier in React" (and this is on a piece of our application that's not even in any SPA right now). I marvel over the eagerness with which developers reach for React and friends nowadays.
• deleted 5y ago
  [deleted]
• gherkinnn 5y ago
  Most major frameworks do that. Barring some devs who navigate using onClick over a link despite having that option. Outside of some lasting mistakes made a decade ago, is this still an issue? On top of that, “SPA” is a misnomer, as many frameworks give you a hybrid anyway.
  • udbhavs 5y ago
    I don't know why routing is the sole focus of the article. In all my SPAs it has been a set up once and forget about it deal. No one is constantly reinventing the wheel there, the churn is in other areas like reactivity and state management.
• phendrenad2 5y ago
  Luckily we don't have to use them. Go ahead and do a full page reload when the user navigates to another page. Go ahead and implement interactive elements using jQuery. It all still works just as well as it did in 2012.
• UltraViolence 5y ago
  I fully subscribe to this notion and hate it that our field is riddled with hyped technologies which everyone chases. Just because something works for Google (Angular) or Facebook (React) doesn't mean it works for your SMB application.
• code_runner 5y ago
  For me, things like react and vue are DEDICATED to the front end. They are great for building UIs and have great ergonomics. Backend frameworks that I LOVE (asp.net, laravel) have templating languages that feel like an afterthought, and passing data to them sucks (I usually have to redeclare what data they receive somewhere, or it’s entirely a dynamic paradigm) editor support is ok AT BEST… all of the sudden part of my app is dynamic c#, which c# isn’t good at. My choice of backend should be absolutely divorced from my choice of front end. I can write an api in node, c#, go, etc and I don’t have to totally change how my front end works. And splitting state between front end and backend (as mentioned throughout the comments here) is awful and error prone. There is a reason large scale apps aren’t using vanilla js or jquery and hand rolling state management etc. It’s all about the size of the app, complexity, division of labor (I can hire a front end specialist who spends 70-80% of their time on front end)… the only goal isn’t JUST performance but if you do it right you get that too.
• b0ner_t0ner 5y ago
  > SPAs were a mistake. Tomorrow, I’ll show you how we can build MPAs that are just as performant as SPAs, with less complexity and fragility. You could just show people Unpoly: https://demo.unpoly.com/ https://demo.unpoly.com/
• darepublic 5y ago
  Nextjs is a great way to make multipage web apps in modern day. Imo it should simply be the default for most use cases
• XCSme 5y ago
  Also, the majority of websites on the web are landing pages, blogs, news websites or e-commerce sites, all of which are inherently multipage. SPAs should be used creating "applications" (as stated by the "A" in SPA), not websites.
• xenreal 5y ago
  I was writing comment explaining how we can use new browser API's to get rid of SPA for 30 minutes. Accidentally pressed F5 and all my message text disappeared in void. The same way it happened 15 years ago, same now, browsers not improved. That's why we do SPA, we want reusable text input component out of box which automatically saves user generated content in forms on typing.
• kshahar 5y ago
  If not SPA, which technologies would you suggest for a web app similar to an IoT dashboard, with gauges and other UI elements that update every second? The server is written in ASP.NET Core. I was considering Blazor server side but it does not seem to be very popular (compared to react, Vue, angular, etc) and I am not sure it's a good choice for the long term (MS likes to kill UI technologies). Approaches like htmx and unpoly do not seem to be appropriate if a large portion of UI needs to update frequently (feels similar to implementing the Blazor approach but inefficiently).
  • deleted 5y ago
    [deleted]
• onion2k 5y ago
  SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features. They might not be actual requirements for a blog or a brochure site but it's not totally unreasonable for someone to want their website to work that way. The question is not whether or not an SPA is a good or a bad thing, but whether or not the cost (more code, more complexity, potentially a series of background requests after the initial page load) is worth paying in order to get the benefits. When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. That should be the goal. Make stuff where the user forgets about the tech. Make a website that just works, that's fast enough for users not to think 'this is a bit slow', and that's coded in a way you can maintain and work on for a long time. If you get those things right then no one can reasonably criticise what you've made no matter how you've made it.
  • midrus 5y ago
    > they work if your connection is flaky, Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.
  • zozbot234 5y ago
    > the idea of essentially removing the network round trip when a user clicks on something is not a bad one. Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.
    • deleted 5y ago
      [deleted]
• cjalmeida 5y ago
  This ship has sailed. SPAs shortcomings are widely known and addressed by frameworks. Whatever MPA alternative you bring will need to address other shortcomings. There will always be something quirky due to building applications in a technology designed for hypertext documents.
  • bdcravens 5y ago
    Many of those shortcomings were solved 15-20 years ago. Far too many SPAs are little more than old school request and response, GET and POSTs. I've literally had to drop into the dev tools console just to push through a page with 7 sets of radio buttons because Angular broke in some spectacular way, on a page that is and should be boring (prescription refill page).
• rado 5y ago
  Anyone else encountered NG routing locking up upon return to the web app with Safari back button?
• Zanfa 5y ago
  I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works, but then you get to browser navigation and you're screwed, because none of this works if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken into a mix of tightly-coupled Javascript, Ruby and ERB templates.
  • beaconstudios 5y ago
    Progressive enhancement was largely solved before SPAs became a thing. Its quite easy to enhance the client side incrementally, but SPAs started out as useful for full on Web apps and now everybody uses them by default for some reason.
  • hombre_fatal 5y ago
    Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things. Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be in that predicament. Too many people hate on SPAs by, presumably, just imagining static read-only content like blogs and news. Though I'm also a bit tired of "SPAs suck amirite, HN?" Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
    • midrus 5y ago
      > Put the user first, consider the trade-offs that work towards that goal, and see what shakes out. In my experience, every single team I've been part of that was building an SPA was because they put the developer experience and desires first, even if in the mid/long term the dev experience ends up being worse as the project grows.
• blunte 5y ago
  I don't disagree with most points here, but I did chuckle at this one: > YouTube is a great example. Being able to keep a video playing while you explore other videos is fantastic. I hate that (mis)feature. When I click something else, my attention is on the new thing. Having to go find the little still-playing video window to close it is a hassle.
  • colejohnson66 5y ago
    As a counter: I love it. It allows me to add videos to a queue without having to build a playlist beforehand. And halfway through the queue, I can add more without having to navigate away.
    • stjohnswarts 5y ago
      Yeah I like it as well, but there should probably be an option to disable for those who don't like it.
  • onemoresoop 5y ago
    Some like it some hate it. I hate it too but generally I like simpler things. I wish we could opt out of some features so everybody would be happy.
  • deleted 5y ago
    [deleted]
  • remram 5y ago
    And if you don't, you're probably going to open in a new tab. Too many webapps are designed with complete disregards to the fact that browsers have tabs.
  • jdrc 5y ago
    agreed. i dont think youtube needs to be an SPA and simple pages work better. For comparison: porn sites.
  • Nextgrid 5y ago
    YouTube is awfully slow - back when I used it I dreaded accidentally mis-clicking on something because it would initiate 3 seconds of stuttering and shit moving around everywhere while their terrible SPA (poorly) reloaded the page. Nowadays I use Invidious which is a proxy that renders good old server-side-rendered pages and it manages to be faster despite being a proxy.
• lambda_dn 5y ago
  SPAs were a good solution when page load/rendering times were longer. However with todays internet speeds, edge caching, HTTP3/Quic as well as todays chips and browser implementations page reloads are barely noticeable so you get all the goodness the browser gives you out of the box creating MPAs. There are still some examples were SPAs are useful such as replacing complex desktop applications but 95% of web apps don't need it.
  • hinkley 5y ago
    It was a big day for me when I realized the CSS perf tool had been removed from my browser because the clock resolution was no longer sufficient to make it work. Everything was <1ms. Bloom filters for CSS were a huge deal, and the CSS load and apply times are one of several things SPAs were trying to amortize.
• wrnr 5y ago
  At this point most articles like this or tools addressing the problem discussed here replace one local optima with another, I'm holding out for something radically different, maybe something like makepad or bevy like ECS with good support for UI.
• coding123 5y ago
  SPAs were not a mistake, SPAs were an attempt to make the front end work like front ends have ALWAYS worked. Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm. POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming.
  • bdcravens 5y ago
    Most SPAs don't interact directly with the datasource, but interact with a middle service. Also many older architecture do draw entire "pages" on the screen at once, rather than manipulating only individual components. (at least not on every interaction)
    • coding123 5y ago
      Clearly, we can't have an SPA front end performing an SQL query directly. The HTTP/GQL/REST services are the SPA equivalent of that data source (they are still a data source). The C++ and VB apps written back in the day were single user programs so yes that's a difference but not by much architecturally. "Pages" are similarly in SPAs too. We usually have a router that helps the app decide what main "page" is on the screen.
  • commandlinefan 5y ago
    > POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming Actually I'm old enough to remember old mainframe CICS programming that was a lot closer to the form-based HTML server-side programming of old. When "the web" came out in the mid-90's, it was actually a "blast from the past".
  • wrs 5y ago
    Not so. IBM mainframe systems (3270 terminal based) that ran most of commerce for a long time are basically the same paradigm as a web browser. Send a form to the smart terminal (GET), wait for the response with the field values (POST), send another form. In fact there are adapters that literally turn these applications into websites by translating the forms into HTML. Commonly seen when you need to do something like change the beneficiaries on your health insurance. “Client-server” paradigm came out in the 90s when PCs became powerful enough to run a “thick client” application, and was considered revolutionary. In other words, the eternal cycle continues… :)
• ramesh31 5y ago
  >SPA's suck! Here's my ad-hoc replacement architecture that you should totally just use! Really though, this is a dead horse. SPAs are just a tradeoff like everything else in engineering. We trade the simplicity of a monolith for the ability to parcel out work efficiently between large disparate teams of frontend/backend engineers.
• mi100hael 5y ago
  I think people have forgotten how easy it is to set up a traditional server-rendered site with Spring Boot or Django or whatever framework. These days I see people adding a SPA as the default starting approach, which adds an entirely separate additional tech stack & deployable to the mix when it's not usually clear why.
  • TedDoesntTalk 5y ago
    If you don’t start with an SPA, you are looked at funny. Like maybe if you were to choose COBOL for the backend code.
• Jenk 5y ago
  It should be obvious why SPA/PWA frameworks were developed by the likes of facebook and Google: Offloading their content rendering to the client. Instead of Google/Facebook CPU cycles being spent on rendering their content, it's now the client devices, while the Google/Facebook infrastructure is "just" serving the data.
  • jtsiskin 5y ago
    This is completely inaccurate. Every millisecond of load time affects conversion so much that they would trade huge amounts of CPU to speed up a page load.
    • Nextgrid 5y ago
      Until you have a monopoly, at which point conversion rates don't matter or rather don't change despite terrible UX.
  • hinkley 5y ago
    First lead dev offered me advice for the rest of my career. Most of what you are going to see people argue about are cyclical fads. A pendulum. We try A and it doesn’t work. So we try !A. And when people forget why we stopped doing A someone tries it again over and over. How are things different this time should be your second question. Your first question is what is the middle ground? Boolean logic falls on its face in the real world. If 1 is bad that doesn’t mean 200 is better. If 200 was bad the solution is not 1. The best answer is probably three.
    • pkilgore 5y ago
      So I ran across a shit ton of your comments in this thread, like how you think, you should hit me up if you're ever hiring.
  • salt-thrower 5y ago
    I'm sure the data that FB and Google are delivering is far more expensive than rendering HTML would be. I am skeptical that server side rendering was a big enough bottleneck for them for that to be their primary motivation. I'm also skeptical that SPA frameworks would have been widely adopted by developers all over the world if they were just some conspiratorial plot by tech companies to save on CPU cycles.
• a_chris 5y ago
  The problem with SPAs is that they have been misused and overused, at least in Italy. Tons of projects built with SPA in which we have to re-implement basic browser features like the back button, just because project manager has no idea of how this technology works. I've worked on at least 4 projects which could be written in Nextjs in half of the time
  • aminerman 5y ago
    They don't know about frameworks in Italy?
  • tofuahdude 5y ago
    Hate to break it to you but Nextjs is for building SPAs.
    • midiguy 5y ago
      I was going to say.... ironically NextJS is just an additional layer for creating static-rendered sites over an SPA framework. We have come full circle.
      • deltaonefour 5y ago
        All of software engineering is a flat circle. All of it. On the backend side it's microservices vs. monoliths.
    • Toine 5y ago
      This is way oversimplified. You can build a completely static website with NextJS. What I love about it is that you can do everything : SSR by default, SSG as an option, and awesome features like ISR etc. However, the way NextJS implements SSR is really weird right now : if you use their <Link/> component, the pages props are actually fetched with an XHR request, then the page is rendered. I don't know why. It does feel like an SPA in the end.
    • sinker 5y ago
      Next.js recommends delivering static assets by default and is geared towards that. > We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request. If you need dynamic content, they recommend server-side rendering, and lastly client-side rendering only if the page is unaffected by SEO and requires a lot of in-page updates. https://nextjs.org/learn/basics/data-fetching/two-forms https://nextjs.org/learn/basics/data-fetching/two-forms
• slashdev 5y ago
  I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me? I would use https://github.com/jfyne/live https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion, having many years of experience in both kinds of web apps.
  • pacifika 5y ago
    When I was reimplementing “reset state” for a logo click I knew it should have been serverside rendering.
  • aminerman 5y ago
    • hinkley 5y ago
      Harsh. Dude ported liveview, this isn’t amateur level work. It’s a useful brush but you can’t use it to paint everything.
      • eloff 5y ago
        I just want to clarify, I didn't create the LiveView port, but I think it's excellent work.
    • lp0_on_fire 5y ago
      Instead why don't you let us know why you think that position is incorrect rather than resorting to reddit-tier insults?
      • aminerman 5y ago
        Quoting another comment to OP "I am indeed (rude). You can have 100 years of experience, it doesn't make you more credible at thinking that engineers who makes choices that are different than yours as incompetent, by deeming them as mistakes. I mean, if a company wants to choose a tech stack, there are so many things to consider for that choice. Your article is just generic ideas about the fact that SPA are mistakes and SSR apps are better. You're not taking into consideration any of each industry's and company's means, priorities, specificities. In fact, your 100 years of experience are what's hindering your ability to see how useful SPAs are. And you're resorting to that same old narrative of "it was better before". It's also the niche you decided to position yourself in to sell courses and stuff. Which makes your ideas even more suspicious as they can't be unbiased. Like in politics, they'll dogmatically say that their opponents are wrong, just because they have a "market" to preserve. So yes, I'm rude, as much as you're inconsiderate to the vast complexity of software engineering, just to preserve your niche market. And as you say in your website: "Hate the complexity of modern front‑end web development? I send out a short email each weekday on how to build a simpler, more resilient web. Join 13k+ others." "
• deleted 5y ago
  [deleted]
• aminerman 5y ago
  Anyone can choose the tech stack, patterns, or whatever that he likes. But developers enjoy being absolutists, and deem something they don't like as a MISTAKE, or would tell you that the way they think is the ONLY way to think. You do your app the way you want depending on the Ux you want to provide, on the tech you enjoy implementing, on the patterns you like to follow.
  • commandlinefan 5y ago
    > Anyone can choose the tech stack, patterns, or whatever that he likes Maybe for personal projects, but 99% of us have to use the tech stack, pattern or whatever of our employer that was decided on (presumedly by some consensus at some point in the past). Publicly pointing out the flaws in what might have made sense then but might not make sense now is a Good Thing so that those flaws might be taken into consideration in the next round of consensus building.
    • hinkley 5y ago
      I don’t understand what sort of cave trolls think I get to decide for me. Even as a lead I am making decisions based on the situation on the ground and those are informed by what people are comfortable with and what I can help them get comfortable with. It’s a team activity. But every conversation has someone spouting off like these are experiments in a Petri dish. Petri dish projects don’t matter. Haven’t for a long time.
    • root_axis 5y ago
      Don't work for a company running a tech stack you don't like.
    • aminerman 5y ago
      That's what interview processes are for. And if the consensus goes for a stack you don't like, let's say for example for doing and SPA, then maybe it's not a mistake as stated in the article. Unless you guys think that any engineer that makes choices different than yours is incompetent.
• softwarebeware 5y ago
  I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?
  • aminerman 5y ago
    • tonyedgecombe 5y ago
      You keep making this ad hominem attack without presenting any evidence.
    • hinkley 5y ago
      You’re really enjoying that brush today.
    • vangelis 5y ago
      Don't be an asshole.
  • freeaccount 5y ago
  • gls2ro 5y ago
    I give you Google Maps is a perfect example maybe for SPA. But Gmail? Why do we need SPA for that? Receiving emails notifications could be websockets and clicking on email should go to a new page displaying the email. I dont know if the initial gmail was SPA or not, but the current version is very very slow and consumes a lot of memory to display some emails that worked even in terminal clients, remember Pine? The same for twitter? I anyhow have to press "Load 39 new tweets" to load the new ones so why is it a SPA? Just for that notification? If you would give me a twitter client where I need to refresh the page to load new tweets but works faster and consumes less memory I will happy use that.
    • 5y ago
• antihero 5y ago
  This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser. However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all. Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per say, they will mostly have buttons, which will have a some sort of defined action. Perhaps these buttons will navigate to some other screen in the application, however, reloading all of the client side state every time one does this is absurd to say the least. Finally, from a technical perspective, having a clear separation of concerns by having code talk to an API as opposed to HTML being rendered on the server, you remove a lot of complexity. It feels like the people who write these articles don't actually remember how utterly shit the jQuery days were.
  • aminerman 5y ago
    He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
    • antihero 5y ago
      It does feel like the tiring contrarianism type of heading as opposed to a particularly well thought out article. In the same way I feel lesser able coders seem to dwell on shit-slinging against tech that is proven, works, and has solved innumerable problems when they bang on about how things were so much nicer with vanilla JS and how frameworks are lazy and slow or something, in order to cultivate a sense of superiority. Any well made tech has it's place, skill and experience are about knowing which tech should be used where.
    • barbarbar 5y ago
      `
      • jaywalk 5y ago
        First of all, this is uncalled for. Second of all, it's not even an SPA. Maybe do the slightest bit of research before slinging shit at someone?
• teilo 5y ago
  Use them where they make sense, and don't get religious about it. I recently wrote a site to track Apple-silicon-native audio software. It works great as an MPA. It's fast, organized, and easy to use. And the first thing someone offered as a suggestion was: "Why don't you use https://www.sanity.io/ https://www.sanity.io/ for the content and nextjs or gatsbyjs for the front end?" I can't even.
• karaterobot 5y ago
  When I was a FE developer building single page apps, I would hear these arguments and say "you just don't get it, man, SPAs are the future". Now that I don't get paid to work on SPAs, these and other downsides come into very stark relief, and it's the advantages which seem more dubious to me. I doubt I'll ever touch an SPA again, and I'm not mad about that. Indeed: "It is difficult to get a man to understand something when his salary depends upon his not understanding it"
• midiguy 5y ago
  Every week someone posts some half-baked blog ramble about how SPAs are bad (except for media sites!). How about this - I am just as or more efficient working with SPA frameworks such as React as working with server-side-rendering. I have invested in a skill and toolset that can deliver any sort of website or web application from blogs to Youtube to Figma. I don't see any reason I would invest in learning an MPA framework that is only good for a subset of that. If you are delivering content-only website with simple forms you might as well just use a CMS and call it a day.
  • hinkley 5y ago
    Why are wood shops loaded to the rafters with tools? Because there is no Golden Hammer, only people who think they’ve found one. You’re saying you’re doubling down on a single solution, which is probably not actually true, but you are surrounded by younger developers who will copy what you seem to be doing rather than what you’re actually doing. All of these unresolved arguments are about team dynamics, not technology, which is why they never get resolved. Because we talk about our experiences or “objective” things like logic.
    • midiguy 5y ago
      > All of these unresolved arguments are about team dynamics, not technology No, it's definitely about technology. Let me simplify this for you. Technology A can do thing 1 very well, and thing 2 decently. Technology B can do thing 2 well, but can't do thing 1 at all. In reality, people who only do technology B claim technology B is necessary to do thing 2 and go to great extents to write blog posts claiming such, while people who only do technology A get on with doing things 1 and 2 without feeling the need to rant.
      • hinkley 5y ago
        Yeah that’s not a technology problem, that’s an ego problem.
• clivestaples 5y ago
  I think SPAs were the best solution we had at the time and I enjoyed trying to build good UX with them. Yes, React started fresh and ended up driving me back to Rails because I'm just not smart enough. That said, I am really excited about Django w/HTMX, Rails w/ Hotwire, and Next and Remix with React. Particularly Remix.
  • hinkley 5y ago
    I can get good at a lot of things, but most of them (including half the ones I’m good at) really just aren’t worth my time and energy. Ain’t nobody got time for that is more often closer to the mark. But anything that requires hypervigilance is eventually going to make you look dumb. Just don’t let them put “human error” on the RCA. Yes, You screwed up, but We put you there in the first place.
• stevebmark 5y ago
  Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet. SPAs and Jamstack favor developer convenience over end user experience. Let's have fewer loading spinners, and more SSR-by-default for pages with dynamic content.
  • kizer 5y ago
    But there's a cost savings, right? JSON requests for just the data necessary vs. sending the whole HTML page each time. Personally I'd prefer to develop a website the old-fashioned way, but I see that the bandwidth savings is a major point for SPAs and if you're running a business...
    • stevebmark 5y ago
      SSR by default, and then if you want, client side hydration and navigation so subsequent page loads happen in the client. However, the size difference between an HTML response and a JSON response is negligible, and HTML responses don't have to wait for Javascript to download, parse, execute, kick off off a request over the internet, get the data back, execute the result, and update the DOM. Browsers have literally decades of optimization to show HTML to users as fast as possible, and doing this in Javascript is fundamentally slower.
  • Graffur 5y ago
    > developer convenience This is really, really important though.
    • Nextgrid 5y ago
      Am I the only one preferring good old-school, "boring" stacks that I can run entirely on my own machine if needed and understand the sequence of operations as opposed to relying on dozens of third-parties, services, APIs, etc just to do what a stupid PHP script on shared hosting could do 20 years ago? I don't consider the modern complexity as convenience.
• fmakunbound 5y ago
  Seaside on Squeak (now Pharo), is still my happy place for web application development.
• vinceguidry 5y ago
  They were necessary from a perspective of "we need a way to develop a company's web presence in a way we can send kids to code camp to get the gist of." Of course they weren't a wonderful thing in terms of actually building sustainable infrastructure, but what's that to stand in the way of business's need to go to market yesterday? Code camps don't have time or resources to educate their students so we got the reinvent-the-world half-solution that is the SPA. SPA frameworks won't ever go away but you'll get the chance eventually to go work on something better-architected than your run-of-the-mill NodeJS shitshow.
  • toqy 5y ago
    I don't think that's accurate. SPA's arise from the desire to put something like Slack in a web page. If bootcamps are responsible for that, I don't see how. Isn't it more likely that they meet the demand rather than create it? And bootcamps taught Rails long before they taught React. And let's be honest, making a server rendered site with some traditional Python framework is in many ways just as easy or easier than making a SPA.
• elchief 5y ago
  Lame opinion, but I miss the (pre-license-change) ExtJS days Unified library of tools. An actual GUI designer to design layouts in. Now everything's just a mess
• ChicagoDave 5y ago
  Users do stupid things regardless of the implementation. The extra work to implement a SPA is worth it because you can swap material in and out on demand without constructing a complete new web page. 100% disagree with OP.
• nawgz 5y ago
  "SPAs were a mistake" Meanwhile essentially every major tech property develops SPAs and users enjoy them far more than traditional hypertext web round-trip-every-change pages
  • jmconfuzeus 5y ago
    Big tech companies love wasting money and developing a SPA is a good way to do that. Whether users prefers SPAs or not is debatable. Amazon, Github, and Aliexpress aren't SPAs because poor usability will cause users to move to competitors. If Hacker news turned into a SPA, I guarantee that it would suck big time. SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems.
    • nawgz 5y ago
      > Github In what world is this not an SPA? I don't see page transitions hardly anywhere, except when you're switching from marketing material to repos maybe. Additionally, the fact that GitLab (which is devops/issue tracking/wiki/etc.) ISN'T an SPA drives me crazy every day. I have to wait for so many rerenders that could just be seamless loads, it's actually insane to me how unoptimized of a user experience it is, especially when my happy path is super clear with respect to what content I load. > SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems I think it's hilarious who you consider to be living in a bubble, and what simplicity really means. Client side interactions need to be smooth. Web applications are consistently and increasingly presenting meaningful user workflows that can be made more resilient and responsive with SPAs. I develop tools for dataflow/workflow editing, scheduling, visualization, etc., and the idea that these things can be made to feel good without a dedicated client layer is truly an archaic attitude.
      • jmconfuzeus 5y ago
        You seem to be mistaken about what SPAs are. Github is simply a traditional Rails app that uses Javascript to enhance client side interaction. A ton of web apps provide data visualization features without being SPAs by simply using libraries like D3. I don't know what kind of apps you're building but claiming that everyone needs to start using SPAs instead of traditional progressive enhancement with Javascript is not right.
• wooque 5y ago
  I, as a user, hate them with passion. I regularly stumble upon stale data in SPAs, even in big names' like Linkedin, Jira, Github, etc. I wonder how the hell corporations with thousands of engineers, lot of them being brightest engineers in the world, can't make proper SPA. Can we just go back to server side rendered pages, with a bit of JS sprinkled in, please.
  • tmcw 5y ago
    Github is not an SPA. They use the middle road of dynamically loading HTML snippets, using webcomponents, and lightweight JavaScript. Any problems you see with most of Github's interface should be chalked up to server-rendered pages with sprinkled JS.
    • Nextgrid 5y ago
      I dread using GitHub's fake client-side navigation. For me it's always faster to just load a link "for real" rather than wait for their terrible JS to pretend to load the link for me.
  • Jcampuzano2 5y ago
    Interesting that you use Github as an example, when Github is not an SPA. So basically just admitting these problems aren't necessarily inherent to SPA's, but to the developers/teams building them. They may just be a bit harder to get right in SPA's.
  • deergomoo 5y ago
    > Github GitHub is a great example of a site that would benefit from actually being an SPA, imo. It is server rendered pages with JS sprinkled in, and you can easily end up in the situation where parts that live update fall out of sync with parts that don't. For example, being able to see that an issue is closed while the badge on the Issues tab still says you have one open. I share your general sentiment over the state of them though. It's not actually that hard to avoid breaking navigation buttons, having links open in new tabs correctly etc, so I don't know how it gets screwed up so much.
• root_axis 5y ago
  SPAs are ideal for web applications where users are manipulating application state in real time. There are many situations where this is applicable, you can't build something like e.g. Office on the web without an SPA, calling SPAs a mistake is trendy, but betrays an ignorance of the practical tradeoffs of an SPA.
• matchagaucho 5y ago
  I'm still bullish on the potential for Web Assembly apps to overtake mobile binaries. And instead of Single Page Apps, we'll have just plain Apps that run in browsers.
  • Dma54rhs 5y ago
    Since I assume you know about it a bit more, what is realistically timeframe it could happen at best?
    • matchagaucho 5y ago
      No idea on timeline. But I'd speculate Apple has no incentive to cannibalize their AppStore ecosystem and make Safari more than a web browser. So Google/Chrome or Firefox are the only 2 players with enough incentive to make Wasm an Internet app standard. Or possibly the next Wasm-first, cross platform browser will come along with a Wasm AppStore?
  • okeuro49 5y ago
    I would much rather program in any language that is compiled to web assembly rather than JavaScript.
• mithr 5y ago
  If the choice was between building a traditional app from scratch, or building an SPA from scratch, then I think the article would have a solid leg to stand on: building an SPA from scratch does involve finding ways around things that browsers provide out-of-the-box. However, pretty much no one writes SPAs from scratch, and there exist many very popular frameworks that handle the vast majority of the common SPA tradeoffs out-of-the-box, so that in reality, you don't really have to think about e.g. whether links are internal or external. That's not to say that SPAs are always a good idea, or that they do everything well — the author's point about scrolling to the right place, especially when navigating backwards and forwards, is one thing that many SPAs don't get right, for example. And the rise of next.js and the like have shown that there are other benefits to hybrid approaches, as well, and there isn't a one-size-fits-all solution. As for why SPAs have become so popular, I think this can be summed up pretty neatly: everything is code. There's something appealing to a software engineer about being able to control everything about how your app behaves, control when and how it loads or preloads data, how navigation works, etc. This comes with tradeoffs, you have to be careful about breaking user expectations and making things accessible, and if you go too far you can end up with a big mess ("just because you can make everything custom doesn't mean you should"), but that underlying freedom to make those choices is appealing.
• osrec 5y ago
  It is annoying to see titles such as this, since SPAs are most certainly not a mistake (the article itself points out that the Youtube SPA is not a mistake). The truth is most devs struggle to implement SPAs well. To implement an SPA well, you need to understand browser APIs extremely well (such as the History API), and in my experience, most devs don't, hence the broken back buttons etc. To me, there is nothing nicer than a well made SPA, and often, the best SPAs are faster and lighter than the desktop apps they replace. I believe they are the best way to deliver software in the current age, and the sandbox that the browser offers actually provides users with a more secure execution environment than traditional software delivery mechanisms. I personally LOVE SPAs.
• sigstoat 5y ago
  webapps were a mistake.
• kizer 5y ago
  Here's the thing: so-called "JAM stack" apps are the cheapest to run, right? I realized this while I was thinking about how to create the cheapest site possible. Mainly, you want to minimize bandwidth. Well, SPAs are designed to do this. The site gets cached on the first hit, and runs usually JSON requests in the background after. So I think a big motivation for building SPAs is because they're cheap to host/run.
• pictur 5y ago
  I have always wondered how people gain this self-confidence.
• cdelsolar 5y ago
  no they weren't, stop with these clickbait bad takes
• AtlasBarfed 5y ago
  The issue is you need some of both for an "optimal" solution. Unfortunately, Javascript and the basic "controller" capabilities of a web browser just aren't up to the task. Here are your "controller" options: 1) the server is the controller 2) the web page is the controller of itself (which sucks) When what is probably needed is: 3) a controller that lives as an extension of the browser. Frames, for all their issues, basically enabled #3. A controller frame could manipulate the view frames, and those frames were scoped/contained web page "processes". There were issues of course, if you hard-refreshed the overall page (and the "controller" frame) it would lose state, so I don't want to say that frames were a complete solution. Client storage is half of the equation, and that was added. Good caching infrastructure, multiple asset delivery, connection multiplexing, that seems to be working so you don't need a "big bertha" first page. Standardized DOM capabilities and the like seem to be fairly well solved, and maybe the "Javascript problem" will be solved once ... crap the thing where you have an IR bytecode so you can code in anything in a browser... well that will be solved. Frankly this needs to be solved. Apps and app stores are a pox upon the land, and the web browser can still save us from that.
• todd3834 5y ago
  To me one of the biggest distinctions here is the overuse of the term "App". I agree that a lot of websites written as an SPA were the wrong tool for the job. There are tons of examples besides the mentioned media websites where SPA is the way to go. Most, but not all, of the applications I work on feel like desktop class applications and the traditional server side rendered approach simply would not work. This includes when I was on the iCloud Web team working on the iCloud Drive App, the Mail App and some others behind icloud.com. I think a lot of companies that default to SPA would benefit from a very quick traditional website. However, some of the applications that I've been fortunate enough to work on would never be possible.
• kizer 5y ago
  Also, more SPA framework logic needs to become part of the web platform; APIs beyond pushState, service workers, etc. You have to integrate it into the browser to really remove the confusion and the boilerplate.
• andix 5y ago
  A SPA is an Application and not a Web Site. With a SPA you can replace classical desktop or mobile applications, for example Gmail, Spotify or maybe Dropbox. SPAs are good for that, because you just have to develop it once, instead of 5 or 10 times for all platforms. SPAs are bad for traditional websites that deliver content.
• goodpoint 5y ago
  The web is a mistake.
• ravenstine 5y ago
  Nah, they weren't a mistake, at least not in isolation. Much of modern software development is a mistake, generally speaking. When you look at it that way, SPAs only failed in the sense that Object-oriented Programming failed, as well as the failure of various design patterns, microservices, write-once-run-anywhere, test-driven development, decentralization... I can go on and on with the number of engineering and computer-sciencey crap that never really lived up to its promises. SPAs only suck as much as we suck. Just admit that SPAs are like any other tool, and if we're going to swing back to apologizing for goto-statements (something I don't necessarily disagree with) then we can't at the same time act like SPAs are a mistake in and of themselves. We collectively continue making mistakes and instead of owning up to our collective lack of craftsmanship, we are blaming the tool. Only when we shed the mindset that informs us that computer "science" is actual science might we then be in enough touch with reality that we seriously impose some standards upon ourselves to address our clumsiness.
  • laerus 5y ago
    why do you think TDD failed :( Doesn't every other science field work pretty much the same way though? We make mistakes, we iterate, we make new and better mistakes. It may be too obvious in software cause it's easy to create stuff and iterate very fast cause there aren't so many natural constraints. Someone may even argue that this is what makes software also an art.
    • ravenstine 5y ago
      TDD, or rather the effort behind TDD, failed because its proponents couldn't help but preach it as a cornucopia of solutions with the insistence that it's appropriate for every circumstance. When you are familiar with the domain of a problem, TDD makes a lot of sense. For the project I'm working on now where I'm effectively learning at just about every step of the way, and said project is intended for very few users, it's highly questionable if I could have benefited from TDD. Even when I'm not doing something unusual, TDD doesn't always make sense. Any research that currently exists around TDD is of poor quality and proves little, but TDD fanatics (not sure how many of them exist anymore though) speak like there's objective evidence in their favor. And some call this sort of thing "science"? By the way, when I mentioned science, I was specifically referring to the concept of "computer science", of which there has been very little actual use of the scientific method in our lifetimes. Computer science is of course a legitimate area of study; if our heads are still so in the clouds that we are still calling it a "science" then it's no surprise that we're continually losing touch with the very technologies we create. TDD also shot itself in the foot with this (IMO toxic) insistence that the tests are the documentation, which is a nice principle to keep in mind, but I've never seen it come close to replacing actual documentation. A simple comment block describing the why of a function is always better than scrolling through tests and reconciling inconsistencies with the mocks that were used. And yeah, I know that TDDing isn't really about "mocking", but let's face it [...]. Perhaps the worst thing of all is that TDD is founded on a somewhat dishonest implicit premise, which is that if you aren't TDD'ing then one must be either not writing enough tests or are writing inferior code because one is writing tests after development. TDD fanatics, in particular those freshly inducted into the cult, often think it's either TDD or nothing, and if you're not TDD'ing one particular part of an app then you're not following "standards". Maybe TDD is fine as a form of guard rails when you're a junior developer, but by the time you're a high mid-level and in touch with reality then you're going to intuit whether a unit of work will actually benefit from TDD. TDD isn't bad at all in terms of its mechanics. It's a great idea, and I've used it many times. In fact I even TDD'd an entire web app that handled payment processing from start to finish. The part about TDD that "failed" was this belief that it is actually a generalized solution that needs to be applied everywhere, which lead to it both being misapplied as well as dismissed when it becomes apparent that those promises of better and easier code/process/readability often don't magically manifest. This is really the story behind just about every failed idea related to our field, not just TDD. SPAs were supposed to make pages snappier because it meant server responses to different user actions would require fewer bytes and no page refreshes. Instead of viewing SPAs as a tool with a purpose, people had to treat SPAs as the end-all-be-all of frontend development and a way to do everything, and now the world is stuck with many SPAs that are likely worse than if they were done as regular webpages.
• austincheney 5y ago
  > Browsers give you a ton of stuff for free True, but irrelevant. I have written an OS GUI, including full file system support, in the browser that performs faster than native OS GUIs. My biggest learning from this is talking about performance in a job interview is the fastest way to kill the interview. Performance, like security, requires trade offs that deviate from comfort. If the common developer is insecure comfort is the only thing that matters. JS hiring expects the following: React components, 2-6 weeks of JS practice, the ability to use map/filter on arrays, and CSS. If you overshoot that you begin to enter unknown territory that intimidates other developers. The better you are the less employable you become as the further from the bell curve you drift. If you are wondering why this is or how we got here the answer is trust, or the lack thereof. In software there is a long standing bias: if you can see it visually its worth less. I have been doing this work for more than 20 years and that bias predates my work, so its been around for a while. Bias is continuously reinforced by the lack of standards in software hiring and the inability of employers to train their employees. This lack of trust means that employers do not trust their employees to perform original work and likewise the developers don't trust each other. This is why absolutely everything, I mean this literally, is a downloaded NPM package, because the developers will trust an anonymous stranger to write original code before they trust anyone they know. There is all kinds of excuses to qualify this, of which some are bizarre and nearly all lack any kind of merit. This is why its irrelevant what the browsers provide. Its baked into the framework, an NPM package, or ignored.
• bluewalt 5y ago
  I think one of the main reason SPAs are overused is because it's hard in 2022 for your users to wait after clicking on a link. Users are now used to instantaneous, especially since they all have a smartphone with apps on it. We, as web developers, try to give the best UX to users.
  • gls2ro 5y ago
    I agree with you and I think there are some good SPAs. In my case what makes me angry is opening a presentation website and seeing a loader because someone decided to make that a SPA.
• me_me_mu_mu 5y ago
  I had the pleasure (aka hell mode) of building a content site as a SPA because some non-technical manager kept pushing it (it was one of those companies). It was an insane task to meet all the SEO requirements, we ended up doing server rendered pages, and keep in mind this was years ago so there was not a whole lot of support or tutorials on how to do it. Oh well, I got paid to learn a bunch of new stuff so I can't complain :D
  • chilldsgn 5y ago
    Yeah, I was gonna say SPAs are not really good for marketing type of sites. Doesn't work easily with SEO. I learned this the hard way, but there are other use cases for SPAs. Just don't use it for sites that require good SEO. I am pushing for a rebuild of that site using Laravel and minimal amount of javascript, actually :D
    • me_me_mu_mu 5y ago
      That was the worst manager I've ever worked for. He also never pronounced my name right even after I told him, so he can go f** off. Still triggers me to this day :D He pulled the SEO requirement at the last minute, since he would not invite the technical people to decision meetings.
• barrenko 5y ago
• k__ 5y ago
  While Web2 is moving to SSR, I think SPAs will be a huge part of Web3. SPAs are perfect for decentralized infrastructure like IPFS and friends. Same goes for mobile apps.
  • gls2ro 5y ago
    What exactly from SPA is making them good for decentralized?
    • k__ 5y ago
      Can be put on IPFS without much hassle.
    • deleted 5y ago
      [deleted]
• Zaskoda 5y ago
  In my humble opinion, SPAs are not the fundamental mistakes. SPAs are applications. There's nothing wrong with having applications. The mistake was not maintaining a distinction between applications and content. The difference between a static document, a collection of hypertext documents, and a web application is very blurry. If it were less blurry, there would have been things we would have been able to do that we are not currently able to do.
• hunterb123 5y ago
  This opinion gets reiterated over and over and it's still wrong no matter how many times you say it. SPAs are just apps. I'm sorry people can't tell the difference of when you need a site and when you need an app. That doesn't make web apps a mistake.
  • Jensson 5y ago
    But it is so strange, most SPA's are basically just power point presentations. Why did it go like that? It isn't like people look for programmers to replace their power point presentations or PDF's, but for some reason that is exactly what they do on the web.
• dec0dedab0de 5y ago
  I've been thinking about this a lot, and the one thing I love about SPAs is that everything the user can do from the front end. They can do from the API. The trend has essentially tricked tons of corporate apps into opening up APIs to their users. My screen scraping skills are starting to get rusty, but it's worth it. I sometimes daydream about a framework that allows me to build a spa and a server side app at the same time using the same url scheme.
• EMM_386 5y ago
  My company wouldn't know it. I'm lead on a large Angular 13 app used by tens of thousands of companies, it works and it's very fast. I wouldn't call SPAs a mistake. I have 2+ decades in the industry and come from an ASP.Net / MVC background prior to Angular.
• beardedman 5y ago
• shroompasta 5y ago
  It's posts like these where I can feel the age of HN. For many developers, especially in startups, SPAs are all they've ever known. Now, I'm relatively young, but I'm old enough to know monolithic django before moving onto angular then onto react, and it is quite staggering what I'm capable of doing in SPAs as opposed to traditional web pages. You mentioned Soundcloud and Youtube, but you'd be lying to yourself if you think the list comes even close to even stopping there. How about fantasy drafts in DraftKings, Sleeper, or FanDuel? How about chess like chess.com or lichess? How about collab tools like Trello, Monday, or Asana? I wouldn't even dream of building these types of applications in a traditional web app The level of interactivity that is capable within SPAs makes applications like these seamless and snappy, and overall feel-good for the user.
• mattlondon 5y ago
  Most of that navigation stuff is long-solved - e.g. Angular's router will do a lot of that. If you want to do a SPA without a modern library, then yes you will need to reimplement a bunch of stuff. But who would start from scratch? Unless you are doing something incredibly niche or tiny-tiny-tiny, just use Angular or React or whatever and don't worry about the minutiae. Of course there will now be people screaming at their screen about how this attitude is everything that is wrong with the modern web etc. I am sure they'll get over it one day, or just go use gopher/Gemini if not.
• thaway2839 5y ago
  The argument appears to be that browsers give you a lot of things for free that SPAs need to recreate. But that's not true in practice. In practice most SPAs are created on top of a handful of extremely well tested libraries/frameworks that do all the work for you that the browser would do in an MPA. That's not really a good reason that SPAs are a mistake.
• MaxMoney 5y ago
• mrvenkman 5y ago
  The article does give good examples of where SPA works.
• i_have_an_idea 5y ago
  No shit, Sherlock. Of course, all of this was obvious to any of us with more than 5 minutes of industry experience, alas this field seems super prone to reinventing the same things over and over again, making the same mistakes and never learning from the past. Also, this article does not even mention the fact that SPAs are terrible for SEO. Of course, that's not an issue for YouTube, but it might be a huge issue for your clients, unless it's ok to not have any search traffic.
  • randomsearch 5y ago
    SEO for SPAs is a solved problem
    • i_have_an_idea 5y ago
      It is definitely not solved for the vast majority of SPAs out there. Where it is solved, it is not solved for free or cheaply, as it would've been if these apps used server-rendering tech.
      • randomsearch 5y ago
        Obv there’s next Nuxt etc but Doesn’t Google’s crawler “render” JS now?
        • i_have_an_idea 5y ago
          Kind of, but it is done separately from regular indexing, at a much lower volume and it is filled with loads of gotchas [1] that can make Googlebot skip your site. In practice, what happens is Google spends their JS rendering resources on the top sites and will very rarely render a new site. Generally, assuming you stay clear of all the gotchas, Googlebot can eventually "see" your JS-rendered content but it will certainly take a lot longer to be indexed and, therefore, it will take longer to appear in search results. If you or your clients rely on organic search traffic for your site, then picking client rendering based tech is certainly a bad decision. [1] https://developers.google.com/search/docs/advanced/javascript/javascript-seo-basics https://developers.google.com/search/docs/advanced/javascrip...
• deleted 5y ago
  [deleted]
• synergy20 5y ago
  Unless you already have a SSR in place(or you're familiar with it, e.g. Django, Laravel, Rails,etc), I feel SPA(or MPA) is actually a decent choice albeit the learning curve. Separation of concerns is always good. With SPA frontend developers can develop the UI using restful or some web APIs provided by the backend, while backend engineers can advance the server side and keep the API consistent.
• nhoughto 5y ago
  Not the reasons I expected I don’t see Navigation as a main problem and it can be solved quite neatly, not that much more complex than a normal site. Was expecting something about bundle size etc.
  • themanmaran 5y ago
    Agreed. The blog doesn't seem like a very thought out examination, and I expect most of the HN replies are just debating the title. For me, the biggest con of SPAs is lack of SEO.
• gunapologist99 5y ago
  REST API's (literally, "Representational State Transfer", ReST) are a very nice match with SPA's, because now the browser is the sole source of truth for application state (and the server only has to produce some JSON data instead of entire HTML pages). Literally the entire point of REST is that you don't have to maintain server-side sessions, and you shouldn't. This also has benefits for scalable applications, in that you can transfer your running application to a cluster of servers on the other side of the world, and it'll still keep working. The trust boundary between the front and back ends can be a huge boon to security as well, and some things are literally impossible to do with a multi-page app, and you can still maintain URL parity with new actions in your page. That's why SPAs were, and are, great! That doesn't mean everything should be an SPA! A photo, news, blog, or recipe website might be better laid out as a separate page for each individual item. However, there are tons of other types of real applications that can only be built as an SPA. Are they unwieldy, sometimes hard-to-code and maintain, and sometimes result in a poorer experience? Yes, but that can also be true of a multi-page app, especially if you're trying to shoehorn an SPA experience into a multi-page app and want to maintain the same user experience as a user moves around within the app. A multi-page "app" isn't really an app anymore; it's a server-side app that is producing multiple pages. A single page app literally is running in the browser and only sending a bit of data back and forth with each user interaction. It's just a completely different model.
• AtNightWeCode 5y ago
  ANY modern site uses something like nextjs or any other static site generator. The q is then if you make the site isomorphic or not and how the need for dynamic content looks. There are no other viable options today for large professional sites. If you have the problems described in the article you probably are not using a web framework.
• seer 5y ago
  One thing that I found working in a bigger organisation is just how well React encapsulates Design Systems. You can have a dedicated team of talented frontend engineers that builds a really solid design system, and then other folks building the actual user facing bits can use them, and everything will be nice and consistent across all the various apps. For example look at how well this has been going for Uber. Now this is certainly possible, and even relatively easy to do in server side frameworks, but as others have stated, its harder to make sure it works nice in all the various edge cases and visual flair that is required for end users, and keeping it all consistent and upgradable across the board. React (and I'd wager other component based approaches) shine there - its low level enough that you can implement anything with it, but still allow you to build complex things fast. And then are free to implement the actual business logic of the backend with the technologies of your choice. Even better various teams can do that in their preferred language, without the end user being affected by the difference. Throw in react native to make the styles transferrable to mobile apps and you have the perfect sweet spot for largish tech companies. And since those tend to be the more vocal ones, we get this, in my opinion largely deserved desire to build SPAs. Smaller teams / startups of coarse don't have those incentives, so they will understandably not have the same cost / benefit analysis.
• thepra 5y ago
  I guess Blazor WASM is the elephant in the room. OOP as much as you want, js codebase required near to 0.
• bluetwo 5y ago
  If it makes you feel better, SPAs were a mistake when they were all the craze in Flash. Also way before that in Director. In those two cases, they signified (or accelerated) the end of the useful lifespan of those languages. SPAs, like frameworks, always make some things easier and some things harder. As long as you stay within the lines of what is easy, you are good. As soon as you stray outside those lines, you get punished.
• randomsearch 5y ago
  Controversial opinion: SPAs are great and also SPAs are an admission that Java applets were along the right lines.
• simonw 5y ago
  It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states, and the "interactivity" mainly consists of form submissions that don't trigger a full page - which could have been done for a fraction of the cost (in development time and performance) using a 2009-era jQuery plugin! And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons. I started out thinking "surely there are benefits to this approach that I've not understood yet - there's no way the entire industry would swing in this direction if it didn't have good reasons to do so". I've run out of patience now. Not only do we not seem to be learning from our mistakes, but we've now trained up an entire new generation of web developers who don't even know HOW to build interactive web products without going the SPA route! My recommendation remains the same: default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit. Don't default to building an SPA.
  • fennecfoxy 5y ago
    Idk I don't think the problem is the SPA itself, it's bad design patterns that that make it terrible as you say. I think really clean, performant SPAs can definitely be written and I think the overall experience of using a SPA can be much better than a multi-page site if the task at hand requires it. There should be two parts of the web now really: * Traditional multi-page websites * SPAs that could have been a native app on the device, but are much more accessible in web form and without requiring an install
    • midrus 5y ago
      The alternative to SPAs is not 90s pages reloads. Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.
• aelzeiny 5y ago
  SPAs exist for a reason. Same with SSR. Developer ergonomics play a bigger role than you think. And if you think that the choice is either SPA or SSR then you haven't been paying attention to recent developments in the frontend world. Websockets+SSR (PhoenixJS) attempts to store state on the server rather than the client; in that way you can still have stateful interactions with minimal JS. NextJS does an amazing job patching the bridge between SPA+SSR by having the same codebase run on the backend and the frontend. What I would like to see more of from this industry is less "grass is greener on the other side" and the unification of a single tool that allows for the cross-collaboration of SPA + SSR without having two distinct codebases that one has to context-switch between.
• crescentfresh 5y ago
  I showed an interviewer a piece of something I built in a traditional page-per-view design, with some xmlhttprequest where appropriate, and a sprinkling of Vue where it added usability to some of the modal dialogs. Their only response was "why didn't you build it in React?". I stopped interviewing for front-end work since then. The landscape changes frustratingly too often.
• winslett 5y ago
  SPA's #1 draw back is that you have to rebuild browser functionality inside of the browser. The browser natively handles internet connectivity, back / forward buttons, refresh buttons, URL management. Additionally, users have been trained to understand the responses, hit the refresh button, and use the back button. Browsers have gotten better at distinguishing between your internet being down and the website being down. Good SPAs have to rebuild all of that functionality.
• blablabla123 5y ago
  I think SPAs are awesome, there are just so many cases that SPAs can handle easily and more gracefully. From non-redundant input checks over interactive elements to optimizations for spotty networks or even offline usage. Anyway, it's painful when a page won't load or it takes 10 seconds to load for no apparent reason. That's why profilers need to be used, loading indicators within the elements and also there's the trend towards frameworks with small footprints or even to go framework-less.
• jdrc 5y ago
  the frustrating thing is that i rarely find a page that doesnt take at least 20 seconds to load, even if i only want to see an 100x100 image. This happens no matter how fast computer i use and it 's despairing The term "server-side rendering" gives me giggles every time
• donatj 5y ago
  I have in my life used a couple of SPAs where I thought "Man, this works really smoothly and quickly!" Like there have seriously been a couple really good ones. They absolutely can be done right, I've built one I think is done right. I've built a couple. I don't think the average team has it in them to build a good SPA. The majority of SPAs are user hostile hot garbage. The 95% of other SPAs were full of minor frustrations that could have been easily avoided by not being an SPA including 1. Completely unhandled errors with no indication anything is wrong. - This is a majority of SPAs. Any request error on flakey internet? Don't bother tell the user, just break. - The sheer number of times I've needed to open inspector to see that something has gone wrong… At least an actual non-SPA request that fails will show you an error page. 2. Broken… native… everything - 2.1 Especially "broken open link in new tab"/middle click - see next. 3. Inability to run the site in multiple tabs. - State is entirely local so state gets broken *easily*. - Some just outright refuse and warn you. 4. Adding everything I do to the browser history api - Makes it even worse than the back-button-not-working of old. Have to hit back a thousand times. - Scrolling SHOULD NEVER add things to my back button. NEVER. 5. High CPU usage on a site doing seemingly nothing - Looking at you, Medium. 6. Generally being way slower to use than the previous non-SPA website - Looking at you, Wells Fargo. 7. LOSING MY POSITION ON HITTING BACK - The sheer number of times I've been scrolling down an infinite list for like 30-45 seconds, click on something, nope not what I wanted, hit back, returned to the top of the list is entirely unacceptable as a society. - This is very often combined with 2.1 and 3 to make for a truly infuriating experience Like don't get me wrong, you can do a lot of this junk in a non-SPA but the failure state is almost always better.
  • com2kid 5y ago
    > Inability to run the site in multiple tabs. State is entirely local so state gets broken easily. I have seen this more for sites where a TON of state is stored in the backend, the site expects the user to have 1 tab that is kept in sync with what the server thinks that user session is doing. Heck I have seen sites that throw up errors asking me not to open multiple tabs. I have also seen sites where if I have Tab 1 on Page A, and I open Tab 2 to Page B, then go back to Tab 1 and navigate to Page C, if I go to tab 2 and try to navigate anywhere, it just goes to Page C. Fun times when the server has too much state.
• Aerroon 5y ago
  SPAs are just Flash 2.0, except it's not popular to hate on them like it was popular to hate on Flash websites.
• romellem 5y ago
  These types of posts always miss a common reason why an SPA might be desirable in the real world: cross-company collaboration. The assumption made in these posts is that you have total control over your entire application stack. Infra, Backend, Frontend, Ops, etc. In the real world, often times different companies are collaborating to build a final product for a client. I worked at an agency that built an SPA because the frontend and backend were built by two separate companies at the same time. We’d meet to agree on what the APIs would look like and what shape to expect in the data payloads. Once we had some sample data, we could build a UI against that data. When the real API was ready, we just switched the URL in the app config and everything started working. If we didn’t build that as an SPA, we wouldn’t have been able to make the deadline the client was aiming for. In a perfect world, would this have made sense to build as a MPA? Probably. But in the real world, you sometimes have to build things given some non-ideal constraints.
• sdegutis 5y ago
  Traditional dynamic web servers can solve a lot of the same problems that SPAs and event front-end frameworks like React solve, by just applying software engineering principles to the whole stack. That's what Novo Cantico[1] does, and a lot of what I've been trying to say in my blog posts[2] that explain Novo Cantico. [1] https://github.com/sdegutis/Novo-Cantico https://github.com/sdegutis/Novo-Cantico [2] https://www.novocantico.org/blog https://www.novocantico.org/blog
• bob1029 5y ago
  The fundamental conclusion I reached is that all of the pain originates by having your state divided between client & server, and then being forced to synchronize the two. Doesn't really matter what technique or framework is involved. The worst trip I've had is with angular 2, trying to put humpty dumpty back together again via tons of janky API calls. The best solution I have used so far is probably Blazor. In server mode this gets you pretty damn close to 100% state lives on the server. I've had to write some javascript, but even then the abstractions for interop make it very clean throughout. I use eval to dynamically run methods against the client. This allows me to avoid having to serve any custom javascript source (aside from the blazor client js).
• marvinblum 5y ago
  This article doesn't seem to be thought out properly. I mean the name already suggests what Single Page _Applications_ are good for. They are useful when you want to build an application in a browser and not just a regular website. State is probably the main factor why you would like to do this. I can agree on that SPAs are used in some places where they don't fit (mostly content heavy sites). But they are not a mistake.
• tracker1 5y ago
  For me, I mostly work on applications, the UI just happens to be in a browser. This is different from server rendered sites that may make more sense in some scenarios. I happen to really like, React, Redux, Material UI, etc... ymmv.
• bvrmn 5y ago
  It's funny how author reinvents caching on service workers in next daily tip instead of relying on browser caching.
• philipphutterer 5y ago
  well summarized. its easy to make bad SPAs nowadays. imo more time needs to be spent in the tool/environment/framework/language selection and evaluation process. also, many SPAs cant even handle basic forms correctly anymore, because developers learn more javascript than html5. like the author pointed out, rebuilding features in js that already exist, just because one is unaware of the fact that it exists or what the underlying design choices have been, often is a bad idea. are there actually still people that care about noscript? i mean, i get that most people dont care and js is enabled by default in most browsers, but the no-js-web-world is also quite interesting.
• v0idzer0 5y ago
  I usually bite my tongue when these articles pop up weekly, but let’s ask ourselves a question: did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something? I’ve recently worked on converting a large code base to an SPA and the improvements in DX, UX and performance are enormous. Even the old timers that resisted the project have all come around. This doesn’t mean your blog should be an SPA. It shouldn’t. but reducing the valid use cases for them to Youtube is equally ignorant. I generally agree they are being overly applied, but that’s not an indictment on the technology whatsoever. Fads in technology happen (“rewrite it in rust” is a recent one). The fact that many people are falling into this fad says nothing about Rust as a technology other than people love it enough to overuse it.
  • blakehaswell 5y ago
    > did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Is that so impossible? There are many other considerations that go into technology choices at these companies. There are trade-offs involved, and for companies with huge teams of developers the considerations need to be very different than for small–medium sized groups of developers. I would argue that a smaller group of developers can focus much more on user experience and engineering efficiency, whereas a large company has a organisational scaling issues and a significant bureaucracy to support. At a large company, engineering considerations come second to very many things. It would actually be surprising if the trade-offs and choices those companies made were correct for other very different companies.
  • Nextgrid 5y ago
    > did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something? Today I opened the Music app on my Mac to cancel a subscription. It asked me to use Touch ID to authenticate (fair enough) but then immediately fell back to asking me for my Apple ID & password. This is on a Mac that's been logged into iCloud for ages, has a working iCloud connection (exchanged some files through it today) and I installed an app from the App Store today (without being asked to reauth, suggesting my session is indeed still valid). The fact that MacOS frequently asks for Apple ID credentials seems to be a common and widespread problem that I myself experienced for years (sadly this occurrence wasn't a surprise for me - if anything the initial Touch ID prompt was more surprising as I couldn't believe it would actually not ask me for my password this time), so I wouldn't use big names as a sign of quality - if anything it's the opposite, big names means lots of employees who might have their own reasons for doing certain things or preserving a status-quo that might benefit them & their careers at the expense of the user experience.
• lmilcin 5y ago
  I love SPAs. When used correctly. SPA stands for Single Page Application. It makes sense when what you expect is an actual application. Tools that just happen to be running within a browser for convenience. The browser just happens to be delivery mechanism. On the other hand if the user expects navigable, hyperlinked content, SPAs just get in the way of navigation and make users' lives miserable for no good reason. I want to move forward, move backwards, make a bookmark, open multiple tabs. It is frustrating when the application makes it impossible when those would be completely reasonable operations on, say, news site.
• gefhfffh 5y ago
  I wonder how you would build an encrypted messenger like like Element (app.element.io) without SPA style. I think it's not even possible, since you are required to process incoming messages client side and must not send any private keys to the server.
  • Nextgrid 5y ago
    This is irrelevant in practice because the SPA's code is also loaded from the server - if the server is malicious it'll just serve you backdoored JS, unless you load from a separate domain and have the main server allow cross-origin requests. If you want to defend against a malicious server you need to make sure your client doesn't load & execute code from said server - it needs to be distributed as a stand-alone application instead of in a browser.
    • gefhfffh 5y ago
      > unless you load from a separate domain Which is the case... app.element.io doesn't host a Matrix server. Servers are completely independent of that.
• harel 5y ago
  Using them for everything and everywhere as a default option might have been a mistake. SPAs in general are not a mistake (but generalised headlines do bring in the clicks so there's that). As a user, when I'm using an "application", on the web or the desktop, the last thing I want is for the entire UI to be reloaded for me after every action. For applications it makes sense to be run on a single page, fetching only the data when it's required and that's it.
• metta2uall 5y ago
  This is probably true if you're writing an SPA from scratch, but in reality much of that complexity is handled by libraries like Next.js. I also think it's much easier to learn a React-like library than to learn various server-side template frameworks..
• rvr_ 5y ago
  I am mostly on the SPA-hating camp. There are two issues that annoy me the most. They are not a framework's fault but some kind of "mental model" fault: First. When doing SPAs, APIs tend to leak a lot more info than needed, opening the door to attacks not commonly seen on server-rendered pages. Second. Applications' bundle tend to have way more than users needs, even UI's they should not have access due to security/permissions. Most developers are not even aware of this problem and don't know that sensible info/features/endpoints are leaking. As I said before, those are not faults at the framework level, but the development style that I seed used when making SPAs always led to them.
• stevage 5y ago
  >This is, in theory, supposed to result in web apps that feel as fast and snappy as native apps. What a bizarre premise. We don't build SPAs as alternatives to native apps. We build them as alternatives to server rendered web apps.
• proxybyte 5y ago
  lol another developer who hasn’t built an enterprise web app that requires The be benefits of a spa… and hasn’t taken advantage of the best practices around redux state management. Have fun with managing state in the server while building apps that work internationally and offline.
• foxhop 5y ago
  Of course, but who would believe us if we told u sooner?
• kumarvvr 5y ago
  I found that Blazor to be a right mix between server rendered pages and SPAs. The programming model is good and adding interaction is easy. The only issue is with scaling.
• kromem 5y ago
  Everytime I see one of these binary "XYZ is good/bad" posts I come away thinking that either I don't know what I'm doing, or the author doesn't. Having built relatively simple Django web applications, and having built and managed building complex SPAs with Angular/React and GraphQL backends, I have a hard time thinking of when I would ever willingly grab for serving up dynamic HTML ever again. The mixing of concerns with something like Django vs just having a native JS application loaded and running in the browser pulling in data as needed once loaded is a world of difference. Using straw man examples of people using a technology badly to claim the technology itself is a mistake is silly. There's literal annals of examples of poor memory management in compiled software causing massive issues. Is allowing memory management to be handled directly by software engineers a mistake? In some cases, yes, people would be better off with garbage collection. But you'd have a revolt in embedded systems development if that was taken away. SPAs create more surface area for inexperienced or poor developers to screw up the UX. But a talented team developing SPAs (which really is a misnomer as you're rarely not chunking and lazy loading things behind the scenes) will ALWAYS result in a better UX for users than dealing with the browsers loading individual pages, and very likely more manageable development too. That said, as I've spent more time in development I've noticed there's a noticeable shortage of talented teams out there.
• intrasight 5y ago
  If it's an "application" there are no "pages" as that's an old (very old) and deprecated construct. Now if it's a "web site" with a collection of "web pages" - that's another matter. I've been building commercial SPAs now for over 20 years and I can say with much authority that users prefer "applications" over "web sites" for complex business management tasks. I've also built some pretty huge static web sites (longwoodgardens.org for example) and it an absolute joy to do those as well. I would never recommend to such a client that they build an SPA. So I'll state this opposing view - that "web sites" were a mistake when used for complex business applications.
• mo_s_i212 5y ago
  I'm building business application at my job. Users navigate (filter, configure, visualize 3D models) huge lists of data (bill of material, product structures). SPAs are heaven sent. Delegating every filter or configuration action to the server would be insane. Same with server side paging. Another example is 3D viewing: When selecting a part in the viewer detailed data should be displayed. A round trip to the server for this? No, thank you. I have to heavily disagree with this post. Which by the way lacks any in depth arguments.
• adriangrigore 5y ago
  I'm still insisting that progressive enhancement was the way to go.
• code_duck 5y ago
  I just wanted to note that the example - YouTube - is not an SPA. A click on a video from the homepage loads a distinct page, along with user profiles and other areas of the site.
• agrippanux 5y ago
  This article could of just said “use NextJS” and saved a lot of words
• eternityforest 5y ago
  SPAs are great when you're actually making an app. It's a little less great when you're just putting a browser in the browser so they can browse while they browse. Even then sometimes it works when the content is more app like and you don't want to set up a bunch of js and websocket connections with every load. Maybe we need some new easy to use APIs for JS that persists it's state between pages.
• deleted 5y ago
  [deleted]
• democracy 5y ago
  I also notice how much longer it takes to build the same crap we built 15 years ago with just html/css/js, and no, projects these days are not more sophisticated. Same old form submissions, but with a monstrosity of a project and crazy rates of devs who wants to constantly upgrade/update/migrate so some newer JS framework :shrugged :evilsmile
  • nfw2 5y ago
    Many projects are absolutely more complex than they were 15 years ago. The web is now a space for fully-interactive applications, not just interlinked documents and forms
    • democracy 5y ago
      I am comparing apples to apples (CRUD to CRUD), not some random websites.
      • nfw2 5y ago
        Okay apples to apples then This is Amazon in 2006 https://www.webdesignmuseum.org/timeline/amazon-2006 https://www.webdesignmuseum.org/timeline/amazon-2006 Now Amazon landing page has: - Omni-search with autocomplete - Dynamic language and region selection - Quick order forms accessible by profile dropdown - Many submenus embedded somewhere on the page - Multiple carousels of content embedded throughout the page Nothing like Amazon's current landing page existed on the web in 2006. Basically everything was just CRUD back then. Simple CRUD applications are becoming increasingly rare
        • democracy 5y ago
          yeah, most of them plugins are still jquery-compatible, so...
• nfw2 5y ago
  I have worked as an engineer on products in a lot of different domains in my career including: - edtech - real estate - HR/payroll software and every single project I've worked on had enough complex state to benefit from using a SPA. I've also worked on one complex web project run by someone dogmatically against client-logic, and it was absolute hell. The codebase was full of janky hacks to approximate the same complex session state and full interactivity that a SPA provides trivially. This whole thread seems like a huge echo chamber of people who seem annoyed that FE development is getting too complex. But do you all really think that the entire industry is so disconnected from its needs, and the entire community of FE engineers just have their heads in the sand about the requirements of working in their domain of expertise? And to everyone saying SPAs are sometimes useful in very rare occasions, what web apps do you use regularly? Gmail? Jira? Slack? LinkedIn? Figma? Notion? Docs? Dropbox? Airbnb? Netflix? Airtable? ... How many of these use javascript to do the heavy lifting on the client?
  • threeys 5y ago
  • porker 5y ago
    In your experience how often did the complex state have to be modelled on the backend as well as the frontend, to provide validation of submitted data? And for personal interest, how did you handle streaming in updates and edits from multiple people, and stopping people from editing eg the same real estate listing at the same time? I know it can be done but I find it easier with server round trips for every request.
    • fulafel 5y ago
      These are good concerns. IME it's important to be able to share code and schemas & domain data manipulation code between BE and FE like you can do eg with Clojure + ClojureScript.
    • nfw2 5y ago
      State is a pretty loaded word, but what I meant more specifically is complex application state, and by that I mean the ephemeral state that manages a user's usage of the application. For example, in the real estate use case, there may be, all on the same page: - a table of listings and grid of listings that can be toggled between - a map that can be displayed alongside the table with all the listings plotted - dynamic updates on the map that highlight listing when it is hovered on the table - a detail modal that displays whenever any listing on the table or map is clicked - pagination that can controlled from either the modal or the table - selection state for each row on the table and a bulk action bar that conditionally appears when the row is selected. - filters and search that need to work quickly and not disrupt the user experience None of these things are particularly unusual or groundbreaking, but trying to control all these stuff via server-rendering or jquery would be a huge mess and potentially a jarring UX.
• canyonero 5y ago
  It's seeming pretty fashionable these days to bash SPAs. I disagree that SPAs were mistake (or that it's often a mistake to reach for a SPA, even today) SPAs are now and have been a great tool to leverage when you want to build an application without needing to think about servers. Yes, there are tradeoffs. Yes, you should think about the thing you're building for. Yes, you should think about the skills of the developers working on it. That doesn't change the fact that SPAs can be great choice and not something to be perceived as a mistake.
• ehnto 5y ago
  I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic data features of SPAs. A think a lot of backend frameworks offer some attempts at frontend composability on the serverside but it's usually not the same approach that SPA tooling uses. I would love to get people's thoughts on backend tooling that is attempting to solve composability in a serious way, not just tacked onto an existing MVC framework.
  • int_19h 5y ago
    But components in web apps aren't really new. That's what ASP.NET and JSF was all about, waaaay back when.
    • fireant 5y ago
      Having worked with ASP.NET and other templating engines way back when and now working with React, I can say that there is a world of difference between the ease of composability of ASP.NET templates and React components. People really want composability and sometimes they need a tiny bit more interactivity than their server rendered stack offers without hacks (even if it's just more interactive forms)
  • porker 5y ago
    This. I'm keeping an eye on the newer server side renderings like Remix because most of the time what I want is to be able to write components and have them render to HTML, with a few remaining interactive. If Web components had got this right we the developers could have been happy and using composable components a decade ago.
    • ehnto 5y ago
      I agree, I'm am pretty disappointed by how web components turned out. I still use them actually, on personal projects. But that developer experience is absolutely not where it needed to be, then the cool kids showed up and stole their lunch.
• szastamasta 5y ago
  What a total nonsense. I’m quite old in our industry standards and remember all this ”great and easy” way of working with backend templates and struggle to find it much easier than working with SPAs. I also thank computer gods for SPAs each time I click in Github and wait for it junky slow interface to reload whole page. Please save us from likes of ROR etc. that is slow and has awful user experience. Just try to use Basecamp. It’s so ugly, slow and free of any features at all that your eyes will bleed. I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps. Web is not for documents any more. Just get over it.
  • nfw2 5y ago
    "I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps." Have you tried using React Native For Web? The name is so ironic it almost seems like a joke, but I think the rationale is to simplify things as you are suggesting
    • szastamasta 5y ago
      Yeah it’s a nice idea, but it still has to mess with DOM and css in the end. I just think that web apps are not web pages. And all this struggle with css quirks and all this power wasted on parsing DOM is not really needed. I know that if what you need is a blog, then html with css is enough. But building interactive apps with backend templates rendering ends up like Github (slow and with bad user experience), or it requires a lot of crazy jQuery hackery we have been doing in the old days. And I’ll pick building a React app any time I have a choice like that.
• thomas-guettler 5y ago
  htmx.org the one and only frontend revolution
• cjohnson318 5y ago
  If our whole industry is wrong about SPAs, and a whole generation is wrong about SPAs, what is the best practice then? Does anyone have a comprehensive resource on the right way to do things?
• winrid 5y ago
  The worst is when you have to use a piece of tracking or support software in your product and it pulls in a whole SPA with its own react/angular/whatever even when nothing is shown...
• numlock86 5y ago
  SPAs are great, not a mistake. If you use the wrong tool for the job you can make look anything like a mistake. Sure, your two-page hobbyist blog won't benefit from being an SPA, having a well-partitioned Cassandra cluster holding your three-paragraph posts nor having a serverless autoscaling architecture, but that's how people like to build it.