Blinded By the Light DOM – Eric’s Archived Thoughts

You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.

I think Eric’s approach here should be the default for most web components: you probably don’t need to mess around with the shadow DOM, and you should definitely be wrapping your web component around existing HTML instead of witing opening and closing tags with nothing in between.

As Chris puts it:

Augment, don’t replace.

Blinded By the Light DOM – Eric’s Archived Thoughts

Tagged with

Related links

How Microsoft Edge Is Replacing React With Web Components - The New Stack

“And so what we did is we started looking at, internally, all of the places where we’re using web technology — so all of our internal web UIs — and realized that they were just really unacceptably slow.”

Why were they slow? The answer: React.

“We realized that our performance, especially on low-end machines, was really terrible — and that was because we had adopted this React framework, and we had used React in probably one of the worst ways possible.”

Tagged with

Cameron Dutro on ruby.social

Here’s the inside scoop on why Github is making a bizarre move from working web components to a legacy React stack.

Most of what I heard in favor of React was a) it’s got a good DX, b) it’s easy to hire for, and c) we only want to use it for a couple of features, not the entire website.

It’s all depressingly familiar, but it’s very weird to come across this kind of outdated thinking in 2023.

My personal prediction is that, eventually, the company (and many other companies) will realize how bad React is for most things, and abandon it. I guess we’ll see.

Tagged with

Web Components Will Outlive Your JavaScript Framework | jakelazaroff.com

Decision time:

There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. And the cost accumulates over time.

This post is about more than web components:

If we want our work to be accessible in five or ten or even 20 years, we need to use the web with no layers in between. For all its warts, the web has become the most resilient, portable, future-proof computing platform we’ve ever created — at least, if we build with that in mind.

Tagged with

Using Stencil to make a live poll Web Component

Before getting into the details of the code, Matt hits the nail on the head talking about the the one thing that web components have that no framework can offer: longevity.

Quoting Stuart Brand:

Old systems break in familiar ways. New systems break in unexpected ways.

Well! The web is an old system.

Tagged with

Building a Frontend Framework; Reactivity and Composability With Zero Dependencies

The thinking behind the minimal JavaScript framework, Strawberry:

Even without specialized syntax, you can do a lot of what the usual frontend framework does—with similar conciseness—just by using Proxy and WebComponents.

Tagged with

Related posts

Extensibility

A difference of opinion regarding what the core features of custom elements should be.

Browser support

Here’s Clearleft’s approach to browser support. You can use it too (it’s CC-licensed).

Applying the four principles of accessibility

Here’s how I interpret the top-level guidance in the Web Content Accessibility Guidelines.

Speculation rules

A performance boost in Chrome.

Baseline progressive enhancement

If a browser feature can be used as a progressive enhancement, you don’t have to wait for all browsers to support it.