One thing I like about both Polymer & React is that they encourage you to treat your apps as a composition of components, as opposed to each page being a wall of HTML with a few variables substituted in.
That being said, React really makes it easy for those components to be tiny little things that do only one thing, that compose nicely, and that are easy to understand. There's a heuristic in programming that if a function is more than a page in length, it's probably too complicated. The same heuristic applies to React: if your component (JS, JSX & CSS together) is more than a page, it's probably too big.
Just the act of splitting apart the JS, JSX & CSS encourages the components to become much larger.
I think they solve two different problems. Polymer I see as useful for creating atomic UI elements while React.js is better for stringing the UI elements together into a cohesive experience.
That is crazy. React is just the current trend but having tried both React and Polymer (Web Components), I'm confident that plain Web Components will win out in the end. You just can't beat simplicity.
In a large application, it starts to become a pain to deal with. It doesn't obviate the need to be careful over mixing responsibilities. In general, React components should just be things that render out to the DOM. If the HTML code is in JS, it doesn't matter as much as the more important thing of separating out your application layers.
Can you explain what you mean a bit more? My experience with React is that composing components is so trivial (particularly compared to e.g. Angular directives) that I've tended to end up with very small view files (~10 lines of DOM max, plus whatever functionality is directly tied to that). It's seemed like one of React's greatest strengths to me, so I'm curious as to where your complaint stems from.
(I don't use React in my day job... yet. But I'm considering pushing for it, so getting a better understanding of its shortcomings is really important to me.)
I'm not terribly experienced with React, but from briefly using it, I definitely prefer polymer's simple vanilla html+js declarative data-binding approach over react's JSX + element injection, from a basic usage perspective.
React has a bigger community, more hype, more tooling around it, better native mobile support and better support for automated testing.
But if I had to pick my favourite, I'd have to go with Polymer because:
- It's simpler (fewer dependencies).
- Declaring styling and layout is cleaner (it's easier to visualise a component's appearance and to modify it during debugging because layout and styling are kept separate from a component's behavior logic). When it comes to debugging, styling/layout issues almost always happen independently from behaviour issues so it makes sense to keep them separate in the source.
- It works better with browsers' native development tools.
- No need for a compile step (and associated complexity that comes with it as your app grows).
It's not fair to pretend that React bypasses the DOM entirely. Ultimately, when the user clicks on a button, they are interacting with a DOM element, so the event still has to pass through the DOM layer. The DOM is still the API whether you like it or not.
I've used ExtJS, Backbone, CanJS, Angular, Polymer and React commercially.
To me, React is a more complex alternative to Google's Polymer framework.
In React, a component is made up of code which has HTML inside it.
In Polymer, a component is made up of HTML which has code inside it.
They're actually the inverse of each other but the result is almost exactly the same - Both libraries allow you to build components which contain other components and both provide clean encapsulation.
One of the reasons why I have a slight preference for PolymerJS is that it's much simpler and works with existing HTML concepts (they didn't need to invent a new debugging panel, a new DOM model, a new approach to CSS styling or an advanced state management architecture like Redux to make it work) - Instead, they leveraged existing web technologies. For example, Polymer provides really nice CSS style encapsulation. In PolymerJS, the <style> tag only affects the component in which it's declared (potentially including sub-components but not parent components).
It makes CSS really easy to use/maintain without actually reinventing it. You can do cool stuff like allow a sub-component's style to change automatically as you move it from one parent component to another. You don't need any special module or library or special styling logic; just a <style> tag declared at the appropriate level in your component tree/hierarchy is all you need.
That said, the React community is massive and because of this, there are tons of modules and tools around it so it's hard to beat now - It seems that pretty much every problem that React has introduced has since been fixed.
React is a lot more than it seems. The essential problem it tries to solve is componentization: how can you have a large team of varying skill work on separate parts of a page in a web application without one part breaking the others in hard to detect ways?
Many people focus on JSX or virtual DOM and muse about how that just duplicates the browser-- what's the point? But that isn't the point. It's componentization and encapsulation for large teams at scale, and for Facebook it works, it makes them more successful at pulling together disparate modules on a single page than their competitors, so there is some meat to this $NEWSHINY.
Now, if the browser itself had been properly designed years ago to be componentized and encapsulated, we'd have those features without inventing a new DOM or creating a new tagging language or isolating CSS. There is a web components standard that offers much of the same thing... It came out around the same time as React, but still isn't widely used outside of Google Polymer. Truth is these were developed in parallel before they knew of each other.
Anyway, React makes a lot more sense if you think of it as rewritting the browser from outside the browser. In the old days the stack that would have been hard to impossible-- you would have simply started your own browser. And people would have shamed you for not following existing standards, so you would have petitioned the W3C or served on committees to bring your real-world cases for years, being mostly ignored.
Now, devs have the ability to change the browser quickly and find things that work (and also create chaos and suffering).
We (tonicdev.com) experimented with both Polymer and React before settling on React. Doing things "the right way" in Polymer/WebComponents was just a mess. It did in fact remind me of the "old way" of doing things in Cocoa: AKA, accounting for every edge case with every appendChild or DOM mutation that could take place on your component. Having tried React's "API-less" approach of just re-rendering what you want given the params/sub-components, it was an absolute time sink that just offered no benefits.
You'll see in the answer the complexity around dealing with children that come and go (vs in React you'd actually write it declaratively once and be down with it -- kind of interesting that Polymer has so much "templaty" stuff and is ultimately less declarative than the pure JS approach React).
The component paradigm that react is built around is all about working with very small objects, where everything you need for that component is in one file. It's a fantastic model when you are working with a complex interface that has many components to it. It's a paradigm that needs to be managed and used carefully though, otherwise you'll end up with massive 2000 line files.
I never thought there was a separation between JS and CSS, that sounds a little outdated, to be honest. As a front-end developer, I would be expected to do JS and CSS.
It's not about how complex the component is. In my experience what matters is how easy it is to use. With React it's easy to build a world in a teacup, and that's mostly a good thing.
For "regular CRUD developers", the vast majority of us, I have zero concern about how big or crazy component code is until it's so huge it impacts page size. I'll use the easiest most feature complete library out there.
React does encapsulation like jQuery never could. I don't care if I have this vanta black box on my page as long as it's easy to mess with and gets the job done
React's complexity literally only exists for two reasons:
1. To sidestep problems with the DOM. The virtual DOM helps with performance, and fibers help with responsiveness.
2. To implement reactive components. Virtual DOM makes rebuilding sub trees of the DOM cheap, making it possible to have clean components that don't need to constantly attempt to tweak the DOM. Doing this style of programming without DOM diffing is possible, but much slower.
There are other approaches, but this one is significantly nicer to code for than DOM binding and is significantly faster than any naive approach.
Yes, you can extract the essence of React into a several kb bundle. It's been done to death. But why? React is fast, mature, has a great ecosystem, and it's nice to code for. It does nice things like seamlessly support SVG and intelligently batching changes. If you're truly making a complex app, it's worth the bump in bundle size.
The largest part of any web app is the browser. If the DOM wasn't so bloated and ridiculous, maybe we wouldn't need to spend all of our time minimizing our interactions with it. But if you try to count all of the work the browser has to do to layout and render one DOM element, suddenly React feels very tiny.
In my experience, React has been a better realization of the concept behind Polymer ("reusable web components"), without the non-sense. I don't even consider server-side rendering the killer feature.
I'm not the biggest fan of react, but it's pretty easy to slap a single component into a project using the cdn, a single require and a single jsx file. I mean it isn't as easy as jquery, but it feels like it's in the some order of magnitude of difficulty.
As with all technologies it matters how they are used; I simply stated web components make the separation easier than ever before but that doesn't mean the same can't be done with JSX.
I think it's very important to keep the interface away from the logic. Creating components in React that only drive the user interface isn't bad but it's not as straightforward as something native like dealing directly html and css. I've worked with many designers who are awesome at styling and making pages look great but when they have to edit any type of scripting or something outside of HTML / CSS it's a whole new skill-set they need to learn to be effective (a skill-set they don't really need that the majority do not have).
I had similar thoughts when I first learned React. After building several UIs with it, I think the core thing that trips devs up is that it's very easy to make things far more complicated than they need to be. Beginner resources often don't help, either. Many of the boilerplate and starter pack examples you can find online have a ridiculous level of complexity in the file folder structure, component structure, dependencies, etc. - for example, no, you don't need half a dozen components spread across as many files to render a simple header or footer.
If you try to stick to a minimalist approach, it can be a pretty convenient framework. Definitely beats trying to do the same thing the jQuery way.
Having watched the talk now, I see what he's getting at. I have maintained, at most, a small-approaching-medium-sized single-page app, and it was an internal tool. Clearly I have not felt any of the same pain that inspired React.
But within that particular experience, despite my "underpowered" templating tools, I've settled on a style that very close to what he calls "components", built instead from pairs of one partial and one viewmodel. Tightly coupled (cohesive?) within each pair, but as a unit are reusable together elsewhere in the front-end app.
So I can agree in theory, and see where my ideas have wandered close to the path that React takes. Really the only thing to do now is try it on a substantial project to see how it compares in experience. I suspect I'll still feel the urge to want the JSX in a separate file in some cases.
That being said, React really makes it easy for those components to be tiny little things that do only one thing, that compose nicely, and that are easy to understand. There's a heuristic in programming that if a function is more than a page in length, it's probably too complicated. The same heuristic applies to React: if your component (JS, JSX & CSS together) is more than a page, it's probably too big.
Just the act of splitting apart the JS, JSX & CSS encourages the components to become much larger.
reply