It's true that React doesn't let you build web components. React does not use or polyfill Custom Elements or Shadow DOM.
It's also true that React is "monolithic" in the way that other frameworks are: they don't naturally interoperate, or do by cumbersome adapter libraries that require wrapping widgets and marshaling between data-binding techniques. They interfere with normal DOM usage, and tend to break if other code modifies a component's DOM (granted Shady DOM has made this trade off temporarily), and they aren't "just elements" - getting a node controlled by React out of the DOM doesn't get you the component itself, no useful API is added to the node.
You simply don't see many applications that mix and match React, Angular and Ember because of this. This Polymer difference is that it's deigned to help you create "just elements" so that they're interoperable with other frameworks, plain JavaScript or just HTML. Users of Polymer elements should never have to know that they were made with Polymer.
Needing to use Shady DOM APIs is an unfortunate exception to this, but an site can choose to use the full Shadow DOM polyfill if the performance fits their needs.
Well... Despite Polymer's repeating of "use the platform", I always felt React used the platform far more than Polymer. In the end, React is just a way to structure an application that generates and manipulates regular HTML. In other words, you can use shadow DOM and custom tags just fine. If the browser supports it, that is - and if you've used Polymer since before Web Components were standardised (HTML Imports still aren't and will never be), that was a major downside, and the opposite of light-weight.
First, I do dabble in frontend dev but I'm more of a backend person. I never used React and briefly played with Polymer 2.
Shadow DOM and custom tags make it possible to closely mimic the way we used to do UI development back in the Delphi/VB6 era. I like how eg. css properties only apply to a given component.
Polymer seemed like the most lightweight possible way to implement this because it uses the browser facilities. I understand that React also has components and custom tags (JSX) but it doesn't use browser facilities but rather implements them itself, which just sounds like the wrong way of approaching the problem.
I’m not sure what your point is. React components can use Shadow DOM if they want, but they don’t have to. Neither do Web Components. React components can be rendered to DOM nodes, but they can also be rendered to lots of other things.
I use Polymer at work quite a bit, and its really nice, but it's a completely different approach based on trusting that the DOM is sane and running as close to web standards as possible.
React and its 1 billion clones run off of the assumption that the DOM API is not to be trusted, and that lets you target more browsers, even non browsers. I mean have you ever tried to get Polymer stuff to work in Firefox? It's not Pretty.
Polymer includes a Web Components polyfill, so you can write raw Web Components if you want to. Polymer is really just some syntactic sugar over that (and other specs thrown in, like html imports, templates, etc).
That said, these aren't really the same kind of libraries at all, so I'm not sure why this is such a x vs y thread. Ideally, react and web components are fully composable, and it doesn't really matter where the element came from.
I dunno, I'd rather use "vanilla" React/Redux/JSX than try and get those tools to fit with custom elements, shadow DOM and the html import/template stuff.
The web components specs look poorly thought out to me. They seem superficially like good ideas, but when you actually bother to build something with them you hit the rough edges and missing pieces. I do not appreciate that Chrome rammed them unilaterally down our throats, or that their Polymer evangelists continue to flog these technologies as though they are somehow an answer to the vast majority of problems web developers face.
I'm on the Polymer team, so admittedly biased here, but I don't understand your comment about Polymer minimizing reusability.
Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.
Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.
My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.
This example shows how cumbersome the DOM APIs and their limitations are. Also, React is not _just_ DOM diff-ing. It also provides a host of other benefits... some of which are both shown here and covered immediately in the next set of examples with Polymer's kinda-templating-language.
You cannot buy into Web Components without buying into at least Polymer to supply you with data binding.
If you don't like React's size, there are slimmer options: Inferno, Preact etc.
(Speaking as someone who worked on the Polymer team for a year, and has been writing React at a separate job for roughly half that)
> The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components.
Web components have pretty much the same levels of composability as React, but have promise for even more. The main reason I say this is that the components specs attempt to formalize a surface area for all web webcomponents libraries to interoperate with each other - though we're not to that point yet.
Many of the Polymer core components are a great example of composed elements (sometimes overzealously so). Shadow DOM and insertion points (<content> or <slot>) do wonders for this. (Yes, Polymer 1.0+ backs off from this a little bit)
React really only composes well with elements written in React. It can talk out to native components (and custom elements), but it's awkward enough that you tend to build wrappers to expose a more React-y interface (value, onChange, etc).
---
> I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;)
Assuming that you want these inline frames on a per component basis, we're talking about a ton of overhead per component:
* A new JS VM context (for the sandboxed global and security mechanisms)
* A new render layer (and the the synchronized painting you mention)
* All the other browser bits that would need to be built up
---
DOM is a problem, but it's not the biggest problem, and performance-wise, there have been tremendous improvements in the last few years (Try running your benchmarks again).
However, imagine a world where all elements are defined with a set of public APIs like web components. No more crazy special cased properties, magic methods, etc. Imagine how much cruft the browser vendors could remove from the DOM. Imagine how much faster things would be.
Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.
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.
I actually implemented React's UI Router in polymer, works the same as in Angular 1/2. The biggest issue with web components in general are problems with Shadow DOM support.
Which means you need to do elements without shadow components up to top level - that is indeed annoying and reduces the pros of components.
A "web component" is some stand-alone combination of HTML/CSS/JS that does some thing. It should not conflict with the application that uses it in any way. It should, however, allow the application to communicate with it (to modify its state) and to potentially change its appearance in a way that will not break the component.
A problem with HTML/JS/CSS pre-shadow DOM is that it was impossible to actually build a component as described above. There was no way to sandbox the HTML/JS/CSS that's used to build the component from the application. There was always the possibility for contamination.
What the specs that Polymer is intended to polyfill permit is a combination of this sandboxing capability along with other means of permeating this sandbox with the functionality needed for such sandboxed components to be truly useful (how useful is something you embed in your page then can't access/talk to at all?). This includes data binding, events, allowing parent CSS to apply to certain things (in a very explicit, named way, which allows the parent application to style the component in a manner the component creator deems appropriate, and not in a way that will break the component), etc.
These standards, in effect, define features that once implemented will permit true web components to be built.
It's a mess, I agree, but it's something that Web Components are supposed to solve. You can really think of React, Angular, Ember, jQuery Widgets, etc. as poor polly-fills for Web Components; poor because they don't interop with each other easily (which is the pain you were experiencing). With Web Components, people can author components and anyone else can use them just like they would any built-in tag like <input> and <video>. This will give you exactly what you're wanting, which is a Bootstrap or Material Design implementation that you include in your project and instantly expand your library of DOM elements.
The problem with React is that the core team has explicitly stated that they are not worried about compatibility with Web Components, so if you stick with that framework over the long term you may find yourself shut out of that bright future. The Angular team re-wrote their framework mainly because they wanted to be compatible with the upcoming Web Components spec.
I didn't say polymer can't do it. What I'm saying is that certain constructs are more difficult to write in polymer. Or involve more code and indirection.
Most apps will have their core data loaded into nice JavaScript objects and class instances. With react the transformation of that data into DOM is a one step process. With polymer you have to first map that data to javascript primitives which are consumed by expressions which then generate the DOM.
I guess ultimately it's my preference to having types (I use TypeScript) which can be used inside the rendering code to ensure correctness. With polymer you lose some of that because everything ends up in these untyped expressions.
I'd like to see React support shadow-dom and web components. Not holding my breath however, since Facebook considers web components to be a "competing technology".
Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.
It's also true that React is "monolithic" in the way that other frameworks are: they don't naturally interoperate, or do by cumbersome adapter libraries that require wrapping widgets and marshaling between data-binding techniques. They interfere with normal DOM usage, and tend to break if other code modifies a component's DOM (granted Shady DOM has made this trade off temporarily), and they aren't "just elements" - getting a node controlled by React out of the DOM doesn't get you the component itself, no useful API is added to the node.
You simply don't see many applications that mix and match React, Angular and Ember because of this. This Polymer difference is that it's deigned to help you create "just elements" so that they're interoperable with other frameworks, plain JavaScript or just HTML. Users of Polymer elements should never have to know that they were made with Polymer.
Needing to use Shady DOM APIs is an unfortunate exception to this, but an site can choose to use the full Shadow DOM polyfill if the performance fits their needs.
reply