
Ask HN: Why use an SPA? - abahlo
Using a single page application like React has become the defacto standard for most web applications.
I realize this makes sense for JavaScript-heavy, interactive components but it feels like a majority would work perfectly fine with server-side templates, maybe even better since it’s way less overhead (talk about translations, validation, sync of backend routes and frontend client, etc.).
======
factorialboy
I agree. In fact static rendering has become refreshing given the saturation
of SPAs everywhere. Even content websites are SPAs these days. Pointless.

Anyway my next venture will be as JS free as possible. I don't have JS, I love
it. But that tribe is going thru an over-engineering cycle. Just like Java in
the early 2000s.

It will all settle down, eventually.

~~~
certera
I completely agree. I went this route with my recent project and it was very
refreshing.

------
tony
Downsides first: It's a time sink. By the time you bootstrap webpack, babel,
sass, etc. you're often pushed into building an "app" and instead of a web
page. So there's a sunk cost just to do something remotely meaningful with
react, in practice. The build outputs are colossal, even with tree shaking and
codesplitting. The initial build times on a non-trivial app can be minutes.
Minutes.

I made some pretty scathing comments about React / SPA apps on HN before. I
was insistent I could build an app with django templates + css + js. But in
the end I ended up having to use webpack just to build SASS/JS, even if I
spurned using a SPA app. So I never found a way to keep it with just
jinja/django templates and css and ship a good experience.

If you're making a website that's differentiated enough to be noticed, most
likely it'll end up needing the attention to detail a JS app brings. It's just
hard to make UX scale without it: template includes are not composable - ES
Modules + React components definitely are.

What changed my mind on SPA:

\- TypeScript is really the thing that changed the game, because it shores up
a very hard-to-scale, disorganized language ecosystem with an amazing type
system.

\- Webpack and babel getting somewhat stable in their APIs, as well as their
extension/plugins

\- React Functional Components / Hooks (cleans up a level of indentation and
avoids that class cobwebs that can make maintenance a pain)

\- Prettier: Excellent formatting tool

\- JSX: Ends up making components very "HTML-like" and the formatting with
prettier makes it feel like "blocks" where you can get a gist of the
depth/hierarchy.

\- GraphQL + Relay: The responses are code-generated into types and it
automates retrieving data from the server. You can throw redux out. Which
leads me to another thing - I consider redux an antipattern on most cases. Not
fun at all to work with at scale.

I wish typescript / react / jsx / sass just worked from the browser itself,
without all the webpack and babel, and these configuration files. I think
maybe, after thousands of hours, I finally comprehend webpack. But in all
likelihood I'm mistaken, and webpack 5.x will end up making me have to start
over anyway.

------
BWStearns
If your team consists of backend engineers who haven’t done full stack in a
while and front end engineers who are already good with react/vue then I’ve
found it easier to just go SPA instead of everyone trying to remember how
Django/Rails works. Also if your server side stuff has to or probably will
have to talk to other machines then you’re just saving yourself the trouble of
implementing the human only version.

If your team consists of mostly people who’re used to doing rails/Django style
webapps then it’s perfectly reasonable to not build an SPA.

------
macando
Why do we need elaborated backend structures? A bit of SQL in stored
procedures on top of a DB is good enough all the time. It's way less overhead.
Heck, why don't we just let the users get what they want by giving them access
to a SQL prompt. We could eliminate the UI completely.

~~~
jolmg
> A bit of SQL in stored procedures on top of a DB is good enough all the
> time.

You do need an HTTP server if you want to offer an HTTP service.

> Heck, why don't we just let the users get what they want by giving them
> access to a SQL prompt.

I don't think any RDBMS has a sufficiently complex permissions system to
accommodate the needs of a webapp.

> We could eliminate the UI completely.

Obviously, any user needs a UI to interact with any software, so I'm not sure
what you're trying to say here. Your proposed SQL prompt is also a UI.

I feel you're trying to imply something here, but I'm at a loss as to what
that is.

~~~
macando
I was joking. I usually hear complaints about SPAs from backend engineers who
see frontend as a few server-side rendered forms with some validations thrown
in. An equivalent to that is a back-end with a thin layer atop of database
tables. I programmed server-side web forms in ASP.NET and JSP for years before
switching to SPAs and React. Literally everything is better with React.
Everything.

~~~
theworld572
> I programmed server-side web forms in ASP.NET and JSP for years before
> switching to SPAs and React.

I don't think that comparison makes sense? ASP.NET and JSP are server side
languages while React is client side.

------
aphextron
The web has evolved from a collection of hyperlinked documents in the 90s to a
fully featured application platform in 2019. There's still a place for server
side rendering. But it's for static content, not applications anymore.
Practically everyone on the web now has a client capable of executing complex
application code. As a result it has become incredibly simple for developers
to build things out on the client that would have been impossible with the old
paradigm. Not only does it make development faster, but it allows a much
greater separation of concerns across the stack. Backends can now be
completely agnostic of the presentation layer, which pays for itself many
times over when you realize a given application may be running across native
desktop, native mobile, mobile web, desktop web, TV OS's, game consoles, etc.
Having to duplicate your business logic for these use cases would be terrible.

------
dmlittle
A valid use-case is to provide a UI for API products (Stripe, Lob, Twilio,
etc). The main product is an API for customers to use but you may also want to
be able to login to their website and check the current state of affairs of
your account. Since you already have to build an API for your customers and
everything you're showing might already be possible with the API, you can
create a UI to glue the request calls together. A SPA can use the same API,
avoids you having to write new code for your website and you get to dog-food
your own API.

Disclaimer: I work for Lob.

~~~
jklein11
Using the front end as the glue sounds dangerous. If you are accessing a third
party api via the front end directly I can't see a way around passing whatever
authentication mechanism they use to the client. This is giving pretty open
access to hit the api with your credentials.

~~~
dmlittle
In this case it’s not a third party API but your own products API. Also while
you can use the same endpoints, authentication and authorization don’t have to
be the same. You could use your standard basic auth (or other) for your
regular API use case and then use cookie based auth or JWTs (or whatever other
auth you want) for the SPA. Again this isn’t for third party APIs but for
companies creating a web app for their own apps so you can have flexibility.

------
tobltobs
Shiny New Thing Syndrome.

------
muzani
For example, one of our web apps regularly sends 'heartbeats' to the server.
It's difficult to track this across different pages.

But there's definitely overhead, so I wouldn't do it unless necessary.

------
jklein11
In a lot of cases, it is more efficient to save state on the front end so you
don't need to retrieve it each time on the back end.

------
stephenr
The #1 use for an SPA is called “resume padding”.

If you’re a front end dev who wants to look important, making the entire
application reliant on your fragile client side code can give a lot of hutzpah
to your resume.

~~~
throwaway58295
Here we go again with the front end developer hate

~~~
theworld572
Backend devs do this as well. You could just as easily start a thread called
"Why use MicroServices/Serverless/Kubernetes/NoSQL etc.". Just like SPAs,
those things all have a time and a place but unfortunately devs often push for
them to be used in order to practice resume-driven-development and so they can
play with the shiny new toy that everybody is talking about.

Personally I think SPAs have a time and a place - highly interactive web apps
like google docs, facebook, slack etc. should definitely be SPAs. But using
React to create a blog site is just ridiculous. Indiehackers.com is a perfect
example of a site which would be so much better if it was a plain old
statically rendered site. I remember a podcast where the founder of
indiehackers said that he used React to build the site because he wasn't happy
that the indiehackers business is not technical enough - so using react was a
way making it more "techy" even though it actually makes the site worse (he
didn't admit that part though). And thats fine for him as he is a solo-
entrepreneur, but when developers working on teams take on that mentality it
be extremely frustrating for the developers who would rather produce value
than produce overly-complicated solutions in order to gain bragging rights.

