Web Components could replace frontend frameworks?(dannymoerkerke.com)

450 pointsby technojunkie7 anni fa239 comments

Web Components could replace frontend frameworks?

https://www.dannymoerkerke.com/blog/web-components-will-replace-your-frontend-framework

247 comments

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.

lstamour7 anni fa

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

Vinnl7 anni fa

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

spankalee7 anni fa

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.

petilon7 anni fa

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

tracker17 anni fa

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.

zwww7 anni fa

Vue already offers compiling to web components.

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

shams937 anni fa

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.

cynx7 anni fa

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

spankalee7 anni fa

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.

dmitriid7 anni fa

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

dfabulich7 anni fa

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.

pjmlp7 anni fa

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.

RussianCow7 anni fa

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

pjmlp7 anni fa

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/

RussianCow7 anni fa

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.

pjmlp7 anni fa

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

spankalee7 anni fa

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

_bxg17 anni fa

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

augustl7 anni fa

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.

madeofpalk7 anni fa

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

augustl7 anni fa

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.

madeofpalk7 anni fa

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

_bxg17 anni fa

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.

augustl7 anni fa

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

WorldMaker7 anni fa

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.

Vinnl7 anni fa

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?

supermatt7 anni fa

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.

Vinnl7 anni fa

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.

supermatt7 anni fa

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.

pjmlp7 anni fa

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

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

newman8r7 anni fa

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.

_ea1k7 anni fa

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.

jbwyme7 anni fa

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!

plopz7 anni fa

Thats what lichess uses as well.

[deleted]7 anni fa

fergie7 anni fa

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

robrez7 anni fa

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

roguecoder7 anni fa

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

kccqzy7 anni fa

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

roguecoder7 anni fa

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.

kccqzy7 anni fa

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.

MaulingMonkey7 anni fa

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!

algesten7 anni fa

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

nitrogen7 anni fa

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

kccqzy7 anni fa

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

[deleted]7 anni fa

z3t47 anni fa

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

adrianhel7 anni fa

textContent is usually better than innerText.

ravenstine7 anni fa

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.

z3t47 anni fa

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!

mscasts7 anni fa

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

dosy7 anni fa

what about slots?

lstamour7 anni fa

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

FiddlyPack7 anni fa

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

no_wizard7 anni fa

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

gedy7 anni fa

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.

ww5207 anni fa

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.

spankalee7 anni fa

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

lstamour7 anni fa

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

dosy7 anni fa

  :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

zaphar7 anni fa

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.

westbrookjo7 anni fa

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

lstamour7 anni fa

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! :)

westbrookjo7 anni fa

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.

dfabulich7 anni fa

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.

lowkeyokay7 anni fa

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

ww5207 anni fa

Shared CSS can be dealt with using @import.

tflinton7 anni fa

"declarative way of updating the DOM"

Updating is not declarative.

Vinnl7 anni fa

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

austincheney7 anni fa

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

Jasper_7 anni fa

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

austincheney7 anni fa

What about with using appendChild or insertBefore instead of innerHTML?

[deleted]7 anni fa

EGreg7 anni fa

Is that really valid ES6? Or are you using typescript

tobr7 anni fa

> src / ui.ts

EGreg7 anni fa

fron7 anni fa

......

The .ts file extension generally means TypeScript.

striking7 anni fa

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

muthdra7 anni fa

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.

austincheney7 anni fa

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

striking7 anni fa

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

austincheney7 anni fa

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

Vinnl7 anni fa

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

VvR-Ox7 anni fa

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.

lmorchard7 anni fa

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.

lmorchard7 anni fa

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.

johncolanduoni7 anni fa

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?

austincheney7 anni fa

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.

johncolanduoni7 anni fa

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

bicknergseng7 anni fa

Ah yes, the quantum DOM.

jchw7 anni fa

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

spankalee7 anni fa

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.

jchw7 anni fa

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

Vinnl7 anni fa

> And much better performance and bundle sizes.

I understand that you're the author of lit-html - would you say that the above is the main selling point of it?

BinaryIdiot7 anni fa

> It's actually particularly heavy

Huh? It's a very small API built _into_ the web browser. What's heavy about it? It's kinda similar to how JSX works just with less bells and whistles, more standard web stuff.

> It disagrees with many of the (much more popular) frontend frameworks far too much.

Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I think it enables them to have wider access to developers.

jchw7 anni fa

>Huh? It's a very small API built _into_ the web browser.

Being built into the browser doesn't make it lightweight.

I mean, if you look in terms of functions that WebComponents adds, it's a relatively small API surface. However those APIs encompass an awful lot of different functions that imo bloat basic concepts by introducing complexity into HTML elements and the DOM.

>Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I think it enables them to have wider access to developers.

I'm very much not holding my breath for that. I do think interoperabilility with WebComponents is a definite future, but thats it.

React fundamentally disagrees about what a component is. At the most basic level, React components are not DOM components, their entire DOM representation is what they render. This is not something that can be reconciled.

However should React let you export a component as a "WebComponent," via custom elements, sure, that's fine. Interoperabilility is not really notable though. It's also possible to interop React with Angular, Angular 2 with Angular 1, etc etc. Many of those are done today. In big apps. In production.

Edit: Reacts take here. https://reactjs.org/docs/web-components.html

>React and Web Components are built to solve different problems

Could not agree more, and that is precisely why no, WebComponents are not replacing my JS frameworks.

pjmlp7 anni fa

Yeah, React is pretty much anti-browser standard APIs.

Vue.js, Angular or vanilaJS are our JS frameworks, exactly because supporting Web Components is part of the culture.

acemarke7 anni fa

On the contrary, the React team has had a bunch of discussions with the Chrome team recently about adding new scheduling APIs to the browser platform, specifically to support the kinds of things that React (and other frameworks) need to do.

pjmlp7 anni fa

Were those discussions public?

Yet another Chrome specific API?

acemarke7 anni fa

https://github.com/WICG/main-thread-scheduling

https://twitter.com/sebmarkbage/status/1050782447497961472

https://twitter.com/acdlite/status/1089273195281080335

pjmlp7 anni fa

Thanks for sharing, it seems pretty much specific to Chrome.

So it is anyone's guess if this will ever land in other browsers.

Vinnl7 anni fa

> However should React let you export a component as a "WebComponent," via custom elements, sure, that's fine. Interoperabilility is not really notable though.

I don't really care about exporting my React applications as Web Components; I'm not going to re-use them inside another application anyway.

What I care about is React supporting interoperability in the sense of allowing Web Components to be used in a React application. I think that's largely possible already, but slightly cumbersome, IIRC.

I also don't really care about the other option: exporting a React Component as a Web Component. If I want to re-use a component in a different application, that's when Web Components by themselves are the right choice, and I'd prefer not having to ship React with it. Especially not once you get to the likely point where you'd want to use two different Web Components that use two conflicting versions of the same framework, or multiple components pulling in different frameworks.

Andrex7 anni fa

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

It seems to me as if you're saying:

"We don't need new complicated technologies."

"Also, we need a new, complicated replacement to the time-tested DOM."

This probably wasn't the intent but it exposes the need for web components to be built the way they are: progressively enhanced from what's already standardized in browsers. Web components really aren't that complex, and comparing them to React in this way is a disservice.

jchw7 anni fa

Yeah, the DOM the web layout engine isn't complicated at all ...

    display: block;
    display: inline;
    display: run-in;
    display: flow;
    display: flow-root;
    display: table;
    display: flex;
    display: grid;
    display: ruby;
    display: block flow;
    display: inline table;
    display: flex run-in;
    display: list-item;
    display: list-item block;
    display: list-item inline;
    display: list-item flow;
    display: list-item flow-root;
    display: list-item block flow;
    display: list-item block flow-root;
    display: flow list-item block;
    display: table-row-group;
    display: table-header-group;
    display: table-footer-group;
    display: table-row;
    display: table-cell;
    display: table-column-group;
    display: table-column;
    display: table-caption;
    display: ruby-base;
    display: ruby-text;
    display: ruby-base-container;
    display: ruby-text-container;
    display: contents;
    display: none;
    display: inline-block;
    display: inline-table;
    display: inline-flex;
    display: inline-grid;

Of course that's just CSS/the layout engine. The DOM itself is sort of unrelated. But to that effect, I'd like to mention two filesizes.

React 16.6.0 base library, minified: 6.21 kb

React 16.6.0 DOM integration, minified: 100.39 kb

pjmlp7 anni fa

Those file sizes miss the dependencies that are native to the browser.

Web Components: 0 kb

jchw7 anni fa

You forgot the polyfills.

aitchnyu7 anni fa

Cynical me saw Youtube in Chrome loading instantly while Firefox was served a build with the high parsing cost of Polymer polyfills. And starry-eyed developers importing if and for statements and writing imperative dom updates, while running some JS transpiler just like a React guy does. Never mind two major versions made Googling impossible, or debugging methods available to only geniuses.

pjmlp7 anni fa

The browsers we target don't need polyfills.

jchw7 anni fa

So you aren't targeting Safari, Edge, Firefox ESR or any version of IE?

pjmlp7 anni fa

Never had to deal with Firefox ESR, and very few customers are still stuck on IE 11, thanks to the ongoing migration to Windows 10.

Latest versions of Firefox, Chrome and Safari support all necessary features for Web Components.

tflinton7 anni fa

"I don't think we need new complicated technologies to solve the kinds of problems React solves."

Isn't web components the standard, and react is the complicated technology?

wwright7 anni fa

I think most of the rationale is around sharing components easily, at a level separate from NPM/&c. For things like JIRA/Disqus widgets, or for small components shared across otherwise disparate parts of a large site (things like Office 365).

davidjnelson7 anni fa

Curious what you think about React Canvas https://github.com/Flipboard/react-canvas

jchw7 anni fa

I don't necessarily think everything should be Canvas, but rethinking the way pages render wouldn't be a bad idea. The issue I take with Canvas in particular is that it's poor for accessibility, password managers, and other services.

I think part of the reason why the DOM and layout engines are so slow and complicated is just because of years of cruft and whatnot. A minimal layout engine with most the abilities of Flex and Grid would be nice.

dmitriid7 anni fa

We could have had it, but alas: https://terrainformatica.com/2018/12/11/10-years-of-flexboxi... (and also a comparison: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....)

BorRagnarok7 anni fa

Thank you for your constructive argument. I now know I don't need Web Components either ;-)

zarzz7 anni fa

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

Vinnl7 anni fa

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

aphextron7 anni fa

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.

yesimahuman7 anni fa

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

benforreal7 anni fa

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.

KuhlMensch7 anni fa

> In that sense, the killer app for Web Components is actually Design Systems, not SPAs.

My read too

spankalee7 anni fa

> The promise was that we could create native components without any dependencies at all

This isn't true at all, and it's a big misperception about web components.

Web components are pretty low level APIs that expose a few abilities that the browser natively has: defining a tag name, hooking into element lifecycles, creating an encapsulate DOM subtree.

Web commonness have no opinion on rendering, state management, etc. and leave other aspects, like responding to property changes, to existing features like JavaScript accessors.

It's expected that developers will use libraries to help implement web components, but the libraries won't have to implement a component model, or DOM composition, or CSS scoping. So they'll be smaller and more focused, and the overall product will be faster have fewer proprietary parts.

reustle7 anni fa

(sorry, I'm not well versed in some of these things)

Would it make sense for React to start using this native web-component at some level moving forward, to improve efficiency ? Maybe another library will replicate most of Reacts features but is powered by this native (faster/cleaner) technology?

wwright7 anni fa

afaik web components are mostly about encapsulation and semantics; they let you box up arbitrary HTML, JS and CSS and put a little bow on top so that it looks like one “custom” HTML tag to the rest of the document. (I could be misremembering.)

React is mostly about life cycles, propagation, and composition. The first two are orthogonal to web components afaik. The third has some overlap, but it’s mostly complementary with web components (once again, afaik.)

paulddraper7 anni fa

Angular has kept web component compatibility as a high priority. You can publish angular components as web components, and even leverage native functionality like shadow Dom.

colordrops7 anni fa

Shadow DOM is now supported across all major browsers.

Also, don't understand your padding comment. Web Components are style-able.

AaronFriel7 anni fa

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.

ernsheong7 anni fa

If you are starting a new project today, use LitElement. Only use Polymer 3 if you're coming from Polymer 2.

westbrookjo7 anni fa

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

AaronFriel7 anni fa

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_way7 anni fa

There exists plugin for VSCode which checks for attributes inside template literal https://marketplace.visualstudio.com/items?itemName=runem.li...

AaronFriel7 anni fa

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.

staticvar7 anni fa

Polymer is deprecated in favor of LitElement which comes with TypeScript decorators.

chmln7 anni fa

With LitElement you are still encoding markup in strings and only the interpolated expressions are typechecked [1]. Not to mention that LitElement is far more clunkier and tedious.

[1] https://lit-element.polymer-project.org/guide/start#use-lite...

spankalee7 anni fa

The lit-plugin VS Code extension provides type-checking and code-completion for lit-html temptlates. The approach can be adopted for a tsc plugin.

dmitriid7 anni fa

It’s still opaque string blobs no matter how you try to dress them up.

—-

I should probably edit this:

It’s still string blobs that are totally opaque to the browser, and that are parsed with regular expressions[1] at runtime[2] and dumped into DOM via innerHtml[3].

[1] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc...

[2] http://exploringjs.com/es6/ch_template-literals.html

[3] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc...

Ruphin7 anni fa

It's a bit disingenuous to say the templates are parsed with regular expressions. The way lit-html generates DOM Templates from strings is by letting the browser parse the string through innerHTML. The purpose of the regexes you are referring to is to find the correct insertion points for dynamic values in the template, and has nothing to do with the HTML parsing process.

There is nothing fundamentally wrong with using innerHTML to parse HTML strings. You use the same parser for the content of index.html, and I don't think anyone is advocating to replace index.html with a single script that creates these nodes using a virtualDOM type rendering system.

dmitriid7 anni fa

> It's a bit disingenuous to say the templates are parsed with regular expressions. The way lit-html generates DOM Templates from strings

"generates DOM templates from strings" <- this is what I'm talking about. lit-html literally:

- parses opaque string blobs [1]

- parses them with regexps [2]

- concatenates string chunks together [3]

- dumps the resulting string blob into DOM via .innerHtml [4]

So it does everything that was considered bad programming practices as early as 1999. And does all that at runtime.

> and has nothing to do with the HTML parsing process.

Yeah, no. This is literally parsing HTML with regexps. Because lit-html has to know whether a value is inside an HTML attribute, or inside a tag, for example. In order to know that it has to... well, parse the string that's passed to it. And what do you pass into lit-html? Oh, HTML. That it parses.

> I don't think anyone is advocating to replace index.html with a single script that creates these nodes using a virtualDOM type rendering system.

Yeah, you're apparently advocating to replace index.html with a function call that parses strings at runtime and dumps blobs of strings via innerHtml into DOM.

[1] Because tagged template literals are just function calls with lists of strings, and some values

[2] https://github.com/Polymer/lit-html/blob/master/src/lib/temp...

[3] https://github.com/Polymer/lit-html/blob/master/src/lib/temp...

[4] https://github.com/Polymer/lit-html/blob/master/src/lib/temp...

spankalee7 anni fa

Yeah, lit-html scans template strings to determine what kind of markers to join them with - comments for text expressions, {{}} for attributes. This is before handing to the browsers HTML parser.

So what? You always pop up to complain about this, like it should be some obvious fatal flaw, but you never explain why it bothers you personally so much.

Does it make lit-html slower? No. lit-html scanning + native HTML parsing is faster than native JavaScript parsing of transformed JSX.

Are lit-html templates "opaque"? That's arguable. Tagged template literals were invented and added to browsers for a reason. lit-html takes advantage of a very nice browser feature, and then hands the result to the native HTML parser, which does understand them. I'd say it's no more opaque than compiled JSX: the browser has no way of knowing that those nested function calls represent HTML, so they're "opaque".

I'm going to continue to shrug every time you complain about this until you explain why it's even bad.

dmitriid7 anni fa

> So what? You always pop up to complain about this, like it should be some obvious fatal flaw, but you never explain why it bothers you personally so much.

I pop up to complain about this because I refuse to give in to mass delusion about what tagged template literals are. Others have said it much better than I have [1]:

"...we’ve learned not to write code in strings. You’d think this would be a fundamental law of software engineering... Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimise it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it"

Edit. Found another great quote [1.1]:

"The benefits of the component as plain, non-stringified data are not the avoidance of closing tags, but what you can do with those components computationally. E.g. instrumentation, behavior/attribute injections, configuration, filtering etc. An approach based on string interpolation can only go this far, whereas having everyting as arrays, objects, iterators your possibilities of composition & transformation are almost endless..."

> Does it make lit-html slower?

The problem isn't performance, is it.

> Are lit-html templates "opaque"? That's arguable.

It's not arguable. It's a simple fact of life.

Not a single piece of the entire tech stack involved in working with them knows what they contain: not the editor/IDE, not the bundler, not the JavaScript VM, not the browser. In case of lit-html they only stop being opaque when they get dumped into the DOM via innerHtml, and when the browser attempts to parse that string as HTML.

> I'd say it's no more opaque than compiled JSX: the browser has no way of knowing that those nested function calls represent HTML, so they're "opaque".

The browser has no idea that those blobs of string are HTML until you dump them into the DOM.

However, the browser knows a great deal more about the Javascript code that gets executed in it's VM.

> I'm going to continue to shrug every time you complain about this until you explain why it's even bad.

Above are some quotes from other users that express these concerns.

I can also quote myself from elsewhere [2]:

In a language that’s already a laughing stock for its insane dynamic type system, we said: “It’s all right, we’ll have all our code in strings now, thank you very much, and we’ll make sure we parse it at runtime because what can possibly go wrong”.

The only reason projects like lit-html, HTM and some others can boast about their “accomplishments” building fast, effecient libraries is because string handling has been insanely optimised by the modern Javascript VMs. And that .innerHTML is no longer the slowest operation on the DOM.

...

Why is this bad again?

Because this isn’t code. This is literally taking a bunch of opaque string blobs, parsing them at runtime, and producing some result. All of programming has been busy moving away from coding in strings and parsing stuff at runtime. For the past few years Javascript has been happily re-introducing the worst programming practices. And devs get away with it, too, just because modern Javascript VMs and browser DOM are optimised way more than they have any right to.

...

Since these are just arbitrary strings, no common tools will be able to lint them, analyse them, optimise them unless you write a very specific tool for this particular very specific string structure. And yes, that includes JS VMs.

...

You wanted macros? Here, have run-time string concatenation and regexp parsing, and stringly-typed everything.

[1] https://news.ycombinator.com/item?id=18511943

[1.1] https://news.ycombinator.com/item?id=18052072

[2] https://dmitriid.com/blog/2019/03/tagged-template-literals/

cletusw7 anni fa

Honest question: How is React/vue/etc. different in this regard?

dmitriid7 anni fa

React is pure JS, no string parsing is involved at runtime (JSX is just function calls [1]).

Vue has its own templating language that gets compiled to function calls that are very similar to React’s [2]. I have my fair share of criticisms against Vue (as any templating system, it’s quite inconsistent[3]).

I don’t think any of them just dump string blobs via innerHtml. And I doubt any of them parse strings with regexps at runtime.

[1] https://reactjs.org/docs/react-without-jsx.html and https://overreacted.io/react-as-a-ui-runtime/ (specifically section on React elements)

[2] https://vuejs-tips.github.io/compiler/#v-else

[3] https://news.ycombinator.com/item?id=19199423

omegabravo7 anni fa

> React is pure JS, no string parsing is involved at runtime (JSX is just function calls [1]).

Why does this matter? React still eventually compiles down to DOM operations whether that be innerHTML or XML modifications.

dmitriid7 anni fa

To quote stevebmark [1]

--- quote ---

…we’ve learned not to write code in strings. You’d think this would be a fundamental law of software engineering

…

Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimize it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it…

--- end quote ---

https://news.ycombinator.com/item?id=18511943

chmln7 anni fa

Looks like there is a typescript plugin already [1], meaning this is not restricted to VS Code and should theoretically work in any editor with LSP support. That's better than I thought.

[1] https://www.npmjs.com/package/ts-lit-plugin

ernsheong7 anni fa

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

The alpha is at https://app.kanrails.com/signup. Again, it's in alpha. It is essentially a Trello + Google Forms + Workflow wannable.

How? Stick to patterns, not libraries. Check out https://pwa-starter-kit.polymer-project.org/ for LitElement starter kits. And just use Webpack, rip out the Polymer CLI. Oh, I also use Redux.

ernsheong7 anni fa

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

benforreal7 anni fa

"Stick to patterns, not libraries" - Such a simple statement, but concise as hell. It's whats been my mindset, but I haven't put it to words. Like normal DOM event bubbling is going to cover lots of use cases. When it doesn't, an event bus is crazy simple to write. A centralized data model can just be a static module. Need observables? Easy to write a simple one - otherwise there's likely a bazillion of them on npm. Not that I've used it, but it's not like Redux or MobX are restricted to React either

kansface7 anni fa

Right... why use an existing framework when you can just build your own!

wokwokwok7 anni fa

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.

boubiyeah7 anni fa

No more reason now than 2 years ago.

greenyouse7 anni fa

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

spronkey7 anni fa

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.

revvx7 anni fa

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.

winterthedeep7 anni fa

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?

boubiyeah7 anni fa

No matter the underlying technology, "lightweight, truly reusable UI components" is almost an ideologic dream, at the web scale. (some companies might achieve it on their own scale with a lot of effort, but not sure for how many years)

As the maintainer, you don't want to cave in and add every possible configuration option people ask for so you have to decide what's a good, thin API for your component and it will never be enough for some usages. Styles are that much more subjective and even vary with design trends over the years!

It might be possible for very, very simple components like text inputs but then again, those are also the simplest to code directly in your framework, so you could wonder, why bother with an inferior programming paradigm in the first place?

The sweet spot for web components really seems tiny.

benforreal7 anni fa

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.

winterthedeep7 anni fa

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

benforreal7 anni fa

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)

zarzz7 anni fa

As others have already answered styling into Components is still hard, but there are answers coming soon with part/theme and Scoped Stylesheets.

Also, ZephJS, the Web Components library I am championing, has the ability to inherit from another ZephJS element which allows one to add to or even completely replace the styles for the new element without any special css magic. So if I want to style <acme-text-field> I simply inherit from it in my new <my-text-field> and I can style however I want.

https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...

winterthedeep7 anni fa

ZephJS looks cool, will try it soon. Thank you!

fbn797 anni fa

Web Components are an anti-pattern

EtienneK7 anni fa

Please expand on this point?

mmckelvy7 anni fa

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.

threeaccents7 anni fa

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.

westbrookjo7 anni fa

You might be interested in https://github.com/bennypowers/stripe-elements Stripe v3 with Shadow DOM.

threeaccents7 anni fa

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.

westbrookjo7 anni fa

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_inflator7 anni fa

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.

ramon7 anni fa

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.

anthonyshort7 anni fa

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.

yesimahuman7 anni fa

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.

anthonyshort7 anni fa

I can imagine a world where this would be useful, being able to drop something in as easy as a <select/> element seems fine.

It seems useful for UI primitives, like a dialog, tooltip etc, that the browsers might not implement as native elements themselves. But as a building block for creating entire applications? I don’t think so.

Which means they’re always going to need to hook into the framework that’s rendering them, either to connect state, managing effects, or for styling.

I just don’t see sharing a component regardless of framework as a major problem worth solving right now. Buy into a framework and community like React and you can just drop components into your app. It’s not framework-agnostic but it works.

hesarenu7 anni fa

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

cletusw7 anni fa

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

dmitriid7 anni fa

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

ravenstine7 anni fa

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.

rovyko7 anni fa

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/

Andrex7 anni fa

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

westbrookjo7 anni fa

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

threeaccents7 anni fa

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/

rhacker7 anni fa

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.

ernsheong7 anni fa

You can use Typescript with LitElement https://lit-element.polymer-project.org/guide/start#use-lite...

thosakwe7 anni fa

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.

ernsheong7 anni fa

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.

staticvar7 anni fa

The lit-element package comes with typescript decorators.

ricardobeat7 anni fa

As expected, no mention of server-side rendering.

JackuB7 anni fa

This was exactly the reason I’ve abandoned them. As mentioned in other comments, they look like a good way to create a design/component system in them, because of the interop with any frontend JS framework (who doesn’t want that?!). So you deal with clunky CSS sharing and theming capabilities and there might be some solutions on the horizon. But now you want to build a static website with it (landing page, docs, blog…) and you can’t pre-render them, because there is no declarative Shadow DOM element https://github.com/w3c/webcomponents/blob/gh-pages/proposals... (rejected https://github.com/whatwg/dom/issues/510). Yeah, you can pre-render them without the Shadow DOM. Then if you want to make those chunks of HTML into WCT on load (sort of rehydration), it will trigger repaints, as you have to remove the chunk of HTML, put it into WCT and parse everything again. Or you don’t put it into Shadow Root, to prevent repaint - but at that point, if your components can work this way, why even use WCT?

westbrookjo7 anni fa

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

georgecalm7 anni fa

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.

westbrookjo7 anni fa

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.

pjmlp7 anni fa

Server-side rendering should be JavaScript free and done in battle tested framework (TM) since the early 2000's, plenty to chose from.

sergiotapia7 anni fa

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-Ox7 anni fa

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.

founderling7 anni fa

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.

colordrops7 anni fa

There are html "includes" in Chrome, used as such:

<link rel="import" href="/path/to/file.html">

But alas, Google was not able to convince other browser vendors to adopt them, and they will be removed from Chrome 75.

zarzz7 anni fa

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

B

founderling7 anni fa

    It’s clean and simple

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

zarzz7 anni fa

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

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

founderling7 anni fa

    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?

Hurtak7 anni fa

Because that would cause cascade of tens or even hundreds of http requests just to download the html.

On the other hand new JS modules work like that, this is less of a problem on http2 and also can be mitigated by tooling.

tobyhinloopen7 anni fa

Frameset / iframe?

galaxyLogic7 anni fa

You are right. IFrame creates an almost but not totally isolated page-environment. So in a sense IFrames are 'web-components".

So what can Web-components offer over that? A simpler way of including them on a page with a single tag. Well, you must load the js-file too but a single js-file could contain multiple web-components I assume.

The whole (?) point of components is isolating the interface from implementation, encapsulation, which WebComponents does nicely by providing a standard way of writing methods of the underlying ES6 class.

We could say that WebComponents are smarter IFrames with a cleaner way to declare their interface.

Another great thing about WebComponents is extending existing tags which makes it easy to prototype improvements to existing tags. For instance I wonder if IFrame could be made better by creating a web-component that extends them?

deanclatworthy7 anni fa

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.

ssorallen7 anni fa

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.

irenkai7 anni fa

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

jaunkst7 anni fa

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.

westbrookjo7 anni fa

Even from the beginning of Polymer and it's use of HTML Imports there were tools for bundling them and they worked great! It's even easier to find the right tool for you now that ES Modules deliver the power of web components with the help of your favorite Rollup or Webpack configs and plugins...

https://open-wc.org/building/

rossy7 anni fa

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

jaunkst7 anni fa

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.

blablabla1237 anni fa

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.

zarzz7 anni fa

Allow me to float ZephJS at you as an example of a Web Component framework with a bundling tool to do what you describe. Simplifies everything about building Web Components.

Introduction: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...

Bundling specifically: https://github.com/awesomeeng/zephjs/blob/master/docs/Compon...

IggleSniggle7 anni fa

This looks pretty cool, thanks for sharing.

Blackthorn7 anni fa

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.

galaxyLogic7 anni fa

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

westbrookjo7 anni fa

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

galaxyLogic7 anni fa

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

pier257 anni fa

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.

zachrose7 anni fa

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.

namelosw7 anni fa

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.

revskill7 anni fa

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

galaxyLogic7 anni fa

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.

jasonkester7 anni fa

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.

johankmagnusson7 anni fa

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.

Aeolun7 anni fa

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.

hyperpress7 anni fa

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

Aeolun7 anni fa

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.

hyperpress7 anni fa

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.

galaxyLogic7 anni fa

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_bx7 anni fa

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_religion7 anni fa

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

Spivak7 anni fa

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.

iliaznk7 anni fa

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__7 anni fa

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

bandy0087 anni fa

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.

[deleted]7 anni fa

mikeytown27 anni fa

CMS static site builder based off of Web components https://github.com/elmsln/HAXcms

bobske47 anni fa

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

Const-me7 anni fa

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?

sbhn7 anni fa

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

[deleted]7 anni fa

kentbrew7 anni fa

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

[deleted]7 anni fa

OnlyRepliesToBS7 anni fa

sbhn7 anni fa