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

631–637 of 637 posts

Re: SPAs Were a Mistake

#631

Post by CRConrad »

apatheticonion wrote: post #391
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 really view it as the opposite. Prefer the writing of an SPA or serverless MPA. If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work. Part of the reason this is effective is because of the low cost nature of deploying applications like this. For example; I can write a calorie counter that…

> Consider that Photoshop and Office are accessible on Linux via web today.

Never used Photoshop, but Office on the web still sucks compared even to native MS Office.

Re: SPAs Were a Mistake

#632

Post by CRConrad »

zerkten wrote: post #266
manigandham wrote: post #237

Earlier quoted context omitted.

What’s wrong with razor pages? They’re fantastically simple and productive. And WebForms wasn't a misunderstanding. It was a deliberate and brilliant design that brought WinForm developers and their experience to the web and allowed them to build complex web apps two decades ago that still work to this day.

It's contextual. For me, WebForms fell down because it let the average web developer impose too many "costs" on internet-facing projects. A WinForms developer is a very specific kind of developer with a high focus on development of internal, or line-of-business (LOB) apps. WebForms also excelled at this, but brought more reach as people moved away from a preference for desktop apps. The height of WebForms coincided w…

> people moved away from a preference for desktop apps.

Who did; which "people"?

Corporations and "Web developers" maybe; users never asked for it AFAIK.

Re: SPAs Were a Mistake

#633

Post by CRConrad »

jkcxn wrote: post #276
dlisboa wrote: post #155

Earlier quoted context omitted.

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

Yes this is exactly right. What I’ve done in the past is use Django to return HTML with JSX mixed in, and have a super lightweight SPA frontend that just hydrates the react components on each load. You can also use form state to communicate back and forth with the server, where sending a response doesn’t refresh the entire page, just a react render diff. With this you get the best of both worlds where your backend ca…

> I have a library I’ve been playing around with for 2 years now, I should package it up

Please do.

Re: SPAs Were a Mistake

#634

Post by CRConrad »

catlifeonmars wrote: post #618
recursivedoubts wrote: post #589

Earlier quoted context omitted.

HATEOAS was and is implemented widely and effortlessly in hypermedia , since Fielding was describing the existing web architecture. It has failed fairly dramatically in JSON APIs, because JSON is not a native hypertext. Early API designers tried to shoehorn HATEOAS concepts into their APIs, which was somewhat plausible when APIs were XML, which, when squinted at, looked sort of like a hypermedia. Once we kicked over…

I’m not arguing against that, just that huge chunks of the web break the HATEOAS abstraction, as it were, and yet, as you pointed out, “the web is pretty successful overall”. It’s not super clear to me that this is because of hypermedia or not in the sense that correlation is not causality.

The Web went all JavaScript instead of HTML sometime between 2000(2005?) and 2010(2015?). But by 2000 it was already wildly successful, so apparently it must have been HTML -- "hypermedia" -- that was the key to success, not JavaScript / JSON.

Re: SPAs Were a Mistake

#635

Post by [deleted] »

kshahar wrote: post #622

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

[deleted]

Re: SPAs Were a Mistake

#636

Post by apatheticonion »

midrus wrote: post #607
apatheticonion wrote: post #391

Earlier quoted context omitted.

I really view it as the opposite. Prefer the writing of an SPA or serverless MPA. If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work. Part of the reason this is effective is because of the low cost nature of deploying applications like this. For example; I can write a calorie counter that…

You're describing an actual client side (mobile or desktop) application made with web technology, not a web application. That's a fair use of SPA tech. As soon as you need authentication, showing data across users, allowing visitors to see shared data, perform validation of inputs, send notifications when other user action happens, etc you're back in SPA hell.

Why do any of those attributes put you in SPA hell?

If you were to write an Android application that featured Authentication, would you also be in "app development hell"?

Languages, performance and UI decorations aside - it's basically the same thing, no?

Re: SPAs Were a Mistake

#637

Post by tracker1 »

com2kid wrote: post #458
tracker1 wrote: post #378

Earlier quoted context omitted.

I can say I've seen a lot of state management issues with SPAs... more with Angular than React, and almost none when using React+Redux well. I think a part of this is that a lot of developers simply don't desire, want to, get to or otherwise take the time to understand the framework they are using... It has been true forever... I can't tell you how many times I've seen stuff copy/pasted from StackOverflow, by devs th…

React+redux well is a huge if. Last time I used redux, about 4 years ago, every tutorial on it demonstrated a completely different way of using it. I spent a week piping a couple dozen form inputs through redux. Throw typescript in there and life got more complex. Maybe it sucks less now. But I've seen plenty of websites where every key press causes crap tons of state to get copied around because "lol const only". I'…

The biggest issue I've seen with things like that, is certain actions with form validation can have unexpected surprises on keypress... so depending on how you're doing form validation, that is usually what will throw off the timing and things drop to a crawl.

Often, if you have a form action button, separate from your validation, best to update state as part of on-change or isolate form state until the action button itself is pressed to push to the redux state.

But I do understand the sentiment... I've run apps, and even forms with some relatively complex and large state via redux without much issue. The biggest hurdle is often getting everyone working on something to understand how redux works, and how the difference comparison works for state changes. Also, dealing with when/where an action should be created/dispatched, how to use the thunks for async handlers, etc.

Post reply on HN