
SPAs are harder and always will be (2013) - donatj
http://wgross.net/essays/spas-are-harder
======
ljoshua
These are fantastic technical reasons when considering a SPA vs. a traditional
server-side app, but to me the largest consideration, outweighing other
technical decisions, is the overall experience the end customer is going to
need and expect.

Migrating from a desktop-based application to a web version? That desktop
version was likely extremely responsive, and full page loads may feel like a
step backward.

Does the application require constant, fast interaction, such as data
analysis, frequent order entry, or highly dynamic UX? That's the domain of the
SPA. But if the situation is more of a request/response scenario, then a
traditional server-side set up works wonders.

The technical difficulties surrounding SPAs vs traditional are for the most
part solved. It does require more overall work, but that gap is shrinking.
Therefore, IMO the largest deciding factor should be user expectations, and
that can go either way.

~~~
purerandomness
The problem is that most SPAs today are cargo-culting.

They break middle mouse button (or Ctrl-Click or whatever your favourite "open
link in new tab" shortcut is on your Apple computer), at the same time break
browser history, and at the same time make you wait for any single interaction
you're doing (show spinning wheel for 6 seconds before opening a confirmation
modal)

The ideal solution is a) minimize server roundtrips (<100ms) and b) reload
parts of the site via AJAX where it makes sense.

No need to shovel 7MB of JavaScript to the user.

~~~
bastawhiz
> They break middle mouse button (or Ctrl-Click or whatever your favourite
> "open link in new tab" shortcut is on your Apple computer), at the same time
> break browser history, and at the same time make you wait for any single
> interaction you're doing (show spinning wheel for 6 seconds before opening a
> confirmation modal)

I am not defending SPAs, but the points you've made are not indicative of
SPAs, they're indicative of bad software. This problem existed before SPAs
were a thing. Remember ASP.Net pages where the whole page is wrapped in a
giant <form> and you couldn't use the back button most of the time? This
problem also doesn't exist with properly built SPAs (e.g., by using <a> for
links, using the history API correctly, and designing a sensible UX).

And certainly, if your app is sending 7MB of JavaScript over the wire and it's
not a video game, something is very wrong--SPA or not.

~~~
reaperducer
I think SPAs get a bad reputation partially because they're trendy. Which
means that inexperienced programmers flock to them and make them awful.

I recently re-wrote an SPA from a previous dev into a regular set of
query/response web pages. The SPA was 2,143K. The new set is 78K. A big part
of that savings was because javascript is verboten for this project due to
client hardware constraints.

Yes, the previous dev was not the best in the world, but IME SPAs are always
heavier than their response/query counterparts.

~~~
neosavvy
Not trying to defend inexperienced programmers but I've seen plenty of 20+
year senior programmers contribute poorly to SPAs.

They refuse to learn the best practices / new patterns because "they have 20+
years experience".

I have been caught in the middle between some younger programmers and some
elder folks for the body of the past 3 years and the bottom line is this:

Learn the suggested best practices, or just don't build apps like this.

The OP's original thoughts on simplicity do ring true, but pushing for better
UX is actually a reason to redo something. There are plenty of legacy systems
out there with frustrated users, and the "complexity" can be simplified if
effort is invested to accomplish those goals.

~~~
jrs95
As a relatively junior developer, my advice would be “learn the best
practices, or don’t write code at all”...

But we’ll see if I’m actually following my own advice 15 years from now.
Hopefully I’m not on the wrong side of the Dunning-Krueger effect

~~~
at-fates-hands
> But we’ll see if I’m actually following my own advice 15 years from now.

The one thing I've learned after doing this for 5 years is you probably won't
be needing to follow best practices in the next 3 months.

I've been in my current role about three years. Most of my 2015 was building
an Angular 1.X transactional app. By the time it was released, I was told to
start learning HapiJS and EmberJS because we were transitioning as a group to
that. Then 8 months later and several smaller apps, I was told we're going
back to AngularJS and Angular 2.0 transitional. So I had to almost completely
relearn that. Then after one huge disaster trying to integrate it into our
services, we gave it up and spent the rest of 2016 moving that app to ReactJS.

I then spent most of last year jumping around (because now all these apps we
built needed supporting) between those three frameworks (Angular, React and
Hapi). Now there's talk of moving to VueJS but there is a loud push to just
stick with one (Angular or React) and be done with this.

My point here is you may _want_ to learn best practices, but how fast my org
was changing, and building things quite literally on the fly, you just don't
have time. Sure, in my own private projects, I learn best practices and use
them myself. For our customers and "the business"? No time man, no matter if
it will us time or not. Getting something shipped that's working is far more
important.

~~~
Silhouette
Ironically, you've just provided an excellent illustration of some _real_ good
practices: find tools that are good enough to do the job, only depend on
things that are built to last, and concentrate on actually doing that job. The
web development world's obsession with constantly moving to the next thing
that does essentially the same job as the last thing but maybe 5% better (or
maybe not) is a huge productivity sink and best avoided as much as possible.
Getting something shipped that's working _is_ far more important than exactly
how you made it, and it always has been. If "best practices" aren't helping
with that, are they really best practices at all?

~~~
jrs95
While this is generally true, the situation with SPAs is a bit more
complicated. Each popular approach early on had a lot of serious issues and
pitfalls. IMO React was the first thing to really break through this and while
it’s not perfect it addressed the biggest issues Angular and Ember had quite
well.

However, at this point, once you’ve adopted React, NG2, Ember 2.x, or Vue,
there’s not much to be gained by switching between them. They’ve all sort of
gotten past the initial immaturities of the SPA approach.

This is really something you ought to carefully evaluate once and be done with
it.

------
t_fatus
One thing I learnt to love about SPAs is how they distribute responsibilities:
obv you get 3 layers:

\- your DB which stores your data

\- your backend which access your data, retrieve it safely, and delivers it
_without having to know anything about the client it serves_.

\- your frontend which handle how / when it needs data, which data it needs,
how it caches it.

Separation is good, since you can test your API _without needing your client_
, you can test your client code with mock data, you can _build different
clients_ (web, native apps, ..) over the same API (and even do not need to
build an API if you're using things like graphql)

~~~
cmont128
1000x this. People seem to ignore this fact, that a lot of times you will need
an API _anyway_ (multiple clients), so really adding in the SPA isn't any
extra work at all.

------
jorgeleo
And... nope!

1) Hard and easy are relative terms, You feel it hard because it is foreign to
'you', not because it is intrinsically hard. If it seems hard to you then get
comfortable with the new pattern, or create a pattern that is more familiar to
you, but please don't tell me this is hard because I have to write more code
or because there is one more thing that you have to know and maintain. That is
not hard, that is been laaaaazy.

2) The 2 points become irrelevant if you do SPA using server rendering. To
give an example using C# and MVC: I have 1 javascript function with 0, I
repeat: 0 business logic. All my MVC methods return a partial view with a tag
saying where it goes. The javascript function does an AJAX call to the
controller and on successful return it looks for the tag, and do a $('#' \+
tagvalue).html(partialView). All the business logic is on the server, all the
drawing is on the server, all the validation is on the server. The only UI
validation logic is the same one that you would write in the case of non-SPA.
There is no data synchronization because the server manages the data. The
browser gets reduced to a pretty HTML document display, which is all that it
is.

SPAs are not harder, they never were.

~~~
betageek
Your second option seems to suggest that the way to make building SPA's easy
is to stop building SPA's and go back to building web apps the way we did in
2005?

~~~
jorgeleo
1\. To me, it is an SPA as long as you are not updating the whole page every
time. The year of the tools has nothing to do with it.

2\. I use the tools I use because they work and produce the proper and
performant results. To be honest, I don't care for developer tool fashion
statements, and so the year is irrelevant to me.

------
linkmotif
Been watching this thread all day and I’m dumbfounded no one has spoken up for
React with a modern router like found[0]. Once you learn to use these things,
making an SPA is really nice, and you can easily introduce universal rendering
which takes your SPA to the next level by rendering it on the server.

I find it strange that people talk like server rendered pages with progressive
enchancent a la 2013 aka Stack Overflow aka GitHub are easy to make and
maintain. It’s 2018 and when you close an issue on GitHub the count doesn’t
change until you refresh the page. It’s 2018 and when you go back on Stack
Overflow the alerts you just dismissed are suddenly unread again. These are
companies capitalized with hundreds of millions of dollars yet they are
incapable of making server rendering with progressive enchancement work. It’s
not their fault, it’s the technology, it’s busted.

Yet for some reason people are lauding server rendering as effective and
desirable and capable of producing rich UI that’s sane to build and maintain.
It’s not. It’s unmanagable at any scale.

With React etc in 2018 all of these problems have been solved, and as I said
above, the SPA is not even something to argue about anymore because you can
render your app on the client or the server. This whole article is moot. All
these problems have been solved and the solutions are free for anyone who has
the interest and bandwidth to build products like it’s 2018.

[0] [https://github.com/4Catalyzer/found](https://github.com/4Catalyzer/found)

~~~
subsection1h
> I’m dumbfounded no one has spoken up for React with a modern router like
> found.

You're dumbfounded that developers aren't powering their companies' multi-
million dollar websites with tools that have a bus factor of roughly
one[1][2]?

A couple years ago I was handed a web app built by a team that had used tools
with low bus factors. Many of these tools had been abandoned only months after
the team starting using them!

[1]
[https://github.com/4Catalyzer/found/graphs/contributors](https://github.com/4Catalyzer/found/graphs/contributors)

[2]
[https://github.com/4Catalyzer/farce/graphs/contributors](https://github.com/4Catalyzer/farce/graphs/contributors)

~~~
linkmotif
You’re right, of course. But that particular repo was one example. Yes that
repo is brand new. But at the same time it’s the product of basically one
person’s work. On the other hand you have these multi million dollar
companies—if their tech stacks were the end all of stacks, wouldn’t they be
able to accomplish what this lowly repo accomplishes? But they don’t. And why?
Because this repo stands on the shoulders of many attempts and failures in
routing with universal rendering, while GitHub and Stack Overflow are stuck in
2013, when people only rendered on the server, progressively enchanced, and
back only kind of worked.

Anyway there’s also react-router, which is a project with probably 10k stars.
I didn’t cite it because I think it’s not as good as “found”. But it works and
will get you back functionality that works in client rendering and server
rendering. So if you’re looking for bus factor, react-router has got that in
2018.

------
edmundhuber
My takeaway from having worked on both traditional webapps, and SPAs (2 with
homegrown frameworks built on backbone.js, and 1 with ember.js): SPAs, being
more complex, demand a higher standard of coding and code review to not have
eisenbugs. I have seen a lot of effort wasted on making SPAs work, when the
customer would have been happier to have a more reliable traditional webapp.

In one of these companies, SPA architecture was chosen because the backend was
unacceptably slow. Instead of fixing that problem, we adopted more complexity
by transitioning to SPA. When I left, the backend was still slow, and the SPA
was breaking all the time. It felt like a waste of effort and I would never do
an SPA by choice again.

------
bpicolo
This is why I'm a fan of having both - no need to limit yourself to one or the
other

Data heavy pages with little or no interaction? Statically render it. Admin
pages, terms of service, etc. Writing endpoints and serialization to move the
data is a waste of time.

Sure, you might have to maintain two separate sets of minor components (header
nav and such) but it's well worth it the lessen the development cost of non-
impactive pages. Can also get away with loading HTML partials from the backend
and throwing them into the dom whole - the perfect case for
__dangerouslySetInnerHTML or whatever, then you can reuse your nav and such

------
autarch
I agree that SPAs are always harder. For me, there are two main reasons to
consider an SPA.

1\. It _can_ let you build a much nicer UI/UX. That said, it's probably easier
to build an _okay_ UI/UX with a traditional webapp, and it's also easier to
build a _terrible_ UI/UX with an SPA. But the upper limit for excellent UI/UX
is higher with an SPA.

2\. If you are planning to build a REST API for your system, then the best way
to do this is to build a REST API from the start and dog food it with an SPA.
Otherwise you end up doing a lot of the server side work twice, once for the
HTML app and again for the REST API. It's better to bite the bullet and _just_
build the REST API server side.

------
throwaway2016a
The article had me confused until I realized this was 2013. Even then it is
out of date.

Muli-Page applications have had business logic on the client-side for years as
a technique to reduce the feeling of latency since at least 2005.

If by "Traditional" web apps you mean web apps from the mid to late 90's, sure
it was done entirely with POST and no business logic at all client side.

At the very least data validation has been being done client side for s long
as Javascript has existed. (and also server side as a second level of checks
if you care about data integrity and security)

SPAs did not appear overnight. They are a logic evolution of what has been
happening for years.

~~~
Udik
> sure it was done entirely with POST and no business logic at all client side

Even if you don't have business logic on the client side, you still have a
state: tab position, state of controls, etc. These are not part of the data
you really care to store on the server, and yet they have to be sent there at
each and every page reload, as they might be needed in order to build the
response.

------
z3t4
I have a simple rule: If the app requires real time updates and push, then SPA
it is, but you can also mix server side rendering with SPA's aka micro
services, eg the "chat" can be it's own component.

The argument for SPA's is that they perform better, but I don't find that to
be the case with all the bloat on real world "apps". Browsers are good at
rendering static content, and a server rendered site will perform well even on
low end mobile devices. With todays hardware the server can render even the
most complexed site in less then a millisecond, and with todays networks the
latency, often as low as a few milliseconds is imperceivable and even faster
then clicking around in something using a JS framework.

------
gedy
...but much easier and maintainable than a "server-side" webapp that is a mess
of jQuery, etc layered on top to make the experience "interactive". Not to
mention the ease of unit testing user interface code in SPA.

------
slackwalker
> If you need to restrict access to a field (e.g. social security number) such
> that only certain users can see it, you need the authorization check twice,
> once when writing the JSON and again when building the HTML.

I think the article may have some points worth considering, but in what world
should security code for restricting access to display a social security
number ever be in the browser? The browser should never get data that it would
be dangerous for the user to have access to.

------
nickjj
My work flow for a new app is:

1\. Use whatever back end framework I know

2\. Use server side templates

3\. Slap on Turbolinks (because it works super easily with any back end
framework)

4\. Sprinkle in JS as needed

This results in very fast development, very fast page loads and no duplication
of things like validations / schemas. The best part is you can use whatever
you want on the back end too. I've followed this pattern successfully with
Rails, Flask and Phoenix.

Screw SPAs (for most document heavy web apps).

------
rb808
Certainly though SPAs are overprescribed and old fashioned template based
sites work great for many projects.

But I think for many enterprisey platforms its likely the opposite, front end
design logic is likely done by a different team to back end data provider so
its a natural split that is more effective than a server generated page. Not
to mention most back end devs suck at design.

~~~
wvenable
Nothing gives you a more cohesive design than splitting a project right in the
middle and giving it to two different teams. /s

~~~
reaperducer
As they say, an elephant is a mouse designed by a committee.

An appropriate aphorism, considering most ASPs are full of javascript bloat.

------
brightball
If people could get to a point of saying:

This system benefits from being an SPA...

This one does not...

99% of the problem goes away

~~~
tomca32
Yes. So much wisdom is so simple. There are apps that benefit from being SPAs,
your google maps, and the like.

Our CRUD app is not one of them, but here we are still with React, and Redux,
and Mobx, and ...

------
tarikjn
An easier way to reason about the modern web, and port this knowledge from and
to native platforms at a minimal cognitive cost, is to think about a web
application as consuming from an API or database layer which already enforces
authorization and provides authentication, instead of mixing all these things
in a single request.

Once you do this, the idea of duplicated authorization goes away, as the only
thing you are doing on the front-end is error representation (and focusing on
the design).

Then, you pre-build, or run+cache this same application on the server side to
pre-render pages for search engines, first page load, accessibility etc. so
that you are actually delivering an application for the semantic Web.

Viewed from this angle, it does not really involve more steps, but it does
create more separation of concern. This in turn allows more specialization,
scaling, and is more secure.

You can apply this approach to build very simple pages (e.g. blog consuming
data from Markdown files), which are not SPAs, but are very easy to turn into
SPAs.

So it's not really that SPAs are this hard, it's that the "do everything in
one request" thinking is still very pervasive and making it harder to reason
about building modern websites in a simple manner.

------
JepZ
Well, I think that many people are not aways that SPA != SPA. Actually, SPA
means that the site never does a full page reload, but apart from that there
is very little defined about SPAs. You can build them with fluid 60 fps
interfaces or with server side HTML rendering causing huge delays. You can add
aria attributes or render everything within a big canvas. Its still a SPA.

So no wonder there is so much disagreement about SPAs.

A first step towards a more defined and reasonable term is PWA as the term
requires the use of some specific technologies (HTTPS, ServiceWorker, etc.).
Nevertheless, it is still very broad. For example what happens to an PWA when
the server is not available anymore? Does it keep running forever? Not
defined, so some do others don't.

I really like well made PWAs, but in general most of them have a too strong
server dependency (in my opinion). I would like to download a PWA on day X and
install it on my PC 5 years later and it should still work (as other software
does). As the old server might not be available anymore, I would also like to
enter a new server in the settings.

The technology behind PWAs would allow such use-cases, it is just not that
simple to use nowadays.

------
throwanem
I don't want to beat up too hard on a five-year-old article. But in case
anyone reading it now might not know better, I want to mention that a lot of
the reasoning here is plain bogus.

You don't do complex authorization on the client. If your backend is serving
SSNs to a user who isn't authorized to see them, you've already lost. Trying
to hide them in the UI avails you nothing beyond a false sense of security.

Cache invalidation is trivial. HTTP provides, in entity tags, a very friendly
mechanism for checking whether a resource is stale without incurring an
expensive refetch unless one is needed. Use it. Resolving write conflicts is
more complicated, sure - exactly as complicated as it is to do on the backend.

It's true that SPAs are _differently_ complex. You're doing work on the client
that'd traditionally be done on the server, and with different tooling and not
all the same paradigms. But _more_ complex? Not once you understand it.

------
Udik
Frankly I think both reasons given for the supposed greater difficulty of
building SPAs are wrong- and that SPAs have been successful exactly because
they're much easier to develop.

Additional logic tier: exactly the opposite is true. A SPA allows to get rid
(almost) completely of the logic on the server, leaving there only a shallow
layer of services. While traditional web applications always had the problem
of a complex logic layer on the backend, with in addition the need to manage
complicated interactions happening only client side (because even traditional
web applications couldn't afford an entire page reload for simple things like
reordering a table, displaying an error message, etc.). Part of the logic had
to be replicated on both sides, with all the problems that it creates.

Data synchronization- again, given the fact that the entire state of the
application resides only on the client and is rendered only by the client,
data synchronization becomes trivial- it's just a matter of calling some
backend service to store or retrieve the full state.

In short, the problem with traditional web apps is that they've always had the
need to manage a state on the client as well as on the server; and the
client's state was lost at every page reload, or either had to be sent to the
server with some hack to be restored after the page reload. A nightmare.

------
sillysaurus3
I'm pretty convinced that rather than shying away from SPAs (which is totally
fine), we could solve this with an extra layer of abstraction.

Consider the Unreal network architecture:
[https://docs.unrealengine.com/udk/Three/NetworkingOverview.h...](https://docs.unrealengine.com/udk/Three/NetworkingOverview.html)

When Tim Sweeney needed to make an engine, he didn't simply hardcode each of
the tasks: Update position, update velocity, play animation...

Instead, he created a system that allowed those things to become implicit.
They synchronize themselves across the network by default. There's no special
logic required.

So when I look at SPAs, I see a similar sort of situation. Rather than
hardcoding each of our endpoints, why don't we come up with a system where we
can synchronize some variables from the server to the client? Then adding some
new data is as simple as declaring a new variable. No need to create an
endpoint for every single thing.

This is vague and handwavey, but there's an underlying idea here worth
examining. It seems like we could leverage abstraction in a way that unifies
these systems (as opposed to simply shoveling another layer of abstraction on
top of the current pile).

Has anyone been working on anything like this?

~~~
faitswulff
Like Firebase? [https://firebase.google.com/](https://firebase.google.com/)

~~~
sillysaurus3
I meant aimed specifically at SPAs. Firebase is nice, but it doesn't really
help reduce code bloat on the front end. E.g. if you're making a react app,
your instinct is to reach for redux + reducers, even though that means dozens
or hundreds of lines of boilerplate code.

~~~
gieksosz
In my experience you can/should skip redux if you use firebase-firestore. One
good reason is that if you try to use them both, you will end up writing a lot
of "mee too" action and reducers that will just wrap firebase update events.
It is really not necessary to always use Redux.

------
jnsaff2
Yea, there's this guy telling us about the biggest SPA in the world (spoiler
it's azure) here: [https://vimeo.com/156417164](https://vimeo.com/156417164)

It just so happens to be the worst UI whenever I need to use it. Just awful.

------
Daycrawler
The answers to the first difficulty are called "Universal Rendering" and
"Isomorphic Rendering". Universal Rendering will render the page at any URL
server-side, then the client will render other pages from there. Isomorphic
Rendering is a special case of Universal Rendering in Node.js apps where the
same JavaScript code is used to render pages in the client and the server.

Anyway, the article is right. Of course presenting users the current state of
things in real time and allowing them to mutate this state in real time will
always be harder than issuing requests to query the current state and requests
to mutate the current state. It'll always be harder because it's way more
complex and powerful from a user perspective.

------
dane-pgp
The article helpfully considers the issue of logic being duplicated across
layers, and questions the choice of potentially unnecessary layers of business
logic being in the architecture at all.

I wonder, though, how this changes in a modern world of web services like
Amazon's, where your web host provides REST APIs to talk to your database
(e.g. DynamoDB), and you can serve your SPA as static files out of an S3
bucket, not needing to worry about server-side code at all.

Taking out the server layer altogether may not work if you need a specific
user auth model which your web services provider doesn't support, but this
simplified serverless model has the advantage that attackers can't hack your
server code if you don't have any server code.

------
jondubois
The frameworks that are popular at the moment make it harder.

I put together a simple set of frameworks, engines and libraries that let me
build real-time SPAs really quickly and easily. I've built a complex
production app with it in a couple of weeks and it works really well. I tried
to promote it a while ago and those who tried it seemed to really like it but
it never became popular.

Promoting technical solutions these days is literally impossible if you're not
a rock star developer.

I don't even care about promoting it anymore. It's my own secret toolkit now.

If people want to believe that SPAs are harder to build, that's fine. But I'm
going to keep building them because for me with my tooling of choice it's much
much easier.

~~~
betageek
If it only took you a couple of weeks to build it isn't a complex production
app.

~~~
jondubois
Complexity is a relative term.

The app I built has sign up, sign in, password reset, subscription-based
payment processing, usage quota tracking, email verification, GitHub
integration and supports different account permission levels and it can scale
out indefinitely to pretty much any number of machines. I built it from
scratch. Also it has fade in and fade out transitions when navigating between
pages and all data throughout the app updates in real time... So for example
if you do email verification in a different tab, your main dashboard will
update in real time.

And it only receives real-time updates for pages that you're actually looking
out so it doesn't over-fetch.

------
jrs95
This whole extra logic tier comparison doesn’t make much sense to me. The same
logic exists on the server side anyways, you’re just moving it to the client.
It’s not like making a site without substantial amounts of JS is really an
alternative. You generally can’t just do everything with form submissions.

------
sova
Your first point is dead on but your second point is way off and I would
actually say the harder point is SEO. My clojurescript app is excellent at
keeping front end and back end perfectly synchronized across many clients.
However, my ability to generate pages that can be SEO'd is not as easy.

------
tpkj
Single Page Applications? Bah Humbug!

[https://wildermuth.com/2014/9/1/Single_Page_Applications_Bah...](https://wildermuth.com/2014/9/1/Single_Page_Applications_Bah_Humbug)!

------
shams93
For webrtc apps you really need a SPA, currently I use vue2. If you leave the
page you lose the session. There are other html5 APIs that are also much
happier within an SPA, like webmidi and webgl. But for text based crud apps
rails is still the best way to go. Or express and ejs. If you're not using
advanced APIs turbolinks is often a better way to make your app spa like
within incurring spa pain.

------
atoko
It's not that there's an additional layer, the rendering of the view was
always there, just tightly coupled to fetching data from the DB.

It is now a better practice to create a BFF that can serve more clients than
just browsers.

~~~
weberc2
It's not tightly coupled to the database, it's just not on the browser. And
because they aren't tightly coupled, you can still make the renderer the
client of your REST/gRPC API just as you would the browser. Or it may be more
practical to have your non-browser clients talking to your API while your
renderer talks directly to the database.

~~~
atoko
Your second choice is just coupling it again. I've only seen few frameworks
that let you render both HTML and json (Ruby on Rails).

You still have to map a model to HTML, regardless.

~~~
weberc2
Yes, that's my point. Decoupling it for the purpose of supporting multiple
frontends may not be more practical than leaving it coupled and providing an
API for other frontends.

------
ryanthedev
considering this was written 5 years ago, these points are invalid with
today's frameworks.

~~~
cultofmetatron
thats my feeling. nuxt renders a lot of these difficulties moot

------
Sujan
(2013)

~~~
sctb
Thank you! We've updated the headline.

------
nawitus
"But if you're building an app that honestly is only going to serve 10 people,
or 100---or 1000---do you really want to incur higher development and
maintenance costs just for the sake of pushing the user-experience envelope?"

Yes, because modern tooling makes it pretty much as easy.

------
matte_black
Disagree, but if you can’t take the heat get out of the SPA business.

*Ah, I see this was from 2013, makes sense. I wonder if they still hold the same opinion today?

