Another deep dive into web history, this time on JavaScript. The timeline of JS on the web is retroactively broken down into four eras:
Nice to see “vanilla” JavaScript making a resurgence in that last one.
It’s 2017, the JavaScript ecosystem is both thriving and confusing as all hell. No one seems to be quite sure where it’s headed, only that it’s going to continue to grow and change. The web’s not going anywhere, which means JS isn’t going anywhere, and I’m excited to see what future eras bring us.
I’m slapping my forehead—progressive web components is a perfect name for what I’ve been calling HTML web components. Why didn’t I think of that?
A Progressive Web Component is a native Custom Element designed in two layers: a base layer of HTML and CSS that renders immediately, without JavaScript, and an enhancement layer of JavaScript that adds reactivity, event handling, and more advanced templating.
This is an excellent one-stop shop of interface patterns:
This is an organic collection of common JS patterns that can be replaced with just HTML, CSS, and no, or very low, JS. As HTML and CSS continue to mature, this collection should expand.
Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.
This is a great way to think about client-side JavaScript!
Also:
Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
Some handy tips courtesy of Chris Ferdinandi.
HTML’s new `command` attribute on the `button` element could be a game-changer.
How I switched to high-resolution maps on The Session without degrading performance.
Naming custom elements, naming attributes, the single responsibility principle, and communicating across components.
HTML web components for augmenting date inputs.