The Story of Web Components

This is the story of Web Components and why, at least for now, they haven't managed to gain meaningful adoption.

[nickfotopoulos]

"Flash [...] Created by Adobe..."
Abobe ACQUIRED Flash and but didn't contribute very much at all feature wise to it. Those accoladed belong to Jonathan Gay of FutureWave Software.

FutureWave created SmartSketch. When AT&T aquired the hardware that it ran on, the software no longer had a platform so Jonathan Gay retooled SmartSketch to be an application that could output animated content that could be played in any web browser and called it FutureSplash Animator. FutureWave pitched the product to Abode but they apparently were not impressed enough to reach an agreement. Not long after Macromedia acquired FutureWave and their technology and the product would go on to be branded Macromedia Flash and Jonathan Gay would eventually become the CTO of Macromedia in 2004. The very next year in 2005 Adobe aquired Macromedia for 3.4 billion dollars as a means of getting the Flash product, and it became Adobe Flash.

[nChauhan]

I have been working on web components for last 6-8 months now using LIT, i think they are great for simple re-usable peices of an app but it's true that they have a long way to go before they can be considered as a replacement for the current frameworks

[slava_trushkin]

I think web components do have their uses and might become more popular.

Just few years ago big issue was browser support that prevented web components adaptation. One big issue was Edge, which until the end did not support shadow DOM. Browser adaptation takes time, so for several years after Microsoft switched to Chromium there were enough users still using old Edge, that polyfills (which were good, but had their own issues) were required to run web components in productions. Now it is finally not an issue.

Then issue was complexity of developing web components. Today it is also not an issue with many frameworks adding support for generating web components. Svelte, Vue 3, Lit all can generate reusable web components.

As for uses, one use case is dealing with server side rendering. SSR is becoming more popular, but often data needs to be rendered only in browser, such as components that fetch data from APIs or show user specific data. When such components are used in big app, hydrating them could become a nightmare, especially if its a reusable third party component that is meant to work with all frameworks, but if logic is split in reusable web component, framework doesn't need to worry about hydration.

[MaxArt]

I think this video has quite some misconceptions.
Web Components weren't never meant to replace frameworks or data-flow control libraries. They weren't event meant to replace templating and styling libraries. And this is from the get go.
They, on the other hand, were meant to offer the basic bricks to create framework-agnostic, reusable, accessible elements. And they _do_ deliver this.
Now, yes, of course developing "vanilla" web components is cumbersome - but the counterpart isn't using React, but rather basic DOM methods like document.createElement and .appendChild.

Keep in mind that the concept of Web Components was born before React and hasn't changed, so the comparison with that is out of place. I repeat, they weren't meant to replace React, or Angular or whatever. In fact, they _work quite well_ with them (well, not particularly well with React, but that's React's fault).

I think the best fit for Web Components at the moment is using them for UI kits (libraries of small, reusable components), but creating fully-fledged applications with them is already possible, although some libraries still need to be refined and there's definitely a much smaller community around at the moment.

Personally I think the problems with Web Components adoption can be sum up with these points (one or more could be true for every case):
- lack of support for Declarative Shadow DOM (no server-side rendering);
- lack of support for Form-Associated Custom Elements (FACEs) (Firefox recently shipped a part of the spec);
- the simple fact that if you're using Framework X and you already did everything in Framework X, you aren't compelled to use another technology to do something equivalent.
The last point, on the other hand, brings the problem of framework lock-in, meaning that it's always hard to migrate from Framework X if for some reason you're forced to do so. In the end, relying so heavely on Framework X increases the team's technical debt.
The good news is that Web Components - being framework-agnostic - actually _help_ migrating from frameworks. They also are great as foundational elements if you need to work with different third-party teams.

I agree that the adoption has been slow and could have been faster (also because other vendors didn't share Google's sentiment and commitment about them), but they _are_ gaining traction, no doubt about it.

[lemontec]

seems like if you want the web to move forward you need a big tech company who dog feeds the tech into their own projects. Apple early on pushed html5 before the appstore existed and they added css animations to make their product pages more interactive. Facebook and Google of course invented React and Angular to solve their own app UI problems. In comparison, web components felt like an academic undertaking coming out of a standard body.

[donniedamato]

I write low-level web components all the time. I find them easier to understand because I've been working with the DOM for so many years. Trying to get an input to focus after a user event is easy using the DOM, not easy in React for example. It's also really nice that I don't need to have a framework running to support the component; the browser just needs the component code. I'm looking forward to declarative shadow DOM to support SSR better for custom elements which don't have JS logic (used for layouts).

[nilfux]

Stencil is brilliant. It cooperates with any existing library/framework or standalone. Web components still can work. Our use case was a company wide set of components that needed to work inside React, Angular and Wordpress.

[fulgren]

I once interviewed at a heavy Web Components using company, without knowing too much about this tech. The questions they asked made a lot more sense in context after watching this video. I didn't get in, and now it feels like I dodged a bullet.

[TrevorOFarrell]

Best webdev channel on youtube I've seen so far, keep it up!

[kevinbatdorf]

So maybe we got the alien timeline but didn’t know it. That explains a lot actually.

[kamalsahoo]

I have recently tried Microsoft Fast which is a web component framework. I feel like it is great for developing display components when you couple the UI web components with other framework like react for state management it really shows it benifits.

[rahulgawale]

Salesforce uses web components massively. They have their extended version called lightning web components. I love it. Its simple and faster to build.

[Weeksmistro]

Dude, at 5:04, more than half of that code can be replace with an html template.

[Infinighost]

"Do templates have to live inside the application logic? If so, this is a really poor decision" 10 years ago, everything was so MVC and I absolutely hated it. I just never felt that such an extreme separation was necessary unless you had different teams/members managing each part. I'm on a dev team of two, and it is much easier and faster to avoid those artificial separations.

[DannyEngelman]

While viewing this video, which only goes into V0, I inspected the <video> tag in DEVTools. WTF? It says the <video> tag has a #shadow-root (user-agent) and contains a whole bunch of <div> tags I can **not** touch. So Web Components suck, but all more complex HTML5 elements are built with Web Components. Better not ever use an <input> again if you don't want to use Web Components.

[niorad]

For me one the biggest downside of WC-as-react-alternative is the lack of tooling (nothing like Jest/Enzyme, lack of SSR). But as some here already mentioned, it was never meant for architecting entire apps. On the day to day it's not terrible, though. (Working on WC-Projects since 2020)

[wick]

Damn this is the history version of 100 seconds of Web Components, You are so under-rated mate!

[Azurryu]

Web compoments are extremely useful for scoping styles where you have no control over the web page your component gets used in. I can't throw in react or anything else, friendly iframes technically achieve the same with their own drawbacks (resizing to fit the content) - but a native web component perfectly enables us to offer our customers what they need: components that don't conflict with their page and are developed by a third party with no access to their CMS or their code. We can pretty much distribute it similar to ads - but this tag where you want this component to render and our scripts handles the rest for you without conflicting with your page.

[death-disco]

This video was made too eagerly, web components are amazing especially if you’re working on web assembly or any kind of native wrapper framework. They’re absolutely the future, unless we move post-browser somehow.

[ploosqva]

The spec is low level, like assembler to high level languages

Then again, if "61 ways to build web components" is not an indicator for their success then I don't know what is. Look up "all the ways to make a web component" article

So many ways to create web components and they all work together seamlessly and transparently. React does not even come close. It's a closed environment