SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#621

Post by kshahar » Sun, Mar 06, 2022, 6:43 PM UTC

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?

What approach did you take with real-time collaboration and interactivity? Is that part still rendered client-side?

Re: SPAs Were a Mistake

#622

Post by kshahar » Sun, Mar 06, 2022, 7:00 PM UTC

If not SPA, which technologies would you suggest for a web app similar to an IoT dashboard, with gauges and other UI elements that update every second? The server is written in ASP.NET Core.

I was considering Blazor server side but it does not seem to be very popular (compared to react, Vue, angular, etc) and I am not sure it's a good choice for the long term (MS likes to kill UI technologies). Approaches like htmx and unpoly do not seem to be appropriate if a large portion of UI needs to update frequently (feels similar to implementing the Blazor approach but inefficiently).

Re: SPAs Were a Mistake

#623

Post by yencabulator » Mon, Mar 07, 2022, 2:34 AM UTC

int_19h wrote: post #620

yencabulator wrote: post #619

Earlier quoted context omitted.

Mostly because the tooling is so bad. Or do you have unit tests, lint, and easy version control for your stored procedures? Are they written in a way that matches at all what rest of your programming is? Can you import a randomly picked utility library?

The next obvious question is, why is tooling so bad then? And would it have been so bad if we invested as much into RDBMS as we did into Node.js web-frameworks-of-the-day.

Writing the next modern elegant artisanal javascript webshit is a lot easier than making a sandboxed programming environment that integrates tightly with a production quality database engine and has a good story for testing, deployment, debugging, etc.

Re: SPAs Were a Mistake

#624

Post by lmm » Wed, Mar 09, 2022, 12:33 AM UTC

manigandham wrote: post #596

lmm wrote: post #586

Earlier quoted context omitted.

> If you need to persist past a reload then a few lines can save to localstorage. Sure, and pretty soon you've got a dozen random little copies of bits and pieces of your state, all out of sync with each other. > Anything more requires server-side calls anyway. The issue isn't whether you need server-side calls (ultimately every webapp needs server-side calls, otherwise why would it be a webapp at all?), the issue is…

There's usability benefit in reloading to reset state and it's the common expectation when browsing. Regardless, if you do decide to add it then its a few lines of code to persist all forms on the page. SPAs don't automatically provide any state management, and often the complexity requires even more work to manage forms. This is the complaint here, taking a simple requirement and forcing a webapp into it. It's compl…

Many SPA frameworks do provide state management. If you start from the idea that you want structured client-side state management for your webpages, you'll probably land on an "SPA framework". And if you're using such a framework, while I'll always advocate things like proper URLs and history (which the framework should handle for you), forcing a page reload when it's not needed seems pretty wasteful.

Re: SPAs Were a Mistake

#625

Post by neon_electro » Thu, Mar 10, 2022, 2:00 AM UTC

lolinder wrote: post #440

stevage wrote: post #439

Earlier quoted context omitted.

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.

I think the person you're replying to is implying using JS/Node for both front- and back-end.

Re: SPAs Were a Mistake

#626

Post by CRConrad » Sat, Mar 12, 2022, 4:45 PM UTC

gefhfffh wrote: post #390

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…

> a bit of extra text Doesn't really sound like an application, but a website. In a web app it can happen that you use it for an hour without the backend doing a single thing. > There are only fewer languages to deal with if you aren't in charge of writing backend code. You don't have to deal with them at the same time

> Doesn't really sound like an application, but a website.

Yeah, well, from the name of it, doesn't that sound like what the Web is for?

I mean, we already have systems to run applications on; they're called operating systems.

Not only SPAs but "web applications" as a whole are a mistake IMO.

Re: SPAs Were a Mistake

#627

Post by CRConrad » Sat, Mar 12, 2022, 4:48 PM UTC

dzhiurgis wrote: post #519

anonymoushn wrote: post #463

Earlier quoted context omitted.

Why?

I’m not experienced with best in class tooling (probably with worst) but seems very quick, easy and native to render html using js.

> seems very quick, easy and native to render html using js.

Seems even quicker, easier and "more native" to render HTML as, you know... HTML.

Re: SPAs Were a Mistake

#628

Post by CRConrad » Sat, Mar 12, 2022, 5:39 PM UTC

ozim wrote: post #572

manigandham wrote: post #537

Earlier quoted context omitted.

Why would people not care that browsing URLs work well?

Because they don't care about computer stuff. They just have to do computer stuff because they are forced to.

Shit you gotta do not because you want to but because you have to, you care even more that it works without hassle.

This is so obvious that not seeing it is weird, and claiming not to see it is weirdly defensive.

Re: SPAs Were a Mistake

#629

Post by CRConrad » Sat, Mar 12, 2022, 6:41 PM UTC

finniananderson wrote: post #496

ksec wrote: post #472

Earlier quoted context omitted.

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 :-)

> > Smart and YOUNG

> I'm 21 :-)

No problem, you'll be young in a few years.

Re: SPAs Were a Mistake

#630

Post by CRConrad » Sat, Mar 12, 2022, 7:15 PM UTC

shroompasta wrote: post #502

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 mean, of course the co-creator of Django would say this. I wouldn't recommend newer generation of developers to build traditional web apps, let alone use jQuery. I don't understand why people think we're still in the age of form submissions and blog posts - There has to be a good majority of us here that has worked on something complex that required SPAs here, no? Not only would it be detrimental to a young develop…

> I don't understand why people think we're still in the age of form submissions and blog posts

Because we are.

> There has to be a good majority of us here that has worked on something complex that required SPAs here, no?

No. Because complex stuff doesn't require SPAs.