#webcomponents

So whatever happens to web components in the future, and regardless of whether web developers ignore them, forget them, celebrate their demise, or write them off entirely, nothing can take this victory away from them. They are woven into the texture of the web platform in a way that can never be undone. For me, this makes me happy even if I never write another web component again.

It is not acceptable to bounce users on old browsers, users with bad network connections, users using assistive technologies. Certainly not from a monopoly public service. A lot of hype and noise is pressing us to extend the cowboy, wild-west phase of the software industry’s expansion. We should set that aside, and take ourselves seriously as a mature industry. Build a web application that works on a playstation portable on a 3G connection - if you do, it will work for all your users, and it will still work 30 years from now.

Elena is a simple, tiny library for building Progressive Web Components. Unlike most web component libraries, Elena doesn’t force JavaScript for everything. You can load HTML and CSS first, then use JavaScript to progressively add interactivity.

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.

Last year, we launched a new frontend for MDN. The most noticeable changes were adjustments to our styles; we simplified and unified the MDN design across all of our pages. In truth, the biggest changes were not reader-visible, but rather in the overhauled code that powers our frontend. This post describes what we've done, the technologies we chose, and why we did it at all.

A few years ago, I was looking for a way to add interactive code sandboxes to my Markdown files without embedding third-party iframes, like the ones from Codepen or Codesandbox. Those services are great and I use them all the time to share demos, but I’ve never been a fan of using them on a blog since you have to jump back and forth between your local Markdown file and an external site to make changes to the demos. Plus, they typically load lots of JavaScript.

Today, I want to look into one very specific topic in excruciating technical detail: how to dynamically load custom elements.

A bunch of people shared their own approaches, but the one that absolutely blew my mind was the handleEvent() method, a platform-native method for managing all of the events on your Web Component.

Previously on meyerweb, I crawled through a way to turn parenthetical comments into sidenotes, which I called “asidenotes”. As a recap, these are inline asides in parentheses, which is something I like to do. The constraints are that the text has to start inline, with its enclosing parentheses as part of the static content, so that the parentheses are present if CSS isn’t applied, but should lose those parentheses when turned into asidenotes, while also adding a sentence-terminating period when needed.

The extremely quick read is, add /* HTML */ to the front of the template. Case sensitive and space sensitive (though hopefully one day it won't be so strict). Now highlighting and prettier (with save and fix) works. Note that you need the es6-string-html VS Code extension for this to highlight correct (something I had forgotten I had installed).

I’ve had the opportunity to use Kelp on a big client project for the last few weeks, and it’s been so awesome to work with!

One unsung feature in the web components space that I don’t think gets enough attention is the Custom Elements Manifest initiative. I think it’s the killer feature of web components.

As an ode to the train stations of my childhood, I bring you a skeuomorph split-flap web component

Recently, a friend asked if I knew of a Web Component that generates a QR Code from meaningful HTML. She said that there seemed to be plenty of options for creating QR codes in general, but none that worked by extending already-useful HTML instead of just configuring it all with JavaScript. I couldn't find any either, but thinking through these kinds of patterns is probably what I enjoy most about working on the web, so I thought I'd write up how I'd make one.

Today, I wanted to share a little Web Component I made for expanding or collapsing all of the <details> elements on a page.

Since octothorpes get registered with an Octothorpes Ring, that means you’re automatically on a webring if you’re using octothorpes. So each Ring hosts a web component that lets you put a classic webring browser on your page. You can see it working right now in the footer of this site!

In this job we need to think a lot about the tools we choose and why, so I cataloged all the places where web components (for me) feel like “the right tool for the job”. Your list may be different and I’d love to read it. And because I don’t want this to be 100% propaganda, I’ll also cover some of the not-so-great parts of web components as well.

The bottom line is, web components reduce the number of use cases where we need to reach for a framework, but complex large applications will likely still benefit from one. So how about we conclude that frameworks are useful, web components are also useful, stop fighting and go make awesome sh!t using whatever tools we find most productive?

Web apps are the only open and standardised GUI software development and distribution platform that’s available to us. Discarding them out of spite or annoyance is exactly the sort of situation that the phrase “don’t throw the baby out with the bathwater” was coined for.

I recently tried Storybook, a popular tool for browsing the demos and documentation for a UI component library. I think Storybook offers a good user experience, but its developer experience entails complexity out of proportion to its benefits. I tried creating a simpler web component library browser using web components, and am happy with the result.

Activates a suggestion menu to expand text snippets as you type. - github/text-expander-element

Lit supports server-side rendering through the Lit SSR package. Lit SSR renders Lit components and templates to static HTML markup in non-browser JavaScript environments like Node. It works without fully emulating the browser's DOM, and takes advantage of Lit's declarative template format to enable fast performance, achieve low time-to-first-byte, and support streaming.

Lit supports server-side rendering through the Lit SSR package. Lit SSR renders Lit components and templates to static HTML markup in non-browser JavaScript environments like Node. It works without fully emulating the browser's DOM, and takes advantage of Lit's declarative template format to enable fast performance, achieve low time-to-first-byte, and support streaming.

Web components and Polymer are exciting technologies that may fundamentally change the way we develop web applications, but because of the large performance gap between browsers that support the technologies natively (aka Chrome 36+) and those that don’t (aka every other browser), it will be difficult for most developers to use web components until they’re implemented everywhere, and there’s no way of knowing how long that will be.

Web components and Polymer are exciting technologies that may fundamentally change the way we develop web applications, but because of the large performance gap between browsers that support the technologies natively (aka Chrome 36+) and those that don’t (aka every other browser), it will be difficult for most developers to use web components until they’re implemented everywhere, and there’s no way of knowing how long that will be.