|
On the contrary, I generally browse with JS disabled and there's a strong correlation between sites for which this is existentially problematic and sites whose content or utility are garbage. I have a personal toolkit of components I call "you might not need Javascript". Dropdowns, slideovers, toggles, modals, tabs, accordions, autocomplete, lightboxes, all with nice transition animations, and all in pure server-rendered HTML+CSS. A lot of it is just semantic elements being used appropriately. How many developers use <datalist> or <summary>/<details>? or :target and :focus-within? In my experience, not enough. How about, using <details> in combination with a CSS [open] selector? The palette gets rich in combination. Overall, no, it's not hard, but it does require one to study. A couple of times a year, I'll re-read through the HTML LS and CSS specifications. There's a lot in there to build from, and almost all of it has broad evergreen browser support. For the leading-edge stuff, "caniuse.com" remains an essential reference. I currently have my eye on the <dialog> element, high expectations there, works well already in Chrome; Firefox just has a couple of bugs to shake out, and it's experimental (but incomplete) in Safari. All that said: a light dusting of JS can still provide progressive enhancement, but we can limit this to minor cosmetic improvements & optimizations, for browser compatibility, and where dynamic ARIA markup is necessary. The motivation as to why I prefer this style is another matter, and it's do with product strategy, and in particular, not crystallizing your architecture in the front end (where it is brittle) but in the backend (where it is much faster to pivot and/or rapidly prototype/spike/redevelop, by proximity to business logic and persistence schema). These are understandings that've been long (and sometimes painful) in the learning, but they're pretty much universal. |