14 ms·

A single-page app is almost always worse than a multi-page app

289 points by 1gor 8y ago

deleted 8y ago
[deleted]
citeguised 8y ago
I want to hug Greg for this article and especially this paragraph at the end: "Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React."
- eropple 8y ago
  You can totally do that, but I write React for the entirety of an app because it means not having two separate development flows for different features. Making my login page driven by HTML and postbacks, rather than a straightforward REST(-ish) API talked to by an SPA, makes it nontrivially more difficult to establish the kind of separation of concerns necessary to then build a mobile application out of it (and as it happens, React is pretty useful there with React Native).
BWStearns 8y ago
I get where the author is coming from but if your frontend team is already proficient at making SPAs then going SPA from the start actually simplifies things and buys you room to maneuver. The backend team can focus _just_ on the server side and the frontend team can just request the needed APIs. Additionally you can now reuse the API you just built with other systems. If your Widget Management Interface™ is a MPA and you your Automated Widget Building Factory™ to know when to produce more widgets then you just got a new project. If it's an SPA then you just give the Factory a user and have it use the API.
decasia 8y ago
So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)." I find the ad hoc jQuery+endpoint tangle much harder to reason about than something built with a front end framework and a more uniform API.
- bauerd 8y ago
  This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).
  - basch 8y ago
    is that true? googles auto-suggestions are rendered server side, as you type in the field they update. (unless I am mistake, but I thought that was the case)
    - drewmol 8y ago
      I think it's a combination of local cache immediately, followed up by a server response
    - icebraining 8y ago
      That's not really "rendered" server side; the data is fetched from the server by JavaScript in JSON form, then dynamically inserted into the DOM.
  - paulie_a 8y ago
    Honestly no it wouldn't suck and from a end user perspective for a calendar. It is actually far superior. Granted this is only my personal opinion. There seems to be this desire to overcomplicate the front end when simple solutions work quite well. Granted they don't have all the catchy buzzwords. But they make for a better less bug filled solution.
    - bauerd 8y ago
      Calendar UIs commonly demand stuff like auto-refreshing, datetime selects, drag-dropping items around, resizing those, list goes on. Please elaborate how you'd build a "simple solution" that does not resort to client-side rendering.
rossdavidh 8y ago
I think that the over-applicaton of the SPA architecture is one of those things that in the future will seem obvious, and we will wonder, "what were they thinking"? But when it is what everyone does, it is hard to question. It probably still has a few years before this becomes clear to management at the typical web shop, however.
ehayes 8y ago
Over the past year we replaced an Angular front-end with the author's recommendations: Turbolinks and Stimulus.js. With the pair, our app mostly feels like an SPA, but has the developer benefit of leaning on server-side rendering. The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech.
- SamBam 8y ago
  How does Stimulus compare to Angular? It seemed like a random plug in the article for a framework that appeared at first glance to basically be Angular.
- jhall1468 8y ago
  > The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech. You presented the actual valid argument for the OP's position. If you are a small team of largely backend engineers, using tech you aren't familiar with is probably the wrong solution. Unfortunately, the blog post decided to take a more aggressive stance and made the author just look like a fool.
- ernsheong 8y ago
  Unfortunately, there are too many weird corner cases with Turbolinks. And it doesn't work with certain ad scripts (which ad publishers aren't interested to support Turbolinks).
codingdave 8y ago
Forcing a SPA just for the sake of SPA is overkill. But putting a group of related actions into a single page makes sense. Absolutely feel free to make a separate page for each separate group of UX actions/tasks. But let us not go back to the days of full page reloads on every mouse click.
crazygringo 8y ago
Sorry, but this is just silly and looks at the problem from the wrong end. Of course single-page apps generally require far more development than multi-page. Of course they require more state, more testing, are slower to load, etc. But they also do a million things multipage "apps" can't and, and therefore have the potential to provide a vastly better user experience at the end of the day. In the end it's same tradeoff as literally every other business decision: will the resulting benefits be greater than the costs they incur? My dentist doesn't need a single-page app for their site. Anything complex enough to intuitively be called an "app"... there's a good chance it does.
- eropple 8y ago
  You still have to test a non-SPA app and you still have to manage state--it's just on the other end of the wire. TBH, given the state of modern tooling I'm not sure that SPAs really do require more development (once you have actually bought into the process of using them, which is nontrivial). I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on. I like your division of "site" and "app", and it's the same one I use. The boundaries are definitely fuzzy, but if you're working on it--I think you know.
  - toolz 8y ago
    > I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on. I've never understood this opinion. To me it seems like you're forcing such complexity that you _need_ focused developers. That by definition scales far worse than having all cross functional team of developers that can work on the view layer and the data layer (by virtue of the view layer being easy enough all developers can understand it). It's touted quite frequently ime that it's better to have front-end engineers and back-end engineers and that to me just feels flat on its face wrong. I'm not claiming there are no benefits to SPAs, of course. I'm just saying I don't understand the opinion that claims it scales better with development cycles.
    - 8y ago
alexmuro 8y ago
tldr; I've invested a lot of time becoming very good at rails and I don't want to learn a new appraoch to solving a problem I am already very good at solving. The quality of an end product doesn't have as much to do with tools as people would like to believe.
poisonborz 8y ago
While there are some valid concerns in the article, it mostly is just a rant against SPAs, which seem to be unfamiliar and subjectively disliked by the author. As with stacks, this is highly team-dependent. I for one do not crave for the time of constant back and forth between backend-frontend mindsets and stack lock-in because of rigid query/rendering requirements. This may not work for the author's team of mostly "backend-mindend" devs who wish for more control over output, but is much preferred for a more diverse set of members (or especially departments).
- t_fatus 8y ago
  Totally agree with you. There is a huge benefit having a clean API which works for a variety of clients (native / mobile / desktop) and a corresponding variety of team members instead of maintaining 2 different view sets on your backend, without even talking of the specific issues you can find yourself in in web development (browser specific features / inputs / styles / ...). And you still can't do any real native apps.
joshwcomeau 8y ago
The justified text on this page makes it so hard to read on mobile.
sbr464 8y ago
I’m curious if anyone has done any analysis and seen any patterns emerge around days of the week >> certain popular HN topics (controversial/rants/per category)? Kind of similar to the analysis you find around best times to post etc. I feel like I see type system related posts closer to Fri/Sat. I think we could make a nice color coded calendar or almanac to celebrate these more. Maybe even create more formal holidays. I’m inspired by the Giant Man radio interview[0] I heard on NPR this last weekend. Highly recommend it, by Hillary Frank. [0]https://www.thisamericanlife.org/351/return-to-childhood/act-four-0 https://www.thisamericanlife.org/351/return-to-childhood/act...
madmaniak 8y ago
SPA done properly is much simpler than classical, well known and established ways of making web applications. The only issue is in misleading "best practices".
- lotyrin 8y ago
  What I don't get is why these conversations try to pretend that "best practice" is a single point, making huge implicit assumptions about the skill level and practices of the host organizations... Things which almost always have larger force multipliers than the wider space of "what options for this (theoretically) exist in wider industry". If I have a team of apes slapping keyboards that know Perl and don't understand finer points of OS/servers/state-management very much and see JS as form of evil, then yeah... I'm going to have an MPA where everything complicated happens in a CGI Perl backend that gets wiped clean between every request and probably hand-roll a little bit of turbolinks for them so they don't have to in the spots that will benefit from that. If I have a team consisting of a single perfect crystalline entity that exists out of time and can pluck the correct solution out of the set of all possible solutions and just start banging out source files in alphabetical order, but BA is staffed by two-headed barbarian ettins that change their mind mid-sentence and can't produce static documentation then we're going to have to account for that least common denominator when it comes to our project management style -- super-iterative... maybe kanban, crystal boy banging out a set of feature branches and staging environments for them with big demos meetings of "so.. kinda like this?"
thesimon 8y ago
>An MPA renders a 500 page upon error and that's it. However, an SPA needs to detect errors in the client code and then update the user interface accordingly. Again, busywork required to regain what MPAs offer out of the box. Is that supposed to be a downside? Just showing a 500 page isn't really a great UX, the SPA experience is probably a lot better (think preserving of unsaved data for example).
- Technetium_Hat 8y ago
  I am not arguing against SPAs, but to prevent redownloading common page elements (menu bars, footers) you can use web components. I recently built a website using web components for this purpose (official implementation of the university's official theme) and it was a good experience. Proper CDN caching means you only have to download them once.
- dagss 8y ago
  Then you go back to the point made in the beginning of the article: Is the better UX during 5xx worth the extra investment? Does it directly drive more revenue than what it costs in developer time? I would argue that in most situations the business is better off using 10 hours of engineer time working on some source of 5xx, than 10 hours making sure the error has good UX. Problem with SPA made here is simply that there isn't an easy "good enough" solution like you have for MPA, it is either good ux or nothing. (I don't know if that is true or if it is just that SPA devs will always insist in good ux even if it doesn't improve company's bottom line)
  - jhall1468 8y ago
    User Experience is not just about bottom line, and approaching it from that position is just terrible. People that have to interact with terrible UX don't like those interactions. A 500 error with a bolded text saying "an error occurred" is going to make me never return to your site, because a reasonable user experience for that page doesn't require 10 hours of work.
    - dagss 8y ago
daliusd 8y ago
JWT is encoding standard for tokens. Bearer tokens can be JWT tokens (and usually are). Has anyone idea what author had in mind with bearer tokens?
- detaro 8y ago
  From the context, any bearer token that's tied to a session with backend state, in contrast to having no backend state, securing state through the JWT validation, with the listed downside of having no way of revoking it.
yogthos 8y ago
This seems really misinformed and written by somebody who has no idea how SPAs work. The SPAs approach results in much cleaner and simpler architecture in practice because you have clear separation between the client and the server. It also forces you to think about the API up front allowing you to create other clients, such as native mobile apps, later on. The SPA approach also helps with statefulness, because it allows you to keep the UI state on the client where it belongs. The UI becomes much easier to reason about because you're not trying to keep state of the server and client in sync. Meanwhile, the server can just be a set of service calls the UI queries when it needs data, and doesn't need to store any state about it. This directly helps with horizontal scaling where you can spin up more servers and balance across them. While SPAs can have a larger initial Js download, they can be a lot more responsive overall because you don't have page repaints, and you fetch data as you need it. Testing actually becomes easier because your front-end is decoupled from the backend. You can test it in isolation, and the amount of statefulness is dependent on the complexity of the UI as opposed to whether its implemented SPA style or not. An equally complex UI implemented using traditional server-side rendering will likely be harder to test in practice. Also not sure why authentication needs to be any different with SPAs. You can authenticate exactly the same way as if you did server-side rendering. >Let's illustrate this with an example: we're building an e-commerce site that has a list of categories. We need to update the list from time to time. In an MPA, the list is updated on every page load. That's not the case in an SPA though. Why wouldn't it be? >In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization. Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs. >Single-page apps are much more expensive to build than multi-page apps. In most cases, there is no business reason to choose this architecture. Perhaps this is just a problem with the particular stack the author is using, and they're extrapolating this to be a general problem?
- lucaluca1453 8y ago
  >>In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization. >Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs. I think the author means serialization of models into JSON for your API, which is non-trivial in frameworks like Django - you have to pick which model fields to use, how to represent foreign keys, etc. In Django you can just pass that model object into a HTML template processor (view) in a MPA.
parski 8y ago
Oh. He's talking about websites.
k_bx 8y ago
I've just started implementing a website which would look like an ideal fit for a non-SPA (online library), but since I am using my own spare time on it, there's no way I will go back to the old non-SPA development. Most of the problems are solved by using Haskell+Elm+Generating the API types (sharing the code for their encoding/decoding). Testing the backend is way easier through API, and testing UI is better done with hands/eyes.
- oever 8y ago
  The routing and type safety from url to database that Yesod (Haskell) offers makes it simple to make MPA than an SPA. You can still add an API to test the backend. https://www.yesodweb.com/ https://www.yesodweb.com/
  - k_bx 8y ago
    Yesod is great, and would cover most of my app, but then you get things like "search field which filters as you type" and other UI elements (even as small as "like" button) and you get into a territory where you stop having a good time.
Driky 8y ago
I find the author forget that those problems arise with each new paradigm and each time tools evolves to resolves those problems.
3dfan 8y ago
How would something like this work as a non-single-page-app: https://www.productchart.com/laptops/ https://www.productchart.com/laptops/ Would the user have to chose "32 GB Ram", hit a submit button and wait for the page to reload with the matching laptops?
- rocky1138 8y ago
  I can't decide whether you're joking or not. That's how the web has worked since its inception until just a few years ago when SPAs appeared on the scene. I don't think SPAs are always a bad idea, but they sometimes are. For instance, I've gone back to HTML Gmail and I love how fast it is compared to the JavaScript mess the main product has become.
  - 3dfan 8y ago
    Not joking. It was a rhetorical question. What I mean: This is an example where a single-page approach is better. I agree that there are many single-page sites that would be better if they were multipage. But I'm not sure the "almost always" is justified. The title of the article is even stronger "The Architecture No One Needs". But you and I clearly can bring up examples where it's an architecture that does make sense.
    - cpeterso 8y ago
      Why is this product chart SPA better than a simple MPA? The zoom animations do not add any value to the user experience. Also, with this SPA, you can't bookmark or a share a URL to a particular hardware search, so information and usability is lost. The URLs could be fixed, but the SPA has to explicitly manage the page history. An MFA gets that for free.
      - systematical 8y ago
        As a developer I appreciate it more, perhaps users might find it slicker. However, I go back to something another user posted "The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are." And that is the correct answer here. As the other poster stated, there are tons of applications that don't need to be an SPA. Think of damn near every admin section of a companies intranet or whatever. That thing just needs do the job, run fast enough, be easy to scale and develop on and hopefully not look like an eye sore.
hiram112 8y ago
This is where skill and experience come in. Should huge wizards and complex forms be constantly sent back to the server and rendered as each bit is filled in? Of course not. But if you have a basic CRUD app with a big dashboard, create route, edit route, view route, etc., it's a hell of a lot cleaner to break up each one of these main features into mini SPAs that cleanly refresh the state on the server when moving from one function to another. Otherwise, you're constantly making duplicate calls to ensure you've got the data you want as you really can't be sure if some previous click from one of dozens of in-memory widgets has stale or incomplete data. At least that's been my experience working on a few legacy apps written in AngularJS and, God forbid, JQuery. At that time, an Asp.Net or GWT app would have probably been easier to maintain as the duct tape increased over the years. Maybe React and Vue allow for cleaner architectures, but older apps were a pain.
jordache 8y ago
bull crap. The complexity of state management must exist within an app. Either it's stateful server side or stateful client side. Going away from the SPA pattern doesn't save anything in this regard. The only unique complexity SPA brings to the table is route management, which can get confusing, and a non-trivial learning curve.
funfunfun 8y ago
Hahaha. Its nice HN will give a voice to Neo-Luddism even if its content borders on trolling
devwastaken 8y ago
Completely Disagree. SPA's are about making your 'site' like a GUI application. If you had to use Apache to navigate pages in visual .net or QT that'd be crazy. SPA's also benefit from static caching and serving. You do not always need to have the pages being served from your origin, but can be served from a much cheaper source like Cloudflare or even a different origin.
MattyRad 8y ago
I will add that since the learning curve is substantially higher for SPAs, non-technically proficient front-end people (designers or folks who just do HTML/CSS) will constantly bastardize your app; creating 1000 line components, splicing in jQuery, inadvertently creating elements with duplicate IDs. It's been a headache for me at times, and I often feel like I'm the maid cleaning up after people. It's understood that this can also happen in an MPA, but I think the blast radius is much smaller.
LiterallyDoge 8y ago
The user experience is always the number one problem of any application. Implying that you don't like building great products because you are lazy says more about you than the state of the front-end world.
jho406 8y ago
You can have the best of both. The simplicity of multipage apps with the feel of SPAs. Turbolinks is one example that comes to mind. Or if you want the full power of React, Redux, AND the simplicity of Turbolinks/PJAX. You can use https://jho406.gitbook.io/breezy/ https://jho406.gitbook.io/breezy/ which is Turbolinks for React Redux Rails, you can build SPA without APIs, just by treating JSON as a navigational format. Full disclosure, I'm the author and I've been trying to get some feedback on the project.
citilife 8y ago
Turbolinks have to be my favorite part of Rails, I've used them with other applications as well, the idea that you just load partials (without a huge framework such as React) is pretty nice.
mschaef 8y ago
As much I tend to be sympathetic to the no-SPA cause, it's easy to run into requirements that exclude MPA's. Incrementally updating a page just has too many potential performance and usability advantages. (Not to mention that an SPA can potentially be given some offline capability to accommodate a marginal network connection.)
osrec 8y ago
Could not disagree more with the article. In my experience, well designed SPAs are almost always better and lighter than multi page apps. The fact that a lot of SPAs are implemented quite poorly is a different story. In actual fact, whether a web app is single or multi page is merely an implementation detail; in both cases we're just passing information back and forth between client and server. With multi page apps, you transmit and parse full markup each time. With SPAs, you do it once and then mutate as needed. In that sense it's more efficient and I can't see why that's a bad thing.
yummybear 8y ago
Most of the issues listed are either issues with MPA's as well or optional for SPA's. There are plenty of MPA's with slow first time loads for instance.
okal 8y ago
At my current workplace - as a deliberate design choice - and last one - organically "discovered", but deliberately maintained - we've tended towards building user facing products as collections of smaller apps sharing a backend, rather than typical SPA (Single Page Application) architecture What that means in practice is that: 1. Routing is always handled server side. The less frontend state (IMO/IME) the better. There will be the odd bit of pushState where appropriate, but no actual full-on routes. 2. Whether to render content server or client side is determined on a case by case basis. It's often easier to build HTML using whatever templating system your backend tooling provides than build a REST/GraphQL endpoint for a component to consume. 3. You can introduce React/React-style programming piecemeal to a team with varying levels of experience. Everyone on a team (with varying degrees of frontend skill/experience) can be productive from day one. Does anyone else do this?
- bunderbunder 8y ago
  Another potential benefit is reduced toolkit lock-in. Migrating a bunch of smaller pages one at a time is pretty doable. Migrating a large SPA without disrupting business could be like trying to pass a camel through the eye of a needle.
arendtio 8y ago
> There are cases where an SPA makes sense but this is a topic for another article. Without that second part, this is just a trite rant against SPAs.
deleted 8y ago
[deleted]
ravenstine 8y ago
I don't really agree with the author that SPA's are almost always worse. Although sometimes they're gratuitous, as was the case with a lot of early Angular apps where it was pretty clear that the developers thought they were being cool by making way too many things behave "dynamicky" for the sake of having their work appear more like an app than a site. On the other hand, there are plenty of times where a multi-page app is just fine. If that's the tool that works best for you, then by all means use it. The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are.
- systematical 8y ago
  >The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are. This is the correct response, but among developers you will have zealotry on this topic. I personally find MPAs easier, but that is based on my work experience and my perception of the learning curved involved in things like React and Angular (I found VueJS to be far easier to learn). I do like the idea of thinking about an API from the get-go with an SPA, but do all applications need an API? Nope. The amount of applications in the business world that will require both a web implementation and an iphone/android app is actually quite small, isn't it?
Zooper 8y ago
Alternate title: the front-end sucks now because we have too many options for doing generally the same thing, and they all aren't compatible with each other, but my way, the way I first learned, is best, and something about functional programming even though UIs arbitrarily necessitate or do not necessitate state. I, personally, place blame on WC3 for this state of affairs, as Web components should have solved the UI interoperability problem, observed objects were dropped which regardless of what one thinks of them (I think a trie is better) would have unified state management clearly (replaced by Proxy? yeah, I see everyone using that string-only thing for state), and various other specs should have solved most of these issues, but I guess they were too busy making people leave their org over DRM, rather than making a useful, consistent, easily-produced internet. Who needs standards when all of the for-profit board members have their own un-interoperable libraries?
casper345 8y ago
> For instance, if you’re building a chat box then there’s really no need to implement your login page in React. Wrestling with this idea. Been using create react app for most of my projects that arguably do not need it. But the development is so much faster and easier to manage than traditonal html/css webpack
calibas 8y ago
If I let the browser handle internal links so everything reloads, is my SPA now an MPA?
n1tranquilla 8y ago
This is a load of garbage.
barbecue_sauce 8y ago
I didn't really learn web development seriously until the age of SPAs, so I find SPAs much easier to reason about than multi-page. That said, I'm not really sure that a UI which is mostly fields and forms really warrants a front-end framework unless its an extremely complex, stateful flow.
mekoka 8y ago
I'm a long time server-side developer who've been working on the front-end for the past 6 months. I don't agree with this article. I think its author has a significant misunderstanding of SPAs and overstates some of the potential issues. Having built both type of applications at varied level of complexity I absolutely don't agree with the notion that SPAs are necessarily more expensive than MPAs. I'll address a few of his points, but most, if not all, of his claims can similarly be refuted. Statefulness: Few people would build an SPA on top of a stateful backend? Most SPAs query an API which nowadays will more than likely be hypertext driven (read stateless). The user authenticates, gets an access key, then serves that access key along with each subsequent request to the API that needs it. The server does not keep a session around. It receives the query, does its job in the confines of what is requested and serves back a response (likely in JSON). That's more or less it. There's very little state involved here. Testing: Vague unsubstantiated claims. Why make backend and frontend talk to each other when mocking would do just fine. Performance and network latency: Has anyone been using an SPA recently and had this as their main problem? If your client is incessantly polling your API, then it's a sign that either your API is not designed well enough to address the problem domain, or you need to employ a caching mechanism on the front. There's no cookie cutter way to architect an API. If your client is more likely to query and use 10 items from a collection, don't force it to make 10 requests, provide a facility to bundle them up into one. On the front-end most frameworks have satisfactory libraries to handle state and cache management. Slow first time load, multiple times per day? Stop updating your live bundle multiple times in a single day. Authentication with JWTs: JWTs are not an SPA requirement, they're just one of many approaches to authentication. I don't use them and don't see the point of them in most apps that I've built. If you do use them and need to keep track of them (maybe because you'd like to be able to invalidate them), store them in something fast like Redis on the server. State updates: The JavaScript ecosystem has excellent caching facilities, that can automatically poll and update resources upon a timeout. It's indeed not rocket science. Error Handling: You catch the error from the http response and call your handler. That's practically like muscle memory whenever one does an http request. client.get({url}).then(resp=>{ // handle response }).catch(error=>{ errorhandler(error) }) No busywork there and probably much more user-friendly than that default error message that will be served by nginx (if one truly wants to stick to such a "no busywork" philosophy). The rest of the article can similarly be addressed. My conclusion is simply that if you want to maximize your cost efficiency, build a team that is familiar with their tools. If all your developers have done and are familiar with are MPAs, then yes, it might be more costly to build an SPA for them at first. I should know. I went through that phase at the beginning of my recent JS foray. Doing anything was slow and would've taken me a fraction of the time by simply playing around with Jinja on the backend. But fast-forward a few months, after immersing myself a bit more with the ecosystem, I cannot imagine reverting to that approach to build anything more complex than a simple data driven app. Emphasis on the simple.
CosmicShadow 8y ago
SPAs: reinventing the browser in the browser, and you get the bonus of doing it all in JavaScript! I hate SPAs, so much more complexity and work. In MPAs you can still use JS and AJAX for a better experience, but SPAs just have so much needless extra work and are harder to maintain. They are also frustrating to use. They can be better to use when done well, but you don't often see that unless it's from someone quite big.
dapreja 8y ago
> Error HandlingAn MPA renders a 500 page upon error and that's it. However, an SPA needs to detect errors in the client code and then update the user interface accordingly. Again, busywork required to regain what MPAs offer out of the box. I'm no gilded dev, but 5 years back when PHP wasn't avoided like the black plague we would still need to update user interface handling these internal server errors. It's judt good design practice. I more or less agreed/understood with the writer up to that point. Everything else past this just sounded like a argument for argument's sake.
systematical 8y ago
This was a rant, but I did learn about turbolinks, so its a worthwhile read for me. The salt in here is strong.

289 points by 1gor 8y ago

deleted 8y ago

[deleted]

I want to hug Greg for this article and especially this paragraph at the end: "Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React."

eropple 8y ago
You can totally do that, but I write React for the entirety of an app because it means not having two separate development flows for different features. Making my login page driven by HTML and postbacks, rather than a straightforward REST(-ish) API talked to by an SPA, makes it nontrivially more difficult to establish the kind of separation of concerns necessary to then build a mobile application out of it (and as it happens, React is pretty useful there with React Native).

BWStearns 8y ago

I get where the author is coming from but if your frontend team is already proficient at making SPAs then going SPA from the start actually simplifies things and buys you room to maneuver. The backend team can focus _just_ on the server side and the frontend team can just request the needed APIs. Additionally you can now reuse the API you just built with other systems. If your Widget Management Interface™ is a MPA and you your Automated Widget Building Factory™ to know when to produce more widgets then you just got a new project. If it's an SPA then you just give the Factory a user and have it use the API.

decasia 8y ago

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)." I find the ad hoc jQuery+endpoint tangle much harder to reason about than something built with a front end framework and a more uniform API.

bauerd 8y ago
This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).
- basch 8y ago
  is that true? googles auto-suggestions are rendered server side, as you type in the field they update. (unless I am mistake, but I thought that was the case)
  - drewmol 8y ago
    I think it's a combination of local cache immediately, followed up by a server response
  - icebraining 8y ago
    That's not really "rendered" server side; the data is fetched from the server by JavaScript in JSON form, then dynamically inserted into the DOM.
- paulie_a 8y ago
  Honestly no it wouldn't suck and from a end user perspective for a calendar. It is actually far superior. Granted this is only my personal opinion. There seems to be this desire to overcomplicate the front end when simple solutions work quite well. Granted they don't have all the catchy buzzwords. But they make for a better less bug filled solution.
  - bauerd 8y ago
    Calendar UIs commonly demand stuff like auto-refreshing, datetime selects, drag-dropping items around, resizing those, list goes on. Please elaborate how you'd build a "simple solution" that does not resort to client-side rendering.

rossdavidh 8y ago

I think that the over-applicaton of the SPA architecture is one of those things that in the future will seem obvious, and we will wonder, "what were they thinking"? But when it is what everyone does, it is hard to question. It probably still has a few years before this becomes clear to management at the typical web shop, however.

ehayes 8y ago

Over the past year we replaced an Angular front-end with the author's recommendations: Turbolinks and Stimulus.js. With the pair, our app mostly feels like an SPA, but has the developer benefit of leaning on server-side rendering. The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech.

SamBam 8y ago
How does Stimulus compare to Angular? It seemed like a random plug in the article for a framework that appeared at first glance to basically be Angular.
jhall1468 8y ago
> The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech. You presented the actual valid argument for the OP's position. If you are a small team of largely backend engineers, using tech you aren't familiar with is probably the wrong solution. Unfortunately, the blog post decided to take a more aggressive stance and made the author just look like a fool.
ernsheong 8y ago
Unfortunately, there are too many weird corner cases with Turbolinks. And it doesn't work with certain ad scripts (which ad publishers aren't interested to support Turbolinks).

codingdave 8y ago

Forcing a SPA just for the sake of SPA is overkill. But putting a group of related actions into a single page makes sense. Absolutely feel free to make a separate page for each separate group of UX actions/tasks. But let us not go back to the days of full page reloads on every mouse click.

crazygringo 8y ago

Sorry, but this is just silly and looks at the problem from the wrong end. Of course single-page apps generally require far more development than multi-page. Of course they require more state, more testing, are slower to load, etc. But they also do a million things multipage "apps" can't and, and therefore have the potential to provide a vastly better user experience at the end of the day. In the end it's same tradeoff as literally every other business decision: will the resulting benefits be greater than the costs they incur? My dentist doesn't need a single-page app for their site. Anything complex enough to intuitively be called an "app"... there's a good chance it does.

eropple 8y ago
You still have to test a non-SPA app and you still have to manage state--it's just on the other end of the wire. TBH, given the state of modern tooling I'm not sure that SPAs really do require more development (once you have actually bought into the process of using them, which is nontrivial). I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on. I like your division of "site" and "app", and it's the same one I use. The boundaries are definitely fuzzy, but if you're working on it--I think you know.
- toolz 8y ago
  > I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on. I've never understood this opinion. To me it seems like you're forcing such complexity that you _need_ focused developers. That by definition scales far worse than having all cross functional team of developers that can work on the view layer and the data layer (by virtue of the view layer being easy enough all developers can understand it). It's touted quite frequently ime that it's better to have front-end engineers and back-end engineers and that to me just feels flat on its face wrong. I'm not claiming there are no benefits to SPAs, of course. I'm just saying I don't understand the opinion that claims it scales better with development cycles.
  - 8y ago

alexmuro 8y ago

tldr; I've invested a lot of time becoming very good at rails and I don't want to learn a new appraoch to solving a problem I am already very good at solving. The quality of an end product doesn't have as much to do with tools as people would like to believe.

poisonborz 8y ago

While there are some valid concerns in the article, it mostly is just a rant against SPAs, which seem to be unfamiliar and subjectively disliked by the author. As with stacks, this is highly team-dependent. I for one do not crave for the time of constant back and forth between backend-frontend mindsets and stack lock-in because of rigid query/rendering requirements. This may not work for the author's team of mostly "backend-mindend" devs who wish for more control over output, but is much preferred for a more diverse set of members (or especially departments).

t_fatus 8y ago
Totally agree with you. There is a huge benefit having a clean API which works for a variety of clients (native / mobile / desktop) and a corresponding variety of team members instead of maintaining 2 different view sets on your backend, without even talking of the specific issues you can find yourself in in web development (browser specific features / inputs / styles / ...). And you still can't do any real native apps.

joshwcomeau 8y ago

The justified text on this page makes it so hard to read on mobile.

sbr464 8y ago

I’m curious if anyone has done any analysis and seen any patterns emerge around days of the week >> certain popular HN topics (controversial/rants/per category)? Kind of similar to the analysis you find around best times to post etc. I feel like I see type system related posts closer to Fri/Sat. I think we could make a nice color coded calendar or almanac to celebrate these more. Maybe even create more formal holidays. I’m inspired by the Giant Man radio interview[0] I heard on NPR this last weekend. Highly recommend it, by Hillary Frank. [0]https://www.thisamericanlife.org/351/return-to-childhood/act-four-0 https://www.thisamericanlife.org/351/return-to-childhood/act...

madmaniak 8y ago

SPA done properly is much simpler than classical, well known and established ways of making web applications. The only issue is in misleading "best practices".

lotyrin 8y ago
What I don't get is why these conversations try to pretend that "best practice" is a single point, making huge implicit assumptions about the skill level and practices of the host organizations... Things which almost always have larger force multipliers than the wider space of "what options for this (theoretically) exist in wider industry". If I have a team of apes slapping keyboards that know Perl and don't understand finer points of OS/servers/state-management very much and see JS as form of evil, then yeah... I'm going to have an MPA where everything complicated happens in a CGI Perl backend that gets wiped clean between every request and probably hand-roll a little bit of turbolinks for them so they don't have to in the spots that will benefit from that. If I have a team consisting of a single perfect crystalline entity that exists out of time and can pluck the correct solution out of the set of all possible solutions and just start banging out source files in alphabetical order, but BA is staffed by two-headed barbarian ettins that change their mind mid-sentence and can't produce static documentation then we're going to have to account for that least common denominator when it comes to our project management style -- super-iterative... maybe kanban, crystal boy banging out a set of feature branches and staging environments for them with big demos meetings of "so.. kinda like this?"

thesimon 8y ago

>An MPA renders a 500 page upon error and that's it. However, an SPA needs to detect errors in the client code and then update the user interface accordingly. Again, busywork required to regain what MPAs offer out of the box. Is that supposed to be a downside? Just showing a 500 page isn't really a great UX, the SPA experience is probably a lot better (think preserving of unsaved data for example).

Technetium_Hat 8y ago
I am not arguing against SPAs, but to prevent redownloading common page elements (menu bars, footers) you can use web components. I recently built a website using web components for this purpose (official implementation of the university's official theme) and it was a good experience. Proper CDN caching means you only have to download them once.
dagss 8y ago
Then you go back to the point made in the beginning of the article: Is the better UX during 5xx worth the extra investment? Does it directly drive more revenue than what it costs in developer time? I would argue that in most situations the business is better off using 10 hours of engineer time working on some source of 5xx, than 10 hours making sure the error has good UX. Problem with SPA made here is simply that there isn't an easy "good enough" solution like you have for MPA, it is either good ux or nothing. (I don't know if that is true or if it is just that SPA devs will always insist in good ux even if it doesn't improve company's bottom line)
- jhall1468 8y ago
  User Experience is not just about bottom line, and approaching it from that position is just terrible. People that have to interact with terrible UX don't like those interactions. A 500 error with a bolded text saying "an error occurred" is going to make me never return to your site, because a reasonable user experience for that page doesn't require 10 hours of work.
  - dagss 8y ago

daliusd 8y ago

JWT is encoding standard for tokens. Bearer tokens can be JWT tokens (and usually are). Has anyone idea what author had in mind with bearer tokens?

detaro 8y ago
From the context, any bearer token that's tied to a session with backend state, in contrast to having no backend state, securing state through the JWT validation, with the listed downside of having no way of revoking it.

yogthos 8y ago

This seems really misinformed and written by somebody who has no idea how SPAs work. The SPAs approach results in much cleaner and simpler architecture in practice because you have clear separation between the client and the server. It also forces you to think about the API up front allowing you to create other clients, such as native mobile apps, later on. The SPA approach also helps with statefulness, because it allows you to keep the UI state on the client where it belongs. The UI becomes much easier to reason about because you're not trying to keep state of the server and client in sync. Meanwhile, the server can just be a set of service calls the UI queries when it needs data, and doesn't need to store any state about it. This directly helps with horizontal scaling where you can spin up more servers and balance across them. While SPAs can have a larger initial Js download, they can be a lot more responsive overall because you don't have page repaints, and you fetch data as you need it. Testing actually becomes easier because your front-end is decoupled from the backend. You can test it in isolation, and the amount of statefulness is dependent on the complexity of the UI as opposed to whether its implemented SPA style or not. An equally complex UI implemented using traditional server-side rendering will likely be harder to test in practice. Also not sure why authentication needs to be any different with SPAs. You can authenticate exactly the same way as if you did server-side rendering. >Let's illustrate this with an example: we're building an e-commerce site that has a list of categories. We need to update the list from time to time. In an MPA, the list is updated on every page load. That's not the case in an SPA though. Why wouldn't it be? >In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization. Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs. >Single-page apps are much more expensive to build than multi-page apps. In most cases, there is no business reason to choose this architecture. Perhaps this is just a problem with the particular stack the author is using, and they're extrapolating this to be a general problem?

lucaluca1453 8y ago
>>In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization. >Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs. I think the author means serialization of models into JSON for your API, which is non-trivial in frameworks like Django - you have to pick which model fields to use, how to represent foreign keys, etc. In Django you can just pass that model object into a HTML template processor (view) in a MPA.

parski 8y ago

Oh. He's talking about websites.

k_bx 8y ago

I've just started implementing a website which would look like an ideal fit for a non-SPA (online library), but since I am using my own spare time on it, there's no way I will go back to the old non-SPA development. Most of the problems are solved by using Haskell+Elm+Generating the API types (sharing the code for their encoding/decoding). Testing the backend is way easier through API, and testing UI is better done with hands/eyes.

oever 8y ago
The routing and type safety from url to database that Yesod (Haskell) offers makes it simple to make MPA than an SPA. You can still add an API to test the backend. https://www.yesodweb.com/ https://www.yesodweb.com/
- k_bx 8y ago
  Yesod is great, and would cover most of my app, but then you get things like "search field which filters as you type" and other UI elements (even as small as "like" button) and you get into a territory where you stop having a good time.

Driky 8y ago

I find the author forget that those problems arise with each new paradigm and each time tools evolves to resolves those problems.

3dfan 8y ago

How would something like this work as a non-single-page-app: https://www.productchart.com/laptops/ https://www.productchart.com/laptops/ Would the user have to chose "32 GB Ram", hit a submit button and wait for the page to reload with the matching laptops?

rocky1138 8y ago
I can't decide whether you're joking or not. That's how the web has worked since its inception until just a few years ago when SPAs appeared on the scene. I don't think SPAs are always a bad idea, but they sometimes are. For instance, I've gone back to HTML Gmail and I love how fast it is compared to the JavaScript mess the main product has become.
- 3dfan 8y ago
  Not joking. It was a rhetorical question. What I mean: This is an example where a single-page approach is better. I agree that there are many single-page sites that would be better if they were multipage. But I'm not sure the "almost always" is justified. The title of the article is even stronger "The Architecture No One Needs". But you and I clearly can bring up examples where it's an architecture that does make sense.
  - cpeterso 8y ago
    Why is this product chart SPA better than a simple MPA? The zoom animations do not add any value to the user experience. Also, with this SPA, you can't bookmark or a share a URL to a particular hardware search, so information and usability is lost. The URLs could be fixed, but the SPA has to explicitly manage the page history. An MFA gets that for free.
    - systematical 8y ago
      As a developer I appreciate it more, perhaps users might find it slicker. However, I go back to something another user posted "The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are." And that is the correct answer here. As the other poster stated, there are tons of applications that don't need to be an SPA. Think of damn near every admin section of a companies intranet or whatever. That thing just needs do the job, run fast enough, be easy to scale and develop on and hopefully not look like an eye sore.

hiram112 8y ago

This is where skill and experience come in. Should huge wizards and complex forms be constantly sent back to the server and rendered as each bit is filled in? Of course not. But if you have a basic CRUD app with a big dashboard, create route, edit route, view route, etc., it's a hell of a lot cleaner to break up each one of these main features into mini SPAs that cleanly refresh the state on the server when moving from one function to another. Otherwise, you're constantly making duplicate calls to ensure you've got the data you want as you really can't be sure if some previous click from one of dozens of in-memory widgets has stale or incomplete data. At least that's been my experience working on a few legacy apps written in AngularJS and, God forbid, JQuery. At that time, an Asp.Net or GWT app would have probably been easier to maintain as the duct tape increased over the years. Maybe React and Vue allow for cleaner architectures, but older apps were a pain.

jordache 8y ago

bull crap. The complexity of state management must exist within an app. Either it's stateful server side or stateful client side. Going away from the SPA pattern doesn't save anything in this regard. The only unique complexity SPA brings to the table is route management, which can get confusing, and a non-trivial learning curve.

funfunfun 8y ago

Hahaha. Its nice HN will give a voice to Neo-Luddism even if its content borders on trolling

devwastaken 8y ago

Completely Disagree. SPA's are about making your 'site' like a GUI application. If you had to use Apache to navigate pages in visual .net or QT that'd be crazy. SPA's also benefit from static caching and serving. You do not always need to have the pages being served from your origin, but can be served from a much cheaper source like Cloudflare or even a different origin.

MattyRad 8y ago

I will add that since the learning curve is substantially higher for SPAs, non-technically proficient front-end people (designers or folks who just do HTML/CSS) will constantly bastardize your app; creating 1000 line components, splicing in jQuery, inadvertently creating elements with duplicate IDs. It's been a headache for me at times, and I often feel like I'm the maid cleaning up after people. It's understood that this can also happen in an MPA, but I think the blast radius is much smaller.

LiterallyDoge 8y ago

The user experience is always the number one problem of any application. Implying that you don't like building great products because you are lazy says more about you than the state of the front-end world.

jho406 8y ago

You can have the best of both. The simplicity of multipage apps with the feel of SPAs. Turbolinks is one example that comes to mind. Or if you want the full power of React, Redux, AND the simplicity of Turbolinks/PJAX. You can use https://jho406.gitbook.io/breezy/ https://jho406.gitbook.io/breezy/ which is Turbolinks for React Redux Rails, you can build SPA without APIs, just by treating JSON as a navigational format. Full disclosure, I'm the author and I've been trying to get some feedback on the project.

citilife 8y ago

Turbolinks have to be my favorite part of Rails, I've used them with other applications as well, the idea that you just load partials (without a huge framework such as React) is pretty nice.

mschaef 8y ago

As much I tend to be sympathetic to the no-SPA cause, it's easy to run into requirements that exclude MPA's. Incrementally updating a page just has too many potential performance and usability advantages. (Not to mention that an SPA can potentially be given some offline capability to accommodate a marginal network connection.)

osrec 8y ago

Could not disagree more with the article. In my experience, well designed SPAs are almost always better and lighter than multi page apps. The fact that a lot of SPAs are implemented quite poorly is a different story. In actual fact, whether a web app is single or multi page is merely an implementation detail; in both cases we're just passing information back and forth between client and server. With multi page apps, you transmit and parse full markup each time. With SPAs, you do it once and then mutate as needed. In that sense it's more efficient and I can't see why that's a bad thing.

yummybear 8y ago

Most of the issues listed are either issues with MPA's as well or optional for SPA's. There are plenty of MPA's with slow first time loads for instance.

okal 8y ago

At my current workplace - as a deliberate design choice - and last one - organically "discovered", but deliberately maintained - we've tended towards building user facing products as collections of smaller apps sharing a backend, rather than typical SPA (Single Page Application) architecture What that means in practice is that: 1. Routing is always handled server side. The less frontend state (IMO/IME) the better. There will be the odd bit of pushState where appropriate, but no actual full-on routes. 2. Whether to render content server or client side is determined on a case by case basis. It's often easier to build HTML using whatever templating system your backend tooling provides than build a REST/GraphQL endpoint for a component to consume. 3. You can introduce React/React-style programming piecemeal to a team with varying levels of experience. Everyone on a team (with varying degrees of frontend skill/experience) can be productive from day one. Does anyone else do this?

bunderbunder 8y ago
Another potential benefit is reduced toolkit lock-in. Migrating a bunch of smaller pages one at a time is pretty doable. Migrating a large SPA without disrupting business could be like trying to pass a camel through the eye of a needle.

arendtio 8y ago

> There are cases where an SPA makes sense but this is a topic for another article. Without that second part, this is just a trite rant against SPAs.

deleted 8y ago

[deleted]

ravenstine 8y ago

I don't really agree with the author that SPA's are almost always worse. Although sometimes they're gratuitous, as was the case with a lot of early Angular apps where it was pretty clear that the developers thought they were being cool by making way too many things behave "dynamicky" for the sake of having their work appear more like an app than a site. On the other hand, there are plenty of times where a multi-page app is just fine. If that's the tool that works best for you, then by all means use it. The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are.

systematical 8y ago
>The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are. This is the correct response, but among developers you will have zealotry on this topic. I personally find MPAs easier, but that is based on my work experience and my perception of the learning curved involved in things like React and Angular (I found VueJS to be far easier to learn). I do like the idea of thinking about an API from the get-go with an SPA, but do all applications need an API? Nope. The amount of applications in the business world that will require both a web implementation and an iphone/android app is actually quite small, isn't it?

Zooper 8y ago

Alternate title: the front-end sucks now because we have too many options for doing generally the same thing, and they all aren't compatible with each other, but my way, the way I first learned, is best, and something about functional programming even though UIs arbitrarily necessitate or do not necessitate state. I, personally, place blame on WC3 for this state of affairs, as Web components should have solved the UI interoperability problem, observed objects were dropped which regardless of what one thinks of them (I think a trie is better) would have unified state management clearly (replaced by Proxy? yeah, I see everyone using that string-only thing for state), and various other specs should have solved most of these issues, but I guess they were too busy making people leave their org over DRM, rather than making a useful, consistent, easily-produced internet. Who needs standards when all of the for-profit board members have their own un-interoperable libraries?

casper345 8y ago

> For instance, if you’re building a chat box then there’s really no need to implement your login page in React. Wrestling with this idea. Been using create react app for most of my projects that arguably do not need it. But the development is so much faster and easier to manage than traditonal html/css webpack

calibas 8y ago

If I let the browser handle internal links so everything reloads, is my SPA now an MPA?

n1tranquilla 8y ago

This is a load of garbage.

barbecue_sauce 8y ago

I didn't really learn web development seriously until the age of SPAs, so I find SPAs much easier to reason about than multi-page. That said, I'm not really sure that a UI which is mostly fields and forms really warrants a front-end framework unless its an extremely complex, stateful flow.

mekoka 8y ago

I'm a long time server-side developer who've been working on the front-end for the past 6 months. I don't agree with this article. I think its author has a significant misunderstanding of SPAs and overstates some of the potential issues. Having built both type of applications at varied level of complexity I absolutely don't agree with the notion that SPAs are necessarily more expensive than MPAs. I'll address a few of his points, but most, if not all, of his claims can similarly be refuted. Statefulness: Few people would build an SPA on top of a stateful backend? Most SPAs query an API which nowadays will more than likely be hypertext driven (read stateless). The user authenticates, gets an access key, then serves that access key along with each subsequent request to the API that needs it. The server does not keep a session around. It receives the query, does its job in the confines of what is requested and serves back a response (likely in JSON). That's more or less it. There's very little state involved here. Testing: Vague unsubstantiated claims. Why make backend and frontend talk to each other when mocking would do just fine. Performance and network latency: Has anyone been using an SPA recently and had this as their main problem? If your client is incessantly polling your API, then it's a sign that either your API is not designed well enough to address the problem domain, or you need to employ a caching mechanism on the front. There's no cookie cutter way to architect an API. If your client is more likely to query and use 10 items from a collection, don't force it to make 10 requests, provide a facility to bundle them up into one. On the front-end most frameworks have satisfactory libraries to handle state and cache management. Slow first time load, multiple times per day? Stop updating your live bundle multiple times in a single day. Authentication with JWTs: JWTs are not an SPA requirement, they're just one of many approaches to authentication. I don't use them and don't see the point of them in most apps that I've built. If you do use them and need to keep track of them (maybe because you'd like to be able to invalidate them), store them in something fast like Redis on the server. State updates: The JavaScript ecosystem has excellent caching facilities, that can automatically poll and update resources upon a timeout. It's indeed not rocket science. Error Handling: You catch the error from the http response and call your handler. That's practically like muscle memory whenever one does an http request. client.get({url}).then(resp=>{ // handle response }).catch(error=>{ errorhandler(error) }) No busywork there and probably much more user-friendly than that default error message that will be served by nginx (if one truly wants to stick to such a "no busywork" philosophy). The rest of the article can similarly be addressed. My conclusion is simply that if you want to maximize your cost efficiency, build a team that is familiar with their tools. If all your developers have done and are familiar with are MPAs, then yes, it might be more costly to build an SPA for them at first. I should know. I went through that phase at the beginning of my recent JS foray. Doing anything was slow and would've taken me a fraction of the time by simply playing around with Jinja on the backend. But fast-forward a few months, after immersing myself a bit more with the ecosystem, I cannot imagine reverting to that approach to build anything more complex than a simple data driven app. Emphasis on the simple.

CosmicShadow 8y ago

SPAs: reinventing the browser in the browser, and you get the bonus of doing it all in JavaScript! I hate SPAs, so much more complexity and work. In MPAs you can still use JS and AJAX for a better experience, but SPAs just have so much needless extra work and are harder to maintain. They are also frustrating to use. They can be better to use when done well, but you don't often see that unless it's from someone quite big.

dapreja 8y ago

> Error HandlingAn MPA renders a 500 page upon error and that's it. However, an SPA needs to detect errors in the client code and then update the user interface accordingly. Again, busywork required to regain what MPAs offer out of the box. I'm no gilded dev, but 5 years back when PHP wasn't avoided like the black plague we would still need to update user interface handling these internal server errors. It's judt good design practice. I more or less agreed/understood with the writer up to that point. Everything else past this just sounded like a argument for argument's sake.

systematical 8y ago

This was a rant, but I did learn about turbolinks, so its a worthwhile read for me. The salt in here is strong.