10 ms·

You Shouldn't Start with an SPA

46 points by simonhamp 3y ago

camhart 3y ago
If you have multiple frontends seperating frontend logic from backend makes a lot of sense. I've been building/maintaining a SPA for the past 8 years and have no regrets and am unconvinced by this article (or the one it mentions).
- moribvndvs 3y ago
  While the author explains that the front and backend are coupled, I think they overstate the coupling of client/API but don’t account for the numerous and disparate factors that motivated the popularity of SPAs to begin with. It’s perhaps out of scope of a comment to go into those details, but anyone who’s built and had to evolve large business applications on the web in the early 2000s is familiar with the headaches of the traditional server side techniques [sweats in server-side includes, ASP.NET form state, unnecessary db calls loading whole pages when only part has changed, etc.]. Not even getting into other benefits (API reuse and the flexibility to support multiple clients and use cases simultaneously). In my opinion, the two major problems are tooling (which I think is more of an issue with browsers and the deficiencies of JS) and people using SPAs as an all purpose solution (does your blog or marketing homepage really need to be a SPA, really?). The former has seen steady improvements, but at any rate I’ll eat the cost of because it’s worth it for some of the larger systems I have to build and maintain. The former, well I dunno what to tell you, the cargo cult has been a fixture in this industry for a long time. I don’t think wearing a “you’re a bad person if you develop SPAs” helps (not accusing OP of this, but remarking on a general attitude) but in fact furthers the problem by pressing devs into binary thinking rather than evaluating and making decisions on their own. So I’m with you: I won’t be shamed for having written SPAs and I’ll continue to do so as needed
  - simonhamp 3y ago
    No shaming intended. This is not meant to be applied retrospectively. I believe now that an SPA is unneeded, precisely because of how far the technology has come. And I believe that SPAs are the cause of a lot of that advancement and have pushed back-end approaches to level up to help realise some of these benefits.
jongjong 3y ago
I completely disagree with any attempt to merge the front end with the back end by obscuring the boundary. It's a horrible idea and leads to security vulnerabilities. The front end is a public resource, the back end is a private resource whose access needs to be controlled according to clear and consistent rules and with proper authentication checks.
- ivan_gammel 3y ago
  There’s usually no problem with security in thin hypermedia apps. Backend still has full control over access, you just have an extra step of actually rendering the view with the model you’d otherwise return via API.
BinRoo 3y ago
I wonder, what the best practices for supporting offline mode when the backend drives the frontend?
- ivan_gammel 3y ago
  There’s none, obviously. Offline mode excludes thin clients. You need a lot of UI, state and business logic cached locally.
- prophesi 3y ago
  You can choose the routes that workbox caches, but any dynamic templates likely won't work; server-side rendering could potentially help with that, or at least help point out where it breaks.
- simonhamp 3y ago
  You still don't need an SPA for this
lelanthran 3y ago
I think that this all boils down to "The tooling sucks". The specific SPA problems mentioned are due to the bundling, the packing, the dependencies, etc. None of the SPA problems mentioned are specific to SPA, they're specific to current toolsets.
- realusername 3y ago
  But there's no world where the tooling doesn't suck for an SPA. As the application grows, the bundle is going to grow and the caching / building / splitting problems will just increase higher and higher. All those esbuild & associated tools just slightly delay the inevitable. All the ones I worked on inevitably stumble upon this problem and the worst part is, the bigger your team is, the harder it's going to be to scale an SPA meaning that hiring more people doesn't even help here.
  - lelanthran 3y ago
    > But there's no world where the tooling doesn't suck for an SPA. I dunno about that. I've seen good things with htmx. Also pretty nifty things with web components. An SPA doesn't have to use all the most modern frameworks. SPAs were being done long before React and friends were created, long before even Jquery was popular.
    - realusername 3y ago
      Htmx isn't built with SPAs in mind. Htmx is the opposite approach to an SPA in my opinion, it's traditional views but improved. And yes, that does scale easier compared to an SPA, there's no bundling / splitting / caching complexity here. Technologies where the frontend bundle increase with a flat or nearly flat curve as the features get added have a much much easier time to scale than the ones which do not.
      - candiddevmike 3y ago
        What is your definition of scaling here? A large, untyped, JS-in-HTML via Htmx codebase reminds me of the jquery dark ages.
xutopia 3y ago
I think he's fundamentally right even if he's wrong about certain details. SPA create a polarization between devs whereby they're either front end or backend. Full stack devs are slowed down compared to tools like Hotwire/Turbo, Liveview, HTMX, etc.. Furthermore you need a huge stack of tooling to make pages work and lots of javascript code needs to be downloaded to make most standard SPAs work today. Not to mention having to render html on the backend in a slower and more complicated manner than using any of the more recent enhancements of HTML that provide caching, high speed download out of the box.
- mdasen 3y ago
  This is probably correct...for now. However, I think the next decade will see SPAs become simpler and we're already starting to see it. In some ways, I'd argue that Livewire is an example of that. I think Remix (JS) offers a full-stack experience where you just create an `action` function of what you want run on the server. Remix can be pre-rendered on the server so pages don't need to download lots of JS before stuff is displayed to the user for the initial page load. I think WebAssembly is also going to be bringing innovations. .NET's Blazor is probably the furthest along at this point and it allows you to create an app that's rendered on the server and then WASM is downloaded in the background to enable all the interactivity. It can also operate like Livewire with websockets if you prefer. While Blazor might be here today, we'll probably see more coming. Rust's Leptos looks really cool and allows you to use its `#[server]` macro to define functions to be run on the server instead of the browser. I think that we're going to start seeing better options for creating SPAs without needing to maintain two separate codebases.
klysm 3y ago
You should start with an SPA if it makes sense for what you are building.
- simonhamp 3y ago
  Can you give an example?
  - klysm 3y ago
    Complex admin dashboard with lots of interactions that should be low latency
    - pier25 3y ago
      You can have complex interactions with an MPA. Regarding latency, it's mostly related to the distance between the user and the database. The routing strategy has nothing to do with that.
      - klysm 3y ago
        The routing strategy can have a significant impact on what latency the user sees.
    - simonhamp 3y ago
      Yeh I've seen some of those as SPAs... ouch Honestly, I'd rather not be presented with an empty grid of spinners tbh I think you can get something useful on first render and then dynamically update from there (either with polling, SSE or WebSockets) all without the added complexity of an SPA
      - spiderxxxx 3y ago
        I make mine such that the first load includes the data needed in the first load of the page. If you're going to populate a grid on the first load, just have the backend include that in the page itself inside a dynamically inserted javascript block. For something like paged search results, you can preload the first page, and preload the second page a short while after that.
azangru 3y ago
> When does an SPA make sense? I didn't quite get the answer — if it is that an SPA makes sense when you have front-end and back-end specialists on your team, then it is surely the wrong answer. Perhaps I misunderstood. I like Alex Russell's answer: an SPA makes sense when data about users' session depth demonstrates deep sessions. Or Jason Miller's answer: an SPA makes sense when the thing that's being built fits certain known app holotypes.
- simonhamp 3y ago
  Thanks for the feedback. I will try to make this clearer in the article. While I state later that true decoupling isn't technically possible, it really only makes sense (to me) to attempt it when you've got larger teams split down these lines. It really comes down to where you want to create the split: in code or on the org chart? If you've created the split in one place, it will of necessity happen in the other. If you can avoid the split altogether, then an SPA probably doesn't ever make sense.
  - azangru 3y ago
    > It really comes down to where you want to create the split: in code or on the org chart? Deciding on the architecture of an application based on the org chart is probably not a good idea.
    - simonhamp 3y ago
      And yet Conway's Law still holds up surprisingly well One way or another, your app reflects the org chart. So either you force the split because of your architectural choice or it happens because of your org structure One way or another it will happen
ivan_gammel 3y ago
Client-side rendering has a lot of benefits not mentioned in the article. 1. Adaptive design: it’s easier to adjust user experience to the client device capabilities. SPA frameworks take the job of ensuring browser compatibility, but it’s not just it. 2. Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts). 3. Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. SPA can auto-retry, just showing the spinning wheel longer. Browser will show the timeout page, and who knows if the backend can correctly recover on refresh.
- tonyedgecombe 3y ago
  >Better UX for slow networks Yet the reality seems to be very poor UX from SPA's on a slow or intermittent connection.
- leosanchez 3y ago
  > Better UX for slow networks Don't you think the case can be made against SPA's w.r.t slow networks ? Angular, react add hundreds of KB's to frontend bundle which give bad UX especially in slow networks
  - jauntywundrkind 3y ago
    But then after 20s loading or whatever, it's cached and your experience every moment thereafter & if you return later is speedier. If the app has optimistic updates, actions may even feel instant. If your app really cares, it'll have an offline mode/be local-first. Then you you pretty much need an SPA or some kind of heavier front end.
    - zelphirkalt 3y ago
      After 20s ... you have lost 50% of your visitors, because they think the damn thing is never going to finish loading on their connection and you will have triggered connection loss anxiety on multiple levels. Also this is assuming, that one does not want to take all the things of that website and burn them after use, which is not a safe assumption to make on most websites, considering all the ads and trackers on today's typical websites. An offline still working app sounds great. Unfortunately very few aspire to reach that point. Most already break to various degrees when you hit the back button.
davidsergey 3y ago
The article talks a lot about technology choice, but not about given product. I do tend to agree – that SPAs are not necessary, but I would not use this article as an argument. And if somebody would present this article to me – I would not take it seriously. The fact that author is using very interesting language when refering to React and Angular does not help. I'd love to hear customer-centric or product-centric reasoning. * Don't use SPA because customers hate it when you change entire app on them. * Don't use SPA, because customers of our particular product require faster turn-around. * Don't use SPA, because they are harder to test in our organisation.
- simonhamp 3y ago
  Thanks for the feedback. Noted
kgeist 3y ago
>Your back-end and front-end are always coupled. So trying to split them in anything but the most extreme circumstances is an exercise in futility. >If your back-end team want to move in one direction, they've got to align with the front-end team. We have different backend and frontend teams and I can't agree that it's futile or hard to decouple etc. The only "coupling" which we have is the public API of the backend. Before a product or a feature is started, the teams design and agree on the API between the backend and the frontend, as part of our overall architecture design process (doesn't take more than a couple of days of 1-2 senior engineers if it's a big feature). After that, the two teams work completely in parallel. The frontend team has a framework which allows them to test the UI without the backend ready (using mock API). The backend team checks their API implementation using end-to-end tests. When the both teams are ready, we have the integration phase to see if it works together. Sure, often some edge cases are found and the API has to be changed a bit, but overall for me it has been quite a pleasant experience.
- thomaslord 3y ago
  I think there are pros and cons to this. I can definitely see how, in a company with larger teams, separating the frontend and backend can help with productivity. On the other hand, I'd wager that decoupled applications are less efficient with API calls something like 90% of the time. When I build a fully-coupled application, loading any given page after the CSS/JS files are cached requires a single HTTP request which always includes exactly the data that's required for that page. When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable. I started out at my current job working on a fully coupled system that's basically as "legacy" as you can get, and eventually started modernizing it - as part of that process, we decoupled the frontend from the backend. At first it felt more productive simply because it wasn't the old system and the new frameworks actually had documentation, but once I compared it to building a coupled system with modern frameworks I realized the coupled system made me much more productive. I'm currently the only developer at my company, though, so I feel like I'm probably the perfect target audience since I don't have to worry about team coordination at all.
douglee650 3y ago
Modern frontend frameworks smear technical concepts into the presentation layer; for example, understanding of hydration becomes integral to semantic presentation of content and therefore an overriding concern; "developers aren't cheap!". Then we are reduced to two outcomes — developers become more design-aware, or designers become more dev-aware. Both are unicorn hunts, what do?
- simonhamp 3y ago
  I don't think this has anything to do with design tbh. You have developers who are comfortable with HTML/CSS/JS and those who prefer to stay clear of it. A lot of those HTML/CSS/JS folks happen to also really enjoy (and are great at) PHP/Ruby/Python etc - not so unicorn-y
ebiester 3y ago
I believe this is a cultural argument mascaraing as a technical one. The honest truth is that we have had front end and back end developers for as long as the web has been around, and before that. Your "full stack" developers are most often back end developers who begrudgingly can put together a less complex front ends with very little understanding of what makes a front end good to work with. Your "full stack" front-end preferring developers get drummed out because the back end developers conflate being good at back end concepts with being good at programming in general. There is a definite back-end bias with developers who do not specialize in web or mobile front ends. For some applications, that's fine. However, back end developers build the back end frameworks and do not think about what makes a great experience for developing more complicated user experiences. In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks.
- simonhamp 3y ago
  You can have great front-end experiences and great front-end-back-end developer relations without an SPA
  - ebiester 3y ago
    I'm talking about a great front end developer experience. Rails was crap. Spring * was crap. None of the back end frameworks came close to thinking in abstractions - code reusability was an afterthought at best. Ask yourself, why was there never a Rails component library? Because Rails made abstraction difficult in the front end. Nobody did a good job here.
- acdha 3y ago
  > In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks. Partially, but let’s not pretend our field is more rigorous than it actually is. Most it was following fads: the cool kids at some big tech companies were building HUGE apps with tons of logic as SPAs and a lot of people wanted to say “us too!” without considering how similar their apps are or comparing staffing. The natural arc I’ve seen is that teams who didn’t pick an SPA for solid technical requirements end up delivering results which are no better at considerably slower speed because they’re supporting a lot of non-domain complexity and still end of changing their backends in lock-step with the front end. That tends not to leave time for things like accessibility or performance.
redcobra762 3y ago
Two thoughts: Firstly, when you provide a normative assertion, at least couch it in positive terms. “If you want X, then you should do Y.” That way people at least know the tradeoffs you’re opting them into. I really can’t tell what trade offs the author is proposing are better for me. Secondly, if you can’t build a system that actually decouples the frontend and the backend, that’s a “you” problem, not a technology problem. I have successfully designed and implemented many APIs that operated completely independently of the UI, allowing both the UI and power users to interact with our platform through a shared service. I do get so tired of people presuming their specific issues are everyone’s issues. I have zero problem with the tooling of an SPA, my ability to customize is increased, not decreased, when I use an SPA, and when I’m working with other people, they often prefer not having to think about the whole stack, which makes them happier. This is one of those articles you read that shows up “unplugged” from the culture in which it originated. The author demonstrates the value of talking to others in a given field, and the pitfalls that one can get trapped in when one doesn’t socialize enough professionally.
- jabradoodle 3y ago
  How can it operate completely independently if the front end requires data in a format it understands to perform logic on.
  - redcobra762 3y ago
    By providing the data in a format that any consumer can understand. JSON, very often.
    - jabradoodle 3y ago
      But your front end is still coupled to the structure of that JSON, which is often fine, but it is coupling
      - redcobra762 3y ago
        “Couples” means two-way. Of course your front end will depend on your backend, the problem arises when they become interdependent; when you can’t develop one without making changes to the other. In this sense a frontend and a backend can be entirely independent, and in every sense the backend should be independent of the frontend.
cpursley 3y ago
Post mentions Livewire & Hotwire but totally misses the real star (and OG) of this type of architecture: Phoenix LiveView ^ Elixir is an order of magnitude more scaleable, easier to operate and cheaper than any of these other solutions.
- pier25 3y ago
  What about DX? Would you say Phoenix is better than Laravel?
  - cpursley 3y ago
    I haven’t used Laravel (I hear good things). But Phoenix is voted as most loved web framework fwiw: https://curiosum.com/blog/phoenix-framework-guide https://curiosum.com/blog/phoenix-framework-guide
- pritambarhate 3y ago
  Only if one knows Elixir which is tiny percentage of developers.
  - cpursley 3y ago
    Def use what you know. But you can learn the basics of Elixir in two weeks. The payoff is worth it.
paxys 3y ago
This article (and all others like it) always ignore the fact that mobile exists. Nowadays "front end" isn't just HTML pages being rended on some browser but also entire iOS and Android apps and maybe several others. Those APIs you think are an overhead are actually necessary regardless, and after that it's your server rendered HTML that instead becomes an additional burden to maintain. A SPA with dedicated front end engineers using the same APIs as the mobile ones is the most sensible approach for most apps.
- simonhamp 3y ago
  I've done this. I spent six years building and maintaining an API platform to support apps and websites. I'm fully aware of mobile and the need for those APIs. They just weren't sufficiently overlapping to be of any use to an SPA. You need a whole slew of separate endpoints and behaviour, so it may as well not be an API - just make it a server-rendered monolith and move along.
  - paxys 3y ago
    Why would your mobile apps and browser client be so diverging that you need a completely separate set of APIs for both?
    - simonhamp 3y ago
      Because they were entirely different applications. It was an API platform for a suite of applications There was almost zero crossover in functionality
      - paxys 3y ago
        Ok sure, but 99% of applications out there do not fit this description.
        simonhamp 3y ago
        If you're building an SPA that's identical to a native app, I think someone in the exec team is making poor decisions Either make a web app or a native app... don't do both
superkuh 3y ago
It reads like this article's unstated premise is that it's about what you should do in situations where you aren't in control, are being paid to do the things, and working with other people in the same situation. But why write articles about what we're forced to do for money? That situation is always borked and we wouldn't be there unless we were being paid. Who wants to think about and do work during non-work free time? Yuck. Lets see some articles about what human people, not people hired to do corporate person's bidding, should do. In this context the case for SPA is even more diffuse. In fact, all the arguments about synching frontend and backend don't even makes sense: that kind of thing is cargo culting. Human persons when operating of their own free will working on their own projects should definitely not start with SPAs. They shouldn't even start with javascript dependent frameworks. Just put an HTML file in a directory.
- simonhamp 3y ago
  I'm a freelance consultant and a human person. I advise companies, especially early-stage startups, on this stuff. I'm writing about what I see, which is hundreds of hours being wasted on triaging bugs, meetings trying to align small teams, and decision-makers simply following trends.
  - superkuh 3y ago
    I get that, you write what you know. But you're literally saying it's a thing you do because you want money to live. It's not something you're chosing to do as a human person. We're all technically human (except the corporate persons) but if you're doing something for money for companies then you're operating with those motives and preferences in mind; motives and preferences that apply to corporate persons, not human persons. I know thinking in terms of those corporate needs is the default on HN, but it doesn't have to be, and shouldn't be. We're all human people too.
endisneigh 3y ago
It’s always amusing how people compare crappy spa vs great traditional site. A well done spa is far superior. Offline support, caching, adaptive layout, etc. it’s not even close. That being said, barring things like offline support the two are equivalent functionally. Use what you know.
- simonhamp 3y ago
  You can get offline support without an SPA. Of course, that may mean replicating some of your back-end behaviour in JavaScript, but that doesn't necessitate building an SPA, or the whole app in JS. Please do share which crappy SPAs you're thinking of
pjerem 3y ago
For what it’s worth, I started my current project with the good old Django framework. I haven’t touched it for mostly a decade and my god it’s just a pleasure. You just write your domain code and the framework handles everything else. But more importantly, Django don’t try to be original or to force you into a paradigm, it just solves and abstract away the real life problems of websites. There is basically 0 boilerplate. Add some htmx for the few things you want dynamic and you’re done. Now, I prefer typed languages but why haven’t we something like Django (or Rails) in typescript ?
- reducesuffering 3y ago
  Django in Typescript is Next.js / T3 stack which I much prefer to Django
  - pier25 3y ago
    Not even close. Next is pretty barebones as a backend framework compared to mature solutions like Django, Rails, or Laravel.
  - pjerem 3y ago
    > Django in Typescript is Next.js / T3 stack I’m sorry but no. In Django, every parts of the framework are tightly integrated in smart ways to make you more productive. You can write things like "redirect(entity)" to redirect your user to the view that shows your entity. Displaying a form to create/edit an entity is a few lines of code… I understand why you would prefer something else but you can’t say that it’s Django.
    - reducesuffering 3y ago
      > You can write things like "redirect(entity)" to redirect your user to the view that shows your entity. You literally have a redirect() in next.js routing you to another URL https://nextjs.org/docs/app/api-reference/functions/redirect https://nextjs.org/docs/app/api-reference/functions/redirect > Displaying a form to create/edit an entity is a few lines of code… A form is not a particularly hard example in any sized app. https://nextjs.org/docs/pages/building-your-application/data-fetching/forms-and-mutations https://nextjs.org/docs/pages/building-your-application/data... Now do Django with any sort of frontend that isn’t just html and adhoc js or htmx. DRF is very 2005 syntax “basic crud that’s it” Then trying deploying Django, a process that will take 50x what the form will. https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-22-04 https://www.digitalocean.com/community/tutorials/how-to-set-...
simonhamp 3y ago
I feel like a lot of the commenters here have missed the point... in the title it says you shouldn't start with an SPA. I never say "don't ever use an SPA," just that I feel—more strongly than ever—that the kinds of environments that call for a true SPA are getting further and further towards the extreme. You should do whatever you like. As always, there are trade-offs. For me it's becoming clearer that the trade-offs are heavily stacked towards keeping my front-end and back-end more tightly coupled.
- lelanthran 3y ago
  Just a nit on your article: I think you meant 'retch' not 'wretch'.
  - simonhamp 3y ago
    You're absolutely correct. Thanks
from-nibly 3y ago
In my experience spas have a much better ux. Have you guys used Jira before? It's actively painful and there even is some local interactivity. But whenever you need a page wide rerender it makes me twitch. Same thing with aws when navigating between accounts/products. Also having a spa doesn't mean you need to have separate frontend and backend engineers. But it does allow various value streams to leverage each other's APIs in their own front ends.

46 points by simonhamp 3y ago

If you have multiple frontends seperating frontend logic from backend makes a lot of sense. I've been building/maintaining a SPA for the past 8 years and have no regrets and am unconvinced by this article (or the one it mentions).

moribvndvs 3y ago
While the author explains that the front and backend are coupled, I think they overstate the coupling of client/API but don’t account for the numerous and disparate factors that motivated the popularity of SPAs to begin with. It’s perhaps out of scope of a comment to go into those details, but anyone who’s built and had to evolve large business applications on the web in the early 2000s is familiar with the headaches of the traditional server side techniques [sweats in server-side includes, ASP.NET form state, unnecessary db calls loading whole pages when only part has changed, etc.]. Not even getting into other benefits (API reuse and the flexibility to support multiple clients and use cases simultaneously). In my opinion, the two major problems are tooling (which I think is more of an issue with browsers and the deficiencies of JS) and people using SPAs as an all purpose solution (does your blog or marketing homepage really need to be a SPA, really?). The former has seen steady improvements, but at any rate I’ll eat the cost of because it’s worth it for some of the larger systems I have to build and maintain. The former, well I dunno what to tell you, the cargo cult has been a fixture in this industry for a long time. I don’t think wearing a “you’re a bad person if you develop SPAs” helps (not accusing OP of this, but remarking on a general attitude) but in fact furthers the problem by pressing devs into binary thinking rather than evaluating and making decisions on their own. So I’m with you: I won’t be shamed for having written SPAs and I’ll continue to do so as needed
- simonhamp 3y ago
  No shaming intended. This is not meant to be applied retrospectively. I believe now that an SPA is unneeded, precisely because of how far the technology has come. And I believe that SPAs are the cause of a lot of that advancement and have pushed back-end approaches to level up to help realise some of these benefits.

jongjong 3y ago

I completely disagree with any attempt to merge the front end with the back end by obscuring the boundary. It's a horrible idea and leads to security vulnerabilities. The front end is a public resource, the back end is a private resource whose access needs to be controlled according to clear and consistent rules and with proper authentication checks.

ivan_gammel 3y ago
There’s usually no problem with security in thin hypermedia apps. Backend still has full control over access, you just have an extra step of actually rendering the view with the model you’d otherwise return via API.

BinRoo 3y ago

I wonder, what the best practices for supporting offline mode when the backend drives the frontend?

ivan_gammel 3y ago
There’s none, obviously. Offline mode excludes thin clients. You need a lot of UI, state and business logic cached locally.
prophesi 3y ago
You can choose the routes that workbox caches, but any dynamic templates likely won't work; server-side rendering could potentially help with that, or at least help point out where it breaks.
simonhamp 3y ago
You still don't need an SPA for this

lelanthran 3y ago

I think that this all boils down to "The tooling sucks". The specific SPA problems mentioned are due to the bundling, the packing, the dependencies, etc. None of the SPA problems mentioned are specific to SPA, they're specific to current toolsets.

realusername 3y ago
But there's no world where the tooling doesn't suck for an SPA. As the application grows, the bundle is going to grow and the caching / building / splitting problems will just increase higher and higher. All those esbuild & associated tools just slightly delay the inevitable. All the ones I worked on inevitably stumble upon this problem and the worst part is, the bigger your team is, the harder it's going to be to scale an SPA meaning that hiring more people doesn't even help here.
- lelanthran 3y ago
  > But there's no world where the tooling doesn't suck for an SPA. I dunno about that. I've seen good things with htmx. Also pretty nifty things with web components. An SPA doesn't have to use all the most modern frameworks. SPAs were being done long before React and friends were created, long before even Jquery was popular.
  - realusername 3y ago
    Htmx isn't built with SPAs in mind. Htmx is the opposite approach to an SPA in my opinion, it's traditional views but improved. And yes, that does scale easier compared to an SPA, there's no bundling / splitting / caching complexity here. Technologies where the frontend bundle increase with a flat or nearly flat curve as the features get added have a much much easier time to scale than the ones which do not.
    - candiddevmike 3y ago
      What is your definition of scaling here? A large, untyped, JS-in-HTML via Htmx codebase reminds me of the jquery dark ages.

xutopia 3y ago

I think he's fundamentally right even if he's wrong about certain details. SPA create a polarization between devs whereby they're either front end or backend. Full stack devs are slowed down compared to tools like Hotwire/Turbo, Liveview, HTMX, etc.. Furthermore you need a huge stack of tooling to make pages work and lots of javascript code needs to be downloaded to make most standard SPAs work today. Not to mention having to render html on the backend in a slower and more complicated manner than using any of the more recent enhancements of HTML that provide caching, high speed download out of the box.

mdasen 3y ago
This is probably correct...for now. However, I think the next decade will see SPAs become simpler and we're already starting to see it. In some ways, I'd argue that Livewire is an example of that. I think Remix (JS) offers a full-stack experience where you just create an `action` function of what you want run on the server. Remix can be pre-rendered on the server so pages don't need to download lots of JS before stuff is displayed to the user for the initial page load. I think WebAssembly is also going to be bringing innovations. .NET's Blazor is probably the furthest along at this point and it allows you to create an app that's rendered on the server and then WASM is downloaded in the background to enable all the interactivity. It can also operate like Livewire with websockets if you prefer. While Blazor might be here today, we'll probably see more coming. Rust's Leptos looks really cool and allows you to use its `#[server]` macro to define functions to be run on the server instead of the browser. I think that we're going to start seeing better options for creating SPAs without needing to maintain two separate codebases.

klysm 3y ago

You should start with an SPA if it makes sense for what you are building.

simonhamp 3y ago
Can you give an example?
- klysm 3y ago
  Complex admin dashboard with lots of interactions that should be low latency
  - pier25 3y ago
    You can have complex interactions with an MPA. Regarding latency, it's mostly related to the distance between the user and the database. The routing strategy has nothing to do with that.
    - klysm 3y ago
      The routing strategy can have a significant impact on what latency the user sees.
  - simonhamp 3y ago
    Yeh I've seen some of those as SPAs... ouch Honestly, I'd rather not be presented with an empty grid of spinners tbh I think you can get something useful on first render and then dynamically update from there (either with polling, SSE or WebSockets) all without the added complexity of an SPA
    - spiderxxxx 3y ago
      I make mine such that the first load includes the data needed in the first load of the page. If you're going to populate a grid on the first load, just have the backend include that in the page itself inside a dynamically inserted javascript block. For something like paged search results, you can preload the first page, and preload the second page a short while after that.

azangru 3y ago

> When does an SPA make sense? I didn't quite get the answer — if it is that an SPA makes sense when you have front-end and back-end specialists on your team, then it is surely the wrong answer. Perhaps I misunderstood. I like Alex Russell's answer: an SPA makes sense when data about users' session depth demonstrates deep sessions. Or Jason Miller's answer: an SPA makes sense when the thing that's being built fits certain known app holotypes.

simonhamp 3y ago
Thanks for the feedback. I will try to make this clearer in the article. While I state later that true decoupling isn't technically possible, it really only makes sense (to me) to attempt it when you've got larger teams split down these lines. It really comes down to where you want to create the split: in code or on the org chart? If you've created the split in one place, it will of necessity happen in the other. If you can avoid the split altogether, then an SPA probably doesn't ever make sense.
- azangru 3y ago
  > It really comes down to where you want to create the split: in code or on the org chart? Deciding on the architecture of an application based on the org chart is probably not a good idea.
  - simonhamp 3y ago
    And yet Conway's Law still holds up surprisingly well One way or another, your app reflects the org chart. So either you force the split because of your architectural choice or it happens because of your org structure One way or another it will happen

ivan_gammel 3y ago

Client-side rendering has a lot of benefits not mentioned in the article. 1. Adaptive design: it’s easier to adjust user experience to the client device capabilities. SPA frameworks take the job of ensuring browser compatibility, but it’s not just it. 2. Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts). 3. Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. SPA can auto-retry, just showing the spinning wheel longer. Browser will show the timeout page, and who knows if the backend can correctly recover on refresh.

tonyedgecombe 3y ago
>Better UX for slow networks Yet the reality seems to be very poor UX from SPA's on a slow or intermittent connection.
leosanchez 3y ago
> Better UX for slow networks Don't you think the case can be made against SPA's w.r.t slow networks ? Angular, react add hundreds of KB's to frontend bundle which give bad UX especially in slow networks
- jauntywundrkind 3y ago
  But then after 20s loading or whatever, it's cached and your experience every moment thereafter & if you return later is speedier. If the app has optimistic updates, actions may even feel instant. If your app really cares, it'll have an offline mode/be local-first. Then you you pretty much need an SPA or some kind of heavier front end.
  - zelphirkalt 3y ago
    After 20s ... you have lost 50% of your visitors, because they think the damn thing is never going to finish loading on their connection and you will have triggered connection loss anxiety on multiple levels. Also this is assuming, that one does not want to take all the things of that website and burn them after use, which is not a safe assumption to make on most websites, considering all the ads and trackers on today's typical websites. An offline still working app sounds great. Unfortunately very few aspire to reach that point. Most already break to various degrees when you hit the back button.

davidsergey 3y ago

The article talks a lot about technology choice, but not about given product. I do tend to agree – that SPAs are not necessary, but I would not use this article as an argument. And if somebody would present this article to me – I would not take it seriously. The fact that author is using very interesting language when refering to React and Angular does not help. I'd love to hear customer-centric or product-centric reasoning. * Don't use SPA because customers hate it when you change entire app on them. * Don't use SPA, because customers of our particular product require faster turn-around. * Don't use SPA, because they are harder to test in our organisation.

simonhamp 3y ago
Thanks for the feedback. Noted

kgeist 3y ago

>Your back-end and front-end are always coupled. So trying to split them in anything but the most extreme circumstances is an exercise in futility. >If your back-end team want to move in one direction, they've got to align with the front-end team. We have different backend and frontend teams and I can't agree that it's futile or hard to decouple etc. The only "coupling" which we have is the public API of the backend. Before a product or a feature is started, the teams design and agree on the API between the backend and the frontend, as part of our overall architecture design process (doesn't take more than a couple of days of 1-2 senior engineers if it's a big feature). After that, the two teams work completely in parallel. The frontend team has a framework which allows them to test the UI without the backend ready (using mock API). The backend team checks their API implementation using end-to-end tests. When the both teams are ready, we have the integration phase to see if it works together. Sure, often some edge cases are found and the API has to be changed a bit, but overall for me it has been quite a pleasant experience.

thomaslord 3y ago
I think there are pros and cons to this. I can definitely see how, in a company with larger teams, separating the frontend and backend can help with productivity. On the other hand, I'd wager that decoupled applications are less efficient with API calls something like 90% of the time. When I build a fully-coupled application, loading any given page after the CSS/JS files are cached requires a single HTTP request which always includes exactly the data that's required for that page. When I've built decoupled applications, I frequently end up doing 4+ HTTP requests to load various pieces of data that don't make sense to include in the same API request. In some cases these API requests will depend on data from a previous API request, which leads to multiple sequential round-trips before the page is fully usable. I started out at my current job working on a fully coupled system that's basically as "legacy" as you can get, and eventually started modernizing it - as part of that process, we decoupled the frontend from the backend. At first it felt more productive simply because it wasn't the old system and the new frameworks actually had documentation, but once I compared it to building a coupled system with modern frameworks I realized the coupled system made me much more productive. I'm currently the only developer at my company, though, so I feel like I'm probably the perfect target audience since I don't have to worry about team coordination at all.

douglee650 3y ago

Modern frontend frameworks smear technical concepts into the presentation layer; for example, understanding of hydration becomes integral to semantic presentation of content and therefore an overriding concern; "developers aren't cheap!". Then we are reduced to two outcomes — developers become more design-aware, or designers become more dev-aware. Both are unicorn hunts, what do?

simonhamp 3y ago
I don't think this has anything to do with design tbh. You have developers who are comfortable with HTML/CSS/JS and those who prefer to stay clear of it. A lot of those HTML/CSS/JS folks happen to also really enjoy (and are great at) PHP/Ruby/Python etc - not so unicorn-y

ebiester 3y ago

I believe this is a cultural argument mascaraing as a technical one. The honest truth is that we have had front end and back end developers for as long as the web has been around, and before that. Your "full stack" developers are most often back end developers who begrudgingly can put together a less complex front ends with very little understanding of what makes a front end good to work with. Your "full stack" front-end preferring developers get drummed out because the back end developers conflate being good at back end concepts with being good at programming in general. There is a definite back-end bias with developers who do not specialize in web or mobile front ends. For some applications, that's fine. However, back end developers build the back end frameworks and do not think about what makes a great experience for developing more complicated user experiences. In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks.

simonhamp 3y ago
You can have great front-end experiences and great front-end-back-end developer relations without an SPA
- ebiester 3y ago
  I'm talking about a great front end developer experience. Rails was crap. Spring * was crap. None of the back end frameworks came close to thinking in abstractions - code reusability was an afterthought at best. Ask yourself, why was there never a Rails component library? Because Rails made abstraction difficult in the front end. Nobody did a good job here.
acdha 3y ago
> In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks. Partially, but let’s not pretend our field is more rigorous than it actually is. Most it was following fads: the cool kids at some big tech companies were building HUGE apps with tons of logic as SPAs and a lot of people wanted to say “us too!” without considering how similar their apps are or comparing staffing. The natural arc I’ve seen is that teams who didn’t pick an SPA for solid technical requirements end up delivering results which are no better at considerably slower speed because they’re supporting a lot of non-domain complexity and still end of changing their backends in lock-step with the front end. That tends not to leave time for things like accessibility or performance.

redcobra762 3y ago

Two thoughts: Firstly, when you provide a normative assertion, at least couch it in positive terms. “If you want X, then you should do Y.” That way people at least know the tradeoffs you’re opting them into. I really can’t tell what trade offs the author is proposing are better for me. Secondly, if you can’t build a system that actually decouples the frontend and the backend, that’s a “you” problem, not a technology problem. I have successfully designed and implemented many APIs that operated completely independently of the UI, allowing both the UI and power users to interact with our platform through a shared service. I do get so tired of people presuming their specific issues are everyone’s issues. I have zero problem with the tooling of an SPA, my ability to customize is increased, not decreased, when I use an SPA, and when I’m working with other people, they often prefer not having to think about the whole stack, which makes them happier. This is one of those articles you read that shows up “unplugged” from the culture in which it originated. The author demonstrates the value of talking to others in a given field, and the pitfalls that one can get trapped in when one doesn’t socialize enough professionally.

jabradoodle 3y ago
How can it operate completely independently if the front end requires data in a format it understands to perform logic on.
- redcobra762 3y ago
  By providing the data in a format that any consumer can understand. JSON, very often.
  - jabradoodle 3y ago
    But your front end is still coupled to the structure of that JSON, which is often fine, but it is coupling
    - redcobra762 3y ago
      “Couples” means two-way. Of course your front end will depend on your backend, the problem arises when they become interdependent; when you can’t develop one without making changes to the other. In this sense a frontend and a backend can be entirely independent, and in every sense the backend should be independent of the frontend.

cpursley 3y ago

Post mentions Livewire & Hotwire but totally misses the real star (and OG) of this type of architecture: Phoenix LiveView ^ Elixir is an order of magnitude more scaleable, easier to operate and cheaper than any of these other solutions.

pier25 3y ago
What about DX? Would you say Phoenix is better than Laravel?
- cpursley 3y ago
  I haven’t used Laravel (I hear good things). But Phoenix is voted as most loved web framework fwiw: https://curiosum.com/blog/phoenix-framework-guide https://curiosum.com/blog/phoenix-framework-guide
pritambarhate 3y ago
Only if one knows Elixir which is tiny percentage of developers.
- cpursley 3y ago
  Def use what you know. But you can learn the basics of Elixir in two weeks. The payoff is worth it.

paxys 3y ago

This article (and all others like it) always ignore the fact that mobile exists. Nowadays "front end" isn't just HTML pages being rended on some browser but also entire iOS and Android apps and maybe several others. Those APIs you think are an overhead are actually necessary regardless, and after that it's your server rendered HTML that instead becomes an additional burden to maintain. A SPA with dedicated front end engineers using the same APIs as the mobile ones is the most sensible approach for most apps.

simonhamp 3y ago
I've done this. I spent six years building and maintaining an API platform to support apps and websites. I'm fully aware of mobile and the need for those APIs. They just weren't sufficiently overlapping to be of any use to an SPA. You need a whole slew of separate endpoints and behaviour, so it may as well not be an API - just make it a server-rendered monolith and move along.
- paxys 3y ago
  Why would your mobile apps and browser client be so diverging that you need a completely separate set of APIs for both?
  - simonhamp 3y ago
    Because they were entirely different applications. It was an API platform for a suite of applications There was almost zero crossover in functionality
    - paxys 3y ago
      Ok sure, but 99% of applications out there do not fit this description.
      - simonhamp 3y ago
        If you're building an SPA that's identical to a native app, I think someone in the exec team is making poor decisions Either make a web app or a native app... don't do both

superkuh 3y ago

It reads like this article's unstated premise is that it's about what you should do in situations where you aren't in control, are being paid to do the things, and working with other people in the same situation. But why write articles about what we're forced to do for money? That situation is always borked and we wouldn't be there unless we were being paid. Who wants to think about and do work during non-work free time? Yuck. Lets see some articles about what human people, not people hired to do corporate person's bidding, should do. In this context the case for SPA is even more diffuse. In fact, all the arguments about synching frontend and backend don't even makes sense: that kind of thing is cargo culting. Human persons when operating of their own free will working on their own projects should definitely not start with SPAs. They shouldn't even start with javascript dependent frameworks. Just put an HTML file in a directory.

simonhamp 3y ago
I'm a freelance consultant and a human person. I advise companies, especially early-stage startups, on this stuff. I'm writing about what I see, which is hundreds of hours being wasted on triaging bugs, meetings trying to align small teams, and decision-makers simply following trends.
- superkuh 3y ago
  I get that, you write what you know. But you're literally saying it's a thing you do because you want money to live. It's not something you're chosing to do as a human person. We're all technically human (except the corporate persons) but if you're doing something for money for companies then you're operating with those motives and preferences in mind; motives and preferences that apply to corporate persons, not human persons. I know thinking in terms of those corporate needs is the default on HN, but it doesn't have to be, and shouldn't be. We're all human people too.

endisneigh 3y ago

It’s always amusing how people compare crappy spa vs great traditional site. A well done spa is far superior. Offline support, caching, adaptive layout, etc. it’s not even close. That being said, barring things like offline support the two are equivalent functionally. Use what you know.

simonhamp 3y ago
You can get offline support without an SPA. Of course, that may mean replicating some of your back-end behaviour in JavaScript, but that doesn't necessitate building an SPA, or the whole app in JS. Please do share which crappy SPAs you're thinking of

pjerem 3y ago

For what it’s worth, I started my current project with the good old Django framework. I haven’t touched it for mostly a decade and my god it’s just a pleasure. You just write your domain code and the framework handles everything else. But more importantly, Django don’t try to be original or to force you into a paradigm, it just solves and abstract away the real life problems of websites. There is basically 0 boilerplate. Add some htmx for the few things you want dynamic and you’re done. Now, I prefer typed languages but why haven’t we something like Django (or Rails) in typescript ?

reducesuffering 3y ago
Django in Typescript is Next.js / T3 stack which I much prefer to Django
- pier25 3y ago
  Not even close. Next is pretty barebones as a backend framework compared to mature solutions like Django, Rails, or Laravel.
- pjerem 3y ago
  > Django in Typescript is Next.js / T3 stack I’m sorry but no. In Django, every parts of the framework are tightly integrated in smart ways to make you more productive. You can write things like "redirect(entity)" to redirect your user to the view that shows your entity. Displaying a form to create/edit an entity is a few lines of code… I understand why you would prefer something else but you can’t say that it’s Django.
  - reducesuffering 3y ago
    > You can write things like "redirect(entity)" to redirect your user to the view that shows your entity. You literally have a redirect() in next.js routing you to another URL https://nextjs.org/docs/app/api-reference/functions/redirect https://nextjs.org/docs/app/api-reference/functions/redirect > Displaying a form to create/edit an entity is a few lines of code… A form is not a particularly hard example in any sized app. https://nextjs.org/docs/pages/building-your-application/data-fetching/forms-and-mutations https://nextjs.org/docs/pages/building-your-application/data... Now do Django with any sort of frontend that isn’t just html and adhoc js or htmx. DRF is very 2005 syntax “basic crud that’s it” Then trying deploying Django, a process that will take 50x what the form will. https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-22-04 https://www.digitalocean.com/community/tutorials/how-to-set-...

simonhamp 3y ago

I feel like a lot of the commenters here have missed the point... in the title it says you shouldn't start with an SPA. I never say "don't ever use an SPA," just that I feel—more strongly than ever—that the kinds of environments that call for a true SPA are getting further and further towards the extreme. You should do whatever you like. As always, there are trade-offs. For me it's becoming clearer that the trade-offs are heavily stacked towards keeping my front-end and back-end more tightly coupled.

lelanthran 3y ago
Just a nit on your article: I think you meant 'retch' not 'wretch'.
- simonhamp 3y ago
  You're absolutely correct. Thanks

from-nibly 3y ago

In my experience spas have a much better ux. Have you guys used Jira before? It's actively painful and there even is some local interactivity. But whenever you need a page wide rerender it makes me twitch. Same thing with aws when navigating between accounts/products. Also having a spa doesn't mean you need to have separate frontend and backend engineers. But it does allow various value streams to leverage each other's APIs in their own front ends.