I recently migrated a browser extension from React to web components. This post describes my observations, learnings and pain points. Anything ment...
For further actions, you may consider blocking this person and/or reporting abuse
Vanilla will always be the web standard, jQuery for example was a guide to JavaScript maturity.Just as axios is for fetch, the tendency is always for some library or framework to be swapped for the native.
I hope more and more people will see that.
Having coded for IE6 "back in the day" and watched the slow-but-inevitable rise of jQuery, I think there are three reasons. First, browser implementation is always just a little different. We're spoiled now that almost all major browsers run on Blink or WebKit, but Gecko can still be temperamental at times. Using a community supported library means it is battle tested against all popular engines and a good library will "just work". Second, the best features are always almost ready. Even as HTML5 was being standardized, it took so long the standard itself was forked. Libraries have the benefit of being able to shim the best features and remove the shims when native support is widely available. Third, knowing and using the DOM API is almost always necessary for native features, and that is in and of itself a pain point still.
Native solutions should always be the goal. But libraries are part of the natural evolution of features that developers actually want to use.
Knowing and using the native DOM APIs are a necessary "pain". I see people all the time jumping on the React/Vue etc. bandwagon without learning the basics of how browsers work and how to manipulate the DOM. The DOM APIs are not some sort of low-level machine code. They're highly abstracted and usable. Yes, they can be verbose and yes they can be confusing sometimes but learning them is way easier than grasping how React/Vue work.
I wrote about the topic a while ago because I see the issue happening all the time. maroun-baydoun.com/blog/dont-start...
I think they can replace them in a technical sense. I don’t think we’ll see mass migration, refactoring budgets, or dev knowledge growth in that area, without something big happening. Oh the “vanilla framework” is in the hype cycle. And there are future promises hanging out there like react seamlessly solving the pain points around SSR combined with CSR.
Respectfully, I think your outlook might be coloured too much by social media.
Web components adoption, as measured in code running on page loads in browsers, is rising steadily.
arewebcomponentsathingyet.com/
Wow really great article, it makes a lot of sense for you since you are working on a plugin and the support is a little bit more open than for who want to use web components for web development. Thanks to your article now I'm thinking about it, I love vanilla Js and I prefer it, in my opinion at the end it depends, but when I can vanilla is the way to go, with web components mmm would be amazing more support for other browsers
That's true, browser support could be a concern for traditional web applications and websites that need to target a wider array of browsers and users. The browser support is not bad overall however. There is definitely a case for using web components in production with polyfills if needed.
Take a look at Svelte.
You can't avoid this, frameworks will always exist. React for example is more powerful then web-components.
It only took me 5 years...
hi, I've developed a library and set if widgets, so you can have bindings, di and extensibility with web components
npmjs.com/package/skinny-widgets
That's true, they'll always exist. It doesn't mean, however, that they should be used in every codebase.