7 ms·

To me this article and demo shows why we use SPA's, and how much modern frameworks actual do for you. It's hard to not see a whole lot of very basic problems in

To me this article and demo shows why we use SPA's, and how much modern frameworks actual do for you. It's hard to not see a whole lot of very basic problems in this demo that any modern framework would solve out of the box. The "SPA bad" arguments are also largely outdated. Most apps that are build now are at least hybrid, with some SSR getting best of both worlds, urls and navigation are solved, accessibility is improving with better component libraries linters and best practices, automatic bundle splitting, highly optimized caching of static assets, build tools with hot reloading as a standard option, static exports, etc etc. Getting a good Lighthouse score is not the flex it used to be (referring to the enhance movies demo), my all-JS Next.js app scores 100's without even trying. The only potential argument would be users not having JS enabled, which is not relevant to most apps and use cases. In most cases you do not want to degrade the experience of most (but more likely all) of your users, and with SSR you can have it all. Obviously build for your audience and use cases and apply technology that makes sense and I welcome experimentation with alternative approaches, but saying "spa bad" is imo not very productive.

CSSer 3y ago
When I started in the industry, progressive enhancement as a concept was the theme du jour. As SPAs have gained prominence, I’ve sadly watched the drive to improve them and sometimes pushback against them morph this concept as it’s taught to newcomers into “No JS” or “low JS” as a side effect. It lacks nuance. For example, your menus should work without JS but that doesn’t mean they should work as well as or exactly the same way as they do with JS disabled. There are many features and patterns that a11y/screenreader users (which I recognize I’m somewhat lumping in with the “I disable JS for X reason(s) crowd here) appreciate that are still impossible without JS. I’ve surprised people on a couple occasions by showing them how much JS is actually used to create many of the WAI-ARIA menu proof of concepts[0], for example. I think the “a11y is easy” crowd, well intentioned as it may be, is also partially to blame for this. I’ve read articles with titles like “How to do X with CSS only” that gloss over many UX downsides to the chosen approach. The sad reality is that a11y users represent another audience with a different set of formed expectations one needs to cater to, and fulfilling those expectations is not free more often than some would care to admit, especially when you consider how complex the differences in approaches between screen readers can be. This isn’t an excuse to not help those users, but I have wondered before if we would be doing better if we were more scathing in our commentary on vendor standards as it relates to this. Who knows? Perhaps I’m naive. [0] https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/me...

CSSer 3y ago

When I started in the industry, progressive enhancement as a concept was the theme du jour. As SPAs have gained prominence, I’ve sadly watched the drive to improve them and sometimes pushback against them morph this concept as it’s taught to newcomers into “No JS” or “low JS” as a side effect. It lacks nuance. For example, your menus should work without JS but that doesn’t mean they should work as well as or exactly the same way as they do with JS disabled. There are many features and patterns that a11y/screenreader users (which I recognize I’m somewhat lumping in with the “I disable JS for X reason(s) crowd here) appreciate that are still impossible without JS. I’ve surprised people on a couple occasions by showing them how much JS is actually used to create many of the WAI-ARIA menu proof of concepts[0], for example. I think the “a11y is easy” crowd, well intentioned as it may be, is also partially to blame for this. I’ve read articles with titles like “How to do X with CSS only” that gloss over many UX downsides to the chosen approach. The sad reality is that a11y users represent another audience with a different set of formed expectations one needs to cater to, and fulfilling those expectations is not free more often than some would care to admit, especially when you consider how complex the differences in approaches between screen readers can be. This isn’t an excuse to not help those users, but I have wondered before if we would be doing better if we were more scathing in our commentary on vendor standards as it relates to this. Who knows? Perhaps I’m naive. [0] https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/me...