Drupal react

Last week at DrupalCon Vienna, I proposed adding a modern JavaScript framework to Drupal core. After the keynote, I met with core committers, framework managers, JavaScript subsystem maintainers, and JavaScript experts in the Drupal community to discuss next steps. In this blog post, I look back on how things have evolved, since the last time we explored adding a new JavaScript framework to Drupal core two years ago, and what we believe are the next steps after DrupalCon Vienna.

As a group, we agreed that we had learned a lot from watching the JavaScript community grow and change since our initial exploration. We agreed that today, React would be the most promising option given its expansive adoption by developers, its unopinionated and component-based nature, and its well-suitedness to building new Drupal interfaces in an incremental way. Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place.

Two years ago, it was premature to pick a JavaScript framework

Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:

  1. More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.
  2. Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.
  3. JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

(For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)

By September 2015, I had built up enough conviction to write several long blog posts about these views (post 1, post 2, post 3). I felt we could accomplish all three things by adding a JavaScript framework to Drupal core. After careful analysis, I recommended that we consider React, Ember and Angular. My first choice was Ember, because I had concerns about a patent clause in Facebook's open-source license (since removed) and because Angular 2 was not yet in a stable release.

At the time, the Drupal community didn't like the idea of picking a JavaScript framework. The overwhelming reactions were these: it's too early to tell which JavaScript framework is going to win, the risk of picking the wrong JavaScript framework is too big, picking a single framework would cause us to lose users that favor other frameworks, etc. In addition, there were a lot of different preferences for a wide variety of JavaScript frameworks. While I'd have preferred to make a bold move, the community's concerns were valid.

Focusing on Drupal's web services instead

By May of 2016, after listening to the community, I changed my approach; instead of adding a specific JavaScript framework to Drupal, I decided we should double down on improving Drupal's web service APIs. Instead of being opinionated about what JavaScript framework to use, we would allow people to use their JavaScript framework of choice.

I did a deep dive on the state of Drupal's web services in early 2016 and helped define various next steps (post 1, post 2, post 3). I asked a few of the OCTO team members to focus on improving Drupal 8's web services APIs; funded improvements to Drupal core's REST API, as well as JSON API, GraphQL and OpenAPI; supported the creation of Waterwheel projects to help bootstrap an ecosystem of JavaScript front-end integrations; and most recently supported the development of Reservoir, a Drupal distribution for headless Drupal. There is also a lot of innovation coming from the community with lots of work on the Contenta distribution, JSON API, GraphQL, and more.

The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us: I'm impressed by how fast Drupal made lots of progress with its REST API and the JSON API contrib module!". It's a good sign when a core maintainer of one of the leading JavaScript frameworks acknowledges Drupal's progress.

The current state of JavaScript in Drupal

Looking back, I'm glad we decided to focus first on improving Drupal's web services APIs; we discovered that there was a lot of work left to stabilize them. Cleanly integrating a JavaScript framework with Drupal would have been challenging 18 months ago. While there is still more work to be done, Drupal 8's available web service APIs have matured significantly.

Furthermore, by not committing to a specific framework, we are seeing Drupal developers explore a range of JavaScript frameworks and members of multiple JavaScript framework communities consuming Drupal's web services. I've seen Drupal 8 used as a content repository behind Angular, Ember, React, Vue, and other JavaScript frameworks. Very cool!

There is a lot to like about how Drupal's web service APIs matured and how we've seen Drupal integrated with a variety of different frameworks. But there is also no denying that not having a JavaScript framework in core came with certain tradeoffs:

  1. It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.
  2. It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
  3. It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.

Several years later, we still don't know what JavaScript framework will win, if any, and I'm willing to bet that waiting two more years won't give us any more clarity. JavaScript frameworks will continue to evolve and take new shapes. Picking a single one will always be difficult and to some degree "premature". That said, I see React having the most momentum today.

My recommendations at DrupalCon Vienna

Given that it's been almost two years since I last suggested adding a JavaScript framework to core, I decided to bring the topic back in my DrupalCon Vienna keynote presentation. Prior to my keynote, there had been some renewed excitement and momentum behind the idea. Two years later, here is what I recommended we should do next:

  • Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
  • Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.
  • Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.
  • Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.

Selecting a JavaScript framework for Drupal's administrative UIs

In my keynote, I proposed a new strategic initiative to test and research how Drupal's administrative UX could be improved by using a JavaScript framework. The feedback was very positive.

As a first step, we have to choose which JavaScript framework will be used as part of the research. Following the keynote, we had several meetings at DrupalCon Vienna to discuss the proposed initiative with core committers, all of the JavaScript subsystem maintainers, as well as developers with real-world experience building decoupled applications using Drupal's APIs.

There was unanimous agreement that:

  1. Adding a JavaScript framework to Drupal core is a good idea.
  2. We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
  3. While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
  4. This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

We created an issue on the Drupal core queue to discuss this more.


Drupal supporting different JavaScript front ends
Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

In short, I continue to believe that adopting more JavaScript is important for the future of Drupal. My original recommendation to include a modern JavaScript framework (or JavaScript libraries) for Drupal's administrative user interfaces still stands. I believe we should allow developers to use their JavaScript framework of choice to build front-end applications on top of Drupal and that we can start small with one or two administrative user interfaces.

After meeting with core maintainers, JavaScript subsystem maintainers, and framework managers at DrupalCon Vienna, I believe that React is the right direction to move for Drupal's administrative interfaces, but we encourage everyone in the community to discuss our recommendation. Doing so would allow us to make Drupal easier to use for site builders and content creators in an incremental and reversible way, keep Drupal developers' skills relevant in an increasingly JavaScript-driven world, move us ahead with modern tools for building user interfaces.

Special thanks to Preston So for contributions to this blog post and to Matt Grill, Wim Leers, Jason Enter, Gábor Hojtsy, and Alex Bronstein for their feedback during the writing process.


Jingsheng Wang (not verified):

This blog didn't provide the two things that I am interested in:

1. The reasoning between adopting custom components (React components) vs. native components (Web Components). If "most people seem to want a way to compose interfaces and interactions with reusable components", then using Web Components seems to make more sense. Or what does React really have to offer (ES6 can't offer) that worth giving up on Web Components?

2. What happened to the Progressive Drupal? Now, Drupal with a strong web services API, and more rich UX frontend trend, do we have a vision to (progressively) handle over a lot of PHP-oriented computation from Views, Calendar, Slideshow to frontend?

Attiks (not verified):

Leaving this here "If you’re a tech-lead or manager for a web team, it’s time to consider how and when you’ll transition to Web Components and what value frameworks add when most of their function has been supplanted by the platform. Forward-looking teams like Ionic are making this transition, and the results are incredible." from https://infrequently.org/2017/10/web-components-the-long-game/

Aleksi Peebles (not verified):

The MIT license does not mention patents. Has it been tested in court regarding patents? If not, how has the React patent issue gone away?

The Free Software Foundation says about MIT that ”for substantial programs it is better to use the Apache 2.0 license since it blocks patent treachery”.

Ashley Wilson (not verified):

I would love to see some attention going to https://www.drupal.org/project/pdb - my team has been building and deploying Angular 4 - based front end to be used by 30,000 users. Currently in beta, we are going live in February.

Nick_vh (not verified):

I'm completely in favor. Just don't make it required to be used in a front end, but I saw you tackled that already. Great decision making and hoping that it will bring unprecedented and insane interfaces for the long overdue overhaul of the admin and content editing interfaces!

Barry Fisher (not verified):

This is great news - especially about staying open to allow people to use whatever framework people feel is best for their sites. Solid APIs and the variety of options like GraphQL are a great way to go. React is now a no-brainer given the move to MIT and level of adoption. We're enjoying Vue here, but... horses for courses! No doubt there will be plenty of bikeshedding about whether to use JSX and other such topics, but making a pragmatic choice of React as the officially supported framework for Drupal means there can (hopefully) be several points of agreement so we can get ahead of the curve again and not be left behind while the JS world steams ahead. This feels like the right time to make the decision. Let's get building some great modern UIs with first-class APIs to boot! Cheers!

Phil (not verified):

I'm still a believer that a good majority of agencies are choosing to use Drupal as a headless system because they have to, not because they want to. I foresee a lot of new and existing agencies back away from a headless approach once Drupal ships with a decent frontend framework. The less time developer have to come up with their own frontend, the faster they can get the work done.

I'm not saying a headless Drupal doesn't have it's place, I'm simply saying I think most developers would rather not spend the time on it if they don't have to.

Has any research been done in this area?

Jon Anthony (not verified):

Very excited about this. Last year we delivered a major UN project in Drupal and angular https://www.drupal.org/node/2851185 . We would have been equally comfortable in ReactJS We used Drupal as a headless backend apart from admin where we leveraged full Drupal. If I had my choice of wishes I would want to see a nodeJS services module integrated into core - something along the lines of SailsJS which is very structured and fully socket integrated. Our project has live chat and the lack of a default socket solution was a challenge.

Mark Hanna (not verified):

-1 on React, Web Components would be the preferred supported paradigm.

Patrick Thurmond (not verified):

I think that a backend framework should not be choosing a front-end one. If you want to include React on an admin theme level, but otherwise leave it decoupled from core that is one thing. But it sounds like you want tighter integrations between core and React than that.

Further, I have seen many developers move from React to Vue.js and find it to be a much better tool for JS development. Yet you have a preference towards a tool that seems to have a community that is draining away from it as it's cracks have shown through. They have moved to other tools that seem to solve those problems. So why adopt a tool that people are moving away from?

The move to Symfony was, in my opinion, a hasty mistake. As it overcomplicated the backend immensely. Drupal would have been served much much better by using Laravel instead (which, I know, leverages a large chunk of Symfony components). That would have given us better tools to simplify backend development instead of making it far more complex than needed. I agree that Drupal needed strong tools as it's base so that it can leverage a larger development community as a whole as well as thoroughly tested code and thus freeing up dev time for more important things in core.

Drupal should try to be as agnostic and flexible as possible. There seems to be a haste to grab older tech that is already showing problems and people migrating from them in preference towards better ways of doing things. This, just to leverage the shear number of developers with experience in a technology. There seems to be a lack of looking forward to tools that offer a better developer experience and I wonder if much of that has to do with a preference towards what is familiar to Drupal core dev leadership.

I know it is hard to pick a direction and not be criticized for any choice that is made. To make a choice and hold to it is challenging in the face of such wide ranges of opinions in the community at large. That is not a position I envy. That is also why I try not to be overly critical of any choice that is made. You have to come to a decision at some point and just move forward.

I only ask that you try to do a deep dive into your choices, including testing the top choice yourself and it's common alternatives as well as consulting the community at large for the direction they are going and why instead of just figuring out where they have been.

Good luck, I wish you the best of wisdom in your choices.

Aleksi Peebles (not verified):

The MIT license is not solid regarding patents. The Apache 2.0 license would have been a good choice for React, as it explicitly covers patents. It is noteworthy that Apache 2.0 is the license React was initially released under, and for some reason Facebook did not want to use it this time. With MIT it all boils down to trust regarding patents, and I don't think an open source project like Drupal should trust Facebook.

Max Bachhuber (not verified):

I also see the future of Drupal be better suited by the W3C Web Components standard instead of some framework like react which tries to mock this functionalities...

Lewis Eigen (not verified):

I think that this is a prudent direction in which to go/ The two keys that I would like to endorse are (1) allowing for all libraries and not just picking one or two
(2) Choosing React for our administration

So this is just a Shout Out and an endorsement for the direction

Karoly Negyesi (not verified):

While much lesser known I really would love if people would take a very good look at sveltejs. It is going down a very different path, it supports web components, it is small and most importantly, it makes sense even to this old php curmudgeon. I am just not so sure this band of php developers suddenly becoming so js proficient to be able to use react well. I am not reading on whether this aspect was considered at all.

Mike Stewart (not verified):

Dries, you wrote: "I see React having the most momentum today.". However, your State of Drupal talk in Vienna clearly show more Drupal shops using Angular 43.5% vs React 33.9% (https://dri.es/state-of-drupal-presentation-september-2017). It seems you disagree with yourself, or I'm missing something?

In addition, a quick keyword search on the job boards also favor Angular. Hmm.

In either case, a continued focus on rock solid web services ... AKA headless, aka small core is still prudent. Be the best at one thing.


Good point! The survey results in my keynote are limited to a subset of Drupal agencies. In this blog post, I was talking about React vs Angular 2 globally (i.e. outside the Drupal community).

David Hernandez (not verified):

Couldn't you say the same about Vue then? I have no preference, but by github stats it is approaching React popularity and is more popular than Angular and other frameworks.

klokie (not verified):

Well done!
For anyone who wants real usage and opinion data about some of the most popular JS frameworks, please see Sacha Greif's recent keynote, "The State Of JavaScript"
(https://www.youtube.com/watch?v=FZw1j_tTSag (full results to be published soon on https://stateofjs.com/ as noted at https://medium.com/@sachagreif/the-state-of-js-2017-results-preview-acb…). Note 58% reported dev satisfaction with React vs 20% with Angular. Just putting that out there ;)

Dries, thank you once again for listening to the community and carefully weighing all the available options when making this important decision. I think it's a good one.

Stephan (not verified):

I was wondering what consideration might have been given to other Component-based frameworks like VueJS.

Anoop John (not verified):

This is a big step for Drupal. Not just on the improved ability to have great javascript/UI capabilities on the public facing website but also for the great opportunity to have a fluid UI in the administrative backend of the website. A significant part of the time spent by the key stakeholders of website is spent on the backend of the website. This move would help push for much better user experiences in the administrative and editorial interfaces in Drupal. There will always be another framework that would have some advantage or other but the key here is to go with some a framework which we can hope to rely on for the foreseeable future.

Aleksi Peebles (not verified):

The selection of a JavaScript framework is an important decision, which should not be based on just technical merits or popularity. Drupal has been an open source project and a community for over 17 years, and when we make decisions like this, our values should weigh more than what is the hottest JavaScript framework at the moment.

Dries has written and spoken several times about how we should not let a handful of companies like Facebook, Google and Apple control how we experience the web. One aspect of this control is the technologies and standards these companies support or do not support. These companies also acquire software patents, which they can enforce when it best suits their business interests.

Even if we trusted Facebook to not have patents on React technology, or at least to not enforce them against React users, patents are not the only issue to consider. Facebook maintains and controls React, deciding its direction. And currently this direction does not seem to be very standards-based. React is developed by Facebook for Facebook. Many decisions are made behind closed doors, and we don’t know the motives behind all of them.

So should Drupal, an open, community-based, GPL-licensed open source project, trust a company like Facebook? Do we want to use technology possibly patented by Facebook, with uncertain license coverage? Do we want Drupal to become a part of an open source ecosystem steered by Facebook? A decision to adopt Facebook technology will affect every Drupal site owner.

Even though we are currently only talking about administrative interfaces, a framework used in core will no doubt influence framework choices for user-facing front ends. People will choose and learn this framework because Drupal core uses it. We should also remember that the Drupal ecosystem is big and important enough for our choices to make a difference even outside of Drupal.

We should cherish our values of openness and being standards-based, and if we value our community, we should prefer community-led projects over company-led projects. These are the things that I’ve understood to be the true ‘core’ of Drupal, things that come before technological trends and details.

e0ipso (not verified):

I think that these are great news. I would still like to see experimentation done in contrib (provided we implement a way for the product team to highlight contrib modules to enhance findability). Nonetheless I think that better UIs will improve the product greatly!


Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs.

The API-First team has made available a list of issues that we can use help with. We selected issues for a wide variety of skill sets.


Gustavo Marcante (not verified):

Dries, great article, great view!

As you asked for a feedback, I would point:

1) I'm a user, not a coder. In terms of "philosophy", Vue is a community driven project, as Drupal is. Would be more coherent, in my point of view, to use Vue. Both communities would benefit. I agree that from a technical point of view, React can be more ready to use now. But if you look "the video" and not "the picture", Vue is growing more, in users, in resources, in projects, in approval (even some AngularJS users feel more "at home" with Vue than with Angular 2+). As this is a project "for the future", I think Vue would be a better choice. I don't know about using Web components, cited above, but in a philosophical point of view, would be coherent too.

2) I would prefer saying "decoupled" Drupal than "headless" Drupal. Not just because "headless" is very weird word (remembers me this Game of Thrones thing :) ). But, honestly, If somebody really want a "headless" CMS, with no front end, there are many newer, lighter, faster, ready-to-use options. What makes Drupal unique, special, is, in my point of view, that you CAN have a "content manager channel", a "admin view" (one of many heads), and ALSO serve content for many channels/sites/front-end frameworks via APIs. You already wrote about progressive decoupling and I think this could be more explored by Drupal. (My idea was to build a content repository together with its FIRST site/access in Drupal, and then make its content available to other channels, but it became much more difficult that it would be in Drupal, specially because incompatibilities between modules and distributions).

3) Think about GraphQL! Not just for front-end, but even databases are using it as API - and the lack of connection with graph databases I think is a weakness of Drupal. Drupal already has a GraphQL module, that can be more integrated/explored.

Best regards!

Brandon Rotkel (not verified):

While I was very big on advocating for Web Components over JavaScript frameworks 3 years ago, I'm more inclined to believe now that Web Components are indefinitely stalled and not worth waiting for. I hope to see native support some day, but Drupal should be building for what people want to do today, and if it's worth it, we can refactor in the future for Web Components.

See: https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/


Thanks for all the feedback both on this blog post and on the Drupal.org issue! I'm reading and listening before responding. I'll also discuss the feedback with the Drupal 8 core committers and Drupal 8 JavaScript maintainers.

@tonystar (not verified):

React could be great, it's just Vue seems to have everything over it -- so why we are still considering React whilst totally ignoring Vue?

1) Developers who have worked with both almost universally favor Vue, and 2) there are very few arguments against Vue actually presented, and never technical ones. I've dug for a long time to find a strong technical argument against Vue, but by all accounts it simply gives all the benefits of React but with added flexibility and a nicer learning curve.

I have nothing particularly negative to say about React, other than maybe a disagreement w/ the JSX choice. React is great, it's just Vue seems to have everything over it. And I do believe that for any sufficiently large open-source project, ease of onboarding should be considered an extremely high priority, and Vue definitely has the edge there. I think this is even more important with modern JavaScript, as we've seen no end of discussion from developers overwhelmed and frustrated by the explosion of complexity in the ecosystem.

React would work great, but I feel Vue would attract more devs. I think that's really essential for Drupal right now.

Quoted from https://www.drupal.org/node/2913321#comment-12288281.

g089h515r806 (not verified):

React JS is is forbidden by Baidu, maybe more big companies in China forbid it in future. It is a trend in China. Please choose Ember, Angular, Vue instead of React for China users.

Drupal7 (not verified):

Whatever JS framework you choose, the Drupal 8 RESTFul services are built using PHP in OOP code which means they are doomed to be slow (with all those crazy interfaces, gets, use, not use unnecessary German complexities). Any reasonable man today would simply use DotNet or J2ee or Scala to deliver super fast backends (tens if not hundreds of times faster endpoints than Drupal 8's Holy API) and use any JS library on the front end => Drupal 8 left completely out.

I think Drupal should keep its original goal to allow people build websites without any developer, take care of all forms/views etc.. all settings stored in DB with hundreds of check-boxes to tick before something reasonable happens :-)

As for React, why not consider Vue.js or you have not heard about it yet?

Good luck OOP :-)

Chris Weber (not verified):

I am very happy to see such support for the Web Components standard here. I have been a huge fan of the standard for many years because I see it as a way for all platforms (PHP, .Net, JS Frameworks, etc.) to find a way to share work in the form of frontend components. It seems like an idea (like AJAX) that once it takes hold will become part of the fabric of the web and stay around for a long time. An idea so good, that almost every framework that has existed has attempted to provide a series of reusable components. An idea so ingrained into the process of problem solving that every form of engineering has provided some what of reusing previously solved solutions to speed up the act of making the things. Again, I’m super opinionated on this point, and have been talking about it for the last 4 years, because it seems obvious that once a web standard rises to solve the same problem an add-on framework solves, the standard wins, because it’s everywhere.

Sure, a frontend framework could create their own component system, they could do all the work necessary for establishing an ecosystem of components and handle all the framework related issues of backwards compatibility, maintaining the internal meaning of the components, and providing the hooks and allowed interactions with the components. But why? Please read: https://infrequently.org/2017/10/web-components-the-long-game/ for a solid understanding of the pitfalls that are hopefully React will avoid.

For Drupal, when choosing a frontend framework to build advanced administrative user experiences, this choice will make a lasting impact for Drupal as a project. It’s really great that we have this call for input from the developers in the ecosystem. Knowing Dries and everyone involved, this is not a rubber-stamp decision. They really do care about the feedback from those that make Drupal a powerful tool for making web experiences. I also know that part of the decision to propose the adoption of React is born from the impressive nature of the platform and the vibrant ecosystem that brings wonders like GraphQL and Relay. We’ve all seen in previous Drupalcons the impressive demos and there is a lot of potential if we to move forward with it.

Speaking for myself, I need to see that React is as community-focused as Drupal. Many of the decisions, such as a lack of support for custom attributes and many more issues that break compatibility with Web Components are concerning.

You wouldn't want to use a browser that doesn't support HTML5. Why would we want a framework that doesn't support Web Components. Yes, React is working on it, there are several concrete patches they can accept to improve support. The roadmap is here: https://custom-elements-everywhere.com/ . But as you can see from that page, there are many frameworks that have better or complete support.

My concern is that choosing React over these options, in an effort to improve Drupal’s ecosystem by adding the benefits of React's ecosystem, we are making future work for ourselves when we want to free Drupal from the conflicts of a tool that doesn’t support the Web Component a choice to make Drupal to depend an ecosystem while locking Drupal out or making it significantly harder for Drupal to be apart of the larger ecosystem of component sharing that is certain to bloom out of the Web Components standard.

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.