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

491–500 of 637 posts

Re: SPAs Were a Mistake

#491

Post by porker »

ehnto wrote: post #484

I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic dat…

This. I'm keeping an eye on the newer server side renderings like Remix because most of the time what I want is to be able to write components and have them render to HTML, with a few remaining interactive.

If Web components had got this right we the developers could have been happy and using composable components a decade ago.

Re: SPAs Were a Mistake

#492

Post by int_19h »

emteycz wrote: post #216
sitzkrieg wrote: post #191

Earlier quoted context omitted.

ok dont look up how long grid layout has existed in wpf

Who cares? (I know btw I used to be a C# engineer in my previous life - I actually first used WPF when it was still beta) Here and now, WPF is much worse. Even Microsoft itself now invests into React Native.

WPF hasn't had any serious investments for, what, 10 years, no?

But OP's point still stands - it is much less hacky than anything in the web ecosystem even so.

Re: SPAs Were a Mistake

#493

Post by cjohnson318 »

If our whole industry is wrong about SPAs, and a whole generation is wrong about SPAs, what is the best practice then? Does anyone have a comprehensive resource on the right way to do things?

Re: SPAs Were a Mistake

#494

Post by winrid »

The worst is when you have to use a piece of tracking or support software in your product and it pulls in a whole SPA with its own react/angular/whatever even when nothing is shown...

Re: SPAs Were a Mistake

#495

Post by int_19h »

freedomben wrote: post #255
gowld wrote: post #80

Earlier quoted context omitted.

Have you tried to use a site that reloads all the data on every click, from a slow, distant (high latency), or metered connection? Same problem.

Of course, and it's usually not as big of a problem because everything you need comes in the page render. With SPAs it's not uncommon to have to click 5 or buttons/menus and then wait for data to load, then click again, and more data. That said there are plenty of SSR sites that are terrible too. It's not the technology that's at fault, but SPAs and common dev patterns in the community definitely enable and encourage…

Worse yet, with a traditional web app, you are in control of loading the page - or stopping the load, for that matter. With an SPA, it does all those requests in the background. Many apps fail silently (as in, don't refresh) if request to the backend fails.

Re: SPAs Were a Mistake

#496

Post by finniananderson »

ksec wrote: post #472
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.

Smart and YOUNG , seek and try to conquer complexity, pushing open The Gate of Truth. Only to be completely consumed and burned by it. There are abundance of smart people. Wisdom, has and possibly always will be in short supply.

> Smart and YOUNG

I'm 21 :-)

Re: SPAs Were a Mistake

#497

Post by Someone »

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…

> SPAs are great for a number of reasons:

> [...]

> 2. You need a beefier backend.

I don’t work on front-end and am trying to learn from this thread, so I may misunderstand, but that doesn’t look like an advantage to me. Doesn’t “beefier backend” imply “higher costs”?

Re: SPAs Were a Mistake

#498

Post by fireant »

int_19h wrote: post #489
ehnto wrote: post #484

I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic dat…

But components in web apps aren't really new. That's what ASP.NET and JSF was all about, waaaay back when.

Having worked with ASP.NET and other templating engines way back when and now working with React, I can say that there is a world of difference between the ease of composability of ASP.NET templates and React components.

People really want composability and sometimes they need a tiny bit more interactivity than their server rendered stack offers without hacks (even if it's just more interactive forms)

Re: SPAs Were a Mistake

#499

Post by s17n »

s17n wrote: post #370
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…

This is missing the real reason that people write SPAs, which is that React solved web components, which are hugely beneficial for almost 100% of web sites, and thus became the standard for building web sites, and with React it's easier to make an "SPA" than to make a "traditional" site and users don't know or care either way.

Also the React programming model is brilliant.

Anyway the point is that people write SPA's because of React, not the other way around.

Re: SPAs Were a Mistake

#500

Post by ehnto »

porker wrote: post #491
ehnto wrote: post #484

I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic dat…

This. I'm keeping an eye on the newer server side renderings like Remix because most of the time what I want is to be able to write components and have them render to HTML, with a few remaining interactive. If Web components had got this right we the developers could have been happy and using composable components a decade ago.

I agree, I'm am pretty disappointed by how web components turned out. I still use them actually, on personal projects. But that developer experience is absolutely not where it needed to be, then the cool kids showed up and stole their lunch.
Post reply on HN