In my previous blog post about Web Components, I described several challenging problems still unsolved as of today. The feedback I received was sur...
For further actions, you may consider blocking this person and/or reporting abuse
I tried to use Web Components on my most recent project and failed miserably. Legacy systems was probably the biggest thing holding me back, as I had to support IE11 and not all component libraries were able to provide that support through polyfills, so I sat there confused, trying to figure out the differences between a dozen libraries I had never heard of, and attempting to do some tutorials with each to get a feel for what would work out well.
I was really interested in Svelte, but I haven't ever used Typescript before and that became enough of an issue that I had to choose something else. The site I was making the components for is built off of ASP.NET Web Forms, so it was really difficult to bootstrap data into the pages and I couldn't figure out a reliable build system for my components. I gave up and went back to the site's default jQuery approach because I couldn't waste any more time pllaying around with things. If I had to do it again, I would probably just use Vue with multiple roots instantiated on the page.
At my next job, I won't be stuck with as many legacy systems, but I will be switching to a mainly-backend role and won't have much sway with the front-end team, who is all about React. I see value in Web Components, but I don't have enough experience to validate any of my points. I wasn't able to make any production-grade examples which demonstrated the value of Web Components, in fact, I wasted hours and hours frustrating the hell out of myself.
There were too many options available and I felt overwhelmed. Most of the options provide poor documentation, or none at all. There didn't seem to be a solid community I could rely on if I had questions and overall I got a sense that there wasn't a lot of knowledge to be passed around. I have some time off until my new job begins and I considered looking into Web Components during this time, but it was such a frustrating experience I don't want to re-approach the issue. I think I might learn Haxe or ReasonML instead.
Thanks for the feedback! As I mentioned, the lack of documentation and best practices is the key, and might become a blocker for many teams. That's why I have started working on "Web Components the Right Way" project.
Svelte and probably other similar "disappearing frameworks" might get attraction once they stabilise and provide clear documentation and smooth developer experience. The popularity which Vue gained is a great illustration.
Hopefully React will gradually update its internals (at least the project announced as "React Fire" sounds promising) to be more compatible with usage of native DOM APIs, but I don't have enough context to make any statements on that.
That's a noble effort. I'm curious about your project, it sounds really cool. Is there anything I could help out with? I'd really love to learn how to do this right and I can see it being something to advocate for at my new job. I will mostly doing backend so it would be cool to have a connection to FE still.
Thanks for the feedback! At the moment, the list contains a bunch of links to specs, various articles and tutorials, etc. Feel free to hare any feedback on the structure, order of sections or anything that would help to make it more clear and easy to use by newcomers.
Hi, Scott!
Could you please describe a little bit how exactly Typescript was affected you to use Svelte? Actually, Svelte doesn't support Typescript at all for now.
My bad, I meant to say Stencil. Trying to get a grasp on the concepts behind web components takes a lot of brain cycles for me right now...they make total sense to me and a componentized architecture with communication visa a message bus is how I have been designing Javascript for years. So I understand what they are supposed to accomplish and it excites me, but I have a very informal definition of building components over the years vs doing it in a standardized way. Hand coding components just takes a really long time, so I felt like I would be wasting time if I didn't go with one of these support libraries. Typescript was just one thing more to have to remember on top of everything else, it was information overload and I was super-stressed out already.
I also think it might have been a much better ending to the story if I wasn't working with an ASP.NET Web Forms-based CMS. There is 0 info out there on getting Webpack set up in Web Forms, and it is something I struggle to do in a modern environment already. This project was the breaking point where I realized there was so much technical debt in this company's website that making any productive, major changes was going to be near impossible. It was built by an "expert" agency before I was hired and it was some of the worst code I have ever seen, so glad they "accepted my resignation early" and let me go.
I'd be curious to see them work out on a project I don't actively dread working on.
Oh, I see, everything fell into place. So, I definitely advise you to try Svelte. It has pure and neat syntax and a bunch of built-in features under the hood. Shows us great benchmarks metrics and can be compiled as native Web Component by setting a single flag in compiler options. Check out this video for a quick overview: youtube.com/watch?v=Gne762oc7s4
Try hyperapp. Its a 1kb alternative to vue.
I'm proud to be able to say that Aurelia has been leveraging the WebComponents HTMLTemplateElement, ShadowDOM, and Slot capabilities since the framework was conceived in late 2014. We've worked really hard to leverage standards and then augment them with the pieces needed to create more complex applications. We're not as well-known or as large as something like React, but we've still got tens of thousands of companies building with Aurelia who are very happy with our approach to adopting standards in this way. Just a couple of weeks ago, we introduced a plugin that enables our components to be exported as WC Custom Elements, with no additional work by Aurelia developers. We're carrying this work forward with our next major framework version, leaning even more on these and emerging standards and making them even easier for people to leverage.
Thank you Serhii for the honest and balanced look at Web Components. Speaking for my team, I can say that we're very happy to see that more real use cases are being discussed and that there's action around several of the most critical long-standing issues. If I or anyone from my team can be of service in helping to advance this work, please don't hesitate to reach out.
These posts are awesome, please keep them coming.
Is love to hear more from you on why you think
<app-router>was a mistake. I really enjoyed using it back then, and I've often heard how the concept was "wrong", but I'm still curious why it is considered such a harmful pattern.Nowadays I do my routing in callback methods in
<my-app>type elements, or I use a data framework like Apollo.The problem as I see it lies in choosing improper abstraction.
There is no need for such components to be in the DOM, and to query from the DOM just because we consider HTML as the only way of writing declarative code in the applications we build.
I still think that DOM should only contain the "view" layer, whereas router is better to have as JS library not necessarily tightly coupled with web components.
Thanks for the explanation. Do you think that having that model code in the DOM was error prone or insecure, or is it strictly a matter of separation of concerns?
I think both statements are valid to some extent.
Storing data (especially, when it comes to application state) in DOM is one problem, attempting to use DOM for meta programming is a different one.
Interestingly, trying to solve the first problem could sometimes result in leaning towards the second one, as we can see it when looking at github.com/google/uniflow-polymer
In my opinion, all these problems have been implied by the two way data binding system and how it affected the way of thinking of Polymer users.
I hold a lot of hope for Web Components, and right now I am in the process of aligning a massive platform front-end refactor; so far I cannot outweigh the risks (functionality and performance blockers and knowledge among devs) with the benefits of using Vue.js.
With that said, trying to align with a Web Component approach is still highly desirable. For us, the "tipping point" of community support and shared knowledge with a solid, single direction would allow us to adopt this tech. So, we won't be rendering an all-containing
<my-app>, we will have many roots instead. We also considered the approach noted here, allowing a path to migrating away from Vue.js in the future, as WCs mature - but as you can see from those docs, IE11 is not supported. This is a deal-breaker for us, as are accessibility shortcomings, so the benefits of adoption get watered down more.In the long term, our team will look to align as closely as we can to properly composable concepts with HTML because it feels right. We hope in the future to adopt a WC standard and approach to not only individual components, but also collections of those components, right up to whole page layout level (we follow atomic design principles, for example, and I can foresee WCs being a solution for all levels of it).
In the short term however, battling through adoption blockers and issues would strain our resourcing and probably introduce issue for end users; both of those things affect our business bottom line, so we must play it "safe".
Thanks for the feedback! I like your idea about how the atomic design principles might work with Web Components.
It's unfortunate that IE11 is still a blocker for many projects. Hopefully, Chromium-based Edge delivered to Windows 7 and 8 will help to slightly reduce IE11 usage under 5% where it still stays. Until then, there are polyfills, but using them results in not so graceful degradation as we'd want it to be.
Just came across your post and i am very into the whole Web Component topic. I am currently writing my Master Thesis about a "Declarative Shadow Root" solution to provide HTML authors with the same encapsulation features JS developers have with Web Components. Do you have an opinion on that topic as well?
We have recently started a POC for using LitElement for our huge enterprise Web app. One problem, I am facing initially tooling wise is Chrome Dev tool's inability to alter CSS within shadow Root on the fly.
Its really helpful to be able to experiment with CSS right in the browser, with Web Components that flexibility seems to be taken away which I think is a bummer. And this one for a change does not require browser consensus :)
There is an issue to fix that already so I hope it would be resolved in future:
bugs.chromium.org/p/chromium/issue...
In the meanwhile, you can workaround that using
delete Document.prototype.adoptedStyleSheets.When called prior to loading LitElement, this will make it act like the feature does not exist and place style elements into the shadowRoot (same as Firefox and Safari).
It's a great post. I enjoy reading it especially the slot proposal. BTW, I spotted a typo in the
What's Nextsection:event start->even start.Thanks a lot! Thanks, fixed the typo.