Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

271–280 of 637 posts

Re: SPAs Were a Mistake

#271
ANY modern site uses something like nextjs or any other static site generator. The q is then if you make the site isomorphic or not and how the need for dynamic content looks.

There are no other viable options today for large professional sites.

If you have the problems described in the article you probably are not using a web framework.

Re: SPAs Were a Mistake

#272

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…

Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand. I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection. Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to se…

>Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on

This doesn't happen because the browser caches the last page.

Re: SPAs Were a Mistake

#273
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

Big tech companies love wasting money and developing a SPA is a good way to do that. Whether users prefers SPAs or not is debatable. Amazon, Github, and Aliexpress aren't SPAs because poor usability will cause users to move to competitors. If Hacker news turned into a SPA, I guarantee that it would suck big time. SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems.

> Github

In what world is this not an SPA? I don't see page transitions hardly anywhere, except when you're switching from marketing material to repos maybe.

Additionally, the fact that GitLab (which is devops/issue tracking/wiki/etc.) ISN'T an SPA drives me crazy every day. I have to wait for so many rerenders that could just be seamless loads, it's actually insane to me how unoptimized of a user experience it is, especially when my happy path is super clear with respect to what content I load.

> SPA developers seem to be living in a tiny bubble oblivious of simple solutions to simple problems

I think it's hilarious who you consider to be living in a bubble, and what simplicity really means. Client side interactions need to be smooth. Web applications are consistently and increasingly presenting meaningful user workflows that can be made more resilient and responsive with SPAs. I develop tools for dataflow/workflow editing, scheduling, visualization, etc., and the idea that these things can be made to feel good without a dedicated client layer is truly an archaic attitude.

Re: SPAs Were a Mistake

#274

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.

But it is so strange, most SPA's are basically just power point presentations. Why did it go like that? It isn't like people look for programmers to replace their power point presentations or PDF's, but for some reason that is exactly what they do on the web.

Re: SPAs Were a Mistake

#275
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.

Interesting that you use Github as an example, when Github is not an SPA. So basically just admitting these problems aren't necessarily inherent to SPA's, but to the developers/teams building them. They may just be a bit harder to get right in SPA's.

Re: SPAs Were a Mistake

#276
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…

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 can do the heavy lifting where everything it needs to decide on the view is all in one place, and your frontend just comprises of really really generic JS components.

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

Re: SPAs Were a Mistake

#277
post #264
post #215

Earlier quoted context omitted.

But browsers absolutely do keep the form filled unless your HTML or JS says otherwise. Pressing back after submitting on a vanilla HTML form keeps all values in place. As it should.

Not after a post. If you change the form method to get, I believe this is the behavior. There are tons of good reasons to prefer this behavior, aside from just avoiding duplicates. Think of login forms.

Yes, even after POST. Why not try it, right here, on Hacker News. The comment form uses POST. I post this comment and go back and my text is still in the input box.

In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.

Re: SPAs Were a Mistake

#278

Earlier quoted context omitted.

At least since HTML5 and CSS3 and ES6 (so many years already) these technologies are made for SPAs. There aren't many better UI frameworks, and WPF isn't that by a long shot.

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

I mean, grid layout has existed in Tk (the one with the Motif look) since the earliest version I can quickly find documentation for, 8.2 from August 1999; Wikipedia tells me that 'table', apparently an early version of 'grid', was introduced in July 1993, that is to say around the time Windows NT (and with it Win32) was officially released. (And of course plain Win32 never got it, seemingly because Microsoft decided they weren’t in the business of selling toolkits despite USER being one.)

The hard idea from the programmer’s point of view is automatic layout, not grids; my impression was that Tk originated it (it certainly brought it to light), but now that I’m looking I’m not sure it wasn’t already in Motif to some extent, so the roots of the idea might go down into the primordial soup of Project Athena and similar places.

Re: SPAs Were a Mistake

#279
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…

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…

this seems to be approximately what https://htmx.org/ is trying to accomplish.

Re: SPAs Were a Mistake

#280
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

GitHub is a great example of a site that would benefit from actually being an SPA, imo. It is server rendered pages with JS sprinkled in, and you can easily end up in the situation where parts that live update fall out of sync with parts that don't. For example, being able to see that an issue is closed while the badge on the Issues tab still says you have one open.

I share your general sentiment over the state of them though. It's not actually that hard to avoid breaking navigation buttons, having links open in new tabs correctly etc, so I don't know how it gets screwed up so much.

Post reply on HN