Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

601–610 of 637 posts

Re: SPAs Were a Mistake

#601

Post by midrus »

gefhfffh wrote: post #390
lolinder wrote: post #376

Earlier quoted context omitted.

Your arguments seem to be assuming a particularly bad implementation of a traditional backend. 1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL. 2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML ins…

> a bit of extra text Doesn't really sound like an application, but a website. In a web app it can happen that you use it for an hour without the backend doing a single thing. > There are only fewer languages to deal with if you aren't in charge of writing backend code. You don't have to deal with them at the same time

There is no black or white here. 98% of every site is in between those things and you could consider them one way or the other. Is reddit a website or an application? is a backoffice dashboar a website or an application?.

The problem with SPAs is not the technology or the architecture itself. The problem is everyone thinks, by your own definitions, they are building an "app" by default.

I've already worked for several teams which struggle to get almost anything done and everything takes ages to ship because of the fanaticism of using React for everything. God, some didn't even know you could submit a form without building a json API endpoint.

Re: SPAs Were a Mistake

#602

Post by midrus »

freedomben wrote: post #349
com2kid wrote: post #329

Earlier quoted context omitted.

> And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

I agree with all your points, but I think it's worth pointing out that those benefits you mentioned are largely for the developers . As a consumer I love a well-written SPA when the problem set calls for it, but most of the SPAs I have to use are garbage. I don't fault the tech for that, although I suspect that a lot of those SPAs were created by "me too" people that just wanted to build a SPA. When React was in the…

> but most of the SPAs I have to use are garbage

As an example, look at reddit. I'm still using old.reddit.com because I can't stand their fancy SPA UI. It is so bad to the point, as a user, I enjoy a lot more HN's interface than reddit's one.

Re: SPAs Were a Mistake

#603

Post by midrus »

nrb wrote: post #454
tored wrote: post #442

Earlier quoted context omitted.

2. Hard to believe that is true in the general case. Typical scenario for SPA is to use some sort of REST API, these API:s are usually designed for general usage, not specific usage, i.e. designed to be reused between components and views thus they basically return everything of a specific model regardless if data is needed or not. Therefore the controller queries the database with the equivalent of SELECT * on a tab…

GraphQL is such a quality of life upgrade coming from this environment, especially at the scale where your frontend teams are potentially larger and shipping more than the teams closer to the SQL can provide.

GraphQL is just another artificial solution to a problem created by SPAs themselves. Same as SSR, hydration, server components, client side routers, dynamic bundles loading, dynamic translations loading, etc, etc, etc. A whole industry of workarounds for a broken idea. Now 10 years after SPAs became popular we starting to approach a point were we almost have what we already had.

Re: SPAs Were a Mistake

#604

Post by midrus »

finniananderson wrote: post #303
simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

Totally agree. We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack. It's rock-solid, performant, dead-simple and extremely productive to work with. Why're we throwing away years of learning to build unstable, complex and inaccessible applications?

Same experience here, in our case with Laravel. The project started as a Next.js SPA and after we needed to add authentication, translations and background jobs things became so crazy and so "custom" that we ditched it and in almost 2 weeks had everything built in a much more robust way with Laravel and Livewire + Alpine.

Re: SPAs Were a Mistake

#605

Post by midrus »

delusional wrote: post #319
whatshisface wrote: post #312

Earlier quoted context omitted.

> Why're we throwing away years of learning to build unstable, complex and inaccessible applications? 1. Smart people seek out difficult problems. 2. Difficult problems drive the creation of complex, niche tools, that bear cultural associations with the smart people who made and use them. 3. People who want to be smart seek out complex, niche tools.

I think you're somewhat right, but it's not the whole story. There's another pipeline that goes something like: 1. Technical software problems are more fun than difficult product problems 2. Programmers would rather solve fun problems 3. Programmers end up creating technically elaborate machines to solve simple (buy annoying) product problems

As an ex-member of a team who used react, redux, typescript, observables, epics, thunks, custom hoome-grown validation libraries, websockets and elixir deployed in two different microservices to build a... signup wizard... I can confirm this.

I proposed to build it in Rails (which we already had, but was the "old monolith we're migrating away from") and I almost get crucified.

Re: SPAs Were a Mistake

#606

Post by midrus »

fennecfoxy wrote: post #595
simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

Idk I don't think the problem is the SPA itself, it's bad design patterns that that make it terrible as you say. I think really clean, performant SPAs can definitely be written and I think the overall experience of using a SPA can be much better than a multi-page site if the task at hand requires it. There should be two parts of the web now really: * Traditional multi-page websites * SPAs that could have been a nativ…

The alternative to SPAs is not 90s pages reloads. Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

Re: SPAs Were a Mistake

#607

Post by midrus »

apatheticonion wrote: post #391
simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

I really view it as the opposite. Prefer the writing of an SPA or serverless MPA. If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work. Part of the reason this is effective is because of the low cost nature of deploying applications like this. For example; I can write a calorie counter that…

You're describing an actual client side (mobile or desktop) application made with web technology, not a web application. That's a fair use of SPA tech.

As soon as you need authentication, showing data across users, allowing visitors to see shared data, perform validation of inputs, send notifications when other user action happens, etc you're back in SPA hell.

Re: SPAs Were a Mistake

#608

Post by midrus »

shroompasta wrote: post #577
tored wrote: post #548

Earlier quoted context omitted.

> There has to be a good majority of us here that has worked on something complex that required SPAs here, no? You can still create a something complex without using any of the common SPA techniques, instead you can use things like Hotwire, Livewire, htmx instead.

not practical for hiring. and although I find it intriguing that hey.com is using Hotwire, it's still insignificant compared to some SPA framework's ecosystems. Performance isn't an end all be all, otherwise we should make another article and say "Python and PHP was a mistake for web servers" There is some give to be had for the sake of practicality.

I'd say it is very practical for hiring, as you will need just 1 or 2 developers that knows JavaScript and (Rails|Laravel|etc..) for every 4 or 5 you'd need otherwise (some that know JS, some that know backend, and some to coordinate/manage them).

Re: SPAs Were a Mistake

#609

Post by midrus »

Graffur wrote: post #597
lolinder wrote: post #398

Earlier quoted context omitted.

We have a PHP app that doesn't reload the full page. We use jQuery's .load(), which has been around since 1.0: https://api.jquery.com/load/

Okay - build a complex site with JQuery and see how it goes..

Then you can use Livewire, Unpoly, or HTMX. MVC doesn't mean 90s style reloads anymore.

Re: SPAs Were a Mistake

#610

Post by midrus »

hombre_fatal wrote: post #17
Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things. Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be…

> Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.

In my experience, every single team I've been part of that was building an SPA was because they put the developer experience and desires first, even if in the mid/long term the dev experience ends up being worse as the project grows.

Post reply on HN