We need to talk about Shadow DOM. While the Google official docs strongly encourage the use of Shadow DOM, I quite strongly disagree. As an example, a couple weeks ago I realized I could style the <summary> part of a <details><summary> set of elements as a button, which would look great and more readily indicate its function. You can see the improvement here: Before: After: Thankfully I hadn’t swallowed the party-line on Shadown DOM and this is the full set of CSS changes I had to make, just the following additions:

Over 5 years ago I wrote No more JS frameworks and just recently Jon Udell asked for an update. It's almost 4 years since @bitworking said: "Stop using JS frameworks, start writing reusable, orthogonally-composable units of HTML+CSS+JS." I'm curious, Joe, about what you've since learned, thought about, and done with the idea.https://t.co/zdKjEZfIe3 — Jon Udell (@judell) July 17, 2019 I have been blogging bits and pieces over the years but Jon’s query has given me a good excuse to roll all of that up into a single document.

Via Alex Russell, I just found Guidelines for creating web platform compatible components, which further contains a link to The Gold Standard Checklist for Web Components, both of which look like excellent resources when creating custom elements. This is a good time to mention that work is progressing on elements-sk, a set of neat Vanilla JS custom elements.

Last August, as my team was pondering moving away from Polymer and creating our own set of neat vanilla js custom elements, I decided to take a data driven stab at deciding is this was a viable plan. My team has been building web applications for over four years using Polymer and that corpus of code could be used to guide the decision. The first thing I did was scan each project and record every Polymer or Iron element used in every project.

The latest release of elements-sk has added elements for all the Material Design Icons. You can see the full set of icons in action on the elements-sk documentation site. Each one is its own module, so you only pay for what you use.

Both Pulito and VanillaJS have updated to webpack 4. Additionally both have moved from yarn to npm. While npm still isn’t as fast as yarn, the support for package-lock.json files and increased attention to security and speed are worth the tradeoff.

My VanillaJS project, where I re-implement popular framework sample apps in vanilla JavaScript, has now been ported over to ‘a la carte’ web development. In this case that means they all use pulito for their tooling and directory structure, and individual framework ports bring in templating libaries as needed. For example, the React sample rewrite uses lit-html for templating, and the Angular sample rewrite uses hyperHTML for templating. This is a perfect example of the power of a la carte web development, where you get to pick the components you want and only have to ‘pay’ for what you use.

Stop using JS Frameworks is something I’ve been advocating for years now, and a legitimate question I get is what do you replace it with? The answer is “a la carte” web development. Instead of picking a monolithic solution like a web framework, you just pick the pieces you need. I don’t mean any old random pieces, below I am going to outline specific criteria that need to be met for some components to participate in a la carte web development.

“Neat” – as applied to drinks served in bars – refers to a shot of liquor poured directly from the bottle and into a glass. There is no chilling involved with a “neat” drink. There is never an additional ingredient in a drink served “neat”. Up, Neat, Straight Up, or On the Rocks The Custom Elements V1 spec has reached concensus and implementations are going well, which is all great news, but what I find surprising is the lack of VanillaJS custom elements on WebComponents.

I love custom elements! I've been building UIs with them since Polymer 0.5 was announced in 2014. One of the things that I've questioned with custom elements has been Shadow DOM and its relationship to CSS. This page is an experiment for comparing custom elements with and without Shadow DOM. Press the buttons below and 1,000 spinners will be displayed on the page, when 'Light' is pressed the custom element uses CSS defined for the whole page, and when 'Shadow' is pressed the custom elements have a style sheet attached to their Shadow DOM, and when 'External' is pressed the CSS for the element is still encapsulated in the Shadow DOM, but it is loaded as an external stylesheet.

I spent some time over the holidays porting web framework sample apps over to vanilla JS. I’ll add the same caveat here that I also included in the code: The code works w/o polyfils in Chrome. To get it to run in a wider range of browsers you will need to add polyfills and, depending on the target browser version, compile the JS back to an older version of ES, and run a prefixer on the CSS.

Now that Custom Elements has reached v1 and is starting to appear in browsers, let's make some elements. We'll start with one of the simplest elements possible, a busy spinner, or activity indicator. Caveats: No accessibility. spinner-bw { display: none; border-radius: 50%; width: 2em; height: 2em; border: 0.4em solid #a6cee3; border-left: 0.4em solid #1f78b4; animation: spinner-bw-spin 1.5s infinite linear; } spinner-bw[active] { display: inline-block; } @keyframes spinner-bw-spin { 0% { transform: rotate(0deg); } 100% { transform: rotate(360deg); } } window.

It was over three years ago that I wrote No more JS frameworks, at which time I was roundly criticized for not understanding that data binding could only be done via JS framework, the two were inextricably linked, and only 2-way data binding would do, as one way data binding was for weak-minded fools who weren’t building real applications. You can find the comments on HN yourself, I don’t link to that cesspool.

Note: This post was updated in Jan 2017 to use the Custom Elements V1 spec. One of the questions that comes up regularly when talking about zero frameworksis how can you expect to stitch together an application without a framework? The short answer is "the same way you stitch together native elements," but I think it's interesting and instructional to look at those ways of stitching elements together individually.

Stop writing Javascript frameworks. Translations: Chinese Japanese Russian Here's the talk, based on this essay, that I gave at OSCON 2015. [Slides] The 100-line templating library presented as a Gist has been cleaned up, documented, and published as the Stamp library. JavaScript frameworks seem like death and taxes; inevitable and unavoidable. I'm sure that if I could be a fly on that wall every time someone started a new web project, the very first question they'd ask is, which JS framework are we using?