|
|
|
|
|
|
by zarzz
2629 days ago
|
|
|
The reality of Web Components is that it was never intend to take share away from the large frameworks. Instead Web Components is intended to fill the middle ground between a simple web page and a full blown web application. There is a real need for web page developers to be able to just drop in a prebuilt web component and go without having to reach for the 10,000 pound gorilla of frameworks. That’s where Web Components can have real value, real benefit. Is Web Components flawless, hardly. While the APIs are accepted standards and implemented in most browsers there are still a few holdouts, and to be sure there are still edges to iron out. No technology is without it warts, its awkward teen years. But Web Components is maturing and the tooling around it is maturing as well and Web Components most definitely has a place and is most definitely here to stay. Also it is worth keeping in mind that the Web Component APIs are specifically written as low level APIs and intend to be built upon by libraries and frameworks to simplify and aid the process. Libraries like the one I am currently pitching, ZephJS [1], which aims at making writing and distributing web components mind numbingly simple to do. ZephJS is a perfect example of the new generation of Web Component libraries to facilitate answering the need I espouse above: the middle ground between basic and beast that so many web developers live in. [1] Introducing ZephJS: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3... |
|
|
Exactly. More specifically, it was created in response to the years-long hiatus in development of the HTML spec, when we were still waiting for a date picker element (heck, we still are!).
With Web Components, we might all use the same widely supported and actively maintained emoji picker regardless of the framework we're using. But they do not solve the problems that framework solves.