"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 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.
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.
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 RU-vid 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.
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.
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.
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.
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.
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.
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.
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
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….
"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.
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)
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.
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.
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.
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
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.
If you look at any tech on the web right now and feel like that is a "win", you're lost. Everyone is a loser in that space. Being able to write tool-less and dependency-free components trivially would be a godsend. We're now closer than ever and until we're there, we've migrated from React v47 to Angular v21 just to be able to finally resolve all the issues with the build tooling or testing or whatever.
I find it a joke that most web development starts with "Ok install NPM- no no the right version of NPM...ok now install this one lightweight super easy 1.5GB javascript framework that'll be abandoned in 5 years after having its core syntax change 8 times...ok now you can type hello world in 2 lines of code!"
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.
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.
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.
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?
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.
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
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
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.
I believe the design of Web Components is so raw for a purpose, considering that you can create anything from a simple tag like p or as complex as canva. It's more of a Blueprint than a Framework. It doesn't seem to me to be the solution to all problems (as a Framework proposes) but just one of several Web Standards that works together with the ecosystem. It's just another tool for the box... the problem is that this tool depends on the collaboration of all browsers to work and a community interested in using it.
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.
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?
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.
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
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.
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.
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.
@@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.
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.
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 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.
This video is kinda misleading, if not a a bit too sensationalized? Web component's aren't dead, obsolete, nor are they really trying to occupy the same space as the big JS frameworks. In the scope of their history, I feel like the video really missed the mark in covering just that.
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
