
Web Components could replace frontend frameworks? - technojunkie
https://www.dannymoerkerke.com/blog/web-components-will-replace-your-frontend-framework
======
ssorallen
Web Components don’t offer a declarative way of updating the DOM; it’s still
`innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was
a hassle to manage in any sizeable app because updating the view was left up
to every dev to figure out themselves. React brought a declarative wrapper
around the statefulness of the DOM, and that is the killer feature that Web
Components does not offer at all. Vue adopted the declarative template
approach as well.

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.

~~~
lstamour
There is lit-html and lit-element, though you can get tripped up by the
difference between props and attributes coming from React JSX where everything
is props because it’s all native JS until the DOM render...

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](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](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...](https://github.com/systemjs/systemjs/blob/master/docs/import-
maps.md) or [https://github.com/guybedford/es-module-
shims](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...

~~~
Vinnl
But at that point the headline is "framework x could replace framework y"?

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...

~~~
spankalee
Templating libraries are far from frameworks. lit-html doesn't have a
component model, and it's use in a web component doesn't leak outside of that
component. You could switch from lit-html to something else and it wouldn't be
a breaking change to users.

Try thinking about writing a React component that doesn't use React to render.
Or seamlessly intermixing React and Vue commoners. Then you see the
difference.

------
jchw
>Web Components will replace your frontend framework

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.

~~~
spankalee
How do you feel that web components are heavy? They're a pretty small set of
low level APIs, and being native they have no download cost.

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.

~~~
jchw
>How do you feel that web components are heavy? They're a pretty small set of
low level APIs, and being native they have no download cost.

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.

------
zarzz
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...](https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e)

~~~
Vinnl
> 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.

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.

------
aphextron
I love writing Web Components, but they're never going to really be a thing.
The promise was that we could create native components without any
dependencies at all but it just hasn't worked out that way. Shadow DOM
support, the real killer feature, is patchy at best without polyfills.
Orchestrating them into any kind of complex app still requires some kind of
framework to handle things like passing down props and event binding, which at
that point you might as well go full on (React/Angular/Vue) + Webpack/Babel.
The dream of being able to share reusable components breaks down the moment
your designer wants an extra 5 pixels of padding here or there. It's fun to
use them for small things but it's just not viable as an alternative to
frameworks.

~~~
yesimahuman
Strongly disagree. We (Ionic) built our new version directly on top of Web
Components and they are certainly a thing for us and our users building real
apps on top. Plus, they are a huge reason why we now support React and Vue and
plain JS.

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/](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.

~~~
benforreal
I'm glad to hear this take. I came from Angular v1 and got sick of the
framework churn, so jumped over to Web Components around 2015/2016 instead of
going React. I abandoned Polymer pretty quickly around v0.6 because things
were changing too much and just went plain vanilla JS + Web Components. I've
been building applications since then with just Web Components and couldn't be
happier. Unfortunately I just don't have enough experience with React to
debate any of these points - I guess I just have to leave it that React is a
need I don't have.

------
AaronFriel
The tooling is woefully inadequate, and the premiere Web Component tool is
stringly typed to all heck which makes it a non-starter for me. I don't want
giant blobs of runtime parsed text with no validation, syntax highlighting,
and obviously no type checking.

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>
          `;
        }
    

Cool. What an enormous regression over TypeScript with React and Vue. My
editor just sees components as enormous blobs of text, and what do you know,
so does my build system.

~~~
westbrookjo
Types are cool, TypeScript is cool, and types with JSDocs are cool,
[https://dev.to/dakmor/type-safe-web-components-with-
jsdoc-4i...](https://dev.to/dakmor/type-safe-web-components-with-jsdoc-4icf)
and what's more, they're all cool with web components.

~~~
AaronFriel
I'm confused, I scrolled down and still saw this:

    
    
        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>
        `;
    

That is not type checked. I can change any of the HTML tags in there, any of
the attributes on the HTML tags, I can make the template ill-formed HTML, and
nothing in my editor or build system will check that.

    
    
        const el = /** @type {TitleBar} */ (document.querySelector('title-bar'));
    

Why would I do that instead of this, if I'm using TypeScript?

    
    
        const el: TitleBar = document.querySelector('title-bar');
    

Moreover, this is an unsafe type coercion, we have no witness that the return
value is a TitleBar. document.querySelector returns an HTMLElement, and if you
were using strict TypeScript types this assignment would not type check.

~~~
no_way
There exists plugin for VSCode which checks for attributes inside template
literal
[https://marketplace.visualstudio.com/items?itemName=runem.li...](https://marketplace.visualstudio.com/items?itemName=runem.lit-
plugin)

~~~
AaronFriel
That looks extremely useful though it's definitely in the "early adopter"
phase of utility. It looks like this extension and the underlying TypeScript
plugin that allows typechecking are being developed by a single person, and I
think a team or individual would have to make a judgment call on whether to
depend on it.

------
ernsheong
Web Components did replace frameworks for me. I built KanRails
([https://www.kanrails.com/](https://www.kanrails.com/)) with LitElement,
without React/Vue/etc.

The alpha is at
[https://app.kanrails.com/signup](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/](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.

~~~
ernsheong
Just to elaborate a bit further to help fellow sojourners:

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).

------
wokwokwok
So I tried web components two years ago, and it was very painful, and I
crawled back to react.

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.

~~~
boubiyeah
No more reason now than 2 years ago.

------
greenyouse
Browser specifications are not nearly as transient as proprietary frameworks.
Web components will be here next year, five years from now, ten, and thirty
years from now. We should focus on how we can take advantage of the new spec
to enhance existing frameworks.

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...

~~~
spronkey
Forms are where web standards are most lacking. HTML5 took us from the stone
age to the bronze age by adding some still-basically-useless inputs for e.g.
colours and dates.

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.

------
revvx
I strongly believe Web Components will catch on, but not in its vanilla form.
Writing code for them is a pain in the ass for non-trivial stuff.

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.

------
winterthedeep
I worked with Polymer-based components ~2 years ago (an eternity in frontend-
land), and I want to share my biggest pain point: you may want to integrate a
`<cool-carousel>`, but it does not "look right" in your design (eg white
website, but the carousel has a black background). If the author did not set
up CSS variables, you have to either try overriding stuff, or fork it. This
problem is why every organization (eg GE with Predix or Electronic Arts) had
to create their own components, so they can share the same "art style"/design.
Can you share your experience about that?

~~~
benforreal
In the instance of Predix (I peripherally worked on that during my time at GE)
and likely EA and every other large Web Component ecosystem you're thinking
of, that's desired behavior. The real want is a design system such that things
look consistent, but as design systems are CSS only, they aren't smart enough
for interactions that require JS. So then the need for a design system becomes
a need for components of some kind that include the design. You're looking for
components with more adaptable design, but that's just not the intention of
these ecosystems. If done with that goal, yes CSS vars take you a little bit
of the way, but I think we'll see more power coming to help out soon with
Shadow Parts/Theme, CSS Modules, and Scoped Stylesheets. But really, just
styling a background? If the component author just left the background: none,
you could do whatever you wanted from the outside. It just takes planning -
even without the Shadow DOM you still need to plan for proper themeing.

~~~
winterthedeep
"styling a background" is just an example - I admit it is a bad one (glad I
don't work in frontend anymore). I will read about CSS Modules and the other
stuff you mentioned. Thank you.

~~~
benforreal
Sure thing! Those things are def up and coming, and I'll admit I haven't
looked into them so much yet, but they are being designed to solve this very
problem. I don't think that Web Components are the tool to solve every
problem, but I've been a fan for a while (so much so that I'm writing a book)

------
mmckelvy
Web components will never take off because they are HTML-first and rely on DOM
apis.

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.

------
threeaccents
Web components are awesome I've been using them in production using StencilJS
for a pretty large app for about a year now. Even though browser support is
widely available there are still a few gotchas with web components, specially
Shadow DOM. Not all community tools have caught up as well. For example you
can't use Stripe v3 with Shadow DOM. Most analytics tools also cannot access
the Shadow DOM. We had to remove Shadow DOM from all our components that were
using it. In my opinion Web Components are definitely the future but there's
still some catching up to do before we can claim it can replace frameworks.

~~~
westbrookjo
You might be interested in [https://github.com/bennypowers/stripe-
elements](https://github.com/bennypowers/stripe-elements) Stripe v3 with
Shadow DOM.

~~~
threeaccents
Thanks I had actually seen this while looking into a workaround for us.
However I thought that LitHTML elements only worked with other LitHTML
elements since you need the correct bundler for it. StencilJS projects don't
have any bundling system.

~~~
westbrookjo
LitHTML and LitElement don't need a specific bundler, they work with whatever
tools (or not) you'd like. You might want to get them another look!

------
_the_inflator
I think that the author misses the point.

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.

------
ramon
A couple of days ago I saw a project here called pika which is any npm package
it seems running in the browser, it's interesting to have the web components +
pika where we can bring in different modules from npm and combine that with
the power of web components then there really is no need for other frameworks
but.. it brings that problem we used to have with JQuery which is lack of
standards.. it seems we keep on going around in circles but web components are
a lot faster and easier then React or Preact.. and the routing thing just
makes everything fat for the bundles... then you have to worry about bundle
splitting... the main/core bundle... pika is a good one because it takes the
bundling off the bat and makes everything easier without the routing.. I now
wish for a standard with web components and pika and doing the polyfilling...
and ... material framework... and.. some coding standards just so we don't get
a mix of Jquery and react and preact and a lot more in one single page load.

------
anthonyshort
I don’t understand the push to make userland component abstractions into
native primitives. It’s perfectly fine for the browser to just implement low
level primitives for frameworks like React to build on top of. It allows the
framework to develop much faster.

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.

~~~
yesimahuman
They aren't trying to solve the same problems. The main problem they solve,
that no other userland framework solves, is that I can now share a collection
of my rich JavaScript components with every single web developer in the world
regardless of the technology they build web apps with.

~~~
hesarenu
I would rather have browser provide rich components then rely on third party.

~~~
cletusw
That's one of the huge benefits of web components -- third parties can iterate
quickly to find useful patterns, then browsers can just standardize the
best/most popular ones. The old way of discussing ad nauseam in committee then
implementing straight in the browser gave much less useful elements. (And it's
much less straightforward to convert a popular React component into something
browsers could implement natively.)

~~~
dmitriid
> hird parties can iterate quickly to find useful patterns, then browsers can
> just standardize the best/most popular ones.

I'm looking at hundreds of date pickers, carousels, autocompletes,
customizable selects, data tables, modals (e.g. for media previews). They've
been around for as long as there have been browsers (so, thrity years or so).

Can you point at any standardisation effort around any of these commonly
repeated patterns?

input type="date" and input type="color" are only now barely making it into
the browser.

------
ravenstine
This article, the HN comments here, as well as comments on /r/javascript, are
helping to solidify my view that way too many frontend developers don't know
enough about what they're talking about.

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.

------
rovyko
CSS is still a pain in Web Components. Constructable stylesheets solve that
problem, but they're still in the "Worth Prototyping" stage for Firefox.

[https://mozilla.github.io/standards-
positions/](https://mozilla.github.io/standards-positions/)

------
Andrex
I argued for a similar case last year[1], however the missing piece right now
is updating state in a clean way. Web Components definitely won't replace
current front-end frameworks, but combined with ES Modules the web is getting
to a good place for resuable primitives. :)

[1] [https://andrewrabon.com/the-case-for-react-like-web-
componen...](https://andrewrabon.com/the-case-for-react-like-web-
components-63887335fe41)

~~~
westbrookjo
Be sure to checkout lit-html and LitElement ([https://lit-html.polymer-
project.org](https://lit-html.polymer-project.org) & [https://lit-
element.polymer-project.org](https://lit-element.polymer-project.org))...what
you've written about here already exists!

~~~
threeaccents
Also give StencilJS a look. It's a compiler instead of a framework or library.
The end result is pure vanilla components
[https://stenciljs.com/](https://stenciljs.com/)

------
rhacker
It's insane to me that everything Polymer was got reduced to LitElement which
is basically a complete copy of React without React and without the
immeasurable support of typescript, VSCode support IN the view and debugging
directly in the TSX.

~~~
thosakwe
Yeah, I didn't really understand why there was a need for an overhaul like
that. I honestly was hoping that there'd be a better story for databinding,
types, etc. I just gave up and went back to React.

~~~
ernsheong
Polymer was trying to do too much (to be a framework), and the quality was
average at best.

LitElement is able to focus on providing the best base class to build a Web
Component. I think it is almost there.

------
ricardobeat
As expected, no mention of server-side rendering.

~~~
westbrookjo
You can server side render a `video` element just the same way you would a
`custom-element`. We've been doing it for years and there's no reason to think
anything about that has changed. If you're looking to deep SSR which is
arguable as far as benefit, check out approaches like
[https://github.com/ionic-team/stencil-ssr-starter](https://github.com/ionic-
team/stencil-ssr-starter)

~~~
georgecalm
I think the difference is that the browser already contains the shadow dom
needed to render the video tag. But for a custom tag it would need to fetch,
parse and execute your component code before it can begin to render.

~~~
westbrookjo
That's an interesting read. I'm thinking on whether the real question is what
is the declarative difference between the video tag, which by normal
application lets everyone feel find about that content hidden by the shadow
DOM vs the APIs we're developing for our custom elements. There seems to be an
important piece of learning, not just for SSR, but for custom element
development in general, that I think we can build off of.

------
sergiotapia
Being native to the browser, how fast is it compared to React? It is 10x
faster because it's native? Is it on par, with room for browsers to improve
it's performance even further?

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".

~~~
VvR-Ox
I totally agree - we need "one framework to rule them all". I don't want to
learn another 10 technologies we won't use anymore in 5-10 years.

------
founderling
I wonder why HTML never got includes.

It would be so nice to just write:

    
    
        <include src="footer.html">
    

On Hacker News, for the first pageview, this would load the whole "Guidelines
| FAQ | Support ..." section. On all other pageloads, the browser would
already have it in the cache. So it does not have to be loaded again.

Building complex websites would become so much nicer. Because each part of a
page would be an include.

~~~
zarzz
If you are looking for just a simple load some html and replace this where my
<include> tag is kind of thing you are right, nothing does that because it’s
more complicated then that... what about the styles of the included html? What
about the behaviors (JavaScript) for it. How does that translate with the
include?

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...](https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e)

B

~~~
founderling

        It’s clean and simple
    

How so? What is the Web Components equivalent of <include src="footer.html">?

~~~
zarzz
As an example HN here on might structure things like this:

<script src="./hn-components.js"></script> <hn-header></hn-header> ... all the
main body content ... <hn-footer></hn-footer>

To answer your direct question, the WC equivalent of <include> is the <script>
tag. The <script> loads the component definition and all the resources related
to them (See ZephJS for how this is super easy to do:
[https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...](https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3e))

<hn-header> and <hn-footer> are defined in the script. They carry with them
all the content, layout, and behavior for those parts of the site. This
provides a nice clean separation between the page and the header and footer
pieces. Changing the header or footer becomes just changing those parts. This
is absolutely easier then using react or angular for the equivalent kind of
things. Does it provide all that react/angular does, of course not. But it is
infinitely cleaner then using either. Especially with ZephJS (gratuitous
plug).

~~~
founderling

        the WC equivalent of <include> is the <script> tag
    

I beg to differ. My <include src="footer.html"> would insert the html in the
footer.html file. While <script src="components.js"></script> will execute
javascript. Then the javascript has to _somehow_ prepare magic so that <hn-
footer> will be replaced by some html.

The link to the library you gave does not help here. Because I am thinking
about browser technology here. What has to go into components.js (without
using a library) to make <hn-footer> be replaced with the html in footer.html?

------
deanclatworthy
I think a lot of you are missing the point of Web Components here. They're not
going to replace React et. al for huge frontend applications. But they are a
great solution to drop in for a lot of projects where you need things like:

\- 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.

~~~
ssorallen
I agree, your examples seem to be prime use cases of Web Components. The
original post though makes the claim that WCs are ready to replace your entire
framework.

------
irenkai
You are only thinking of one frontend, React allows a multitude of renderers,
even the command line [0].

It has great tooling, awesome community, and it's pushed the boundaries of how
we thought frontend development.

[https://github.com/Yomguithereal/react-
blessed](https://github.com/Yomguithereal/react-blessed)

------
jaunkst
Ploymer was a crapshow and HTML import a nightmare for load times. Unless some
sort of topology bundling is provided for web components I'm out. We tried to
do generic components for multiple frameworks based in webcomponets and it was
an utter failure in practice especially for low band networks.

~~~
rossy
To be fair, HTML imports is deprecated and won't be standardised. The
recommended way to package web components now is with ES modules, and they
_can_ be bundled (with eg. Rollup or Webpack.)

~~~
jaunkst
That is great, but I am still 100% sceptical of a web component intergration
with any given framework. Is the integration point opinounated? Is it
reactive, callbacks? Two way bindings? What does the application lifecycle
look like? Would it be just opiononated sets of components? I just don't
know... If I'm wrapping web components to meet our design patterns then why
bother at all? I feel like the entire web component concept from an API level
is a great concept but just not there for real world at scale consumption. I
may just be not optimistic about it all.

~~~
blablabla123
It seems that it's not about binding but that devs need to take of it
themselves. On the other hand, I guess you _first_ need to generic interface
to bind on and _then_ it's possible to take care of bindings.

That said, I think nobody needs any framework any more if some automatic
binding mechanism would get standardized. At least for apps that routinely
instantiate and destroy components would profit from that a lot.

------
Blackthorn
I don't get the hate for web components. I think they are amazing. A number of
times I just wanted a damn date picker, not a framework that changes how I'm
making my website! Web components provide exactly that.

~~~
galaxyLogic
I agree. But there's always "hatred" for anything new which requires people
yet again to learn new ways. I understand that. But there's nothing more
difficult to stop than an idea whose time has come. I think that was from a
Funkadelic LP-cover :-)

------
westbrookjo
One thing that is particularly important to take into account when comparing
web components to framework is that they can and should work together. If
indeed "web components" replace your "framework" it will most likely be
because a new framework that takes advantage of web components and all that
the web is now replaces your old framework. Already libraries that combine
popular concepts like hooks from React with web components
([https://github.com/matthewp/haunted](https://github.com/matthewp/haunted))
are pointing the way to a more powerful future for both site that need just
that little extra something via a stand alone web component or a whole family
of components wedded to a framework into a rich application. That being said,
don't get confused by people on either side being overly defensive of their
place in the web ecosystem things are they are now will change. Techniques
will grow and merge and there will be something else that is "the thing"
before too long. Web components will likely be as much a part of that as the
elements who's shoulders they stand on (e.g. <select/> and <video/>). That's
the power of the web.

~~~
galaxyLogic
True. One more thing about web-components is that they are a standard. Vue,
React, JQuery are not.

------
pier25
No. WCs can only replace one aspect of React or Vue. You still need a better
way to manipulate the dom and react to data changes than pure vanilla.

------
zachrose
I wish the ideas of the Elm Architecture (or React/Redux) could be brought to
the browser. Primarily, an atomic single source of truth (serializable data)
for window.document and a way to connect that state to the DOM through pure
functions so that we can avoid local component state that then has to be
orchestrated with references, event buses, etc.

------
namelosw
At least for current Web Component API, no.

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.

------
revskill
It's not about implementation details, it's about programming paradigm. In the
case of React, it's

\- 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) ?

~~~
galaxyLogic
Of course not. But many smaller apps don't need all of those.

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.

------
jasonkester
I see a header and a footer and a big blank page. Whatever the author is using
to replace his front end currently doesn't work on my iPad Air.

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.

------
johankmagnusson
I've written a couple of smaller and larger apps in Angular 1 and 2, Vue,
React, Polymer and recently trying out lit-element and it solves pretty much
all my needs. I like the typescript decorators for properties and elements and
that is the only reason for which I need Webpack. Redux, the part of it I need
which is updating from a central store, I replaced with about 20 lines of
javascript.

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.

------
Aeolun
Given that they were introduced in 2011, and in regards to their usage you
hear... well _crickets_

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.

~~~
hyperpress
> Given that they were introduced in 2011, and in regards to their usage you
> hear... well crickets

> 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.

~~~
Aeolun
Nope, no nonsense, but the issue has already been repeated in a bunch of
comments here, so I don’t really need to any more.

> 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.

~~~
hyperpress
Repeating what? The same outdated, misrepresented arguments mainly relied on
by react fandom? It's simple, lot's of options out there. If comfort and
loyalty clearly takes precedence over best solutions, you've already made the
decision. The problem isn't that web components failed, or you can't pass
objects via props, or that you think you need polymer, or their not browser
supported, or they actually adapt in most existing Frameworks. The problem is
turf, and react loves its turf. Just point out that arguing from a position of
5 year old specs, adoption, and knowledge isn't, IMO, very wise. Rather a self
inflicted lost opportunity.

------
galaxyLogic
I think this is an excellent thorough presentation of WebComponents. One think
I didn't quite understand was the first example about which it is said:

"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?

------
k_bx
Web Components are an ideal complement to pure statically typed languages like
Elm, where it's a bit of a hassle to implement simple, isolated components.

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.

------
true_religion
The shadow dom is just JavaScript, HTML and CSS. For any significantly sized
component I would want a framework to wrangle all that.

~~~
Spivak
I don't really think end-devs are the target audience for Web Components. I
see two users that will benefit:

* 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.

------
iliaznk
That's the case when a title is enough to see the author has no idea what he's
talking about, that's convenient!

------
k__
No.

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".

------
bandy008
It's a good development but this article is misleading and ignorant. Web
Components cannot replace web frameworks like ReactJs, Angular or Vue. At
least not yet. Im not sure if this guy have used any of these frameworks
before.

------
mikeytown2
CMS static site builder based off of Web components
[https://github.com/elmsln/HAXcms](https://github.com/elmsln/HAXcms)

------
bobske4
wasm and wasi will eventually take over enabling higher level languages such
as C#, Java and Python to be used at frontend (Blazor project is an example).

As Mr. Bernhardt says: JavaScript had to be bad for the evolution to happen.
([https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript))

------
Const-me
The page renders as a big white nothing in Edge and IE.

Works in Firefox.

I wonder does it use web components the article is about?

------
sbhn
When i download static html from a webserver, it just draws it straight to the
screen

------
kentbrew
When you write something like this please include a date of publication.

