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

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

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.

You can use JSX syntax for building web components using this tiny library: https://github.com/wisercoder/uibuilder

You can absolutely use web components with react... you just have to use `<lower-case-component>` for webcomponents, since a capital first character will trigger JSX transforms.

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.

Vue already offers compiling to web components.

https://cli.vuejs.org/guide/build-targets.html#vue-vs-js-ts-...

Well I like stencil for its typescript and jsx but I haven't dug into it hard enough yet to discover its agony points. Its just that when it compiles its all native code calls, no framework to ship but you still benefit from jsx and typescript in development.

And, there is Stencil JS (https://stenciljs.com/) which in my opinion offers a neat API to create Web Components.

There's nothing wrong with using a DOM templating library to give you declarative DOM updating. There are a number of solutions, many even JSX-based, and this is also why I created lit-html, which offers extremely light weight template expressions, similar to JSX but in standard syntax, and very fast updates.

There's no requirement that you use web components without helper libraries. That was never their intent.

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

Amen!

The core problem now is that Web Components aren't any faster than userland frameworks like Preact.

Specifically:

1) First Contentful Paint: Web Components require client-side JS to render, which guarantees that their FCP numbers will be slower than React/Preact server-side rendering solutions, which can render without client-side JS.

2) Time to Interactive: LitElement + lit-html at 4KB is smaller than React (but not if you include WC polyfills), though it's not smaller than Preact (3KB).

3) Efficient Updates: lit-html might be able to beat out React/Preact here if you have a large page and you don't use shouldComponentUpdate or React.memo, but lit-html doesn't use Web Components (custom elements, shadow DOM). Haunted "virtual components" (lit-html + React-ish hooks) look pretty cool, but that's still not WC.

Without a credible performance advantage, Web Components are a zombie standard, walking dead.

If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac.

Any JS component library needs JS by definition.

> If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac.

Not if you need both server-side rendering AND a rich frontend. Unless you want to duplicate logic between two frameworks.

Server-side rendering and a rich frontend are orthogonal.

And yes, JavaScript is absolutely not the best way to actually make use of the server rack.

https://www.techempower.com/benchmarks/

They are, unless you want to avoid duplicating logic, like I said. That's where most of the benefit of server-side rendering via JS comes from: you can render the initial page on the server, but then have the client-side framework take over on load, all from the same framework and with very minimal code duplication. Otherwise you have to write most of your rendering logic twice, in two different languages/frameworks.

Re: benchmarks, I don't know what that has to do with anything. JavaScript (via V8) is much faster than Ruby and Python, and yet Rails and Django are still massively popular. For most apps, using a super fast backend language is not a concern.

I rather go with rendering performance of HTML, CSS and minimal JS.

No one working on web components had ever said that they're intended to be used with absolutely no helpers.

What I don't get is why there isn't a native, declarative DOM templating API yet. It would be so much faster and would mostly eliminate the need for React and the like. Instead of a "virtual dom", a native "dom buffer".

I have high hopes for Flutter/Hummingbird in that regard. When their renderer is implemented using web APIs, this is basically what we'll be getting.

this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"

Well, yes and no. They are implementing a rendering engine that supports things the web famously doesn't support, which includes fundamentals like UITableView from iOS. They are doing this by leveraging new APIs to access what browser layout engines do under the hood. So in that way, it generates native browser elements, and their API is declarative. So it's at least one abstraction layer below React and friends.

....no and no. The call was for a declarative interface to the DOM, like React, built into the browser. Flutter, being not built into the browser, is not that.

There are a million things that do this already - including Qt, which already works in WebGL. The point is to leverage the rest of the web's existing features while also getting declarative templates, not to create another Flash.

Flutter/Hummingbird will be writing DOM elements, so it's not just an opaque WebGL texture.

In terms of "dom buffer" there's a proposal in the works for the buffer "other half" to `window.requestAnimationFrame()` to queue DOM reads (where RAF is the place to queue DOM writes). So far I've heard it has the unimaginative and odd use of grammar name `window.requestAnimationFrameAfter()`.

Still would be too low level to easily work with though without a framework like React.

Yeah, articles that proclaim the end of frameworks due to Web Components always revolve around a misunderstanding of what those frameworks bring. This article, likewise, starts out on the same incorrect premise:

> [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 reuse react components ALL the time.

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.

Ah, yes - within the same applications, components are often re-used. Still, it's a stretch to say code re-use is the main reason people are using React. Rather, its advantage lies in its composability and how easy it makes it to separate view logic from other logic. And probably a few other reasons that other people would name as well; in any case, it's not just the ability to re-use components, and an alternative only providing that part is not going to replace React in my applications any time soon.

I reuse components in different applications. There are also popular third-party components (and even whole libraries) to be found on github and elsewhere.

I don't think web components will replace react, simply because they do different things. You can write web components in react which gives you the best of both worlds.

> How often do you re-use your Angular and React application?

A lot, our Angular components are re-usable across projects.

I'm constantly reusing modules/components/pipes/guards/interceptors/etc across angular projects. Saves a lot of time. It's not the reason I use the framework, but it gives me more incentive to stick with it.

Our company standardized on React company-wide along with a company-built framework of reusable components to share across all applications.

Apparently at least some people choose frameworks because they want that.

We have been using a small bit of glue code to write Web Components declaratively with Snabbdom for a couple of years at Mixpanel: https://github.com/mixpanel/panel. Happy to talk further about our experience!

Thats what lichess uses as well.

"React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature"...

Yes, If there was a native standard for watching and manipulating state then frontend frameworks would be largely unnecessary.

You might be interested in this: https://github.com/w3c/webcomponents/blob/gh-pages/proposals...

(For security purposes, in vanilla js we should all be using textContent, not innerHTML, and creating dom nodes directly.)

When you control the data, innerHTML is fine. It's only untrusted data coming from the user that's the problem.

Only if you can, with absolute certainty, keep track of which of those is which, and never have it change, or have some offline process polute data that was supposed to be clean.

There is almost never a reason to use innerHTML, and by avoiding it you reduce the surface that could be attacked.

You are just making things extreme without giving your fellow software engineers some confidence that they won't screw up. Plenty of variables are string constants, or numbers coerced into strings or some such. A good type system will always help though.

In the words of Jeff Atwood, "Give me parameterized SQL, or give me death" - and HTML escaping is little different. My fellow "software engineers" are human. They will screw up. That's simply a matter of human nature and statistics. Even if we only employ godlings, we'll eventually hire a human intern.

"It happens to be safe for the moment because it's a constant" isn't a high enough bar. I've refactored plenty of string constants to new locations, and then to dynamic strings. If that's the bar you're using, every such refactoring is now a security critical change that requires a thorough security audit.

There are uses of innerHTML, but the post you're replying to acknowledges that - "almost never". If you're building the APIs that enable safe DOM manipulation, you have some use cases. If you're serving HTML fragments directly from the server, you have some use cases - although I'd hope you're using safe APIs serverside if it's dynamic, instead of hand-building HTML in code!

apart from where you actually have html formatted text. not plain text.

innerHTML has to parse the html, so won't it be a bit slower?

Wouldn't the JavaScript engine need to parse your long and complicated chains of `document.createTextNode(blah)` or `parent.appendChild(foo)`?

Never use .innerHTML! Instead use .appendChild, .removeChild, and .innerText. Using .innerHTML is like having a program patch itself during runtime.

textContent is usually better than innerText.

While I know what you're getting at, the word "never" really isn't helpful or useful. There are certain times where innerHTML(or insertAdjacentHTML) is the best approach. It's really not that slow that it can't be the most clear and concise solution.

Its not about performance. innerHTML is actually fast. Its about security and maintainability. InnerHTML makes it easy not only for the developer but also an hacker to inject code into a web page/app. innerHTML is like a global missile satellite network that can fire anywhere at any time. Instead you want to design like a plumber, where data flows via a pipe to the database, then back again in another pipe which change the state of the view. You should not have a single HTML tag in your single page application!

I use lit-html and it is more than enough for our needs!

what about slots?

Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)

Performance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.

True, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation if you want CSS nesting the way you expect it in Sass. Here’s more documentation on constructible stylesheets: https://developers.google.com/web/updates/2019/02/constructa...

I wasn’t aware of this because this stuff is being developed and released so dang quickly! (I do worry that APIs developed in relative haste might be replaced or iterated on in relative haste, especially if they aren’t adopted widely first...)

  :is()

can make concise CSS of some of what nesting does in Sass

https://developer.mozilla.org/en-US/docs/Web/CSS/:is

there's a lot New coming into web all the time. I watch chrome status for drops.

https://www.chromestatus.com/features

Very early ShadowDom had worse performance, but the major browsers have been hard at work improving it for a while now. I haven't benchmarked in several years but I wouldn't be surprised to find that it is now a boost in many cases.

You might want to check out https://cssdb.org/#nesting-rules native nested CSS rules have hit stage 1!

I checked the spec earlier and it’s impossible to make it backwards compatible with Sass without some slight edits, at least according to their GH issue on it. It’s worth watching though I suspect <style type=“text/scss”> or something like it will be added before we see broad adoption! :)

Possibly. I think the extra `&`s are something that could wash out with one-time tooling, and that the desire for `@nest .parent &` would bump the conversion rate, but it's always fun to watch the comings and going of standards.

Perf boost compared to what? It can't be a FCP perf boost relative to server-side rendered plain old CSS and HTML, because shadow DOM requires client-side JavaScript.

Plain old CSS is able to parse and render before the JS required to launch web components has even finished.

It can be a performance boost because it only updates the part of the DOM tree that has changed. Not completely unlike React’s virtual DOM

This. I feel like an old man yelling at a cloud, but while everyone seems to focus on how awesome shadow DOM and isolated CSS is, I need to deal with using a global theme and styles.

I have the same problem with global styles when using Web Components. Using @import in the components to include the shared style files solve the problem.

:part and :theme CSS puesdo-selectors will help address these issues

you can also use :host, which target the custom element specifically (and using :host on custom-element children does not, from what I recall off hand, get broken when nesting) and then target its children.

Also, css variables can be global and still enter into the shadow-dom unobtrusively (This is without using the polyfills, though, I believe this is a limitation in the polyfills currently, which might be why that part of it has been confusing in the past.).

Shared CSS can be dealt with using @import.

"declarative way of updating the DOM"

Updating is not declarative.

It's React that does the updating, the programmer only writes declarative code.

> Web Components don’t offer a declarative way of updating the DOM;

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

> The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic.

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

Is that really valid ES6? Or are you using typescript

> src / ui.ts

?

......

The .ts file extension generally means TypeScript.

What about with using appendChild or insertBefore instead of innerHTML?

> * stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_...

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.

A wiser man than me once said its hard to have rational conversations on this matter because delusional people more invested in their opinions than they are in the work they perform.

> If the purpose of this article is to convince people that disagree with your statements

You missed the point. It isn't about disagreement. Its about not throwing away evidence to retain a challenged opinion. The first two thirds of the article was very explicit about this.

> when I haven't been able to find anything indicating this elsewhere on the web.

Then you didn't search very hard. The article specifically mentioned this is in relation to the web assembly host bindings proposal. The first search on any search engine brings me to the spec on github. As far as DOM work you would have to dive into the DOM string portion of JS API integration section: https://github.com/WebAssembly/webidl-bindings/blob/master/p...

If you are confused as to what the article says then submit a pull request with a superior recommendation. It is on github after all.

> You missed the point. [explanation of the point]

If it's that simple, could you consider replacing the first 1k words with this instead? I'm entirely serious.

> Then you didn't search very hard.

Okay, I'll bite. I searched for the phrase "host bindings extension to WASM" (the literal phrase included in your treatise) on DuckDuckGo, which brings me to https://duckduckgo.com/?q=host+bindings+extension+to+WASM&ia.... The first result is https://github.com/WebAssembly/webidl-bindings/blob/master/p..., a 404. If you want someone to find something so badly, link it instead of making claims about how much effort they might have put in. The onus is on you to prove the claims you make, and I wish this were something you took the time to link instead of the definition of "acquiescence".

> As far as DOM work you would have to dive into the DOM string portion of JS API integration section: https://[...]

You don't make clear which part I'm supposed to be looking at, and I don't explicitly see it stated that DOMString will be the only way WASM can interact with the DOM; there's just an example of how a WASM function might take a DOMString and return a DOMString, and how the binding machinery works in that case.

Additionally, after some additional searching, I found https://github.com/WebAssembly/function-references/blob/mast... including "Easier and more efficient exchange of function references between modules and with host environment" and information about closures. I'm not certain about it, but doesn't this run counter to your point about code running against `window.document`? After all, you could (if I'm reading this correctly?) pass in a bunch of closures that directly manipulate `window.document` through something like this.

> If you are confused as to what the article says then submit a pull request with a superior recommendation.

If I don't understand the article (you've just told me I don't), how do I help you make it better?

> If it's that simple, could you consider replacing the first 1k words with this instead?

No. I am not going to change anything because strangers online cannot read. If you have a better approach submit a pull request.

One does wonder what the point is of trying to communicate something, if the speaker does not care about whether the listener understands their message...

This can be seen in scientific papers as well as in some books.

It is based on the literacy of the powerful that we know from the dark ages. To use complex language as a substitute for easier formulations is a tool for literate people to prevent lesser educated people from understanding their texts.

Calm down, have some dip.

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.

Also I would say that the statement "The DOM is extremely challenging and working to the DOM destroys architecture" is a straw-man here, or at least a red herring.

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.

I would argue that for what the OP was discussing `textContent` (From the linked example) is very much like `innerHTML` (As it’s a safer version of the former). I’m not sure what you mean by the DOM being neither stateful or stateless, or describing an implementation of logic. Could you clarify?

The DOM is a model of a markup language instance plus access methods. State describes memory of properties resulting from a change. For example HTTP is stateless.

The DOM can be both stateful and stateless, neither, or one of. The statefulness depends on your application logic rather than any intrinsic quality of the DOM itself.

Any stateful data structure is stateless if it’s not changed. That doesn’t seem to me to be a particularly deep revelation about the DOM.

Back to your original point, that code example you linked attatches a shadow dom, creates an element in it and then puts text in it. I fail to see how that’s declarative or stateless, and AFAIK that’s the only way to populate a shadow DOM (the original HTML of the document cannot put elements there).

Ah yes, the quantum DOM.