HTML with Superpowers: An Introduction to Web Components(htmlwithsuperpowers.netlify.app) |
HTML with Superpowers: An Introduction to Web Components(htmlwithsuperpowers.netlify.app) |
It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to the DOM, which will break virtually all of them (including my own sad contributions to this space).
The exception to this are those built using a 3rd party library like lit-element or stenciljs, which fill in the obvious omissions of these specs. Perhaps in another 10 years, a mangled version of half of one of them can be standardized? In the meantime, each component shipping its own frontend library or inlining the same core functions over and over again does nothing in the way of interoperability. You can bundle every popular JS framework and mix their components today. The reason you don't do it then or now is bloat, not the lack of a minimally viable shared component interface.
Besides, if you're going to use a 3rd party library and associated bundler/compiler, you might as well pick a good one such as React, Vue, Svelete, Solid or even jQuery UI. Using any of these, you can design and build an entire app faster than the bikeshedding commissars from goog and aapl can agree on whether "open" or "closed" should be the default for attaching a shadow DOM (at the risk of ruining the joke: there was no agreement; the developer has to provide a value in each instance...)
You have to invent all your own wiring and passing of events, state-management et cetera if you go that route.
Because very few of the people developing web standards are web developers. And of those who are very few have done anything of note in the past 20 years or more.
They do love working on standards though.
This seems like the norm for tech now days. A lot of meeting and work and nothing major or significant really gets done. Seems like the the whole industry is about making it easier and simpler for new developers to get develop.
Regarding React, ES should just stick and simplify E4X that would just really make all these front end lib not necessary.
Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.
Is there a continuous churn?
React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x).
Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like granular reactivity and removing components as a unit of UI in its entirety.
Meanwhile the "non-churn" in web components has already resulted in two deprecated standards (custom elements v0, html imports), and is rapidly churning out dozens of new standards requiring more and more javascript to paper over their egregious design (form participation, constructible stylesheets, declarative shadow dom...)
And to have web components support built-in would mean to have them in the browser anyway, not in a third-party library.
Since I really like mithril and there's one UI library, I've been playing with Shoelace and Crayons and they're pretty nice to work with, but I remain a bit puzzled why there's so few players in the space.
That said, generally speaking, web standards really suck at offering sandboxing capabilities for third party integrations.
Just take filtering - there are so many possibilities of how filters can look like, how can they be combined (AND, OR, nested) etc.
Source: I fought with Ionic code for months over this. Really soured me on native encapsulation, but I see the benefits still. I just think it has to be approved very very very carefully.
Question: when and or if they gain in adoption, could you see them replacing react? If not, what’s the use-cases that you believe they wouldn’t work for?
I tried to get into WebComponents, but the MDN tutorial has you writing a lot of `document.createElement` and `document.appendChild`, which is the sort of imperative stuff I don't like about vanilla JS DOM manipulation.
Frameworks like react/angular/backbone/vue solve the problem of creating a single page application with a nice architecture and sharing code between components within the SPA.
Web components solve the problem of sharing code between any application.
There are opportunities to share code (eg/ data binding) and I believe that is the case (they use the same underlying browser APIs where available)
Treating the web as a low level platform that we can extense on top of, grow & further, with new, creative higher-level layers of hypermedia: that is a path to software with a soul, not just for big companies hacking out features, but genuine good for society. A malleable cohesive comprehendible connected information space.
Documentation and Google-ability of the subject isn't great so prepare to some digging and experimentation.
The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library. Building any significantly sized project purely native with vanillaJS would be challenging.
There are also some unique hurdles with this type of project that our org had to work through-mainly on the integration and design side of it.
Other than that, the website looks quite nice.
"New! Powerful!" It's neither
"Standard JS so it works where HTML works" says a lot about your experts
I did have some early hopes that it would also be a good way to enable content authors to coin and style markup within their posts/articles/etc., but the JS required makes me feel like it'll be too heavy for that use-case for most.
<!DOCTYPE html>
<html lang="en" class="no-js">
<head>
<!--#include virtual="/ssi/head.html" -->
<title></title>
<meta name="description" content="">
</head>
<body>
<header>
<!--#include virtual="/ssi/header.html" -->
</header>
<main>
</main>
<footer>
<!--#include virtual="/ssi/footer.html" -->
</footer>
</body>
</html>
In nearly every (marketing) agency I've worked at, the designers envisioned themselves as creatives. "Boundaries? Not us. We live outside the box..." Trying to get them to understand you can have the same underlying structure and just bend it with CSS wasn't something they've wanted to imagine. The idea of reusing (read: not creating from scratch) isn't in their DNA.
Again, this isn't all web designers. But marketing agencies do a lot of non-enterprise design and dev.
At a lot of BigCos, the designs are supposed to be standard outside of the once in a generation refresh. One of the advantages of a big brand is a consistent, known quantity, and so things have to be harmonious; Starbucks is not out there making crazy new cups for every new drink they sell, every McDonald's location looks more or less the same, etc.
A lot of the variation we've seen in the early web was because web was something that a lot of people were outsourcing, but these days web is more integral, theoretically.
- extremely light on content
- goes out of its way to not present anything more complex than non-functional pieces of code or static examples
- while advertising that they are "easy to use", the Writing section immediately skips to comparing and using frameworks and libraries
- I guess is a front to get the courses at $39/month, but the only link is on the front page
This is a horrible, bad, no good resource that offers nothing of value.
Svelte fully supports compiling to Web Components with 100% test coverage.
Vue fully supports Web Components as well, the only issue I've run into there is with CustomEvent.detail not being copied into the Vue event payload properly.
Web Components are widely used on the web, just under the covers sometimes.
So, VueJS docs are actually incorrect when they say it scores 100%. The actual score is 91%.
I had reported this 8 months ago.
In general, none of the major frameworks, and very few of the new frameworks use web components as a foundation for their functionality for many extensively described reasons that wc proponents literally couldn't care less about.
That seems to be a worthy goal, but I don't see that being usable in prod projects, at least not in the near future.
The closest I've seen is something like PrimeFaces, which has components for Angular, React and Vue, which is the majority of projects I've seen out there: https://www.primefaces.org (I've also used the Java JSF variety, it was... sometimes problematic)
If you need something that works the same (or as close as you can get) across multiple front end frameworks/libraries, while still having most of the components you could possibly want, I don't think there are many other options out there.
For example:
- Angular calendar: https://www.primefaces.org/primeng/calendar
- React calendar: https://www.primefaces.org/primereact/calendar/
- Vue calendar: https://www.primefaces.org/primevue/calendar
I know this might seem like a "who cares" sort of thing since the industry has standardized on the three listed, but I find all three overkill for a lot of things and, for example, keep my small projects in Mithril. But then I'm hit with either using Construct UI (which is honestly ok, this is all internal stuff), or having to make all the components myself.
What makes it such an impossibility for production? Even if, as in the case of Ionic, they provide web components but also wrap them up for React, Vue and Angular.
You don't need web components for that. You need https://open-ui.org (started, of all people, by Microsoft). Unfortunately Google et al are too busy sinking hundreds of millions of dollars and countless man-hours into web components (with no final goal in mind and increasingly arcane and complex workarounds for their deficiencies) to be interested in this.
> but I remain a bit puzzled why there's so few players in the space.
In which space?
In UI libs for the web? There are thousands, all busy re-implementing the same dozen-or-so primitive controls.
In UI libs for web components? Because they are a badly designed tech that still requires you to reinvent the same dozen-or-so primitive controls and combat the issues of styling, a11y, no SSR etc. that they bring.
And yet wc proponents keep pushing them as if they were panacea.
And "ecosystems is young" is a funny statement for something that is entering its 12th year of development (and fifth year of wide availability in browsers).
> The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library.
If they are lacking, have glaring unsolved issues, https://twitter.com/Rich_Harris/status/1198332398561353728), and you still need to augment them with a framework/library,... what's the point then?
If any of the existing solutions had the same amount of issues that wcs have, they would never have gotten of the ground. And yet here we are 12 years and hundreds of millions of dollars of effort later
What WebComponents support in SPAs bring to the table is a migration path to native support.
> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.
> Today, component frameworks and design systems reinvent common web UI controls to give designers full control over their appearance and behavior. We hope to make it unnecessary to reinvent built-in UI controls
But the lack of a combobox in HTML, I don't get at all. datalist kind of sort of does it but not quite, plus it's inconsistently implemented as to what it actually shows.
If there were a standard, you'd probably still complain that it doesn't match your use-case.
Because HTML Imports died in the spec drafting process. Unless you want a client-side SSI equivalent that doesn't require any JavaScript, HTML Imports wasn't that. I'm not aware of an alternative proposal that doesn't.
https://www.w3.org/TR/html-imports/
https://webmasters.stackexchange.com/questions/127482/on-wha...
It is that sort of thing and it breaks my heart that this is the case.
And yet, supporting solutions that would work with any front end solution and do so well without death by committee is some ways off, if not outright impossible.
It's very much the same way how I love Firefox but when >95% of your userbase is on Chrome, you need to pay additional attention to testing and compatibility against it.
It's also very much how many of the SaaS solutions or even self-hostable tools and such might have integrations for most of the popular languages/frameworks/libraries out there, yet keep the niche ones unsupported due to a lack of market share.
So for now, I'll just take what I can get, in lieu of better options.
Ay.
Can you please explain what this means in simple, 5th grader English?
Vanilla JS says how to do things (find these HTML elements and update them by doing X).
It is much simpler to track and mutate a state object, than it is to find all the nodes you need to update and update appropriately.
The good news is that the tooling around the Web components is evolving even when the standard itself may moving at glacial pace.
> The good news is that the tooling around the Web components is evolving
You mean web components are growing their own frameworks at the same pace :) With new APIs and breaking changes
In 12 years web components had:
- original lib, polymer. Breaking changes 1.0-> 2.0, then completely deprecated
- lit is 4 years old, already had breaking changes in each version update 1.0->2.0->3.0 (and "potential breaking changes" even in patch releases), and adds new APIs with every release
- stencil is 5 years, has already had breaking changes in 1.0->2.0, but is probably the most stable of them all
etc.
Looks on par with the rest of the industry :)
The sad thing is that web components as a standard don't allow is for actual iteration of ideas. While Solid, S, Marko et al are exploring granular reactivity, web components are stuck in 2010. And all the tools around them are doing what the rest of the tools have been doing for the DOM since time immemorial: invent new, better ways that are only hampered by the underlying platform.
It doesn't solve the problem, but would solve the problem if it was started 10 or 20 years ago.
This is what needed in the browser: an actual properly specified comprehensive set of controls. Web Components are not it, as they continue re-inventing the wheel with the same components that libraries where defining since the dawn of the web: buttons, avatars, tabs etc. All of them different, all of them incomplete, all of them inaccessible etc.
> but say for <breadcrumb /> component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?
Because if you go to any UI library for the web, it's one of the components almost everyone defines. As you can see in the research for each component. What does having it as a web component give you? Nothing. It gives you fifteen hundred different incompatible re-implementations [1]
Having a higher level abstraction you don't need to re-implement it, you don't have to to manually provide additional things (like accessibility hints etc.)
In general, if everyone attempts to implement the same elements in the browser, it makes sense to have them as a part of the platform, doesn't it?
[1] https://shoelace.style/components/breadcrumb, https://web-components.carbondesignsystem.com/?path=/story/c..., https://vivid.vonage.com/?path=/story/alpha-components-bread..., https://sap.github.io/ui5-webcomponents/playground/component..., https://ionicframework.com/docs/api/breadcrumbs ...
edit: no one is saying a purpose-built framework needs to do everything that a mass-market framework ecosystem does. it's disingenuous to think there aren't circumstances it would make sense, not all of us make forms for a living.
I mean, you can do all that. And either spend your time writing tons of boilerplate code, or reinventing half of those frameworks and libraries anyway.
And still having to deal with issues like having to remember that they don't participate in forms (more JS to each component), that a11y can suddenly be broken (when your label references an element inside shadow dom), that wcs are not extensible to SVGs (which is important if your field is data visualisation) etc.
At which point you will go "why bother".
The irony is, marketing agencies that do web design work for multiple clients should be looking to leverage web component bricks. The majority I've seen, are not; at least not yet.
There is not a single soul in marketing at any company - small or big - that's going to see, "Before you deploy I want to see the markup..." :)
In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.
html[stylus-iframe$="twitter.com"] h1 { display:none }
.comment:shadow .title { font-size: 1.1rem; }
Just because someone uses a technology, doesn't mean it's good. I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good?
Also, I'd skip youtube as an example. No idea what incentives they had internally to re-write everything in web components, but they (and the web) paid dearly for it:
- Youtube was re-written in v0 of Custom Components. Which was deprecated as soon as they re-wrote it. Chrome couldn't remove v0 from the browser until Youtube was re-written (undoubtedly at great expense) with v1 four years later
- The polyfill for v0 was famously extremely slow in Firefox. Given that Youtube is one of the most popular websites (if not the most popular), you can imagine what it did to Firefox's image.
If you have an extra billion of dollars for such shenanigans, sure, knock yourself out (especially if it helps to cripple your competition).
Also IIRC GitHub is using React as well now, but I can't find the relevant link and discussion right now.
At least it shows that the technology is both scalable and battle-tested.
> I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good?
It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later. Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.
> Also IIRC GitHub is using React as well now, but I can't find the relevant link and discussion right now.
On their promo sites, yes. And maybe in the project management tools as well. Developers of the main site are heavily into web components.
So are all other technologies used on the web sites. It still doesn't make it good.
You keep pretending that if something is used somewhere means it's good.
> It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later.
So what? Neither of these technologies have the laundry list of issues that web components have. And jQuery is still used on significantly more sites than React and Web Components combined. I'd bet on survival of jQuery more than on survival of Web Components.
> Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.
Unfortunately, yes. They are here to stay: a badly designed, barely working technology that needs increasingly complex and arcane hacks to make up for its deficiencies, sucking up human resources and making browser engines incomprehensibly complex. Oh, and they also infect other standards that have to cater to them now. E.g. Scoped CSS covers 80-90% of use cases WCs are used for, but now it has to be butchered to accommodate Shadow DOM.
But yeah. It's here to stay.
As Rich Harris, the author of Svelte said, "it's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1]
There's a reason why very few, if any, of the major frameworks, and very few of up-and-coming web frameworks use web components as the foundation. Well, not one reason, but multiple extensively documented, discussed and debated reasons. However, WC proponents couldn't care less about these reasons because "but look, it's in the browser now".
So. What.
marquee was in the browser. Custom elements v0 was in the browser. Many things were, or indeed still are, in the browser. Doesn't make them good technology. We're here 12 years after they were introduced and they still have the issues that a non-wc library by even a first year CS student wouldn't have on the first try:
- form participation, "solved" by throwing more JS at the problem
- a11y boundaries, will through more JS at the problem when AOM arrives perhaps 10 years from now
- incorporating SVGs, will never be solved. That is, doing <svg><y-axis></y-axis><x-axis></x-axis></svg> will never be possible. Not an issue for literally any non-wc framework.
- SSR is barely solved by DSD if at all
- etc. etc.
And 12 years later people are actually exploring ideas without components as those are pure overhead: https://dev.to/this-is-learning/components-are-pure-overhead...
[1] https://twitter.com/Rich_Harris/status/1513668040784814084
You do, when you need at least slightly more complex.
> The main critique I can think of is that Web Components provide many ways to do things
Nope. The main critique is that Web Components is 2010s tech solidified in the platform when the rest of the world has moved on and is now exploring fine-grained reactivity and trying to remove components as a unit of work/ui. That they are 12 years in the making and still have issues that no framework has (see links here: https://news.ycombinator.com/item?id=34346269). That their design now poisons the rest of the platform that needs to add countless new workarounds for their shortcomings, and seemingly unrelated standards (like scoped CSS) now have to take them into consideration...
Well, there is not just one main critique, there are many main critiques
> There aren't that many gotchas.
Just because you haven't run into them it doesn't mean there aren't any gotchas. And there are plenty.
That's what I said: At best they can consume/embed them and perhaps compile to them.
> regardless if they are their foundation or not.
And the fact that they are not forming the foundation of these frameworks should be examined and fixed, not ignnored. However, wc proponents ignore this entirely.
It is like asking why so many graphics engines get written, instead of using raw OpenGL/Vulkan calls and extension spaghetti all over the place.
I'm curious what the problems are with web components that you see? Is it specifically related to how they might be used (or useless) in the major frameworks?
Bitesized explanation from Rich Harris, the author of Svelte: https://twitter.com/Rich_Harris/status/1198332398561353728 It's from 2019, but all the issues are still there. When/If they are going to be solved, it will be by increasingly complex standards that require more and more Javascript for them to just barely function (like they couldn't even participate in form events without additional Javascript).
See also a larger discussion by the author of Solid: https://youtu.be/BEWkLXU1Wlc?t=5837 (if the link doesn't open at the timestamp, skip to "Failed Promise of Web Components" at 1:37:17). It's a bit rambling because it was unrehearsed and on stream, but still good. He also shows and discusses other articles like Rich Harris' https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and his own https://dev.to/ryansolid/maybe-web-components-are-not-the-fu... You can read them directly, but Ryan gives excellent additional context.
It sounds to me like most of the criticism's outlined are solvable. Perhaps the people behind the standard should be engaging the framework community more.
I wonder if you think web components (and the problem they set out to solve) is wrong from a fundamental/architectural standpoint?
The absolute vast majority of new frameworks don't use web components as the foundation.
Perhaps instead of burying their heads in the sand people pushing web components would should finally start asking why?
I only need to ask why, when I have to deal with React based stuff.
VueJS doesn't use web components as their foundation.
So you're not asking why. You're ignoring the question and burying your head in the sand.
We use them with the frameworks that have first class support, regardless if they are at their foundation or not.
Who is actually being ignored here?
I'm not yelling. I'm pointing out facts.
> regardless if they are at their foundation or not.
So why are they not used as a foundation? Why are they used at best as a second class citizen? Why is it these frameworks don't produce web components by default?
> Who is actually being ignored here?
Framework authors, who have been pointing out the very many deficiencies and shortcomings for years. Most developers who need things like scoped CSS and open-ui.org more than fifteen hundred new standards, each requiring JS to work, barely.
Angular and Vue framework authors considered them good enough to spend development resources on adding support for Web Components, they didn't do it for fun and glory.
See how you ignore everything I write even though I wrote it in the very first reply: "there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them."
All you keep saying is "oh they support web components only react doesn't support that's the only question why"
Full on denial and ignorance.
Angular's "support", for example, is slapping on a wrapper, and ignoring everything about web components entirely by loading the angular runtime and everything else Angular behind the wrapper. But sure. Support.
We are done here, it is quite clear were we stand.
My very first comment says this:
- There are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation.
This is a fact
- At best they can consume/embed them and perhaps compile to them.
This is also a fact
Somehow you saw me saying "React" in there. Which says a lot about you.
> We are done here, it is quite clear were we stand.
Oh yes, it's crystal clear.