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

451–460 of 637 posts

Re: SPAs Were a Mistake

#451

Post by mo_s_i212 »

I'm building business application at my job. Users navigate (filter, configure, visualize 3D models) huge lists of data (bill of material, product structures). SPAs are heaven sent. Delegating every filter or configuration action to the server would be insane. Same with server side paging. Another example is 3D viewing: When selecting a part in the viewer detailed data should be displayed. A round trip to the server for this? No, thank you.

I have to heavily disagree with this post. Which by the way lacks any in depth arguments.

Re: SPAs Were a Mistake

#453

Post by dzhiurgis »

dlisboa wrote: post #155
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…

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

Any non-trivial app will require some frontend state eventually.

Re: SPAs Were a Mistake

#454

Post by nrb »

tored wrote: post #442
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…

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.

Re: SPAs Were a Mistake

#455

Post by dzhiurgis »

ithrow wrote: post #236
dlisboa wrote: post #155

Earlier quoted context omitted.

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.

The old mythical man month strikes back. Best devops is no ops. Best team is no team.

Of course eventually you need more people and I don't love anyone touch my code, but I'd rather have someone incompetent do entire stack that at least I can review than spend weeks upon weeks communicating basic assumptions.

Re: SPAs Were a Mistake

#456

Post by rrrhys »

lolinder wrote: post #376
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…

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…

> Your arguments seem to be assuming a particularly bad implementation of a traditional backend.

These weekly SPA complaint threads always assume a particularly bad implementation of a SPA as well though.

Re: SPAs Were a Mistake

#457

Post by code_duck »

I just wanted to note that the example - YouTube - is not an SPA. A click on a video from the homepage loads a distinct page, along with user profiles and other areas of the site.

Re: SPAs Were a Mistake

#458

Post by com2kid »

tracker1 wrote: post #378
simonw wrote: post #350

Earlier quoted context omitted.

"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 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…

React+redux well is a huge if.

Last time I used redux, about 4 years ago, every tutorial on it demonstrated a completely different way of using it.

I spent a week piping a couple dozen form inputs through redux.

Throw typescript in there and life got more complex.

Maybe it sucks less now. But I've seen plenty of websites where every key press causes crap tons of state to get copied around because "lol const only". I've seen sites where typing takes a second per character due to mis use of redux, and the problem with redux is that it is easier to misuse than to use properly.

Re: SPAs Were a Mistake

#459

Post by [deleted] »

rrrhys wrote: post #456
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…

> Your arguments seem to be assuming a particularly bad implementation of a traditional backend. These weekly SPA complaint threads always assume a particularly bad implementation of a SPA as well though.

[deleted]
Post reply on HN