Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

241–248 of 248 posts

Re: Web Components could replace frontend frameworks?

#241

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…

[deleted]

Re: Web Components could replace frontend frameworks?

#242
post #59
post #50

Earlier quoted context omitted.

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

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

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.

Re: Web Components could replace frontend frameworks?

#244

Earlier quoted context omitted.

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

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

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.

Re: Web Components could replace frontend frameworks?

#245
post #244

Earlier quoted context omitted.

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.

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

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

Re: Web Components could replace frontend frameworks?

#246

Earlier quoted context omitted.

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

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

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

Re: Web Components could replace frontend frameworks?

#247

Earlier quoted context omitted.

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

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.

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.

Re: Web Components could replace frontend frameworks?

#248
post #102

Earlier quoted context omitted.

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

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.

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