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.
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.
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.
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.
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.
@@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 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.
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
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'"
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.
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.
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 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).
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.
*"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.)
@@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 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
"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).
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
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.
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.
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.
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
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
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.
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
Sorry to say Theo but Ryan's article is absolute s*. Basically it is just a rant. I'm surprised you spent 1,5 hour on a post of a frustrated JS library author. There are more imporant things to cover, not everything is a reason to release a YT video... AI/crypto/Tesla bros are already doing that. I seriously expected more from this channel.
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.
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'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.
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.
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
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 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.
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.
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.
Web components were designed to act like a native widget and so kind of act like a hole cut from the page where you can't see what's happening inside. For composing them, you're putting holes into a now bigger hole. Anyone else see the problem here?
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 ]
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.
I'm glad to hear you praise Ryan. I've learned such a disproportionate amount from his work. He's one of those divergent thinkers with enough competence and confidence to offer real value from the ideas he pursues. I suspect he's doing to do a lot of great things for years to come, and I'm really grateful for the work he has already done.
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?
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).
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.
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.
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.
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. 🤷♂️
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).
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.
HTML is meant to be a generalized presentation of semantic information to user-agents. The concept of user-agent is not specific to web browsers or desktop app browser containers. The concept is also for accessibility (which the general developer community clearly do not care about), but also other platforms that could exist like augmented reality, virtual reality, etc. This is why people who understand the concept, still separate HTML/CSS/JavaScript. Web components are specific to web browsers, which is why they really don't belong in HTML, but frameworks are doing the same violation in a different way. I wish the majority of developers who utilize HTML for their needs, understood the concept of user-agent. Their awareness would force the HTML protocol to properly improve and benefit all developers across the board whether they are building 2D visual websites/apps, screen readers, or augmented reality websites/apps. It would also force proper improvement of user-agent influenced languages like JavaScript. Unfortunately, I'm a "lame" "boomer" for understanding and existing in the Idiocracy movie. 😭🤷♂
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 seems that the hobbyists who love web components have gathered with pitchforks in the comments. The level of debate generally amounts to, "Theo likes react so he must be evil and stupid." Who would have thought that the TH-cam comment section is not a place for serious developers talk about serious things?!?
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.
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.
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.
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
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.
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.
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.
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.
I wrote another comment on here, but this video is so long and touches on so many important points, I have to leave another. This whole discussion is basically the web version of free market vs. planned economics. Capitalism vs. socialism. The frameworks are the wild, free, innovative, capitalistic forces of the market. They survive and thrive based on their ability to be useful, fast, and provide devs with a great dx…otherwise they fail and no one uses them. Web standards are web socialism-centrally planned, controlled by the “government” of the web, constraining functionality and creating miles of red tape and bureaucracy, presumably with the interest that “evil capitalist frameworks” create inequality in features, lest a svelte or a vue user be unable to view JSON interactively. Web standards and working groups are like laws and congress/lawmakers. Except we don’t elect them, and many of us have no idea who they are or what they do, even though they are open.
Let me get this straight... you're claiming the frameworks don't use Web APIs? They don't use fetch, promises, async/await, etc.? They don't use HTML elements like form, input, ul, details? These are Web APIs. The whole web is built on Web APIs even the current JS based frameworks. This is not like capitalism vs socialism at all. The framework authors just don't want to use this particular Web API because they have already hacked together solutions for things this Web API now solves natively. It's like how jQuery came up with a way to query elements in the DOM but now we can do it easily natively with querySelector.
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.
No component is generalized, until it is. No matter what your goal is when making it, you have no idea when you are making a component if it will ever get used more than once... until it does. So i agrrr that the distinction between different "types" of components is asinine.
"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
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) 😂
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
1:22:30 What is this magical use case where you need a web component but not a framework? Huh? You either make something static HTML and do not need anything else or you make things interactive and need any kind of framework- WC is another one - and in that case why use WC then add another framework later??? WTF.
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).
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
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.
![SAFEPLANET - ดาวเคราะห์ [ THE PLANET ]](http://i.ytimg.com/vi/4X1XL3I_k3c/mqdefault.jpg)
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.
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.
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 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
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.
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 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.
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
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'"
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.
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.
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.
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.
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
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 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.
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.
*"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
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
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
"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).
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 :)
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.
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.
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.
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
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.
360p enjoyer 😎
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 love web components. They’re a terrible compile target for frameworks.
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
320p on TH-cam 18 years ago was HIGH quality, I was still uploading 240p videos back then :)
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.
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
Sorry to say Theo but Ryan's article is absolute s*. Basically it is just a rant. I'm surprised you spent 1,5 hour on a post of a frustrated JS library author. There are more imporant things to cover, not everything is a reason to release a YT video... AI/crypto/Tesla bros are already doing that. I seriously expected more from this channel.
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.
hot take: we don't need more browser standards.
in fact, most recent changes to the web only made it worse
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. 🤣
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.
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 love Ryan's mind flow 5-hour streams.Usually I fall asleep in the middle...
My to-go sleep stream 😁
Best of your post reading videos yet.
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.
As a non-native English speaker and frontend enthusiast, I like this kind of blog reading content very much. 💖
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
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 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.
ironically TH-cam serving you this video with web components 🤷♂
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.
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.
Web components did not fail. Web components are alive in angular land.
Funnily enough, I was looking at that exact block post by Ryan Carniato, yesterday.
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.
Web components were designed to act like a native widget and so kind of act like a hole cut from the page where you can't see what's happening inside. For composing them, you're putting holes into a now bigger hole. Anyone else see the problem here?
So basically like all component libraries that people just use without having a clue what happens inside of them?
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 ]
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.
I'm glad to hear you praise Ryan. I've learned such a disproportionate amount from his work. He's one of those divergent thinkers with enough competence and confidence to offer real value from the ideas he pursues. I suspect he's doing to do a lot of great things for years to come, and I'm really grateful for the work he has already done.
I owe him for so much of my success
He's wrong about web components tho.
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?
༼ つ ◕◕ ༽つ framework authors TAKE MY ENERGY ༼ つ ◕◕ ༽つ
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.
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.
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.
At minute 46 I suddenly learned why I hated working with zendesk so much. It was hell, and nothing worked right.
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.
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. 🤷♂️
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).
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.
HTML is meant to be a generalized presentation of semantic information to user-agents. The concept of user-agent is not specific to web browsers or desktop app browser containers. The concept is also for accessibility (which the general developer community clearly do not care about), but also other platforms that could exist like augmented reality, virtual reality, etc. This is why people who understand the concept, still separate HTML/CSS/JavaScript. Web components are specific to web browsers, which is why they really don't belong in HTML, but frameworks are doing the same violation in a different way.
I wish the majority of developers who utilize HTML for their needs, understood the concept of user-agent. Their awareness would force the HTML protocol to properly improve and benefit all developers across the board whether they are building 2D visual websites/apps, screen readers, or augmented reality websites/apps. It would also force proper improvement of user-agent influenced languages like JavaScript. Unfortunately, I'm a "lame" "boomer" for understanding and existing in the Idiocracy movie. 😭🤷♂
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 like that the Venus Project is used as an example of Utopia.
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 seems that the hobbyists who love web components have gathered with pitchforks in the comments. The level of debate generally amounts to, "Theo likes react so he must be evil and stupid." Who would have thought that the TH-cam comment section is not a place for serious developers talk about serious things?!?
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.
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.
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.
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
I misheard "sup nerds" as "sub nerds". Perfect opportunity for *sub*liminal messaging.
P.S. Subscribed!
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.
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.
That Appwrite plug 👌
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.
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.
By the way, Lit is intentionally not a framework, it is just a library where its intended to be deprecated as the standards evolve.
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.
Dammit Theo, why do all of these ad sketches have to claw at my existential dread?
I haven't heard anyone talk about web components since about 2012
I wrote another comment on here, but this video is so long and touches on so many important points, I have to leave another.
This whole discussion is basically the web version of free market vs. planned economics. Capitalism vs. socialism. The frameworks are the wild, free, innovative, capitalistic forces of the market. They survive and thrive based on their ability to be useful, fast, and provide devs with a great dx…otherwise they fail and no one uses them. Web standards are web socialism-centrally planned, controlled by the “government” of the web, constraining functionality and creating miles of red tape and bureaucracy, presumably with the interest that “evil capitalist frameworks” create inequality in features, lest a svelte or a vue user be unable to view JSON interactively. Web standards and working groups are like laws and congress/lawmakers. Except we don’t elect them, and many of us have no idea who they are or what they do, even though they are open.
Let me get this straight... you're claiming the frameworks don't use Web APIs? They don't use fetch, promises, async/await, etc.? They don't use HTML elements like form, input, ul, details? These are Web APIs. The whole web is built on Web APIs even the current JS based frameworks. This is not like capitalism vs socialism at all. The framework authors just don't want to use this particular Web API because they have already hacked together solutions for things this Web API now solves natively. It's like how jQuery came up with a way to query elements in the DOM but now we can do it easily natively with querySelector.
I think Ryan is the most famous person I knew before he became famous
good vid theo. more of this. less clickbait
Theo has not grown as a developer in the last couple years at all.
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.
No component is generalized, until it is. No matter what your goal is when making it, you have no idea when you are making a component if it will ever get used more than once... until it does. So i agrrr that the distinction between different "types" of components is asinine.
"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
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) 😂
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
1:22:30 What is this magical use case where you need a web component but not a framework? Huh? You either make something static HTML and do not need anything else or you make things interactive and need any kind of framework- WC is another one - and in that case why use WC then add another framework later??? WTF.
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).
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'm using Lit and I love it.
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.