A Web Component UI library for people who love HTML | Go Make Things
I’m obviously biased, but I like the sound of what Chris is doing to create a library of HTML web components.
Link tags: progressive
523
Hiding elements that require JavaScript without JavaScript :: dade
This is clever: putting CSS inside a noscript element to hide anything that requires JavaScript.
A pragmatic browser support strategy | Go Make Things
- Basic functionality should work on any device that can access the web.
- Extras and flourishes are treated as progressive enhancements for modern devices.
- The UI can look different and even clunky on older devices and browsers, as long as it doesn’t break rule #1.
Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read”. - Tantek
Practice Progressive Enhancement.
Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.
All content should be readable without scripting.
If it’s worth building on the web, it’s worth building it robustly, and building it to last.
mirisuzanne/track-list: Enhance a list of audio tracks with playlist controls
This is very nice HTML web component by Miriam, progressively enhancing an ordered list of audio elements.
The web on mobile (a response) | Clagnut by Richard Rutter
Rich suggests another reason why the UX of websites on mobile is so shit these days:
The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.
A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?
Build for the Web, Build on the Web, Build with the Web – Web Performance and Site Speed Consultant
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
Progressive enhancement brings everyone in - The History of the Web
This is a great history of the idea of progressive enhancement:
It is an idea that has been lasting and enduring for two decades, and will continue.
Your App Should Have Been A Website (And Probably Your Game Too) - Rogue Engine
Remember when every company rushed to make an app? Airlines, restaurants, even your local coffee shop. Back then, it made some sense. Browsers weren’t as powerful, and apps had unique features like notifications and offline access. But fast-forward to today, and browsers can do all that. Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
This is all factually correct, but alas as Cory Doctorow points out, you can’t install an ad-blocker in a native app. To you and me, that’s a bug. To short-sighted businesses, it’s a feature.
(When I say “ad-blocker”, I mean “tracking-blocker”.)
If Not React, Then What? - Infrequently Noted
Put the kettle on; it’s another epic data-driven screed from Alex. The footnotes on this would be a regular post on any other blog (and yes, even the footnotes have footnotes).
This is a spot-on description of the difference between back-end development and front-end development:
Code that runs on the server can be fully costed. Performance and availability of server-side systems are under the control of the provisioning organisation, and latency can be actively managed by developers and DevOps engineers.
Code that runs on the client, by contrast, is running on The Devil’s Computer. Nothing about the experienced latency, client resources, or even available APIs are under the developer’s control.
Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.
As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site’s lifetime.
You can use Web Components without the shadow DOM
So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?
- Obvious Markup
- Instantiation is More Consistent
- They’re Progressive Enhancement Friendly
JavaScript dos and donts @ Mu-An Chiou
Straightforward smart sensible advice that you can apply to any feature on a website.
Building a robust frontend using progressive enhancement - Service Manual - GOV.UK
Oh, how I wish that every team building for the web would use this sensible approach!
Request for developer feedback: customizable select | Blog | Chrome for Developers
I’m very glad to see that work has moved away from a separate selectmenu element to instead enhancing the existing select element—I could never see an upgrade path for selectmenu, but now there are plenty of opportunities for progressive enhancement.
Developers Rail Against JavaScript ‘Merchants of Complexity’ - The New Stack
Perhaps the tide is finally turning against complex web frameworks.
Reckoning: Part 1 — The Landscape - Infrequently Noted
I want to be a part of a frontend culture that accepts and promotes our responsibilities to others, rather than wallowing in self-centred “DX” puffery. In the hierarchy of priorities, users must come first.
Alex doesn’t pull his punches in this four-part truth-telling:
The React anti-pattern of hugely bloated single-page apps has to stop. And we can stop it.
Success or failure is in your hands, literally. Others in the equation may have authority, but you have power.
Begin to use that power to make noise. Refuse to go along with plans to build YAJSD (Yet Another JavaScript Disaster). Engineering leaders look to their senior engineers for trusted guidance about what technologies to adopt. When someone inevitably proposes the React rewrite, do not be silent. Do not let the bullshit arguments and nonsense justifications pass unchallenged. Make it clear to engineering leadership that this stuff is expensive and is absolutely not “standard”.
HTML Web Components Can Have a Little Shadow DOM, As A Treat | Scott Jehl, Web Designer/Developer
This is an interesting thought from Scott: using Shadow DOM in HTML web components but only as a way of providing sort-of user-agent styles:
providing some default, low-specificity styles for our slotted light-dom HTML elements while allowing them to be easily overridden.
HTML Web Components Make Progressive Enhancement And CSS Encapsulation Easier! | CSS-Tricks
Three great examples of HTML web components:
What I hope is that you now have the same sort of epiphany that I had when reading Jeremy Keith’s post: HTML Web Components are an HTML-first feature.
It’s about time I tried to explain what progressive enhancement actually is - Piccalilli
Progressive enhancement is a design and development principle where we build in layers which automatically turn themselves on based on the browser’s capabilities.
The idea of progressive enhancement is that everyone gets the perfect experience for them, rather than a pre-determined “perfect” experience from a design and development team.
MSEdgeExplainers/WebInstall/explainer_same_domain.md at main · MicrosoftEdge/MSEdgeExplainers
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!