
Why I don't use web components - catacombs
https://dev.to/richharris/why-i-don-t-use-web-components-2cia
======
gildas
On my side, the criticism I could make to web components is that there is no
standard to serialize their shadow roots and, therefore, they are not
deserializable without using JavaScript. I have been maintaining SingleFile
[1], a web extension to save complete web pages, for 9 years and this is the
first time I have had to include JavaScript code [2] to attach and display the
shadow root of the web components (e.g. embed tweets) included in the saved
page.

[1] [https://github.com/gildas-lormeau/SingleFile](https://github.com/gildas-
lormeau/SingleFile)

[2] [https://github.com/gildas-
lormeau/SingleFile/blob/93d1e7c000...](https://github.com/gildas-
lormeau/SingleFile/blob/93d1e7c000946800866730c5763e3d0af0a033ef/lib/single-
file/single-file-core.js#L940)

~~~
dmix
Thanks for your work on this and good job not having to inject JS for so long.

I’m surprised there hasn’t been other nasty web stuff that required it.

~~~
gildas
Thanks! You can find web components in a lot of unexpected places. For
example, this page [1] contains more than 10K web components... The good news
is that once the Pandora's box is open, I had the idea to code SingleFileZ [2]
which also requires JavaScript to be enabled but frankly uses it!

[1]
[https://bugs.chromium.org/p/chromium/issues/detail?id=4](https://bugs.chromium.org/p/chromium/issues/detail?id=4)

[2] [https://github.com/gildas-lormeau/SingleFileZ](https://github.com/gildas-
lormeau/SingleFileZ)

~~~
dmix
It’s always interesting what we volunteer ourselves to become experts in
through our work in software. I respect any OSS developer that dedicates
themselves to this type of thing.

I’m curious what google used to create that chromium bug report page (internal
framework or a custom job). The internal tools targeting devs with good
browsers will always have the most advanced stuff it seems.

~~~
gildas
Google uses LitElement (version 2.0.1) [1] to create the page. You can see it
by typing `litElementVersions` in the JavaScript console.

[1] [https://github.com/Polymer/lit-element](https://github.com/Polymer/lit-
element)

~~~
dmix
Right, of course it was their Polymer toolchain. Thanks

------
JMTQp8lwXL
I manage a web application with hundreds, if not thousands, of screens written
in Angular, Vue, React, and server-side JSPs -- all of it developed over a
decade-plus worth of time. While old UIs will be continually be re-platformed
into the new, we will always have a legacy monolith. That's the reality of our
world.

If I want to introduce a design system, where all users of these technologies
can work with a basic set of bread-and-butter buttons, input fields, etc., Web
Components are the lingua franca of all of these technologies. That's why I
use Web Components.

Now of course, not everyone is developing on monoliths globbed together with
newer tech. But the reality is, most of the software used today is written
this way. It isn't pure, functional, isolated modules / apps that startups
going from scratch have the privilege of beginning with. Technology stacks
slowly become the consequence of business acquisitions, etc. You can exert
some control over things, but it will always be a moving target.

~~~
tracker1
Personally, I just find the lack of being able to declaratively pass state
and/or event handlers to child components painful. Not to mention that testing
with a full DOM (virtual or real) is really slow by comparison.

React + Redux + JSS just really matches how I've always conceptualized about
building web based applications. I absolutely favor material-ui as a component
library. I've been building web applications for almost two and a half
decades. React is the first framework that felt "right" to me, and still did
after using it. I've used a _LOT_ of options over the years.

I do think WC can be used with React in some cases, and that it's probably a
better approach if you're building mostly static content and wanting to add
additional interactive features outside of core display.

I also think in 5+ years there will be a couple library options that makes
using WC a better option for application style development.

~~~
JMTQp8lwXL
Web Assembly will maybe change everything.

~~~
tracker1
I think it will bring about a _LOT_ of changes for targeted applications, and
most specifically gaming. I also find Blazor and a few other technologies
related to WASM interesing. I do not think it will displace much as far as web
based applications.

And all of that said, I happen to like JS. It's my favorite language. While
I'm really green with it, I'd consider Rust my second fav. C# third. In the
end, I find that I can be incredibly productive with JS + NPM and that cannot
be understated. I'm able to leverage community repos that cover everything
under the sun and write less than half the code and better cover my use cases
for good enough performance. When I need more, I'll leverage other
languages/tools, most of the time, I don't. And even when I do, I tend to lean
on Node/JS for orchestration.

~~~
JMTQp8lwXL
I agree it would be kind of a waste to throw away all of the tooling and
innovations that has been made in JS ecosystem, just to start over because
another language can be easily used due to WASM.

The list of languages is bigger that I would've thought:
[https://github.com/appcypher/awesome-wasm-
langs](https://github.com/appcypher/awesome-wasm-langs)

In terms of enterprise usage, I'm not seeing any mature polyfill
implementations out there, but I did find
[https://github.com/lukewagner/polyfill-
prototype-1](https://github.com/lukewagner/polyfill-prototype-1).

------
ww520
I've started using web components in my last project and it has been very
helpful in compartmentalizing functionality and promoting resue. Things are a
bit different in my experience than what're described in the blog. Here're the
points as seen differently.

1\. Good point, though someone is going to write a server side renderer to
pre-generate the custom tags into regular html tags.

2\. A web component can import its own CSS file, no need to put styles in JS
code or string.

    
    
        <style>
          @import "/css/shared-styles.css"
          @import "/components/my-widget/my-widget.css"
        </style>
    

5\. Composing with sub-components works just fine with or without slotted
content. What's wanted in item 5 was a special case for dynamically including
content at runtime. That's best left to Javascript when triggered with
property setting.

6\. For properties and attributes, it's simplest to just reflect all property
get/set calls to attributes, using attribute as the only storage. I have some
helper function to do that.

    
    
        attrAsProp(comp, attr, property)
            Object.defineProperty(comp, property, {
                get: function()  { return comp.getAttribute(attr) },
                set: function(v) { comp.setAttribute(attr, v)     }
            });
    

9\. Global namespace is a problem but it also makes things simple to use. We
don't want complicate stuff like xmlns.

------
ken
> (The three spec editors are all Googlers. Webkit seem to have some doubts
> about some aspects of the design.)

Here's my issue with a browser monoculture. With 3 or 4 major browsers, it was
easy to tell what features would survive. The specs were never great at that
-- there were some early spec'd features that never got widely implemented.
But any feature that could convince people at Google + Microsoft + Apple +
Mozilla to all implement it would be around for a long time.

With Microsoft switching to a Chrome-based engine, this is a valuable data
point we've lost. Essentially, instead of new features being opt-in by
default, they're opt-out. We've seen it before: when one browser has a
majority market share, nobody else can afford to tell them an idea is bad.

~~~
nickthemagicman
Doesn't Chrome follow w3 standards though?

~~~
alexisread
Kinda, the W3C are now following WHATWG, so as Google are the major
stakeholder by marketshare it's more like the tail wagging the dog.

\- [https://www.neowin.net/news/w3c-and-whatwg-agree-on-
single-h...](https://www.neowin.net/news/w3c-and-whatwg-agree-on-single-html-
and-dom-specs)

~~~
nickthemagicman
Haha that's nuts. I see your point.

------
namelosw
The Web Component API is too imperative. It's hard to composite, and too easy
to let data out of sync (not being reactive).

For a broader meaning of Web Component (plain React, Vue, etc), they provide
good encapsulation and some degree of local reasoning. But harder to
communicate and stay sync with other components/server.

For Web Component with a centralized store approach (Redux, Mobx Vuex, etc),
it breaks local reasoning, and it requires the user to manage the life cycle
of data instead of just reuse the life cycle of components.

So there is still quite some space to improve. I found the idea of GraphQL co-
location is pretty interesting. And I also found there's a ClojureScript
library named Fulcro[0] specifically trying to provide the ability to have a
global data store while keeping the ability to local reasoning.

[0]
[https://github.com/fulcrologic/fulcro](https://github.com/fulcrologic/fulcro)

~~~
spankalee
Web components APIs are low level. They allow code to know where to do things
(the element instance, the shadow root) and when to do them (constructor, the
lifecycle callbacks).

They are not a direct analog to modern frameworks, and it's completely
expected that developers will use helper libraries to get better DX like
declarative and reactive components.

I work on two such libraries: lit-html and LitELement. Combined they give you
just as much declarative and reactive power as frameworks, much better DOM and
style isolation, better performance, and smaller size than just about anything
else out there.

Compare a styled Hello World example to React or any other framework:

    
    
        import {LitElement, html, css, property, customElement} from 'lit-element';
    
        @customElement('hello-world')
        class HelloElement extends LitElement {
    
          static styles = css`
            :host {
              display: block;
            }
            p {
              background: pink;
            }
          `;
    
          @property() name;
    
          render() {
            return html`<p>Hello ${this.name}!</p>`;
          }
        }
    

(this example uses decorators because I think it's clearer, but we support
plain JS as well)

~~~
arve0
> ... and smaller size than just about anything else out there. Compare a
> styled Hello World example to React or any other framework:

Compared with svelte from the article:

    
    
        <script>
            export let name;
        </script>
    
        <style>
            p {
                background: pink;
            }
        </style>
    
        <p>Hello {name}!</p>
    

# Size comparison

## lit-element

lit-element.js?module: 8421 bytes

lit-hello.js: 340 bytes

## svelte

bundle.js: 2628 bytes

bundle.css: 72 bytes

~~~
spankalee
1) That's the raw unbundled module source from unpkg. Bundled, minified, and
gzipped lit-element + lit-html is about 6.7K.

2) Svelte bundles the runtime operations that each component uses directly
into every component. HelloWorld doesn't use much, so it'll be small, but most
component are not HelloWorld and most applications will not have only a single
component. The cost of the common dependency on LitElement is amortized over
all the elements that use it.

~~~
arve0
> Bundled, minified, and gzipped

Why gzipped? Bytes of source is a fairer comparison. Parsed source code should
be the comparison, not transfer time.

> HelloWorld doesn't use much, so it'll be small, but most component are not
> HelloWorld and most applications will not have only a single component.

Then why dare other to compare sizes of a Hello world example? :-)

~~~
spankalee
Huh? I'm not comparing the size of hello world examples.

~~~
arve0
Then I read your first comment wrong, I was referring to my quote in
[https://news.ycombinator.com/item?id=20236130](https://news.ycombinator.com/item?id=20236130)

Regarding the comparison in source bytes, here it is:

minified lit-(element + html)[1]: 21.4k

I'm not sure it "amortizes" svelte when having more components, when runtime
in hello world example is less then 8x size. Would love to see an example.
Tried finding lit-element in "Real World Example" [2], but did not find it.
Maybe you have some pointers?

1: [https://bundlephobia.com/result?p=lit-
element@2.2.0](https://bundlephobia.com/result?p=lit-element@2.2.0)

2: [https://www.freecodecamp.org/news/a-realworld-comparison-
of-...](https://www.freecodecamp.org/news/a-realworld-comparison-of-front-end-
frameworks-with-benchmarks-2019-update-4be0d3c78075/)

------
traverseda
It's a problem of mixing data and visual elements.

In a good model of the web, html is your data, css is your styling, and
javascript doesn't really exist.

In another model of the web, your data would be your data, html/css would work
together to form a scene-graph. Javascript defines the relationship between
your data and it's scene graph.

That friction, are we using html as data or as part of our scene-graph, is
what causes a lot of these problems.

I like web components because they bring you closer to having html be just
your data. I like react because it brings your html closer to being just your
scene graph. Both solve the same underlying problem from different directions.

~~~
shooner
Well, I thought the 'good' model of the web was schema-based XML was your
data, XSLT was your representation structure logic, HTML was your
representation structure, and CSS was your representation styling. But the
ship sailed on that one a while ago...

~~~
miohtama
The road to hell is paved with XSLT. It was a good idea, but early 00s
X-everything were terrible implementations.

~~~
HelloNurse
XSLT is an unpleasant language (particularly for beginners) but
implementations I've seen tend to be correct and stick to the standard; what
trouble did you find yourself in?

------
danShumway
Good article. This articulates a number of issues that I wasn't able to put
into words, particularly around this idea that the DOM can be a really
inconvenient way to track state.

I still kind of feel like I need to sit down and figure out exactly what my
issue is with the current spec, but roughly speaking I guess I'd say that the
DOM should be a standardized display layer, not a way to store internal
application state. Or put it another way, the DOM is for your users, not for
your application. I don't think that fully captures the problem, but it's a
bit closer.

Regardless, I often flail when people ask me why I'm a little skeptical about
the way web components are currently designed, so at least now I have
something to point them towards.

~~~
interlocutor
When you use radio buttons, checkboxes and text inputs, they have state and
that state is in DOM. Web Components don't change this.

~~~
danShumway
Again, this is tough to articulate, and I'm not sure I'm going to do a good
job, but:

Good design seeks to limit the amount that we rely on that state in the DOM.
Typically speaking, I try to listen for events on input elements. I don't rely
on them as a state store.

Text inputs in particular here are kind of a good example, because they often
get used in combination with validation and autofill. I've seen a lot of bugs
and spaghetti code come out of running validation on field update, and using
that validation to update or fill in other fields, and needing to track which
update will trigger another event, and so on.

I'm not saying we should get rid of interactive elements on the web, but I
think they fall into something of a grey area that shouldn't necessarily be
encouraged. I use inputs to get the current user state, and to respond to user
input -- I try very hard not to use them as a state store for application-
level data.

I kind of think I would still say the same thing about inputs as I would about
regular HTML elements -- input elements are for your users, they're not for
you. They're not _your_ interface, they're just the way your users communicate
with you.

------
thrownaway954
I find it so funny how people use to make fun of ColdFusion cause of it's tag
syntax and the ability to create your own custom tags. Seems we have come full
circle now on the frontend. ColdFusion was truly ahead of it's time.

~~~
jchw
I think this is missing the forest for the trees. The key innovation behind
most modern frameworks is DOM abstraction and reactive data flow. The main
reason JS apps were, at one point, ugly spaghetti directly manipulating DOM
structures using jQuery is because JS was dog-slow at a point and was not
really capable of doing the cool object oriented stuff you could do on desktop
apps. jQuery answered to the problems of the time: it was relatively fast,
provided a terse interface (vs DOM,) and probably most importantly, it
smoothed over browser bugs and inconsistencies. Angular.js finally popularized
components, in the post IE6 era when JavaScript execution was a lot less slow
and unreliable, then React popularized reactive data flow and virtual DOM.

I think most good ideas in software engineering have already been discovered,
and primary innovation has long been applying existing ideas more effectively.
Hard to argue Angular.js or React does anything that has genuinely never been
done before, and same to ColdFusion.

~~~
kls
I would argue that YUI and Dojo where the ones that popularized components and
angular 1.0 directives where a step backwards in truly encapsulating
components as you could bleed scope all over the place. I agree with you on JS
speed.

~~~
jchw
This is fair. I didn’t use YUI too much but in retrospect it was pretty modern
for it’s time.

Still, I don’t think YUI necessarily had the mindshare the same way Angular or
jQuery once did...

------
tanin
I like the abstraction that web components provide. An encapsulated of logic,
view, and namedspaced style is great. I can build things like a button with a
loading icon.

But I can use Vue's component which don't care about the standard and just
compile everything down to a plain JS, so it works well with any browser.

On the other hand, PolymerJS tries too much to utilize the web component
standard. I didn't originally thought that this would be a bad thing.

Svelte does look good. I checked it out a year back and thought that Vue
should've moved more stuff into its compiler if it could.

------
pier25
My biggest issue with WCs is that they only solve a small part of the problem.
You get custom tags but without data binding and some form of reactivity these
are not very helpful.

Lit, Skate, Stencil, etc, solve those limitations, but if you are already
using a complicated toolchain and third party code for doing the heavy lifting
I don't see much value in WCs.

~~~
derefr
It’s a bit like having a stdlib type specifically for Sets or URIs or Rational
numbers in a programming language.

It’s not that any given library couldn’t make its own. It’s that having a
single implementation “canonized” in the stdlib means that every library that
wants this functionality will be using the stdlib’s implementation, and stdlib
functions will _also_ be able to consume or produce that type when it makes
sense, and so you’ll have an ecosystem that all interoperates by passing
around and transforming this shared type.

Also, standardizing Web Components also means changing the semantics of DOM
parsing for user-agents _other than_ browsers. My random Python HTML crawler
lib isn’t going to parse some third-party library’s implementation of Web
Components; but it _is_ going to parse standardized HTML Web Components.

~~~
danShumway
The problem is that Web Components give you an implementation standard, but
not a standard for what components are named or how they work.

Your random Python HTML crawler is welcome to try and parse standardized HTML
Web Components, but since every single one is going to be named differently
and have separate controls and interfaces for accessing data, your crawler
isn't going to get very far.

I am moderately concerned that Web Components are a step backwards for the
semantic web, not a step forwards. Particularly after seeing other comments on
this post that the shadow DOM is only accessible through Javascript in some
situations. To me, web components feel over-engineered. I'm not sure exactly
what it is, but I can't help but feel like there's a simpler answer to this
problem that would have worked better for everyone.

Maybe a better, Javascript free implementation of HTML imports? The last spec
got rejected for very good reason, but it's not like the core idea was
necessarily bad. Then maybe throw out Shadow DOM entirely and replace it with
some kind of more flexible/accessible scope system instead?

------
EGreg
Can someone succinctly tell us what problem Web Components actually solve?

Is it about avoiding namespacing your CSS? Is it about shipping reusable
components for many sites, hosted on some other domains? Loading JS on demand?
What?

It just seems overly complex and limited with its slots etc.

~~~
derek1800
The big advantage from my perspective is component reusability independent of
Framework (React, JSP, Angular, none, etc). A couple scenarios come in mind,
you have many teams working on web app(s) that need to have the same styling,
CX, controls. You can distribute them this way without tying them to a
framework. Another example is complex controls that can be downloaded to speed
up development.

~~~
interlocutor
There is also robustness. Today you can't take a React component from one
application and drop it in another React application and expect it to just
work. You may need to also copy CSS classes, make sure the class names are
unique, remove any conflicting ids, global variables and so on. Thanks to
Shadow DOM, web components are much more robust. You can just drop a web
component in an existing application and expect it to just work, regardless of
what framework (Angular, React etc) it is using.

~~~
EGreg
How is it better than using, say, iframes and postMessage? Is shadow DOM more
efficient? Can Web Components work across domains?

I want to have Shadow DOM that encapsulates trust, so the enclosing parent
javascript cannot access its contents!!

[https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144](https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144)

------
kls
I have a bit of a contrary view on a few of the items, not that I am defending
web components, I have my own issues about them but my point is to offer a
different perspective on a few of these items:

 _1\. Progressive enhancement - but I think that websites should work without
JavaScript wherever possible_

At a certain point, backwards compatibility becomes more a of hindrance than a
help, in an effort to support an ever shrinking demographic. Now I will give
the author the fact that they used the word website, where my frame of
reference is building modern web applications, falling back to no-javascript
to me would be going back to server rendering and the dumpster-fire of page-
post AS/JS/PH/P's.

 _2\. CSS in, err... JS_

Separation of technology, is not separation of concerns. This has been argued
over JSX and it has been shown to be a huge productivity improvement. If
everything for a component is internal to that component and does not need to
be reused in a way other than using that component then there is no reason to
separate the technology. As both of their concerns are the UI component. In
that regard, where everything is encapsulated to the component (HTML, CSS, JS)
it is actually a better pattern to not separate technologies as it makes the
component easier to reason about.

------
nickthemagicman
I feel like web components are more true to the original intent of the web
instead of these SPA frameworks in javascript.

You define your page with an XML document of UI components and javascript
exists for animation and data fetching.

I could be wrong but that's just what it seems like to me.

~~~
dmitriid
Nope.

You define your page with custom html tags that won't even render properly
without Javascript. And then you need Javascript for literally everything:
initialising the component, data fetching, inserting data into the DOM,
updating data in the DOM etc.

~~~
nickthemagicman
When I used SPA's it was basically web components inside of javascript so
seemed like a layer of unnecessary indirection?

I'm SURE web components allow a non-js fallback, or that should be introduced
into the spec.

See here for progressive enhancement of web components
[https://googlechromelabs.github.io/howto-components/howto-
ta...](https://googlechromelabs.github.io/howto-components/howto-tabs/)

Dont' SPA's require defining multiple components? A non-js component inside of
the html page and a JSX component or whatever inside of the SPA.

~~~
dmitriid
> When I used SPA's it was basically web components inside of javascript so
> seemed like a layer of unnecessary indirection?

In vast majority of cases it's nowhere near "basically web components".

> I'm SURE web components allow a non-js fallback, or that should be
> introduced into the spec.

They don't. All they can do is render static content inside if they have any.

> See here for progressive enhancement of web components

I fail to see where you see progressive enhancement. It's literally dozens of
lines of Javascript code. If you disable JS on that page, you'll get just the
static content with no functionality.

> Dont' SPA's require defining multiple components? A non-js component inside
> of the html page and a JSX component or whatever inside of the SPA

All you do is attach the root node of an SPA to any element in the DOM. A
common approach would be:

    
    
        <body>
          <div id="app"></div>
        </body>
    
        // elsewhere in JS code
        X.render(document.getElementById('app'), rootNode)
    

where X is your framework of choice.

~~~
nickthemagicman
>In vast majority of cases it's nowhere near "basically web components".

What else does it do besides render JSX components and manage their state just
like a web component except with more indirection?

> All you do is attach the root node of an SPA to any element in the DOM.

You missed the point of what I was saying

The root node is a single node...where do you define the rest of your
components? IN JAVASCRIPT. IF you want progressive enhancement you have to
define a SECOND SET OF NODES IN HTML. THIS IS REDUNDANT.

>I fail to see where you see progressive enhancement.

Why don't you actually read the thing? "If JavaScript is disabled, all panels
are shown interleaved with the respective tabs. The tabs now function as
headings."

~~~
dmitriid
> What else does it do besides render JSX components and manage their state
> just like a web component except with more indirection?

1\. There many more ways to implement SPA than JSX.

2\. WebComponents have exactly zero state management capabilities, and you
need to implement your own ways to deal with state

So, SPA frameworks provide the following:

\- state management

\- optimised/batched updates (they can flush to the DOM efficiently thus
avoiding jank, unnecessary re-paints and reflows)

\- async rendering

\- easy fallback states for async data fetching

\- data fetching

\- data propagation (for example, from parent to a deeply nested child)

\- data binding

\- render targets other than HTML (example, canvas, webgl, native mobile apps)

I'm definitely missing more. None of the above are provided by web components,
and you will need to bring your own frameworks/libs to cover all those points.

~~~
nickthemagicman
Some of those aren't SPA specific. They're just javascript. Some are done by
external libraries like redux. Some are benefits, however, two way data flow
is a janky model in itself that could possbily be done away with by a nice
data structure imo.

Also, this SPA cargo cult has been around a lot longer than Web Components
which have just the past year or two become cross browser compatible.

I expect great things from them.

Web Components and their associated libraries can and will do all of those as
they grow.

~~~
dmitriid
> Some of those aren't SPA specific. They're just javascript.

What do you think SPAs are? They are just Javascript. You add all that
Javascript on top of web components and you ... end up with an SPA

> Some are benefits, however, two way data flow is a janky model in itself
> that could possbily be done away with by a nice data structure imo.

Quite a few frameworks _don 't_ have two-way data binding. React famously
doesn't.

> I expect great things from them. Web Components and their associated
> libraries can and will do all of those as they grow.

So, they can't do those things and you're asking "what are SPA libs good for"?

You clearly have little to no experience with web development.

------
sdegutis
I've never considered #9 (global namespace) until yesterday, but it seems like
a show stopper for dynamic web components, whereas a system like React has
components simply being JavaScript objects that can be imported and whose name
is largely irrelevant except at JSX (or HTM[1]) parsing time.

[1] [https://www.pika.dev/packages/htm](https://www.pika.dev/packages/htm)

~~~
spankalee
It's being worked on:
[https://github.com/w3c/webcomponents/issues/716](https://github.com/w3c/webcomponents/issues/716)

The fundamental difference here is that HTML needs to know what class to
instantiate when it sees a tag. Supplying that unlocks a lot of power, like
custom elements in the main document, Markdown support for free, easy
integration with existing CMSes.

We can and will solve the single namespace problem though.

~~~
sdegutis
Thanks for the link.

By the way I just noticed you're the maintainer of lit-html. How does it
compare to HTM[1]? They both look like they accomplish the same goal but HTM's
implementation looks smaller.

[1] [https://github.com/developit/htm](https://github.com/developit/htm)

~~~
spankalee
htm is a nice bridge, because it works with React and Preact and both allows
for development in standard JavaScript as well as being a runtime perf boost
because strings are a lot faster to parse than nested function calls.

But htm is just a shell over VDOM (that's why it's small, you still need the
real VDOM implementation).

React + htm still suffers from its use of VDOM and the diff that necessitates.
lit-html doesn't do a diff because it remembers where the dynamic expressions
are located in the DOM, so it can directly update them.

~~~
sdegutis
Oh so lit-html has the incremental DOM update feature built-in? It's a full-
fledged replacement for the VDOM? I thought it was just a syntax parser like
HTM. (Hence my question.)

[Edit] Oooh, I see where I got mixed up: in your README, the only part where I
can find mention of this feature is in the very last part of this line:

> "lit-html templates are plain JavaScript and combine the familiarity of
> writing HTML with the power of JavaScript. lit-html takes care of
> efficiently rendering templates to DOM, including efficiently updating the
> DOM with new values."

Specifically the "including efficiently updating the DOM with new values"
part, that's the only mention on this page, and it's literally right after
where I started to skim due to (incorrectly) assuming the rest of the sentence
was just a continuation of the first part.

That feature should probably be mentioned more prominently.

Also, if it has the ability to re-render based on state updates (e.g. from
onclick callbacks), an example would be really important to know how to make
use of that feature.

------
5trokerac3
Everything is a give and take. At large organizations I've been at, web
component frameworks - especially strictly typed ones like Angular - have
tremendously helped to standardize web development across a large team of
varying skill levels. When there's only one standard way to make a GET request
and a defined interface that the result has to meet, output is much more
stable.

On the other hand, these frameworks can be completely unnecessary overhead for
one or two person teams. I'm currently using Preact for personal work, just
because of how simple and lightweight it is.

To the author's point on site's that work in older browsers or without JS,
unless you're building a product for government use or for an org that has
really archaic IT requirements, the chances of needing polyfills that aren't
provided by default in the framework are really low. The chances of someone
_needing_ your site to work without JS is also really low, especially if
you're providing any sort of complex functionality.

~~~
tyingq
_" site's that work in older browsers or without JS"_

I'm curious about this. A graph of say, what percentage of the top 500
websites can't run without JS, over time, would be interesting.

My assumption is that it's a non-trivial percentage, and growing.

~~~
HelloNurse
"The top 500 websites" aren't relevant. Their needs and tradeoffs are
different, and of course they tend to be negative examples.

Does _your_ site work without JS? If not, what justifies the more complex
development and the degraded user experience for you and your audience?

~~~
tyingq
This has nothing to do with my site. I'm curious what the trend is amongst the
most visited sites. You sure read a lot between the lines that isn't there.

------
diminish
If www was invented in this decade we would have a dozen mobile and touch-
friendly events and html element types.

And if we had those element types mobile web would be easier to use.

So Chrome and Firefox please invest in new HTML elements for mobile touch
web..

------
RocketSyntax
Looking forward to the day when Django templates can observe realtime changes
in user input (aka the equivalent of R Shiny).

------
carapace
(This might sound snarky so I apologize in advance for that.)

Just use Elm-lang.

In all seriousness, what is the business-value argument _against_ using Elm?

~~~
officialchicken
Hiring/staffing/ramp-up expenses for a team are the majority in comparison to
most other expenses the typical SMB will incur. Choosing a widely used
technology (or a specific one that is very common in a particular industry)
will normally provide greater long-term benefits and potentially reduce risk.
"Nobody ever got fired for buying IBM" was a truism 50+ years ago - and still
is today in many industries.

Edit: grammar, speeeling

~~~
carapace
I'm not sure I understand exactly what you're saying, but it sounds like a
kind of argument I used to encounter back in the day when trying to get people
to pick Python over Java, to wit: there are so many more Java programmers than
Python programmers, it might be hard to find people.

My response was, why would you hire a Java programmer who is unwilling or
unable to learn Python?

In this case, I would hire a normal person who was good at Sudoku and _teach
them_ Elm before I would hire, say, a React specialist who refused to pick up
Elm.

