I have been working on web components for last 6-8 months now using LIT, i think they are great for simple re-usable peices of an app but it's true that they have a long way to go before they can be considered as a replacement for the current frameworks
@@uidotdev sure, it makes sense as the video was focused on the core technology of WCs & it's true they are very hard (comparatively) to learn on their own They should make it simpler, i was able to learn LIT relatively easily because it looked very similar to class based components from other frameworks. But using a library feels like doing the same thing which WC were created to avoid 😃
@@nChauhan91 sometimes with lit and stencil it might be even worse. It might seem like there are two layers of abstraction instead of one with other frameworks. For me it is worth it cause we deliver our design system to all kind of stacks but for smaller companies with smaller teams and fewer stacks... not sure.
"Flash [...] Created by Adobe..." Abobe ACQUIRED Flash and but didn't contribute very much at all feature wise to it. Those accoladed belong to Jonathan Gay of FutureWave Software. FutureWave created SmartSketch. When AT&T aquired the hardware that it ran on, the software no longer had a platform so Jonathan Gay retooled SmartSketch to be an application that could output animated content that could be played in any web browser and called it FutureSplash Animator. FutureWave pitched the product to Abode but they apparently were not impressed enough to reach an agreement. Not long after Macromedia acquired FutureWave and their technology and the product would go on to be branded Macromedia Flash and Jonathan Gay would eventually become the CTO of Macromedia in 2004. The very next year in 2005 Adobe aquired Macromedia for 3.4 billion dollars as a means of getting the Flash product, and it became Adobe Flash.
Nice comment.. Not just interesting events, but very important to give context to the evolution of the Web with real facts. The video maker needs to get his priorities straight. Titling videos on unsettled matters in such authoritative terms and not even having the history nailed down, shaking my head.
I once interviewed at a heavy Web Components using company, without knowing too much about this tech. The questions they asked made a lot more sense in context after watching this video. I didn't get in, and now it feels like I dodged a bullet.
I think this video has quite some misconceptions. Web Components weren't never meant to replace frameworks or data-flow control libraries. They weren't event meant to replace templating and styling libraries. And this is from the get go. They, on the other hand, were meant to offer the basic bricks to create framework-agnostic, reusable, accessible elements. And they _do_ deliver this. Now, yes, of course developing "vanilla" web components is cumbersome - but the counterpart isn't using React, but rather basic DOM methods like document.createElement and .appendChild. Keep in mind that the concept of Web Components was born before React and hasn't changed, so the comparison with that is out of place. I repeat, they weren't meant to replace React, or Angular or whatever. In fact, they _work quite well_ with them (well, not particularly well with React, but that's React's fault). I think the best fit for Web Components at the moment is using them for UI kits (libraries of small, reusable components), but creating fully-fledged applications with them is already possible, although some libraries still need to be refined and there's definitely a much smaller community around at the moment. Personally I think the problems with Web Components adoption can be sum up with these points (one or more could be true for every case): - lack of support for Declarative Shadow DOM (no server-side rendering); - lack of support for Form-Associated Custom Elements (FACEs) (Firefox recently shipped a part of the spec); - the simple fact that if you're using Framework X and you already did everything in Framework X, you aren't compelled to use another technology to do something equivalent. The last point, on the other hand, brings the problem of framework lock-in, meaning that it's always hard to migrate from Framework X if for some reason you're forced to do so. In the end, relying so heavely on Framework X increases the team's technical debt. The good news is that Web Components - being framework-agnostic - actually _help_ migrating from frameworks. They also are great as foundational elements if you need to work with different third-party teams. I agree that the adoption has been slow and could have been faster (also because other vendors didn't share Google's sentiment and commitment about them), but they _are_ gaining traction, no doubt about it.
Don't tell anyone but all Browser developers have implemented complex HTML5 tags *with* Web Components technology, here on UA-cam you can see (set Show user agent shadow DOM in F12 settings) every tag has a shadowRoot and shadowDOM content you can't change. Some applies to and and a lot more. So only if your site has plain HTML tags, you *do not* use Web Components.
@@uidotdev That doesn't mean what you think it means. It says to end framework _wars_, not to end the _frameworks_. The goal here is to create interoperable components, not components that could work only with Framework X. One of the expected results was the ability to wrap components for Framework X in Web Components in order to use them with Framework Y.
Our company is starting to work with Web Components. I haven't been super hands-on with them myself but adoption is up by at least one data point 😁. I think the video is missing a significant piece, though: that frameworks like React also haven't coordinated state changes between components well*. This is why there are state management libraries. The existence of Redux, Mobx, Vuex, Riverpod, etc. don't invalidate the usefulness of React, Vue or Flutter--they just indicate that state management is a tangential concern. When working among a large team of developers, encapsulation is a useful concept /architecural-feature. Most changes should happen locally so that sub-teams can work independently. But then there remain boundary cases where multiple sub-teams need to be able to coordinate and agree on the interface their systems use to interact. Components + State Management, taken together, fulfill both sides of the divide-and-conquer approach to complex projects. * Arguably the advent of Context and Hooks addresses this somewhat but they arrived late relative to the popularity of React.
Very well stated. Frameworks and libraries come and go - the average is about 10 years for popular framework adoption to start waning. We have tools like StencilJS and LitElement in the meanwhile to help keep our core components as framework agnostic as possible. The next framework will probably treat Web Components with more respect now that support has gotten better and the tech has matured. Always bet on the web.
I think web components do have their uses and might become more popular. Just few years ago big issue was browser support that prevented web components adaptation. One big issue was Edge, which until the end did not support shadow DOM. Browser adaptation takes time, so for several years after Microsoft switched to Chromium there were enough users still using old Edge, that polyfills (which were good, but had their own issues) were required to run web components in productions. Now it is finally not an issue. Then issue was complexity of developing web components. Today it is also not an issue with many frameworks adding support for generating web components. Svelte, Vue 3, Lit all can generate reusable web components. As for uses, one use case is dealing with server side rendering. SSR is becoming more popular, but often data needs to be rendered only in browser, such as components that fetch data from APIs or show user specific data. When such components are used in big app, hydrating them could become a nightmare, especially if its a reusable third party component that is meant to work with all frameworks, but if logic is split in reusable web component, framework doesn't need to worry about hydration.
For me it was SSR, because that helps a lot with SEO, I always wondered why ionic didn't support ssr properly and now I know it's due to web components.
Genuine question, if you have a team that's building FE components using Svelte/Vue, why would you need to add an extra layer of complexity by shipping your code as web components?
@@RexGalilae I don't see why you would use web components. You know precise framework and SSR solution your project is using, so you don't need to support multiple environments. Your component is likely to use your project's styling, so you don't need Shadow DOM to detach UI from global CSS.
seems like if you want the web to move forward you need a big tech company who dog feeds the tech into their own projects. Apple early on pushed html5 before the appstore existed and they added css animations to make their product pages more interactive. Facebook and Google of course invented React and Angular to solve their own app UI problems. In comparison, web components felt like an academic undertaking coming out of a standard body.
I write low-level web components all the time. I find them easier to understand because I've been working with the DOM for so many years. Trying to get an input to focus after a user event is easy using the DOM, not easy in React for example. It's also really nice that I don't need to have a framework running to support the component; the browser just needs the component code. I'm looking forward to declarative shadow DOM to support SSR better for custom elements which don't have JS logic (used for layouts).
I think there’s a lot going on with familiarity there, focusing and element after an event is extremely easy in react. You just set const ref = useRef(), set the ref on the element (same as setting an id) and then ref.current.focus() in your event handler.
@@ryanz7667 Doesn't work if the component re-renders due to the user event. You'd have to add a useEffect to apply the focus and potentially a useState to determine if the focus should occur.
Stencil is brilliant. It cooperates with any existing library/framework or standalone. Web components still can work. Our use case was a company wide set of components that needed to work inside React, Angular and Wordpress.
Web components are fine in all the ways that don't matter... to devs who prefer convenience over all else, which it turns out is most of the devs outside Google and Firefox. We collectively deserve the timeline we live in.
"Do templates have to live inside the application logic? If so, this is a really poor decision" 10 years ago, everything was so MVC and I absolutely hated it. I just never felt that such an extreme separation was necessary unless you had different teams/members managing each part. I'm on a dev team of two, and it is much easier and faster to avoid those artificial separations.
It's a trade-off between structure - maintainability on the one hand, and ease and speed of development on the other. For small teams it might be advantageous to prefer the latter, but that decision is poor for a large-scale project.
99% of the case, separating Logic and Layout (as much as possible) is the correct way to go. You even do that in React when you abstract most of the logic to some hook or component abstraction, and the UI to its own component. SOME overlap is good. If you don't do that, you get those trainee-level 3000 line class components that are impossible to debug or add features to. So "being a nazi" about MVC separation is usually rooted in having to debug that type of bundled-together code in the past.
Agreed, the mere fact that this video claims communication is not handled well tells me the author has little to no experience with them. You can’t get more simple than passing data through properties and standard events….
I have recently tried Microsoft Fast which is a web component framework. I feel like it is great for developing display components when you couple the UI web components with other framework like react for state management it really shows it benifits.
For me one the biggest downside of WC-as-react-alternative is the lack of tooling (nothing like Jest/Enzyme, lack of SSR). But as some here already mentioned, it was never meant for architecting entire apps. On the day to day it's not terrible, though. (Working on WC-Projects since 2020)
Web compoments are extremely useful for scoping styles where you have no control over the web page your component gets used in. I can't throw in react or anything else, friendly s technically achieve the same with their own drawbacks (resizing to fit the content) - but a native web component perfectly enables us to offer our customers what they need: components that don't conflict with their page and are developed by a third party with no access to their CMS or their code. We can pretty much distribute it similar to ads - but this tag where you want this component to render and our scripts handles the rest for you without conflicting with your page.
This video was made too eagerly, web components are amazing especially if you’re working on web assembly or any kind of native wrapper framework. They’re absolutely the future,unless we move post-browser somehow.
Hey Tyler. Do you have plans do update your react course?. It was almost 2 years since it last updated. If so when will be expected release date. Thanks
The spec is low level, like assembler to high level languages Then again, if "61 ways to build web components" is not an indicator for their success then I don't know what is. Look up "all the ways to make a web component" article So many ways to create web components and they all work together seamlessly and transparently. React does not even come close. It's a closed environment
While viewing this video, which only goes into V0, I inspected the tag in DEVTools. WTF? It says the tag has a #shadow-root (user-agent) and contains a whole bunch of tags I can **not** touch. So Web Components suck, but all more complex HTML5 elements are built with Web Components. Better not ever use an again if you don't want to use Web Components.
I hate the sentiment that custom elements are too hard to use without a framework. The amount of frontend developers that have years of experience, but fall apart when they have to actually use standard APIs or understand issues not related to the framework they're using is astounding! No one teaches actual frontend development, only frameworks. On the surface, this is fine. However, it creates an entire class of "frontend developers" that can't function without their framework doing it for them. I'm not arguing that vanilla custom elements are the most developer friendly, but... It's not rocket science to use the platform or understand it. Nothing against anyone making a living riding the React train, but it's going to die. Every framework does as the platform evolves and new tooling is created.
As a design system dev I am pretty conflicted about WC. I use Stencil to output the design system in WC and also as an Angular wrapper. The fact that Stencil has to compile framework specific wrappers pretty much shows that web components are in a weird state where they don't play along nicely with others but rather even compete with the frameworks. I don't know, it is just weird to think sometimes.
It's not that Web Components don't play nicely with frameworks -- it's that (some/most) frameworks haven't prioritized making the experience of using with Web Components as nice as their proprietary components, despite the fact that Web Components have been part of the web platform for years now. But to be specific, other than React's refusal to acknowledge the existence of custom DOM events, and in general the poor support for type-checking custom elements in proprietary templating languages, Custom Elements are otherwise very usable without any wrappers in most frameworks (google custom-elements-everywhere for stats). So the wrappers are really just to close the DX gap that (so far) most frameworks haven't prioritized. And it's not because they can't or that it's somehow intractably hard, it's that they'd rather just focus on their proprietary model, standards be damned. I imagine they don't see a benefit to _their framework's adoption_ to allow commodity components to more freely move in/out/between frameworks; they'd just rather you rewrite all of these components in their framework once you decide their shiny ball is the next one to move to. It's the definition of optimizing for a local maxima -- my framework vs. your framework, zero sum. If frameworks would instead really prioritize first-class support for using the platform-standard component model (at least as an option, if not as the basis), think how much reuse could happen as component sets become stable and hardened and portable wherever the winds of front-end development take us after React/Angular/Vue fade into something new. In short, Web Components are a perfect interface for a coopera-tition model of framework evolution: interoperability at the component boundaries, innovation on the implementation details. Unfortunately, that common good has yet to be acknowledged by the existing framework juggernauts. So don't aim that disappointment at WC, aim it at the frameworks to do better.
There's absolutely no need to wrap Web Components for Angular, as it plays quite nicely with them. What Stencil does is handy but not really necessary. You can use Web Components in Angular as they are.
A world that no longer existed? Webcomponents are just beginning to be widely adopted, if anything i think it was way ahead of its time, and yeah perhaps the implementation was too complex and most people didn't see the point in it at the time. People cared more about making SPAs quickly which is what you get with something like React. Webcomponents were never really meant to replace frameworks, they were meant to provide a building block that others might later use to build frameworks on top of, that's what Google did, that's what Stencil does and that's what Vue and Svelte do with their custom-element wrappers. Comparing webcomponents to React is an unfair comparison, a more fair comparison would be comparing the difficulty of setting up webcomponents to setting up native reactivity using Proxies alongside your own virtual dom. If you're building your own webcomponents from scratch and complaining it's difficult to build stuff that way you might also want to try doing reactive SPAs using only native APIs and see how hard THAT is lol
Rad video! 2 points of contention though. Flash was created by MacroMedia, which Adobe purchased. Flash was not killed by Apple's iPhone, tho Flash was grueling on battery life. THE BIG problem with Flash was that it offered ZERO SEO. All the biggest companies paid to make "interactive" Flash sites. And when their SEO disappeared, they paid top dollar again to for HTML/CSS/JQuery to compete for SEO agian. Also, Flash sites couldn't be scrolled and took ages to load. Flash was cool, but doomed all along. Much respect! Awesome work!
I really feel like there was some whitewashing of Flash at the opening (maybe purposefully at the expense of Apple). Steve Jobs was right - Flash was horrible. Fundamentally, it was existential threat to all mobile computing; (1) its was riddled with security holes, (2) it was massively inefficient and drained the battery of mobile devices (3) Adobe had no interest in supporting the touch inputs that Apple spent billions in creating that the entire mobile platforms use today. The HTML5 transition was inevitable was mobile became mainstream. Adobe tried and gave up in getting it working on ARM. We know today, as a result of the Apple vs Epic lawsuit, that Steve Jobs wasn't being petty. Apple paid and worked with Adobe engineers to port Flash to the iPhone and iPad. After months of work the performance was awful; and only until after they tried did Steve Jobs fully reject Flash
Vanilla Web components can be nice and powerful. Any complex logic can be imported with a bundler. Lit and stencil are great for event binding, which is a pain point with vanilla custom elements.
My former enterprise company used web components - but they had a custom framework for managing them. Every team in the massive org would use WC + React for building different parts of the massive website, and it worked well given each team were effectively a silo. Beyond publishing documentation of the data and events that went in and out of the component, it allowed teams to independently maintain their products without stepping on each other's toes too much. The downside is everyone was locked onto using React and the custom web component framework. If you wanted to use SSR or Vite instead of Webpack, you couldn't. In the new company I moved to, they tackled this problem by moving to Webpack's Module Federation the moment it got released. MF apparently can work with SSR. Unfortunately I moved out before I could see it in practice.
Thanks for the great comment. What was the value in using both WC and React? I've always felt like at that point, why not just have everything in React?
People hate change and from my experience, developers especially hate it. Just think about all times new version of Windows came out or new big update for something came out, people don't want to update because they don't like change. Humans are creatures of habit and routine.
The industry has always swung back and forth between aggressively separating concerns, and tightly coupling them together. And there's always resistance on both sides. Personally I was very against it, but after using Vue single file components, and more recently, finally learning React... It's not that bad. I like CSS, and so long as what I'm writing is *actually* CSS, I don't care wear I write it...
@@billkammermeier That was only introduced later in Visual Studio 2005 and was purely to avoid conflicts with the designer tool-changing the generated code can lead to bugs and errors. It is only separated by a single method `InitializeComponent`, generated by the designer. All the UI and logic can be co-located in the same file as it was in the earlier versions of Visual Studio.
Anaconda just came out with a new web framework, which uses web components and lets you run Python in the browser. Will be interesting to see if that helps make WC more mainstream
I wouldnt bet on it. Pyscript might be fine for python developers to grt their feet wet making apps or wrapping a program around a ui, but i dont see any profesional web developers adopting it as it serves absolutely no advantage at all to have python run in the browser. In fact, pythons block-indent syntax and poor support for lambdas make it a bad candidate even if we didnt have javascript.. Besides, what are you going to do when you need a feature node supports? Learn javascript so you can serve an app made with python? If people want to use pyscript more power to them but if thats where we are at in 5 years im going to teach myself how to coal mine.
I've used web components since 2014 and haven't ever found the need for any javascript frameworks. The only need for things like React, Vue, or Angular, is in getting a job, because so many companies find themselves locked in they insist on existing experience with those frameworks.
Shopify implemented theme into their newest default theme and have to say - its very performant and easy to work with. Doubt its enough to bring them back but was a cool thing to see done well.
Is the problem that they didn’t start from the developer ux and work backwards to figure out the technicalities and principles? Instead they figured out the principles and theory that sounded good to them and didn’t prioritise what it was like to develop for?
Web components story isn't over, and to be more precise this was a misinterpreted story of web components. You might not see or use web components but they are used by some design system library
Lit isn't a framework, it's a base class. Web components aren't meant to replace frameworks. Context is most important. How you choose to architect is based a lot on the scale of your project/ enterprise. There's a situation for every decision.
Can't agree. I think custom elements gained a lot of traction in the last year. You can build them with vue, svelte and the amazing lit library. I love them for traditional ssr projects. E.g. Drupal. They allow easy interactivity and decoupling of FE from BE
This video is talking about "Web Components", as in the proposed standard of bringing native component functionality to HTML outside of JS frameworks like Vue/Svelte/etc. It's not talking about "web components", as in writing custom elements. Writing custom elements is great, but there's no real way to do that outside of using JS frameworks. It would be nice to do that just by writing native HTML. The "Web Components" standard discussed in this video touched on how the proposal for that never really took off.
I've been working with native web components a lot lately, and the biggest thing that frameworks like lit give you on top web components is template bindings and some reduction in boilerplate; tbh, if they made a standardised, optional vDom to use for template bindings, I wouldn't be missing much from the more fleshed out frameworks/libraries.
In interviews we are often only told to use vanilla javascript. But in the interview, when asked to build a widget for example it's a good idea to have ui components in your code. So how do you suggest we do that? Should we use native web components (which are quite complex), or build functions returning templates?
This is more a signal that interviews are broken rather than anything about Web Components. In that scenario though, I would choose to write functions with pure DOM manipulation over raw Web Components.
@@DK-ox7ze Don't let time be a limiting factor. You can learn anything :) While it was a little bit of a joke, I truly do mean that if you want to learn vanilla JS and how DOM works, to build a simple UI library. React is quite simple if you take the basic concepts of it. Do away with JSX and dig into the API and you'll understand its simplicity. The hard parts of React are the implementation details such as the scheduling and virtual DOM diffing.
I'd really like to try using web components together with HTMX to create a single page application that lives in the backend. It seems so much simpler than dealing with frameworks.
You probably should change your title as this video is not a Story about Web Components, more of a rant about why they are not as relevant as frameworks with only surface level arguments. What I can see from your point of view is that the expectation is that Web Components replace frameworks in some way, but they never meant to do that. What they do is to plug into the DOM and have efficiently rendered behaviour snippets, one that is used for design systems and plugins. The are not meant to manage your state, they meant to display snapshots of your state. Like, there are 120+ unique components just on this site and if you look through them they either serve a particular UI, or handle a particular rendering job. As a story, I would have expected that you present the problem in detail, the state where it started, the various evolutions of the implementations, the current state, adoption, and role. Include the fact that many frameworks you have mentioned do use Web Components as their rendering engine or have a variant that do uses it. Include a showcase where Web Components are heavily used, and where they are not. While the shown libraries are relevant, they are hardly a representation of the entire Web Component usage. The standard is adopted to all the browsers years ago and many just use the standard directly without the helper libraries you selected. It would have been a lot more insightful if you were able to find a source that measures the actual Web API usage or compare the frameworks' variants to showcase your point. I feel like you wanted to tell a story, failed to understand the original situation and the problem, mid-way decided to start comparing apples with oranges then choose examples that support your view and draw conclusions and declare one framework in particular as a winner of some sort of competition.
Had no idea web components didn’t “pave a cow path”, but that makes so much sense with this historical context. This is a much watch channel for anyone seeking to better understand the history of the web, needed to understand where it’s at today
1:05... AHEM. That was Macromedia. Or if you really want go get specific, Jonathan Gay, the same dude that make the 80's game Dark Castle for the Mac. Flash was already dominant before Adobe acquired it.
I definitely feel that web components has use as framework-agnostic drop-in components. Plus, they are so nicely integrated in the browser. If I'm building regular (non-SPA) websites and need some bits of dynamic functionality, it seems like a nice fit. So to me they are a good companion to things like React and don't directly compete.
That's reasonable. I've always felt that at that point, I don't see much value in using a WC if you can just use a react component. But admittedly React support for WCs has been terrible until recently.
@@uidotdev Perhaps you're a developer of a payment gateway, and want to offer a great credit card field component =). I'm primary a developer of libraries for other devs. WC would definitely make the top of my list when I need to author an ui component, just like I'd prefer fetch over axios; the former is (now! finally!) universal/dependency free/opinionated even if it doesn't offer the same features as Axios. I find that generally my libraries reduce their dependencies over time as the web/node platform improves. But, if I were working on a single application that's not a dependency for many others, and the decision was already made to do a fat client/SPA, I also don't see a reason to build something with WC instead of React/Angular/whatever.
This! My take on WC is that its biggest fault was its marketing. Having worked on a component library for a +10k employee company, WC was a saving grace for it being a browser-standard rather than a runtime library. This made it possible that we were able to support every single website with the company.
@@DannyMoerkerke We get accused of this every video, regardless of how controversial or tame the topic is. I'm not sure what you said, but I promise we didn't delete it. Proof is that there are plenty of comments telling us how stupid we are - which is fine.
@@jaredwhite88 You're essential calling us liars, and that's fine. But I promise on my brand new baby daughter who is 3 weeks old, we're not deleting comments. I'm not sure what else to say. I couldn't care less if you love WCs and think we're stupid. If you look at the comments, I've only complimented others who have had opposing views.
Web component still solves a big issue for companies that want all their applications to be build with consistent stylings/branding and prevent devs from doing duplicate works in different teams. In those cases they can make a central SDK team that make common components and services and ship them to application teams as web components. Using web components, application teams are not restricted to Web frameworks used by SDK. For instance the SDK team can develop all there components using say svelte and ship this wrapped in a web component to any team regardless of the framework that team uses. Application team hence can completely focus on fetching data and control flows rather than remaking dashboards, grids, accordions
Your missing the point of Web Components.... They weren't designed as a replacement for the frameworks.... They are supposed to be used as framework agnostic components... Regarding authoring, just use a cloned template and slot it... e.g. static template ( ){ let temp = document.createElement('template'); temp.innerHTML = `My Component` return temp }() connectedCallback(){ let temp = myCustom.template.cloneNode(true) let frag = this.slot(temp.content) this.appendChild(frag); } BTW you don't need ShadowDOM... The real question should be why are frameworks garbage? The only framework that is even remotely performant is SolidJS. And why do they keep changing and adding junk code and complexity every year? On a side note TypeScript is for the most part just a clone of ActionScript (Flash). The real problem with Flash was too many insecure bloated library's.... It looks like history is repeating itself... Steve Jobs probably would have tried to kill the frameworks like Google has tried... This video has definitely given me something to think about though so thanks for the great content 😀
What if we start with a more simple (in theory?) approach: Have a way for HTML to natively import other HTML from separate files, similarly to how we can already import CSS & JS via & tags respectively. Could be a new tag that functions something like this: ** Consider this example: I want to make a very simple static website. It has 5 pages. Using a JS framework would be total overkill, so I'll just write it using native HTML/CSS/JS. I create a header component with a navigation menu containing links to all the pages on my website. This component has some CSS and maybe some JS to accommodate its functionality. Now I want to add this header component to all of my pages. I need to manually copy/paste the HTML that makes up this component 4 other times for the 4 other pages. Later, I decide I want to make some minor changes to the layout of the menu. Now I need to copy/paste those changes in every page again. This workflow just sucks, plain & simple. Part of the reason why I & others use JS frameworks is the convenience of writing a commonly shared component that can be easily added anywhere on any page, and easily modifiable from a single source. If there were a way to do _just this one thing_ alone natively by just importing one HTML file from another HTML file, that would be a massive improvement to developing websites natively as a whole. It should even have the benefit of being semantically meaningful as well. Web crawlers/search engines/screen readers/etc. should be able to navigate through the internally linked HTML from the tag that imports it & understand what it conveys, whereas dynamically rendering HTML using JS doesn't have that same benefit.
Micro front-end results in a horrible mess of code for a developer and a bad experience for the user. Use one framework not multiple as the cost to maintain multiple isn’t worth it for a business and the end user doesn’t need that much code shipped to the client.
@@uidotdev would you consider doing one one the transition of angularjs to angular that was a pretty big event and pushed a lot to use react and the current state of angular.
Hmm, it's not totally clear what is considered difficult about using WC? is it no JSX or is it the lack of default data binding? My understanding is that you can simply add other libraries to support that functionality or use a WC-framework that offers default helper functions for that
I have been working on web components for last 6-8 months now using LIT, i think they are great for simple re-usable peices of an app but it's true that they have a long way to go before they can be considered as a replacement for the current frameworks
Yeah we purposefully left out LIT and anything regarding WC in the future.
@@uidotdev sure, it makes sense as the video was focused on the core technology of WCs & it's true they are very hard (comparatively) to learn on their own
They should make it simpler, i was able to learn LIT relatively easily because it looked very similar to class based components from other frameworks. But using a library feels like doing the same thing which WC were created to avoid 😃
@@nChauhan91 Agree!
@@nChauhan91 sometimes with lit and stencil it might be even worse. It might seem like there are two layers of abstraction instead of one with other frameworks. For me it is worth it cause we deliver our design system to all kind of stacks but for smaller companies with smaller teams and fewer stacks... not sure.
We are also since a few months in the process of rewriting our project on lit web components.
"Flash [...] Created by Adobe..."
Abobe ACQUIRED Flash and but didn't contribute very much at all feature wise to it. Those accoladed belong to Jonathan Gay of FutureWave Software.
FutureWave created SmartSketch. When AT&T aquired the hardware that it ran on, the software no longer had a platform so Jonathan Gay retooled SmartSketch to be an application that could output animated content that could be played in any web browser and called it FutureSplash Animator. FutureWave pitched the product to Abode but they apparently were not impressed enough to reach an agreement. Not long after Macromedia acquired FutureWave and their technology and the product would go on to be branded Macromedia Flash and Jonathan Gay would eventually become the CTO of Macromedia in 2004. The very next year in 2005 Adobe aquired Macromedia for 3.4 billion dollars as a means of getting the Flash product, and it became Adobe Flash.
Feels a little pedantic but 👍
Nice comment.. Not just interesting events, but very important to give context to the evolution of the Web with real facts. The video maker needs to get his priorities straight. Titling videos on unsettled matters in such authoritative terms and not even having the history nailed down, shaking my head.
Thanks for this! I was gonna bitch about it myself so you saved me a few minutes.
@@blu3_enjoy lol
Bro, nobody cares. Most people know Flash from Adobe, so that's what's relevant to get the mind to recall what Flash is.
I once interviewed at a heavy Web Components using company, without knowing too much about this tech. The questions they asked made a lot more sense in context after watching this video. I didn't get in, and now it feels like I dodged a bullet.
😂 Glad it was helpful!
Best webdev channel on youtube I've seen so far, keep it up!
Thank you! That means a lot.
I think this video has quite some misconceptions.
Web Components weren't never meant to replace frameworks or data-flow control libraries. They weren't event meant to replace templating and styling libraries. And this is from the get go.
They, on the other hand, were meant to offer the basic bricks to create framework-agnostic, reusable, accessible elements. And they _do_ deliver this.
Now, yes, of course developing "vanilla" web components is cumbersome - but the counterpart isn't using React, but rather basic DOM methods like document.createElement and .appendChild.
Keep in mind that the concept of Web Components was born before React and hasn't changed, so the comparison with that is out of place. I repeat, they weren't meant to replace React, or Angular or whatever. In fact, they _work quite well_ with them (well, not particularly well with React, but that's React's fault).
I think the best fit for Web Components at the moment is using them for UI kits (libraries of small, reusable components), but creating fully-fledged applications with them is already possible, although some libraries still need to be refined and there's definitely a much smaller community around at the moment.
Personally I think the problems with Web Components adoption can be sum up with these points (one or more could be true for every case):
- lack of support for Declarative Shadow DOM (no server-side rendering);
- lack of support for Form-Associated Custom Elements (FACEs) (Firefox recently shipped a part of the spec);
- the simple fact that if you're using Framework X and you already did everything in Framework X, you aren't compelled to use another technology to do something equivalent.
The last point, on the other hand, brings the problem of framework lock-in, meaning that it's always hard to migrate from Framework X if for some reason you're forced to do so. In the end, relying so heavely on Framework X increases the team's technical debt.
The good news is that Web Components - being framework-agnostic - actually _help_ migrating from frameworks. They also are great as foundational elements if you need to work with different third-party teams.
I agree that the adoption has been slow and could have been faster (also because other vendors didn't share Google's sentiment and commitment about them), but they _are_ gaining traction, no doubt about it.
Don't tell anyone but all Browser developers have implemented complex HTML5 tags *with* Web Components technology, here on UA-cam you can see (set Show user agent shadow DOM in F12 settings) every tag has a shadowRoot and shadowDOM content you can't change. Some applies to and and a lot more. So only if your site has plain HTML tags, you *do not* use Web Components.
twitter.com/slightlylate/status/769684151091892224 🤷
@@uidotdev That doesn't mean what you think it means. It says to end framework _wars_, not to end the _frameworks_.
The goal here is to create interoperable components, not components that could work only with Framework X. One of the expected results was the ability to wrap components for Framework X in Web Components in order to use them with Framework Y.
Our company is starting to work with Web Components. I haven't been super hands-on with them myself but adoption is up by at least one data point 😁.
I think the video is missing a significant piece, though: that frameworks like React also haven't coordinated state changes between components well*. This is why there are state management libraries. The existence of Redux, Mobx, Vuex, Riverpod, etc. don't invalidate the usefulness of React, Vue or Flutter--they just indicate that state management is a tangential concern.
When working among a large team of developers, encapsulation is a useful concept /architecural-feature. Most changes should happen locally so that sub-teams can work independently. But then there remain boundary cases where multiple sub-teams need to be able to coordinate and agree on the interface their systems use to interact. Components + State Management, taken together, fulfill both sides of the divide-and-conquer approach to complex projects.
* Arguably the advent of Context and Hooks addresses this somewhat but they arrived late relative to the popularity of React.
Very well stated. Frameworks and libraries come and go - the average is about 10 years for popular framework adoption to start waning. We have tools like StencilJS and LitElement in the meanwhile to help keep our core components as framework agnostic as possible. The next framework will probably treat Web Components with more respect now that support has gotten better and the tech has matured. Always bet on the web.
I think web components do have their uses and might become more popular.
Just few years ago big issue was browser support that prevented web components adaptation. One big issue was Edge, which until the end did not support shadow DOM. Browser adaptation takes time, so for several years after Microsoft switched to Chromium there were enough users still using old Edge, that polyfills (which were good, but had their own issues) were required to run web components in productions. Now it is finally not an issue.
Then issue was complexity of developing web components. Today it is also not an issue with many frameworks adding support for generating web components. Svelte, Vue 3, Lit all can generate reusable web components.
As for uses, one use case is dealing with server side rendering. SSR is becoming more popular, but often data needs to be rendered only in browser, such as components that fetch data from APIs or show user specific data. When such components are used in big app, hydrating them could become a nightmare, especially if its a reusable third party component that is meant to work with all frameworks, but if logic is split in reusable web component, framework doesn't need to worry about hydration.
Great comment. Thank you!
For me it was SSR, because that helps a lot with SEO, I always wondered why ionic didn't support ssr properly and now I know it's due to web components.
Genuine question, if you have a team that's building FE components using Svelte/Vue, why would you need to add an extra layer of complexity by shipping your code as web components?
@@RexGalilae I don't see why you would use web components.
You know precise framework and SSR solution your project is using, so you don't need to support multiple environments. Your component is likely to use your project's styling, so you don't need Shadow DOM to detach UI from global CSS.
seems like if you want the web to move forward you need a big tech company who dog feeds the tech into their own projects. Apple early on pushed html5 before the appstore existed and they added css animations to make their product pages more interactive. Facebook and Google of course invented React and Angular to solve their own app UI problems. In comparison, web components felt like an academic undertaking coming out of a standard body.
I write low-level web components all the time. I find them easier to understand because I've been working with the DOM for so many years. Trying to get an input to focus after a user event is easy using the DOM, not easy in React for example. It's also really nice that I don't need to have a framework running to support the component; the browser just needs the component code. I'm looking forward to declarative shadow DOM to support SSR better for custom elements which don't have JS logic (used for layouts).
I think there’s a lot going on with familiarity there, focusing and element after an event is extremely easy in react. You just set const ref = useRef(), set the ref on the element (same as setting an id) and then ref.current.focus() in your event handler.
@@ryanz7667 Doesn't work if the component re-renders due to the user event. You'd have to add a useEffect to apply the focus and potentially a useState to determine if the focus should occur.
yeah, ssr + web components feels like a breath of fresh air.
some people create a hell with their react framework framework frameworks
Stencil is brilliant. It cooperates with any existing library/framework or standalone. Web components still can work. Our use case was a company wide set of components that needed to work inside React, Angular and Wordpress.
Yeah Stencil is rad. Thanks for watching!
@@uidotdev Story of Stencil please 😅
Does it do anything that Svelte doesn't?
So maybe we got the alien timeline but didn’t know it. That explains a lot actually.
🤔 you may be onto something
same here.
and absolutely hated react or angular, happy to have dropped those 5 years back, my code is neat, clean, short and state management super simple !
Web components are fine in all the ways that don't matter... to devs who prefer convenience over all else, which it turns out is most of the devs outside Google and Firefox. We collectively deserve the timeline we live in.
Damn this is the history version of 100 seconds of Web Components, You are so under-rated mate!
"Do templates have to live inside the application logic? If so, this is a really poor decision" 10 years ago, everything was so MVC and I absolutely hated it. I just never felt that such an extreme separation was necessary unless you had different teams/members managing each part. I'm on a dev team of two, and it is much easier and faster to avoid those artificial separations.
100%
The key to all these disagreements is that the underlying language is pure dogshit to begin with. So there's no truly right answers.
It's a trade-off between structure - maintainability on the one hand, and ease and speed of development on the other. For small teams it might be advantageous to prefer the latter, but that decision is poor for a large-scale project.
@@TimL_ I know of a lot of large teams that are doing just fine with that decision.
99% of the case, separating Logic and Layout (as much as possible) is the correct way to go.
You even do that in React when you abstract most of the logic to some hook or component abstraction, and the UI to its own component. SOME overlap is good.
If you don't do that, you get those trainee-level 3000 line class components that are impossible to debug or add features to.
So "being a nazi" about MVC separation is usually rooted in having to debug that type of bundled-together code in the past.
GOAT here 💛
Appreciate you! ❤️
Salesforce uses web components massively. They have their extended version called lightning web components. I love it. Its simple and faster to build.
Agreed, the mere fact that this video claims communication is not handled well tells me the author has little to no experience with them. You can’t get more simple than passing data through properties and standard events….
@@tommy516 correct
ServiceNow uses the same for their Next UI platform. It's all web components
I have recently tried Microsoft Fast which is a web component framework. I feel like it is great for developing display components when you couple the UI web components with other framework like react for state management it really shows it benifits.
We'll check it out. Thanks for watching!
Dude, at 5:04, more than half of that code can be replace with an html template.
…which would still need to be hydrated
For me one the biggest downside of WC-as-react-alternative is the lack of tooling (nothing like Jest/Enzyme, lack of SSR). But as some here already mentioned, it was never meant for architecting entire apps. On the day to day it's not terrible, though. (Working on WC-Projects since 2020)
Web compoments are extremely useful for scoping styles where you have no control over the web page your component gets used in. I can't throw in react or anything else, friendly s technically achieve the same with their own drawbacks (resizing to fit the content) - but a native web component perfectly enables us to offer our customers what they need: components that don't conflict with their page and are developed by a third party with no access to their CMS or their code. We can pretty much distribute it similar to ads - but this tag where you want this component to render and our scripts handles the rest for you without conflicting with your page.
Yo wtf this is S-tier content. Keep doing what you're doing, this channel is ready to blow up
Ayy that means a lot. Thank you!
This video was made too eagerly, web components are amazing especially if you’re working on web assembly or any kind of native wrapper framework. They’re absolutely the future,unless we move post-browser somehow.
The first clip we showed was over a decade ago. If it's still "too early", I'm not sure when would be appropriate.
Don't have time to watch it yet, but I'll save this video for later and help out with the algorithm meanwhile 🔥
❤️❤️❤️❤️
Hey Tyler. Do you have plans do update your react course?. It was almost 2 years since it last updated. If so when will be expected release date. Thanks
Yes, but not release date right now.
No more uploads?
Did you die with the web components?
The spec is low level, like assembler to high level languages
Then again, if "61 ways to build web components" is not an indicator for their success then I don't know what is. Look up "all the ways to make a web component" article
So many ways to create web components and they all work together seamlessly and transparently. React does not even come close. It's a closed environment
I didn't know Web Components is not that popular, because that's what I do right now and I find it more attractive than the normal one.
Thanks for watching!
Amazing video, thanks!
Thank you!
While viewing this video, which only goes into V0, I inspected the tag in DEVTools. WTF? It says the tag has a #shadow-root (user-agent) and contains a whole bunch of tags I can **not** touch. So Web Components suck, but all more complex HTML5 elements are built with Web Components. Better not ever use an again if you don't want to use Web Components.
Very informative video, thanks!
So glad it was helpful!
thanks for this great video.
Glad you enjoyed it!
I hate the sentiment that custom elements are too hard to use without a framework.
The amount of frontend developers that have years of experience, but fall apart when they have to actually use standard APIs or understand issues not related to the framework they're using is astounding!
No one teaches actual frontend development, only frameworks. On the surface, this is fine. However, it creates an entire class of "frontend developers" that can't function without their framework doing it for them.
I'm not arguing that vanilla custom elements are the most developer friendly, but... It's not rocket science to use the platform or understand it.
Nothing against anyone making a living riding the React train, but it's going to die. Every framework does as the platform evolves and new tooling is created.
Really great video, thanks for this.
Amazing, love the animations!
Lit is pretty great tho.
Yeah we purposefully left out LIT and instead focused on the history.
no 😢
As a design system dev I am pretty conflicted about WC. I use Stencil to output the design system in WC and also as an Angular wrapper. The fact that Stencil has to compile framework specific wrappers pretty much shows that web components are in a weird state where they don't play along nicely with others but rather even compete with the frameworks. I don't know, it is just weird to think sometimes.
100%. I still dig the vision, just needs better execution. We tried to be objective about that in the video.
It's not that Web Components don't play nicely with frameworks -- it's that (some/most) frameworks haven't prioritized making the experience of using with Web Components as nice as their proprietary components, despite the fact that Web Components have been part of the web platform for years now.
But to be specific, other than React's refusal to acknowledge the existence of custom DOM events, and in general the poor support for type-checking custom elements in proprietary templating languages, Custom Elements are otherwise very usable without any wrappers in most frameworks (google custom-elements-everywhere for stats).
So the wrappers are really just to close the DX gap that (so far) most frameworks haven't prioritized. And it's not because they can't or that it's somehow intractably hard, it's that they'd rather just focus on their proprietary model, standards be damned. I imagine they don't see a benefit to _their framework's adoption_ to allow commodity components to more freely move in/out/between frameworks; they'd just rather you rewrite all of these components in their framework once you decide their shiny ball is the next one to move to. It's the definition of optimizing for a local maxima -- my framework vs. your framework, zero sum. If frameworks would instead really prioritize first-class support for using the platform-standard component model (at least as an option, if not as the basis), think how much reuse could happen as component sets become stable and hardened and portable wherever the winds of front-end development take us after React/Angular/Vue fade into something new.
In short, Web Components are a perfect interface for a coopera-tition model of framework evolution: interoperability at the component boundaries, innovation on the implementation details. Unfortunately, that common good has yet to be acknowledged by the existing framework juggernauts.
So don't aim that disappointment at WC, aim it at the frameworks to do better.
There's absolutely no need to wrap Web Components for Angular, as it plays quite nicely with them. What Stencil does is handy but not really necessary. You can use Web Components in Angular as they are.
haha i love the john mayer interview audio part
Such a great clip
Those final words of your narration gave me goosebumps! 👌
Thanks for watching!
A world that no longer existed? Webcomponents are just beginning to be widely adopted, if anything i think it was way ahead of its time, and yeah perhaps the implementation was too complex and most people didn't see the point in it at the time. People cared more about making SPAs quickly which is what you get with something like React.
Webcomponents were never really meant to replace frameworks, they were meant to provide a building block that others might later use to build frameworks on top of, that's what Google did, that's what Stencil does and that's what Vue and Svelte do with their custom-element wrappers. Comparing webcomponents to React is an unfair comparison, a more fair comparison would be comparing the difficulty of setting up webcomponents to setting up native reactivity using Proxies alongside your own virtual dom.
If you're building your own webcomponents from scratch and complaining it's difficult to build stuff that way you might also want to try doing reactive SPAs using only native APIs and see how hard THAT is lol
Rad video! 2 points of contention though. Flash was created by MacroMedia, which Adobe purchased. Flash was not killed by Apple's iPhone, tho Flash was grueling on battery life. THE BIG problem with Flash was that it offered ZERO SEO. All the biggest companies paid to make "interactive" Flash sites. And when their SEO disappeared, they paid top dollar again to for HTML/CSS/JQuery to compete for SEO agian. Also, Flash sites couldn't be scrolled and took ages to load. Flash was cool, but doomed all along. Much respect! Awesome work!
I really feel like there was some whitewashing of Flash at the opening (maybe purposefully at the expense of Apple). Steve Jobs was right - Flash was horrible. Fundamentally, it was existential threat to all mobile computing; (1) its was riddled with security holes, (2) it was massively inefficient and drained the battery of mobile devices (3) Adobe had no interest in supporting the touch inputs that Apple spent billions in creating that the entire mobile platforms use today. The HTML5 transition was inevitable was mobile became mainstream. Adobe tried and gave up in getting it working on ARM.
We know today, as a result of the Apple vs Epic lawsuit, that Steve Jobs wasn't being petty. Apple paid and worked with Adobe engineers to port Flash to the iPhone and iPad. After months of work the performance was awful; and only until after they tried did Steve Jobs fully reject Flash
Hard to be nuanced with subtopics in videos like this. Appreciate your comment though.
Vanilla Web components can be nice and powerful. Any complex logic can be imported with a bundler.
Lit and stencil are great for event binding, which is a pain point with vanilla custom elements.
We purposefully didn't talk about either of those and kept it more on the history. But yes, those are doing great.
2:05 the fact that he didnt made any rows completed with javascript is hilarious
My former enterprise company used web components - but they had a custom framework for managing them. Every team in the massive org would use WC + React for building different parts of the massive website, and it worked well given each team were effectively a silo.
Beyond publishing documentation of the data and events that went in and out of the component, it allowed teams to independently maintain their products without stepping on each other's toes too much. The downside is everyone was locked onto using React and the custom web component framework. If you wanted to use SSR or Vite instead of Webpack, you couldn't.
In the new company I moved to, they tackled this problem by moving to Webpack's Module Federation the moment it got released. MF apparently can work with SSR. Unfortunately I moved out before I could see it in practice.
Thanks for the great comment. What was the value in using both WC and React? I've always felt like at that point, why not just have everything in React?
Your only down side is that you don't make a lot of videos, I'm hungry for such quality content
These high quality, well written/animated/structured video are a lot of work
We're working on it! Every video takes about 60-80 hours of work. So hard to make a lot of them.
@@uidotdev Doing a phenomenal job. Cannot thank you enough.
@@drewfoster1033 Thank you!
Can you explain in layman terms what is contextual and non contextual learning which was mentioned in your site.
I never understood the hate for having css and html inside your JavaScript file. That’s how it was done on native platforms, why not with JS?
100% agree
People hate change and from my experience, developers especially hate it. Just think about all times new version of Windows came out or new big update for something came out, people don't want to update because they don't like change. Humans are creatures of habit and routine.
in Windows Forms applications the styling was in a separate designer file away from the code.
The industry has always swung back and forth between aggressively separating concerns, and tightly coupling them together. And there's always resistance on both sides. Personally I was very against it, but after using Vue single file components, and more recently, finally learning React... It's not that bad. I like CSS, and so long as what I'm writing is *actually* CSS, I don't care wear I write it...
@@billkammermeier That was only introduced later in Visual Studio 2005 and was purely to avoid conflicts with the designer tool-changing the generated code can lead to bugs and errors. It is only separated by a single method `InitializeComponent`, generated by the designer.
All the UI and logic can be co-located in the same file as it was in the earlier versions of Visual Studio.
Anaconda just came out with a new web framework, which uses web components and lets you run Python in the browser. Will be interesting to see if that helps make WC more mainstream
🧠
I wouldnt bet on it. Pyscript might be fine for python developers to grt their feet wet making apps or wrapping a program around a ui, but i dont see any profesional web developers adopting it as it serves absolutely no advantage at all to have python run in the browser. In fact, pythons block-indent syntax and poor support for lambdas make it a bad candidate even if we didnt have javascript..
Besides, what are you going to do when you need a feature node supports? Learn javascript so you can serve an app made with python?
If people want to use pyscript more power to them but if thats where we are at in 5 years im going to teach myself how to coal mine.
Python is bad
@@nomadshiba saying "Python is bad" helps no one. say why, or don't speak at all.
@@nomadshiba "python is bad ASS!" - I finished it for you, and I would never say otherwise I'm just saying things have there place.
Your videos are great!!
Thank you!
How does this compare to Razor Components from Microsoft?
Good stuff, informative and consciese
Thank you!
I've used web components since 2014 and haven't ever found the need for any javascript frameworks. The only need for things like React, Vue, or Angular, is in getting a job, because so many companies find themselves locked in they insist on existing experience with those frameworks.
"the only need is in getting a job" - that's... literally the biggest need people have.
Shopify implemented theme into their newest default theme and have to say - its very performant and easy to work with. Doubt its enough to bring them back but was a cool thing to see done well.
Is the problem that they didn’t start from the developer ux and work backwards to figure out the technicalities and principles? Instead they figured out the principles and theory that sounded good to them and didn’t prioritise what it was like to develop for?
This was really well made. Subbed
Welcome!
Nice , please where do you source those videos from
Stencil js helps overcome all those problems.I love it. It integrates well with capacitor as well.
Yeah Stencil is great.
I'd love to hear what you think about Shoelace, Font Awesome, and upcoming Web Awesome in relationship to Web Components now!
We need more of these videos ❤😢
Amazing video. Love the quality and the information. Keep em coming
Thank you!
Web components story isn't over, and to be more precise this was a misinterpreted story of web components. You might not see or use web components but they are used by some design system library
Love your content!! can you please make one about "why we need svelte"
That's on our list.
the social network is highly underated
Hard agree!
@@uidotdev Also, the john mayer sound bite
What's the original RWE quote?
Lit isn't a framework, it's a base class. Web components aren't meant to replace frameworks. Context is most important. How you choose to architect is based a lot on the scale of your project/ enterprise. There's a situation for every decision.
That's reasonable. Thanks for watching!
Interesting to see another history of javascript. What would happens if Jobs likes Flash?
One year later: Web components are everywhere! 🤣🤣😂😂
Nice Dean Kamen cameo
Dean's the 🐐
U are awesome dude
❤️
Can't agree. I think custom elements gained a lot of traction in the last year. You can build them with vue, svelte and the amazing lit library. I love them for traditional ssr projects. E.g. Drupal.
They allow easy interactivity and decoupling of FE from BE
Thanks for watching!
You just answer yourself when you said "You can build them with vue".
This video is talking about "Web Components", as in the proposed standard of bringing native component functionality to HTML outside of JS frameworks like Vue/Svelte/etc.
It's not talking about "web components", as in writing custom elements.
Writing custom elements is great, but there's no real way to do that outside of using JS frameworks. It would be nice to do that just by writing native HTML.
The "Web Components" standard discussed in this video touched on how the proposal for that never really took off.
I've been working with native web components a lot lately, and the biggest thing that frameworks like lit give you on top web components is template bindings and some reduction in boilerplate; tbh, if they made a standardised, optional vDom to use for template bindings, I wouldn't be missing much from the more fleshed out frameworks/libraries.
In interviews we are often only told to use vanilla javascript. But in the interview, when asked to build a widget for example it's a good idea to have ui components in your code. So how do you suggest we do that? Should we use native web components (which are quite complex), or build functions returning templates?
This is more a signal that interviews are broken rather than anything about Web Components. In that scenario though, I would choose to write functions with pure DOM manipulation over raw Web Components.
The solution is obviously to re-implement React.
@@dealloc Can't do that in a 45 minutes interview.
@@dealloc galaxy brain
@@DK-ox7ze Don't let time be a limiting factor. You can learn anything :)
While it was a little bit of a joke, I truly do mean that if you want to learn vanilla JS and how DOM works, to build a simple UI library.
React is quite simple if you take the basic concepts of it. Do away with JSX and dig into the API and you'll understand its simplicity.
The hard parts of React are the implementation details such as the scheduling and virtual DOM diffing.
@uidotdev ....the Emerson quote...I can't stop laughin man.
I'd really like to try using web components together with HTMX to create a single page application that lives in the backend. It seems so much simpler than dealing with frameworks.
You probably should change your title as this video is not a Story about Web Components, more of a rant about why they are not as relevant as frameworks with only surface level arguments. What I can see from your point of view is that the expectation is that Web Components replace frameworks in some way, but they never meant to do that. What they do is to plug into the DOM and have efficiently rendered behaviour snippets, one that is used for design systems and plugins. The are not meant to manage your state, they meant to display snapshots of your state. Like, there are 120+ unique components just on this site and if you look through them they either serve a particular UI, or handle a particular rendering job.
As a story, I would have expected that you present the problem in detail, the state where it started, the various evolutions of the implementations, the current state, adoption, and role. Include the fact that many frameworks you have mentioned do use Web Components as their rendering engine or have a variant that do uses it. Include a showcase where Web Components are heavily used, and where they are not. While the shown libraries are relevant, they are hardly a representation of the entire Web Component usage. The standard is adopted to all the browsers years ago and many just use the standard directly without the helper libraries you selected. It would have been a lot more insightful if you were able to find a source that measures the actual Web API usage or compare the frameworks' variants to showcase your point.
I feel like you wanted to tell a story, failed to understand the original situation and the problem, mid-way decided to start comparing apples with oranges then choose examples that support your view and draw conclusions and declare one framework in particular as a winner of some sort of competition.
I love this videos
Thank you!
Keep making these, high quality content, would love for some technical content
Thank you!
Had no idea web components didn’t “pave a cow path”, but that makes so much sense with this historical context.
This is a much watch channel for anyone seeking to better understand the history of the web, needed to understand where it’s at today
❤️
Why not support HTML import?
Yeah....but what about Salesforce lwcs?
1:05... AHEM. That was Macromedia. Or if you really want go get specific, Jonathan Gay, the same dude that make the 80's game Dark Castle for the Mac. Flash was already dominant before Adobe acquired it.
We love getting specific, but not on points like that :) Thanks for the correction.
Flash was created by Macromedia, then accquired by Adobe in 2008, if I'm not mistake.
Yeah that was our mistake
Salesforce LWC OSS is build upon web Components and is very lightweight and easy to implement.
I don't see the issue with data flow. Why not just put the state in window. You just need an object and there you are.
It is worth mentioning how bad flash was though, proprietary and full of vulnerabilities and really didn't perform well on mobile devices.
I definitely feel that web components has use as framework-agnostic drop-in components.
Plus, they are so nicely integrated in the browser. If I'm building regular (non-SPA) websites and need some bits of dynamic functionality, it seems like a nice fit. So to me they are a good companion to things like React and don't directly compete.
That's reasonable. I've always felt that at that point, I don't see much value in using a WC if you can just use a react component. But admittedly React support for WCs has been terrible until recently.
@@uidotdev Perhaps you're a developer of a payment gateway, and want to offer a great credit card field component =).
I'm primary a developer of libraries for other devs. WC would definitely make the top of my list when I need to author an ui component, just like I'd prefer fetch over axios; the former is (now! finally!) universal/dependency free/opinionated even if it doesn't offer the same features as Axios.
I find that generally my libraries reduce their dependencies over time as the web/node platform improves.
But, if I were working on a single application that's not a dependency for many others, and the decision was already made to do a fat client/SPA, I also don't see a reason to build something with WC instead of React/Angular/whatever.
This! My take on WC is that its biggest fault was its marketing. Having worked on a component library for a +10k employee company, WC was a saving grace for it being a browser-standard rather than a runtime library. This made it possible that we were able to support every single website with the company.
I heard comments were being deleted.
Nope. Comments actually help us. Regardless of if they agree or disagree with us.
@@uidotdev well, mine is gone...
@@DannyMoerkerke We get accused of this every video, regardless of how controversial or tame the topic is. I'm not sure what you said, but I promise we didn't delete it. Proof is that there are plenty of comments telling us how stupid we are - which is fine.
Don't see mine anywhere, so yeah.
@@jaredwhite88 You're essential calling us liars, and that's fine. But I promise on my brand new baby daughter who is 3 weeks old, we're not deleting comments. I'm not sure what else to say. I couldn't care less if you love WCs and think we're stupid. If you look at the comments, I've only complimented others who have had opposing views.
React was created by awful engineers who couldn't figure out how to properly apply the MVC design pattern.
Wild this is still an argument in 2022.
Yeah, and now people are learning to love Web Components because they can be used regardless of the ui framework you use.
Flash wasn't created by Adobe but by Macromedia
Web component still solves a big issue for companies that want all their applications to be build with consistent stylings/branding and prevent devs from doing duplicate works in different teams.
In those cases they can make a central SDK team that make common components and services and ship them to application teams as web components. Using web components, application teams are not restricted to Web frameworks used by SDK.
For instance the SDK team can develop all there components using say svelte and ship this wrapped in a web component to any team regardless of the framework that team uses.
Application team hence can completely focus on fetching data and control flows rather than remaking dashboards, grids, accordions
Your missing the point of Web Components....
They weren't designed as a replacement for the frameworks....
They are supposed to be used as framework agnostic components...
Regarding authoring, just use a cloned template and slot it... e.g.
static template ( ){
let temp = document.createElement('template');
temp.innerHTML = `My Component`
return temp
}()
connectedCallback(){
let temp = myCustom.template.cloneNode(true)
let frag = this.slot(temp.content)
this.appendChild(frag);
}
BTW you don't need ShadowDOM...
The real question should be why are frameworks garbage?
The only framework that is even remotely performant is SolidJS.
And why do they keep changing and adding junk code and complexity every year?
On a side note TypeScript is for the most part just a clone of ActionScript (Flash).
The real problem with Flash was too many insecure bloated library's....
It looks like history is repeating itself...
Steve Jobs probably would have tried to kill the frameworks like Google has tried...
This video has definitely given me something to think about though so thanks for the great content 😀
Thank you for the great comment as well and for watching, though you disagree. ❤️
I was doing react in 2017..... i never realized how early I was...
Flash was created by Macromedia, then Adobe acquired it
Pedantic, but fair.
So Steve jobs is the reason for all of these modern JS frameworks 😮
What if we start with a more simple (in theory?) approach: Have a way for HTML to natively import other HTML from separate files, similarly to how we can already import CSS & JS via & tags respectively. Could be a new tag that functions something like this:
**
Consider this example:
I want to make a very simple static website. It has 5 pages. Using a JS framework would be total overkill, so I'll just write it using native HTML/CSS/JS.
I create a header component with a navigation menu containing links to all the pages on my website. This component has some CSS and maybe some JS to accommodate its functionality.
Now I want to add this header component to all of my pages. I need to manually copy/paste the HTML that makes up this component 4 other times for the 4 other pages.
Later, I decide I want to make some minor changes to the layout of the menu. Now I need to copy/paste those changes in every page again. This workflow just sucks, plain & simple.
Part of the reason why I & others use JS frameworks is the convenience of writing a commonly shared component that can be easily added anywhere on any page, and easily modifiable from a single source.
If there were a way to do _just this one thing_ alone natively by just importing one HTML file from another HTML file, that would be a massive improvement to developing websites natively as a whole. It should even have the benefit of being semantically meaningful as well. Web crawlers/search engines/screen readers/etc. should be able to navigate through the internally linked HTML from the tag that imports it & understand what it conveys, whereas dynamically rendering HTML using JS doesn't have that same benefit.
🔥🔥🔥
❤️
If you check micro frontend, you will notice it behaves like web components, irregardless of which js framework
Micro front-end results in a horrible mess of code for a developer and a bad experience for the user. Use one framework not multiple as the cost to maintain multiple isn’t worth it for a business and the end user doesn’t need that much code shipped to the client.
@@A.D.G it's not for everyone, dont tell me it doesnt have any use-case
Angular>react
Both are fine
@@uidotdev would you consider doing one one the transition of angularjs to angular that was a pretty big event and pushed a lot to use react and the current state of angular.
svelte > frameworks
use svelte make the web fast again
Flash was created by macromedia then acquired by Adobe.
So we've heard. Our bad.
GOAT
❤️
Hmm, it's not totally clear what is considered difficult about using WC?
is it no JSX or is it the lack of default data binding?
My understanding is that you can simply add other libraries to support that functionality or use a WC-framework that offers default helper functions for that
Right. And if I want to grab another lib, I'll grab React (or something similar).
@@uidotdev ya. I have to admit, I really have no clue why WC are being compared with libraries.
WC are just primitives. Aka a competitor to divs