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

531–540 of 637 posts

Re: SPAs Were a Mistake

#531

Post by szastamasta »

nfw2 wrote: post #514
szastamasta wrote: post #485

What a total nonsense. I’m quite old in our industry standards and remember all this ”great and easy” way of working with backend templates and struggle to find it much easier than working with SPAs. I also thank computer gods for SPAs each time I click in Github and wait for it junky slow interface to reload whole page. Please save us from likes of ROR etc. that is slow and has awful user experience. Just try to use…

"I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps." Have you tried using React Native For Web? The name is so ironic it almost seems like a joke, but I think the rationale is to simplify things as you are suggesting

Yeah it’s a nice idea, but it still has to mess with DOM and css in the end.

I just think that web apps are not web pages. And all this struggle with css quirks and all this power wasted on parsing DOM is not really needed. I know that if what you need is a blog, then html with css is enough. But building interactive apps with backend templates rendering ends up like Github (slow and with bad user experience), or it requires a lot of crazy jQuery hackery we have been doing in the old days. And I’ll pick building a React app any time I have a choice like that.

Re: SPAs Were a Mistake

#532

Post by tored »

int_19h wrote: post #486
nrb wrote: post #454

Earlier quoted context omitted.

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.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Just give the end user an account to phpMyAdmin. Done. No complex frontend framework required.

Re: SPAs Were a Mistake

#533

Post by manigandham »

com2kid wrote: post #329
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…

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

1) JS history handling is fragile. A single error can break navigation completely. There's no built-in loading indicator so sites are left with no feedback or have bloated progress bars. And nothing automatically solves for deep links if the app doesn't use routes for different views or relies on other events instead of hyperlinks.

2) Servers are very fast and assembling HTML is trivial. Browsers are optimized for downloading, parsing and rendering HTML as it streams in. Using JS to write HTML after making multiple network calls is objectively slower than a single network request that assembles everything on the server close to the datastore with minimal latency.

3) Every other language is faster and more capable on the server than JS, and all major web frameworks have modern component-based UI templating. Interactions with roundtrips are just fine, and some light JS can handle most other scenarios.

> "an actual application"

That's the only reason to use a SPA, not what you mentioned.

Re: SPAs Were a Mistake

#534

Post by qw »

int_19h wrote: post #486
nrb wrote: post #454

Earlier quoted context omitted.

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.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Even if you solve the security issue, a query can easily bring down the server if it has a complex join query.

This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.

Re: SPAs Were a Mistake

#535

Post by arvinsim »

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?

Because the majority of developers will gravitate towards tools that will give them the best employment opportunity, not necessarily the best tools for the job.

TL;DR Resume Driven Development

Re: SPAs Were a Mistake

#536

Post by manigandham »

lmm wrote: post #423
bcrosby95 wrote: post #369

Earlier quoted context omitted.

> 1. You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync. If this were true, you wouldn't need a REST API. I don't understand what you're trying to say here. When you make a REST call to get data, you instantly have…

> If this were true, you wouldn't need a REST API. I don't understand what you're trying to say here. When you make a REST call to get data, you instantly have two different sets of state: the client and the server. It's no different from SSR, it's just transmitted in a different data format (json vs html). SSR means you don't have a clear representation of the client-side state (as distinct from the presentation) -…

That state lives on the context of the page. That's the point of having a URL/page lifecycle that reloads the context.

If you need to persist past a reload then a few lines can save to localstorage. Anything more requires server-side calls anyway.

This magical state that can only be managed on the client-side with a heavy SPA is a myth for 99.9% of sites.

Re: SPAs Were a Mistake

#537

Post by manigandham »

ozim wrote: post #357
the_gipsy wrote: post #346

Earlier quoted context omitted.

> 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. 99% of SPAs break history related features in some way.

99% of people don't FRICKING care. Most of the users I have to deal with still have problems with double clicking. They don't understand basic browser features. They don't understand that they can set preferred language in their browser. History related features are not an argument in any way.

Why would people not care that browsing URLs work well?

Re: SPAs Were a Mistake

#538

Post by int_19h »

littlecranky67 wrote: post #513
int_19h wrote: post #486

Earlier quoted context omitted.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Authorization & access restrictions. Yes, you can go quite far with table/row/column permissions, but a lot of business logic cannot be modeled using just those (i.e. "user cannot place orders if total outstanding invoice payments surpass value $X").

Then why aren't we working on improving the databases to allow for such complex rules, and instead wrap it in another layer (often multiple) to do all this stuff there?

Re: SPAs Were a Mistake

#539

Post by tored »

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 a consequence of the SPA design, a bad design leads to a worse fix.

The drawback is that the frontend now has its own schema, often it starts as a naive direct mapping of the real schema.

Thus any changes in the real schema also need to change the frontend schema and every use of it, or the mapping to the frontend schema needs to change.

Eventually these two schemas will diverge because it is not feasible that every schema change results in frontend change. Especially if the idea is to have two different teams working from either side, then the backend team can’t wait for the frontend team therefore the schema mapping will change.

And the thing is that the frontend shouldn’t be aware of how the backend schema is constructed, if the User model is separated into three different tables, because of some technical reason, that should not change how the frontend operates. The frontend understanding of what a User is shouldn’t be the same as the backends.

Therefore ideally frontend schema and the backend schema will always differ. They don’t view the world the same way.

However what you now have is a slow mapper between the frontend schema and backend schema.

The point of relationship databases is that you can view your data from different perspective by doing different SQL queries. That is already built in. But now we have invented yet another layer on top of SQL, usually in combination with the already monstrosity called ORM.

Re: SPAs Were a Mistake

#540

Post by dragonwriter »

littlecranky67 wrote: post #513
int_19h wrote: post #486

Earlier quoted context omitted.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Authorization & access restrictions. Yes, you can go quite far with table/row/column permissions, but a lot of business logic cannot be modeled using just those (i.e. "user cannot place orders if total outstanding invoice payments surpass value $X").

The combination of DB permissions, DB constraints, and simple (SQL, not procedural language) triggers gets you a lot, including the ability to enforce rules like the one you mention.
Post reply on HN