4 ms·

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

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

jchw 8y ago
>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 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.
- pjmlp 8y ago
  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.
  - acemarke 8y ago
    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.
    - pjmlp 8y ago
      Were those discussions public? Yet another Chrome specific API?
      - acemarke 8y ago
        https://github.com/WICG/main-thread-scheduling https://github.com/WICG/main-thread-scheduling https://twitter.com/sebmarkbage/status/1050782447497961472 https://twitter.com/sebmarkbage/status/1050782447497961472 https://twitter.com/acdlite/status/1089273195281080335 https://twitter.com/acdlite/status/1089273195281080335
        pjmlp 8y ago
        Thanks for sharing, it seems pretty much specific to Chrome. So it is anyone's guess if this will ever land in other browsers.
- Vinnl 8y ago
  > 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.

jchw 8y ago

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

pjmlp 8y ago
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.
- acemarke 8y ago
  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.
  - pjmlp 8y ago
    Were those discussions public? Yet another Chrome specific API?
    - acemarke 8y ago
      https://github.com/WICG/main-thread-scheduling https://github.com/WICG/main-thread-scheduling https://twitter.com/sebmarkbage/status/1050782447497961472 https://twitter.com/sebmarkbage/status/1050782447497961472 https://twitter.com/acdlite/status/1089273195281080335 https://twitter.com/acdlite/status/1089273195281080335
      - pjmlp 8y ago
        Thanks for sharing, it seems pretty much specific to Chrome. So it is anyone's guess if this will ever land in other browsers.
Vinnl 8y ago
> 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.