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.
271–280 of 637 posts
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.
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…
This doesn't happen because the browser caches the last page.
"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.
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.
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.
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.
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…
I have a library I’ve been playing around with for 2 years now, I should package it up
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.
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.
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
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.
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…
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 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.