I'm a generalist web developer with my hands in a few libraries.I don't consider myself a purist or evangelist of any technical approach, especiall...
For further actions, you may consider blocking this person and/or reporting abuse
A few quick points from my perspective. (I work on React.)
We're not opposed to supporting web components better. The problem is that there's no single "web component community". There are multiple subcommunities. You mention "web component libraries" in the post. These libraries don't agree on a single standard so React would need to pick a side in debates like "how does server rendering work with web components". Whatever we pick will have large downstream effects, and our reluctance to support more has to do with being careful (see [1] note below) about the semantics — not somehow being at odds with web components per se.
As I mentioned in the previous point (and you mentioned in the post), there are multiple "web component libraries". As far as I can see many of the criticisms of React would apply to such libraries as well. I don't think the way to counteract "DOM FUD" is to introduce "library FUD". If you're using a library for defining and updating your web components declaratively, you're not following a conceptually different approach from using React.
Saying "you can do everything with WCs that you can do in React" is double edged. Yes, of course, you can do anything — because we haven't actually agreed upon any constraints. If the constraint is "you don't use a React-like library on top" I think you'll find there's plenty of things that are very hard to do with an imperative abstraction like vanilla WC APIs. We've done a few talks about what using React as a unifying abstraction lets us do (such as non-blocking rendering, or dynamically loading UI code without degrading user experience). You might want to check them out (youtube.com/watch?v=nLF0n9SACd4, youtube.com/watch?v=ByBPyMBTzM0). Of course, you can do these things if you use a library like React on top of WCs. But that negates the argument that you don't need React-like libraries for this.
To sum up: we'd be happy to support WCs better in React. We don't want to rush it, and want to make sure this support is well thought-out. Additionally, we believe there are many things that raw imperative WC APIs don't give you — and for them something like React would be appropriate even in a WC world. Finally, there's this myth going around that once you write React code, you can't reuse it as web components. That's not true — and as you can see from the documentation it's a few lines of code: reactjs.org/docs/web-components.ht...
Hope that makes sense, and provides some additional context!
Hey Dan, thanks for dropping by 👋
Totes. It's pretty frustrating trying to compare the advocacy efforts in the wc community with what your team is blessed with. Then again, there's no "querySelector" community either. Open standards might not be sexy but they make the world go round
They agree on at least two: the HTML spec and the DOM spec. Those are the standards we're working with. I appreciate the React team's need to consider platforms beyond the web, and I'm grateful that's not my concern at the moment as a web developer, since that sounds like a hard problem. But server-side rendering is beyond the scope of the question "what should be the web's component model" in my humble opinion.
As far as I've seen (and this is as a developer/user, not as a library author or community manager) the difference is about how to apply the concept of components. Should we use a bespoke all-js solution, or agree on standards for things like component model? Then, it's about how much code we're adding on to the web APIs. Justin Fagnani had an interesting hot take on this in the Polymer Community Slack
Actually in the same thread, that same Justin sort of preempted your next point:
To loosely paraphrase - Now that we have the DOM API, we don't need jQuery, but we still sometimes need libraries like jQuery. The low-level WC APIs are best used by library authors. There might be some simple cases (like a
<lazy-image>element) that are best implemented and shipped with bare-bones browser APIs, but in most or almost-all cases, it would be better to use a library.Amazing
Sure!
Totes. I'm not sure that's even a debate. For me, that "something like React" is the option which lets me hit save then reload without any intervening tools.
I Hope the interop promise of web components lands in the massive react community soon. In the mean time I'll be declaratively defining reactive templates in LitElements et. al., and running them without babel, webpack, or any other tooling (unless I decide to bring them in as nice-to-have optimizations)
Thanks again for stopping by, it's great that you decide to add your voice to this discussion. 😊
Not quite sure what you meant by this, but I'd like to emphasize we don't currently have developer advocates working on React web. People you might talk to on Twitter are just JS engineers who happen to work on it and like open source.
Maybe. It's in the scope of "how to write a performant application" though, which is why a lot of people care about it. Since it's in the scope of what React does (and perhaps holistic thinking like this is part of the reason people don't hurry to ditch React), we need to consider any decisions there very carefully — especially because they impact the web component communities too.
The same goes for all other things we consider our concerns (such as dynamic loading of UI code). They might not be low-level enough to be in the spec, but we think it's much easier to write product code when the component abstraction is aware of them. Which is why we think it's worthwhile to keep working on React.
Overall it doesn't seem like we disagree on many things? I wish these discussions were less polarized in general, as they keep being about how we need to ditch one and use the other whereas the tools are more complementary in nature. My personal impression has been that web components solve organizational problems more often than technology problems (e.g. how to share UI between teams that don't want to agree on a library). But those absolutely are valid problems, and it's great if we can have solutions to both spectrums.
Cheers!
Yup
100%
My spidey-sense is tingling. The React team isn't the w3c or the whatwg. Big questions that affect the future of the web should be the purview of standards bodies, not library authors. I'm not against awesome JS that makes things work in lieu of agreed-upon standards, (and let me take a moment to praise your team for their technical accomplishments) but we have a standard component model now - one that's not just theoretically standardized but also universally implemented (!RemindMe 6 months or so when Edge releases support).
It happens to be that I prefer not to use React because of VDOM and JSX, which for my use cases are in my (very) humble opinion overengineered. I like hitting save and reloading. I like inspecting a custom element and seeing its DOM properties in the JS console instead of some custom dev tools plugin. I like working without source maps (and if I had my druthers lit-html would be written in JS not TS 😉). I like standards and I like the web. I don't like it when people think that "web developer" has to mean "react developer"
My main issues are that React's success has made babel and webpack de rigueur requirements (I just spent an hour with a mentee unscrewing babel for a one-file 700 LOC react js script for a wordpress site. Madness!), and that a lot of the advocacy for react has come as mud slinging against standards (and I hope it's clear that I'm not pointing the finger at you personally))
This is precisely my point. I think you're both asking that we do implement a tighter WC integration, and also that we don't make any decisions about how it should interop with React (and thus impact questions like server rendering). These are mutually exclusive requirements. And they're the reason we haven't historically been hurrying with this despite efforts like custom-elements-everywhere.com/.
Re: Babel, fair, although you could use it as a JSX-only transform if you don't care about newer JS features. React doesn't force you to use ES6. I found it curious that people who complain a lot about JSX tend to also love SASS — which, if you think about it — is a transform just like JSX.
Re: webpack, this has nothing to do with React. People use it because they write more complex apps, and shipping them as a single bundle without code splitting (or as ES6 modules!) hurts the users. If you don't need bundling, you can use React as a script tag and not do any bundling: reactjs.org/docs/add-react-to-a-we...
Let me know when you see it and I'd be happy to chime in! I've also seen a lot of unjustified stabs back at React which doesn't help either.
Can't believe im about to be 'that guy' on an internet forum saying this, but im running out of fingers to count the times I've shook my head after seeing a "use the platform LOL" jab from the React community.
Having said that, I really do appreciate the sentiment of your comments in this thread, and you taking the time to engage in (what feels like an actual fruitful) discussion!
So now that we've established this, perhaps we can all slow down with the mud throwing a bit?
It's a weird situation. As Benny mentions it's a false dichotomy. Sort of. I can write Web Components or React Components, and Web Components can be used in React apps/components, but I still need React or something to "orchestrate" the app, namely data flow and app logic. Using a Web Component base element like LitElement is basically choosing a framework that makes components built with them as reusable outside of that framework as React components. This makes me think we may even see more incompatibility between components as Web Components ecosystem develops.
So when I ask, Should I start building Web Components? I don't even have a good answer for myself. Clearly I'm interested in them, but pragmatically there isn't a big enough general draw to invest in them. Plus I'm doing stuff with WASM and a lot of this gets thrown out the window.
A different question is, Should I use Web Components that have been made? Yes, if they're good enough. There doesn't seem to be a ton there yet though.
litelement components are reusable outside your app, if you write them to be. If you write them dependent on your app, they will be, but they don't have to be. The point is that you can write reusables and have them run anywhere, which you can't do with frameworks.
also, the notion that 'wcs need some framework to orchestrate them' is also applicable to react, since it's just a view layer as well.
You can absolutely write a reusable React component that's used in non-React apps.
We even have an example of this in the documentation (using web components :-):
reactjs.org/docs/web-components.ht...
It's a few lines of code.
but you can't npm i some useful react component and use it in your non-react app (or if "can't" is the wrong word, "probably won't ever")
whereas I can
npm i -S @polymer/paper-input @vaadin/vaadin-gridand use them in my Vue app, no problem.Maybe I'm wrong about that, and I hope I am, but I think it's in line with the general sentiment out there - apps are either vue apps or they're react apps
You can definitely do that if you want to.
For example: npmjs.com/package/web-react-compon...
That sounds more likely. But is it because it's so difficult? Or because using a declarative library lets component authors come up with more natural and expressive APIs instead of catering to the imperative lowest common denominator? I think it's the latter.
Cool package!
I think that his comment is just too harsh on React. Yes, it is the most popular library to code web stuff right now, but we all know where was Angular a few years ago, and Meteor and Ember before it. Libs/Frameworks come and go, and that usually happens with the web itself evolving and making easier to create stuff without framework overhead. In my opinion, React will embrace Web Components as soon as we start to see professional and big web applications created with WC because they have a similar ideology. There are a few problems remaining to be solved as WC are using custom HTML tags and as @benny mentioned a different approach to handling browser events.
After reading his comment, a reader might get the opinion that React is slowly dying, but React will not go anywhere anytime soon (MS is rewriting Skype in React, and XBOX will use React Native, among other stuff happening in React world) :) I've taken a look at WC and they are still not ready for production, but it's a very good thing to know nevertheless, who knows when you might need it :)
There are plenty of big sites out there using wcs. ING, wego, ea, others. Every McDonald's menu runs Polymer. People cite the youtube thing, but youtube is using the v0 specs with polyfills (soon chrome will also require polyfills for those old deprecated specs), so when people point to yt and say it doesn't work, it's a straw man (see my original comments)
How come I don't see more articles about WC then? Where is WC community? Does it have some sort of ecosystem of packages and utilities?
For now, it seems just like some niche tech like Haskell, Dart, Elm, and Clojure, everyone is talking about them and admire them but I haven't seen a single practical use in production applications except for a few exceptions. Companies and corps are usually going after something that is battle tested, and once WC are battle tested with a bunch of really good examples, I'm sure we will use a new framework based on WC as usual.
That's what I came up with just off my fingertips. But also, when was the last time you attended a
querySelectorConf?so I'd like to suggest that the reason you don't see more is because you're not looking hard enough ;)
To be fair, my oft-repeated complaint in the Polymer Community Slack is that not enough resources are being directed to advocacy and community building. Lately I've been hearing subterranean rumblings that the situation on that front might improve.
I think the point was about "niche" not existance as such. Although there might be a ton of resources out there, I too believe it is not - let's say - well marketed.
On the other hand, I see this fruitful discussion as an opportunity for me, to take a look at what exactly WC are - if that was intended: mission accomplished 😄
I have a dark fuzzy image of it which eventually needs some details.
But anyway: the point of not having a querySelector conf is, that I suspect it being common shared knowledge in contrast to not so common knowledge about WC.
There are plenty of resources about WebComponents. Nearly none of them are about WebComponents though. They are about Polymer. Or Stencil. Or lit-html. Or...
There's a Polymer summit. I don't think there's a Web Components conference.
It's probably the first time in the history of web standards that the new "use the platform" and the new "use the APIs" are rarely if ever mentioned in any of the resources dedicated to them.
People keep mentioning jQuery. However, as the platform develops, there's less and less need for jQuery (querySelector, fetch, etc.). The platform developed to include WebComponents, and they somehow don't reduce the need for libraries. Instead, they all but require libraries to be even remotely usable.
Yeah React has been great for me and has served me well in multiple different projects. But if you're telling me there's a standard spec that works cross-browser, I'll 100% go with the standard instead of a library.
I ditched jQuery a few years ago.
I'll probably ditch React too.
As an employee I'm very familiar with front-end libraries and frameworks and I use them everyday (because I have to and that's how I get paid, I work on a team after all). As a developer I have an increasing disdain for these front end shiny things. I like learning how things work and how to make things. I have no idea why everyone is so obsessed with "there's a library that does that for you!". Am I the only person that actually enjoys making fast, responsive custom UI's from scratch? Am I the only person who wants to figure out what a library is doing so I can code it myself? I got into web/app development because it is enjoyable to make this stuff. Not because I wanted to get great at installing libraries that do everything for me...
Also, most large front-end frameworks are amazing. The people behind them are geniuses and the work they do is incredible. But I've personally seen, that even at an enterprise level, these frameworks simply are overkill. Most web apps being built with them could have been made with virtually nothing front-end wise but html, css and javascript. These frameworks are so robust I would compare them to a sports car/monster truck/space rocket. If you need launch off to a new planet and drive around on the surface, bingo! But if you need to get milk from a grocery store, just hop on your moped...
Business requirements ≠ the trendiest/ most hyped up tech being thrown around...
Having said all that. I move away from React/Angular/Vue and write vanilla web components every chance I get! I love'm and they are the future.
Jquery is dead. Long live Jquery...
I think web components are the future, but sadly not the present.
I read, Google switched many of its websites to the new Polymer framework, and they became unusable with Firefox on MacOS. I'm going to use the platform when it's finally usable until then it's React for me.
Also, React plays a much bigger game than being just a front-end framework for the web. While the web is still the most significant chunk of that game, there are many more platforms the React team has in mind when planning.
I don't know what the future brings. Some people say hooks are one step on the way to make React web components ready in the future, and the React-Native team works on opening their platform for other frameworks, like NativeScript did. Maybe React-Native will stay in the game, but with something different on top, who knows.
Yeah, these read as contradictory to me
"Intent to ship" means "not currently supported." I've been hearing about how web components are right around the corner for the entire time I've been paid to write React code.
I don't disagree with the premise; web components are likely to be a superior implementation for the "leaves" of an application. Buttons, dropdowns, checkboxes, etc, would be much easier to use if we could do
<custom-checkbox onChange={handleChange} />within React.The YouTube performance/stability problems that I saw demonstrate to me that they're not truly usable yet, though, and I have concerns that they'll be outdated and difficult to use by the time they're supported across all modern browsers. The can I use page for them says to me that it's still a long way off.
It should be no surprise that React will not outlive our careers. WebComponents are simply providing the ability to create composite elements AFAIK. I tried it back in 2012 and it was too soon to switch to it. I amost subscribed to polymer and thankfully it wasn’t ready for prime time.
People are still using jQuery even though browsers support those features natively. Yes, even jQuery will succumb to the advent of the web. It is our job to stay up to date. When the time comes, React developers will adapt. The library is still evolving as it is. Facebook developers will think this through.
What problems do you think they're solving? And better solutions for what?
For scoping CSS? Shadow DOM is the ONLY solution that provides both bottom up and top down style encapsulation.
For extending HTML? React components only work in React components; not in HTML.
For application orchestration? Web Components don't and aren't trying to solve that.
Great choice of topic and great discussion! I'm learning such a lot just reading the comments.
Just wanted to show appreciation for the good conversation about the current state of things, above all, respectfulness as shown is the way to go.
BTW, in case it comes handy, there is an open standards initiative based on GitHub I started over at openstandards.guide
One could say that there is an opportunity to create a new library that comes in par with React that has Web components as first class citizens.
I do think Stencil comes closest. I personally do a lot of React and Stencil development and Stencil is very close to react from a developer experience, and can be made even closer by using function components and the like. Of course, I'm biased, but given that was a design goal of ours I am happy at where we've ended up there.
Personally, I want to see Stencil get support for hooks and even stronger function component story, but there are trade-offs given that you need a Web Component initial component as a host (not required for most of your components, however)
Stencil ?
Nope.
It seems to me that the WC community is also completely missing the point with React. For those who build static non-responsive web pages based on interactive components, there is probably no reason to use React at all. You could just as well use WC. However, for those who wish to build the dynamic pages of the future, there is certainly a need for the likes of React.
So what is React? It seems to me that this article completely misses the point on that. React is not just a way to define static components on a website. React is foremost a way to constantly and dynamically rebuild those components, without loosing the state of some components mind you!
So, react and the synthetic DOM comes to use when:
And this is the whole point with the synthetic DOM, whether you like the (slight?) performance penalty or not.
The whole point with React, is that you can write your code, without concern for how all the components will be updated/relocated and moved once the dynamic user interface updates.
And as far as I can see, WC has no solution for this whatsoever. WC is just a way to isolate and package components, but WC in itself offer no coherent and thought out methodology to rebuild and rearrange those components.
So, if there is a resistance from the React community, in adopting WC... think again. Perhaps there is a valid reason for it.
And, it is also my guess that many of those who fail to se value in React over WC, probably never built very dynamic user interfaces.
I remember the old saw about "alternating hard and soft layers". React and WC are exactly that. WC provide the "hard layer" basically an extension of HTML as a platform. React is the soft layer we use to assemble the WC into our working applications. Think C components, plus Python. Or C++ COM and Visual Basic.
The only problem is that React and WC do not interface very cleanly for events, or properties. Once that is fixed it's going to be a great combination. Just wish the React team would put more a higher priority on that.
Caleb, if you want save and reload for React you might try using ES6 imports and HTM: npmjs.com/package/htm. HTM lets you use ES6 template literals that resemble JSX sort of. I've used it with Preact. You literally skip the build step. You do need to run a server instance in the project to run the page in the browser so that ES6 imports work in the browser. Since this works with Preact I'm assuming the same thing would work with React.
Here's a live demo of Preact using HTM running in the browser without a build step: htm-demo-preact.glitch.me
Can't believe I'm just now seeing this, but it is what it is. In case any one else stumbles on this conversation, what I'm talking about is native custom event binding. In React, you pass down handlers through props:
<my-el onClick={whatever}></my-el>, but that requires React's synthetic event system to know what your event name is (which it can't the way it's currently architected).In Angular and Vue you can bind using the
(event-name)="callback"orv-on:event-name="callback"syntax. LitHTML or LitElement use the@event-name="${callback}"syntax. There's currently no way to declaratively process non-native events using React/JSX and that's what I need.I've recently started working in a large scale project with webcomponents after some PoC with polymer 4 years ago.
I use to be fw or lib agnostic as much as possible but honestly, last 3 large scale project where I have worked on were made in react because of many reasons that are not part of the discussion, it's just to give some context.
My humble opinion is that the WC still not ready to be used, there are not a properly defined way to get the list of attributes, attributeChangedCallback doesn't work in some cases even if I'm using just a line of code and some other little painful staffs.
I loved the webcomponent concept when I read the first article mentioning that years ago, but again, after several years, doesn't seem to be ready to be used at scale.
On the other side, if some issues will be resolved, I would like to check it again together with React or something else limiting WC to simpler visual components. I think that orchestration and state management it's not its best and I still prefer to use something more mature and reliable (that doesn't declare props in the wild in the main object for example).
Is my humble opinion, I don't want to blame WC, and by the way, I don't have the same experience with WC that I have with other libs like React or Vue so, maybe I miss something but by far, WC is requiring to my team (the entire project have more than 140 developers, but the teams are splitted into units of 4 devs with bounded and independent scope) more time and requiring more effort to make a simple package (composition of components and logic) to work than any of the two above.
You are forgetting a very important problem that React was intended to solve... That is excessive DOM manipulation with native javascript. You can say WebComponents are good and well supported and safe, but you can't say that the devs implementing the web components are any more knowledgeable about DOM bottlenecks than they were 5 years ago. React only updates the DOM when necessary. Remember when we had monolith front-ends with jquery, and every piece of javascript having a slice of the DOM pie? How is WebComponents gonna solve the problem of batching and optimising DOM reads/writes on a monolith codebase?
lit-html provides a good example of how to solve that problem in a way that works well within a Web Component context: From npmjs.com/package/lit-html/v/0.2.1 :
lit-html's method of creating HTML templates with markers for dynamic sections, rather than updating the final DOM tree, enables efficient updates of previously rendered DOM
First time I've heard "use the platform",
I thought everyone is using it, no? Perhaps they meant use the platform More?
As I have learnt later, what they actually meant was -
"Use the new features that are not shipped yet and mostly supported only by Chrome, so use the Chrome, and polyfill for everyone else".
But in light of recent news with Edge moving to Chromium stack,
"Use the platform = Use the Chrome"? Coincidence?
Even though they might be right in a longer term, but in short term, businesses that have invested in those ideas, probably are downshifting now.
I haven't seen anyone actually benefiting a lot from webcomponents reuse, mixing them inside of their applications with other frameworks, since most webcomponents libraries provide means to make a framework around them, just add Redux, and don't look around, you are using platform now.
Microfrontends architecture articles encourage use of webcomponents. But you can't have custom elements defined twice in the same page. I know that message was that you isolate your microfrontend, not use it to build everything. But message was picked up wrong by many.
I may have sounded salty, its just because I just have invested a lot in platform, I hope it will pay off one day, React's support will definitely help.
And lets wait for webassembly to replace javascript, lets see what use the platform will mean then:)
The reason why webcomponents are not successful:
the majority of "web developers" are not programmers.
They do yoga, they are vegans, they copy-paste code, they are gurus
Note: Safari does not plan to support the
is=''thing anytime soon, or ever.