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

431–440 of 637 posts

Re: SPAs Were a Mistake

#431

Post by whatshisface »

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

That's a story I'm familiar with, but I am not actually aware of any (major, commonly used) tools that were created out of boredom. I only see instances of people using existing tools when they are not necessary out of boredom.

Re: SPAs Were a Mistake

#432

Post by Nextgrid »

gefhfffh wrote: post #403

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.

This is irrelevant in practice because the SPA's code is also loaded from the server - if the server is malicious it'll just serve you backdoored JS, unless you load from a separate domain and have the main server allow cross-origin requests.

If you want to defend against a malicious server you need to make sure your client doesn't load & execute code from said server - it needs to be distributed as a stand-alone application instead of in a browser.

Re: SPAs Were a Mistake

#433

Post by Nextgrid »

jtsiskin wrote: post #123
Jenk wrote: post #18

It should be obvious why SPA/PWA frameworks were developed by the likes of facebook and Google: Offloading their content rendering to the client. Instead of Google/Facebook CPU cycles being spent on rendering their content, it's now the client devices, while the Google/Facebook infrastructure is "just" serving the data.

This is completely inaccurate. Every millisecond of load time affects conversion so much that they would trade huge amounts of CPU to speed up a page load.

Until you have a monopoly, at which point conversion rates don't matter or rather don't change despite terrible UX.

Re: SPAs Were a Mistake

#434

Post by Nextgrid »

Graffur wrote: post #351
stevebmark wrote: post #49

Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet. SPAs and Jamstack favor developer convenience over end user experience.…

> developer convenience This is really, really important though.

Am I the only one preferring good old-school, "boring" stacks that I can run entirely on my own machine if needed and understand the sequence of operations as opposed to relying on dozens of third-parties, services, APIs, etc just to do what a stupid PHP script on shared hosting could do 20 years ago? I don't consider the modern complexity as convenience.

Re: SPAs Were a Mistake

#435

Post by rvr_ »

I am mostly on the SPA-hating camp. There are two issues that annoy me the most. They are not a framework's fault but some kind of "mental model" fault:

First. When doing SPAs, APIs tend to leak a lot more info than needed, opening the door to attacks not commonly seen on server-rendered pages.

Second. Applications' bundle tend to have way more than users needs, even UI's they should not have access due to security/permissions. Most developers are not even aware of this problem and don't know that sensible info/features/endpoints are leaking.

As I said before, those are not faults at the framework level, but the development style that I seed used when making SPAs always led to them.

Re: SPAs Were a Mistake

#436

Post by Nextgrid »

nawgz wrote: post #94

"SPAs were a mistake" Meanwhile essentially every major tech property develops SPAs and users enjoy them far more than traditional hypertext web round-trip-every-change pages

> users enjoy them far more than traditional hypertext web round-trip-every-change pages

"Major tech" often monopolizes its market so it's not really fair to say users enjoy it when there aren't any alternatives.

Re: SPAs Were a Mistake

#437

Post by stevage »

>This is, in theory, supposed to result in web apps that feel as fast and snappy as native apps.

What a bizarre premise. We don't build SPAs as alternatives to native apps. We build them as alternatives to server rendered web apps.

Re: SPAs Were a Mistake

#438

Post by coruja »

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 try to tell myself "don't get caught up in using a fancy frontend framework on this one," as I'm starting a new project, but I keep running into situations where my functionality would just work so much better.

As an example, I was writing a tool the other day to automate some things that have to do with quotes for my 9-to-5. Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin. My point is, this feels like very basic functionality, but turned into a whole other ordeal using traditional methods.

Re: SPAs Were a Mistake

#439

Post by stevage »

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…

Speaking for myself, I find it much quicker and easier to build an SPA than a server rendered app. You seem to take the stance that server rendered is the default, normal way to architect and SPA requires justification for its aberrant departure from the norm.

SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.

Re: SPAs Were a Mistake

#440

Post by lolinder »

stevage wrote: post #439
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…

Speaking for myself, I find it much quicker and easier to build an SPA than a server rendered app. You seem to take the stance that server rendered is the default, normal way to architect and SPA requires justification for its aberrant departure from the norm. SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.

> SPA have lots of advantages: fewer languages to learn, easier to deploy, etc.

The two examples you give are only true if you don't have a backend at all. As soon as you have a backend, you're back to having to pick a backend language and deploy a backend server.

If your app doesn't need a backend, then I'd agree that an SPA is the way to go.

Post reply on HN