SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#201

Post by mattmanser » Wed, Mar 02, 2022, 7:29 PM UTC

hughrr wrote: post #178

prmph wrote: post #167

Earlier quoted context omitted.

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective

The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.

Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked.

Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean.

But it's not that much different from Rails, Laravel, Django, etc.

Re: SPAs Were a Mistake

#202

Post by jmconfuzeus » Wed, Mar 02, 2022, 7:30 PM UTC

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

Progress bars and previews are simply a matter of attaching an events to the http request and file input respectively.

When someone submits a form and navigates back, don't you just re-display the empty form?

If it needs to be a form bounded with the uploaded file (maybe as part of a wizard), then why not ask the server for it instead of storing client side state?

Maybe using Javascript without a SPA looks hard because you're trying to avoid storing state on the server as well as bypass native browser features.

Re: SPAs Were a Mistake

#203

Post by gls2ro » Wed, Mar 02, 2022, 7:30 PM UTC

k__ wrote: post #183

While Web2 is moving to SSR, I think SPAs will be a huge part of Web3. SPAs are perfect for decentralized infrastructure like IPFS and friends. Same goes for mobile apps.

What exactly from SPA is making them good for decentralized?

Re: SPAs Were a Mistake

#204

Post by viggity » Wed, Mar 02, 2022, 7:31 PM UTC

gowld wrote: post #198

antihero wrote: post #30

This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser. However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all. Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per…

jQuery days were bad?

there were certainly people that committed war crimes with jQuery. Just like every other framework in existence. I yearn to return, honestly.

Re: SPAs Were a Mistake

#205

Post by myfavoritedog » Wed, Mar 02, 2022, 7:32 PM UTC

te_chris wrote: post #22

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

Phoenix LiveView really does solve a lot of these problems.

No post body was provided.

Re: SPAs Were a Mistake

#206

Post by gowld » Wed, Mar 02, 2022, 7:32 PM UTC

slashdev wrote: post #24

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…

Sure, if you implement a trivial single-task app (one tiny feature of a Calendar app) with an unfriendly UI, you don't need an SPA. That doesn't prove anything.

Re: SPAs Were a Mistake

#207

Post by gls2ro » Wed, Mar 02, 2022, 7:32 PM UTC

bluewalt wrote: post #174

I think one of the main reason SPAs are overused is because it's hard in 2022 for your users to wait after clicking on a link. Users are now used to instantaneous, especially since they all have a smartphone with apps on it. We, as web developers, try to give the best UX to users.

I agree with you and I think there are some good SPAs. In my case what makes me angry is opening a presentation website and seeing a loader because someone decided to make that a SPA.

Re: SPAs Were a Mistake

#208

Post by rosenjcb » Wed, Mar 02, 2022, 7:34 PM UTC

ColonelPhantom wrote: post #192

rosenjcb wrote: post #184

Earlier quoted context omitted.

No, the template is usually a static file that is read into memory and served over HTTP or locally if it's a JS only site. But before being served, it's being picked at via imperative operations. And if it's really bad, then when a user presses a button it triggers some event that actually statefully changes the view itself.

I don't see template operations as imperative, rather I see them as declarative: you write the HTML and declare lists/placeholders inside the HTML. You also don't generally do much with the data except insert it into HTML; the rest of the backend is responsible for fetching/etc the data.

Yeah, but the function itself doesn't return that view. The framework you're working in essentially composes the view based on the associated code and template. This is fundamentally different from just returning the view itself in the function. These are all declarative approaches, but leaving your view in code is a lot better.

Every template-based framework I've seen has involved a lot of magic, syntax and DSL. That's not to say that JSX isn't a DSL as well but you can return regular React.Elements just as easily. You shouldn't need to remember a unique expression system just to be able to conditionally render. The premise that you're just not doing much with the data except dumping it into HTML is less true the more complex your site becomes. Think of the loads of conditions and evaluations that happen when you go to your Facebook wall or friends list.

Re: SPAs Were a Mistake

#209

Post by hunterb123 » Wed, Mar 02, 2022, 7:34 PM UTC

This opinion gets reiterated over and over and it's still wrong no matter how many times you say it. SPAs are just apps.

I'm sorry people can't tell the difference of when you need a site and when you need an app. That doesn't make web apps a mistake.

Re: SPAs Were a Mistake

#210

Post by tmcw » Wed, Mar 02, 2022, 7:35 PM UTC

wooque wrote: post #101

I, as a user, hate them with passion. I regularly stumble upon stale data in SPAs, even in big names' like Linkedin, Jira, Github, etc. I wonder how the hell corporations with thousands of engineers, lot of them being brightest engineers in the world, can't make proper SPA. Can we just go back to server side rendered pages, with a bit of JS sprinkled in, please.

Github is not an SPA. They use the middle road of dynamically loading HTML snippets, using webcomponents, and lightweight JavaScript. Any problems you see with most of Github's interface should be chalked up to server-rendered pages with sprinkled JS.