? React Is A Terrible Idea (archive)

Source originale du contenu

There's been a lot of excitement lately about React. React seems to have bumped Angular from the top of the hippest-framework mountain. This is unfortunate, because both of these frameworks are bad for your application's health. They're also bad for the entire software industry. For new applications, please, for the love of all things open, use Web components instead.

React's design is bad. I could give you a lot of specifics—separation of concerns, coupling views with models, the focus on needless optimizations, the importance of supporting open standards—but I'm going to tell you a story, instead. The story is about a startup with a popular product and lots of venture capital. This startup decided that they wanted to make their Web app extra special. Like many who came before them, they decided that HTML and CSS just weren't quite good enough for them.

The Wayward Startup

They went to a great deal of trouble to build their own rendering engine, using Canvas. And it worked! Their Web app was now extra special. However, as it turned out, the browser vendors were working on solving the very problems that had motivated this startup to write their own rendering engine. In fact, just two weeks after the startup announced their extra special rendering engine, a major browser release included a solution to one of the biggest problems of all.

The startup is Flipboard. The major problem is smooth scrolling, which just dropped in Firefox. The framework they wrote is React-Canvas, which was largely motivated by the desire for smooth scrolling. Instead of contributing to various efforts to speed DOM rendering, Flipboard decided to write their own canvas-based rendering engine. Was it cool? Yes. Was it impressive? Yes. But was it wisely constructed? No. Instead of a solution everyone can benefit from, we have a solution you can only benefit from if you use React. Even if React was a good design (it's not), that's still severely limiting the potential audience.

Panda Strike is not a mindless cult, of course. Some of us think it's silly to support 60 FPS animations so your users can look at magazines, aka static content. Some of us buy John Gruber's argument that iOS-level responsiveness is not really optional any more. But we all agree the engineers at Flipboard are obviously very talented, and React Canvas might be useful to someone. And that it would have been better as a simple Canvas library, without being tightly coupled to React.

Every Innovation Does Not Need Its Own Framework

Internally, React depends on virtual DOM. The advantage over browser DOM is that virtual DOM nodes are relatively lightweight. You can create thousands of virtual DOM nodes without any performance impact on your application. Not only that, but you can diff virtual DOM trees and get a patch that can be applied to the actual browser DOM. That seems like it might, indeed, be handy. But what has that got to do with reactive programming? Or embedding markup in JavaScript?

Nothing. As proof, I submit to you this nice, stand-alone virtual DOM implementation. Here's what the authors said about why they wrote a stand-alone version:

One important part of the virtual DOM approach is that it is a module and it should do one thing well. The virtual DOM is only concerned with representing the virtual DOM. The diff batch and patch functions are only concerned with the relevant algorithms for the virtual dom.

The virtual DOM has nothing to do with events or representing application state. The below example demonstrates the usage of state with observ and events with dom-delegator. It could just as well have used knockout or backbone for state and used jQuery or component/events for events.

The same things could be said of a Canvas-based rendering engine.

The Real Purpose of React

Even if Flipboard spent all their venture capital on improving the rendering engines in browsers, they couldn't spend nearly as much as Facebook is capable of. Whatever sins of misplaced enthusiasm Flipboard may have committed, Facebook has committed tenfold with React. What if, instead of promoting an open source framework that only benefits applications that adopt it, they instead put their efforts into making open source browsers better?

They won't do this, though, because it isn't in their interest to do so. You may recall Facebook's abrupt about-face on their mobile app back in 2012, when Mark Zuckerberg said building on HTML5 was his company's "biggest mistake." What you may not recall was Sencha took this claim as a challenge, and built a great HTML5 implementation of the same app, effectively demonstrating that Facebook's criticisms of HTML5 were largely unfounded. Unlike Google, whose revenue largely depends on their search engine–which, in turn, depends on people using the Web for everything–Facebook has always benefited from being a walled garden. Put another way, Facebook doesn't care if you use the Web, it only cares that you use Facebook.

So why release an open source Web framework at all? Because Facebook is battling Google for engineers. So you've got a big fight between two companies over which company is the coolest place to work, and both of them are companies that your grandparents love. How are you going to win this fight? One way is to have the hippest Web framework.

Basically, both Google and Facebook are desperate to find a baseball cap that they can put on backwards. Angular is Google's baseball cap. React is Facebook's.

The Open Web Is More Important Than You Think

Meanwhile, Web components are now available in Chrome and Firefox, with polyfills for older browsers. Web components are the biggest leap forward for the Open Web in years…and, yet, we're talking about React, a completely unnecessary framework. (Seriously, why not just introduce JSX and virtual DOM as separate libraries? And, as far as the data flow stuff goes, that's not even a new thing. People have been doing that for years.) This is bad, because the Open Web is important, and ten years ago, we nearly lost it.

Today, Microsoft looks like a lost wildebeest, wandering the Saharan plains of failed products. But ten years ago, they were poised to own the Web. If you've been in this business less than ten years, you might not realize how close we were to a world where the mobile Web would have required using Windows Phone. Don't believe me? Microsoft was actually ruled to be a monopoly in the United States, and is still dealing with the aftermath. To this day, we still hear about the need to support Internet Explorer 8, which is the new Internet Explorer 6, a useless, bug-ridden weight that tied down the entire industry for nearly a decade. And the reason we're largely free of that weight today is the emergence of Firefox and WebKit.

That didn't happen by accident.

How You Can Help

We have the luxury of complaining about “slow” rendering times in the DOM because we can take for granted a browser platform that is improving faster than we can even make use of the new features. This includes major rendering improvements. We don't need more workarounds; what we need is more investment in making the platform we have, whose very existence is a near-miracle, better. And you don't have to know C or iOS internals to be a part of that. All you have to do is make use of the platform.

That's right. Just by using new innovations like Web components, instead of work-arounds like React, you're contributing to the success of the Open Web. You're voting with your code. With adoption comes community, and with community comes an ecosystem. In two years, we could have a Tower of Babel of recruiting-campaigns-posing-as-frameworks, or we could have an ecosystem of reusable Web components.

The best part is that you don't have to compromise to get the benefits of Web components. Because they're actually a much better abstraction for building human-computer interfaces than anything React or Angular have to offer. What a lot of people don't realize is that components were implicit in MVC when it was first introduced. They're also the basis of pretty much every other HCI platform ever, including iOS and Android. So it's not like we're talking about limiting ourselves by using Web components. Quite the contrary, Web components represent a far superior option.

React, Bad; Web Components, Good

A good framework supports separation of concerns. Web components do not impose a way of representing views or attaching event handlers or rendering to the DOM. A bad framework couples those things together so that you can't use one without the others. That's what React does.

Sure, you can use JSX if you want, but that's the worst part of React anyway. JSX wants you to couple your view with the model and controller. It's a bad idea. Don't do that. Virtual DOM is great, if you need it, but you probably don't. And it was thankfully FTFYd anyway. React is not a good framework. And Web components aren't even a framework really, so much as how browsers work now. More generally, components are how pretty everything but the Web has worked for decades.

The solution to the problems on the Web is never, ever going to be to tightly couple presentation, behavior, and data. Your Web apps will ultimately become unmaintainable hair balls of unreadable code. The solutions will come in the form of better Web browsers, and reusable components that reduce coupling instead of increasing it. In other words, they'll be based on best practices that have survived decades of evolution in the software industry. In the meantime, your best bet is typically going to be to use what works and focus on the problems you can do something about, without trying to reinvent the browser from inside the browser.