Do you use a framework? Do you work on a team? Those questions aren't meant to be accusational, whether they're meant to help me understand how you use this web technology that I never see myself using.
@@JonasLiljegren Perhaps in some cases, but overall, I don't think that is true. As shown in the video, every major framework has wanted to incorporate WCs, and the problem is that they don't really work for that. As stated in my other comment, the big issue is you have to ship/parse JS to make them work, and the logical next step is SSR... which WCs are not designed for. They are a browser engine tool.
@@RonNorthcutt It should work if you don't try to overcomplicate things (with bundling and compiling), using Declarative Shadow DOM, signals and modern JS.
Theo seems to not understand that the Browser itself uses Web Components and Shadow DOM for what seems like simple elements. An HTML element does NOT have to be a primitive that is not composed of smaller entities. Just take a look at the simple input element or the details element in the Chrome console. Both of these elements have a shadow dom with functionality that exists simply by placing it on the page. In fact, Web Components are just an extension of this idea that we should be able to have access to this kind of power to create our own elements. And just like input and details, these elements can be composed of other elements.
And none of these browser-provided web components require the special handling that user-provided web components require. If a user-provided web component were as easy to use as an input element or details element, then I suspect that there would be a lot less complaining about them. Personally, I'm not in the hater group on this, but I'm not a supporter either, and I really think your glib comment is brushing aside actual issues brought up in the video.
@@erics2133 if you use custom web component the same as you would an input element (aka create it, pass in prompts as strings and listen at the component level for events it emits) then it is the same as an input element.
@@hishnash Except for the cases brought up in the video. I have noticed that the people that dislike web components the most tend to be those maintaining web frameworks, so it's likely that in the simplest cases, you don't encounter as many issues.
@@erics2133 There is nothing requiring framework devs to use components. There are thousands of web features that are not used by most frameworks. I think the main pain many framework devs had with components is they wanted to one to one map them to the higher order structures that the framework has rather than just treet them the same as native components like input, select, etc.
Hey Theo, loved discussing with you in the chat during this whole thing. I had a few thoughts that didn't really seem to stick during the conversation, which I think may clarify some of the issues you're seeing. The biggest thing is that, while framework authors' frustrations about being sold the idea that web components are for them are entirely legitimate, that is a flawed premise to begin with and should never really have been part of the discussion. If framework authors can make use of it, that's great! But for the most part, it's not aimed at them, but at a completely separate use case. The people pushing for frameworks to integrate with web components in the way you and Ryan described did both those framework authors and the web components API a disservice. The primary function of web components is, put as simply as possible, to extend HTML. They aren't and were never "components" in the same sense as frameworks use the term, and the name "web components" has caused a lot of confusion as a result. They're far more similar in practice to an XML extension than a framework component - you're defining a new HTML element, in terms of the existing elements, with its own inherent semantic meaning and built-in behavior. That comes with both benefits and drawbacks, and it fundamentally serves a very different use case than what frameworks call a component; for example, while you might legitimately build an entire website almost solely out of React components for dozens of layers deep, and that deeply nested structure is idiomatic for React, you would effectively never use web components that way if you want to keep your sanity intact. But conversely, web components are perfect for cases like custom form inputs, where you don't want to have to think about the innards of your custom form input basically ever after you've built it, and you simply need the browser to see it as just another form element to be processed - a localized, self-contained use case, which may be used multiple times on a single page, in which the details of what's inside the component are best hidden away. That said, it's not like web components can't be composed, but rather that defining web components in terms of other web components isn't idiomatic. They can be composed using s (the idiomatic way, where the shadow DOMs of each component aren't actually nested and the nested component is treated as a child of the outer component, rather than an implementation detail), or just by jamming one web component in another's shadow DOM (not idiomatic, structurally implies that the nested component is a hidden implementation detail of the outer component). Notice the distinction I'm making there - the shadow DOM is where implementation details live, and the light DOM is where content lives. That concept is fundamental to understanding the design intent behind web components, why slots work the way they do, and so on; I would even go so far as to say it's the underpinning of the entire API. And it's for exactly that reason that I claim putting web components inside each other's shadow DOM is, while entirely possible (contrary to claims in the video), not an idiomatic way of using them in general - they're designed primarily for building small, isolated parts of your site, not for structuring your entire site architecture around. There's tons more I have to say on this topic that isn't really suited for a TH-cam comment, so please don't hesitate to reach out here or on Discord (@foxoninetails) if you'd like to learn more about web components as their own technology, rather than only in the context of their unfortunate conflation with frameworks. I'd love to hear your thoughts =)
You should write a blog post detailing where web components are good and bad, this is really interesting and I’d love to read a more refined version of it!
I prepare a Video i destroy Solid and react he is payed he hast Skill issues i do not understand how He can BE this way He complains about Shadow Dom and 1000 none neede stuff
@@PotravnyyVV One, they shouldn't be called components, because it's a name that already had a ubiquitous and orthogonal meaning in web development, the reuse of which has been a source of immense confusion and misinformation. Two, the point I'm getting at is that they aren't meant to be composed *with each other* in the same manner as component-driven architecture - that is, defining web components in terms of other web components. They can still be "composed" with one another as parent and child elements, but that's a content-container relationship, not a part-whole relationship, which is a very different mindset.
It seems to get missed but I'm not actually suggesting that Web Components are made for frameworks. I went through that years ago but I know better now. My grievances are mostly around that their existence and the need for frameworks to account for them puts an overhead everywhere. If I could just be like I won't use them anymore, the end, it would be fine. But the problem is they make everything else on the platform more complicated. I think maybe proxies in JS are probably the closest equivalent in terms of change. Like now when someone does an `innerHTML` on a div some random user JavaScript code might run. So for example if that Web Component uses Signals and the innerHTML happens in an Effect well who knows what's going to trigger that re-running again. I have an endless pile of silly examples like this because I get Github issues. I almost published a followup article longer than my original article of examples like this but realized it was too in the weeds. The impact of these decisions are endless. I'm not suggesting Components !== Elements for the sake of trying to align Framework Components with Web Components. I'm suggesting not all things should be DOM elements and the extensions ot the platform have profound impact on those trying to use the platform.
@@edwardallenthree - Theo keeps saying "Attributes and properties can only be strings" several times in the video. This is wrong, properties can be any JS value just like for regular classes. Attributes being strings is true. - He's talking about slot behavior at th-cam.com/video/UrS61kn4gKI/w-d-xo.htmlsi=iTWVs1Dh0MtOaexz&t=3389, where he mistakenly believes you have to name your slots, and does not seem to know just putting `` will accept all element children. It is possible to name slots and select elements to to in those slots, but that's optional or when using multiple slots. - Can't remember specific instances, but it's very noticeable that Theo's knowledge about Web Components is very basic. Hating on class syntax is typical React brain scenario (especially given how many "gotchas" hooks have)
Web components by definition cant fail. They are in the browser forever. And they keep getting better, albeit slowly. For something like a design system with primitive UI components they make way too much sense. I'm excited for Web Awesome.
i actually also created a component library with lit. the cool thing is you cant destroy them with css and the only way to style them is by using its token based design system.
Web component as a response to React ? Are you certain of this, Theo ? I remember reading about WC in 2011 or 2012, if not before. React appeared after that.
Web Components v0 were introduced in 2011 by Alex Russell. They eventually evolved into the v1 spec which was introduced in 2016. I am not sure if he is referring to the v1 spec or if there were any drama between that and React.
Web components are another tool in my toolbox. I worked on a workflow designer using D3. This was integrating with a legacy application, so the shadow dom keeps everything nice and isolated. Web components fit nicely into this projects requirements.
This is the way. WCs are a tool, and the proper application of that tool is critical. I don't think the issue is that WCs are "good" or "bad"... I think the issue is that the dream of using WCs as the primary strategy for a component based application is not really feasible. It can be done, but it is not the best approach.
i think he meant that once something becomes a web standard, we are stuck with it regardless of if its still good or not (because now some websites have used this standard, and the burden of compatibility is on the browsers).
@@kangar1797 that’s my point too. CSS, JavaScript, HTML, HTTP, and many more are all individual web standards, that every site relies on. Sites built 20+ years ago and longer can still run. Sure, we get stuck with past decisions, yet somehow, all these standards have managed to improved tremendously over that time. Some of the new HTML elements means we don’t need to roll our own components, improved CSS means we don’t need to use as much JavaScript, or as much superfluous HTML structure for layout. Improved JS APIs and syntax means we have access greater functionality that brings us closer to that native app feel. So, no, I don’t understand that argument against standards. I agree that Web Components are currently largely unusable because they are not easily composable. I’m currently building a framework that makes use of them, so I understand some of the issues at play. The problem isn’t actually the Web Components themselves; they are actually pretty good, in concept. There are a few missing pieces that make them unusable though. Have a think about how you might map an array of JS objects to an HTML element. You can’t add a JS loop in the middle of HTML code like you can in some of the front-end frameworks. But we should be able to. We should be able to do the same thing as what ERB/Razor pages/PHP does but using JS. The other issue is passing custom callbacks to web components. Only the on* attributes (like onclick) can accept JS and execute them. We can’t define our own and send custom events as arguments. I’ve had to do a lot of weird hacks to make an arbitrarily define attribute to accept JS and to have it execute in the correct scope. The last missing piece is reactivity. I know there is a push to get Signals into JS, but that would be a mistake from my perspective because they are not low level enough. The actual requirement is Object.watch() and Object.observe(). They accept a variable containing a value of object and a callback which gets called whenever the value or object changes. The difference from signals is that it doesn’t keep track of dirty state. The call back gets fired the moment the value changes. That’s the functionality I have identified as needed to make Web Components useable. There are a few more subtle missing pieces m, but those are the large ones. Basically we’re missing an HTML/JS templating syntax.
@@_phenomen I’m not sure what your point is. Pointing out those three things doesn’t detract from the fact that many many many standards do indeed improve over time. It doesn’t even make a comment on their positive or negative impacts. All it says is some standards are no longer used. E.g Flash had an insanely positive cultural impact. We’ve lost so many good applications and games and animations because someone decided to deprecate it.
@@br3nto Yeah but the fix is to have "Web components" and "Web components 2", or change the name and be as ambiguos. We are stuck with "this version" of we components, even if we can have more standard to create components. The current standard CANNOT CHANGE, and that's the point on the statement It's like if css grid was dogwater. We can have other css rules and properties to aid in the creation of layout, but there can only be one grid, and it's behavior cannot change
We use a handful of web components. every single one is basically a full SPA written in vue designed for easy embedding in other projects. I doubt anyone who's embedded them even knows what a web component is. it breaks down to "to use our widget, stick this script in your head and you can now use this 'new html element'"
"The people who don't use SPA frameworks are hobbyists" laughs in 80% of the web is built in PHP (although it's possible to use PHP with frameworks) and 77% with jQuery (For comparison, React is ~18%). Her conclusions violate sanity checks, so either her data is flawed (e.g. sampling bias) or her analysis is. This doesn't mean that browsers shouldn't work with frameworks, but they also shouldn't treat non-framework use case as second class citizens. Also, I find it funny that she cites not using NPM and "the standard set of tools we [framework users] have all gotten used to to" as evidence that non-framework user's aren't serious developers. It would be like me as a Rust developer finding that people who were using primarily typescript are the less likely to use the standard tools in my toolbox (e.g.Cargo and rust-analyzer), and arguing that this proves that typescript developers are hobbiest and students. It turns out that when you (general you, not you specifically) define "non-hobbyist" as "someone who builds software using the same tools you use", you find that only the hobbyist aren't using the same tools as you. This says way more about your definition than the nature of developers who don't use your tools.
This isn't a great interpretation of what she said...the people who write pure JS ONLY (not "don't use SPA frameworks" like you said) work by themselves, and don't use npm as one example. Can you build an actual pertinent argument that those wouldn't be hobbyists? Most of the web is legacy sites as well; not sure how jQuery (which wouldn't even qualify as vanilla JS in this study) is relevant here when the discussion is about building web dev tooling for the future.
The vast majority of websites the average person uses today are built with React. Your numbers don’t reflect reality for the average person on the web.
@@PraiseYeezus First off, the actual quote was "the developers who were using vanilla javascript" (not "pure JS ONLY"). And the very next sentence was "and so that allowed us to say 'no, the bulk of the web uses frameworks'". The entire context makes it clear she's contrasting the SPA approach with the old school MPA with links, forms, and some light scripting approach. This is also why it's not at all clear to me that JQuery wouldn't count as vanilla JS for the purpose of her study. It's certainly much closer to vanilla JS than it is to e.g. react. "Can you build an actual pertinent argument that those wouldn't be hobbyists?" See my second paragraph. People who don't write SPAs usually don't use tools built primarily for writing SPAs, film at 11. This doesn't prove that people who don't write SPAs are hobbyists, any more than the (probable) fact that Theo doesn't have Cargo installed right now prove's he's one. As for building for the future (note: she was talking about the browser here, not about external tools like NPM, vite, typescript, etc). a) there are still plenty of new projects being deployed using the "old" MPA approach, as evidence by things like e.g. job postings, and b) legacy websites are still being maintained (I would know, doing that is part of my job) and getting new features, so treating this use case for the web as second class would be harmful to them. Whether they're legacy or not, they're still most of the internet. Again, this isn't an argument that browser makers should have an adversarial relationship with SPA developers. Rather, I'm saying that it's incorrect to treat SPAs as the primary use case and ignoring other ways of building websites (aka how most of the web is built).
@@spht9ng citation needed. If you check e.g. builtwith (not sure if youtube's spam filters would eat a link to it), you see 18.6% of the top million websites use react, and while it does rise for the top 100k and 10k, it's still nowhere near JQuery's usage. I respectfully suggest that your estimates are based on what you see as someone who develops websites using tools like react, rather than an accurate impression of how the web is actually built. (Which is fine! Goodness knows my own chosen tech stack isn't the most popular way of doing things).
Because that ranking was made from the biased comments from people who consistently use them; their frustrations and appreciations. You can't create a proper ranking without using an unbiased party who is proficient in all and prefers to use none of them.
I’m a WC fanboy, but here I’d tread carefully. I think it’s fine for folks to shift their opinions on things as they learn and grow. That said, I still don’t agree with Theo’s take but calling this out when it’s clear that Theo is evolving his opinion probably isn’t fair, since I’d hope all of us can do what he’s doing. For example: Maybe I could be convinced to totally drop WC someday, I just am not yet.
I don't think web-framework authors are impartial on this issue. They built their entire paradigm around the world before custom elements, and are psychologically and financially locked into that paradigm. Once you embrace the next paradigm: HTMX/zero-build/vanilla-js, webcomponents make a lot of sense.
that's not really a strong argument because web components could, in theory, have great interop with your web framework of choice if they worked proper.y
This is not correct. We may not be impartial but it isn't because frameworks came first. Solid was created because Web Components existed. That's why Solid has lightweight components because I thought WCs would fit that role. Svelte/Vue Slots were based on Shadow DOM slots. We learned from Web Components and realized what did and didn't work.
@@ryansolid you're still thinking within the spa paradigm. I don't even disagree that wc aren't ideal there. wc are a great fit however if you use no frameworks or a lightweight one like htmx.
@@ratoshi21 Framework components and web components serve different needs, so the framing of them as competing and therefore biasing SPA framework authors against them doesn't make sense. Framework authors would benefit significantly if the web component API was better for them, and it wouldn't make frameworks less useful (and I'm saying this as a fellow hypermedia enjoyer).
I love web components. Sure, it lacks when compared to React / Svelte Components. But when you have to work with react, svelte, and php, and plain html, and God knows what js framework spawning in the future. Creating 1 web component to use for every project suddenly makes sense.
I think this is the best use case for web components. When you have many microfrontends all sharing the same UI components / framework, using web components and making thin adapters makes a of sense
@@HolyMacaroni-i8e adblock is more harmful to the author of the channel, than sponsorblock, which saves only your time by skipping through the ads parts
@@HolyMacaroni-i8e because there can be multiple sponsors, interaction reminders, interludes, recaps etc. It skips them all and you don't have to skip through to find the end of it which isn't always clear. If i'm not directly at my PC or TV and just listening it's also pretty helpful there.
@@HolyMacaroni-i8e don't get the point of manually skipping sponsored segments when I can skip them automatically with an extension and don't even need to know there are any in the video
I believe the main issue of these discussions about WCs are due to them being called Web Components. For example, if they were called Web Elements, clearly showing they are meant to extend HTML not build apps per se. Then the conversation would be about how these edge cases should be ironed out, not about whether they are unnecessary or not. Beyond considering this a necessary browser standard or not. They clearly need to be worked on so they behave better. As a platform, currently the web benefits for having this API for experimentation. However, from the experience framework authors shared, it is undeniable the initial implementation left a lot to be desired and still needs to be worked on. Just as it happened with CSS, when the current bugs are solved, WCs will neatly fit into a place when simpler frameworks are enough for most of the web. Remember this, big frameworks are only needed for big web applications. You don't need a framework for your blog with some interactive elements. Or a wiki site. Or a news site. But this is a different conversation altogether. What I believe WCs promise now is to think about a web where most websites don't need to have heavy reactive frameworks. As Lea said, you would use a WC for an element which would exist if dev resources for browsers/standards would make it given infinite resources. To close my thoughts I would add, that we are already in a phase were big frameworks are starting to not be used for simple sites, with the push for vanilla js and server-centric frameworks. The survey done by the Chrome teams was done quite a while ago when JS sucked a lot more and the web wasn't as mature. Maybe today results would be different. With even some folks coming back from Typescript. And if web components have performance issues, then maybe as part of this less is more trend, they should be optimized as they did for the frameworks before. I remember when React, Ember and AngularJS slowed the web for having too much JS shipped on slow internet and doing a lof of thins on JS when engines weren't as optimized and computers weren't as powerful.
38:06 OMG you would never build HTML in that way using web components! That’s trying to apply a CRS concept to something that is inherently not CSR. You would either build the HTML in its entirety on the back end using a template, or you would build the HTML in JavaScript on the front end. What even you just described seems purposefully obtuse.
DOM-Elements are Lego, WCs are playmobil. With Lego you can build great things from simple things, with WC you can only do what they are supposed to do. And they don't work well together.
but you can actually use web components inside web components. thats not an issue as long as the are registered beforehand. they will be in the slot next to the shadow dom. this means their shadow domes are actually never nested, which is pretty clever actually
I'm dubious on the claim that "not all elements are components". Every element has properties, every element is an event emitter. Further, many elements have logic and state; details element can be toggled, forms have validation state, a search field has a "filled" state which can be cleared using the X or esc key, buttons can be disabled, a fieldset can disable all the form fields within it, etc. Even complexity isn't a delimiter since form fields like an upload field have multiple sub elements and date fields have complex popovers.
Not all sites use a framework. I don’t love the API, they are far from perfect but if you just want one or two interactive components they are better than nothing. It’s nice that they work without a build tool.
YES - WCs are a great option to have, and make a ton of sense in the right situations. They aren't a silver bullet (nothing is), but can often provide a simpler solution where needed.
I think you should think of web components more like a replacement for than anything else. They're more like separate apps and composable in the same way you can use Firefox, Excel, and Dropbox at the same time in your OS. Doesn't Theo make some sort of file-upload-thing? That is a perfect target for web components: you define a strict API for your new _element_ , include the script on the page, and it can be instantly usable in _any_ framework, from static html, through Rails strange no-js thing, to hyper aggressive SPA frameworks that _have_ to control every aspect of the DOM. Maybe "web components" is a bad name, but one should keep in mind that web component isn't really anything. It's a common collection name for several technologies, custom elements, shadow dom, et cetera. Similar to MVC.
Kinda a dumb take. Web components are amazingly useful for things like design systems (eg. with Stencil, which is a fantastic framework). When you're working on small projects, you don't need a design system and something like shadcn works great. The vast majority of web code is not in small projects though, it is written for huge projects at large companies. That is where you need a design system. Often you want this design system to work across multiple frameworks. And that's where the issue arises: getting the frameworks to interop with each other is INSANELY hard. None of them play nice with each other. Try rendering a Solid component inside of a React component as a child. It's extremely hard while allowing that React component to be used like an Angular component in an Angular app. Web components are supposed to fix that. You can implement a common set of HTML elements (which in larger apps SHOULD NOT be app-specific), and it allows you to reuse it in any framework out there. That's why you have companies like Amazon or Ionic using Stencil to build design systems, because it allows them to use whatever the right framework is a good fit for the job they need, while using their design system. Sure it's harder to implement for framework authors. But framework authors have completely ignored interop stories for years and it is not a priority for them. React has no reason to care about interop with any of the frameworks that have a quarter the size of it, because if a component is written already that you need, it's probably going to be written in React. Web components might be a shitty interface for framework authors to have to adopt, but for the kind of interop that companies and larger teams need, it is a necessary pain that would've had to been done if we needed good interop anyways.
*"Just"* use X. *"Just"* do Y. "Just" minimizes someone else's efforts, when it's said this way. It's arrogant and inconsiderate to suggest the other person couldn't imagine X or Y. I usually learn more about the context of a problem when I ask: "Have you thought about X or Y?" with some humility instead. I *"just"* didn't know everything. (Disclaimer: "just" _can_ be used without arrogance in other ways, but we techies seem to use it in the arrogant form a lot.)
Honestly, this is why I have gravitated more towards HTMX. You get all the benefits of a responsive application with minimal JS and pure HTML. SSR is already a thing, and a necessary part of most systems, so why not just focus on delivering the rendered HTML fragments directly? Even simpler.
23:00 The cause of this difference is "due historical reasons" as with everything in life. In fact, the "disabled" alone is not a flag but it's an SGML (of all things!) shorthand notation for *value* "disabled" if exactly one attribute allows value "disabled" (yes, SGML is truly this brain-damaged). Technically it's shorthand for writing disabled="disabled" which is also *why* you have to use the latter syntax if you write XHTML instead (XHTML being implemented in XML, it obviously doesn't support SGML shorthands).
Me neither until i found accidently at some point back in the day at courses that i undergo, forcing me to build entire front end with it. definitely not a good experience tho
You can think of a component like html + css + js It also uses a shadow dom so you can't accidently change it and also it'll work in every library/ framework
just think of them as custom html tags that have their own custom behaviours. They normally have a hyphen to distinguish them from the standard tags. If you inspect this website, you'll find them, eg in the description of videos.
Web Components are only not useful because there are a few missing pieces to make them useful. There’s actually no declarative way to build and compose them. There’s no HTML templating language, you’re either in JS land or HTML land with no way to properly mix the two. We need something like ERB or Razor pages but for HTML/JS. And there needs to be a way to register these components and to fetch/register them as required.
@@WesseI sure, but that’s just as useless on its own. There are still all the missing pieces I mentioned in o make it usable. Just think how you would loop the though an array of values/objects to populate a ul, or table, or select with values. You can’t. Well you can within JS land, but you can’t intermingle JavaScript and HTML within the template element. The experience is missing the actual templating syntax to intermingle HTML and JS.
48:02 it's NOT a stupid argument if at least one team member needs to add new functionalities... I've worked on 10 year old sites with jQuery and it's fine. But I've also worked on 4 years old projects with react and just getting your environment to work is hell.
Neither were web components a response to React, nor did React introduce the concept of a component. Web components were proposed in 2011 and even before that, libraries like Angular.js and Knockout.js came up with the concept of a component.
The reason there are two pronunciations for attribute is because one is for the noun and the other is for the verb. I attribute my success to web components, the verb. An attribute on an html element, the noun. As for why they are pronounced differently but spelled the same... because English is a mess :D
As someone who works with web components professionally. They’re not good for the browser except in the 3rd party widget use case. They‘re not bad as long as you use a framework on top of them. But they’re just the wrong solution to the problem of “competing web standards”. Mitosis by builder is the better solution that if I was on the W3 committee I would work towards adopting. It’s a translator, not a standard that needs to work in the browser. So framework authors only need to translate into that abstraction of what a component is, and then it can compile down to native web components or to react or to vue , vanilla html+js or even react native. Having a library of mitosis as a unified definition for headless ui components and then combine it with shadcn’s new cli and it means you only need to make sure that everyone can translate to mitosis to convert to any other standard. That’s what I would push for at least
I'm significantly more pro web components than theo, but this was addressed in the video/stream and I think the explanation made sense. The framework authors point out that if web components were good for their use case, it would allow them to offload some of their job to the browser (which is a good thing). Further (although they didn't say this themselves), since web components fill a different role than framework components, the entire premise of them competing with framework components is flawed, IMO. If you're building a SPA, you likely would end up using a framework regardless.
Thank you for mentioning your "alternative" pronunciation of 'attribute'. Half my brain kept trying to figure out if you were trolling, actually unaware of how 99% of the rest of the English speaking world says it or if I lived in some strange pocket of the world with its own accent 😆
These frameworks have ruined webdev. There’s a generation of people who know nothing about DOM and CSS. Frameworks have cost billions of dollars and millions of developer hours.
1:15:32 This is like we all agreeing on the Lego pieces and the Lego fundamentals like the hole sizes under every block then coming up with a secondary hole sizing system and asking everyone else to modify their already built stuff to become compatible with the new hole system as well as the old to be attached in any standard.
I use TailwindCSS for my personal projects as I love it, however when using regular CSS it seems to be overall better to not have scoped styles but instead follow something like BEM - this way you almost never have styles pollution, you have meaningful classes and you are able to style anything without worrying about scope etc
A second good example of a web component is the Mux Video Player. I agree that 90% of the time, the complexity of a Web component is not worth it when considering integrating it into a production application and team. To me, the most important takeaway from this article is that Web Components tried to be the solution to a problem that was still being defined. It could have been everything it promised, but it was set in stone before the problems it tried to solve were even defined. As a final point, try to find a clear post about building and publishing a web component with something as common as Tailwinds in a framework like Vue that is supposed to be supported at the framework level. There isn't.
If you are building the usual web application you don't need a hydration framework at all, and yes, then you should avoid the schizophrenia and use something simpler. You only need server side rendering if you are building something like a portal or a store, where latency is crucial (the UI must appear instantly or people will leave).
lol! I love Theo actually called out his own pronunciation of attribute - which to me is like nails on a chalkboard. Every time Theo talks about "ah-TRIBUTES" I think he is reviewing The Hunger Games! Theo puts the emPHASis on the wrong syLABLe. It is AT-tributes, dammit. 🤣
Yep we should improve this standard. But instead they invest millions into build tools to make building their awful react code a little faster and to avoid react being slow as all hell.
I have to disagree. Although picking the right tool for the job is important, web elements offer a "bare metal" aproach to development. No over arching designs and just raw functionality. Frameworks like react have over arching archetecture that you must consider. For example, you wanted to make a drag and drop utility? In react, you would need to either use some kind of portal or use state when reparenting an element or risk breaking the virtual dom. This aproach doesnt scale with many elements either. In web components, your aproach is purely in js land and all you need to do is reparent. No weird states involved. Its easier to make a certain building block in wc that doesnt follow conventional standards that are found in common component libs.
1:15:39 - "The one catch is, it's only for React" Not anymore 😎 - Vue has a port (with Nuxt support) - Svelte has a port They're "unofficial" but do the job and community loved
Your assumptions are totally wrong here. 1. The assumption that there is a conflict of interest -- there is none. 2. The assumption that these people wouldn't be fair. To overcome your own prejudices, forget who is saying the thing, and consider the argument. In a rational conversation, arguments have value in themselves, and it doesn't matter who uttered them. A rational conversation is a clash of arguments, not of people. And if you don't change this, honestly, you shouldn't be a part of any engineering discussion.
@@nandoflorestan ...this is a hilarious and extremely blind take. They are a tool. This article, and Theo on the whole are hyperbolic. Remember, you are reading an opinion piece, not a proof.
You both have valid points, to be fair. There is a conflict of interest, indeed. But I don't think that there should be competition among bloated frameworks and webcomponents. I am an admirer of many JS frameworks, and would see a lot of benefits in using webcomponents despite all the magic that comes with frameworks and out-of-the-box features. However, I honestly feel that webcomponents have endured certain disregard simply because people are too vendor locked and adapting to a new technology is rather complicated and in this case have no encourage from most big players.
There are approaches you need with web components to make sure you have a good time with your favorite framework. Usually the most important part is writing the web component in your framework so it has the usual hooks. I did not know about tracking clicks before load. That sounds problematic where a person multiple clicks because it's not working then what is the framework supposed to do? Also, why is the page so large that the user has time to click things with a standard connection? I'm going off to rust land for FE form here on. So as much as I like web components, I'm going to need to figure out what I'm doing before I can touch them again. (Hoping to add shadow dom support to leptos)
at 1:08:35 I built a custom element html editor solely based on standard implementation or vanilla. It's doable. html editor as in you make web pages with it. It's fairly complex, and pretty fast in my experience with custom elements. I mean, it's dirty as I was bored with it by the time I finished implementing server side page construction with it and wasn't able to refactor it. But it works, it's fast, it's portable. Dirty as in, all the code is in the component itself and no external code along with it. It's one big spaghetti. I just checked on it right now, it still works, minus the linking since I used a static ip instead of prepping it dynamically. But the gist of the code works, and it's fast.
I think there is a really valid point in moving some more modern features to the web standard, if nothing else, to get away from the whole npm shitstack that everything is build on nowadays. We are currently developing with a non-js stack (go backend) and none of the frameworks really support is well. In this, web components has been huge- mostly since they are so "lightweight".
When I joined my new job the first task they handled me was fix the mess of microfont end they had build (built by an external) using vue web components, it has tons of issues only resolved by not so elegant patches, and a hell of a deployment pipeline. Now we switched to Single SPA and it has it's challenges but it's way better
1:17:05 I think the fact that web components do not behave similar to native components (e.g. cloning) is the issue here and that part should be fixed in the web standards. It doesn't matter if the difference is hurting framework's internal implementation or native JS code you're trying to write by yourself. If this is caused by specs, then the specs would need to be improved to fix this and make web components to work when a fragment of DOM is cloned, or at least immediately throw instead of silently failing to clone parts of the fragment. Changing some old APIs to throw in case web components are passed in is an acceptable solution if the API has design that truly cannot support web components. Hopefully the error message would prod towards the newer API for *the same use case* that does support web components. Every API that has to be broken must have newer counterpart that has minimal changes to make it compatible with web components.
the number of web standards is kind of like RISC vs CISC in cpu processors, kind of. we curently have CISC. of course html/css/js interpreters (browsers) are pretty different than low level processors that have to be implemented with wires, but it's interesting to draw the connection of how we basically have the same thing at a much higher abstraction layer, now js frameworks are starting to be compiled / dsls such as with svelte or react's jsx and upcoming forget-compiler, so maybe the complexness should be implemented at the framework level instead of the browser level just as in cpus the complexness switched from being at the cpu architecture level to the "low level" programming language compiler?
one standard we are locked in to in the browser is javascript itself. that's why they invented web assembly. but my understanding is that web assembly is not currently as capable as it could be compared to javascript the real point of the browser is not to run javascript websites, but it's to provide an enviornment where a user feels comfortable quickly opening new pieces of software, without the friction of waiting for a big file download, going through an installation process and worrying about potential malware. theres no reason i can think of that web apps shouldn't be able to be built in kotlin or swift or any language you want, and it could potentially help things like performance or time to write, or creativity of ideas based on what a different kind of language makes easy. I mean look at all the hoops the effect people are jumping through to make functional programming work in javascript. meanwhile in the backend world every language gets to coexist and you can pick which one you want
Backend frameworks/languages only have to comply to one minimal standard: HTTP Protocol (get/post/etc query parameters, message body). They then can invent their own standards on top of that that are not codified as an official standard of something, eg REST, GraphQL, SOAP (dead). Maybe this way of doing things gives how things are done more room to evolve and become better. In the video you argue that components should be done by the framework level not the browser, in the backend http rendering and data communication is mostly done by the language level which is like an http framework. whereas for front end frameworks they have to comply with JavaScript which is a whole programming language with specific tradeoffs compared to others. It’s interesting to think about the different ways to do abstraction that have evolved in different places of computing.
From a pure developer perspective I completely agree. My current job is working for a school district trying to revamp their entire web profile. They are locked into a CMS and it sucks. Wit that said I have a lot of experience bending a CMS to do more than it was designed to do. I explored web components as an option and after looking into it and experimenting I eventually had to ask why? If it's a case of normal web content why does one even need it? There should be little to no JS anyway. Why force more JS just to avoid using a pile of divs with id and class names? If one needs to build an actual web app and must use JS then why not just use something like React instead? If it's a complex web app that is? Sometimes we just need something simple and importing React is kind of a waste. Developers tend to just default to a framework because. Even if it's not needed. Kind of like how every app tends to default to a state manager when there may be little to no actual global state needed. In some ways web components can kind of make sense when someone wants a more elegant way to build a UI without having to choose a framework. It also selects a standard that is there automatically vs others having to learn a new framework. Maybe. It feels like an odd special use case for them to really make sense. Even for my own odd "I'm going to push and warp the heck out of what this CMS is supposed to do" I just don't really see a valid reason to use them. The only way I might ever consider it is if it did eventually replace frameworks which it clearly is never going to do. I don't work with a single person that has even ever heard of them and I doubt they will ever use them. They just doin't feel designer or business friendly the way web standards were supposed to be. The way web components should have been is without the use of JS at all. A native built in way to create web components that does not need JS. I'm a fan of vanilla JS but I'm also a fan of not using JS at all if it doesn't need it. Thats why web components feel kind of odd and out of place. For page content and use in a CMS we really don't need them at all. For a complex web app it's kind of crude and there are much better solutions. They kind of feel like a hack or budget framework. I'm sure they have some potential but right now I just don't see it. The only real advantage I see is I can use them within a CMS page fairly easily without the huge overhead of loading the React library. I tend to create reusable CMS modules where I paste in web standards and then lock them so nobody else in the school district can break them. It works and it's much easier to paste in the code when it's a pure HTML, CSS and JS file vs trying to use a framework. Eventually I want to try to convince the district to go headless and use Contentful and NextJS. Until that point I think I will avoid web components since I doubt they will provide me much benefit over just having a article or div tag with a custom id or class name.
can you link to the article in the description? while i appreciate your input, it's very frustrating to hear up to 5 sentences from you before i hear one from the article.
1:08:26 I hate this moment. What's the problem to use a framework to build a Web Component? When I think about Web Components I think about Video Players, Audio Players, Whiteboards, Code blocks with Highlighting, etc., So components that have quite some complexity and where you might want to use a framework to build it. But you use Web Components to share that functionality. It's not a replacement for React. Don't think about Web Components how you think about React components. It's different things. And if you implement a blog with React, you have a lot of components and it doesn't make sense to write these components as Web Components. But when you embed e.g. a podcast and want a better player than the default HTML audio player, it makes totally sense to load an podcast player as web component. Like the Podlove Web Player, it's a great player, but it's included via an . And that's kind of nasty. So web components are a good way to embed things like an audio player as an alternative to an . The article may complains about events in web components are not the same as outside the web components. Well events inside of s are way worse. In my previous company we used web components for a feedback widget and a header, because different pages were written by different teams which used different technologies. Some used Vue, some React, some Angular and web components where a good way to have a reusable component that can be used in all that pages. And we used vue to implement the feedback widget. Where is the problem with that? It's not a good replacement for the frameworks, but web components are really good if you want to embed some functionality in a website as a wrapper layer.
15:03 them being willing to listen to pushback could be partially due to the fact that people can switch off of them if they want to edit ok you said it right after lol. but it feeds into ryan's point
1:15:00 I think this is a great illustration of the current situation and the web components definitely belong to the left side of the spectrum just as you put it. However, we need some new standards to live around ShadCN level or even slight closer to "component I wrte in my codebase" level but we don't have anything yet. And it's still unclear to me if there can be any non-framework agnostic solution here. Whatever solution is chosen, I hope it can fully interact with DOM. If you have any kind of virtual DOM solution where a piece of JS code overwrites the actual standard defined DOM from virtual DOM, that's definitely a model that cannot co-exist with standards compliant code. We would need a solution where you can have some server side rendered components co-existing with code that uses native JS code to work with the DOM without both sides stepping on the toes of the other side.
It seems to me that web components (WC) are great if you're trying to re-implement something like `` but it's a poor fit for server side rendering (SSR). Unfortunately, many JS authors try to use web components for SSR. Browsers really would need to support SSR better but the current state of WC is not designed for that.
I for one take issue with what Lea(sp?) wrote when she went from "CSS will never work" to "Clearly this was the solution all along." I hated CSS when it was introduced, and I still hate it. Why? The fundamental aspect of CSS' architecture, the cascade. Or better explained, CSS' lack of scoping (without~25 years of bad hacks) making styling a website *still* fragile ~25 years later. 🤨 But then there is a reason I was so happy to finally leave web development 5 years ago and became a backend-only developer. 🤷♂️
Web component should mainly be used when adding widgets/addon to other sites outside of your control. Using it in the same environment is not a good appeal. Stripe, for example ,leverages web component to make people use their some of the buttons.
What I understand: - Framework creators are used to hack existing rules of the browser to make efficient frameworks. - Browser creators create new rules, and create web components as a proof of work. - Framework creators are angry, because they need to manage both old rules and new rules. - Framework creators make the error of not asking for the rules they truly need, because they can't imagine they could get them. - Browser creators make the error of proposing components, because they think it's the better way to propose something to framework creators. I think this is a very serious communication problem. It would likely need people from both sides to spend years on the other side, to build a common understanding. To know if the solution is already ongoing, it would require to look how many framework creators have been recruited by browser companies to work on browser rules. And if things are going well for them. Is that a correct understanding of the situation?
The most confusing thing to me is the name, web components are the shadow dom thing and not the component model in general right? Really trips me up as a backend guy entering fullstack like your grandma thinking java and JavaScript are the same. We have a prod app in polymer and it sucks really bad, but I've found angular to be pretty decent so far
ngl i have been watch theo for only 2 week for now and one thing i really loved about him is his honestly and style to explains it [ especially the old DB comparisons with diagrams odc ]
I have used both. Web components are a bit too low level for me, you deal with events, query selectors, conditional dom is too verbose, the disconnect between an element and its JS is sometimes bothering. If you add a framework on top that would help you with state, data and event binding, well, then it looks more like React. Web components could help with wrapping some non-react JS library. For me, React is simply quicker to develop. If you need to create a large number of Web components on the fly, not sure if it is really that more performant than virtual dom (most likely not). Web components are supposed to augment an existing dom tree, React is generative in nature, you compose things.
22:48 You have this issue with HTMX the most cause now all you have is HTML element properties. It's pain in the butt to figure out if this thing is a boolean or just needs to exist to function. I hate it so much.
Web components are a big reason why I quit my last Job. We were retiring Angular and looking for an alternative. Backend people kept pushing Web components while I just wanted to get shit done using react.
"Web components possibly pose the biggest risk to the future of the web that I can see" If it is seen as bad and less people are using it then I don't get why the above quote would make sense
I don't understand why the Shadow DOM is not more flexible. Why does it have to simultaneously isolate styling, enable slots AND isolate JS. It feels so silly to build something as powerful and just blunder the finishing touches.... Why didn't you build those isolation mechanisms separately, opt-in? Flexibility is what makes the Web awesome, why build a feature like this? Also the fact that they didn't even think about forms until after it was out just blows my mind. Such a poorly thought-out feature.
@@nandoflorestan I have been working with web components for the past 5 years. You either opt in on everything or opt out of everything (slots, style / js isolation, etc). If you have more experience than me and you know how to have both slots and non-isolated styling, please enlighten me :)
Bias: I work on a team that does this for our chrome extension Take: Web Components are GREAT as BLACKBOXED OUTGOING COMPONENTS (a.k.a. compile target). They work BEST when I'm injecting them into someone else's page and I need my components to be ISOLATED from that page's control. Web Components SUCK as imported components. Too much effort to make it work with a framework. Half baked thought: Part of me wonders if there is a way we could take a more "Web Assembly" route where there's a common, generic, not exactly HTML/JS/CSS, compile target (WAT) that can be compiled into another language for executing (WASM).
To the 'disabled' vs 'aria-disabled="true"', could we not allow for just 'aria-disabled' also? Yes, another piece to maintain but still. There are others like it that we could do the above. I get screen readers sometimes do their own things so might not work.
I remember trying out web components and the next day I went right back. I am by no means an expert though. Edit: when I mean right back I meant right back to what I was using before (svelte)
I used WC for 1.5 years in production many years ago. I remember Polymer, how Google stopped supporting Custom Elements V0, and how many problems it got to us. Remember how we tried to make SSR work with Shadow DOM. I saw how all WC influencers burnt out. It was some fun. Now, WC works much better, but I still prefer React.
1:11:46 what? Most people who knowingly use divs are developers too. Why would users of webcomponents have knowledge of them if they weren't somewhat curious in making them. How is that indicative of a problem? It's just selection bias and bad assumptions
I have not yet watched it but here is my take: make a simple select component which has entries to choose from, server side rendered as web component. sounds simply, huh? :D its not! first of all a select component can not have a slot. second funny thing: when your LitElement Component gets rendered on the server, it has no access to its children. it can not read the html option tags it has as children, so no chance to bypass the slot problematic by just throwing the options in as children. my task was to build a component library that can be used with any framework and that can be styled ion figma via design tokens. i managed the figma design token part but i got frustrated with a simple select component. now i understand that you wont be able to write a single SSR web component that works in each framework. the best you could do is to write a own WC framework. but if the select component is already such a challenge, how much fun will it be to make web components reactive framework ready? :D yes, this sadly can end in a dead end for me :/
It is funny enough, that Web-Components are praised for being cross framework, while I try to avoid using Web-Components, because I made the experience, that they often don't work as expected in combination with a framework (in my case Angular) 😂
I use Web Components. I like them. I don't get the hate.
I've written hundreds of them.
Do you use a framework? Do you work on a team? Those questions aren't meant to be accusational, whether they're meant to help me understand how you use this web technology that I never see myself using.
They just frustrated that it doesn't work like their framework and have to learn new things
@@JonasLiljegren Perhaps in some cases, but overall, I don't think that is true. As shown in the video, every major framework has wanted to incorporate WCs, and the problem is that they don't really work for that. As stated in my other comment, the big issue is you have to ship/parse JS to make them work, and the logical next step is SSR... which WCs are not designed for. They are a browser engine tool.
@@RonNorthcutt It should work if you don't try to overcomplicate things (with bundling and compiling), using Declarative Shadow DOM, signals and modern JS.
Surprised to see you here, but I really shouldn't. Already knew about your Web experience
Theo seems to not understand that the Browser itself uses Web Components and Shadow DOM for what seems like simple elements. An HTML element does NOT have to be a primitive that is not composed of smaller entities. Just take a look at the simple input element or the details element in the Chrome console. Both of these elements have a shadow dom with functionality that exists simply by placing it on the page. In fact, Web Components are just an extension of this idea that we should be able to have access to this kind of power to create our own elements. And just like input and details, these elements can be composed of other elements.
And none of these browser-provided web components require the special handling that user-provided web components require. If a user-provided web component were as easy to use as an input element or details element, then I suspect that there would be a lot less complaining about them. Personally, I'm not in the hater group on this, but I'm not a supporter either, and I really think your glib comment is brushing aside actual issues brought up in the video.
Shadow Dom is cool.
Web components aren't
@@erics2133 if you use custom web component the same as you would an input element (aka create it, pass in prompts as strings and listen at the component level for events it emits) then it is the same as an input element.
@@hishnash Except for the cases brought up in the video. I have noticed that the people that dislike web components the most tend to be those maintaining web frameworks, so it's likely that in the simplest cases, you don't encounter as many issues.
@@erics2133 There is nothing requiring framework devs to use components. There are thousands of web features that are not used by most frameworks.
I think the main pain many framework devs had with components is they wanted to one to one map them to the higher order structures that the framework has rather than just treet them the same as native components like input, select, etc.
Hey Theo, loved discussing with you in the chat during this whole thing. I had a few thoughts that didn't really seem to stick during the conversation, which I think may clarify some of the issues you're seeing.
The biggest thing is that, while framework authors' frustrations about being sold the idea that web components are for them are entirely legitimate, that is a flawed premise to begin with and should never really have been part of the discussion. If framework authors can make use of it, that's great! But for the most part, it's not aimed at them, but at a completely separate use case. The people pushing for frameworks to integrate with web components in the way you and Ryan described did both those framework authors and the web components API a disservice.
The primary function of web components is, put as simply as possible, to extend HTML. They aren't and were never "components" in the same sense as frameworks use the term, and the name "web components" has caused a lot of confusion as a result. They're far more similar in practice to an XML extension than a framework component - you're defining a new HTML element, in terms of the existing elements, with its own inherent semantic meaning and built-in behavior. That comes with both benefits and drawbacks, and it fundamentally serves a very different use case than what frameworks call a component; for example, while you might legitimately build an entire website almost solely out of React components for dozens of layers deep, and that deeply nested structure is idiomatic for React, you would effectively never use web components that way if you want to keep your sanity intact. But conversely, web components are perfect for cases like custom form inputs, where you don't want to have to think about the innards of your custom form input basically ever after you've built it, and you simply need the browser to see it as just another form element to be processed - a localized, self-contained use case, which may be used multiple times on a single page, in which the details of what's inside the component are best hidden away.
That said, it's not like web components can't be composed, but rather that defining web components in terms of other web components isn't idiomatic. They can be composed using s (the idiomatic way, where the shadow DOMs of each component aren't actually nested and the nested component is treated as a child of the outer component, rather than an implementation detail), or just by jamming one web component in another's shadow DOM (not idiomatic, structurally implies that the nested component is a hidden implementation detail of the outer component). Notice the distinction I'm making there - the shadow DOM is where implementation details live, and the light DOM is where content lives. That concept is fundamental to understanding the design intent behind web components, why slots work the way they do, and so on; I would even go so far as to say it's the underpinning of the entire API. And it's for exactly that reason that I claim putting web components inside each other's shadow DOM is, while entirely possible (contrary to claims in the video), not an idiomatic way of using them in general - they're designed primarily for building small, isolated parts of your site, not for structuring your entire site architecture around.
There's tons more I have to say on this topic that isn't really suited for a TH-cam comment, so please don't hesitate to reach out here or on Discord (@foxoninetails) if you'd like to learn more about web components as their own technology, rather than only in the context of their unfortunate conflation with frameworks. I'd love to hear your thoughts =)
You should write a blog post detailing where web components are good and bad, this is really interesting and I’d love to read a more refined version of it!
I prepare a Video i destroy Solid and react he is payed he hast Skill issues i do not understand how He can BE this way He complains about Shadow Dom and 1000 none neede stuff
If composing them was never a goal, why are they called components?
@@PotravnyyVV One, they shouldn't be called components, because it's a name that already had a ubiquitous and orthogonal meaning in web development, the reuse of which has been a source of immense confusion and misinformation.
Two, the point I'm getting at is that they aren't meant to be composed *with each other* in the same manner as component-driven architecture - that is, defining web components in terms of other web components. They can still be "composed" with one another as parent and child elements, but that's a content-container relationship, not a part-whole relationship, which is a very different mindset.
It seems to get missed but I'm not actually suggesting that Web Components are made for frameworks. I went through that years ago but I know better now.
My grievances are mostly around that their existence and the need for frameworks to account for them puts an overhead everywhere. If I could just be like I won't use them anymore, the end, it would be fine. But the problem is they make everything else on the platform more complicated. I think maybe proxies in JS are probably the closest equivalent in terms of change.
Like now when someone does an `innerHTML` on a div some random user JavaScript code might run. So for example if that Web Component uses Signals and the innerHTML happens in an Effect well who knows what's going to trigger that re-running again. I have an endless pile of silly examples like this because I get Github issues. I almost published a followup article longer than my original article of examples like this but realized it was too in the weeds. The impact of these decisions are endless.
I'm not suggesting Components !== Elements for the sake of trying to align Framework Components with Web Components. I'm suggesting not all things should be DOM elements and the extensions ot the platform have profound impact on those trying to use the platform.
The article content is good but pretty much everything Theo says off the cuff about web components is incorrect but said with such confidence
React brain virus I’m afraid
@@roccociccone597 It is a cult at this point. React is the new PHP.
Can you give me an example?
@@edwardallenthree 26:40 Event handling is tricky but you absolutely can put web components in web components.
@@edwardallenthree
- Theo keeps saying "Attributes and properties can only be strings" several times in the video. This is wrong, properties can be any JS value just like for regular classes. Attributes being strings is true.
- He's talking about slot behavior at th-cam.com/video/UrS61kn4gKI/w-d-xo.htmlsi=iTWVs1Dh0MtOaexz&t=3389, where he mistakenly believes you have to name your slots, and does not seem to know just putting `` will accept all element children. It is possible to name slots and select elements to to in those slots, but that's optional or when using multiple slots.
- Can't remember specific instances, but it's very noticeable that Theo's knowledge about Web Components is very basic. Hating on class syntax is typical React brain scenario (especially given how many "gotchas" hooks have)
Web components by definition cant fail. They are in the browser forever. And they keep getting better, albeit slowly. For something like a design system with primitive UI components they make way too much sense. I'm excited for Web Awesome.
i actually also created a component library with lit. the cool thing is you cant destroy them with css and the only way to style them is by using its token based design system.
Table based layouts are also in the browser lol
More and more bloat, maybe Browsers will remove them at some point.
Web component as a response to React ?
Are you certain of this, Theo ?
I remember reading about WC in 2011 or 2012, if not before. React appeared after that.
Web Components v0 were introduced in 2011 by Alex Russell. They eventually evolved into the v1 spec which was introduced in 2016. I am not sure if he is referring to the v1 spec or if there were any drama between that and React.
@@dogokuduring his time at Chrome they were implemented. This happened after React. No?
Web components are another tool in my toolbox. I worked on a workflow designer using D3. This was integrating with a legacy application, so the shadow dom keeps everything nice and isolated. Web components fit nicely into this projects requirements.
This is the way.
WCs are a tool, and the proper application of that tool is critical. I don't think the issue is that WCs are "good" or "bad"... I think the issue is that the dream of using WCs as the primary strategy for a component based application is not really feasible. It can be done, but it is not the best approach.
8:33 I don’t get the standards argument. Standards evolve and can improve. CSS and JS has been evolving quite nicely over the decades.
i think he meant that once something becomes a web standard, we are stuck with it regardless of if its still good or not (because now some websites have used this standard, and the burden of compatibility is on the browsers).
@@kangar1797 that’s my point too. CSS, JavaScript, HTML, HTTP, and many more are all individual web standards, that every site relies on. Sites built 20+ years ago and longer can still run. Sure, we get stuck with past decisions, yet somehow, all these standards have managed to improved tremendously over that time. Some of the new HTML elements means we don’t need to roll our own components, improved CSS means we don’t need to use as much JavaScript, or as much superfluous HTML structure for layout. Improved JS APIs and syntax means we have access greater functionality that brings us closer to that native app feel. So, no, I don’t understand that argument against standards. I agree that Web Components are currently largely unusable because they are not easily composable. I’m currently building a framework that makes use of them, so I understand some of the issues at play. The problem isn’t actually the Web Components themselves; they are actually pretty good, in concept. There are a few missing pieces that make them unusable though. Have a think about how you might map an array of JS objects to an HTML element. You can’t add a JS loop in the middle of HTML code like you can in some of the front-end frameworks. But we should be able to. We should be able to do the same thing as what ERB/Razor pages/PHP does but using JS. The other issue is passing custom callbacks to web components. Only the on* attributes (like onclick) can accept JS and execute them. We can’t define our own and send custom events as arguments. I’ve had to do a lot of weird hacks to make an arbitrarily define attribute to accept JS and to have it execute in the correct scope. The last missing piece is reactivity. I know there is a push to get Signals into JS, but that would be a mistake from my perspective because they are not low level enough. The actual requirement is Object.watch() and Object.observe(). They accept a variable containing a value of object and a callback which gets called whenever the value or object changes. The difference from signals is that it doesn’t keep track of dirty state. The call back gets fired the moment the value changes. That’s the functionality I have identified as needed to make Web Components useable. There are a few more subtle missing pieces m, but those are the large ones. Basically we’re missing an HTML/JS templating syntax.
Both are still awful once you exit the frontend web dev sphere
@@_phenomen I’m not sure what your point is. Pointing out those three things doesn’t detract from the fact that many many many standards do indeed improve over time. It doesn’t even make a comment on their positive or negative impacts. All it says is some standards are no longer used. E.g Flash had an insanely positive cultural impact. We’ve lost so many good applications and games and animations because someone decided to deprecate it.
@@br3nto Yeah but the fix is to have "Web components" and "Web components 2", or change the name and be as ambiguos. We are stuck with "this version" of we components, even if we can have more standard to create components. The current standard CANNOT CHANGE, and that's the point on the statement
It's like if css grid was dogwater. We can have other css rules and properties to aid in the creation of layout, but there can only be one grid, and it's behavior cannot change
We use a handful of web components. every single one is basically a full SPA written in vue designed for easy embedding in other projects. I doubt anyone who's embedded them even knows what a web component is. it breaks down to "to use our widget, stick this script in your head and you can now use this 'new html element'"
"The people who don't use SPA frameworks are hobbyists" laughs in 80% of the web is built in PHP (although it's possible to use PHP with frameworks) and 77% with jQuery (For comparison, React is ~18%). Her conclusions violate sanity checks, so either her data is flawed (e.g. sampling bias) or her analysis is. This doesn't mean that browsers shouldn't work with frameworks, but they also shouldn't treat non-framework use case as second class citizens.
Also, I find it funny that she cites not using NPM and "the standard set of tools we [framework users] have all gotten used to to" as evidence that non-framework user's aren't serious developers. It would be like me as a Rust developer finding that people who were using primarily typescript are the less likely to use the standard tools in my toolbox (e.g.Cargo and rust-analyzer), and arguing that this proves that typescript developers are hobbiest and students. It turns out that when you (general you, not you specifically) define "non-hobbyist" as "someone who builds software using the same tools you use", you find that only the hobbyist aren't using the same tools as you. This says way more about your definition than the nature of developers who don't use your tools.
80% of the web is built in PHP and a large percentage of that is never getting touched again
This isn't a great interpretation of what she said...the people who write pure JS ONLY (not "don't use SPA frameworks" like you said) work by themselves, and don't use npm as one example. Can you build an actual pertinent argument that those wouldn't be hobbyists?
Most of the web is legacy sites as well; not sure how jQuery (which wouldn't even qualify as vanilla JS in this study) is relevant here when the discussion is about building web dev tooling for the future.
The vast majority of websites the average person uses today are built with React. Your numbers don’t reflect reality for the average person on the web.
@@PraiseYeezus First off, the actual quote was "the developers who were using vanilla javascript" (not "pure JS ONLY"). And the very next sentence was "and so that allowed us to say 'no, the bulk of the web uses frameworks'". The entire context makes it clear she's contrasting the SPA approach with the old school MPA with links, forms, and some light scripting approach. This is also why it's not at all clear to me that JQuery wouldn't count as vanilla JS for the purpose of her study. It's certainly much closer to vanilla JS than it is to e.g. react.
"Can you build an actual pertinent argument that those wouldn't be hobbyists?" See my second paragraph. People who don't write SPAs usually don't use tools built primarily for writing SPAs, film at 11. This doesn't prove that people who don't write SPAs are hobbyists, any more than the (probable) fact that Theo doesn't have Cargo installed right now prove's he's one.
As for building for the future (note: she was talking about the browser here, not about external tools like NPM, vite, typescript, etc). a) there are still plenty of new projects being deployed using the "old" MPA approach, as evidence by things like e.g. job postings, and b) legacy websites are still being maintained (I would know, doing that is part of my job) and getting new features, so treating this use case for the web as second class would be harmful to them. Whether they're legacy or not, they're still most of the internet.
Again, this isn't an argument that browser makers should have an adversarial relationship with SPA developers. Rather, I'm saying that it's incorrect to treat SPAs as the primary use case and ignoring other ways of building websites (aka how most of the web is built).
@@spht9ng citation needed. If you check e.g. builtwith (not sure if youtube's spam filters would eat a link to it), you see 18.6% of the top million websites use react, and while it does rise for the top 100k and 10k, it's still nowhere near JQuery's usage. I respectfully suggest that your estimates are based on what you see as someone who develops websites using tools like react, rather than an accurate impression of how the web is actually built. (Which is fine! Goodness knows my own chosen tech stack isn't the most popular way of doing things).
youtube and github uses them and saying no one uses them its ridicilous
inspect a native date input in the browser... oh, it has a shadow dom. yes, we are all users of WCs. even non devs or none youtube users
Tbf youtube has possibly the worst over engineered and slow piece of s**t frontend library imaginable. Not a great endorsment
@@TheMrKeksLp And yet, here we are.
@@CristianKirk Despite the UI, not because of it!
But to be clear, thats not web component's fault. It's just google being google
Also one great example of good use is mux video web component
why did you give Lit an A rank in your framework tier list if web components suck?
lmaoooo
Because that ranking was made from the biased comments from people who consistently use them; their frustrations and appreciations. You can't create a proper ranking without using an unbiased party who is proficient in all and prefers to use none of them.
I’m a WC fanboy, but here I’d tread carefully. I think it’s fine for folks to shift their opinions on things as they learn and grow. That said, I still don’t agree with Theo’s take but calling this out when it’s clear that Theo is evolving his opinion probably isn’t fair, since I’d hope all of us can do what he’s doing. For example: Maybe I could be convinced to totally drop WC someday, I just am not yet.
I don't think web-framework authors are impartial on this issue.
They built their entire paradigm around the world before custom elements, and are psychologically and financially locked into that paradigm.
Once you embrace the next paradigm: HTMX/zero-build/vanilla-js, webcomponents make a lot of sense.
that's not really a strong argument because web components could, in theory, have great interop with your web framework of choice if they worked proper.y
This is not correct. We may not be impartial but it isn't because frameworks came first. Solid was created because Web Components existed. That's why Solid has lightweight components because I thought WCs would fit that role. Svelte/Vue Slots were based on Shadow DOM slots. We learned from Web Components and realized what did and didn't work.
@@ryansolid you're still thinking within the spa paradigm. I don't even disagree that wc aren't ideal there.
wc are a great fit however if you use no frameworks or a lightweight one like htmx.
@@ratoshi21 Framework components and web components serve different needs, so the framing of them as competing and therefore biasing SPA framework authors against them doesn't make sense. Framework authors would benefit significantly if the web component API was better for them, and it wouldn't make frameworks less useful (and I'm saying this as a fellow hypermedia enjoyer).
@@lunar_mycroft i never said they compete.
Lit makes web components awesome. I've loved working with Lit. There's a reason it's used by Adobe, Microsoft, Red Hat, ING, etc.
Is it me or is video quality restricted to 360p for this video?
youtube is still processing better quialities, the video was probably just uploaded
It's probably taking some minutes until HD is available
@@theultimateevil3430 makes sense, thank you!
Still processing probably
Theo release the video to soon. TH-cam still processing his upload video. If you want better quality on image just come back in a few hours.
I love web components. Sure, it lacks when compared to React / Svelte Components. But when you have to work with react, svelte, and php, and plain html, and God knows what js framework spawning in the future. Creating 1 web component to use for every project suddenly makes sense.
I think this is the best use case for web components. When you have many microfrontends all sharing the same UI components / framework, using web components and making thin adapters makes a of sense
Damn, uploaded 11 minutes ago and the video is already segmented using SponsorBlock.
The best web component of them all 😎
@@HolyMacaroni-i8e adblock is more harmful to the author of the channel, than sponsorblock, which saves only your time by skipping through the ads parts
@@HolyMacaroni-i8e you don't need to move your hand to skip that 2 sec. also it will save you a ton of time when watching a ton of video.
@@HolyMacaroni-i8e because there can be multiple sponsors, interaction reminders, interludes, recaps etc. It skips them all and you don't have to skip through to find the end of it which isn't always clear. If i'm not directly at my PC or TV and just listening it's also pretty helpful there.
@@HolyMacaroni-i8e don't get the point of manually skipping sponsored segments when I can skip them automatically with an extension and don't even need to know there are any in the video
The dream js project is a todo app with 234 dependencies that will be outdated 24 hours after you send the code to production 😍
lmaooo
I believe the main issue of these discussions about WCs are due to them being called Web Components.
For example, if they were called Web Elements, clearly showing they are meant to extend HTML not build apps per se. Then the conversation would be about how these edge cases should be ironed out, not about whether they are unnecessary or not. Beyond considering this a necessary browser standard or not. They clearly need to be worked on so they behave better.
As a platform, currently the web benefits for having this API for experimentation. However, from the experience framework authors shared, it is undeniable the initial implementation left a lot to be desired and still needs to be worked on. Just as it happened with CSS, when the current bugs are solved, WCs will neatly fit into a place when simpler frameworks are enough for most of the web.
Remember this, big frameworks are only needed for big web applications. You don't need a framework for your blog with some interactive elements. Or a wiki site. Or a news site.
But this is a different conversation altogether.
What I believe WCs promise now is to think about a web where most websites don't need to have heavy reactive frameworks. As Lea said, you would use a WC for an element which would exist if dev resources for browsers/standards would make it given infinite resources.
To close my thoughts I would add, that we are already in a phase were big frameworks are starting to not be used for simple sites, with the push for vanilla js and server-centric frameworks.
The survey done by the Chrome teams was done quite a while ago when JS sucked a lot more and the web wasn't as mature. Maybe today results would be different. With even some folks coming back from Typescript. And if web components have performance issues, then maybe as part of this less is more trend, they should be optimized as they did for the frameworks before. I remember when React, Ember and AngularJS slowed the web for having too much JS shipped on slow internet and doing a lof of thins on JS when engines weren't as optimized and computers weren't as powerful.
28:18 hydration isn’t how most SSR works. Most SSR generates the entire HTML server side. No need to fetch JSON. Hydration is a very CSR concept.
38:06 OMG you would never build HTML in that way using web components! That’s trying to apply a CRS concept to something that is inherently not CSR. You would either build the HTML in its entirety on the back end using a template, or you would build the HTML in JavaScript on the front end. What even you just described seems purposefully obtuse.
DOM-Elements are Lego, WCs are playmobil. With Lego you can build great things from simple things, with WC you can only do what they are supposed to do. And they don't work well together.
but you can actually use web components inside web components. thats not an issue as long as the are registered beforehand. they will be in the slot next to the shadow dom. this means their shadow domes are actually never nested, which is pretty clever actually
Nice, I learned something new today.
@@zlatanonkovic2424 happy to hear :)
I'm dubious on the claim that "not all elements are components". Every element has properties, every element is an event emitter. Further, many elements have logic and state; details element can be toggled, forms have validation state, a search field has a "filled" state which can be cleared using the X or esc key, buttons can be disabled, a fieldset can disable all the form fields within it, etc. Even complexity isn't a delimiter since form fields like an upload field have multiple sub elements and date fields have complex popovers.
Not all sites use a framework. I don’t love the API, they are far from perfect but if you just want one or two interactive components they are better than nothing. It’s nice that they work without a build tool.
The vast majority of popular sites today are using React. Way more often than not
YES - WCs are a great option to have, and make a ton of sense in the right situations. They aren't a silver bullet (nothing is), but can often provide a simpler solution where needed.
I think you should think of web components more like a replacement for than anything else.
They're more like separate apps and composable in the same way you can use Firefox, Excel, and Dropbox at the same time in your OS.
Doesn't Theo make some sort of file-upload-thing? That is a perfect target for web components: you define a strict API for your new _element_ , include the script on the page, and it can be instantly usable in _any_ framework, from static html, through Rails strange no-js thing, to hyper aggressive SPA frameworks that _have_ to control every aspect of the DOM.
Maybe "web components" is a bad name, but one should keep in mind that web component isn't really anything. It's a common collection name for several technologies, custom elements, shadow dom, et cetera. Similar to MVC.
Kinda a dumb take. Web components are amazingly useful for things like design systems (eg. with Stencil, which is a fantastic framework). When you're working on small projects, you don't need a design system and something like shadcn works great. The vast majority of web code is not in small projects though, it is written for huge projects at large companies. That is where you need a design system. Often you want this design system to work across multiple frameworks. And that's where the issue arises: getting the frameworks to interop with each other is INSANELY hard. None of them play nice with each other. Try rendering a Solid component inside of a React component as a child. It's extremely hard while allowing that React component to be used like an Angular component in an Angular app.
Web components are supposed to fix that. You can implement a common set of HTML elements (which in larger apps SHOULD NOT be app-specific), and it allows you to reuse it in any framework out there. That's why you have companies like Amazon or Ionic using Stencil to build design systems, because it allows them to use whatever the right framework is a good fit for the job they need, while using their design system.
Sure it's harder to implement for framework authors. But framework authors have completely ignored interop stories for years and it is not a priority for them. React has no reason to care about interop with any of the frameworks that have a quarter the size of it, because if a component is written already that you need, it's probably going to be written in React. Web components might be a shitty interface for framework authors to have to adopt, but for the kind of interop that companies and larger teams need, it is a necessary pain that would've had to been done if we needed good interop anyways.
hot take: we don't need more browser standards.
in fact, most recent changes to the web only made it worse
*"Just"* use X. *"Just"* do Y. "Just" minimizes someone else's efforts, when it's said this way. It's arrogant and inconsiderate to suggest the other person couldn't imagine X or Y. I usually learn more about the context of a problem when I ask: "Have you thought about X or Y?" with some humility instead. I *"just"* didn't know everything. (Disclaimer: "just" _can_ be used without arrogance in other ways, but we techies seem to use it in the arrogant form a lot.)
^--- in reaction to the opening OP's tweet: "Everyone should *just* be using Web Components".
totally agree with this, respect all efforts
This makes me even more bullish on web components. No build step, modular, follow web standards.
Honestly, this is why I have gravitated more towards HTMX. You get all the benefits of a responsive application with minimal JS and pure HTML. SSR is already a thing, and a necessary part of most systems, so why not just focus on delivering the rendered HTML fragments directly? Even simpler.
23:00 The cause of this difference is "due historical reasons" as with everything in life. In fact, the "disabled" alone is not a flag but it's an SGML (of all things!) shorthand notation for *value* "disabled" if exactly one attribute allows value "disabled" (yes, SGML is truly this brain-damaged). Technically it's shorthand for writing disabled="disabled" which is also *why* you have to use the latter syntax if you write XHTML instead (XHTML being implemented in XML, it obviously doesn't support SGML shorthands).
The funniest part is... I have no idea what web components are.
Me neither until i found accidently at some point back in the day at courses that i undergo, forcing me to build entire front end with it. definitely not a good experience tho
I just had to ask ChatGPT to explain web components. Last dev in 2008 started back in 2022 I'm like Rip Van Winkle. ;)
You can think of a component like html + css + js
It also uses a shadow dom so you can't accidently change it and also it'll work in every library/ framework
It's like but for elements, not whole websites
just think of them as custom html tags that have their own custom behaviours. They normally have a hyphen to distinguish them from the standard tags. If you inspect this website, you'll find them, eg in the description of videos.
Web Components are only not useful because there are a few missing pieces to make them useful. There’s actually no declarative way to build and compose them. There’s no HTML templating language, you’re either in JS land or HTML land with no way to properly mix the two. We need something like ERB or Razor pages but for HTML/JS. And there needs to be a way to register these components and to fetch/register them as required.
@@br3nto lit not good enough for you?
There is the template element which can be used to create the HTML for your Web Component, even comes with support for slots.
register/fetch is done with importmaps
@@WesseI sure, but that’s just as useless on its own. There are still all the missing pieces I mentioned in o make it usable. Just think how you would loop the though an array of values/objects to populate a ul, or table, or select with values. You can’t. Well you can within JS land, but you can’t intermingle JavaScript and HTML within the template element. The experience is missing the actual templating syntax to intermingle HTML and JS.
@@br3nto i mean you could use lit which seems to address of those concerns
48:02 it's NOT a stupid argument if at least one team member needs to add new functionalities... I've worked on 10 year old sites with jQuery and it's fine. But I've also worked on 4 years old projects with react and just getting your environment to work is hell.
We use them from time to time, if we need something, not too complex to write, that can be just dropped to any project and used.
I love web components. They’re a terrible compile target for frameworks.
Neither were web components a response to React, nor did React introduce the concept of a component. Web components were proposed in 2011 and even before that, libraries like Angular.js and Knockout.js came up with the concept of a component.
They were a response to jQuery plugins. Few remember that
The reason there are two pronunciations for attribute is because one is for the noun and the other is for the verb. I attribute my success to web components, the verb. An attribute on an html element, the noun. As for why they are pronounced differently but spelled the same... because English is a mess :D
As someone who works with web components professionally. They’re not good for the browser except in the 3rd party widget use case. They‘re not bad as long as you use a framework on top of them. But they’re just the wrong solution to the problem of “competing web standards”. Mitosis by builder is the better solution that if I was on the W3 committee I would work towards adopting. It’s a translator, not a standard that needs to work in the browser. So framework authors only need to translate into that abstraction of what a component is, and then it can compile down to native web components or to react or to vue , vanilla html+js or even react native. Having a library of mitosis as a unified definition for headless ui components and then combine it with shadcn’s new cli and it means you only need to make sure that everyone can translate to mitosis to convert to any other standard. That’s what I would push for at least
Opening statement saying the people who benefit from web components not being “good” are saying it’s bad is hilarious
I'm significantly more pro web components than theo, but this was addressed in the video/stream and I think the explanation made sense. The framework authors point out that if web components were good for their use case, it would allow them to offload some of their job to the browser (which is a good thing). Further (although they didn't say this themselves), since web components fill a different role than framework components, the entire premise of them competing with framework components is flawed, IMO. If you're building a SPA, you likely would end up using a framework regardless.
320p on TH-cam 18 years ago was HIGH quality, I was still uploading 240p videos back then :)
Thank you for mentioning your "alternative" pronunciation of 'attribute'. Half my brain kept trying to figure out if you were trolling, actually unaware of how 99% of the rest of the English speaking world says it or if I lived in some strange pocket of the world with its own accent 😆
A React developer who can't code JavaScript or understand how browsers work is one of the biggest "taxes" we end up paying in the long run.
These frameworks have ruined webdev.
There’s a generation of people who know nothing about DOM and CSS.
Frameworks have cost billions of dollars and millions of developer hours.
So many strong arguments in these comments, so much rational debate. That was sarcasm. Do better.
1:15:32 This is like we all agreeing on the Lego pieces and the Lego fundamentals like the hole sizes under every block then coming up with a secondary hole sizing system and asking everyone else to modify their already built stuff to become compatible with the new hole system as well as the old to be attached in any standard.
I use TailwindCSS for my personal projects as I love it, however when using regular CSS it seems to be overall better to not have scoped styles but instead follow something like BEM - this way you almost never have styles pollution, you have meaningful classes and you are able to style anything without worrying about scope etc
A second good example of a web component is the Mux Video Player. I agree that 90% of the time, the complexity of a Web component is not worth it when considering integrating it into a production application and team.
To me, the most important takeaway from this article is that Web Components tried to be the solution to a problem that was still being defined. It could have been everything it promised, but it was set in stone before the problems it tried to solve were even defined.
As a final point, try to find a clear post about building and publishing a web component with something as common as Tailwinds in a framework like Vue that is supposed to be supported at the framework level. There isn't.
37:05 This shit sounds completely insane. "Modern" front end development seems to be suffering from collective schizophrenia.
If you are building the usual web application you don't need a hydration framework at all, and yes, then you should avoid the schizophrenia and use something simpler. You only need server side rendering if you are building something like a portal or a store, where latency is crucial (the UI must appear instantly or people will leave).
@@nandoflorestan It's comforting to know that hydration is opt in and you don't have to do it that way.
lol! I love Theo actually called out his own pronunciation of attribute - which to me is like nails on a chalkboard.
Every time Theo talks about "ah-TRIBUTES" I think he is reviewing The Hunger Games!
Theo puts the emPHASis on the wrong syLABLe. It is AT-tributes, dammit. 🤣
I love web components and I think we should continue to develop them because all of these different other platforms kind of suck butts.
Yep we should improve this standard. But instead they invest millions into build tools to make building their awful react code a little faster and to avoid react being slow as all hell.
@@roccociccone597 exactly.
I have to disagree. Although picking the right tool for the job is important, web elements offer a "bare metal" aproach to development. No over arching designs and just raw functionality. Frameworks like react have over arching archetecture that you must consider. For example, you wanted to make a drag and drop utility? In react, you would need to either use some kind of portal or use state when reparenting an element or risk breaking the virtual dom. This aproach doesnt scale with many elements either. In web components, your aproach is purely in js land and all you need to do is reparent. No weird states involved. Its easier to make a certain building block in wc that doesnt follow conventional standards that are found in common component libs.
1:15:39 - "The one catch is, it's only for React"
Not anymore 😎
- Vue has a port (with Nuxt support)
- Svelte has a port
They're "unofficial" but do the job and community loved
What a surprise, people that make a living creating, maintaining and using bloated frameworks are critical of web components.
Your assumptions are totally wrong here. 1. The assumption that there is a conflict of interest -- there is none. 2. The assumption that these people wouldn't be fair.
To overcome your own prejudices, forget who is saying the thing, and consider the argument. In a rational conversation, arguments have value in themselves, and it doesn't matter who uttered them. A rational conversation is a clash of arguments, not of people. And if you don't change this, honestly, you shouldn't be a part of any engineering discussion.
@@nandoflorestan ...this is a hilarious and extremely blind take.
They are a tool. This article, and Theo on the whole are hyperbolic.
Remember, you are reading an opinion piece, not a proof.
You both have valid points, to be fair. There is a conflict of interest, indeed. But I don't think that there should be competition among bloated frameworks and webcomponents. I am an admirer of many JS frameworks, and would see a lot of benefits in using webcomponents despite all the magic that comes with frameworks and out-of-the-box features. However, I honestly feel that webcomponents have endured certain disregard simply because people are too vendor locked and adapting to a new technology is rather complicated and in this case have no encourage from most big players.
There are approaches you need with web components to make sure you have a good time with your favorite framework. Usually the most important part is writing the web component in your framework so it has the usual hooks.
I did not know about tracking clicks before load. That sounds problematic where a person multiple clicks because it's not working then what is the framework supposed to do? Also, why is the page so large that the user has time to click things with a standard connection?
I'm going off to rust land for FE form here on. So as much as I like web components, I'm going to need to figure out what I'm doing before I can touch them again. (Hoping to add shadow dom support to leptos)
I used shoelace. I sucked. Not because shoelace was bad, but because web component sucked. Changing CSS is so hard when it should be so easy.
at 1:08:35 I built a custom element html editor solely based on standard implementation or vanilla. It's doable.
html editor as in you make web pages with it. It's fairly complex, and pretty fast in my experience with custom elements.
I mean, it's dirty as I was bored with it by the time I finished implementing server side page construction with it and wasn't able to refactor it. But it works, it's fast, it's portable.
Dirty as in, all the code is in the component itself and no external code along with it. It's one big spaghetti.
I just checked on it right now, it still works, minus the linking since I used a static ip instead of prepping it dynamically. But the gist of the code works, and it's fast.
I'll post a video of it for anyone that's interested.
ironically TH-cam serving you this video with web components 🤷♂
I think there is a really valid point in moving some more modern features to the web standard, if nothing else, to get away from the whole npm shitstack that everything is build on nowadays. We are currently developing with a non-js stack (go backend) and none of the frameworks really support is well. In this, web components has been huge- mostly since they are so "lightweight".
The best way to keep your code maintainable is to never hire anyone who looks or acts like this guy.
And teach your juniors to be vigilant against his breed of baseless opinion.
I have some hiring advice: never hire someone who's comments on an issue they don't understand are pure ad hominem.
360p enjoyer 😎
When I joined my new job the first task they handled me was fix the mess of microfont end they had build (built by an external) using vue web components, it has tons of issues only resolved by not so elegant patches, and a hell of a deployment pipeline.
Now we switched to Single SPA and it has it's challenges but it's way better
I love Ryan's mind flow 5-hour streams.Usually I fall asleep in the middle...
My to-go sleep stream 😁
1:17:05 I think the fact that web components do not behave similar to native components (e.g. cloning) is the issue here and that part should be fixed in the web standards. It doesn't matter if the difference is hurting framework's internal implementation or native JS code you're trying to write by yourself.
If this is caused by specs, then the specs would need to be improved to fix this and make web components to work when a fragment of DOM is cloned, or at least immediately throw instead of silently failing to clone parts of the fragment.
Changing some old APIs to throw in case web components are passed in is an acceptable solution if the API has design that truly cannot support web components. Hopefully the error message would prod towards the newer API for *the same use case* that does support web components. Every API that has to be broken must have newer counterpart that has minimal changes to make it compatible with web components.
the number of web standards is kind of like RISC vs CISC in cpu processors, kind of. we curently have CISC. of course html/css/js interpreters (browsers) are pretty different than low level processors that have to be implemented with wires, but it's interesting to draw the connection of how we basically have the same thing at a much higher abstraction layer, now js frameworks are starting to be compiled / dsls such as with svelte or react's jsx and upcoming forget-compiler, so maybe the complexness should be implemented at the framework level instead of the browser level just as in cpus the complexness switched from being at the cpu architecture level to the "low level" programming language compiler?
one standard we are locked in to in the browser is javascript itself. that's why they invented web assembly. but my understanding is that web assembly is not currently as capable as it could be compared to javascript
the real point of the browser is not to run javascript websites, but it's to provide an enviornment where a user feels comfortable quickly opening new pieces of software, without the friction of waiting for a big file download, going through an installation process and worrying about potential malware. theres no reason i can think of that web apps shouldn't be able to be built in kotlin or swift or any language you want, and it could potentially help things like performance or time to write, or creativity of ideas based on what a different kind of language makes easy. I mean look at all the hoops the effect people are jumping through to make functional programming work in javascript. meanwhile in the backend world every language gets to coexist and you can pick which one you want
Backend frameworks/languages only have to comply to one minimal standard: HTTP Protocol (get/post/etc query parameters, message body). They then can invent their own standards on top of that that are not codified as an official standard of something, eg REST, GraphQL, SOAP (dead). Maybe this way of doing things gives how things are done more room to evolve and become better. In the video you argue that components should be done by the framework level not the browser, in the backend http rendering and data communication is mostly done by the language level which is like an http framework.
whereas for front end frameworks they have to comply with JavaScript which is a whole programming language with specific tradeoffs compared to others.
It’s interesting to think about the different ways to do abstraction that have evolved in different places of computing.
From a pure developer perspective I completely agree. My current job is working for a school district trying to revamp their entire web profile. They are locked into a CMS and it sucks. Wit that said I have a lot of experience bending a CMS to do more than it was designed to do.
I explored web components as an option and after looking into it and experimenting I eventually had to ask why? If it's a case of normal web content why does one even need it? There should be little to no JS anyway. Why force more JS just to avoid using a pile of divs with id and class names?
If one needs to build an actual web app and must use JS then why not just use something like React instead? If it's a complex web app that is? Sometimes we just need something simple and importing React is kind of a waste. Developers tend to just default to a framework because. Even if it's not needed. Kind of like how every app tends to default to a state manager when there may be little to no actual global state needed.
In some ways web components can kind of make sense when someone wants a more elegant way to build a UI without having to choose a framework. It also selects a standard that is there automatically vs others having to learn a new framework. Maybe.
It feels like an odd special use case for them to really make sense. Even for my own odd "I'm going to push and warp the heck out of what this CMS is supposed to do" I just don't really see a valid reason to use them. The only way I might ever consider it is if it did eventually replace frameworks which it clearly is never going to do. I don't work with a single person that has even ever heard of them and I doubt they will ever use them. They just doin't feel designer or business friendly the way web standards were supposed to be. The way web components should have been is without the use of JS at all. A native built in way to create web components that does not need JS.
I'm a fan of vanilla JS but I'm also a fan of not using JS at all if it doesn't need it. Thats why web components feel kind of odd and out of place. For page content and use in a CMS we really don't need them at all. For a complex web app it's kind of crude and there are much better solutions. They kind of feel like a hack or budget framework.
I'm sure they have some potential but right now I just don't see it. The only real advantage I see is I can use them within a CMS page fairly easily without the huge overhead of loading the React library. I tend to create reusable CMS modules where I paste in web standards and then lock them so nobody else in the school district can break them. It works and it's much easier to paste in the code when it's a pure HTML, CSS and JS file vs trying to use a framework.
Eventually I want to try to convince the district to go headless and use Contentful and NextJS. Until that point I think I will avoid web components since I doubt they will provide me much benefit over just having a article or div tag with a custom id or class name.
By the way, Lit is intentionally not a framework, it is just a library where its intended to be deprecated as the standards evolve.
can you link to the article in the description? while i appreciate your input, it's very frustrating to hear up to 5 sentences from you before i hear one from the article.
As a non-native English speaker and frontend enthusiast, I like this kind of blog reading content very much. 💖
1:08:26 I hate this moment. What's the problem to use a framework to build a Web Component? When I think about Web Components I think about Video Players, Audio Players, Whiteboards, Code blocks with Highlighting, etc., So components that have quite some complexity and where you might want to use a framework to build it. But you use Web Components to share that functionality. It's not a replacement for React. Don't think about Web Components how you think about React components. It's different things. And if you implement a blog with React, you have a lot of components and it doesn't make sense to write these components as Web Components. But when you embed e.g. a podcast and want a better player than the default HTML audio player, it makes totally sense to load an podcast player as web component. Like the Podlove Web Player, it's a great player, but it's included via an . And that's kind of nasty. So web components are a good way to embed things like an audio player as an alternative to an . The article may complains about events in web components are not the same as outside the web components. Well events inside of s are way worse.
In my previous company we used web components for a feedback widget and a header, because different pages were written by different teams which used different technologies. Some used Vue, some React, some Angular and web components where a good way to have a reusable component that can be used in all that pages. And we used vue to implement the feedback widget. Where is the problem with that? It's not a good replacement for the frameworks, but web components are really good if you want to embed some functionality in a website as a wrapper layer.
At minute 46 I suddenly learned why I hated working with zendesk so much. It was hell, and nothing worked right.
15:03 them being willing to listen to pushback could be partially due to the fact that people can switch off of them if they want to
edit ok you said it right after lol. but it feeds into ryan's point
1:15:00 I think this is a great illustration of the current situation and the web components definitely belong to the left side of the spectrum just as you put it.
However, we need some new standards to live around ShadCN level or even slight closer to "component I wrte in my codebase" level but we don't have anything yet.
And it's still unclear to me if there can be any non-framework agnostic solution here.
Whatever solution is chosen, I hope it can fully interact with DOM. If you have any kind of virtual DOM solution where a piece of JS code overwrites the actual standard defined DOM from virtual DOM, that's definitely a model that cannot co-exist with standards compliant code. We would need a solution where you can have some server side rendered components co-existing with code that uses native JS code to work with the DOM without both sides stepping on the toes of the other side.
It seems to me that web components (WC) are great if you're trying to re-implement something like `` but it's a poor fit for server side rendering (SSR). Unfortunately, many JS authors try to use web components for SSR.
Browsers really would need to support SSR better but the current state of WC is not designed for that.
I for one take issue with what Lea(sp?) wrote when she went from "CSS will never work" to "Clearly this was the solution all along." I hated CSS when it was introduced, and I still hate it.
Why? The fundamental aspect of CSS' architecture, the cascade. Or better explained, CSS' lack of scoping (without~25 years of bad hacks) making styling a website *still* fragile ~25 years later. 🤨
But then there is a reason I was so happy to finally leave web development 5 years ago and became a backend-only developer. 🤷♂️
Web component should mainly be used when adding widgets/addon to other sites outside of your control.
Using it in the same environment is not a good appeal.
Stripe, for example ,leverages web component to make people use their some of the buttons.
I get where Lea is coming from, but it means we're forced to adopt to using web components opposed to picking a framework we're most comfortable with.
What I understand:
- Framework creators are used to hack existing rules of the browser to make efficient frameworks.
- Browser creators create new rules, and create web components as a proof of work.
- Framework creators are angry, because they need to manage both old rules and new rules.
- Framework creators make the error of not asking for the rules they truly need, because they can't imagine they could get them.
- Browser creators make the error of proposing components, because they think it's the better way to propose something to framework creators.
I think this is a very serious communication problem. It would likely need people from both sides to spend years on the other side, to build a common understanding. To know if the solution is already ongoing, it would require to look how many framework creators have been recruited by browser companies to work on browser rules. And if things are going well for them.
Is that a correct understanding of the situation?
The most confusing thing to me is the name, web components are the shadow dom thing and not the component model in general right? Really trips me up as a backend guy entering fullstack like your grandma thinking java and JavaScript are the same. We have a prod app in polymer and it sucks really bad, but I've found angular to be pretty decent so far
ngl i have been watch theo for only 2 week for now and one thing i really loved about him is his honestly and style to explains it [ especially the old DB comparisons with diagrams odc ]
I have used both. Web components are a bit too low level for me, you deal with events, query selectors, conditional dom is too verbose, the disconnect between an element and its JS is sometimes bothering. If you add a framework on top that would help you with state, data and event binding, well, then it looks more like React. Web components could help with wrapping some non-react JS library. For me, React is simply quicker to develop. If you need to create a large number of Web components on the fly, not sure if it is really that more performant than virtual dom (most likely not). Web components are supposed to augment an existing dom tree, React is generative in nature, you compose things.
1h20m to read some blog posts? Jeez. Software Dev news makers miss the point completely.
Watch for the commentary or just don’t watch
@@AvanaVana Thats him missing the point. I mean the commentor. Regardless of the opinion shared in the video lol
22:48 You have this issue with HTMX the most cause now all you have is HTML element properties. It's pain in the butt to figure out if this thing is a boolean or just needs to exist to function. I hate it so much.
Web components are a big reason why I quit my last Job. We were retiring Angular and looking for an alternative. Backend people kept pushing Web components while I just wanted to get shit done using react.
"Web components possibly pose the biggest risk to the future of the web that I can see"
If it is seen as bad and less people are using it then I don't get why the above quote would make sense
I don't understand why the Shadow DOM is not more flexible. Why does it have to simultaneously isolate styling, enable slots AND isolate JS. It feels so silly to build something as powerful and just blunder the finishing touches....
Why didn't you build those isolation mechanisms separately, opt-in? Flexibility is what makes the Web awesome, why build a feature like this?
Also the fact that they didn't even think about forms until after it was out just blows my mind. Such a poorly thought-out feature.
You don't talk like you have much experience with Web Components. The shadow dom is indeed optional.
open shadow dom exists, not really recommended
@@nandoflorestan I have been working with web components for the past 5 years. You either opt in on everything or opt out of everything (slots, style / js isolation, etc).
If you have more experience than me and you know how to have both slots and non-isolated styling, please enlighten me :)
I like that the Venus Project is used as an example of Utopia.
Bias: I work on a team that does this for our chrome extension
Take: Web Components are GREAT as BLACKBOXED OUTGOING COMPONENTS (a.k.a. compile target). They work BEST when I'm injecting them into someone else's page and I need my components to be ISOLATED from that page's control.
Web Components SUCK as imported components. Too much effort to make it work with a framework.
Half baked thought: Part of me wonders if there is a way we could take a more "Web Assembly" route where there's a common, generic, not exactly HTML/JS/CSS, compile target (WAT) that can be compiled into another language for executing (WASM).
༼ つ ◕◕ ༽つ framework authors TAKE MY ENERGY ༼ つ ◕◕ ༽つ
To the 'disabled' vs 'aria-disabled="true"', could we not allow for just 'aria-disabled' also? Yes, another piece to maintain but still. There are others like it that we could do the above.
I get screen readers sometimes do their own things so might not work.
Dammit Theo, why do all of these ad sketches have to claw at my existential dread?
my brother in christ please make a shorter video if you actually want to get some info across to people
ADHDbrained zoomers won't inherit the kingdom of heaven
Is he even christian?
I remember trying out web components and the next day I went right back. I am by no means an expert though.
Edit: when I mean right back I meant right back to what I was using before (svelte)
I used WC for 1.5 years in production many years ago. I remember Polymer, how Google stopped supporting Custom Elements V0, and how many problems it got to us. Remember how we tried to make SSR work with Shadow DOM. I saw how all WC influencers burnt out. It was some fun.
Now, WC works much better, but I still prefer React.
1:11:46 what? Most people who knowingly use divs are developers too. Why would users of webcomponents have knowledge of them if they weren't somewhat curious in making them. How is that indicative of a problem? It's just selection bias and bad assumptions
Theo has not grown as a developer in the last couple years at all.
I have not yet watched it but here is my take: make a simple select component which has entries to choose from, server side rendered as web component. sounds simply, huh? :D its not!
first of all a select component can not have a slot. second funny thing: when your LitElement Component gets rendered on the server, it has no access to its children. it can not read the html option tags it has as children, so no chance to bypass the slot problematic by just throwing the options in as children.
my task was to build a component library that can be used with any framework and that can be styled ion figma via design tokens. i managed the figma design token part but i got frustrated with a simple select component. now i understand that you wont be able to write a single SSR web component that works in each framework. the best you could do is to write a own WC framework. but if the select component is already such a challenge, how much fun will it be to make web components reactive framework ready? :D yes, this sadly can end in a dead end for me :/
It is funny enough, that Web-Components are praised for being cross framework, while I try to avoid using Web-Components, because I made the experience, that they often don't work as expected in combination with a framework (in my case Angular) 😂
video quality only 360p?
Funnily enough, I was looking at that exact block post by Ryan Carniato, yesterday.
Video processing not done, only OG 360p is available
I haven't heard anyone talk about web components since about 2012
Best of your post reading videos yet.
I think the sponsor link is wrong