The Web Components spec was written before React and Vue were very mature, and it unfortunately shows. Web Components might offer a better primitive for higher level frameworks to build on, but I would not suggest to anyone to use barebones Web Components over React or Vue.
It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that direction... I expect React will be the last to adopt them, or they’ll push for spec changes before they do...
open-wc is also worth a mention: https://dev.to/thepassle/announcing-open-web-components-5h7 - their guide and setup for using web components is over here: https://open-wc.org/guide/#quickstart
You can also technically start using native es modules in browsers, either localhost in Chrome 74+ or via origin whitelist with Google. Or use a polyfill such as Guy Bedford’s https://github.com/systemjs/systemjs/blob/master/docs/import... or https://github.com/guybedford/es-module-shims — but you’ll have to consider solutions for custom syntax, scss or non-es module dependencies. I personally think there’s a gap in the npm ecosystem which is building “source packages” that are native single-file es modules you can easily import or compile from with a native JS module system...
Web Components are great for reusable components like date pickers that you might want to re-use regardless of framework. If they're just the technology backing the implementation of some framework, than that framework is only worth switching to if it provides something fundamentally better than the framework you and many others already know, because the mere fact that it's built on Web Components no longer provides a significant advantage...
So you can use, for example this set of components with a react application and get some of the best of both worlds. The only down side is attributes in web components aren't passable via the markup, only via DOM reference.
I happen to like react as-is, but Vue is probably much closer to web components and could see Vue becoming a compile to web components option sooner than later.
There's no requirement that you use web components without helper libraries. That was never their intent.
No one remembers what the intent was. Just two years ago the whole narrative from the proponents of web components was “the future is here, no need for frameworks, get rid of your reacts and angulars and... and...”
But then people actually tried using them.
So, curiously, the narrative quickly shifted to “oh, these are just primitive APIs never intended for direct use, and only intended for library and framework authors”.
Curiously, at the same time the narrative usually keeps going “react is crap, you should drop it in favor of web components”.
A nice recap from Dan Abramov: https://dev.to/dan_abramov/comment/6kh1 and more in the discussion here: https://dev.to/ben/why-the-react-community-is-missing-the-po...
And we are in yhe comments to an article that literally argues that Web Components will replace frameworks. While half of the people in the comments say “yeah, the intent is for them to be used only by library and framework authors”.
There’s a certain hint of schizophrenia in how Web Components are described by their proponents.
Still would be too low level to easily work with though without a framework like React.
> [Frameworks like Angular and React] have enabled us to do what we always wanted but never were able to: creating reusable autonomous frontend components
That's not what we always wanted to do, and not why people are using these frameworks. How often do you re-use your Angular and React application?
I think the problem with the article is that it is just looking at components (as a developer I have wanted the encapsulation this methodology brings), whereas react offers more than that - the virtual DOM, for example.
A lot, our Angular components are re-usable across projects.
Apparently at least some people choose frameworks because they want that.
Yes, If there was a native standard for watching and manipulating state then frontend frameworks would be largely unnecessary.
Updating is not declarative.
What does that mean? The methods provided by the web components spec appear declarative as do the methods provided by the DOM spec. Declarative example with nothing like innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/att...
Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic.
* DOM - https://prettydiff.com/2/guide/unrelated_dom.xhtml
* state - https://en.m.wikipedia.org/wiki/State_(computer_science)
* stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_...
One of the bizarre realities with those forced to write their own "virtual DOM" library, as I have done, is to deal with all the so-called hidden state. Form field values, the user's current text selection, scrolling position. Without a virtual DOM, simply replacing existing nodes with innerHTML or replaceChild will stomp this away. I'm not of the opinion that you need a full framework to handle this state (I wrote my own 10-line helper function which works in most cases I care about [0]), but you do need something more structured than just replacing nodes wholesale.
[0] https://github.com/magcius/noclip.website/blob/master/src/ui...
It seems you wrote this article; have you read it back? You bury the lede under 1230 words explaining some social concepts rather than anything programming-related.
Additionally, you use many complex words to describe simple subjects. And you do this knowingly: for example, you felt the need to link the definition of "acquiescence" to the word. If you felt that it was complex enough that this was warranted, why not instead rewrite the surrounding content?
If the purpose of this article is to convince people that disagree with your statements, you have certainly lost those people by the end of the article.
I don't even disagree with you; the DOM is great and WASM is definitely just another option and not a replacement for JS.
Finally, I have to note: there aren't any citations for your claims in the programming section. One might otherwise wonder where you get an idea like
> That DOM mechanism will allow a WASM application to execute DOM methods without having to provide its own DOM application, but it will be limited to markup within the WASM application.
when I haven't been able to find anything indicating this elsewhere on the web.
This article claims Web Components could replace frontend frameworks. React is a component library often used in a frontend framework.
React wraps the DOM with a Virtual DOM that provides a declarative abstraction for stateless updates. That is, you can write a plain function - given data X, produce DOM state Y - and React works out all the DOM calls required to arrive at the desired DOM tree from the current actual DOM tree.
So, with React, a developer does not need to make granular element-by-element, attribute-by-attribute changes. Many developers have found that leaving this diff / patch work up to the computer is easier than working out all the DOM calls themselves. Even more so than the concept of components, this has enabled architectures that many developers find pleasing.
Now, you can call that stupid or delusional if you like, but at least understand what's being referenced here.
The DOM is not all that challenging. It can be a tedious API, though. React shifts much of the effort to manage element and attribute changes to an algorithm, thus relieving tedium. Many folks find managing the DOM through a functional paradigm to be an enjoyable & productive approach to working with client side web apps.
Yeah, I very much doubt that.
Web Components is basically a suite of browser technologies. It's actually particularly heavy and I kind of hope it doesn't catch on personally, since it pushes so much to already giant monolithic web browsers.
Frameworks and libraries like React and Angular are tools for developing applications first and foremost. The actual technologies they're backed by doesn't matter, but if you can't reimplement either of them using WebComponents it should probably tell you something about WebComponents:
- It's very opinionated about a lot of things.
- It disagrees with many of the (much more popular) frontend frameworks far too much.
React does a whole lot of things right, and it does them right in a relatively small package with a relatively small API surface, and you can extract the essence into even smaller libraries. With functional components, you can even build React components that have almost no React in them at all, other than JSX.
I don't think we need new complicated technologies to solve the kinds of problems React solves. If anything, we need less, like an alternative to the current DOM model.
Most of the innovations in the frontend world don't seem like they can be cleanly applied to Web Components, or even layered on top of it. And if we want to update it down the road to a new major version, we have to wait for every major browser vendor to have a stable implementation and iron out edge cases/differences. That's not a good bet at all based on how it went with Web Components the first time.
In other words, No Thanks, I'll take my framework.
They're also pretty unopinionated. They only let you define an HTML element and hook it's lifecycle. They let you know where to render (the element instance and it's shadow root), and when to do things (lifecycle). The rest is up to developers, and there are lots of helper libraries with different opinions on how to implement a full element.
I think you'll find that some of them, like lit-html, LitElement, and Haunted, have very similar ergonomics and models to React. And much better performance and bundle sizes.
This is a weird misnomer to me. Stuff that's provided by the browser is not magically faster or better. Further, native browser functionality can slow down applications just by existing, like for example Mutation Events (which were removed in favor of Mutation Observers.)
In that sense I really dislike what functionality is being loaded onto HTML elements, effectively the lowest level primitive of web apps.
>They're also pretty unopinionated. They only let you define an HTML element and hook it's lifecycle.
In itself, there's not a whole lot wrong with this... But as fate would have it, the idea that HTML elements themselves should be components is an opinion hotly debated. In Angular 2, you have both directives, AND components that are selected from attributes. In React, the component tree is a fully separate entity from the DOM tree, and components don't even appear in the DOM.
To me these are not small details that can be reconciled. Part of what makes React ergonomically nice is that it can generate a nice, clean DOM free of component cruft and scoped CSS or whatever.
>And much better performance and bundle sizes.
Modern JS app performance is just not that simple. We've got server side rendering with hydration, scheduling rendering asynchronously for better responsiveness, bundle splitting, etc. Simply saying "WebComponents are better because they're faster" means little to me. Is my app bottlenecking on React? Often it's really not.
And if React's ~100kb is really killing you, there's plenty of libraries that implement just the basics in much less. Preact is quite good.
I understand that you're the author of lit-html - would you say that the above is the main selling point of it?
Huh? It's a very small API built _into_ the web browser. What's heavy about it? It's kinda similar to how JSX works just with less bells and whistles, more standard web stuff.
> It disagrees with many of the (much more popular) frontend frameworks far too much.
Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I think it enables them to have wider access to developers.
Being built into the browser doesn't make it lightweight.
I mean, if you look in terms of functions that WebComponents adds, it's a relatively small API surface. However those APIs encompass an awful lot of different functions that imo bloat basic concepts by introducing complexity into HTML elements and the DOM.
>Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I think it enables them to have wider access to developers.
I'm very much not holding my breath for that. I do think interoperabilility with WebComponents is a definite future, but thats it.
React fundamentally disagrees about what a component is. At the most basic level, React components are not DOM components, their entire DOM representation is what they render. This is not something that can be reconciled.
However should React let you export a component as a "WebComponent," via custom elements, sure, that's fine. Interoperabilility is not really notable though. It's also possible to interop React with Angular, Angular 2 with Angular 1, etc etc. Many of those are done today. In big apps. In production.
Edit: Reacts take here. https://reactjs.org/docs/web-components.html
>React and Web Components are built to solve different problems
Could not agree more, and that is precisely why no, WebComponents are not replacing my JS frameworks.
It seems to me as if you're saying:
"We don't need new complicated technologies."
"Also, we need a new, complicated replacement to the time-tested DOM."
This probably wasn't the intent but it exposes the need for web components to be built the way they are: progressively enhanced from what's already standardized in browsers. Web components really aren't that complex, and comparing them to React in this way is a disservice.
display: block;
display: inline;
display: run-in;
display: flow;
display: flow-root;
display: table;
display: flex;
display: grid;
display: ruby;
display: block flow;
display: inline table;
display: flex run-in;
display: list-item;
display: list-item block;
display: list-item inline;
display: list-item flow;
display: list-item flow-root;
display: list-item block flow;
display: list-item block flow-root;
display: flow list-item block;
display: table-row-group;
display: table-header-group;
display: table-footer-group;
display: table-row;
display: table-cell;
display: table-column-group;
display: table-column;
display: table-caption;
display: ruby-base;
display: ruby-text;
display: ruby-base-container;
display: ruby-text-container;
display: contents;
display: none;
display: inline-block;
display: inline-table;
display: inline-flex;
display: inline-grid;
React 16.6.0 base library, minified: 6.21 kb
React 16.6.0 DOM integration, minified: 100.39 kb
Isn't web components the standard, and react is the complicated technology?
I think part of the reason why the DOM and layout engines are so slow and complicated is just because of years of cruft and whatnot. A minimal layout engine with most the abilities of Flex and Grid would be nice.
Frankly, this has been transformational for our project and for our business. I'm completely sold.
One problem with the WC debate is people constantly compare the raw Web Component collection of APIs to a framework, when in reality, you'll add in libraries or extras on top of your Web Components to get similar functionality (like Stencil: http://stenciljs.com/), but you'll likely not build apps with them as much as you'll build components to share with others.
In that sense, the killer app for Web Components is actually Design Systems, not SPAs.
I disagree with the idea that Web Components replace your framework, however. They solve different problems! For Ionic as a cross-platform Design System, they are a major asset.
My read too
This isn't true at all, and it's a big misperception about web components.
Web components are pretty low level APIs that expose a few abilities that the browser natively has: defining a tag name, hooking into element lifecycles, creating an encapsulate DOM subtree.
Web commonness have no opinion on rendering, state management, etc. and leave other aspects, like responding to property changes, to existing features like JavaScript accessors.
It's expected that developers will use libraries to help implement web components, but the libraries won't have to implement a component model, or DOM composition, or CSS scoping. So they'll be smaller and more focused, and the overall product will be faster have fewer proprietary parts.
Would it make sense for React to start using this native web-component at some level moving forward, to improve efficiency ? Maybe another library will replicate most of Reacts features but is powered by this native (faster/cleaner) technology?
React is mostly about life cycles, propagation, and composition. The first two are orthogonal to web components afaik. The third has some overlap, but it’s mostly complementary with web components (once again, afaik.)
Also, don't understand your padding comment. Web Components are style-able.
As the maintainer, you don't want to cave in and add every possible configuration option people ask for so you have to decide what's a good, thin API for your component and it will never be enough for some usages. Styles are that much more subjective and even vary with design trends over the years!
It might be possible for very, very simple components like text inputs but then again, those are also the simplest to code directly in your framework, so you could wonder, why bother with an inferior programming paradigm in the first place?
The sweet spot for web components really seems tiny.
Also, ZephJS, the Web Components library I am championing, has the ability to inherit from another ZephJS element which allows one to add to or even completely replace the styles for the new element without any special css magic. So if I want to style <acme-text-field> I simply inherit from it in my new <my-text-field> and I can style however I want.
https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...
It would be so nice to just write:
<include src="footer.html">
Building complex websites would become so much nicer. Because each part of a page would be an include.
<link rel="import" href="/path/to/file.html">
But alas, Google was not able to convince other browser vendors to adopt them, and they will be removed from Chrome 75.
But, if you use Web Components, organize your code, and plan ahead, this is very doable today with Web Components. You just create say a <reddit-footer> component complete with style and behavior, and then drop that into your page html along with an import of the component definition. It’s clean and simple and the encapsulation of all your footer needs in one place is really nice.
ZephJS, the library I am promoting, or another Web Component engine, makes this even easier and allows your components to be bundle yup really nicely. ZephJS, for example, offers a cli bundler command that does this (via rollup) and it makes for a really clean component experience. https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...
B
It’s clean and simple
On the other hand new JS modules work like that, this is less of a problem on http2 and also can be mitigated by tooling.
So what can Web-components offer over that? A simpler way of including them on a page with a single tag. Well, you must load the js-file too but a single js-file could contain multiple web-components I assume.
The whole (?) point of components is isolating the interface from implementation, encapsulation, which WebComponents does nicely by providing a standard way of writing methods of the underlying ES6 class.
We could say that WebComponents are smarter IFrames with a cleaner way to declare their interface.
Another great thing about WebComponents is extending existing tags which makes it easy to prototype improvements to existing tags. For instance I wonder if IFrame could be made better by creating a web-component that extends them?
But yet, here's Polymer 3:
static get template() {
return html`
<style>
.response { margin-top: 10px; }
</style>
<paper-checkbox checked="{{liked}}">I like web components.</paper-checkbox>
<div hidden$="[[!liked]]" class="response">Web components like you, too.</div>
`;
}
return html`
<h1>${this.format(this.title)}</h1>
<div
class="dot"
style=${`left: ${this.bar.x}px; top: ${this.bar.y}`}
title=${this.bar.title}
></div>
`;
const el = /** @type {TitleBar} */ (document.querySelector('title-bar'));
const el: TitleBar = document.querySelector('title-bar');
[1] https://lit-element.polymer-project.org/guide/start#use-lite...
Introduction: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...
Bundling specifically: https://github.com/awesomeeng/zephjs/blob/master/docs/Compon...
LitElement is able to focus on providing the best base class to build a Web Component. I think it is almost there.
The alpha is at https://app.kanrails.com/signup. Again, it's in alpha. It is essentially a Trello + Google Forms + Workflow wannable.
How? Stick to patterns, not libraries. Check out https://pwa-starter-kit.polymer-project.org/ for LitElement starter kits. And just use Webpack, rip out the Polymer CLI. Oh, I also use Redux.
1) I use Webpack to bundle, still practically indispensable.
2) Redux state management. I use Redux-ORM to denormalize data but it has its own quirks.
3) Shadow DOM is on by default (both a curse and a great thing), which can be a problem with styling because your global CSS can't penetrate everywhere. What I do is have lots of CSS utils files (ala TailwindCSS), and import the utils as I need on demand. Drawback: Browser is parsing a lot more CSS than it needs to, as each component imports it's own CSS utils. Happy to hear about other approaches, but the browser really didn't break a sweat.
4) With Shadow DOM, you can use <slot></slot> to compose components.
5) Routing, see the starter kit for patterns, essentially it's a router pattern, not a router library.
6) DOM event bubbling is very useful (CustomEvent), I even threw in a small Pub/Sub library somewhere for sibling communication
7) You could use some sort of DI (dependency injection), currently using di-ninja which seems a bit overkill
Essentially, nothing much changed. Use the browser. Use JS. Use patterns. Use libraries as you see fit (watch that bloat).
Web components kind of miss a lot of the reasons why React has taken off. Encapsulation is one thing but it’s the declarative way of handling state, effects, and the DOM that make it powerful. Web components would need a framework on top of it to make it usable by developers building anything significant.
It seems useful for UI primitives, like a dialog, tooltip etc, that the browsers might not implement as native elements themselves. But as a building block for creating entire applications? I don’t think so.
Which means they’re always going to need to hook into the framework that’s rendering them, either to connect state, managing effects, or for styling.
I just don’t see sharing a component regardless of framework as a major problem worth solving right now. Buy into a framework and community like React and you can just drop components into your app. It’s not framework-agnostic but it works.
[1] https://andrewrabon.com/the-case-for-react-like-web-componen...
I think we can safely say that web components have failed.
It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does.
> I think we can safely say that web components have failed.
> It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does.
jQuery? I think your just making up nonsense there.
Fully ten percent of the web is using web components at this typing, and it's continued growth is steady as more and more libraries and frameworks, excepting those least able to easily leverage them, bring them into the their own projects. YouTube, ING, McDonald's, and other adopters are some pretty loud crickets.
> Fully ten percent
Citation needed. I’m sure it could be true, but it seems a high number for something that I’ve literally heard about for the first time today.
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.
Why should I invest my time in it now?
IE support? Are you kidding me?
I really wanted web components to take off, but they didn’t.
Without a new compelling narrative, I fail to see how they are “the future” in any meaningful sense.
Releasing an early version of something that is bad and doesn’t work (and let’s not pretend the shadow dom polyfill works, it doesn’t)... it’s just, not the right way to do this sort of stuff.
Popular projects like React use templates but require you to bundle the entire framework and the speed of the vDOM diffing happens at the speed of JS. What if it could take advantage of HTML templates to work at the speed of C++ by leveraging built-in browser support?
One of my hopes is that we can stop the bad trend of rewriting the same front-end components over and over again. Instead there could be a set of canonical components that people use for different web site types. If you're building an e-commerce checkout system, you could pull in the email address input built by Twitter, Stripe's credit card input, and the address input built by some person on GitHub that has 5,000 stars. Authors could leverage CSS properties and ShadowDOM for nice style hooks so developers could customize the branding.
The job of web frameworks could shift from "how do people build UI components" to "how do people build SPAs with routing, cookie auth, service worker caching, etc.". Not that current frameworks don't try to handle app level things but there is a lot more that could be done to make this easy for developers.
It would be nice to see web components as orthogonal to framework UI styling. We should be able to pull in web components from anywhere and frameworks should be smart enough to co-opt the components by treating them as native DOM elements (like div or span).
Sorry if this was sort of a rant I didn't have much time before work...
Everyone is reinventing the wheel over and over here and it's infuriating. I recently tried to find a good component to provide an internationalised currency input - it's incredibly difficult to find a quality implementation for this, yet it's something that the vast majority of web applications will need to use at least once. Same goes for phone numbers.
It would be nice to see web components take these roles away from frameworks. It would be nicer to see web standards identify the importance of many of these inputs in the first place.
I'm all for something that's native to the browser.
Right now you write a `<p>` tag for a paragraph element. No question about it. Imagine if you needed to use a P-tag library just to render a paragraph tag? Of course not right, you would just use the native browser `<p>` tag. I think that React is a P-tag library in essence.
I would go all-in for a native version of "frontend framework".
- Sliders
- Lazy loading images
- Complex select dropdowns
Rather than having to import a js file, css file, and use some weird wrapper around the existing DOM we have, we can import one file and be done with it.
- Declarative, functional API to write reuseable UI.
- REAL reusable business logic with React Hooks.
- REAL universal data fetching with React Suspense.
- REAL error boundary with Error Boundary.
- Learn once, write everywhere!
Do Web Components have the above benefits (yet) ?
Think about HTML how it started it was very rudimentary. At that point there was very many better "frameworks" for creating GUIs and applications. Yet HTML was in many cases good enough and since it was so simple it was able to evolve.
* Framework/library authors that now have a higher-level and hopefully more performant primitives to build on.
* Widget library authors that can now design component libraries that can used by any framework.
They're too low level compared to modern frameworks.
IMO the future of the web will be about compiling React, Vue, Svelte, to Web Components, for interoperability reasons. And nope, Polymer isn't as good as any of those.
The reason React is so popular and the reason it dethroned Angular, Backbone, etc. is because it is JavaScript-first. In other words, it gives you the power of a proper programming language to build UIs.
The question is how can we build better frontend apps and not should we use frameworks or not. In the end there are only tools for different purposes.
Context and history are important to fully grasp WebComponents.
WebComponents arose when there was jQuery and decoupling of CSS, HTML and JS.
If you look back 10 years, there was no real separation of concern and Web purists like today always disliked the idea of mixing CSS in JS.
Then came NodeJS and frontend build tools started to provide better tools (GruntJS etc.) for compile time checks. Encapsulating CSS in JS for example solved the problem of overuse of id selectors, greedy class selectors and namespace collisions - domains that WebComponents tries to solve with Shadow DOM etc.
Todays frontend frameworks in combination with the underlying build tools provide a lot of the abstraction that WebComponents want to give developers. So I would rather say that WC are another tool which can be used by modern frameworks.
It is like saying air pollution can be solved by driving slower on highways when there are only combustion engines. Why should teslas be punished for the wrong reasons? Same goes for WebComponents. Good idea, great abstraction but context is important.
I really don't get the disdain against Web Components and their related APIs. Why even fewer people are excited about custom elements alone sort of baffles me.
WC's aren't intended to replace frameworks and libraries. It's there to provide some universal primitives for writing components, and a lot of components aren't actually complex enough to warrant all the heavy lifting that comes with things like React and Vue. Those tools are great, but I also really love the idea that I can write useful components without having to import a bunch of extras(eventually the polyfills will be obsolete).
The innerHTML function can be slow if your code is sloppy and you're applying it to the wrong problem. Yes, you might need a data-aware renderer like the one in React, but often times you might not. For a lot of simple things, you can render elements without it by using createElement(), append(), insertBefore(), insertAdjacentElement(), cloneNode(), etc. They're not hard to use, but they're not pretty like a templating language, and they're not going to surround you in bubble wrap. I'm not saying that those tools scale for bigger projects, but there are plenty of small things you could write using Web Component technology. It has its place.
If you do things like call innerHTML multiple times in a loop, when you really could concatenate your HTML and call innerHTML once, is fundamentally going to perform badly, but web developers seem to write that kind of terribly-performing code in all sorts of cases and when it runs like crap they just assume that they need to import a library that will use tricks to cover up their lousy code. It reminds me of how folks will write a pile of garbage with Rails, switch to Phoenix because their Rails app is slow, and then claim that Rails sucks at performance. That's not to say that Phoenix doesn't have clear performance advantages, but the claim that Rails is slow often comes from a place of ignorance. A lot of jobs warrant useful tools like Vue, but then again, maybe your code just isn't very good. It's really embarrassing how many of us don't write code to be efficient, opting to always stand on the shoulders of giants who do the hard work to make our lousy code appear to run fast.
It has great tooling, awesome community, and it's pushed the boundaries of how we thought frontend development.
Html is good because it's declarative, but it's not good since it lack abstraction. So React combine JSX template and lambda as declarative component. Means you have parametrized template and loop etc.
Vanilla and jQuery is not so good because it's not reactive by default, which means you're not always describing things you want, instead you have to update something. Eventually you will forget some. It's called imperative.
Current Web Components spec include attribute changed hooks but it's far from React since most of the APIs are imperative.
But why declarity matters? Because it turns out front-end world is totally different from request-response backend programming. Because in front-end you're dealing with continuous sequence of signals instead of one off requests. Declarative style makes you describe the relation between model, views and derived values, not how to update or maintain those relations.
But in answer to the question, no. I doubt it. I tried building a site using polymer when if first came out. It was harder than the in house thing I'd previously been using and after about a year, the spec had moved on and my site looked like this author's blog: a big white page and some JavaScript errors.
I'm not the sort of person who enjoys rewriting my app every year to suit the whims of the framework it's on top of, so my plan is to emit boring HTML until something equally stable yet better comes along.
Because of how good web components in their current state are my very personal opinion is that the other frameworks I have written code in solve yesterday's problems and are very likely to become the future jQuerys.
"I have created a web component which lazily loads an image once it is fully visible in the browser's viewport"
Once the image is "fully visible", what's the point of "loading it"? Doesn't it go the other way first you load it then it becomes visible?
An example would be: a text paragraph which has "read more" button, when clicked, expands. Or an info popup with a "close" button. No need to put its state in your model and forward its messages.
But they could make frameworks like Bootstrap much easier to use.
CSS is the top. WC are the bottom.
React, Angular, Vue and company are the "between".
As Mr. Bernhardt says: JavaScript had to be bad for the evolution to happen. (https://www.destroyallsoftware.com/talks/the-birth-and-death...)
Works in Firefox.
I wonder does it use web components the article is about?