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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.