Problem / Motivation

At DrupalCon Vienna, Dries proposed a new strategic initiative to test and research how our administrative and editorial UX could be improved by using a JavaScript framework. As a first step, we have to choose which JavaScript framework will be used as part of the research.

Proposed resolution

I discussed this with other core committers, all of the JavaScript subsystem maintainers, the Project Lead, and developers with real-world experience building decoupled applications using Drupal’s API’s. The group appointed me (lauriii) to make the final decision, as the core framework manager who specializes in JavaScript.

We all agreed that:

  • There is an imperative to solve Drupal's UX problems.
  • Drupal is now in a better position to leverage a JavaScript framework to solve some of these problems.
  • We need to continue researching this before making a final decision.
  • We want to have sufficient real-use experience to make a final decision prior to 8.6.0’s development period (Q1 2018.)

In the same discussion, we decided it would be more productive to choose one framework to research. Alternatives may be researched in parallel, by other contributors, but the core team will focus on the chosen framework.

Several options were discussed, and the unanimous consensus was React.

Next steps

  • Gauge community interest, and flesh out any hard blockers (this issue.)
  • Create a “proof of concept” project in React (Database Logging UI, for example) to give the core team real-world experience developing Drupal core features with React. This work will be done in a contrib project, leaving open the possibility to reverse course or experiment with alternatives.
  • Identify changes to our supporting infrastructure, (e.g. do we need new/changed build tools for packaging, testing infrastructure, etc.)
  • Research release cycle, and develop a plan.

Your feedback

Feedback is vital for our next steps. We would like to hear from you about your experience with React. The good, the bad, and the ugly. We want to get a sense of the broader community’s feeling about this direction, and ensure we catch any hard blockers, prior to locking it in.

Please keep discussion focused on whether or not React would be a viable solution for Drupal, not the promotion other frameworks.

Discussion will remain open until 23.10.2017, after which a decision will be made how best to move forward into an experimentation phase.

Benefits of React

  • Large ecosystem of over 16 000 libraries.
  • Very active and friendly community of over 1000 developers.
  • Proven maturity as a project, and backed by a community with a vested interest in its viability as a project.
  • Used by other big projects such as Facebook, WordPress, TYPO3, The New York Times and Airbnb.
  • Licensing concerns of the past have been resolved (now MIT).
  • This move will embrace frontend development trends from the broader web development world and bring them into Drupal.
  • Improve career options for classical Drupal developers

Challenges

  • React’s release cycles are faster than ours, and we need to be able to accommodate this.
  • Theming experience for decoupled UIs will change, and use React’s approach instead of what we currently have.
  • Modularity.

Getting started with React

React is a JavaScript library for building user interfaces. It is maintained by Facebook, Instagram and a community of individual developers and corporations.

If you’re new to React, here are some great resources on how to learn it:

Further reading

Alternative approaches

Sign-offs

  • Dries (Core Product Manager, Project Lead)
  • lauriii (Core Front-End Framework Manager)
  • effulgentsia (Core Framework Manager, Technical Working Group)
  • xjm (Core Release Manager)
  • yoroy (Core Product Manager)
  • webchick (Core Product Manager)
  • droplet (Core JavaScript subsystem maintainer)
  • drpal (Core JavaScript subsystem maintainer)
  • nod_ (Core JavaScript subsystem maintainer)
  • dawehner (top core contributor)
  • eatings (Technical Advisor)
  • hampercm (Technical Advisor)
  • justafish (Technical Advisor)
  • prestonso (Technical Advisor)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lauriii created an issue. See original summary.

Greg Boggs’s picture

Yay! WordPress using JavaScript in Core has really helped them mature their REST API platform. And now that React is Free software, I can't wait to see it happen.

markconroy’s picture

Hi @lauriii,

Can you flesh out a little more what this proposal means, I am getting these two messages from it:

1) We need to decide if we are going to add a JS framework to Drupal Core
- This will be a yes or no answer
- If no, then we leave things as they are - nothing to add, if yes - see point 2 below.

2) We now have consensus on which JS framework is going to be chosen, and it is going to be React.
- I am not sure if I am correct on this point, but this paragraph is what I am basing my thoughts on:

In the same discussion, we discussed which framework we should use in the research. Consensus was React, as our preferred option, though a couple had named similar options as well. However, there was unanimous consensus among the group that React would be a good choice.

Does that seem a fair summation of the issue?

phenaproxima’s picture

I do not have any real-world experience building UIs in React, but I am cheerleading for the idea of a JS framework in core that will allow us to build more modern UIs. I think this has been a long time coming and I'm excited to see us adopt it at last!

Speaking as a maintainer of the Media subsystem, I think this is something Media could hugely benefit from, especially with regards to dragons like #2831940: Create file field widget on top of media entity. Our desired user experience for Media already pushes Form API well beyond its limits, and we agree that trying to achieve our UI goals with just core forms and AJAX is going to be, in a word, a nightmare. We think a JS framework like React would greatly accelerate development, and allow us to provide a more attractive UI for our users with less effort on our part than it would take to fight the core forms systems.

dawehner’s picture

Just a small comment about the bit called "modularity" in the issue summary.
There are a lot of questions opened up:

  • How do modules add new UI parts?
  • Are modules able to register new routes (In whichever router implementation we use)?
  • How is state management done to scale from smaller components/single UIs like the dblog example to the entire application
  • Are we gonna need a build step/transpile step and in that case are we gonna need to somehow deal with modules as well?
  • People like JS frameworks because they don't have the crazy abstraction layers and magic of Drupal, so how can we ensure that we don't add them again to get the modularity we need?

I think there are a lot of questions which are opened up as whatever we will deal with will not be a typical react application.

dawehner’s picture

Issue summary: View changes

I'm also adding a point about react being helpful for the career of classical Drupal developers.

btopro’s picture

+1 for talking about JS and adopting something. -1 for React as it has rather aggressively said it will not adopt webcomponents, a W3C spec that allows greater interop between frameworks / libraries. https://custom-elements-everywhere.com/

It sounds the decision has been made already associated with this "proposal" though so oh well.

prestonso’s picture

Dries has articulated his thoughts in a blog post: "Drupal looking to adopt React".

effulgentsia’s picture

-1 for React as it has rather aggressively said it will not adopt webcomponents

Where have they aggressively said this? In https://reactjs.org/docs/web-components.html, they say: "As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.". https://custom-elements-everywhere.com/ identifies some gaps and links to open issues, but has React said anywhere that they refuse to fix them? Also, could you shed some light on how those current gaps identified in that link would impact Drupal if we were to start using React for admin UIs?

prestonso’s picture

Issue summary: View changes

Adding link to Dries' post into IS in a "Further reading" section.

effulgentsia’s picture

It sounds the decision has been made already associated with this "proposal" though so oh well.

From Dries's blog post in #8: "Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place."

So, please continue providing relevant feedback about this.

Rene Bakx’s picture

I would like to vote against going the React route, and my vote agains React has nothing to do with the somewhat notorious owner of React (Facebook) and surely not because of the now solved licence issue, but more because of the complexity that React brings to the table. Especially the JSX template syntax that won't run without a transpiler build/development flow making it less trivial for some developers to get into it.

For example, support for webcomponents is possible with React, but only in a more complex 'React' way, see this example and partly for reasons like Fago described in the meta parent issue of this issue

We, as a relative small team, tried to build a few frontend projects/testcases in React, but it quickly became a problem with the now defunct two way binding mixin (LinkedStateMixin) and our frontend developers had the feeling they needed to write way more and complexer intertwined code just because of the way the framework demands things to be structured and declared (not bad, but needlessly complex)

We had a strong feeling that React is more aimed as seasoned Javascript developers, perhaps even more complimentary to projects being done in NodeJS as a backend. Eventually it lead up to our descision to ditch React for frontend projects and switched to a lower, more 'average' or traditional javascript developers orientated entry framework (VueJS in case somebody wonders about it).

React bring a level of code complexity that I seriously doubt will help pushing our Drupal community forward. It (gut) feels to me, that it has the same challenge, namely the lack of skilled developers, that the introduction of Backbone to D8 core brought us.

codycraven’s picture

As a long time Drupal developer I have become disillusioned with Drupal over the past few years because of my perception that Drupal is unable to keep up with modern web development.

I firmly rooted this perception in Drupal's tight coupling of presentation with CMS backend which has caused me an enormous amount of efficiency loss as demand for more interactive frontends has increased. This has on nearly every occasion resulted in a poor compromise in one or more of the following:

  • UI/UX (from poorer design)
  • UX (from long round trips to backend)
  • Diminished long term maintainability of the delivered product (due to tight coupling with Drupal internals - frontend developers must have a very deep understanding of Drupal internals to deliver quality)
  • Complete re-build being required as Drupal internal change

Decoupling the backend interface of Drupal would result in a huge shift in the development of Drupal as a whole. Forcing a clear separation between design and API that would result in asymmetrical improvements to the platform. UI would be untethered from Drupal Core upgrades allowing the best admin/editor experience possible at any particular stage of the lifecycle. It would also allow those UIs to span Drupal releases, requiring change only as the exposed API changes.

When working outside of Drupal, most of my experience over the past two years has been with React or React/Redux. I'm a huge fan of the ability to easily reason about state changes and the render performance the system provides.

The only major flag that I would like addressed is how compilation of JS will be achieved. Whenever I have used React I have done it with the intent of building a specific interface. I have never built a project that can handle React components not bundled as part of the JS compilation (for example a contrib module that creates a new field type).

My initial thought would be to have sites compile their own JS bundles, which would give power site builders full control over their interfaces and would need to be balanced with a very simple process for non-power users that utilize Drupal as a system of contrib modules.

Jaesin’s picture

In my opinion, this should be addressed in contrib and supporting issues in core should be taken seriously as a matter of possible future adoption of the loosely coupled front end. And using the loosely coupled front end should be optional.

There are serious drawbacks/costs and added complexity. See: https://www.lullabot.com/articles/the-hidden-costs-of-decoupling

prestonso’s picture

#12: Especially the JSX template syntax that won't run without a transpiler build/development flow making it less trivial for some developers to get into it.

I also have a lot of qualms about JSX, especially the camel-casing of attributes, but it's important to note that JSX is not a requirement for using React.

#13: Decoupling the backend interface of Drupal would result in a huge shift in the development of Drupal as a whole.

That's in the scope of a different issue, #2645666: [policy, no patch] Require Node.js for a future Drupal major version and rewrite some of Drupal's UI code from PHP to JS, which argues for what you recommend. This issue is solely about an incremental approach and experimentation within our existing UIs to verify that React is a good fit.

Bcwald’s picture

Why is the initial discussion for improving the Admin UX focused around selecting a technology addition? What features for an Admin UI are currently not possible without using a framework like React?

Focusing on components that need improvement, then determine what technology is needed to achieve that seems like the right starting point.

StevenPatz’s picture

What about the lack of accessibility when dealing with React?

btopro’s picture

lauriii’s picture

#3: We now have consensus on which JS framework is going to be chosen, and it is going to be React.

The decision hasn't been made yet so please continue providing relevant feedback.

#12: Especially the JSX template syntax that won't run without a transpiler build/development flow making it less trivial for some developers to get into it.

This doesn't change anything in core since we already have a transpilation process because for being able to use ES6. What is still unknown, is whether it will be a hard requirement for contrib projects to transpile their code. It isn't necessarily required since JSX nor React has a hard requirement for that.

#14: In my opinion, this should be addressed in contrib and supporting issues in core should be taken seriously as a matter of possible future adoption of the loosely coupled front end. And using the loosely coupled front end should be optional.

1. Good point! We actually already discussed that the experiments made before the final decision would be made in contrib rather than in core. This also makes the decision easy to reverse if something critical pops up.
2. The plan currently is to only use decoupled architecture by default on the administrative UI's.

#17: What about the lack of accessibility when dealing with React?

Could you explain more in detail, what kind of problems should we be aware?

codycraven’s picture

#15 This issue is solely about an incremental approach and experimentation within our existing UIs to verify that React is a good fit.

Absolutely, I'd imagine performing this test work will require a frontend consumable API to be created (if one doesn't already exist for the Database Logging data).

This change to a creating a first-class consumable API would lead to the "huge shift in the development of Drupal as a whole" I cited. If Drupal had a proper first-class API I don't think this initiative would be needed at all, as community members would likely band together to spin up their own React/Vue/etc user interfaces.

However unless Drupal Core eats its own dog food I have little hope that a fully compliant API would ever be successfully created/maintained.

btopro’s picture

if this is open then... React would be to Drupal as jQuery was to Drupal. Suddenly every plugin will be whatever + React much like everything was whatever + jQuery. Web components / Custom element spec would allow developers to pick up stream what front-end lib to use. React in core components (of any kind) would effectively kill any project fighting against the current of the community on this one.

2 cents in for webcomponents / vanilla web components at that. There's lots of exciting things happening surrounding Stenciljs which compiles down to raw custom elements (as opposed to Polymer / Skate.js which run at build time).

Point being, this tech is like a level below React and people could then use it with whatever framework they wanted to bring for UI. I'd also share the concern about decoupling as we don't do that fully w/ the webcomponents module (worth seeing what we're doing w/ that tech if your not aware of the difference between Polymer and React/Angular worlds - https://drupal.org/project/webcomponents)

Rene Bakx’s picture

#16 Why is the initial discussion for improving the Admin UX focused around selecting a technology addition?

That's the nature of a developer (guilty as charged), we are trained in looking at a problem from a technical solution angle, instead of a more meta point of view. We are very good at answering the How question, less skilled at answering the What one ;-)

We need more of the What skilled people in Drupal ;-)

btopro’s picture

Was encouraged to add more here:

We did things in Angular so similar worldview at least (yes, React a bit lighter decision wise I know) and completely abandoned it for the web component world view. You can see that part of our talk from Dcon Baltimore here -- https://youtu.be/dGi8n1LAQbg?t=21m37s

Basically, Angular started forcing every decision to be angular and we were fighting against every other aspect of Drupal's front-end. When we switched to webcomponents it created a sustainable path forward where we could bother decoupling in the first place. We started by making purely design components, so in admin UI land maybe that's the watchdog paged results. You'd look for a component on wc . org; in our case probably https://www.webcomponents.org/element/vaadin/vaadin-grid which is an amazing paged-results broker.

The important thing is that these custom elements effectively become versionless. Yes, these are built on Polymer and so we have a version of polymer running to prop them up, but Polymer is about compatibility between versions, and also isn't required to use custom elements. There's a lot of things on webcomponents.org which do not require a framework or library (or use different ones). The goal of webcomponents is completely interoperable custom elements / tags. This would net React developers (and Angular, and Vue, and framework someone just made up now) the ability to tap into Drupal's element tags and extend them / build things with them.

Building up from design components, you can start wiring them together; Here's a replacement for the Drupal commenting system that we built out of two custom tags we made (1 handles the comment, the other helps w/ communication between comments) https://lrnwebcomponents.github.io/lrnsys-comment/components/lrnsys-comm...

Attacking a hard problem w/ a simple solution:

Drag and Drop file uploader as a single tag / handful of lines of PHP: https://github.com/elmsln/elmsln/blob/master/core/dslmcode/shared/drupal...
Video explaining it / showing the developer UX side of things : https://www.youtube.com/watch?v=tDiRRvYCmG4&t=87s

Next tag I do could be in Skate.js, or stock web component spec, or Stenciljs (which Ionic just released; they are actively getting off Angular and over to web components) or x-tag (all of these can produce elements). While I haven't tried it I've also read that Vue.js can output in a method similar.

nod_’s picture

For more context, #23 could solve in a more elegant way some challenges we might have with React regarding: theming, modularity with contrib (performance maybe?).

(adding that since the aim of this issue is to give reasons not to go with React. The issue should not be about library/solution promotion).

thamas’s picture

@effulgentisa When the title of the issue, and also the title of the blog post proposes the use of React it doesn't seem to have any real chance to not see React in core sooner or later, even it is "after discussion and experimentation has taken place".

Otherwise I know that it can be an endless debate and there will always be lovers and haters of any framework. There must be a decision and time will tell if it was right or not. We had admin overlay in core too which was later removed.

To be honest I have no practical example with JS frameworks I've just read a lot about them. What makes React unlikable to me that is the CSS in JS thing. From that point of view such a thing as Svelte or Vue seems to be much likeable.

lauriii’s picture

#25: What makes React unlikable to me that is the CSS in JS thing. From that point of view such a thing as Svelte or Vue seems to be much likeable.

For some reason, many React developers seem to like that approach. Luckily React does allow more traditional approaches for loading CSS than JS-CSS.

attiks’s picture

Some background reading from an expert (might be biased): "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." https://infrequently.org/2017/10/web-components-the-long-game/

Z2222’s picture

I think something like Vue would be a much better choice than React. Vue has a much easier learning curve, is well established in the PHP community.

btopro’s picture

Not aware of a performance issue w/ React (future of react that is); issue would be more in DevUX things; and unfortunately the HTML in JS / CSS in JS stuff seems to be the future unfortunate direction of many libraries at the moment ;) so that's not uniquely bad to React (Polymer v3 which is in development will operate this way too).

I'd say yet another thing to keep up w/ the exact versions of would be the biggest negative in my mind w/ any library / framework. I'd add another thing for background reading / watching: https://www.youtube.com/watch?v=c-WDHG6rrdU&feature=youtu.be

This is the author of a new CMS called Simpla. In it he specifically calls out the awful author UX of systems like drupal and wordpress (both by name) and demonstrates a concept of component architecture where the components are self-aware of how to modify (think contentEditable property on steroids). This is something we've played with as well in prototypes where components we use for design have a built in mode for editing (think drupal edit module) which then can be activated by another tag. This shows the idea running in a View where the view told components to be it's display mode https://www.youtube.com/watch?v=0VDIRnxphCk&list=PLJQupiji7J5fCE__ixLNvA...

Also to clarify - I'm not trying to champion what we're doing or Polymer specifically, just pointing to non-React world view for attacking complex problems and how others off the island are handling this. These methods are fundamentally different from React (at least as far as I've seen thus far). Web component world view we could make a tag which Drupal could wrap on anything in the front-end that the current user has access to edit in some way. Then a design tag; let's say could know how to display itself but also how to edit itself and would be there listening for the tag in order to invoke it into "edit mode".

React world view would more so be "let's build an app that does that" and all the components you'd build would work in React apps and with other React apps (sure) but would all be required to play nice. The previous example, we could easily integrate the tag in Drupal 7 (or Backdrop or whatever) since it shows up via a JS Module / HTML Import methodology. The logic of talking to drupal in the tag is doing all the heavily integration work which then allows attacking that problem space next. If that tag was able to talk to drupal correctly (variable_set('system_time') or whatever silly D7 thing).

This would be a decision point akin to Drupal saying it will be evergreen except on the front-end. Other developers adopting components into their workflows would also not have to worry about hiring specifically React developers only to find "well crap, now we can't get off the island for this project bc of front end hiring". Much in the same way Symphony on the backend helped unlock paths to other islands and developer talent pools on the backend, this is that inflection point for the front end (imo).

berdyshev’s picture

I've some experience with React, not only standalone web-app, but also integrated with Drupal 8. The result is perfect, but I faced some limitations and issues:

  • I had to implement custom "routing" - thanks the site was simple.
  • the transpilation and packaging required to build independent app in theme's sub-folder and attached to every page using library (with some alters), which also has its caveats.
  • API modules (REST and JSON API) are not something that is comfortable to work with, especially when we are talking about config entities -
    the main data source for admin UI
  • react's templating (JSX) doesn't suppose the usage of Drupal templating system and twig

So, in summary, I like the idea to have modern front-end framework, and specially React, in Drupal core. But for now, I see the only possible way: decoupled front-end and Drupal just like a backend - an API-first initiative should succeed.

Maybe we can consider another, more lightweight solution, like VueJS just for UI components, which doesn't require transpilation and could be used just for components with some drupal-related addons/plugins/helpers. It also has more lighter learning curve.

dankegel’s picture

For what it's worth, React has a good reputation here as very debuggable. (I haven't used it myself.)

And supposedly it supports accessibility; see https://reactjs.org/docs/accessibility.html

corbacho’s picture

+1 for React
Months ago I personally stepped out of Drupal frontend jobs and focus only on React, because it's really obvious how React is transforming the way we write web/mobile apps. I would be really happy to see two of my favourite OSS projects working together

React is mature, proven technology. It has a small API surface, so it's easy to learn and is becoming the standard "frontend layer" for all devices, not only web. Facebook has shown they know how to nourish the community and ecosystem around React.

Vue it's another very good option, easier for beginners and good documentation I would support too.

There are other promising technologies and frameworks but are not still "there" for massive adoption.

aleksip’s picture

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”.

jrockowitz’s picture

+1 for React... more specifically +1 for a deciding on a front-end framework for core.

As the maintainer of the Webform module for D8, I would like to add that the Webform module would significantly benefit from having a front-end framework like React in core. Developers are already starting to build React front-ends for the Webform module.

On a very personal note, I would love to start learning and mastering a front-end framework like React and trust all the people listed under @Sign-offs to make an educated decision.

segovia94’s picture

Overall I'm in favor of a framework. However, a big question for me is how many PHP developers are going to easily pick up React? I know we want to bring in more Javascript developers, but it seems that most people creating modules and using this will be coming from a PHP background. I know pure javascript guys love React, but it will likely be a steep curve to others in Drupal's already steep learning curve.

I'm not a fan of JSX. How long have we been yelling at PHP developers to not stick their html into their php and instead direct them to call a template? Templates are easy to read and make sense to those who come in after the fact and can easily see what their output will look like.

I saw that the issue summary said not to argue for another framework, but it seems to me that Vue.js has all the benefits of React with none of the downsides. Did the consensus around React happen simply because those deciding already had experience using it? In their use, was it building SPA's or did they ever try integrating it in an existing Drupal site alongside Drupal's other javascript? How "nice" is React going to play with current Drupal admin stuff since we are trying to build this progressively and not doing a wholesale rewrite? It seems that if we are wanting to build this progressively it might make sense to look at the framework specifically titled "The Progressive JavaScript Framework" (vue).

Anonymous’s picture

What's the point of this issue if there's already the mentioned #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs with 217 comments already? Is this to promote react again(the bias is strong with this issue)?

PS: I picked Vue from all available frameworks and that is the only reason I do not want to learn new FW again. But objectively, the web components are the only true solution here. Anything else is just plain wrong.

Also, without API-First initiative reaching its goals, I really do not see any point in conversing about this right now.

imclean’s picture

This is a very interesting topic but I'm a bit curious about the choice of React. In the issue summary under "Benefits of React" there is no mention of DX, ease of learning, performance, compatibility with existing frameworks or anything which might specifically be related to developing in React and integrating with Drupal from a technical perspective. Nor is there mention of the benefits of using React specifically from a user/Site Admin perspective, possibly because the benefits would be similar for all JS frameworks and best suited to a separate discussion.

dawehner’s picture

Also, without API-First initiative reaching its goals, I really do not see any point in conversing about this right now.

As far as I understand its rather the other way round. We will use a framework so we can finally push forward and dogfood our internal APIs, and by that actually reach good APIs.

yoroy’s picture

@imclean all those considerations would be part of the experiments/research that the team wants to do.

imclean’s picture

@yoroy, thanks. Does that mean testing multiple frameworks for the same task? For example, database logging using both React and VueJS?

RainbowArray’s picture

I spent a lot of time and energy arguing against putting a JS framework in core last year to the point where I really burned out.

I think at this time it's worth giving React in core a shot.

We're not talking about rewriting all of Drupal's JS at this point, we're looking at using React for one particular component, then learning from that experience. Built in to that is the possibility that if it doesn't work out, it's possible to back out and try something else.

I think there are definitely good arguments for looking at web components, and Vue appears to have some advantages. That said, arguing back and forth on that for days, weeks or months is unlikely to produce a consensus. I havre a lot of trust for the people who were in the room where the consensus was to try moving forward with React, and I think it's worth giving those folks the benefit of the doubt to move forward.

For those who are interested in experimenting with web components or Vue or X, contrib is a great place to experiment too. Making a module that demonstrates in a similar way how one discrete component could be implemented might be a really useful experience. But it's also worth letting folks work on using React in core, because the high bar for core development is likely to show a lot of things that work great and also demonstrate challenges, as well as the ways those challenges can be resolved.

To me, that seems a lot more productive than lots more arguing back and forth. There are very valid points of debate that can be made on multiple sides, but the debate itself can be exhausting, and it would be great to see that energy go into experimentation instead.

The one point I want to add is that one of the original goals of the JS framework discussion was to improve state management in Drupal. It seems worthwhile to consider if Redux would be useful in conjunction with React in order to handle state management. That might be overkill for one component, but if this is something we may end up using in lots of components, maybe? I'm no expert on any of this, but I have a lot of co-workers that like working with React, and it seems like they also work with Redux a fair amount as well, and I trust their judgment.

PI_Ron’s picture

+1 VueJS

benjy’s picture

I've used React this year and last to build a combination of entirely headless apps and progressive apps where we've built React components and loaded them into existing D8 sites for specific features. To comment against a few points made here:

However, a big question for me is how many PHP developers are going to easily pick up React?

The learning curve for me as a PHP developer when I started out last year had nothing to do with React and everything to do with what JavaScript looks like now. Webpack, Babel, ES5, ES6, ES7 and all the new syntax that go along with it took a few days of learning. Once you've learnt those things, React is easy to get started with.

I also have a lot of qualms about JSX, especially the camel-casing of attributes, but it's important to note that JSX is not a requirement for using React.

Other than ticking some box that says, "o, but you don't have to use JSX" this is pretty much out the question. I tried to build a FieldWidget using React with the non JSX approach and it's completely unrealistic, the verbosity is pretty much insane for even simple tasks.

For some reason, many React developers seem to like that approach. Luckily React does allow more traditional approaches for loading CSS than JS-CSS.

The first 3 projects I did we started with React so we did CSS in JS as the community seemed to favour that approach so it made sense to give it a try. With my most recent project, we already had a styleguide of components so we're using the traditional CSS + using CSS classes in our React components. Can honestly say, I much preferred the inline CSS in JS, keeping it all together is so much easier to work with as the app begins to grow.

How "nice" is React going to play with current Drupal admin stuff since we are trying to build this progressively

There are no issues here, I have more than a few examples of standalone React components running within a Drupal 8 site that enhance specific functionality without any issues as all.

larowlan’s picture

+1 for writing a component in a handful of frameworks and comparing the result of each.

I'd like to see that beforehand. Then we could talk about code rather than abstract concepts.

And I think the emphasis needs to be on vanilla js + components + glue code so we can pivot if {something shiny} comes along. We move very slowly, and if we've learnt anything from adding backbone it would be best if we write as much as vanilla JS and keep things decoupled from the framework. That way if we need to replace the selected framework later... we can do so easier.

I'd like to see the issue summary mention what elements in the admin UI would make ideal guinea pigs for testing/evaluation.

benjy’s picture

Cross posted with mdrummoned but:

It seems worthwhile to consider if Redux would be useful in conjunction with React

Yes, a state management library like Redux will definitely be required at some stage, probably sooner rather than later so all core code can consistently be developed using the flux pattern.

If you're pulling in a list of data, you can avoid it but the second you want to have data created on the client and sent back to the server, I've found a solution like redux to decouple your presentational components from state management and API calls is pretty essential. There are other ways like having your own lightweight data sources (as documented in the React docs) that work well for pulling data down but still never let me avoid Redux entirely when I started pushing data back.

neclimdul’s picture

Im a little confused as this doesn't seem like a it was up for community discussion. I'll offer my opinion anyways, I am strongly for vue and think it is a much better fit for our community and Drupal as a platform.

Edit: I see reading the comments closer that we're still discussing. IS might be a little more clear.

dmdewey’s picture

I've developed applications in Angular 1.x, React , and now Vue.JS. My first choice would be Vue.JS because I see it as taking the best parts of Angular 1.x and React and combining them into something that is very straightforward and easy to learn. That said, React's adoption is higher (as is its learning curve) so it would not be a terrible choice. However, you might actually help Vue.JS (slow?) adoption if you chose to use that to power Drupal's administration interface. It's probably too early to tell about VueJS but it's my favorite by far.

Yaazkal’s picture

As I mentioned on Twitter to Dries, I think this can be a great example and excersice to do: https://medium.com/car2godevs/how-car2go-chose-a-frontend-framework-86b4... and to have fun.

dakala’s picture

+1 for writing a component in a handful of frameworks and comparing the results

The experience of car2go is quite interesting. We may select 3 or 4 frameworks (React, VueJS, Angular, VanillaJS etc). If the task/component is a simple one, it won't take too long but at least we can compare them based on some criteria such as the car2go devs had which I quote below:

  • Documentation
  • Maintainer activity
  • Questions and answers on the usual platforms
  • Available tooling
  • Amount and quality of plugins or extensions
  • Web technology standards
  • Setup Time (setting up the build and support for things like sass, custom fonts, etc)
  • Code style, API Design
  • Extendability
markusa’s picture

I think that btopro's comments warrant attention and I want to give them a big +1

The web component stuff is really awesome and has been developing steadily over the past several years in capability. People use Drupal for a great many use cases that are more expansive than marketing or static content websites, such as learning management software.

The challenges of creating good learning content I think are greater, because you are often dealing with much more interactive and complex content. People want a way to build this interactive content, with an end goal of a content creator having the ability to edit content much the same way as you would layout and develop a Flash app.

To achieve this type of functionality, lower web component libraries need to be able to be used in conjunction with one another and a framework that supports this and ties it all together in Drupal Core would be a huge boon...

React may scratch the JavaScript itch now, but conceptually there are deeper, more robust possibilities on the horizon and knee-jerking into React may prove immature, and regrettable in 5 years. Not supporting web components would be a mistake.

Niklan’s picture

+1, very good decision. Tried React and fall in love with it, also interested in VueJS and think Vue fits better for administrative UI, because it's easy to use when it's only necessary.

UPD. Tried VueJS as well in real project, and prefer it over React for now. It's very transparent how it works, and can be seamless integrated in drupal as full fronted framework or just for simple parts where it needed.

nod_’s picture

Again I would like to remind everyone of the IS that define the scope of this issue: "Gauge community interest, and flesh out any hard blockers (this issue)" Advocating for a different solution without pointing out major problems with React would be better suited in the other issue #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs.

About web components, there is an initiative in core about the topic see: https://www.drupal.org/about/strategic-initiatives#planned Making an admin interface with react doesn't prevent us from developing/supporting reusable web components for non-admin interfaces.

adubovskoy’s picture

+1 for VueJS. Vue is much more easier for delegating subtasks (better template/logic dividing) in teams.

Kingdutch’s picture

I am a big fan of React but one of its harder parts and I think something that Drupal might run into as well is server side rendering. React provides support for rendering both on the server and client side (if you have a javascript runtime on both) but this isn't always tricky. I think it might be especially difficult if you already have a server side router in place in the way Drupal has.

If we can ensure that clients without javascript still receive an experience that works, then by all means, lets get this in core!

Rene Bakx’s picture

I don't think that server-side rendering is a valid option, unless it can be done via PHP. Running NodeJS and PHP on the same vhost is adding a complexity that is not really desired, same as setting a host for admin, host for frontend and a host for API/Backend. Perhaps for more ambitious projects not a problem, but for simpler projects a unovercomable problem

MiSc’s picture

Putting something like React into drupal - is for my point of view a really bad idea. This will make the introduction to Drupal even steeper - and much harder to keep core intact with security updates - look at the deprecated external JS-stuff we have in core already...

I have no objection in adding a JS-framework per see, but this is the wrong choice. React licensing module could easily be moved to something else than MIT in the future - it is in all in the hands of Facebook.

And like stated before - choosing a JS-framework before we even know what we want, and how it should work, is wrong.

aleksip’s picture

Facebook chose to relicense React under the MIT license, which does not mention patents at all. I find this interesting, because Facebook has told us that the additional patent grant in the BSD + Patents license was “designed to ensure that developers can use our projects with confidence”.

React was initially released under the Apache 2.0 license, which explicitly covers patents. So why didn’t Facebook now relicense React under Apache 2.0?

As far as I know, the MIT license has not been tested in court regarding patents, and there are differing legal opinions on whether the license covers patents or not.

The MIT license is a popular license, also used by projects like Angular 2, Ember and Vue. Avoiding all projects that use the MIT license would be a very limiting decision.

So it all boils down to trust. Should we trust Facebook? I don’t, and I don’t think the Drupal community should either.

deadbeef’s picture

I'm with @MiSc on this one. If we must have a JS framework for Fat-Client Drupal, tying it to the whim of FB's current licensing policy is madness.

acouch’s picture

Big +1 for moving in this direction. Either Vue or React would work well IMO. @benjy articulated well my experience with React as someone coming from Drupal. The current JS tool chain was a higher learning curve than React itself. However there is a big difference between create-react-app and react-boilerplate. The learning curve for any React app can greatly vary depending on your approach to state management. Once the community decided on a path (ie Redux vs Mobx) for core it would greatly simplify adoption for devs. This is partly why it is important to do this in core so that there aren't 5 ways of doing this bubbling up from contrib.

Improve career options for classical Drupal developers

This is a big point that deserves emphasis. There is at least 100x the amount of React/Vue work out there.

One thing I see that keeps getting mentioned is the fear that including React will add additional barriers for new devs. I think this point carries a lot less weight than it did 5 years ago. Drupal is no longer suited for new devs anyway and more new devs than not will have some experience with a front-end JS framework before Drupal.

drubb’s picture

So a decision towards React has already been made, now followed by an evaluation phase? Sorry, I think this is the wrong sequence. I really can live with React, but the decision should not be based on the fact that some core developers have experiences with React already.

What do we want to achieve? It's all about modernizing Drupal's Javascript codebase, e.g.

- embracing modern JS features / styles (ES6/ES7, OOP, ...)
- adding a new JS framework to improve UI elements, administrative or not

The first point is vital and independent of the second one. The second one means adding a replacement or addition (really?) for jQuery in core, and maybe for Backbone.js (never used it actively).

I'd like to get a lightweight solution, that's why I'd prefer React / Vue over Angular / Ember. But there are multiple things to consider, like developer experience, license issues, learning curve, building / testing tools, distribution, standard compliance, and more. So there has to be a careful evaluation, without pressure to get this thing in with Drupal 8.6

My suggestion would be:

- taking two or three adminstrative pages as test objects (may it be watchdog, modules list or even a views page)
- adding two or three experimental modules to core (maybe one for React, one for Vue, whatever) that replace the current core markup / js for those test pages.
- comparing / evaluating the results
- discussing the results with UI people, frontend people, backend people
- watching what other frameworks do, e.g Wordpress using React (again?), or Laravel embracing Vue
- come to a final decision

And I'd consider the result a big move for Drupal, so maybe one major change starting in Drupal 9.0

- Disclaimer: just my 2 cents as a backend developer -

davidhernandez’s picture

Isn't the eventual intention to do this work in contrib, not directly committed to core until it is ready? If so, then other solutions (Vue, Web Components, etc) can also be worked on to compare, yes?

sarathkm’s picture

+1 for VUE JS. Simple, elegant, debug support faster rendering and lighter, easier to using with any build(babel etc)... Also best documentation to start with and build better apps... Easier for new developers to jump into Front End dev band wagon...

http://www.dotnetcurry.com/vuejs/1372/vuejs-vs-angular-reactjs-compare

VUE allows already uses best of both angular and react, also angular people will find it easy to jump in VUE.

We can also utilize JSX in VUE with few modification...

https://vuejs.org/v2/guide/render-function.html

So we can take advantage of having VUE in core from four ends.
1. People aware of Angular can shift to VUE easily
2. People aware of React can shift to VUE easily
3. People aware of VUE will jump into Drupal wagon.
4. Faster learing option as it has best docs will allow new devs to jump easily.

Besides it can be used from small to large scale projects.

Alibaba, Laravel, Gitlab are some examples of using VUE.

https://hackernoon.com/debate-vuejs-vs-reactjs-9d2a8867b69b
https://about.gitlab.com/2016/10/20/why-we-chose-vue/
https://medium.com/the-vue-point/the-state-of-vue-1655e10a340a

btopro’s picture

+1 for comparison work. The "camps" that would be worth having examples for comparison would probably be

- ReactJS
- Vue.JS
- Vanilla / Polymer based Webcomponents

If a common problem to attack would be expressed that might help for scoping an initial ABC test if anyone is interested in doing so (I think watchdog / dblog page was suggested). If anyone wants to learn / make a Polymer webcomponent world view example I'd be happy to help mentor (look it's mostly done already ;) https://www.webcomponents.org/element/vaadin/vaadin-grid + https://www.webcomponents.org/element/PolymerElements/paper-dialog)

andypost’s picture

I suggest to postpone the issue on top of related one

Adding another level of abstraction will reduce contribution to core much more https://twitter.com/nod_/status/912010971207671809

patrick.thurmond@gmail.com’s picture

If you keep it in the admin theme and out of core then you have my support. But React should not be directly integrated into core. That would just force another tool on people. Many of whom have moved on to better tools by now.

Rene Bakx’s picture

Extending my views expressed to mortendk and btopro on Twitter, but with more words then a 280 char limit

I see two challenges that need to be taken in the foreseeable future of the 8.x series.

1. The FAPI / Admin theme layer/system.

That's where @mortendk among others spend a lot of time thinking about for the past year or so and imho is the most urgent part that needs to be 'fixed' and moved to a modern stack.

2. The frontend theme layer.

In the current Twig state, the system is not 100% perfect, but way better then we had before. We finally have almost all control over the HTML output we need to build project upon. This imho will do just fine in the 8.x series, and has no real need for a JS system build into core. Yes it could use one, but nobody is stopping you from implementing on in your custom theme.

Addressing elephants

The problem to me is, somehow the decision seems to made that challenge 1 can be solved with React. And in a way that's correct, but to me (and lots of others given the current noise surrounding this pick) it was not the best choice for the problem and more importantly it skips the whole issue with the lack of unity in the contrib sphere in extending the FAPI system in general. Before we pick a system like React, VUE, StencilJS or whatever next months flavor is, we need to address the real elephant in the room and design a system where most of the current FAPI/Admin issue's can be tackled in. A more flexible extendable system perhaps based on the current FAPI, but still dictates UX to the end users. If we skip that step, we are not solving a problem, we are creating new one upon the current one.

Some of us look at wordpress for the excellent UI, and yes it is prettier then Seven... But it is only pretty for plugins that ship with Wordpress out of the box, almost all plugins implement their own 'UX look' which turns it into a messy experience for users. Drupal does it better by providing a system like FAPI. But in the current landscape of JS/UX it is not sufficient enough for the complexity we need. Think Views, Paragraphs etc. Steps are being made with the layout initiative, but that's only solving part of the puzzle.

And that's why I think we need people like Roy now more then ever on helping us solving this UX beast before we take the next step and picking a library to be included with core for the rest of the 8.x series. Yes.. the rest of the series, we can not expect that our developers/customers will buy it if we come to the conclusion that React was a wrong fit after we completely rebuild the admin layer in it. The same goes for every other system BTW ;-)

zanesensenig’s picture

+1 for deciding to seriously adopt a front-end framework. -1 for leaning towards React, the licensing issue has steered many high-visibility projects away from adoption (Apache, Wordpress) https://ma.tt/2017/09/on-react-and-wordpress/.

I support the adoption of VueJS in Drupal going forward. Vue is better supported by large php frameworks like Laravel. Additionally, Vue has a much easier learning curve for new devs.

alexdoronin’s picture

+1 Vue.js

We used Angular 1.x, React and Vue.js

React for php developers — steep learning curve.

— Comlpex, "non-native" (for backend people) JSX. It's hard to read, hard to understand.

— Bad documentaion.

— Defragmentation of "knowledge", quote from here https://github.com/facebook/react/issues/10784

Every time I decide that I want to learn React, I google and find some tutorial, from seemingly reputable sources. Then I try a few things, google more; go to stack-overflow and very quickly i realize that the syntax is different between different web-sites .. the API keeps changing, and I don't know if I'm looking at an old tutorial, or a new one -- I have no way of determining if a stackoverflow question is going to apply because of the version of React that I'm using.

— Always > 500 issues on GitHub (Vue has about 50)

— For non super-React-ninja person work with React it's like:
"What should I do here? Maybe the approach has changed? How do others? Damn, everyone has a different syntax!
Maybe the new version of React has been released? Does this version of the Router work with this version of React?
Damn, webpack config has errors with this version, doesn't do anything."

\\

Vue.js it's really more easier for beginners. And has great documentation.

nod_’s picture

All right, a few things:

  1. We heard and read the feedback from the other issue. Before going for React for building a prototype: VueJS and Elm came up, but given the broader context, everyone still agreed on React. Now there might be some informations that went missing in a way or another, hence this issue to make sure we didn't forget anything.
  2. React is explicitly for (some!) admin ui only. We're not touching the theming experience of the "public" website. Replacing the whole admin ui is not even considered for the near future (our APIs are not ready for that), only parts of it to see how it goes.
  3. Web components: there is an initiative around that for core. It's not forgotten. Will it surpass React for admin ui? who knows. For now it's exploration time on both subjects.
  4. Forms and JS frameworks, it's true that if not solved it'll be pointless which is why tim and matt tried out a few things to make drupal form api integrate with some react form components built by mozilla: #2913372: Allow forms to be defined in three segments: schema, UI, data
  5. You'll notice that Roy has been part of this discussion. He also moderated the Bofs around creating a new admin ui.
  6. In the first admin UI bof (at least) the consensus seemed to be that priority be given to the editor over the developer (UX above DX) so React being hard to learn for backend people is not as much an issue as it seems to be in my opinion. (And by experience there are so little backend developers contributing to core JS… even back when it was ES5 with no jslint/eslint rules).

I would like to point out that we've been talking about this for 2 years. Dries was extremely clear at the beginning that he wanted a framework in core, at that point contrib could have tried out many different frameworks. It didn't happen in a way that would work for core (or that was publicized for core). Maybe because contributing to core is painful, because of a fear of not being taken seriously, because putting that in place for core and contrib seemed too daunting, or because it was a friday. I don't think it was good or bad, it's just what happened.

To talk about the broader decision making in core: Core doesn't have employees, it's not possible to ask the community to implement a solution in X different frameworks in a specific timeframe. That's why this issue is not titled "Implement dblog page in React/vuejs/angular/elm by november 1st". The next best thing to to get people who agree to work on one solution do a prototype, set some ground rules, and have everyone else poke holes in it within the defined rules. That's the only reasonable way to let community have power over what's happening, keep a reasonable timeframe, and respect the work of people spending time on the prototype. Anyone is free to come up with alternative implementations during this time but there is not enough bandwidth within the regular core JS folks to take on a prototype with another framework at this time.

The only real decision here is that a few interested folks from the usual core js "team" + a few others are going to work on a React prototype, unless there is a major oversight that make React unusable for us (it's a real decision with a huge "unless" in it, but still). Everything else is still TBD. If you want to try out vuejs to prove us wrong, by all means please open an issue for a prototype. But if you don't have the ressources, knowledge, time, you're still welcome to poke holes here, as long as we all agree what the feedback looks like. I mean we're trying to make all this fair, I hope that comes across at least.

Everyone that took part in the meeting thought about the subject for a while in various ways, community adhesion, themeing issues, contrib reuse, server side rendering, etc. Given all that we thought React was a good solution. We all spent a significant amount of time on this so you'll understand that seeing a few comments with "+1 X framework" without any justification don't feel great. As the feedback on this topic shows we wouldn't be going anywhere without any decision being made. It might not be the perfect decision but people that attended the meeting, given the context, thought it wasn't a bad one. Now we're asking the community for additional context we didn't consider where React would be a major problem. I do think it is a reasonable thing to ask that the feedback be:

React does X in this way
It is an issue because Y

Framework Z is better because it solves the issue in that way. 

Of course everyone is still welcome to post more free-style feedback in the other issue. I am (at least, most likely everyone else) still looking at it as well.

@andypost: I don't agree with using my tweet as justification. The decrease in js commit rate is mainly due to 3 factors: first is that nothing is fundamentally broken/dirty anymore, second one is that core committers didn't look at js patch as much as they used to, and the third one is that the testing gate killed off the majority of efforts on js patches. React or not, making the admin ui better would increase contribution rate because the effects are clearly visible, unlike making some edge cases of the ajax framework more predictable.

And to finish tongue-in-cheek-ly: I'd be very happy if everyone showing up here would stick in the core js queue for a while and not just on this issue :)

Z2222’s picture

 

webchick’s picture

Is there an issue yet for the React prototype of the watchdog page? When that's created, folks interested in alternative frameworks (I'm hearing both "vanilla" web components and Vue.js come up a lot, both here and in the WP discussions) could start an alternate implementation in a duplicate issue and we could compare/contrast, which would be very helpful IMO.

Rene Bakx’s picture

Thank you for clearing some of the mist Nod_ :-)

But if it's experimental and only for a few admin screens, why advertise it as such a big part of core? Why not build it in the same way as the other experimental things as a separate module that can be removed later on. What I think scares most people, me included, is the fact that is becomes part of core, which means removing is a rather hard thing to do. While as a 'module' it can be a lot easier to remove or include if you prove us all wrong :-)

But can you atleast point out the parts of admin you are going to work on with React? I suspect things that have to do with the Layout and Inside-Out initiatives? And if that's the case, it will be touching parts of front end, as those module need to hook in the front layer somehow to show the edit buttons.

And just to be clear, I do understand where Dries is coming from, and he is right that we need to be push forward with making decisions or else we be discussing thing till the end of time and beyond. I guess most technical leads in smaller projects are well aware of the fact that sometimes you need to force a team forward :) But that it never goes without heated discussions too ;)

GrandmaGlassesRopeMan’s picture

Issue summary: View changes
GrandmaGlassesRopeMan’s picture

@Rene Bakx

But can you atleast point out the parts of admin you are going to work on with React?

We outlined in the summary that the first proof of concept, a stage-0, would be the Database Logging UI.

attiks’s picture

#71 Not sure, but I guess it's the fastest way forward, not sure what was discussed last week, but maybe we need to define what we would love to see in the UI to make it more interesting to build.

I quickly drafted something, but feel free to improve

## Initial page load

- Show 50 logs lines
- Sorted by date DESC
- Not filtered by type
- Not filtered by severity

## Features

- Filtering is using the Facet approach, so you can combine multiple types and/or severities
- Filters has a "Show all" button when needed (reset filter)
- There's a reset button to clears the complete log
- Individual log lines can be removed
- All visible lines can easily be selected
- Add a search to search inside the message

## State

If the user returns to the page it's filtered like it was when the user left the page

nod_’s picture

But if it's experimental and only for a few admin screens, why advertise it as such a big part of core?

It's much better to raise awareness early to avoid very bad reactions later on. As for how it'll look in the code regardless of the framework, a separate module would be easier to work on so I'm pretty sure that's what it'll be to start with (with usual experimental process and all that).

@webchick: no issue yet with implementation details, the goal was to see how this issue to progress before starting work.

@attiks: I'm not convinced this is the issue it should be in. Enough bikes have been shed in this issue to avoid adding UX discussion on top of it (should be in the implementation issue of the core queue that's to be created). but yeah basically that was the plan, filter, search, pagination etc.

altrugon’s picture

With the introduction of Symfony and Twig, Drupal has probably become the most difficult CMS to learn. Sure it is nice to always choose the most powerful tools out there, but this also limit the amount of new adopters. Taking into account that React and Vue are quite similar my vote goes to Vue.js because of its learning curve. This complexity in which Drupal has got involved is already affecting the final clients (post 1, post 2)

webchick’s picture

How about let's move #75 to a new issue entitled something like "Design a spec for initial test implementation of JavaScript-ized watchdog page" or whatever, and tagged "Usability" and "JavaScript." That could be helpful to get alignment on the requirements while this issue plays out.

@nod_ I guess I'm confused then, because I'm not sure how we can close this issue as "Great, looks like React's going to work for us" without a sample implementation to evaluate.

neclimdul’s picture

I'm sort of lost on this. I've written like six responses to this because my first reading of the issue was like "this is the decision get out the way" but then there's "give us your React experience" but then "my experience is bad, vue is a better fit" is met with "ok code is golden, solve it"

Feeling sort of kicked out the process here but I guess for the sake of moving things forward, people that have had better experiences with Vue.js and want to push that forward can go here #2913628: Proposal to use Vue.js for building Drupal’s administrative UIs?

grshane’s picture

I've been working with React to decouple the authoring experience. Adding a built-in frontend JS framework would have been a way to solve many of the issues that I have been trying to solve. While talking with btopro, I now understand web components and see their use case. If web components are chosen, it won't matter on what JS language you know because they can be any framework present or future. Conversely, now you have components that are in different frameworks.

davidhernandez’s picture

This could have been better communicated, but I'm reading the summary and nod_'s comments and what I understand is:

1 - It has been decided to move forward with something. That Dries and the maintainers see a need to implement a frontend framework to solve many of the inherent administrative and editorial usability issues.

2 - Given the limited cycles and energy of everyone who will do the work, it is best to choose a direction and have the team focus on one implementation, instead of diluting resources, to see how it goes and what they learn. If someone wants to do something in parallel and show an alternative, that is fine, (even great,) but the involved group wants to focus itself on one solution.

I think this is a fair tactic given how difficult it can be to get consensus and make progress. There has to be at least a starting point.

3 - After much deliberation, (and I doubt this decision was made naively) the team of people listed under "sign-offs" decided React would be the first choice to try. If that goes well it will likely be adopted, but they are leaving room to back out if it doesn't go well.

4 - This post is primarily asking the community, "If we go ahead and experiment with React, is there some pitfall we don't know about? We're trying to cover all bases." So not looking for every opinion of every framework, and restarting the bikeshed, we just want to know if someone has compelling evidence that this might be a mistake.

If this is the case, then this is closer to a R&D phase, which may well graduate to implementation. But everyone has taken this and Dries' blogpost, especially, to mean "Drupal is all in on React and adopting it for everything."

A better characterization would be that now is the time to take a step forward, and this is the one being taken. Before the foot lands, does anyone have a compelling reason to say "they" ^ have made the wrong decision?

larowlan’s picture

Well put @davidhernandez, I think moving some of that to the issue summary would be good

nod_’s picture

Yes, thank you.

yoroy’s picture

Thank you thank you @davidhernandez

deadbeef’s picture

@davidhernandez #81

1. Moving forward with something:
A good Something would be an initiative to expose the entire core admin functionality as a properly designed JSON/REST API in the first instance. So that the business-logic of the admin functionality is properly defined, and people can choose whatever fat-client they want. Concomitant to that, a workable standard for contrib API additions. Make it React per default if you must, but simple to change out for a less-risky or less immoral licence proposition, or maybe a framework that doesn't in reality require a big, ugly singleton stuck in the middle to make up for a fundamental design-flaw.

It seems rather predictably, fat-client is on the up yet again in the grand cycle because: "interactivity". Any attempt to integrate such a thing into core requires a proper design strategy. And clear, well-defined use-cases. Furthermore: following the crowd outside Drupal in no way implies the crowd know what is best for Drupal.

webchick’s picture

Title: Proposal to use React for building Drupal’s administrative UI’s » Proposal to use React for building Drupal’s administrative UIs

Just your friendly neighbourhood grammar police. ;)

davidhernandez’s picture

@deadbeef It would seem, though not explicitly stated, that part of the next steps would include determining what changes are needed to core to support a framework. Often we need to start doing/experimenting before discovering all the barriers. I'm confident there is no intention to force a specific framework on the user-facing side of things, so it would make sense that core changes would be largely agnostic, even if a specific framework is used for the admin side. (but I'm no expert on what needs changing.)

To add to what webchick said, it doesnt appear there is an actionable next step for this issue. The summary says it will be time-boxed for feedback until October 23. So at that point it should be assigned to Lauri to decide if any reasons have been provided that would change his mind. The next steps of research and experimenting with actual code I assume will be in another issue? It still isn't clear, unless I missed it, whether this is to be done in core issues or in a contrib space.

What will be most helpful from the community and experienced React developers are comments like "Let me save you D months of work. When you get to E, you'll be F'ed."

neclimdul’s picture

"A good Something would be an initiative to expose the entire core admin functionality as a properly designed JSON/REST API in the first instance." Great people are working on top to bottom Rest API's as we speak to support just that. :) #2757967: API-first initiative

davidhernandez’s picture

Issue summary: View changes

Making some issue summary changes.

Anonymous’s picture

fgm’s picture

About the problems with server-side rendering mentioned by @Rene Bakx (and others ?), I stumbled upon Limenius yesterday: https://github.com/Limenius/ReactRenderer which looks like it could help in our case "ReactRenderer lets you implement React.js client and server-side rendering in your PHP projects, allowing the development of universal (isomorphic) applications.". Includes two different flavors of Node usage.

guilopes’s picture

I think first of all we need to define which improvements we want in terms of UX, just add react or any JS framework will not solve any problems, Actually it will bring more problems because we will not be focus on the UX problems but in rewrite the pages to react.

Another thing, we can achieve probably the same UX without React and just with server side rendering and Vanilla JS. It looks like the main goal of this proposal is marketing and not real improvements.

If we can focus first on the UX improvements and design that we can see if the front-end framework will help on that and if we really need one.

anydigital’s picture

-1 for React
+1 for Vue #2913628: Proposal to use Vue.js for building Drupal’s administrative UIs

  1. Single framework. Are you sure React will work well on non-admin pages? Me - not. Vue is much more friendly but still flexible enough for admin UI purposes that makes it perfect single framework for both admin and non-admin UI.
  2. SPA. React is good for single page apps, but Drupal is another beast. Vue is easier to use on server-generated pages.
  3. Maintainability. Drupal core's js is hard to maintain and React will make it much more complex for most of Drupalers.
dawehner’s picture

Single framework. Are you sure React will work well on non-admin pages?

Well, this is not up for debate right now anyway. Please let's focus on the admin UI improvements.

Maintainability. Drupal core's js is hard to maintain and React will make it much more complex for most of Drupalers.

If you want to have actual maintainable code, JS without any static typing is kinda lost anyway. Hint: There is elm ;)

btopro’s picture

Again, as much as I also enjoy Vue in principle, this is not a championing one's solution thread.

Another consideration associated w/ picking anything should be what happens to jQuery. Canvas LMS is a heavily backed corporate "open source" project and it's built on React yet still is forced to have jQuery lingering all over the place (in multiple versions sometimes). Smart people work there, they have total control over the platform, yet their cherrypicking things to do in React has caused them to now have to support jQuery and React based UX patterns (ugh).

Webcomponent spec has already allowed us to eliminate 100k lines of CSS / JS in elmsln. We're able to take what was a jQuery file, shift it into raw, scoped JS, and then put it in an element of it's own; thus reducing the amount of JS to power a page. In the next year we'll have minimized jQuery to a point where we hopefully can turn it off. While I appreciate the theme thread about components my guess is that these are largely design oriented components when the true power of components is coupling them w/ JS driven events and listeners to build complex lego sets.

Another consideration when playing w/ React / other libraries is this interplay w/ what exists and whats the exit strategy from jQuery land. It can still sit there, but reducing reliance on it is fantastic for performance (for sure). Webcomponents would also match the design pattern of Drupal of having a box of legos what all fit on the same grid plate and work nicely together, each serving it's own specific purpose while still being able to support bricks from Megablox and any other company that makes similar enough shaped pegged bricks.

Rene Bakx’s picture

I was pondering about something when walking the dog last night. It's a bit beyond the scope of this ticket, but since this one has a bit of momentum i'm going to spill my beans anyway :-)

Like @davidhernandez and @webchick concludes, nothing is written in stone at this moment. But to make this a fair example I do think all teams should use the same starting point. Meaning that the Core team working on this React solution should play by the same set of rules as the Vue team, Webcomponents Team etc

One of this rules should imho be, develop it as a standalone module that is not part of 8.5-dev. This would 'eliminate' the core developer advantage of being core.

Bear in mind, it's not a competition, it's about finding and comparing the options, so we can find and build the best solution for Drupal and the community. However we should be able to set a deadline to this discovery phase, that would imply that only serious teams (read those who can actually build, document and explain the inner workings) will participate in this phase.

In essence, we as NOOOOO NOT REACT shouters should walk the walk, and not just talk the talk...

(feel free to delete this post, or tell me that i'm naive in thinking this could actually work.)

kevinquillen’s picture

Just a couple of things....

  1. Would this mean backing jQuery/Backbone out of core?
  2. What about the compatibility matrix on the WC site? By the time this initiative is likely finished, it may be fully supported, but right now it does not appear to be.
  3. What are the plans to avoid what happened with Backbone (added to core, but seemingly not used at all by the community at large)?

I see the arguments for and against React, although I think the biggest benefit toward adopting it is similar to Symfony - adopting a product with a very large user/developer base, who don't use Drupal (but also don't need to know it). That is a very large knowledge base to ask for help from, and maybe it would even help attract developers and/or new themers who can eventually pitch in without knowing Drupal internals in order to do theming or create front end components. Although, to get to that point, I also agree with those saying API-first and UX/DX needs to move in unison with this as well.

SPA. React is good for single page apps

I've asked some of the JS experts (who only do JS for static sites) in our building and they said you can use React for anything, not just a SPA. Small pieces, large pieces, or whole pieces.

davidhernandez’s picture

@Rene Bakx Some of that is in the issue summary. It is my understanding that this will indeed be done in contrib and not in core 8.5-dev. Any alternatives would then be on the same playing field. There is essentially a deadline of the end of 2017, when 8.6's dev phase starts. Again, my assuming, that at that point a decision will be made whether it is working and a framework can be moved into core for the admin pages.

If the sample case is the logging page, every solution should do the same, so we can compare apples to apples. I, however, have no authority to say anyone should be spending time on this or that there is any possibility an alternative will be considered, but if someone wants to spend time on that it's their prerogative.

HongPong’s picture

I would reiterate that accessibility should always be considered. If any framework harms this it is a step backwards.

I would really recommend going with more traditional, and not JSX, in Drupal. If it is going to demonstrate how this is used then this will help community members learn it.

It is worth scrutinizing why React is trying to stay away from webcomponents. Even though React is MIT now it still seems like avoiding webcomponents is a kind of walled garden attempt. I don't think it's a bad idea overall and could pan out well for the community, but we should try not to get caught on another island with this.

codycraven’s picture

I'm a huge proponent of this initiative. I personally do not care in the slightest what framework is used as long as it is heavy client-side (go ahead and have it be Golang + Qt for all I care), which forces Drupal to develop a complete API and dog-food it.

I think if we do this the right way in the long term we end up with a headless Drupal. Drupal would then be distributable in multiple flavors such as:

  • headless
  • headless + admin/editor UI
  • headless + admin/editor UI + frontend

Obviously there could be any sort of variety in distributions.

Right now Drupal is tightly coupled with presentation, which is fantastic as long as you're happy receiving whatever Drupal gives you natively. If you want to build any other sort of interface or distribute your servers, get ready to jump through hoops and make compromises with potentially major performance penalties (imagine how much faster Drupal would operate without any of the rendering logic it currently includes) and cost overhead.

I really feel that Drupal will either move to a headless platform (obviously it can/should have a compatible frontend available for each release) or slowly die off. If Drupal gets to a point where it is headless, individuals and groups a free to build their UI in whatever tooling their heart desires (React, Vue, webcomponents, whatever).

However if we battle over the framework for this intermediary period of time we will never progress the state of Drupal.

larowlan’s picture

benjy’s picture

The blocking could almost be the other way around, it would have merit to suggest using the testing tool most common in the framework we select. E.g. Jest is pushed quite heavily in the React eco-system given Facebook maintain that also.

larowlan’s picture

sounds like chicken and egg...so perhaps that means they come together

aleksip’s picture

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.

thamas’s picture

Hey people, what does that mean for the current situation that––as it is mentioned in #2913628-8: Proposal to use Vue.js for building Drupal’s administrative UIs––
there is already (?) a Vue.js implementation of the Database Logging UI?

Rene Bakx’s picture

@thamas, that's a tough question.. VueJS is not part of this proposal and not the prefered choice of the core team for very understandable reasons. However from my P.O.V it looks like the core team might need to re-think some of those reasons as the VueJS route seems to have more people on board within the Drupal Community then the ReactJS route. This might, and probably is biased because there is no accurate measuring of that popularity and the con React / pro VueJS people are bit louder than the pre React people.

But I do believe we need to respect whatever route is picked, but that won't prevent us from protesting against it, especially given the notoriety of Facebook when it comes to their licence policies. Cause like you @aleksip says, we are and must remain an community at all time and be very aware of the power we are giving those big content silo vendors, with a very clear other viewpoint on open web experiences' over our project if we include parts of their property in it.

daften’s picture

@Rene-bakx, what are the reasons to NOT choose vue by the core team? Can you link or post them here for completeness.

RainbowArray’s picture

There's quite a difference between the number of votes in an unscientific poll or the number of comments in favor of one framework versus the number of people who are available and willing to dedicate time to actually work on implementing a solution.

I don't think there's any sort of discussion that will get every single person on board with one framework or another. There will always be some people who are going to want a different approach. Unless we want this discussion to go on forever without any action, a decision needs to be made. And the tentative decision is "Let's try using React." Not for forever, just for trying to build one thing with some people who are willing to put in the time to do that. Then see how that goes also use it as an opportunity to dogfood our APIs.

If there's a really big flaw in using React, that's what this issue is for, to point out something that was missed. I don't think "there are also people that like other frameworks" is necessarily a really big flaw. It's sort of a fact of life with front-end development these days. Not liking Facebook seems to be one of the other big criticisms.

If people want to work in parallel in contrib to demonstrate another technology, that's great. Put together a team, a plan, and get started. Maybe that ends up showing there's a lot of value in that alternative approach. Maybe not.

It's worth a reminder to treat each other nicely even if we disagree. There's a lot of folks who took a good chunk of time at DrupalCon to gather, have a discussion and try to make a tentative discussion to move things forward. Coming up with some reasonable discussion points is great, but let's try to steer away from questioning each other's motives. We're all people, and it's not easy to take the time to work on this. Let's play nice with each other.

btopro’s picture

To avoid camp-ism; I'd encourage the group that said "React is awesome let's do that" to make something simple in pure webcomponents. Reason being - This group already has said they love React. They will produce something awesome (not doubting that) and people will be opposed regardless.

However, if this group tries to make something very simple in a webcomponent based approaches it would help challenge the team's assumptions and force them to reflect on what they like / dislike about React or this fundamentally different (yet similar) approach. That would also give the React devs a chance to reflect on the Developer UX between the two technologies.

webchick’s picture

The issue summary pretty clearly states that the group that's behind React only has bandwidth to pursue pushing React. So folks advocating for other technologies (Vue, Web Components, what have you) would need to present their own research, their own prototypes, etc. alongside. This would be a great thing to do; the more, the merrier; the more data we have, the more sure we can be of the decision. However, Web Components/Vue aren't going to shine by having people behind a different technology trying to cobble something together; the folks really pushing for those will do a much better job, but will need to put in the work.

aleksip’s picture

I don't think anyone has used "I don't like Facebook" as an argument?

What could be a bigger flaw than to find that adopting React is against the values of Drupal? It has been argued that this is the case, and it would be nice to hear counterarguments, especially from the folks behind the proposal to adopt React. Isn't this exactly what this issue is about?

webchick’s picture

Well, no. This issue is specifically about:

Please keep discussion focused on whether or not React would be a viable solution for Drupal, not the promotion other frameworks.

Specifically in the format of:

React does X in this way
It is an issue because Y

Framework Z is better because it solves the issue in that way. 

If you want to merely voice your support for framework X, you can do so at #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs (though it must be said that you're highly unlikely to sway people that way...)
If you want to put forward your support for framework X in the form of a complete proposal that includes detailed research, implementation that can be compared/contrasted against React, etc. you can do that at another issue such as #2913628: Proposal to use Vue.js for building Drupal’s administrative UIs

But this issue is specifically all of the people listed above saying, "We support React as the framework of choice, and furthermore we are all willing to put time/effort into making it happen. If you have reasons why React is not a viable solution, speak now."

It'd be great if we could refocus discussion in this issue on that, because hard data with examples will be a far more effective way of swaying people away from React, if that's your goal.

nod_’s picture

I do think the philosophical and political question of using a framework produced by Facebook is valid. I've seen the several posts about it here.

Providing a counter argument is not in scope for this issue. Not to dodge the question but precisely to give it the importance it deserves. It's such a big topic I think dries, other core comitters, or community working groups could (should?) provide feedback in a more formal way since community values are involved.

But as webchick said this is not the place for counter-counter arguments (and we might give the impression of shutting down discussion if we started doing that).

aleksip’s picture

I still do not understand how this issue is not about discussing a problem with React? To formalize the point in the way requested:

React does not adhere to Drupal's values, as previously argued in detail.
It is an issue because Drupal has different values, as previously argued in detail.

I am advocating any framework that adheres to Drupal's values.

And I do not understand how discussing this might give the impression of shutting down discussion?

But I will stop now, sincerely hoping that Dries, other core comitters, or community working groups will respond to these concerns in some way.

btopro’s picture

@webchick - sorry; to clarify the "React people doing stuff in Web components" I didn't mean for this project I meant more so just in general. In my mind they'd benefit from doing a Polymer hello world tutorial just to see the way data flow / structure differs to see they are fundamentally different ways of attacking the same problem space. That way it could help inform arguments pro/con of React vs WC.

Absolutely the people dedicated to React should focus on just that to make a kick-butt admin ui element / protoype :)

imclean’s picture

#108

I don't think there's any sort of discussion that will get every single person on board with one framework or another. There will always be some people who are going to want a different approach.

This argument isn't quite fair. Many people who want a different approach have argued specifically for one alternative framework and explained their reasons in this issue and others. That said, #115:

Absolutely the people dedicated to React should focus on just that to make a kick-butt admin ui element / protoype :)

Agreed. I hope the VueJS gurus also get stuck in to their project.

neclimdul’s picture

Lots of thoughts... I wish I had a better place to post this because its not specifically about implementing the React solution but here it is anyways. I think personally a lot of this boils it down to the top down message was "Drupal Looking to Adopt React". The founder pushes forward React as the one solution. I know there is more nuance to his post and this issue but a lot of feelings come out of that initial reaction.

I get the feeling from the comments here that what happened was a team decided to get out of the bikeshed an implement the React option because it will force things forward. If that's all this is then great.

Assuming that to be true I'd like to reframe the discussions to what I think the core team is saying anyways and that's "Drupal is moving to adopt a reactive framework to use in Admin UI's". The Core JS team has experience and a passion to implement a React solution so that is happening. There are some passionate Vue people and I guess we're moving forward with that and I hope we can convince you its awesome. Maybe someones going to try something with Polymer. But the idea is the same and we should be the community we claim to be and direct people in to the solution to help fix the foundation, design and build the bikesheds and we can paint them what ever we want because that's the "easy" part. At least the fun part.

If we change how we're talking about it the preferences drop off and we can take an important next step and realize these efforts should be collaborative efforts not competing. While some of the details are likely to be quite different, in reality Vue and React share more in common then different and to that point the end goal is largely the same.

As an actionable next step I'd like to setup up a place where we collaborate around those common needs like designs, build/testing tools, packaging strategies, blocking APIs, angry Drupal bugs that block decoupling, and just general "hey we should should both really do X because we can". We're going to be working on the same problems and if we're going to be comparing apples to apples at the end we'll really need to be working pretty close to deliver similar "products".

PS. if you made it to the bottom of this long post, this allows React people to direction people with the valid feedback of "My React feedback is I had a terrible experience, Vue worked so much better." with "Great, we need you help and you can help move the whole thing forward here" which sounds so much better.

PPS. We're going to need all the Vue peeps and help you can muster so click over and /follow. :-D

nod_’s picture

Yes it was only about cutting through the bikeshed. A few of us here were involved in the module page redesign, status page, toolbar, and responsive preview issues, none of us want to go through that again. And for all the noise here, things are going better than back then.

Talking about process, at some point in the comments I remembered #2573119: [plan] Determine process for big UX changes, which is pretty much what we're trying to follow (willingly or not). And to be extra clear, on the process schema, we're only just past the middle of the first diamond, before the "plan" step, right at the start of the prototype phase. So people saying there is no plan and it's going nowhere, they're not wrong but it's part of the process. Had I remembered that earlier things might have gone a bit smoother.

So please, let's get back on topic.

katmarch79’s picture

Feels like this is going to be a recurring theme for large PHP projects, internal devs pretty much choosing React and then the community pushing back, mostly around Vue. Devs then have a bias (or commenters perceive one at least) towards existing code/knowledge and the discussion ends up less of "what would be the best JS framework for our project" and more "can we just keep using React since we already started with that"?

I've read a lot of similar discussions in the couple months across a fairly wide set of projects, and there's a couple things that started really sticking out to me. 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.

MiSc’s picture

- (just delete this comment - already tired of this discussion)

Rene Bakx’s picture

@webchick

React does X in this way
It is an issue because Y
Framework Z is better because it solves the issue in that way

okay, let me put it in that format if that's what is takes to finally convince you to look beyond the technical scope of this issue.

React does their licensing in the way the seem fit for that moment, or at least are very easy to switch it again, and they haven't said 'We are not going to pull out our patents'

It is an issue because, The patent part is not clear, if somebody uses Drupal to build a competing product in the eyes of Facebook, they can easily whip out the patent card and we failed to protect our own 'customer'

Framework VueJS, Webcomponents it better because, they don't have that patent card to pull out, and are not owned by a notoir company like Facebook.
freelock’s picture

I'm finding this thread extremely interesting, FWIW. We've been experimenting with React, along with Apollo and GraphQL, and had basically settled on the same decision as the core team here, for the same reasons -- use React because:

- It has tremendous momentum, and a huge pool of experienced developers
- It is starting to be requested by customers, so expertise in React seems valuable
- It is open source
- Apollo and GraphQL are a huge improvement over the data binding and more simple REST APIs, which we've used extensively with Dojo and for a while made us consider Angular2 -- this is like the difference between having SQL vs a simple CSV file

But after reading this thread, WebComponents seem extremely compelling, and React's lack of support for them (currently) seems like could be a challenge going forward, at least until React fully supports WebComponents. And I've been hearing similar great things about Vue.js, all the arguments presented here for Vue seem pretty strong.

So I guess I'm all in favor of this initiative, however it goes. I would love to see some competing implementations -- React vs. Vue, if there are Vue developers willing to put in the effort to make a competing Watchdog screen, while the core team implements a React-based one, I would hope that the decision of which framework will move forward in core happen after there are working prototypes.

And that the final decision of framework considers all the factors people have expressed in this thread:

- market adoption, developer experience pool
- license/patent risk
- ease of onboarding new developers
- potential disruptive new technologies (WebComponents)
- patterns set in core that we might have to live with in contrib

Meanwhile, we haven't switched away from React here, but we're certainly going to play around with Vue and WebComponents...

[Edit: Apollo and GraphQL also work with Vue -- and that middle layer is what is most interesting to us...]

kevinquillen’s picture

jimyhuang’s picture

Will there be any reason or fallback plan that React can be moved out of core after research?

Community may find out there are too many problems to adapt React after Q1 2018. For example the JSX, many people mention about that could be a problem in Drupal in this thread.

I personally happy to see Drupal moving forward on adapt modern js framework. But the workflow of building website in React is very different. Drupal is not natively support that flow.

IMHO, it maybe good to have fallback plan addressed on proposal for such a big experiment.

attiks’s picture

cosmicdreams’s picture

Thanks for creating that @attiks. Count me in. I'm excited for this opportunity to show what we can do with Web Components. And it would be awesome for all of us that have been making them get together in some fashion to share implementations and knowledge. See ya in the queues.

attiks’s picture

#78 Created a new issue at #2915262: Define the new DBlog UI to discuss the UI

effulgentsia’s picture

There's a few comments here expressing concerns about React not fully supporting web components. In #9, I asked about how that would be a problem for us if we used React for admin UIs. WordPress is currently on track to have Gutenberg written in React, while still allowing plugin authors to write Gutenberg blocks as web components. I opened #2915311: JavaScript VDOM library evaluation: integrating web components to ask what else people see as a potential problem with integrating web components into React. Please comment over there if you have insights to share about that.

g089h515r806’s picture

Baidu start to forbid React js in all projects since 2017-9 for patent issue. Alibaba, tencent also consider to replace React js in their new projects. If Drupal 8 core include React js, that means big companis which forbid react will not choose Drupal anymore.
e.baidu.com is using Drupal 7 now, If Drupal 8 include React js, that means it will never have chance to update to Drupal 8.

webchick’s picture

Was that decision factoring in https://code.facebook.com/posts/300798627056246/relicensing-react-jest-f... which happened at the end of September?

freelock’s picture

Based on 123 above, I checked out Vue, and I have to say it seems like a pretty compelling alternative -- far easier to get started than React, no build tools necessary, easy to build elements and add to existing Drupal sites. React, for all its power, seems to require a lot more boilerplate in complex components.

As a relative novice in these frameworks, I can see how to start using Vue today, whereas there's a big hurdle of having to deploy build tools for React. I'm not seeing anything React can do that Vue can't -- and Vue seems more future-proof as it is far more compatible with WebComponents -- see https://custom-elements-everywhere.com/.

After going through this, I'm feeling like React carries a lot of baggage we can avoid with far simpler Vue components.

effulgentsia’s picture

Baidu start to forbid React js in all projects since 2017-9 for patent issue

Per #130, I suspect that this decision was related to the prior license, and that it needs to be reevaluated for the MIT license.

As far as I know, the MIT license has not been tested in court regarding patents, and there are differing legal opinions on whether the license covers patents or not.

I opened #2915586: JavaScript VDOM library evaluation: patents to discuss this. Please leave feedback there if you have any.

g089h515r806’s picture

This is the discuss link in chinese why Baidu forbid React js: https://www.zhihu.com/question/65437198.
Also https://www.zhihu.com/question/65446071, for Alibaba start to replace Reactjs in their new projects.
Tencent also check how many existing projects using Reactjs, this is message from their internal team members.

It is a big technical news in 2017-09 in China.

The United States is always complaining that China has infringed upon its intellectual property rights, big companies in China are paying more attention to patent issues now.

This is why baidu forbid it :
When Facebook infringe Baidu's patent, and Baidu is using React js, what will happen? It's uncertain.
Big companis like Baidu, Alibaba, Tencent care about this case, these companies have a lot patents.

effulgentsia’s picture

@g089h515r806: thank you for those links! But, those are both from before 2017-09-26. Since 2017-09-26, React's license is MIT, which does not have the prior problems. Do you know of any new links discussing what Chinese companies are deciding, now that the React license has changed?

g089h515r806’s picture

Once the forbid decision is made, it need some time to change it. Maybe they will change the decision in later, there is no news about this.

websiteworkspace’s picture

With all due respect, it seems like an initiative to fix the many bugs and problems with the existing administrative system ought to be a far higher prior than yet another complete re-write of a subsystem that seems likely to introduce yet more bugs and problems that will need to be fixed.

As one of hundreds of examples of core problem personally noticed, it isn't even possible to delete a taxonomy vocabulary from the D8 admin GUI at present:

https://www.drupal.org/node/2621626

The complete Drupal core re-write that is Drupal 8 still contains innumerable bugs after four years of work. Why push Drupal into a deeper incomplete code deficit, with yet more thinning of priorities and scattering of attentions?

The Drupal development universe has already bitten off many times more than it can chew ...

MiSc’s picture

@DrupalSiteBuilder totally agree on that. Better to fix what we have before throwing something "new random" into Drupal.

markconroy’s picture

FileSize
84.4 KB

@drupalsitebuilder - you can easily delete a vocabulary from Drupal 8's GUI. That issue you linked to is slightly different.
delete vocabulary

cosmicdreams’s picture

Is it out of scope for the React team to show how GraphQL integration team would work for the dblog page?

nod_’s picture

Pretty sure it'd work but it is out of scope. Graphql is not D8 core.

mherchel’s picture

A potential issue that I discussed earlier was in a situation where React is used to control front-end components (toolbar, settings tray, etc).

If the version in core becomes outdated, I won't be able to use the newest version of React on the frontend because then we'd have two different versions running.

React has quicker release schedules than Drupal, so this is a likely scenario.

aleksip’s picture

mgifford’s picture

Issue tags: +Accessibility

Just wanted to thank folks for raising accessibility as a concern, @StevenPatz, @dankegel & @HongPong

I'm tagging it, and also want to try to document concerns & point to resources as best as I can.

This is no small undertaking & know that @lauriii & @dries have put a bunch of thought into this.

First, there's no reason why a site built with a front end framework can't be perfectly accessible. Any modern Assistive Technology works on the DOM, so works fine with JavaScript. @Everett Zufelt has been giving some good presentations breaking down that myth lately.

However, not all frameworks are equal, and not all of them do a good job of presenting semantic information in a way that allows a screen reader user to extract a lot of meaning from the page.

Marcy Sutton is really the person who's done more in this area than anyone else I know. She's got some presentations here:
https://marcysutton.github.io/react-a11y-presentation/#/

She's also written up:
https://www.smashingmagazine.com/2015/05/client-rendered-accessibility/

This react accessibility project may no longer be valid, but should be looked at by someone who knows the space better.
https://github.com/reactjs/react-a11y

There are some examples of patterns here that claim to be accessible:
https://react.rocks/tag/Accessible

I'll try to find some more examples to help make a good decision on this. We're making such good progress on WCAG 2.0, 2.1 & ATAG 2.0, it would be terrible to have to take a step back because of a choice of a JavaScript framework. Just have to do some proper investigation first.

Anyone know if this is the best place to look for known accessibility issues:
https://github.com/reactjs/reactjs.org/issues?utf8=%E2%9C%93&q=is%3Aissu...

amjad1233’s picture

I am up for it...

Maybe a free learning resource for the community would help.

mgifford’s picture

I asked Marcy Sutton on Twitter and she responded with "Wouldn't be any more difficult than a different framework, or no framework really. Just have to build it accessibly", so that is encouraging.

The thing is that we're starting with a pretty accessible back-end. Any migration to react would require a lot of testing.

kevinquillen’s picture

#144 one of the better resources I have seen is React for Beginners.

cosmicdreams’s picture

In a recent Lullabot podcast (https://www.lullabot.com/podcasts/drupalizeme-podcast/react-in-drupal-core), there was a great discussion from the team that's focused here. It was really great to here Sally Young's take on how React may evolve as the web evolves.

Specifically, someone brought up the topic of web components and voice a concern that Web Components would "take over" React. If the listener wasn't paying attention they may take away from that conversation that they have to choose between Web Components and React. That you can't have one if you choose the other.

Sally hopefully sets things straight. Web Components are a series of standards. React could elect to implement some or all of the remaining standards. To be super specific, the standards React has yet to fully implement are Custom Elements (and it's use of attributes and properties) and Shadow Dom.

Right now React has several incompatibilities with Web Components, but maybe the crafty developer can work around them. In a recent blog post, one React developer dove into the challenge of implementing Web Components in React:
https://jeremenichelli.github.io/2017/10/the-web-components-experience/

I'd be very interested in feedback if one has the patience to dive in.

Note: This approach was done with "vanilla" JavaScript without Polymer or any other "helper" library.

xjm’s picture

Just wanted to reassure folks that accessibility will remain a core gate; we won't intentionally allow accessibility regressions regardless of what framework is picked, and any new UI built with one of these frameworks would have to undergo a thorough accessibility review. Thanks!

GrandmaGlassesRopeMan’s picture

My recommendation is that we stick with React.

Andrej Galuf’s picture

@drpal: why? What is your argument in favor of react?

GrandmaGlassesRopeMan’s picture

I'll expand on #149, some of this may be duplicates from the original issue summary.

- Very large ecosystem of adjacent libraries.
- Proven maturity as a project, and backed by a community with a vested interest in its viability as a project.
- JSX, which is just HTML with JavaScript sprinkled in. I don't have to learn another template language.
- The reusable and easily composed design React dictates.
- VDOM
- Amazing in browser developer tools.
- React is small and does not attempt to be everything out of the box. A small API surface to learn.
- I know React.
- Improve career options for classical Drupal developers

dawehner’s picture

Points about frameworks in general

  • Media would profit from a nice UI using a JS framework. It doesn't matter which one
  • Using a JS framework will help us to decouple our APIs #13
  • We could work in contrib #14
  • Accessibility is equally challenging with any framework or no framework #145
  • Arguing for months doesn’t help us #41
  • The hard problem is in state management #41
  • Let’s try to write code independent from the framework, so we can switch later #44
  • Criterias to pick a framework #48, #49
  • Web components are great as it allows you to be independent from a framework (many comments)
  • We should improve our APIs first #85
  • Web components allows lego usage like Drupal #95

Points about react

  • React might not adopt web components #7, #9, #18
  • React seems harder to learn #12
  • JSX is hard to learn #12, #15
  • Seperation of logic and template is unusual #35, makes it harder to split up work #54
  • Vue is much easier to learn #28
  • Using web components would allow modules to choose flavours of web components #21
  • Web components are flexible today with polymer/stencil.js #23
  • Dislike of CSS in JS #25, #29 argues that this is not a problem of react but all component based architectures
  • Dislike of facebook software on sites #28, #57, #70
  • React has built in accessibility features #32, #143
  • Vue is easier to learn #32
  • React is totally mature #32
  • MIT license might not be ideal #33, #57, #104
  • React is easy to learn, the tooling ES Next, babel, webpack is hard
  • There is a lot of react work out there #59
  • React can be rendered using the php v8 extension (#91 and others)
  • How do deal with outdated versions of react? #141

I'm personally still in favour of the issue, following all the arguments in #151
One thing we all should keep in mind. You don't just stick with a decision, but rather you should continue iterate on your previous decisions. One example could be that we leverage web components on some level, like the bits we want to be allowed to be "themed"/"overridden".

eatings’s picture

Though there is much uncertainty about the exact shape of the future, I would put forth that the greatest danger we face is inaction. We can continue to analyze and bikeshed and debate and while the rest of the web world passes us by, or we can take decisive, considered risks and challenge ourselves to move ahead. The worst thing that could happen is we learn a lot about working with modern JS -- a subject we as a community desperately need to catch up on -- and hopefully a lot more: a vastly improved admin UX, and the groundwork that sustains Drupal relevance in a rapidly-changing web ecosystem for years to come.

attiks’s picture

#152 Thanks

#153 Agreed, we need to move forward, the sooner the better, but it does not hurt to look at valid alternatives, react is an opinionated framework. I'm personally a fan of adopting - soon to be - web standards, or at least be certain that whatever gets chosen is compatible with it.

rivimey’s picture

Just to throw my hat into the ring; I too am concerned with Facebook's influence on React.js and their control of its direction and licensing. While I applaud trials of React I do think that points made above (learning curve, licence issues, open source values) are very valid.

Andrej Galuf’s picture

Playing the devil's advocate to #151 here:

- Very large ecosystem of adjacent libraries.
- Proven maturity as a project, and backed by a community with a vested interest in its viability as a project.
- The reusable and easily composed design React dictates.
- VDOM
- Amazing in browser developer tools.
- React is small and does not attempt to be everything out of the box. A small API surface to learn.

All shared by Vue.

- JSX, which is just HTML with JavaScript sprinkled in. I don't have to learn another template language.

Respectfully, I disagree. JSX is not "HTML with JavaScript sprinkled in". It's an attempt to imitate HTML, just as XHTML was an attempt to imitate XML - to what results, we all know. Vue's templating is much closer to an HTML Template (so close that you can literally embed its actions in a Twig template), works similar to Angular (therefore closer to Angular devs) and separates Javascript from HTML. JSX imo tries to do too much at once, which forces it to compromise on all fronts.

- I know React.

We both know jQuery, why don't we use that instead?

Knowing something is a matter of investing time. I would argue that React takes considerably more time to start with and to master than the alternative and provides better tooling for progressive enhancement.

- Improve career options for classical Drupal developers

React currently offers better career options, no arguments there. However, since you already know React, learning Vue or Web Components improves your career options even more, right?

I'm not arguing that React is a bad solution like Backbone was (although I do still have serious issues taking a framework, whose Licencing took a quarter of the web to overturn). I am however arguing that there is a better option and that we are rushing into a decision based on precisely what Evan You argued in https://www.drupal.org/node/2913628#comment-12292622 - that the Core Team already has an investment in React and that the entire discussion basically boils down to "React vs anything else", where the argument of the danger of inaction will be used as a scapegoat to push what has already been decided.

In my opinion, all three options should be evaluated fairly. If two or even all three are found to be acceptable alternatives, it would perhaps even make sense to put it to a vote, because whatever will be put into the Core will become the de-facto standard for Drupal with far reaching consequences.

Anonymous’s picture

-1 for JSX and React

To be honest, I do not believe that the UX/UI problem of Drupal could not be solved with the recent tools (PHP) and in my opinion React will not solve it automatically. It will make Drupal more complex.

The vision of Drupal which has been recently revealed by Dries made me think about Drupal as one of the tools in my professional toolbox.

As I see, for me learning pure Angular framework with TypeScript as a front-end developer and making ambitious web applications with real-time databases (Firebase, Cloud Firestore) or coding in native mobile environment with Swift/Kotlin are more appealing than using Drupal-React couple in the future.

Having said that, I am prepared to leave the Drupal community so I would like to thank all of you for this great journey. It was a pleasure working with Drupal in the past and I wish all the best to you in the future.

mgifford’s picture

Sorry to hear you're leaving the community @Robert Petras - perhaps you'll wonder back one day.

I mostly wanted to post on this article by Scott Vinkle about Creating accessible React apps

droplet’s picture

@mgifford,

I think we don't need any special treatments for REAL DOM frameworks. (e.g. React, Vue, Angular). We able to treat it as Ajax pages

For Shadow DOM (parts of Web Components), I'm a bit worried: https://allyjs.io/data-tables/focusable.html#shadow-dom

droplet’s picture

JSX is hard to learn #12, #15

To be fair, all these frameworks have their own syntax and very close. Most of them are predictable and easier than PHP Twig.
http://jeffcarp.github.io/frontend-hyperpolyglot/
(the table isn't up-to-date)

I think JSX itself is easy but ES6 is a new thing to you. (Sorry, I didn't count ES6 as a part of JSX since you can write ES5. You will find similar syntax in each framework also.)

For ES6, you just have to learn some basic functions:

- Filter
- Map
- Object Shorthands
- Arrow Function

And React 16 has new changes to attributes:
https://reactjs.org/blog/2017/09/26/react-v16.0.html#support-for-custom-...

On "Seperation of logic and template",
No matter what frameworks, you just have to keep the component as PURE functions as you can. Split it to fit your work style. Don't lock yourself with the Drupal CORE way in your own projects. (It's same for most of these frameworks)

mrjmd’s picture

I’ll start with the tldr: my thoughts echo @eating’s above - Beginning the hard work of getting a modern framework into core is already overdue, and the long term dividends of making a decision promptly and moving forward with it far outweigh the risks of either choosing “incorrectly” or losing months or longer debating which framework would best suit our needs. The fact is any of the major frameworks would be a big step in the right direction. So I’m excited to see a decision getting traction and will happily endorse React as that choice, though not without a few misgivings.

The main one, which I don’t think has been raised in this issue yet, has to do with the reasoning by which the “larger” MV* frameworks have been seemingly ruled out. Although there are great use cases for going with a more lightweight library, and I will concede the point that they are more en vogue at the moment, I would argue that it is precisely for software as ambitious as Drupal that considering a more opinionated, fully featured framework makes sense.

The trade off for the steeper learning curve of Angular or Ember is higher guard rails and a more standardized way of architecting applications that might prevent us from ending up with a very “Drupal-y” implementation. That’s a manageable problem, but it will likely require more management, more thoughtful planning up front or refactoring as we go, etc.

My expertise is in Angular, and I will admit to being disappointed that it no longer seems to be under consideration. Simply because no one has made a case for it here I will humbly offer a brief one. From the extensive tooling provided by the CLI, to Dependency Injection and strong typing, to a release process very similar to the one we’ve adopted, Angular shares a lot in common with Drupal philosophically. It has also got great support for state management, server side rendering and service workers baked in, and work well with web components. Further, the M in MV* is really great for use with structured data, which is Drupal’s bread and butter. It's also worth mentioning that the Angular team is specifically interested in the Drupal use case, and has mentioned Drupal directly in the keynotes at ngconf the last two years running (full disclosure: I was involved in the keynote in 2016).

Still, adopting any of the major frameworks will be a positive step, especially when done through the enhancement of Drupal’s APIs. React is the de facto market leader today and on that basis alone is a very natural choice. I will more than happily make my peace with JSX and be excited to see us move forward down this path.

Many thanks to the core team and maintainers who have worked so hard to push this decision forward!

cosmicdreams’s picture

@mrjmd I want to encourage you to gather up developers to demonstrate how the dblog administrative pages could be remade using react similar to this issue and the other issues for other JS frameworks / platforms / standards.

What's missing from platform discussion is a demonstration what developer experience and platform usage will be like if Angular was used. If that can be demonstrated then we can do a proper comparison.

nod_’s picture

There is the philosophical/political question of facebook involvment that I am sensitive to but I don't feel like I know enough to give an informed opinion, so I'll leave it to higher powers to decide.

I read everything here and related issues and still think React is a good first step for an experiment on Admin UIs. What I mean is that all the concerns raised around theming, DX are valid and the whole point of the next step is to be able to give answers to those questions but they are not enough to stop going with React without investigating. I am also very happy we'll have prototypes to compare with Vue and maybe others, thanks for stepping up.

alexrayu’s picture

I played with React and Vue recently. Disliked React for it's complexity and weakness. React's syntax is obscene, it consists of multiple libraries, and you need JSX and Redux for it to not be very limited. It's file size is bigger than Vue's, it's slower than Vue, and harder to learn. And React requires a transpiler to be used up to it's potential. Saying that React itself can be used without JSX, Redux, and a transpiler is like saying you can use Apple earphones and not use the rest of Apple infrastructure - not serious talk at all.

Wordpress used React, but they built the solution that an every day developer won't have to change or hook into. Drupal does not have a clear back end admin section, so it's not the same.

The concern is that adapting of React may slap the hands of the smaller Drupal agencies, who try to use Drupal in their work despite the clear indications that "Drupal is no longer for small sites". React may turn out to be the very thing that may break the camel's back. Of course, if Node.JS is to become a requirement for Drupal 9, then probably that whole concern is irrelevant and it's all lost for the smaller businesses.

nod_’s picture

Not liking something doesn't make it repulsive, let's keep things measured please.

Again, if we find out that we can't sensibly use React in a way that fits for Drupal (hence the involvement of all the JS maintainers on the topic) we'll find something else. The prototype is exactly for this purpose. Please do help out in the Vue issue to show that it's a superior solution to React. No need to restart the discussion past the end of the announced timebox.

davidhernandez’s picture

Status: Active » Needs review

We are beyond the time box date. A decision should be made whether there are compelling reasons not to proceed with an experiment. That requires a response from Lauri.

prestonso’s picture

As the creator of the original issue which proposed an adoption of a JavaScript framework (#2645250: [META] Start using reactive declarative JS programming for some new core admin UIs), I echo #153 and #161 inasmuch as I agree that what we need is forward momentum in some direction, not just to demonstrate what this could look like for Drupal, but also to give Drupal contributors important skills in dealing with today's front-end development landscape. I'm in favor of @davidhernandez's position to move forward, as I have not seen compelling impediments to at least trying something out with React.

Z2222’s picture

.

ygerasimov’s picture

I think what is very important is to understand that bringing JS framework will make learning curve of Drupal a bit higher as well. From this standpoint, something that has plenty of documentation / examples would be preferable.

This is where VueJS really strikes as it is not part of the Laravel core and there is plenty of documentation for "php developers" who are definitively Drupal's developers majority.

I found Vue extremely easy to grasp having not much javascript backgroud (beside writing jquery here and there).

thamas’s picture

If I remember well somewhere earlier it was sad that there can be sample applications build in any framework and than the community can check (and compare) the result(s).

As I know from the similar Vue thread a demo was made using Vue. Did anyone from this thread (or those who made _this_ proposal) checked that? What was the experience? Was a similar demo app built with React? What was the experience?

This issue is currently in NR status. What will happen when you close the issue? Will that mean that the proposal is approved and React goes into core? Or what?

nod_’s picture

No, the only thing it means is that the team from the IS will build a prototype using react, and try to address the concerns raised here. Now that we have things to compare to we'll compare it to the other prototype(s) on the concerns raised here and in the parent issue. It does not means it'll automatically get in core, we've only been trying to guide the discussion so that it does not go on endlessly.

thamas’s picture

@nod_ Great! :)

sumanthkumarc’s picture

For people here, who wants to show that their belief in one of the js frameworks is correct, here's a chance. Contenta folks are trying to build a demo with various js frameworks : http://www.contentacms.org/#demos , Help build it and show people what you say and believe is true. :)

UPDATE: Oops, looks like its just a front facing one and not any of drupal admin screens. so not sure how this is relevant to this discussion :P

lauriii’s picture

Status: Needs review » Reviewed & tested by the community

Thank you everyone for your insightful comments.

I think we should move forward on the JavaScript framework selection process, given that the community is mostly supportive of the idea of adding a new JavaScript framework into core.

I’ve taken time to read and consider all of the feedback posted here, and I couldn’t recognize any hard blocking issues for continuing to research React as the JavaScript framework of choice.

At the moment, I see React as the most likely option to be chosen given that there is a unanimous agreement between JavaScript subsystem maintainers that React would be a good choice. Therefore the core team will focus most of their efforts into researching React. However, I am personally committed to supporting the research team behind Vue.js, given the great community support it has.

I would like to remind that this is not an irreversible decision to go with any particular framework. We will take into consideration points that come up as we continue our research. Your feedback is welcome, and we also encourage to carry on research in the contrib space. The JavaScript framework initiative team will be developing a prototype in a sandbox and it will be added to core as an experimental feature, so there will be a chance to evaluate the prototype and confirm that the framework meets our needs before Drupal core adds any new dependencies on a JavaScript framework.

The initiative team and core maintainers will post more issues in the upcoming days to guide the research process. We will also open separate follow-up issues for the feedback that hasn’t been addressed yet.

I’m leaving this issue as RTBC to give a chance for the other core maintainers to post their feedback and to let Dries make the final call.

Thanks again for all the feedback on this proposal!

xjm’s picture

Thanks @lauriii for the summary!

This proposal has a lot of strengths from a release management perspective. The release cycles and backwards compatibility of core's dependencies are ongoing challenges. (The recent Drupal 8.4 release, with major version updates for both jQuery and Symfony and resulting BC breaks for some tools, underscored the risks we have with third-party dependencies.) React has several strengths in this area:

  1. In their post about their switch to semantic versioning, React made a clear commitment to backwards compatibility and a smooth upgrade process for tools in the React ecosystem.
  2. As @dawehner highlighted for me this week, React already has a mechanism for providing developer-only warnings about deprecated APIs that is very much in line with Drupal 8's deprecation process.
  3. Since the React ecosystem is diverse and widespread, any challenges Drupal might face in supporting React will also be shared by other projects, which means that there's less risk of getting stuck maintaining aspects of the dependency ourselves if we adopt it and encounter upstream bugs.

All three of these strengths aren't unique to React (e.g., I'm told Ember has a similar deprecation practice, and the interest in Vue and other frameworks in this issue shows that these projects also have growing, healthy developer communities). But since this issue is about React, I wanted to highlight that so far React seems to meet our current and anticipated needs in terms of core release management. We'll try to validate all these points during the experimentation process.

Thanks everyone!

benjy’s picture

Facebook have a commitment to BC because they use it extensively themselves, that was shown by the recent rewrite they did for React 16 - https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-...

Dries’s picture

Given that this is a significant decision for the Drupal project, this requires sign off from me. Given the unanimous agreement between JavaScript subsystem maintainers that React would be a good choice, I fully support moving forward with React. React also gets the support from Drupal's release managers and front-end framework managers.

While no framework is perfect, I believe that React is a great choice for Drupal's administrative interfaces. I'm sure other frameworks would have been suitable too. Vue.js, specifically, got a lot of support so it will be interesting to see how things develop. We can always change our mind later -- this can be 3 months from today during the experimentation process, or 3 years from today after various Drupal UIs moved to React. We'll always adjust as needed -- it's how we made it this far. Right now, React has the support from a lot of people and is a very exciting choice for Drupal.

What is most important and most exciting is that we're moving forward with a JavaScript framework, that we can start accelerating our learning, and that we're going to use a JavaScript framework (or JavaScript libraries) as a tool to help make Drupal's administrative UIs more modern and easier to use.

Decisions like this are difficult as there will never be consensus. I'm confident that many who disagree with React, will still see the introduction of a JavaScript framework as an important milestone for Drupal. Let's all work together towards making Drupal more modern and easier to use.

I appreciate all the feedback, passion and debate around this issue. Thank you!

cosmicdreams’s picture

I, for one, am excited for our new JavaScript-powered future.

After reading and re-reading, and knowing how core Drupal development tends to go, I do respect the decision to firmly say that core development is going to use React for rebuilding administrative experiences. Dries makes it clear that this decision is to enable this team to now focus on the experimentation process. I'm really excited to see what they can produce.

At this time, I think it's very important to remember why we are all so invested in this process. We all care very deeply about Drupal. We want to make sure that it has a good future and can adapt and grow to address new challenges. This is the beginning of a new process. We must challenge ourselves to try things, fail, and learn from the failures. We need to trust in each other's professionalism and shared interest in making Drupal better in order to communicate through the challenges ahead.

I am committed to this process and am looking for an opportunity to help where I can.

davidhernandez’s picture

When the sandbox and additional issues get created, please post them here so others interested will see them.

ddrozdik’s picture

Is there any roadmap or plans to prepare a list of issues/tasks that could be shared with the community? Please share as well.

dawehner’s picture

I opened up an issue to discuss what modules should be able to do in a new admin UI. This is mostly a framework agnostic/architecture question: #2920196: Which capabilities should modules have in a new JS based admin UI

Rene Bakx’s picture

Status: Reviewed & tested by the community » Needs work

i for one am not that excited about React, and doubt why the last two points of #151 should be taking seriously or as a joke.

- I know React.
- Improve career options for classical Drupal developers

Those arguments are by far the most dumb arguments made by somebody deciding on the future of an ecosystem like Drupal.

I do agree with the first list of bullet points from #152 and I know that discussing frameworks is an endless one but the outcome of this discussion isn't as easy reverted as #177 claims it will be. If Drupal really wants to be future prepared like Dries wants it to, please please seriously reconsider adopting React over a browser native solution like Webcomponents. Or at least be very very careful on picking the layers where it can and not can be used. (see https://www.drupal.org/node/2920196#comment-12326583) React should be a choice for a frontend, not a forced solution.

mpdonadio’s picture

I know this isn't the issue to discuss nuts and bolts, but how do we envision this being implemented?

Are we thinking

- an experimental module that provides React and friends as a library
- an experimental admin theme that provides templates + JS + CSS that React things up

?

If this is the case, then I don't see React or any framework as being forced on anyone, and Vue, Angular, etc, could be provided in a similar manner.

Rene Bakx’s picture

Experimental theme or module won't work unless core code is duplicated. Core systems like views consist of a very tight combination of logic in PHP/HTML and JS.

dawehner’s picture

Experimental theme or module won't work unless core code is duplicated. Core systems like views consist of a very tight combination of logic in PHP/HTML and JS.

I don't see why the experimental thing could not provide the necessary extension points that views could implement the same API.

Rene Bakx’s picture

Everything can be made working if you have plenty of time. It's integration of B without breaking A that's the hard part. I was referring to the viewsUI as one of the most complex systems in Drupal, not to set an example of why this would fail.

And on a little side note :

I know that my way of communication is a bit harder, bluntly direct even, especially when it comes to things I care about a lot. And this happens to be one of those things. I've spend a lot of energy and time in making Drupal workable for my frontend specialist team members so incorporating 3rd party systems into core in places they will have a hard time overruling it makes them afraid. And it makes my job of selling Drupal to them as being way more themer friendly as they think very hard. So yeah, i'm passionate about this subject. It's not an excuse to attack people but anger and passion aren't always the best advisers. Yet I stand behind my words, decisions should be made because it's the best for the project, and not necessarily for the individual(s) who happens to know about a given solution.

Having said that and reading the outlines being discussed by dawhener in https://www.drupal.org/node/2920196 I believe we are on the same page when it comes to the what we can and can't do parts.

niccolox’s picture

I would suggest Drupal.org look into companies that DO NOT use React and the reasons why, a much harder thing to find.

I remember reading Vmware engineers disclosed their legal team refused to use React because of the PATENT issue.

The React patents file requires that the license can be revoked if there is a lawsuit.

So, imho including React in Drupal core means that no company using React / Drupal will ever be able to challenge/defend against Facebook in court.

Facebook also owns the copyright to React and could change anything at any time.

Facebook is so huge that it could defy the entire open source community at any time.

Facebook is a single corporation controlling an entire ecosystem, whereas Drupal is owned by a association.

Personally, if React goes into Drupal 8 core, I will never use it again.

niccolox’s picture

On a positive note I would suggest Drupal would be much better aligned with Elm.

Lots of opportunities to develop Elm core and contrib and its a much smaller and community focussed next generation framework.

React is lifting a lot of Elm like features.

niccolox’s picture

effulgentsia’s picture

The React patents file requires that the license can be revoked if there is a lawsuit.

That was true for v15 and earlier. And when it was true, React was not in consideration for Drupal core. React 16 is MIT licensed with no patent termination clause, just like Vue, Angular, Ember, and most other free software. If anyone is still concerned about the patents issue, please write up your concerns in #2915586: JavaScript VDOM library evaluation: patents. That issue is closed as "works by design", because the MIT license is unambiguously clear. But comments are still welcome in that issue so long as people still want to discuss it.

effulgentsia’s picture

Facebook also owns the copyright to React and could change anything at any time.

Any copyright owner can change a license in a new release. Any of the vendor libraries that we already use, as well as others we might want to consider using, have that same power. They cannot, however, change the license of what has already been released. So if Facebook changes their license in a future React versions to something not compatible with Drupal, then we'll need to stay on version 16 (or whatever the last acceptably-licensed one is) and then plan to move off to something else, possibly a fork of React, since forking is also permitted by open source licenses, such as MIT. Every other open source project that uses React, including WordPress, will be in that same boat, so the odds of a decent open source fork emerging in such a situation is pretty good. Note that Preact and Inferno already exist as decent React-like libraries.

Facebook is a single corporation controlling an entire ecosystem, whereas Drupal is owned by a association.

What do you mean by control? At least how I understand that word, I do not think that Facebook controls the tens of thousands of React plugins and components that are out there.

Personally, if React goes into Drupal 8 core, I will never use it again.

That's your choice and while you certainly don't need my support to do so, I still want to say that I fully support everyone's right to boycott corporations in whatever way they want to. I don't personally feel a need to boycott FaceBook in this particular way, but everyone is free to make their own decisions about that.

effulgentsia’s picture

Component: Idea » Proposed Plan

From the issue summary of #2785735: [policy, no patch] Agile process for bigger changes in core (Part A: Ideation):

The Idea bounces from Needs review to Needs work until eventually folks feel that the idea has merit enough to raise it to a Product Manager for sign-off, and mark it RTBC.

That happened in #174.

Once an idea was approved, the issue moves to the "Plan" component

The idea was approved in #177. Therefore, changing the "component" field accordingly. If the initiative team forming around this would prefer to close this issue and start a new one for the "Plan" phase, that would be fine too.

The "Plan" issue goes through the same Active > Needs review > Needs work > Reviewed & Tested > Fixed cycles, this time pulling on Subsystem maintainer review, Topic maintainer review, $foo Manager review, etc. as needed.

For everyone who's given feedback on this issue so far, thank you. All of it will get incorporated into the planning phase, whether that's a continuation of this issue or the start of a new one.

From #182:

at least be very very careful on picking the layers where it can and not can be used. (see https://www.drupal.org/node/2920196#comment-12326583) React should be a choice for a frontend, not a forced solution.

+1. This issue title already says "for administrative UIs" and Dries's blog post is also clear about that (see the "My recommendations at DrupalCon Vienna" and "Selecting a JavaScript framework for Drupal's administrative UIs" sections in particular). Figuring out the details of that is happening in #2920196: Which capabilities should modules have in a new JS based admin UI and will get incorporated into the Plan issue as things get figured out. As with all Drupal issues, everyone is welcome to participate in the issues.

Rajab Natshah’s picture

What's the difference between client/server side react rendering? What's the latter even is?
https://github.com/facebook/react/issues/9681

Recently I went in a Tech Talk with sessions from Expedia, and they do have 2 bootstraps (old and new) for their system with 60 micro-modules for artificial generation of links for search results to be indexed organically with search engages.

The most important point for us is that they do use React on the Server and the Client side, and both do rendering for the DOM of the page.

I think we could do some yml schema to switch the behaviour of the twig template or in views.

Example:

mytheme/templates/ds-1col--node-news-full.twig
mytheme/react/node-news.yml

node:
  news:
     display_modes:
       default:
          use_twig: true
          use_react: false
       full:
          use_twig: true
          use_react: false
       teaser:
          use_twig: true
          use_react: true
          render_side: server
       horizontal_teaser:
          use_twig: true
          use_react: true
          render_side: client
alexej_d’s picture

Rendering react templates on the server side requires the JavaScript event loop if I recall correctly. Emulating this behavior in PHP is not easy and would require an additional PHP module I think

fgm’s picture

It might be possible by enabling the http://php.net/manual/fr/book.v8js.php extension. This works for VueJS, so could conceivably work for React too, and could be a simpler option for many hosting situations than combining a separate nodejs server with the PHP FPM daemon: it's just one more PECL extension.

Could be supported like the Twig C extension used to, but with more reason to be than Twig ever had, since it was just an accelerator (which turned out to be slower than PHP in 7.0+).

GrandmaGlassesRopeMan’s picture

@alexej_d and @fgm There's a bit more involved than just a PECL extension. Getting the correct V8 version built is a bit of a hassle (this would apply to any framework/library), and then V8JS provides it's own JavaScript api which requires some minor adjustments to your own code.

One thing to take into account is the lack of checksums with React 16+. You can render your html markup on the server (with Twig) and React can bootstrap after that once the client code has loaded.

alexrayu’s picture

It's interesting that talk of React keeps falling back to JS server side rendering, and rightly so. React relies on a complex infrastructure of libraries, and is not seriously used all alone by itself without NodeJS, JSX, Redux, and all other chain of things that it pulls.

Let's think logically:

Against React:

  1. React is the slowest of the existing frameworks. Even than Angular.
  2. React is "view" parts, so it pulls lots of components that it needs to make it usable.
  3. React is universally recognized as a harder solution than most other frameworks.
  4. React does not support web components well enough.

For React:

  1. React has been used by most large companies and projects in the US.
  2. React developer is easier to find in US.

Please correct me if I am wrong, but all the reasons for React seem to be marketing, and that US specific, and technical are all against.

What about the Wordpress using React?

In Wordpress, the admin site is quite divorced from the front facing website itself. In Drupal, admin and front facing site are much deeper inter-twined, historically. Thus, you can't just implement React for the back end.

The need for a framework

I think everybody agrees that there is a need for a framework to power the better UI for Drupal. We have has jQuery, underscore, and backboneJS in core, and no one complained. This is because these are small and efficient libraries, technically justified. Now, if you look at React, it does look very very questionable technically, unless you are building a NodeJS application. So we need to choose a framework that is:

So let's be logical and professional, and do a list of criteria, and evaluate,

Criteria

  1. Relatively well known.
  2. Templatable (most of them are).
  3. Supports web components well.
  4. Slim.
  5. Fast.
  6. Self-sufficient, but integrates well with others.

Where would React be in this list? Vue? Elm?

Why are we discussing this hotly?

There is a simple fact. Most of the top tier devs of current Drupal work in a half dozen of known large companies. Drupal business has crystallized significantly. The large companies can leverage steeper curve applications, with NodeJS, decoupling, React-driven apps, etc. And the smaller and medium sized businesses won't be able to leverage these front end solutions easily - they don't have the budget for that.

So let's be frank - making Drupal so that only Enterprise level companies can use it is what comes from REALLY introducing React in core. It WILL pull NodeJS, WILL pull Redux, and what not. My personal opinion as a small business developer, is that one could really adjust to the changes Drupal has been making, and still use it. But I am suspecting that React and it's "merry companions" well be it.

So I would really love for some who is a first tier developer, write and answer these points and prove how React is small, fast, and won't pull NodeJs and viscera after itself all over the system.

MiSc’s picture

I think that this thread is interesting for this issue: https://hn.svelte.technology/item/15567657 - discussions around why Netflix stopped using React in the frontend.

e0ipso’s picture

The tone of many replies in this issue are making me sad. Please try to keep the community healthy.

Since this is an experiment at this point (correct me if I'm mistaken), I propose that the people willing to help with React go for it. People willing to go for a different solution can try to convince other with their own experimentation.

Finally, people only willing to tell others not to do stuff, that they are wrong, and not do anything themselves… try to be more constructive. I mean, at the end of the day you don't want to have acid reflux over React right?

joaogarin’s picture

I hope that a consensus is reached here and that it is something that the core js maintainers and people who have worked on drupal’s js are super happy and excited about. To me that has seemed to be react..altough its not my normal framework of choice I would fully support it and would be extremely happy to see it move forward.

As a Angular developer I just back what was already said in #161, Angular would be in my humble opinion a great choice just like many of the frameworks proposed here including react.

My vote goes to what reaches more consensus inside the core js maintainers and people who actively work and will work on the javascript system of drupal.

Most of all its a bit sad to see a topic that makes me so excited and happy to see brought to table divide so many of us and in such a harsh way.

I really hope to see a javascript framework be tested for administrative UI's and I am pretty sure the result will be something great to use, and fun to work on.

Cheers!

aleksip’s picture

React 16 is MIT licensed with no patent termination clause, just like Vue, Angular, Ember, and most other free software

The patent risk with company-led projects is different from community-led projects. Also, we should not only consider 'realistic' risks, but our values and position on software patents in general.

That issue is closed as "works by design", because the MIT license is unambiguously clear.

How can the MIT license be unambiguously clear if the Free Software Foundation and several lawyers do not think it is? Even Facebook itself still insists that an explicit patent grant would be better.

move off to something else, possibly a fork of React, since forking is also permitted by open source licenses, such as MIT

Forking alone will not protect from possible patents.

I do not think that Facebook controls the tens of thousands of React plugins and components that are out there.

The tens of thousands of React plugins and components are dependent on React technology controlled by Facebook. This is exactly what some of us do not wish to see: Drupal becoming dependent on a company-led project that is not based on open standards and could be covered by ambiguously licensed patents.

I still want to say that I fully support everyone's right to boycott corporations in whatever way they want to. I don't personally feel a need to boycott FaceBook in this particular way, but everyone is free to make their own decisions about that.

While there might be people who do not like React just because they do not like Facebook, for me at least the problem is what Facebook is doing with React. Companies are understandably interested in what is best for them, and Facebook is no exception. Facebook is very open about React being developed for their own needs, and that they are not interested in open web standards like Web Components. If Facebook really had wanted to settle the patents issue for good, they could have licensed React with a generally acceptable explicit patent grant or made a legally binding statement that React is not covered by Facebook patents. Now it looks like they still want to keep the patents card up their sleeve, just in case.

This issue title already says "for administrative UIs"

Even if React is used only for administrative UIs, if Drupal can't be downloaded and administered without React, then React is forced on all users. And if they don't want to use React, they are forced to use something else than Drupal.

people only willing to tell others not to do stuff, that they are wrong, and not do anything themselves… try to be more constructive.

This would be a valid point if this was just a technical decision. Personally I find this to be also a philosophical and political decision, something that simply cannot be solved by good old Drupal do-ocracy alone. It should be possible to discuss something as important as our values in a civil way.

If Dries, core developers and most of the Drupal community are happy with or indifferent to the philosophical, political and practical implications of choosing React, that is of course absolutely fine. But maybe Drupal's values and principles should then be changed to better reflect this reality.

xjm’s picture

Status: Needs work » Fixed

Thanks everyone! As @mpdonadio raises in #183, this will be an experimental admin UI (not yet any part of stable Drupal core). Next steps:

As a reminder, if you're interested in experimenting with a different framework, there are these other issues you can participate in:

Marking fixed as per #177. Thanks again for all the input, feedback, and energetic discussion. I look forward to learning more in our research!

effulgentsia’s picture

Component: Proposed Plan » Idea

Thanks, @xjm! Resetting the Component to Idea as it was prior to #192. In other words, what's "Fixed" is the Idea phase of the proposal. Now we need a new issue for the Plan phase. #2920196: Which capabilities should modules have in a new JS based admin UI and #2913790: List of missing APIs and others TBD can become child issues of the new Plan issue once it's opened.

neclimdul’s picture

All of the sub issues for design and discussion seem to be pretty quiet. Is anything happening with this or is it stalled?

David_Rothstein’s picture

Title: Proposal to use React for building Drupal’s administrative UIs » Proposal to experiment with React for building Drupal’s administrative UIs

Here's a more accurate issue title (based on what I can tell from above). Maybe this title would have prevented 200+ panicked comments... or maybe at least it will prevent the next 200 :)

That said, I think #2915586: JavaScript VDOM library evaluation: patents is still a potential blocking issue for React (time will tell), but certainly not any reason to block experimenting with it.

neclimdul’s picture

That's not much compared to "Drupal looking to adopt React" with no context which is still front and center on the d.o homepage linking to a post by our BDFL. I doubt many people found this directly but rather through that post which primed their(at least my) expectations. That _definitely_ hasn't helped.

tedbow’s picture

@neclimdul and all. Here is the project to start experimenting with using React for Drupal's admin UIs. https://www.drupal.org/project/react_admin

Currently it does have the Dblog page with React front-end.

If you are interested in helping out, testing it or just keeping up the progress please check it out.

neclimdul’s picture

I'm actually not interested in React, but I am interested in participating in design discussions so that any Vue experiments can address similar design concerns.

xjm’s picture

Thanks @neclimdul. It's not stalled; these are the main followups I'm aware of:

The initiative also is a topic during "JavaScript office hours" so that's the easiest way to get more info.

We could probably do some better communication about the current status as well, so I will ask about it this coming week. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

webchick’s picture

Main work for this initiative is happening at https://github.com/jsdrupal/drupal-admin-ui

There's also the main overview of initiative goals at: #2926656: [plan] Modernize Drupal's JavaScript

gr8tkicks’s picture

I have to agree with @btopro here, the fact instead of going all in with an open solution like web-components instead of a monolithic Javascript framework such as React seems like a bad idea to me. React maybe cool today, but Drupal has Backbone.js in it now, people thought that was gonna be the thing... and now, I don't know anyone using Backbone. I would prefer a more decoupled approach where web-components could be used to build both backend and front-end functionality, with fallback as classic Twig UI. I also find the need for two server-side languages to render the UI a great barrier to entry for most people.

jwilson3’s picture

I also find the need for two server-side languages to render the UI a great barrier to entry for most people.

Interesting point. And I get that react would normally be hosted with a node js server and that might be a burden, but does the react implementation in the drupal-admin-ui actually use any server-side computational components or is state purely managed client-side js and then synced via api calls to server-side php (drupal)? Could the react side in effect be a static js app served by a CDN or even through apache?

imclean’s picture

This issue is closed so discussion may be best elsewhere. That said, #213:

Could the react side in effect be a static js app served by a CDN or even through apache?

To a certain extent this is possible now with any front end framework. It would only support client polling rather than server push.