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

461–470 of 637 posts

Re: SPAs Were a Mistake

#461

Post by enra »

jmconfuzeus wrote: post #224
xwdv wrote: post #55

Earlier quoted context omitted.

This problem you described is exactly why SPAs will continue to dominate over the traditional server rendered websites. Often when I see people arguing against SPAs, they are peddling trivial toy websites that don’t do much and don’t change much. When you need to build a serious application on the web with quickly growing feature sets and complex state management, just use a SPA. It’s 2022.

The Basecamp guys created Hey which is a mail app not implemented as a SPA. It's probably the fastest mail app I've ever seen while delivering around 40kb of javascript. If Hey is a toy app you then you must be working on some truly alien projects from the future or something.

While it might be fast, it feels you’re like using Rails app with turbo links. Page loads. Feels barely interactive.

Compare native Mail app and Hey. If anything should be a SPA, it’s an email app.

Also who cares how much kb of JavaScript your mail app uses? It’s completely wrong metric to optimize for an app someone uses every day, multiple times a day and likely has the app open all the time.

(Also haven’t heard people using Hey much since the launch)

Re: SPAs Were a Mistake

#462

Post by eternityforest »

SPAs are great when you're actually making an app.

It's a little less great when you're just putting a browser in the browser so they can browse while they browse.

Even then sometimes it works when the content is more app like and you don't want to set up a bunch of js and websocket connections with every load.

Maybe we need some new easy to use APIs for JS that persists it's state between pages.

Re: SPAs Were a Mistake

#463

Post by anonymoushn »

dzhiurgis wrote: post #449
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…

> isn't going to increase your CPU load in any meaningful way. yes but it would be soul crushing for a developer

Why?

Re: SPAs Were a Mistake

#464

Post by rtpg »

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…

Multi-page forms without some front end stuff ends up with the very clunky either "rerender previous form pages over and over again, except hidden", or "have some token to track partial form data", or "build up a DB to store a partially complete form".

With some frontend work you can have a multi-page form just work, with the data stored in the client up until final submission, and only sending in partial checks ahead of time. This is qualitatively easier to handle, in my opinion.

It also seems extremely uncontroversial that sending data for a single item is going to require less text generation than sending over that data + the entire page.

These are all gradients, but people make absolute claims that don't hold up in these arguments.

Re: SPAs Were a Mistake

#465

Post by nfw2 »

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…

Most SaaS developers aren't serving APIs to their clients, they are serving websites and web applications.

Applications have state. In order to render and deliver the application, the server needs to have some concept of what that state is.

Re: SPAs Were a Mistake

#467

Post by kristopolous »

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.

You always have to fight with incompetency in any large codebase.

Incompetency exists the most in whatever the first thing that coders learn is.

I'm old enough to remember when that was c++, then it was java, php, ruby, jquery, now it's react.

It's always a trade-off. You can build things in the "cheapest" language (whatever the first one currently is) but then you'll inevitably get the cheapest code

That's really what this conversation is about in the long arc of coding

Skills and people are a pyramid. The more competency you demand the harder the people are to find.

We have this tendency to taint the tool by the users.

Incidentally after a language or tool loses "first learned" status it generally slowly regains its prestige.

We don't assume a c++ shop is a bunch of morons any more or that using php means you write nothing but garbage. One day vue/react/whatever will lose its first language status as well and I'll be here reading about something that might not have been invented yet being a trashy bad no good idea

Ultimately the technical merits are mostly cover for a conjecture of economic efficiency. There's a reason why people aren't defending things like applications built with Go/wasm bridges - those people are expensive

Re: SPAs Were a Mistake

#468

Post by democracy »

I also notice how much longer it takes to build the same crap we built 15 years ago with just html/css/js, and no, projects these days are not more sophisticated. Same old form submissions, but with a monstrosity of a project and crazy rates of devs who wants to constantly upgrade/update/migrate so some newer JS framework :shrugged :evilsmile

Re: SPAs Were a Mistake

#469

Post by ksec »

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…

>Not only do we not seem to be learning from our mistakes

That is a lot of good faith. What happens if they were not mistakes? But deliberate attempt to push Javascript as the one and only de facto approach to web development and Resume Driven Development?

I recently asked this [1],

I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later?

And for some strange reason this mostly happens to Web Development in general.

[1] https://news.ycombinator.com/item?id=30451916

Re: SPAs Were a Mistake

#470

Post by jamesfinlayson »

krisrm wrote: post #308
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 always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.

Also allowing your mobile app to use the same API as the website.
Post reply on HN