
A single-page app is almost always worse than a multi-page app - 1gor
https://www.gregnavis.com/articles/the-architecture-no-one-needs.html
======
decasia
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.

~~~
reaperducer
_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)."_

In my experience, this is false.

In the last two years I've built five _very_ complex forms for the healthcare
industry that not only had crazy looking flow-charts, but had to be multi-
lingual, predictive, mobile-friendly, and fully accessible.

They use all those little bits that you talk about - multi-part forms, date
pickers, autocomplete, and conditional input.

The only JS is for the autocomplete. The rest is all HTML5/CSS3.

We did user testing on three of them (100 people from our target group,
selected randomly at two of our facilities, with generally low levels of
technology literacy), and the paginated HTML5/CSS3 versions all scored higher
than the previous Javascript SPA mess the preceded them.

~~~
rovek
If you didn't use JS for date pickers, you didn't have very inclusive browser
support - especially for something like a healthcare website. [1]

Were the designs and layout of these SPA and HTML5/CSS3 website also
identical?

[1]
[https://caniuse.com/#search=input%20date](https://caniuse.com/#search=input%20date)

~~~
thrower123
It's more than a little absurd that there isn't a passable date picker
implemented across the major browsers. I have wasted far, far too much of my
life fighting with different half-baked JS datepicker components already in my
life.

~~~
davvolun
Still better than supporting IE6.

------
crazygringo
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
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
> 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.

~~~
the_gastropod
Hear hear! I don't think the assertion that SPA's are faster to build / more
scalable holds up to much scrutiny.

1\. SPA's still require some back end to render the initial page / payload.

2\. SPA's cannot be trusted, so you need to duplicate things like validations.

2a. "But you can just do an ajax call to validate records on the back end, and
get a json response!" — how's that any more performant than just doing a
traditional page load? With pjax or turbolinks, the performance difference
between these options is even closer.

~~~
vidarh
I remember a decade ago, when there was a management demand to get rid of the
"page load", and our quick and (very) dirty solution was to simply load the
next page with ajax as HTML and simply replace most of the body with the body
of the loaded page. It was hardly any faster (we measured), but everyone
insisted it was suddenly blazing fast. The psychological effect of avoiding
the visual artefacts of a page load was large enough that it was mostly
sufficient.

We eventually did some minor optimisations - returning smaller parts of the
page, and replacing more precise sub-parts of the DOM. We had some other small
pieces of JS on the pages too, but for the most part just having the server
render everything replacing large chunks was good enough.

------
poisonborz
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
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.

------
ehayes
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.

~~~
jhall1468
> 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.

------
citeguised
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
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).

------
devwastaken
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.

------
osrec
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.

------
codingdave
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.

------
rossdavidh
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.

------
BWStearns
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.

------
thesimon
>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).

~~~
dagss
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
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
Users never returning _has_ an effect on bottom line. So you can make the
argument from that position.

Whether users return, and how that hurts your business, depends very much on
your site and your users.

I will disagree about UX not being about bottom line though (in the usual
context of a for-profit company of course). In a common setting, whoever pays
developers and designers are doing so as an investment that they think will be
profitable. If you can cut costs without hurting (long term) revenue by
cheaping out on UX then of course you should (!). But often the idea is good
UX will drive revenue...

------
jho406
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.

------
yogthos
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
>>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.

~~~
yogthos
That's a problem with Django though, and not an inherent problem in SPAs.

------
okal
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
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.

------
hiram112
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.

------
ravenstine
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
>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?

------
3dfan
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
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
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
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
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.

------
madmaniak
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
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?"

------
CosmicShadow
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.

------
Zooper
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?

------
barbecue_sauce
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.

------
jordache
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.

------
sbr464
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...](https://www.thisamericanlife.org/351/return-to-
childhood/act-four-0)

------
dapreja
> 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.

------
LiterallyDoge
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.

------
MattyRad
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.

------
parski
Oh. He's talking about websites.

------
k_bx
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
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
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.

------
daliusd
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
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.

------
arendtio
> 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.

------
mschaef
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.)

------
casper345
> 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

------
yummybear
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.

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

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

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

------
citilife
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.

------
mekoka
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_.

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

------
alexmuro
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.

------
n1tranquilla
This is a load of garbage.

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

