7 ms·

Why does everyone suddenly hate Single Page Apps?

35 points by swyx 4y ago

nfRfqX5n 4y ago
It’s quite nice working on an SPA again after a few years working on a SSR site. Auth is simple, no sync issues between the client and the server, and never have to worry about caching
shados 4y ago
As many folks mentioned already, the hate isn't new. Teams keep trying to use a one size fit all. Using SPAs for traditional websites was never a good idea, but people kept trying. SPAs tend to be pretty cheap and easy to build, especially if you cut corners, which makes them good to get an MVP out of the door quick (even if it's gonna suck). When trying to build "app like" products and given enough effort, they worked well and people made tons of money from them. Now though, there's a couple of entities who benefit a lot ($$$) by telling people "Actually, this SPA thing sucks, look at OUR solution that will solve all your problems!". And they're VERY vocal about it (much more vocal than people who actually dislike SPAs). A lot of trend setting in the tech industry is just from people ruffling feather or sowing confusion on purpose to then sell a solution. Right now we have a FEW of those, a bunch of people making money out of training you to solve the problem you didn't know you had, as well as a couple of Youtube "influencers" making money from the confusion.
nesbtesh2 4y ago
I have been building SPA with SSR for years, if you truly know what you are doing they work very well. Yes there are some downsides to SPA's but the amount of friction is removed due to the speed of the app it does amazing things for business. We increases conversion rate and sales like crazy because of the experience of the website. It is true I had do some extra work to make it so fast, but dam the growth we had with the SPA was amazing. Know keep in mind that in our case it made sense because our users are buying 3000+ products in one session
- nesbtesh2 4y ago
  Check it out yourself www.noritex.com
  - twelve40 4y ago
    your website is _fast_, i'm impressed. The problem is, it's a very rare exception. Most SPA's I interact with daily (like banks - BofA, Citi, Chase, etc) are a complete and absolute disaster, anyone who touched that code must be fired for incompetence and banished from profession forever (e.g., Citi has 30,000 developers+all the money in the world, yet their backward-ass, forever-spinning, busted SPA gets a 7/100 in lighthouse)
andrewfromx 4y ago
Here here! Let me click around a site again with real a href links that change the browser url and are copy passable!
- rhaway84773 4y ago
  Proper SPA frameworks have been able to do this extremely well for nearly a decade now, without any effort from the developer.
  - dolni 4y ago
    So you now need a framework to accomplish something browsers have been able to do natively for multiple decades. And we're calling that progress.
    - pram 4y ago
      window.history is from the HTML 5 spec from 2011. It’s as native as anything else.
      - acdha 4y ago
        The API is mature but usage is not. I still see cases where companies screwed up state management on at least weekly basis so clearly the SPA-building community is still lagging behind where the server-side world was three decades ago.
    - berkle4455 4y ago
      Just wait til you learn about SSR
      - rektide 4y ago
        For real. The solution to bad url routing in SPAs is distributing our work across a madcap wild ass front-end/back-end split with ill defined borders & no protocols? What's happening now is 500% more complicated. But the magic is well packaged & available by default. The SSR world has frameworks: but as another commenter pointed out, React stopped at being merely a library. And so it's been anarchy, deciding how to SPA, with many folks not realizing how many needs/libraries they really needed to have. I'm hugely in favor of SPAs, but there's been a lack of well-integrated sensible approaches. The attempt to identify & only solve a narrow window of concerns has hurt our ability to imagine what apps are, left huge voids all over.
PaulHoule 4y ago
SPAs certainly were not a "zero interest rate phenomenon". It was early in the 2010s that I saw all the web design shops who made Ruby on Rails sites in my small town suddenly start building all their apps in Angular and struggling. I'd ask them why they were doing this and it wasn't masochism, rather they believed that small town web clients demanded SPAs and that they couldn't sell user-friendly RoR apps that were affordable to develop.
- shados 4y ago
  I built my first SPA for a company I worked for in 2006! It was funny trying to explain to the lead engineer that it was possible to build a web app without page refresh. He didn't believe me at first. And that was already a while after Outlook Web access, and even later than people using hidden iframes to simulate XHR before XHR existed. They might not have been common, but they're old by now.
- BackBlast 4y ago
  Zero interest rate phenomenon is building native everywhere. iOS, Android, Windows, MacOS, Linux, web. Got money to burn? Build it 4, 5, or 6 times! Then keep it up to date! Even if you're a rocking engineering org, that's an ouch. Web apps/spa/pwa can be a great value choice if you need to hit a lot of platforms on a budget. Angular definitely started out as kind of a dog. Some modern frameworks I'd put up there with ruby, maybe better. Don't chase the hype. Lots of great tooling out there. Prove something out before you run with it. It's not THAT hard.
rhaway84773 4y ago
The real answer to why everyone hates SPAs now is that there are well funded companies providing frameworks that are touting their SSR capabilities as a massive advantage, seeding the internet with content about how SPAs are the worst. Something similar happened about a decade ago when everyone started loving SPAs. SPAs didn’t become popular because of cell phones. In fact, outside of Facebook for a short period of time, there has been a strong consensus over the entire “everything must be a SPA” period that mobile apps should be native. Facebook, once it realized its mistake, tried to fit its massive “build once run anywhere” peg into a tiny “native for mobile, HTML5 for the web” hole through React Native, not SPAs. SPAs have their place. Although I’m not a huge fan (though less of a hater now, thanks to the fact that at least the JS world has largely agreed that typing is good), I have a highly successful SPA that’s been used with almost no maintenance besides basic security upgrades for nearly 7 years now. The reason is that we used a proper framework that fully supports building a SPA, EmberJS, but it could have been anything other than trying to cobble together a variety of react-* libraries thst only barely work together, and that our application actually was a heavily interactive user driven application with most of the stuff happening on the same page. There are only a few minor other pages (such as settings), so the application itself is largely a single page application, which is why a SPA fits it so well.
- rhaway84773 4y ago
  I’m increasingly convinced that so much of the trend following we’re seeing in the front end development world today is a result of the fact that ReactJS absolutely burst through the scene when it realized because it had some game changing ideas, but never had the courage to become a framework. Instead, it insisted on being a thin UI layer forcing others to fill the gaps, which have led to all sorts of startups/open source projects popping up trying to convince others that theirs is the one true way. So instead of being a sober discussion around the pros and cons of using certain technologies in certain scenarios, it’s being recast to resemble the fashion industry where everyone is insisting that their trend is the next big thing.
  - swatcoder 4y ago
    > So instead of being a sober discussion around the pros and cons of using certain technologies in certain scenarios, it’s being recast to resemble the fashion industry where everyone is insisting that their trend is the next big thing. If they were still easily accessible, you could go back and read identical drama play out on 50 year old usenet newsgroups and mailing lists. Our industry is built on the genius of many clever tinkers who could get any tool to meet any task, and plenty enough stubborn contrarians and manic hype-builders ready to argue to their death (or until the next fashion comes through) that the one true light has finally been glimpsed. Meanwhile, countless quiet and productive teams privately figured out how to use a tool well and just stuck with it for as long as it still made sense, not letting themselves getting so wrapped up in the public hullabaloo -- just like you did with your EmberJS project. The fashion debates reflect that a lot of work is actually art, while those many quiet, healthy projects reflect the engineering processes that see us get paid better than most other artists.
smackeyacky 4y ago
I got to hate them when angularjs became the new version, which was nigh on impossible to upgrade from the original. They should have given it a different name. Angularjs burned me so hard that i didn't even bother to look at react.
ihatepython 4y ago
I don't understand the premise, because I have always hated Single Page Apps.
- berkle4455 4y ago
  There’s one good SPA: gmail. Everything else has been a dumb idea.
  - jakelazaroff 4y ago
    My side project is a web-based music video creator. It literally could not exist except as a SPA.
    - meatmanek 4y ago
      IMO: - SPAs make sense for "applications". Google docs, Gmail, Trello, Slack, web-based music video creators, etc. Things that need high levels of interactivity. - SPAs don't make sense for "websites". Blogs, forums, search engines, news sites, etc. Of course, many things exist somewhere on the continuum between "website" and "application", and then the tradeoffs get messier. Gmail arguably doesn't need a high level of interactivity - that's why they also have the basic HTML version.
  - 65 4y ago
    Anything that requires some kind of SEO is a dumb idea for a SPA. If you're making Jira or something, a SPA makes sense. The issue is, the bovine tech herd sees new thing and applies new thing to everything. Everything is React now. Now we have news websites as SPAs, the worst possible use case for a SPA.
- cirrus3 4y ago
  Yep. They cause more problems than they solve. No one likes making or using SPAs.
steponlego 4y ago
I'm not what we call in the Unix greybeard community a "webshitter" so I have no idea what this even is. What's an SPA?
- deleted 4y ago
  [deleted]
- ec109685 4y ago
  Single Page App. A dumb idea when all you need is web page.
- ec109685 4y ago
  Single Page Web App. A dumb idea when all you need is web page.
Lazare 4y ago
Feels fairly simple. A decent chunk of people always disliked SPAs, due to their very obvious disadvantages. Another chunk of people always liked them, either due to novelty or to their, again, fairly obvious advantages. Depending on who you talk to or what online forums you frequent, you may have had an impression that the first group was far smaller (or larger) than the last group. Due to changes in the media you consume, or changes to the culture of various online forums, it may seem to you like the first group is now larger (or smaller!) than the second instead. On the margin I suppose a few people who liked SPAs due to the novelty may have got bored with them, but most people, I think, have had pretty static views about SPAs, because the pros and cons are pretty obvious. Yeah, okay, some prominent engineer tweeted something bad about SPAs last month and it went semi-viral, but prominent engineers have been tweeting and writing bad things about SPAs for the entire existence of SPAs. And more than a few of those have gone pretty viral. Better question might be "How come I saw this tweet on my feed, but didn't notice all the earlier ones?", but I don't think that's super interesting.
- basch 4y ago
  It also depends what the page is. Google Maps was a justified SPA. But when I am looking at a normalish looking web page and can’t open hyperlinks in new tabs cuz they aren’t actually hyperlinks, or the back button doesn’t back, you’ve broken fundamental navigation. Back and forth shouldn’t refresh lists and reset scroll. Too often SPAs completely reinvent browser navigation within themselves. And I know the argument is that it is indistinguishable, but from a performance standpoint, you’re now running a second copy of browser functions in ram/cpu for every tab open.
quickthrower2 4y ago
To publish on social media or a blog, you need an angle/story, that will establish you as the expert. To build, you just build. The latter makes less noise online.
TexanFeller 4y ago
It's not sudden, I've hated them since they've existed with only a handful of exceptions such as gmail. Most things on the web would be better without them.
jbverschoor 4y ago
1) They are more fragile / have more bugs and don't get tested properly, because it is more work for most "applications" 2) They're slow to start 3) They usually lack a good UX (deeplinks, hijacking links, etc)
roncesvalles 4y ago
No one needs SSRs. - The SEO argument is long dead. - Client devices are sufficiently performant for anything you throw at it. Yes, even the $100 Chinese Android smartphones that taxi drivers in India use. - The last argument I've heard is "I don't want to expose a JSON API to the world", but that's false security because scraping a web page is not difficult.
- ec109685 4y ago
  It’s slow. Why make a user make multiple round trips to fetch the page’s data versus serving it online? Spinners stink.
  - cyral 4y ago
    Any decent SPA is serving the content in the initial request and not showing a spinner after it downloads the JS
  - roncesvalles 4y ago
    That's just because the REST API that serves the requests was poorly implemented. Most SPAs on the web don't even bother including spinners.
- ovao 4y ago
  > Client devices are sufficiently performant for anything you throw at it Possibly true of the devices themselves (although dubious generally), but definitely not true of wireless networks. If you can deliver a rendered page in 10 KB versus a 1 KB doc and 120 KB of framework to render that same page, you win. That’s true regardless of whether it’s a 3G connection or 5G. SPAs can hold a small advantage in the aggregate, so if you expect your users to be bouncing around routes quite often within a session, you might amortize the cost of the view framework and bundles, but that’s probably not the typical case on mobile, particularly in developing regions.
  - roncesvalles 4y ago
    120 KB is largely overblown. Especially with gzip, it reduces even further. There aren't many countries left where the time to load 1 KB vs 120 KB on mobile or broadband Internet would be noticeable.
jiggawatts 4y ago
Because like all fads with narrow applicability, idiots in big enterprise assume that All New Things Must Become the Only Way. At $dayjob I regularly see "SPAs + microservices" getting deployed for static content that could have been literally just HTML, CSS, and JPG files. I've seen a design recently for a trivial app that had two Kubernetes clusters in the architecture diagram. Two! Not to mention that virtually all SPAs are infected by Node and NPM, directly or indirectly. JavaScript package management seemed "so easy" at first, and has slowly but inevitably morphed in a nightmare. Minutes of CPU time was insufficient to disentangle the dependency graph of one particular Angular app in the effort to upgrade its packages. If hundreds of billions of machine instructions aren't up to the task, a squishy meat brain definitely isn't either. Maybe SPAs are a great idea if they are your only product and are truly used to develop web applications that are constantly maintained. For corporate web sites they're idiotic beyond belief.
iio7 4y ago
There is no sudden about it, SPA's are yet another one of the so-called "modern web" cancers of the Internet. They go completely against the protocols and architecture they run on and the only reason why they became so popular to begin with is because of all the hype from the big business, like so much else. A web application or a website, by its very nature, is a series of small requests. When someone sends all requests in one big lump of a page, they have just defeated this very important architecture. Not to talk about the fact that they break searching on pages and a whole lot of other things.
- roncesvalles 4y ago
  I think you misunderstand what an SPA is. It also sends a series of requests as you navigate the website. It doesn't break search because everything is rendered to HTML.
  - doodlesdev 4y ago
    It does break search. A traditional SPA returns to the client an empty HTML page (except for header stuff) and a script to parse. The script then populates the DOM with the elements, problem is that crawlers are not really good at waiting for the "render" to happen, and running JavaScript just to see what's in the page opens a whole other can of worms. SPAs are awful for search engines and that's why we get the hybrid monsters that Next.JS, Nuxt, SvelteKit and co. produces nowadays (not saying they are bad from a user perspective though, much prefer web apps made with them over client-side rendered SPAs). We spent the last decade trying to fix the whole mess that client-side "rendering" created in the web, we'll probably spent the next decade trying (and failing) to standardize things such as web components, declarative shadow DOM, among other things. That's because we as developers keep insisting in complexity: hydration, SPAs, bundlers (and in consequence bundle bundlers such as Vite). The only true solution is to bet in simplicity, but that's not sexy, and sex sells. In conclusion: The React revolution and it's consequences have been a disaster for the human race.
    - roncesvalles 4y ago
      The SEO argument is a strawman. Large swaths of the Internet return a blank page if you try to access them with JS turned off. Are you saying search engine crawlers haven't figured out how to deal with that? There is nothing inherent in SPAs that make load time slower. If your REST API takes 5 seconds to serve up JSON, what's to say your SSR rendered page won't also take 5 seconds?
DoesntMatter22 4y ago
I've built so many spa's in virtually every popular framework. I'm over it. Even the simplest SPAs end up being way more effort than they are worth IMO. I'd write thin API layers and it seemed great. Recently though. I moved to all backend with some jQuery. I render all the views on the backend and if they need to be swapped out I make a simple ajax call to pull the rerendered days and swap the div. It's like 2 lines of code for me. Everything is so much faster, primarily because JS has so many gotchas. And so many times where you wonder "wait why isn't the data right here? Shouldn't this have blown up". There is no appreciable difference to the user here but I can work in a backend lang and sparingly use JS and it's a pleasure.
- 88913527 4y ago
  jQuery codebases are great at 2 LOC and complete nightmares at 2M LOC.
  - DoesntMatter22 4y ago
    Any codebase is a nightmare at 2 million lines don't kid yourself
- sebazzz 4y ago
  > Recently though. I moved to all backend with some jQuery. I render all the views on the backend and if they need to be swapped out I make a simple ajax call to pull the rerendered days and swap the div. It's like 2 lines of code for me. Sounds like one of those bad SPA in the making. You know, without browser navigation, without an url that can be revisited.
brap 4y ago
Whenever this “SSR vs SPA” question comes up, I feel like it’s the wrong question to ask, because neither is ideal. Server rendered or static sites make sense in some specific use cases (e.g docs, blogs), but even for those classic use cases they’re not ideal (e.g full page reloads every time). On the other hand, SPAs make sense in some specific use cases (e.g Gmail) but even for those classic use cases they’re not ideal (e.g first render takes time). I think we always need both server and client rendering, regardless of the use case, and the question we need to ask is how can we achieve this in an ergonomic way. There’s some progress being made there (e.g Next.js) but I feel like it’s not quite there yet.
- cyral 4y ago
  The hybrid approach really is the best of both worlds, and it makes perfect sense to do the heavy lifting on the server initially and then turn over everything to the client rather than doing the heavy lifting again for every single subsequent request. Every time this comes up though there is the snarky "lol SSR isn't new, are JS devs just learning about it???" type response here.
cyral 4y ago
Imagine if this was reversed and mobile apps suddenly started switching to SSR. Instead of downloading the app once and making lightweight JSON requests (analogous to what SPAs are doing), they froze for seconds while the next page is rendered on the server while losing all of the local state that you had typed in. Sure would be a lot of hate for that when they have been working fine for a decade. You'd probably argue, that it sounds like that is just a bad implementation of SSR. Not all SSR is like that surely? This is how silly this weekly SPA vs SSR debate is.
- BackBlast 4y ago
  Some mobile apps are like this. Even some desktop apps, won't move forward without it's connection to the mothership. Yes, it's frustrating. I like offline capable systems. The money isn't there for offline ability on most websites. So... I can appreciate it from a distance.
wkat4242 4y ago
I hate everything that's mobile-first. And I prefer simple sites not bogged down by tons of JavaScript. Which is not so surprising considering this is my favorite website. In fact it's not so surprising to find a general desktop-centric view here at all, in my opinion.
Glench 4y ago
Svelte creator Rich Harris gave a great middle-of-the-road talk about single page apps with examples a year ago: https://www.youtube.com/watch?v=860d8usGC0o https://www.youtube.com/watch?v=860d8usGC0o Then he released SvelteKit which has the best of both worlds: https://kit.svelte.dev/ https://kit.svelte.dev/
steve_taylor 4y ago
I’ve noticed that a lot of developers tend to hate things that they’ve tried building but they found it too hard. People enjoy doing things they’re good at and hate doing things they suck at. There are a lot of SPAs that shouldn’t be SPAs, but that doensn’t mean all SPAs are bad. This isn’t your grandpa’s web browser anymore. We’ve moved on from the web being all about hyperlinked documents. The browser is also an app runtime, just like your smart phone. If server-side rendering was the only good way to build web apps, then it stands to reason thay it’s the only good way to build phone apps with equivalent functionality. Maybe phone apps should also start re-rendering the entire UI on the server every time the user taps something.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
recursivedoubts 4y ago
The arc of web development is long, but it bends towards grug brain: https://grugbrain.dev/#grug-on-front-end-development https://grugbrain.dev/#grug-on-front-end-development
userbinator 4y ago
I've always hated them but it's good to see the tide turning. Slow (one of the first signs of an SPA - a page with its own custom loading indicator), requires JS to do things that otherwise needn't, and things like links don't work right. I do wonder if the otherwise superfluous --- and constantly changing --- JS requirement is part of the "weaponised change" approach of Google to furthering its control over the browser, since it's relatively trivial to create a browser that's usable on sites that need nothing more than HTML forms, but substantially more difficult to create one which will work with the simplest of SPAs.
cirrus3 4y ago
"Suddenly"? I don't know any users who liked them ever, and that has been a long time now. Designers and clients seemed to like them. Not users or developers.
rbd765 4y ago
The ecosystem of web standards, browsers and search engines is mostly optimized with MPAs in mind. That's the base experience for web. Things have only gotten more complicated as we've built abstractions on top of MPAs. In the earlier iterations, SPAs broke navigation, broke SEO, had no decent state management solution, and required a good understanding of reflow/repaint to avoid performance issues. The ergonomics of SPA frameworks has improved drastically and metaframeworks like Next.js have mostly fixed those issues. But the myriad of options and paradigms might be exhausting for some devs. Some experienced devs might be nostalgic for the document-centric PHP days. I imagine that many newer devs have only recently been exposed to the pleasure of building a simple MPA website, as they were initially thrust straight into React. For example, I recently chose to use Hugo for my blog. Just wanted something dead simple to build a static website without all the bells and whistles of a SPA.
xboxnolifes 4y ago
I like SPAs when they're actually used for applications. I hate SPAs when they're used for crippled website functionality and slower load times than a normal server round trip.
BackBlast 4y ago
Love me a well built SPAs. Great tech. I certainly don't mind if others don't build them. So many people trying to advocate the "one true way" of tech instead of acknowledging that it really depends on the use case as which tools end up being superior.
tauseefferaz 4y ago
Q: why it matters? A: 90% SaaS product features you see is half baked, SPA's are the cure to the mess. Solving core problems requires rebirth of application but when ARR is big you can't go and rebase the code. Either you're born with it or your product will rebirth. (SAP's has it's own cons but the pros weighs more)
rektide 4y ago
The web has a huge anti- crowd all around it. People detest that there's this terrible awful wretched browser pretending like it can do code. Which is 98% gatekeeping sad-pants whiner-shit. There's problems, but the amplification problem is uber for real, and most of the complaints just don't frigging matter; this is 98% a Bullshit Asymmetry problem: it takes vastly more energy to care about & refute troll-ish petty behavior than it takes to generate it. Positive behavior rarely gets amplified. There's an outsized representation for anger/negativity, as there almost always is, everywhere, forever. Personally I think it's absurd to favor servers. AKA mainframes. Thick client web systems have a fundamental embrace of user-agency, in a way that thin-client systems are utterly unable to negotiate. It's cheap and easy to take digs on how bad things have been, and 100%, there's been a pretty poor developmental track record & much could & should be better in the client side universe. But it's still 100% better a RFC 8890 paradigm - The Internet Is For Users - than literally all the rest of computing, which has nothing for users & offers them diddly squat in terms of agency. Alex's critique / pouring gas on the fire is wrong for a simple reason: we've been asleep at the wheel & embraced little change. URL routing, incremental loading, offline capability, & a host of interesting sprawling new web capabilities that could improve everything are still drastically unadopted. We have a lot of libraries for orthogonal concerns, but there have been essentially zero successful efforts in the last decade to define a system even as comprehensively cross-cutting as literally the first successful JavaScript framework was, Backbone. We have reduced scope since, and left orgs to cobble together orthogonal libraries, which has strengths, but makes it harder to adopt & leverage the high minded better potentials of what could happen. The web just hasn't evolved or advanced significantly, in spite of some churning iteration for how we all React. SPAs are wonderful, but we've crashed against the limits of what we are willing to explore, and there's been a lack of way forward projected, and the upsurge in anti-SPA SSR is basically just an off-gassing, a pent up pressure to do anything other than what we've been up to, and while it has some virtue, I still ascribe most of it's interest to the fact that client-side systems have been at a standstill & real coherence & sensible integrative holistic imagining of how we might better do SPA's has been obviously absent for a while now. GraphQL was some attempt to respin the front-end world but I think by now we know it's not really actually much different or better, but there's ideas captured there, where front-ends are not as hand-craft artisinally-made that we still are far from, and there's countless capabilities we should be tapping - like good Service Worker patterns, much more webworker and distributed computing ideas - that have made essentially no progress. At some point we need to upgrade & enhance what we expect of SPAs, but while the tooling has changed somewhat (React moving from classes, to HoC, to hooks, Redux to whatever), there's been little actual embrasure of real change, real web capabilities, that have been all about. SPAs are still one of the greatest best option out there, even though their means-of-production are essentially unchanged for a decade & the hipsters are desperately hungry for cooler/bettter. Even though we've hit this kind of so so local maxima, there's just nothing anywhere as effective, and the whole SSR pitch may fit some roles, but for like 98% of systems, a SPA has a ton of advantages in being a more unified isolated independent thick client that just networks back to a bunch of dumb resources, which is a better/simpler & less overhead model - albeit one with some more loading cost - than the radically weirder & more complex models of splicing apart the baby & having part of the work happen one place & part of the work happen elsewhere. And none of that is good for the user anyways. I look forward to a new novel exciting future, but this is not the RFC 8890 way forwards. SPAs are kind of stuck, but still the best version of the web we have. https://www.rfc-editor.org/rfc/rfc8890 https://www.rfc-editor.org/rfc/rfc8890
curtisblaine 4y ago
Because you normally need to use a framework + the front-end ecosystem and it's hard (as in: not something you can improvise, you need to be good at it and have years of experience in it). Many developers on the back-end think that the website should be a thin veneer over a service. When they find out they can't just hack on it, but they need to learn React/npm/react-router/table virtualization/some component framework they get irritated because they've always seen front-end as a "lower" discipline for "worse" developers. That said, a well-written SPA is able to express a class of web-based applications that, if written well, are indistinguishable from normal web pages (with anchors etc) but can do much more things than a traditional server generated web page. Since native apps are essentially living in paid, closed, walled gardens, long live SPAs.
0xbadc0de5 4y ago
Why does everyone like skinny jeans and not bell bottoms? Light mode or dark mode? Fashion trends change. Cynically, there's also a measure of job security in chasing trends. Gotta keep up with the latest whizbang framework.

35 points by swyx 4y ago

It’s quite nice working on an SPA again after a few years working on a SSR site. Auth is simple, no sync issues between the client and the server, and never have to worry about caching

shados 4y ago

As many folks mentioned already, the hate isn't new. Teams keep trying to use a one size fit all. Using SPAs for traditional websites was never a good idea, but people kept trying. SPAs tend to be pretty cheap and easy to build, especially if you cut corners, which makes them good to get an MVP out of the door quick (even if it's gonna suck). When trying to build "app like" products and given enough effort, they worked well and people made tons of money from them. Now though, there's a couple of entities who benefit a lot ($$$) by telling people "Actually, this SPA thing sucks, look at OUR solution that will solve all your problems!". And they're VERY vocal about it (much more vocal than people who actually dislike SPAs). A lot of trend setting in the tech industry is just from people ruffling feather or sowing confusion on purpose to then sell a solution. Right now we have a FEW of those, a bunch of people making money out of training you to solve the problem you didn't know you had, as well as a couple of Youtube "influencers" making money from the confusion.

nesbtesh2 4y ago

I have been building SPA with SSR for years, if you truly know what you are doing they work very well. Yes there are some downsides to SPA's but the amount of friction is removed due to the speed of the app it does amazing things for business. We increases conversion rate and sales like crazy because of the experience of the website. It is true I had do some extra work to make it so fast, but dam the growth we had with the SPA was amazing. Know keep in mind that in our case it made sense because our users are buying 3000+ products in one session

nesbtesh2 4y ago
Check it out yourself www.noritex.com
- twelve40 4y ago
  your website is _fast_, i'm impressed. The problem is, it's a very rare exception. Most SPA's I interact with daily (like banks - BofA, Citi, Chase, etc) are a complete and absolute disaster, anyone who touched that code must be fired for incompetence and banished from profession forever (e.g., Citi has 30,000 developers+all the money in the world, yet their backward-ass, forever-spinning, busted SPA gets a 7/100 in lighthouse)

andrewfromx 4y ago

Here here! Let me click around a site again with real a href links that change the browser url and are copy passable!

rhaway84773 4y ago
Proper SPA frameworks have been able to do this extremely well for nearly a decade now, without any effort from the developer.
- dolni 4y ago
  So you now need a framework to accomplish something browsers have been able to do natively for multiple decades. And we're calling that progress.
  - pram 4y ago
    window.history is from the HTML 5 spec from 2011. It’s as native as anything else.
    - acdha 4y ago
      The API is mature but usage is not. I still see cases where companies screwed up state management on at least weekly basis so clearly the SPA-building community is still lagging behind where the server-side world was three decades ago.
  - berkle4455 4y ago
    Just wait til you learn about SSR
    - rektide 4y ago
      For real. The solution to bad url routing in SPAs is distributing our work across a madcap wild ass front-end/back-end split with ill defined borders & no protocols? What's happening now is 500% more complicated. But the magic is well packaged & available by default. The SSR world has frameworks: but as another commenter pointed out, React stopped at being merely a library. And so it's been anarchy, deciding how to SPA, with many folks not realizing how many needs/libraries they really needed to have. I'm hugely in favor of SPAs, but there's been a lack of well-integrated sensible approaches. The attempt to identify & only solve a narrow window of concerns has hurt our ability to imagine what apps are, left huge voids all over.

PaulHoule 4y ago

SPAs certainly were not a "zero interest rate phenomenon". It was early in the 2010s that I saw all the web design shops who made Ruby on Rails sites in my small town suddenly start building all their apps in Angular and struggling. I'd ask them why they were doing this and it wasn't masochism, rather they believed that small town web clients demanded SPAs and that they couldn't sell user-friendly RoR apps that were affordable to develop.

shados 4y ago
I built my first SPA for a company I worked for in 2006! It was funny trying to explain to the lead engineer that it was possible to build a web app without page refresh. He didn't believe me at first. And that was already a while after Outlook Web access, and even later than people using hidden iframes to simulate XHR before XHR existed. They might not have been common, but they're old by now.
BackBlast 4y ago
Zero interest rate phenomenon is building native everywhere. iOS, Android, Windows, MacOS, Linux, web. Got money to burn? Build it 4, 5, or 6 times! Then keep it up to date! Even if you're a rocking engineering org, that's an ouch. Web apps/spa/pwa can be a great value choice if you need to hit a lot of platforms on a budget. Angular definitely started out as kind of a dog. Some modern frameworks I'd put up there with ruby, maybe better. Don't chase the hype. Lots of great tooling out there. Prove something out before you run with it. It's not THAT hard.

rhaway84773 4y ago

The real answer to why everyone hates SPAs now is that there are well funded companies providing frameworks that are touting their SSR capabilities as a massive advantage, seeding the internet with content about how SPAs are the worst. Something similar happened about a decade ago when everyone started loving SPAs. SPAs didn’t become popular because of cell phones. In fact, outside of Facebook for a short period of time, there has been a strong consensus over the entire “everything must be a SPA” period that mobile apps should be native. Facebook, once it realized its mistake, tried to fit its massive “build once run anywhere” peg into a tiny “native for mobile, HTML5 for the web” hole through React Native, not SPAs. SPAs have their place. Although I’m not a huge fan (though less of a hater now, thanks to the fact that at least the JS world has largely agreed that typing is good), I have a highly successful SPA that’s been used with almost no maintenance besides basic security upgrades for nearly 7 years now. The reason is that we used a proper framework that fully supports building a SPA, EmberJS, but it could have been anything other than trying to cobble together a variety of react-* libraries thst only barely work together, and that our application actually was a heavily interactive user driven application with most of the stuff happening on the same page. There are only a few minor other pages (such as settings), so the application itself is largely a single page application, which is why a SPA fits it so well.

rhaway84773 4y ago
I’m increasingly convinced that so much of the trend following we’re seeing in the front end development world today is a result of the fact that ReactJS absolutely burst through the scene when it realized because it had some game changing ideas, but never had the courage to become a framework. Instead, it insisted on being a thin UI layer forcing others to fill the gaps, which have led to all sorts of startups/open source projects popping up trying to convince others that theirs is the one true way. So instead of being a sober discussion around the pros and cons of using certain technologies in certain scenarios, it’s being recast to resemble the fashion industry where everyone is insisting that their trend is the next big thing.
- swatcoder 4y ago
  > So instead of being a sober discussion around the pros and cons of using certain technologies in certain scenarios, it’s being recast to resemble the fashion industry where everyone is insisting that their trend is the next big thing. If they were still easily accessible, you could go back and read identical drama play out on 50 year old usenet newsgroups and mailing lists. Our industry is built on the genius of many clever tinkers who could get any tool to meet any task, and plenty enough stubborn contrarians and manic hype-builders ready to argue to their death (or until the next fashion comes through) that the one true light has finally been glimpsed. Meanwhile, countless quiet and productive teams privately figured out how to use a tool well and just stuck with it for as long as it still made sense, not letting themselves getting so wrapped up in the public hullabaloo -- just like you did with your EmberJS project. The fashion debates reflect that a lot of work is actually art, while those many quiet, healthy projects reflect the engineering processes that see us get paid better than most other artists.

smackeyacky 4y ago

I got to hate them when angularjs became the new version, which was nigh on impossible to upgrade from the original. They should have given it a different name. Angularjs burned me so hard that i didn't even bother to look at react.

ihatepython 4y ago

I don't understand the premise, because I have always hated Single Page Apps.

berkle4455 4y ago
There’s one good SPA: gmail. Everything else has been a dumb idea.
- jakelazaroff 4y ago
  My side project is a web-based music video creator. It literally could not exist except as a SPA.
  - meatmanek 4y ago
    IMO: - SPAs make sense for "applications". Google docs, Gmail, Trello, Slack, web-based music video creators, etc. Things that need high levels of interactivity. - SPAs don't make sense for "websites". Blogs, forums, search engines, news sites, etc. Of course, many things exist somewhere on the continuum between "website" and "application", and then the tradeoffs get messier. Gmail arguably doesn't need a high level of interactivity - that's why they also have the basic HTML version.
- 65 4y ago
  Anything that requires some kind of SEO is a dumb idea for a SPA. If you're making Jira or something, a SPA makes sense. The issue is, the bovine tech herd sees new thing and applies new thing to everything. Everything is React now. Now we have news websites as SPAs, the worst possible use case for a SPA.
cirrus3 4y ago
Yep. They cause more problems than they solve. No one likes making or using SPAs.

steponlego 4y ago

I'm not what we call in the Unix greybeard community a "webshitter" so I have no idea what this even is. What's an SPA?

deleted 4y ago
[deleted]
ec109685 4y ago
Single Page App. A dumb idea when all you need is web page.
ec109685 4y ago
Single Page Web App. A dumb idea when all you need is web page.

Lazare 4y ago

Feels fairly simple. A decent chunk of people always disliked SPAs, due to their very obvious disadvantages. Another chunk of people always liked them, either due to novelty or to their, again, fairly obvious advantages. Depending on who you talk to or what online forums you frequent, you may have had an impression that the first group was far smaller (or larger) than the last group. Due to changes in the media you consume, or changes to the culture of various online forums, it may seem to you like the first group is now larger (or smaller!) than the second instead. On the margin I suppose a few people who liked SPAs due to the novelty may have got bored with them, but most people, I think, have had pretty static views about SPAs, because the pros and cons are pretty obvious. Yeah, okay, some prominent engineer tweeted something bad about SPAs last month and it went semi-viral, but prominent engineers have been tweeting and writing bad things about SPAs for the entire existence of SPAs. And more than a few of those have gone pretty viral. Better question might be "How come I saw this tweet on my feed, but didn't notice all the earlier ones?", but I don't think that's super interesting.

basch 4y ago
It also depends what the page is. Google Maps was a justified SPA. But when I am looking at a normalish looking web page and can’t open hyperlinks in new tabs cuz they aren’t actually hyperlinks, or the back button doesn’t back, you’ve broken fundamental navigation. Back and forth shouldn’t refresh lists and reset scroll. Too often SPAs completely reinvent browser navigation within themselves. And I know the argument is that it is indistinguishable, but from a performance standpoint, you’re now running a second copy of browser functions in ram/cpu for every tab open.

quickthrower2 4y ago

To publish on social media or a blog, you need an angle/story, that will establish you as the expert. To build, you just build. The latter makes less noise online.

TexanFeller 4y ago

It's not sudden, I've hated them since they've existed with only a handful of exceptions such as gmail. Most things on the web would be better without them.

jbverschoor 4y ago

1) They are more fragile / have more bugs and don't get tested properly, because it is more work for most "applications" 2) They're slow to start 3) They usually lack a good UX (deeplinks, hijacking links, etc)

roncesvalles 4y ago

No one needs SSRs. - The SEO argument is long dead. - Client devices are sufficiently performant for anything you throw at it. Yes, even the $100 Chinese Android smartphones that taxi drivers in India use. - The last argument I've heard is "I don't want to expose a JSON API to the world", but that's false security because scraping a web page is not difficult.

ec109685 4y ago
It’s slow. Why make a user make multiple round trips to fetch the page’s data versus serving it online? Spinners stink.
- cyral 4y ago
  Any decent SPA is serving the content in the initial request and not showing a spinner after it downloads the JS
- roncesvalles 4y ago
  That's just because the REST API that serves the requests was poorly implemented. Most SPAs on the web don't even bother including spinners.
ovao 4y ago
> Client devices are sufficiently performant for anything you throw at it Possibly true of the devices themselves (although dubious generally), but definitely not true of wireless networks. If you can deliver a rendered page in 10 KB versus a 1 KB doc and 120 KB of framework to render that same page, you win. That’s true regardless of whether it’s a 3G connection or 5G. SPAs can hold a small advantage in the aggregate, so if you expect your users to be bouncing around routes quite often within a session, you might amortize the cost of the view framework and bundles, but that’s probably not the typical case on mobile, particularly in developing regions.
- roncesvalles 4y ago
  120 KB is largely overblown. Especially with gzip, it reduces even further. There aren't many countries left where the time to load 1 KB vs 120 KB on mobile or broadband Internet would be noticeable.

jiggawatts 4y ago

Because like all fads with narrow applicability, idiots in big enterprise assume that All New Things Must Become the Only Way. At $dayjob I regularly see "SPAs + microservices" getting deployed for static content that could have been literally just HTML, CSS, and JPG files. I've seen a design recently for a trivial app that had two Kubernetes clusters in the architecture diagram. Two! Not to mention that virtually all SPAs are infected by Node and NPM, directly or indirectly. JavaScript package management seemed "so easy" at first, and has slowly but inevitably morphed in a nightmare. Minutes of CPU time was insufficient to disentangle the dependency graph of one particular Angular app in the effort to upgrade its packages. If hundreds of billions of machine instructions aren't up to the task, a squishy meat brain definitely isn't either. Maybe SPAs are a great idea if they are your only product and are truly used to develop web applications that are constantly maintained. For corporate web sites they're idiotic beyond belief.

iio7 4y ago

There is no sudden about it, SPA's are yet another one of the so-called "modern web" cancers of the Internet. They go completely against the protocols and architecture they run on and the only reason why they became so popular to begin with is because of all the hype from the big business, like so much else. A web application or a website, by its very nature, is a series of small requests. When someone sends all requests in one big lump of a page, they have just defeated this very important architecture. Not to talk about the fact that they break searching on pages and a whole lot of other things.

roncesvalles 4y ago
I think you misunderstand what an SPA is. It also sends a series of requests as you navigate the website. It doesn't break search because everything is rendered to HTML.
- doodlesdev 4y ago
  It does break search. A traditional SPA returns to the client an empty HTML page (except for header stuff) and a script to parse. The script then populates the DOM with the elements, problem is that crawlers are not really good at waiting for the "render" to happen, and running JavaScript just to see what's in the page opens a whole other can of worms. SPAs are awful for search engines and that's why we get the hybrid monsters that Next.JS, Nuxt, SvelteKit and co. produces nowadays (not saying they are bad from a user perspective though, much prefer web apps made with them over client-side rendered SPAs). We spent the last decade trying to fix the whole mess that client-side "rendering" created in the web, we'll probably spent the next decade trying (and failing) to standardize things such as web components, declarative shadow DOM, among other things. That's because we as developers keep insisting in complexity: hydration, SPAs, bundlers (and in consequence bundle bundlers such as Vite). The only true solution is to bet in simplicity, but that's not sexy, and sex sells. In conclusion: The React revolution and it's consequences have been a disaster for the human race.
  - roncesvalles 4y ago
    The SEO argument is a strawman. Large swaths of the Internet return a blank page if you try to access them with JS turned off. Are you saying search engine crawlers haven't figured out how to deal with that? There is nothing inherent in SPAs that make load time slower. If your REST API takes 5 seconds to serve up JSON, what's to say your SSR rendered page won't also take 5 seconds?

DoesntMatter22 4y ago

I've built so many spa's in virtually every popular framework. I'm over it. Even the simplest SPAs end up being way more effort than they are worth IMO. I'd write thin API layers and it seemed great. Recently though. I moved to all backend with some jQuery. I render all the views on the backend and if they need to be swapped out I make a simple ajax call to pull the rerendered days and swap the div. It's like 2 lines of code for me. Everything is so much faster, primarily because JS has so many gotchas. And so many times where you wonder "wait why isn't the data right here? Shouldn't this have blown up". There is no appreciable difference to the user here but I can work in a backend lang and sparingly use JS and it's a pleasure.

88913527 4y ago
jQuery codebases are great at 2 LOC and complete nightmares at 2M LOC.
- DoesntMatter22 4y ago
  Any codebase is a nightmare at 2 million lines don't kid yourself
sebazzz 4y ago
> Recently though. I moved to all backend with some jQuery. I render all the views on the backend and if they need to be swapped out I make a simple ajax call to pull the rerendered days and swap the div. It's like 2 lines of code for me. Sounds like one of those bad SPA in the making. You know, without browser navigation, without an url that can be revisited.

brap 4y ago

Whenever this “SSR vs SPA” question comes up, I feel like it’s the wrong question to ask, because neither is ideal. Server rendered or static sites make sense in some specific use cases (e.g docs, blogs), but even for those classic use cases they’re not ideal (e.g full page reloads every time). On the other hand, SPAs make sense in some specific use cases (e.g Gmail) but even for those classic use cases they’re not ideal (e.g first render takes time). I think we always need both server and client rendering, regardless of the use case, and the question we need to ask is how can we achieve this in an ergonomic way. There’s some progress being made there (e.g Next.js) but I feel like it’s not quite there yet.

cyral 4y ago
The hybrid approach really is the best of both worlds, and it makes perfect sense to do the heavy lifting on the server initially and then turn over everything to the client rather than doing the heavy lifting again for every single subsequent request. Every time this comes up though there is the snarky "lol SSR isn't new, are JS devs just learning about it???" type response here.

cyral 4y ago

Imagine if this was reversed and mobile apps suddenly started switching to SSR. Instead of downloading the app once and making lightweight JSON requests (analogous to what SPAs are doing), they froze for seconds while the next page is rendered on the server while losing all of the local state that you had typed in. Sure would be a lot of hate for that when they have been working fine for a decade. You'd probably argue, that it sounds like that is just a bad implementation of SSR. Not all SSR is like that surely? This is how silly this weekly SPA vs SSR debate is.

BackBlast 4y ago
Some mobile apps are like this. Even some desktop apps, won't move forward without it's connection to the mothership. Yes, it's frustrating. I like offline capable systems. The money isn't there for offline ability on most websites. So... I can appreciate it from a distance.

wkat4242 4y ago

I hate everything that's mobile-first. And I prefer simple sites not bogged down by tons of JavaScript. Which is not so surprising considering this is my favorite website. In fact it's not so surprising to find a general desktop-centric view here at all, in my opinion.

Glench 4y ago

Svelte creator Rich Harris gave a great middle-of-the-road talk about single page apps with examples a year ago: https://www.youtube.com/watch?v=860d8usGC0o https://www.youtube.com/watch?v=860d8usGC0o Then he released SvelteKit which has the best of both worlds: https://kit.svelte.dev/ https://kit.svelte.dev/

steve_taylor 4y ago

I’ve noticed that a lot of developers tend to hate things that they’ve tried building but they found it too hard. People enjoy doing things they’re good at and hate doing things they suck at. There are a lot of SPAs that shouldn’t be SPAs, but that doensn’t mean all SPAs are bad. This isn’t your grandpa’s web browser anymore. We’ve moved on from the web being all about hyperlinked documents. The browser is also an app runtime, just like your smart phone. If server-side rendering was the only good way to build web apps, then it stands to reason thay it’s the only good way to build phone apps with equivalent functionality. Maybe phone apps should also start re-rendering the entire UI on the server every time the user taps something.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

recursivedoubts 4y ago

The arc of web development is long, but it bends towards grug brain: https://grugbrain.dev/#grug-on-front-end-development https://grugbrain.dev/#grug-on-front-end-development

userbinator 4y ago

I've always hated them but it's good to see the tide turning. Slow (one of the first signs of an SPA - a page with its own custom loading indicator), requires JS to do things that otherwise needn't, and things like links don't work right. I do wonder if the otherwise superfluous --- and constantly changing --- JS requirement is part of the "weaponised change" approach of Google to furthering its control over the browser, since it's relatively trivial to create a browser that's usable on sites that need nothing more than HTML forms, but substantially more difficult to create one which will work with the simplest of SPAs.

cirrus3 4y ago

"Suddenly"? I don't know any users who liked them ever, and that has been a long time now. Designers and clients seemed to like them. Not users or developers.

rbd765 4y ago

The ecosystem of web standards, browsers and search engines is mostly optimized with MPAs in mind. That's the base experience for web. Things have only gotten more complicated as we've built abstractions on top of MPAs. In the earlier iterations, SPAs broke navigation, broke SEO, had no decent state management solution, and required a good understanding of reflow/repaint to avoid performance issues. The ergonomics of SPA frameworks has improved drastically and metaframeworks like Next.js have mostly fixed those issues. But the myriad of options and paradigms might be exhausting for some devs. Some experienced devs might be nostalgic for the document-centric PHP days. I imagine that many newer devs have only recently been exposed to the pleasure of building a simple MPA website, as they were initially thrust straight into React. For example, I recently chose to use Hugo for my blog. Just wanted something dead simple to build a static website without all the bells and whistles of a SPA.

xboxnolifes 4y ago

I like SPAs when they're actually used for applications. I hate SPAs when they're used for crippled website functionality and slower load times than a normal server round trip.

BackBlast 4y ago

Love me a well built SPAs. Great tech. I certainly don't mind if others don't build them. So many people trying to advocate the "one true way" of tech instead of acknowledging that it really depends on the use case as which tools end up being superior.

tauseefferaz 4y ago

Q: why it matters? A: 90% SaaS product features you see is half baked, SPA's are the cure to the mess. Solving core problems requires rebirth of application but when ARR is big you can't go and rebase the code. Either you're born with it or your product will rebirth. (SAP's has it's own cons but the pros weighs more)

rektide 4y ago

The web has a huge anti- crowd all around it. People detest that there's this terrible awful wretched browser pretending like it can do code. Which is 98% gatekeeping sad-pants whiner-shit. There's problems, but the amplification problem is uber for real, and most of the complaints just don't frigging matter; this is 98% a Bullshit Asymmetry problem: it takes vastly more energy to care about & refute troll-ish petty behavior than it takes to generate it. Positive behavior rarely gets amplified. There's an outsized representation for anger/negativity, as there almost always is, everywhere, forever. Personally I think it's absurd to favor servers. AKA mainframes. Thick client web systems have a fundamental embrace of user-agency, in a way that thin-client systems are utterly unable to negotiate. It's cheap and easy to take digs on how bad things have been, and 100%, there's been a pretty poor developmental track record & much could & should be better in the client side universe. But it's still 100% better a RFC 8890 paradigm - The Internet Is For Users - than literally all the rest of computing, which has nothing for users & offers them diddly squat in terms of agency. Alex's critique / pouring gas on the fire is wrong for a simple reason: we've been asleep at the wheel & embraced little change. URL routing, incremental loading, offline capability, & a host of interesting sprawling new web capabilities that could improve everything are still drastically unadopted. We have a lot of libraries for orthogonal concerns, but there have been essentially zero successful efforts in the last decade to define a system even as comprehensively cross-cutting as literally the first successful JavaScript framework was, Backbone. We have reduced scope since, and left orgs to cobble together orthogonal libraries, which has strengths, but makes it harder to adopt & leverage the high minded better potentials of what could happen. The web just hasn't evolved or advanced significantly, in spite of some churning iteration for how we all React. SPAs are wonderful, but we've crashed against the limits of what we are willing to explore, and there's been a lack of way forward projected, and the upsurge in anti-SPA SSR is basically just an off-gassing, a pent up pressure to do anything other than what we've been up to, and while it has some virtue, I still ascribe most of it's interest to the fact that client-side systems have been at a standstill & real coherence & sensible integrative holistic imagining of how we might better do SPA's has been obviously absent for a while now. GraphQL was some attempt to respin the front-end world but I think by now we know it's not really actually much different or better, but there's ideas captured there, where front-ends are not as hand-craft artisinally-made that we still are far from, and there's countless capabilities we should be tapping - like good Service Worker patterns, much more webworker and distributed computing ideas - that have made essentially no progress. At some point we need to upgrade & enhance what we expect of SPAs, but while the tooling has changed somewhat (React moving from classes, to HoC, to hooks, Redux to whatever), there's been little actual embrasure of real change, real web capabilities, that have been all about. SPAs are still one of the greatest best option out there, even though their means-of-production are essentially unchanged for a decade & the hipsters are desperately hungry for cooler/bettter. Even though we've hit this kind of so so local maxima, there's just nothing anywhere as effective, and the whole SSR pitch may fit some roles, but for like 98% of systems, a SPA has a ton of advantages in being a more unified isolated independent thick client that just networks back to a bunch of dumb resources, which is a better/simpler & less overhead model - albeit one with some more loading cost - than the radically weirder & more complex models of splicing apart the baby & having part of the work happen one place & part of the work happen elsewhere. And none of that is good for the user anyways. I look forward to a new novel exciting future, but this is not the RFC 8890 way forwards. SPAs are kind of stuck, but still the best version of the web we have. https://www.rfc-editor.org/rfc/rfc8890 https://www.rfc-editor.org/rfc/rfc8890

curtisblaine 4y ago

Because you normally need to use a framework + the front-end ecosystem and it's hard (as in: not something you can improvise, you need to be good at it and have years of experience in it). Many developers on the back-end think that the website should be a thin veneer over a service. When they find out they can't just hack on it, but they need to learn React/npm/react-router/table virtualization/some component framework they get irritated because they've always seen front-end as a "lower" discipline for "worse" developers. That said, a well-written SPA is able to express a class of web-based applications that, if written well, are indistinguishable from normal web pages (with anchors etc) but can do much more things than a traditional server generated web page. Since native apps are essentially living in paid, closed, walled gardens, long live SPAs.

0xbadc0de5 4y ago

Why does everyone like skinny jeans and not bell bottoms? Light mode or dark mode? Fashion trends change. Cynically, there's also a measure of job security in chasing trends. Gotta keep up with the latest whizbang framework.