Ask HN: Why use an SPA? | Hacker News Reader

Ask HN: Why use an SPA?

22 pointsabahlo19 comments

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

View on HN

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.

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

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.

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.

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.

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

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.

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

This is a blatant and dishonest strawman.

Nobody said we should remove all UI from applications.

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.

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.

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.

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.

Shiny New Thing Syndrome.

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.

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.

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.

Here we go again with the front end developer hate

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.

Reply on news.ycombinator.com