![\"\"](\"https:\/\/thedevcouple.com\/wp-content\/uploads\/2017\/10\/Interview-React-1.jpg\")
<\/div>\nKnowing that React is a very strong contender for Gutenberg I decided to get the other side of the story as well. i.e., how does the React team feels about it things that we (WordPress Community) care about?<\/p>\n
I had an incredible chat with the React team \u2014 Dan Abramov<\/a>, Andrew Clark<\/a>, and Sophie Alpert<\/a>. They were keen enough to share thoughts about React.js and WordPress.<\/p>\n Have at it.<\/p>\n Currently, the\u00a0React\u00a0team that works full-time at Facebook consists of:<\/p>\n We are also lucky to have a few external contributors on the core team who have helped us a lot:<\/p>\n We are very grateful to them and are looking forward to onboarding more external contributors in the future.<\/p>\n \u25b6\ufe0e Sophie<\/strong>: Our goal is to make it easier for people to build great apps. That can come from a lot of places\u2014whether that\u2019s making better tools for debugging, improving performance, or adding features that save time during development. We try to listen to what people are asking for both at Facebook and in the community. We also try to find new ways to help people develop apps even if that means bringing more capabilities into\u00a0React\u00a0for things that we\u2019re not currently responsible for.<\/p>\n \u25b6\ufe0e Dan<\/strong>:\u00a0As people build larger apps with\u00a0React, they often raise the same problems with us, so we usually have a good idea of the pain points we need to solve in the next releases. We don\u2019t have a multiyear roadmap because we try to stay sensitive to both new challenges and opportunities. However, as we get closer to planning a specific release, we always share our\u00a0checklists<\/a>\u00a0with the community to get feedback on them and provide a sense of progression.<\/p>\n \u25b6\ufe0e\u00a0Andrew<\/strong>: One of the nice benefits of working at Facebook is that we have access to all sorts of interesting, difficult problems. It eliminates much of the guesswork from figuring out how\u00a0React\u00a0can be improved. If we can make\u00a0React\u00a0work for the teams at Facebook, chances are it\u2019s going to help solve problems for the wider community, too.<\/p>\n \u25b6\ufe0e Dan<\/strong>: Despite a small API surface, we have more than two thousand unit tests, and we are constantly adding more. These tests help us catch regressions before we merge changes on GitHub. We consider master to be relatively stable, and even though the APIs on master might change before a release, we do our best only to land the changes that are well-tested.<\/p>\n Some problems are impossible to detect from unit or integration tests, even if we ran them in the browser. To address this, we have built a DOM fixture suite with dozens of manual tests for browser quirks. The code that directly interacts with the DOM in\u00a0React\u00a0is scoped to a few modules, so whenever we change them, we run through the fixtures in different browsers and verify that we did not break anything.<\/p>\n Every two weeks, we update the version of\u00a0React\u00a0used on\u00a0Facebook.com<\/a>\u00a0to the top commit on the master branch on GitHub. This runs about 60 thousand JavaScript product unit tests, many of which rely on\u00a0React. They help expose trickier conditions that occur in the real apps. We also perform manual testing of several large-scale\u00a0React\u00a0apps (such as advertising products with deeply nested forms and data tables), and run Selenium integration tests in different browsers.<\/p>\n Finally, we have a\u00a0sophisticated continuous deployment system<\/a>\u00a0that catches regressions early. We heavily use Facebook products for work communication, and all changes are rolled out to employees first. If we introduced a bug, we get reports and can investigate the problem before the changes are deployed to our users. There are also automated systems that monitor the number of crashes or drops in metrics, and correlate that back to the commits.<\/p>\n \u25b6\ufe0e\u00a0Sophie<\/strong>:\u00a0In practice, in the rare event that regressions ship to production, we find a matter of hours or days, at which point we\u2019ll fix them and add a test to help make sure we won\u2019t regress again. At Facebook\u2019s scale, even an uncommon bug can occur for millions of people, so this testing gives us confidence in the open source releases of\u00a0React.<\/p>\n \u25b6\ufe0e\u00a0Dan<\/strong>: We do major releases roughly once a year, and they usually include some breaking changes. However, we always provide a straightforward migration path. At Facebook, we have more than 30 thousand components, so we can\u2019t afford to do large API-incompatible changes. Outside of Facebook,\u00a0React\u00a0is trusted by companies like Twitter, Airbnb, Pinterest, and hundreds of thousands of other developers. We take this responsibility very seriously and often collaborate with them to ensure smooth upgrades.<\/p>\n If the change is mechanical (like renaming a method), we release\u00a0codemod scripts<\/a>\u00a0that you can run to convert your whole codebase in a few seconds. If the change is more complex, we typically introduce new behavior side by side with the old behavior and warn for a single major release cycle before changing it. This gives our users about a year to opt in and upgrade their code to the new patterns. If a change is non-trivial, we can keep a warning for more than a single release so that we don\u2019t leave anyone behind.<\/p>\n The recent\u00a0React\u00a016 release<\/a>\u00a0is a good demonstration of this approach. It features a completely rewritten core to unlock powerful new features, but it is almost entirely API-compatible. Instead of working on a new version in a vacuum, we ran the new engine side-by-side with the old one on our existing products and fixed all the issues we could find. In case you\u2019re interested in how we did it, our manager Sophie\u00a0wrote a post on the Facebook engineering blog<\/a>\u00a0about this.<\/p>\n When a major\u00a0React\u00a0update is out, there is some churn in the ecosystem. The libraries affected by the changes might also need to be updated. I think this is unavoidable if we want to keep innovating. But in my experience, most popular libraries get updated within a week or two of the new release, and the longer trail of small packages takes about a month.<\/p>\n The library churn is less of a problem at Facebook because we don\u2019t rely on open source components as much, and so we run the migration scripts in a single pass. I\u2019m curious whether this would also be true for WordPress. If WordPress provides some base components to be used by plugins, they could all be updated at the same time. But I don\u2019t know WordPress well enough to tell.<\/p>\n \u25b6\ufe0e\u00a0Andrew<\/strong>: Here’s my favorite way to illustrate our commitment to stability: when we make a change to\u00a0React\u00a0that necessitates changes to the thousands of\u00a0React\u00a0components in production at Facebook, it’s not the product developer’s responsibility to fix it. It’s ours. And our team is less than ten people, for more than 30,000 components that must not break. So we don’t change things on a whim; we know exactly how easy or difficult a migration will be, and do our best to minimize the pain involved for ourselves and our users.<\/p>\n A big reason we\u2019re able to do this is that the\u00a0React\u00a0API is pretty small. Relative to other projects, there just aren\u2019t that many things in danger of breaking. That’s by design: we\u2019re very intentional about adding new APIs. If you look back at the earliest versions of\u00a0React\u00a0and compare them to today, we\u2019ve added some features, renamed a few methods, and swapped out certain APIs for better alternatives. But fundamentally, the way you write\u00a0React\u00a0components is the same.<\/p>\n \u25b6\ufe0e Andrew<\/strong>:\u00a0React\u00a0was designed to fit into the web infrastructure used by Facebook: a mix of server-rendered static content and client-rendered dynamic interfaces. It\u2019s not so dissimilar from how WordPress sites are built. Our servers even run PHP!<\/p>\n \u25b6\ufe0e\u00a0Dan<\/strong>: Facebook has all kinds of\u00a0React\u00a0apps. Some are single-page apps built completely with\u00a0React; others are small components embedded inside larger server-rendered apps. Some are built for the web, and others are built with\u00a0React\u00a0Native. Some are pretty simple, and others include complex navigation, data tables, and highly interactive forms. This gives us a first-hand experience of how different apps live together on one page and work together.<\/p>\n The problem of different apps coexisting on the same page is not trivial. I\u2019m sure you can relate to it after working for so long with WordPress plugins. Code becomes fragile if two plugins can hook into the same mechanisms and conflict with each other. This is why having a strong component model so is important to us. Different parts of Facebook pages are maintained by completely separate teams, so we need to make sure they can make changes without breaking each other\u2019s code. In our experience, the\u00a0React\u00a0component model already provides that isolation, but we have not yet exhausted its possibilities.<\/p>\n For example, before\u00a0React\u00a016, an error in one\u00a0React\u00a0component could break the whole page. This is still the case with many UI libraries. But this is unsustainable because as your app gets larger, someone is going to make a mistake. It is also unfair that an uncaught error in one product can break a different product maintained by a different team. This is why we built\u00a0error boundaries<\/a>\u00a0React\u00a016 to let you catch crashes in your components, and display a fallback UI without taking down the entire page.<\/p>\n \u25b6\ufe0e\u00a0Andrew<\/strong>: In WordPress, I imagine each plugin could surround its views in an error boundary. That way, if one plugin breaks, the rest of the page isn\u2019t affected. Instead, you can display a graceful error message, or perhaps nothing at all.<\/p>\n Start-up time is another important problem, especially for sites with lots of static content, as is often the case with WordPress. We want to build sites with rich interactivity and engaging features, but we also want to avoid clogging the main thread with loads of JavaScript work. Techniques like code-splitting already work with\u00a0React\u00a0today, but we think we can do even better. In the future, we\u2019ll be introducing an\u00a0asynchronous rendering mode<\/a>\u00a0to\u00a0React. The idea is to increase responsiveness by cooperatively scheduling rendering work over multiple frames.<\/p>\n \u25b6\ufe0e\u00a0Dan<\/strong>: I think\u00a0React\u00a0is mostly useful for rich, dynamic applications, and makes less sense for something like a landing page.<\/p>\n React requires some knowledge of JavaScript. This is in contrast to template-oriented libraries that build a custom syntax around HTML. The advantage of using JavaScript is that once you learn its constructs, you can apply them everywhere. But the downside is that it\u2019s harder for folks who have only been exposed to HTML and CSS in the past.<\/p>\n We find that\u00a0React\u00a0performs well for most apps, but there are some cases where templates perform better: for example, stock trading apps where hundreds of cells update every few milliseconds. In these cases, something like Angular with ahead-of-time compilation is faster. Facebook products are mostly focused either on social interactions or managing advertisements, and we find that\u00a0virtualization<\/a>\u00a0when necessary solves our performance issues well.<\/p>\n Thanks to\u00a0React\u2019s popularity, there is a lot of content about\u00a0React, but this also means not all of it is good. Sometimes it can be hard to find good articles or examples in the sea of noise. I\u2019m sure this problem is familiar to WordPress users as well. Generally, we advise that people start looking for answers in our documentation first, but it can be hard to convince people to do this, and it is not perfect either.<\/p>\n \u25b6\ufe0e\u00a0Andrew<\/strong>: In contrast to other JavaScript frameworks,\u00a0React\u00a0doesn\u2019t provide first-class solutions for things like routing, animation, or data management. Our philosophy has been to keep\u00a0React\u00a0itself small and focused, providing the core primitives on top of which our users can solve higher-level problems.<\/p>\n So far, this strategy has been pretty successful. The\u00a0React\u00a0open-source community is incredibly active and churns out innovations at a remarkable pace. The downside is that for developers new to\u00a0React, sorting through all the various open source libraries can be overwhelming. On the whole, I think the trade-off is worth it, but I wouldn’t blame anyone for disagreeing.<\/p>\n \u25b6\ufe0e\u00a0Dan<\/strong>:\u00a0While this approach produces some churn if you switch to every new library, it has longer-term benefits for everyone. For example, the Flux architecture used by Facebook wasn\u2019t a part of\u00a0React, so it inspired a wave of innovation in the ecosystem, including Redux. I believe these ideas have already influenced other communities like Angular and Vue, and they also inform the future direction of\u00a0React\u00a0itself now. This might not have happened if\u00a0React\u00a0forced people to adopt a certain solution and discouraged experimentation.<\/p>\n \u25b6\ufe0e\u00a0Dan<\/strong>:\u00a0React\u00a0has certainly acquired the reputation of being difficult to set up, but in my experience of talking to people, it is not\u00a0React\u00a0but the build tool configuration that is intimidating. I certainly empathize with that. Nobody wants to spend a day configuring a build tool before they can start a project.<\/p>\n I think, however, that there are clear solutions to this problem. Nobody experiences it at Facebook because the build tooling is preconfigured and \u201cjust works.\u201d And we can do the same in open source.<\/p>\n For example, I have been trying to replicate the same zero-configuration experience in a tool called\u00a0Create\u00a0React\u00a0App<\/a>, and 96% of more than 5,000 people we surveyed said they would recommend it to someone getting started with\u00a0React.<\/p>\n If WordPress were to adopt\u00a0React, it would make sense for it to also provide a zero-configuration build environment. We are happy to offer some of the packages we developed as part of Create\u00a0React\u00a0App for reuse: for example,\u00a0our interactive build error overlay with editor integrations<\/a>.<\/p>\n \u25b6\ufe0e\u00a0Clement<\/strong>:\u00a0Adding to what Dan said,\u00a0React\u00a0has a huge ecosystem of plugins, libraries, and whatnot. Although this can be very intimidating at first, it\u2019s also powerful and awesome to have so much pre-existing work done, so you don\u2019t need to re-invent the wheel. When I first started learning\u00a0React\u00a0last year, I found it very useful to focus on the basics\u2014this means ignoring libraries such as GraphQL, Relay, Immutable.js, etc. to begin with and just learning pure\u00a0React\u00a0from\u00a0https:\/\/reactjs.org\/docs\/ \u25b6\ufe0e\u00a0Andrew<\/strong>:\u00a0Most of the data I\u2019ve seen suggests that the job market for\u00a0React\u00a0developers is strong and getting stronger.\u00a0StackOverflow reported<\/a>\u00a0earlier this year that hiring demand for\u00a0React\u00a0is the fastest growing of any technology or developer type. It\u2019s being used by companies such as Microsoft, Apple, Netflix, Airbnb, Pinterest, Yelp, Twitter, and thousands of smaller ones. And Facebook, of course.<\/p>\n Now, historically, popularity in the JavaScript ecosystem can be fleeting. There\u2019s always the risk that, despite\u00a0React’s current position, it could be supplanted by some hot new framework within the next few years. I don\u2019t expect that to happen anytime soon; I\u2019m enthusiastic about the direction of the project and our ability to keep innovating. But if that\u2019s something that concerns you, keep in mind that\u00a0React\u00a0is a crucial part of Facebook’s infrastructure, across pretty much every platform. (Including VR!) Regardless of which way the tides shift, we\u2019re here to stay for the foreseeable future.<\/p>\n When considering which framework can most positively impact your career, you should also take into account the skills and knowledge you gain while using it. What\u2019s great about learning\u00a0React\u00a0is all the other stuff you pick up along the way, like immutability, declarative programming, data flow, and JavaScript in general. If some mind-blowing new framework that obsoletes\u00a0React\u00a0is unveiled tomorrow, the experience you have building apps with\u00a0React\u00a0will transfer to whatever comes next.<\/p>\n \u25b6\ufe0e\u00a0Clement<\/strong>:\u00a0As an intern from the University of Waterloo, I can tell you that the demand for\u00a0React\u00a0developers is pretty big\u2014three of my internships in the last two years involved some\u00a0React\u00a0work, in addition to a contract position that I had during the school year to developer a\u00a0React\u00a0application. Like Andrew said above, the skills that you pick up along the way learning\u00a0React\u00a0won\u2019t be wasted. I\u2019m confident that if\u00a0React\u00a0is obsolete tomorrow, I\u2019ll be able to transfer my skills over.<\/p>\n \u25b6\ufe0e\u00a0Andrew<\/strong>:\u00a0Absolutely. In fact, I made that exact transition. I got my start building WordPress sites at an agency when I was in college, about four years ago. I knew a fair amount of HTML and CSS, but had minimal experience with PHP or JavaScript, aside from snippets I was able to cobble together from tutorials. Even though I was the only developer at the company and had no idea what I was doing, hacking on WordPress sites provided a great education for me.<\/p>\n After about a year of this, I tried out\u00a0React\u00a0for the first time. The app I built was nothing fancy; it occupied a small part of one page of a larger website. But it was easily the most fun I’d had in my career up to that point. I started looking for excuses to sneak\u00a0React\u00a0into all my projects. One of my last projects was a single-page\u00a0React\u00a0application with a WordPress backend via\u00a0WP-API<\/a>\u00a0(which was pretty new at the time).<\/p>\n A bit later, I got involved in open source, which eventually landed me a job as a front-end engineer at a start-up building\u00a0React apps. Then, about a year after that, I joined Facebook. So, yes, it can happen, and anecdotally, I don\u2019t think it\u2019s that uncommon either. I can\u2019t speak for every company out there, but at Facebook, we have engineers from a wide variety of backgrounds. You don\u2019t need a fancy degree or many years of experience. In fact, only one person on the\u00a0React\u00a0team has a degree in Computer Science.<\/p>\n Dan<\/strong>:\u00a0I don\u2019t have enough insight into the problems WordPress is solving on the client side, and how its community feels about different libraries. But I have a hunch that a strong component model is going to be important. Thankfully, most modern libraries agree on this.<\/p>\n I\u2019ve heard an argument that WordPress should not pick any library, and instead offer an interop layer so that people can choose for themselves. This makes some sense to me, but it does seem to go against the \u201cDecisions, not Options\u201d principle in the\u00a0WordPress philosophy document<\/a>. This position also fails to acknowledge the fact that interop is a long solved problem. For example, if WordPress adopts Vue, it\u00a0won\u2019t stop<\/a>\u00a0people from writing\u00a0React\u00a0<\/span>components for it, and vice versa.<\/p>\n Web Components are often hailed as the solution to interop, but in practice, we\u2019ve had an interop solution for all these years: it is called plain JavaScript. On top of that, you can always add something else, including Web Components. Since you can create DOM elements from plain JavaScript, I would consider it to be lower level, and thus more powerful.<\/p>\n If WordPress doesn\u2019t pick a primary library, I think providing low-level JS hooks would be the best choice for everyone. People who like\u00a0React<\/span>\u00a0can use\u00a0React<\/span>, people who want Vue can use Vue, and people who prefer Web Components can use them too! But then again, let\u2019s not forget that interop is entirely possible even if WordPress follows its philosophy and makes an opinionated decision, whatever it may be.<\/p>\n Overall, as people build larger apps with other libraries, I think it is likely they will bump into the same problems that we are trying to solve. So whether WordPress chooses to React<\/span>\u00a0or not, I hope that we will continue this exchange of ideas, and learn from each other’s experiences.<\/p>\n \ud83d\udd25Thank You, everyone, for taking<\/strong> part in this whole thing!\u00a0<\/strong><\/em>If there\u2019s anything, you\u2019d like to ask these awesome people, post in the comments section below.\u00a0<\/strong><\/em><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" The news about Facebook dropping the patent clause and\u00a0re-licensing of React under the MIT license brought some sort of relief to the WordPress community. But the much-heated debate isn’t over yet. People are discussing round the clock about the JavaScript Framework Gutenberg is going to adopt. I’d say we’re sticking with React.js from an engineering […]<\/p>\n","protected":false},"author":3,"featured_media":1880,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":""},"categories":[6],"tags":[58,57,7,59],"coauthors":[81],"jetpack_featured_media_url":"https:\/\/thedevcouple.com\/wp-content\/uploads\/2017\/10\/Interview-React-2.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/posts\/1819"}],"collection":[{"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/comments?post=1819"}],"version-history":[{"count":0,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/posts\/1819\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/media\/1880"}],"wp:attachment":[{"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/media?parent=1819"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/categories?post=1819"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/tags?post=1819"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/thedevcouple.com\/api\/wp\/v2\/coauthors?post=1819"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n