Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

41–50 of 248 posts

Re: Web Components could replace frontend frameworks?

#41

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` .response { margin-top: 10px; } I like web components. Web components like you, too. `; } Cool.…

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

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

Re: Web Components could replace frontend frameworks?

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

Re: Web Components could replace frontend frameworks?

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

Re: Web Components could replace frontend frameworks?

#44

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 eve…

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

Re: Web Components could replace frontend frameworks?

#45
post #32

Earlier quoted context omitted.

> 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 repl…

What about with using appendChild or insertBefore instead of innerHTML?

[deleted]

Re: Web Components could replace frontend frameworks?

#46
post #42

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.

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

Re: Web Components could replace frontend frameworks?

#47

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

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

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

Re: Web Components could replace frontend frameworks?

#48
post #20

Earlier quoted context omitted.

what about slots?

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

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.

Re: Web Components could replace frontend frameworks?

#49

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

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.

Re: Web Components could replace frontend frameworks?

#50
post #42

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.

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.)
Post reply on HN