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

401–410 of 637 posts

Re: SPAs Were a Mistake

#401

Post by tracker1 »

gefhfffh wrote: post #395
tracker1 wrote: post #378

Earlier quoted context omitted.

I can say I've seen a lot of state management issues with SPAs... more with Angular than React, and almost none when using React+Redux well. I think a part of this is that a lot of developers simply don't desire, want to, get to or otherwise take the time to understand the framework they are using... It has been true forever... I can't tell you how many times I've seen stuff copy/pasted from StackOverflow, by devs th…

Tried ngrx?

Yeah... it's decent, but there are many, many other reasons why I'll never touch an Angular app again.

Re: SPAs Were a Mistake

#402

Post by lolinder »

gefhfffh wrote: post #399
lolinder wrote: post #394

Earlier quoted context omitted.

> Doesn't really sound like an application, but a website. "text" here is as in "text/html", not as in "English-language copy". > In a web app it can happen that you use it for an hour without the backend doing a single thing. I would submit that this is an extremely rare case. The most involved web apps I interact with (say, Figma) are constantly syncing their state with the server. The simplest (say, TurboTax) save…

I haven't said that something isn't an app, unless it can go long periods of time without server interactions. Generally, server interactions are arbitrary with SPAs, while SSR will happen all the time. Going only a few minutes without server interactions in an interactive app is a big leap compared to SSR. PS: I not only can pull that off, but I did. It's not too hard to think of apps like that. Consider e.g. Vscode

If the app is VSCode or anything like it, that's a great candidate for an SPA and I agree wholeheartedly that you made the right choice.

Re: SPAs Were a Mistake

#403

Post by gefhfffh »

I wonder how you would build an encrypted messenger like like Element (app.element.io) without SPA style.

I think it's not even possible, since you are required to process incoming messages client side and must not send any private keys to the server.

Re: SPAs Were a Mistake

#404

Post by PeterisP »

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

> Doesn't really sound like an application, but a website.

That's probably the key thing - most companies building SPA's don't really need an application but a website. There are many interesting products that need to be applications because of the functionality they need, but for every one such product there's at least a dozen that does not.

Re: SPAs Were a Mistake

#405

Post by harel »

Using them for everything and everywhere as a default option might have been a mistake. SPAs in general are not a mistake (but generalised headlines do bring in the clicks so there's that).

As a user, when I'm using an "application", on the web or the desktop, the last thing I want is for the entire UI to be reloaded for me after every action. For applications it makes sense to be run on a single page, fetching only the data when it's required and that's it.

Re: SPAs Were a Mistake

#406

Post by simonw »

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…

A calorie counter using IndexDB is a great example of something where an SPA is appropriate - like I said, "default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit".

I mainly work in the world of database-backed websites and applications, where going client-only without a backend isn't an option.

Re: SPAs Were a Mistake

#407

Post by blakehaswell »

v0idzer0 wrote: post #386

I usually bite my tongue when these articles pop up weekly, but let’s ask ourselves a question: did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something? I’ve recently worked on converting a large code base to an SPA and the improvements in DX, UX and performance are enormous. Even the old timers that resisted the project have all come aroun…

> did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake?

Is that so impossible? There are many other considerations that go into technology choices at these companies. There are trade-offs involved, and for companies with huge teams of developers the considerations need to be very different than for small–medium sized groups of developers.

I would argue that a smaller group of developers can focus much more on user experience and engineering efficiency, whereas a large company has a organisational scaling issues and a significant bureaucracy to support. At a large company, engineering considerations come second to very many things. It would actually be surprising if the trade-offs and choices those companies made were correct for other very different companies.

Re: SPAs Were a Mistake

#408

Post by timr »

fuzzy2 wrote: post #326
timr wrote: post #313

Earlier quoted context omitted.

Redirect after POST was a pattern created to bypass the warnings that (most) browsers emit on back-navigating after form submit, while still preventing double-submit (by redirecting to the GET): https://www.theserverside.com/news/1365146/Redirect-After-Po... It sounds like this warn-on-double-submit behavior is convention and not required, so maybe it has become more common for browsers to stop doing it. > Why not tr…

> When you back nav, you are seeing the response to a GET request to /reply?id=BLAH With the text you previously entered, which the browser restored. If it did not for you, you have non-standard settings like disabled caching. I can assure you that it behaves the same on Firefox for Linux, Windows, macOS and Safari on iOS: go back, form content is restored. In fact, the entire internet is full of people trying to get…

I don't have non-standard browser settings. I watched the form submit in the debugger. It responds with a 302 to the GET request.

Re: SPAs Were a Mistake

#409

Post by metta2uall »

This is probably true if you're writing an SPA from scratch, but in reality much of that complexity is handled by libraries like Next.js. I also think it's much easier to learn a React-like library than to learn various server-side template frameworks..

Re: SPAs Were a Mistake

#410

Post by tshaddox »

simonw wrote: post #350
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…

"A website has to go out of its way to mess this up." I know it's supposed to be easier, but I keep seeing teams mess this up.

I just don't know how it could be made any easier to not mess up. You really truly do need to go out of your way to mess it up, or be entirely unfamiliar with the JavaScript routing framework or library you're using.
Post reply on HN