Selecting a client-side framework for Drupal

Last month, my blog post about whether a client-side framework is right for Drupal stimulated some excellent insights into how the future of the Drupal front end might look. There was broad agreement that incorporating more JavaScript into Drupal's administrative interface is important for a future-ready user experience.

I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds. Of course, this does not mean I oppose fully decoupling through any other framework; in fact, I believe we should redouble our efforts toward a first-class API-first Drupal. But progressive decoupling means that we will be able to work toward a next-generation user experience without abandoning much of the work we've done so far.

With that in mind, I tasked a small team made up of various experts from the Drupal and various JavaScript communities with putting together a list of criteria and a comparison matrix to help us decide on the most appropriate client-side framework for progressive decoupling in Drupal.

JavaScript framework comparison matrix

After a hundred hours of work, we came up with a criteria document and comparison matrix (PDF version):

Special thanks to all of the following experts who provided review and input: Miško Hevery (creator of Angular; Google) and Igor Minar (technical lead for Angular; Google); Ed Faulkner (core maintainer for Ember); Amitai Burstein (Drupal and Elm contributor; Gizra); Sebastian Siemssen (Drupal contributor, Elm and React developer; Zensations); and John Albin Wilkins (Drupal 8 mobile initiative lead), Alex Bronstein (Drupal core maintainer; Acquia), Wim Leers (Drupal core contributor; Acquia), and Preston So (Drupal contributor, Acquia).

Though this is a good starting point that lays the groundwork for a formal adoption process in Drupal core, it is time to open our comparison for review by members of both the Drupal and JavaScript communities. We should also more rigorously evaluate these frameworks' appropriateness through actual development.

First, have we decided on the right criteria regardless of the frameworks themselves? This is probably the most important at this stage. While many organizations choose to adopt client-side frameworks for fully decoupled implementations, Drupal is the first to consider layering a framework on top to allow both richly dynamic and more traditional modules to coexist gracefully through progressive decoupling. What issues around templates, rendering, and client-side caching should we incorporate into these criteria? Is there anything missing or overemphasized?

Second, have we selected the right frameworks to focus on? Are there other frameworks, libraries, or even compile-to-JavaScript projects (such as Elm) that should be included in the matrix? In my view, it is best for Drupal to adopt a framework with an already large community and ecosystem that would allow us to more quickly bridge the gap and resolve any friction during adoption. To provide a good frame of reference, we've also included Backbone, Angular, and Knockout, all three slightly older among client-side frameworks. Others on our shortlist that we didn't consider due to low levels of adoption and small communities are Mithril, Riot, and Vue. Still other ambitious projects such as the Elm and ClojureScript languages are also candidates, but their adoption will mean more up-front work to support typical features of client-side frameworks, as well as buy-in into an approach where JavaScript is compiled from a different language.

Finally, have we drawn the right conclusions against these criteria? In other words, did we fill out the cells correctly? While they have been reviewed by some of the frameworks' experts, there might be unexpected gotchas or caveats.

I'm sharing the initial comparison matrix on my blog for maximum reach; I want both the Drupal community and the JavaScript framework communities, as well as the broader front-end community, to take note. After three installments on my blog ("The future of decoupled Drupal", "Should we decouple Drupal with a client-side framework?"), it's time to move the technical conversation to There is now an issue in the core issue queue on to iterate on the matrix.

Preliminary conclusions

At the moment, the most promising candidates in the comparison matrix appear to be Angular 2, Ember, and React, given their technical robustness, relative suitability for progressively decoupled Drupal, and their strong levels of community support and broader adoption. Given that Backbone is already in core and several modules already rely on it, we have included it too.

What we've learned from talking to the different projects is that they are often converging on similar techniques and best practices; they are by and large adding support for Virtual DOM implementations or rehydration (seamless state transfer), and they are all obsessing over small payload size and performance, better testability, etc. Therefore it is important to focus on the fundamental, often philosophical, differences between the projects that will likely be unchanged in time; key architectural differences, their release cadence and stance on backward compatibility, their license, their governance model, their flexibility and learning curve, etc.

From a quick glance at the criteria and our needs, it seems that Ember is currently our best candidate, as it appears to have a slight technical edge overall. Ember 2.0 has an all-new rendering engine named Glimmer, and it has server-side rendering through FastBoot. On the other hand, however, Ember is quite bulky and opinionated (enforcing patterns for code structure) compared to other candidate frameworks. A more fundamental difference is that unlike Angular and React, which have corporate governance and funding, Ember is a community-driven project like Drupal.

While React is lightweight, it needs integration with a variety of other libraries in the React ecosystem to work as a full-fledged implementation, which gives it a steep learning curve from an implementation standpoint. Because React is a relatively young project, best practices are shifting quickly and making it less attractive. The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors.

Angular 2 is a complete rewrite of Angular 1 to address issues with that version of the framework, including performance problems stemming from a large file size. The new version also introduces a new template engine that incorporates both directives familiar to Angular 1 developers and nestable component-based templates. But Angular 2's Apache 2.0 licensing is incompatible with Drupal's own GPLv2 license. While Drupal's PHP code and JavaScript code run in isolated processes, it appears that an Apache 2.0-licensed project can't be jointly distributed within an umbrella project that uses a GPLv2 license.

In addition to being at a slight technical disadvantage to Ember, the legal concerns with React and Angular make me believe Ember might be our best bet. But I'm not a lawyer nor a JavaScript expert, so I can't make this decision alone; I'm looking for lots of feedback, particularly from JavaScript experts, to determine the best option for Drupal.


Whatever the result of the debate around which client-side framework to adopt, I believe that Drupal needs to move quickly to embrace a framework that will aid development of a progressively decoupled architecture and corresponding user experience improvements. By providing some baseline criteria and including our accomplished community, I have no doubt we can reach this decision quickly but also intelligently.

Special thanks to Preston So for contributions to this blog post.


dawehner (not verified):

One point we need to research one: Do those projects scales to the size of Drupal? Most apps out there have a really limited usecase, their domain basically, while Drupal builds really generic ideas.

Just one random example: In Drupal our data model cannot be hardcoded but rather is dynamic due to the usage of fields. Would it be possible to have such dynamic models?

Adam Bergstein (not verified):

My impression of decoupling the front-end from the backend was to afford opportunities to enable any front-end technology or have Drupal operate in a more headless, unassuming manner. After reading your post, it suggests we are still in the mode of selecting one. I see value in asking "How can Drupal be engineered to support any front-end framework?". While this may not be attainable, Drupal may be able to support a series of hooks that change it's theming engine and make these swappable from within a module.

webchick (not verified):

I think it's both.

Obviously, we want a really robust REST API to support whatever kind of front-end you want to put in front of Drupal: a front-end JS framework, Flash, a mobile application, etc. That part will be framework-agnostic.

In terms of progressive decoupling, however, it does make sense to standardize on a single recommended framework for best practices, because this code will (ideally) end up enhancing core/contrib modules' UIs throughout the course of Drupal 8's lifetime. Having to learn N frameworks to fix bugs in module A vs. module B (not to mention the performance penalty / conflict risk of loading multiple external libraries) would be bad.

Preston So (not verified):

I don't think these two trajectories are mutually exclusive. My interpretation of Dries' post is that he still prioritizes an API-first Drupal that facilitates fully decoupled applications which use Drupal solely as a JSON API layer. These fully decoupled implementations should not be limited in any way from choosing the framework most appropriate to their respective use cases. By the same token, however, it's undesirable for many disparate module UIs to depend on disparate frameworks, especially if they're slated for inclusion in core or used in the same site build. Incorporating Backbone enabled us to enrich multiple core UIs (Quickedit, Toolbar, Tour, CKEditor button/group configuration). By standardizing on a single framework for Drupal's administrative layer, we can avoid later technical debt by developing our rich, JavaScript-powered module UIs on a single framework according to a unified set of best practices.

AL the X (not verified):

Component libraries like Vue JS ( and Mithril ( already embrace a more decoupled approach to front-end and back-end development and are both licensed MIT. Both of those libraries are still figuring out the client-side rendering component, just like Angular JS 2.0, but also support isolated components without hijacking the entire document for client-side rendering.

Ivan Borisenko (not verified):

Mithril is great! Also, I absolutely sure that in 2017 it will be most popular framework Cycle.js, which is much more improved and adapted JavaScript ELM kind. People hate Angular and it feels dawn of React too. Just check out Snabbdom performance. Frontend JavaScript community moves to Functional Reactive Programming approach. And note that it's also the Meteor community too with fantastic 1.3 version!

Ryan Tablada (not verified):

One comment that I have is in an open source project such as Drupal, is "Code structure unopinionatedness (M)" a good thing?

When looking at Drupal in the server side arena, there is already a "Best Practices" guide: While Angular and Ember have a steeper learning curve for base contributions (although there is something to be said about being able to contribute in HTML or HBS without touching JS), it does standardize the code and level some of the playing field when it comes to more in-depth features. Jumping on to a framework with set conventions, you would be gaining and contributing back to general best practices.

I also think that another field you may want to look at is how close these libraries map to the web component specification. I think Angular is the closest to the actual specification, while Ember is trying to get closer with things like Glimmer 2.0 and anglebracket components.

Pieterjan (not verified):

As both an Ember and Drupal enthousiast, I welcome this wholeheartedly.

I believe that an opinionated framework isn't supposed to be a negative point, I think that having a unified coding standard across projects increases code collaboration and adoptability. Agreed the learning curve is slightly higher, but casual contributors will find their way more quickly after a while, and to be honest, its not that Drupal is so learning curve friendly.

Ryan Tablada (not verified):

Also, with Ember or Angular there is a lot of room for things you can do in just templates to contribute.

Seems like the Drupal contributing docs advise first time contributors to start off in templates or styles, so I don't see why this should change with the decoupling.

Having distinct templates away from your JS makes this an easier point. And while Array.prototype.reduce is "Just Javascript", I think a templating language "#each" or "ng-for" is easier to understand.

amitaibu (not verified):

I think this comment about Elm is not correct:

> but their adoption will mean more up-front work to support typical features of client-side frameworks ...

No doubt that Elm, by being less popular has less examples, but I find it can be already used like any other JS library. We actually did a whole project that mimics a typical web-app, written in Elm -

Beyond the fact that we got what we wanted - I personally never had such a positive example in writing front end, where testing was so easy, and the compiler was constantly saving us from our-self.

Sebastian (not verified):

> Beyond the fact that we got what we wanted - I personally never had such a positive example in writing front end, where testing was so easy, and the compiler was constantly saving us from our-self.

This is a strong point for Elm. It is so incredibly well designed and beginner friendly despite due to how amazingly well the compiler performs and guides you during your development. I've hardly ever had such a pleasant time when first dabbling in a new programming language. The ease of setting up an Elm development environment and then writing the first pieces of code is incredible. I believe that Elm also found the perfect middle-ground between fully academical FP and an interpretation/implementation of such for mere humans.

I am myself also a React user and I still like and use React every day but there are a few serious problems that we need to think about (and I believe they do not only apply to React but to any of the other contenders above with the only exception being Elm as far as I can tell thus far). The most apparent problem to me is the large ecosystem that quickly grew around React with all it's variations and altering libraries for all sorts of problem spaces. Taking a quick look at one of the many boilerplates/starterkits will quickly overwhelm you unless you are already an experienced JS/React/Webpack user. Learning React nowaday means not only actually learning writing React components but also grasping the entire stack made up of dozens of NPM packages and webpack configurations.

Nate (not verified):

> Learning React nowaday means not only actually learning writing React components but also grasping the entire stack made up of dozens of NPM packages and webpack configurations.

This, in my opinion, is one of the major strengths of Ember. Ember-cli provides a very good build and testing system out of the gate, and gives add-on authors a standard way to hook into Ember apps and builds. The community has fully adopted ember-cli. Every time I've looked at React, the lack of any structure around build systems and configuration has frustrated me.

Ryan Tablada (not verified):

Another thing to possibly look at is Backwards compatibility as a "must have" or "should have" consideration, upgrade paths, and longevity into the future. I would imagine there needs to be a good path for admin area developers (both as part of core and plugins) to be able to easily upgrade their work to the next version. What do the commitment to notifying breaking changes, providing tooling, and LTS support.

Marc Drummond (not verified):

A few things I would really like to see clarified:

  • I *think* this discussion is primarily about selecting a JS framework to generate Drupal back-end admin pages. Essentially anything with an /admin path. Are we talking about generating the entirety of those pages with JS?
  • I don't think we're talking about generating every theme's user-facing pages from a JS framework by default, right?
  • What about admin UI that appears on user-facing pages when an admin user is logged in, like toolbar, quick edit and contextual links: would those be generated from a JS framework alongside the presumably non-JS generated content?


Great questions. Let me try to clarify my current thinking:

I *think* this discussion is primarily about selecting a JS framework to generate Drupal back-end admin pages. Essentially anything with an /admin path … I don't think we're talking about generating every theme's user-facing pages from a JS framework by default, right?

For me, the *eventual* goal is to reduce or eliminate latency between user action and screen update wherever doing so improves UX and is feasible. Eventually, this should include both admin UIs, like arranging blocks in a layout, and non-admin UI, like posting a comment. In some cases, latency between client and server can be reduced with websockets and persistent asynchronous PHP, but I expect that even with those reductions, there will remain cases where eliminating the latency entirely by performing the screen update completely client-side will be preferable.

Getting all the way to a Drupal UI architecture that allows for that across the board, from admin UIs to non-admin UIs and everything in between will likely take years. How to resolve various integration concerns, from theming to hook_form_alter() and more, especially for end-user UIs is not at all clear yet and challenging to answer. It is something we should explore, before we make any drastic changes.

So, I think it makes sense to start with just admin UIs like Block UI, Field UI, the CKEditor button/group configuration UI, etc. Perhaps that means that the next generation of these UIs would for some time only work with the Seven theme, but over time, other admin themes can be refactored to support them, and in the meantime, site builders using other admin themes could still use the current UIs.

Are we talking about generating the entirety of those pages with JS?

Probably not during Drupal 8.x. All of the JavaScript frameworks under consideration in our matrix can be targeted to only the page components that need dynamic behavior. If we wanted to generate entire pages in JavaScript in Drupal 8.x, it would have to be optional, possibly through a second admin theme so Seven (the current admin theme) can stay as-is.

What about admin UI that appears on user-facing pages when an admin user is logged in, like toolbar, quick edit and contextual links

We'd need to explore where it would be of UX benefit to add client-side rendering to these UIs, and then weigh the pros/cons of such a conversion with the pros/cons of the impacts that would have on front-end-theme customization of these UIs.

John (not verified):

No Aurelia on the list? Better then all mentioned frameworks. Sigh ...

John (not verified):

Serious. Very.

In almost every way Aurelia is better then Angular and offer far more control then React. I can tell you haven't built anything with Aurelia but I assure you the competitors don't hold a candle.

Sebastian (not verified):

Just watched the video on the front page of their website and looked at a few examples. I can only speak for myself but from what I saw it doesn't appeal to me at all. Two-way data binding (even if it is optional through that .bind syntax) is a 100% and immediate turn-off for me. In general it looks like an Angular 1/2 spin-off to me. Many similarities. Many of which I don't like.

Anyways, I also believe that you can't actually compare React to Aurelia (nor Angular) directly. React is basically really just a rendering engine. Comparing it to Angular seems fair though. In any case, at least for me, neither Angular nor Aurelia or anything that comes close to these concepts, will ever hold a candle for me ;)

John (not verified):

I'd recommend taking the time to actually read about what is has to offer or better yet actually use it.

Aurelia can in fact be used as only a render library. More to the point Aurelia is simply a collection of libraries. You can pick a choose what you need for your project.

As for bindings I'm not sure I really get your statement. Yes you have bindings in Aurelia, however it's using native object observables that you already have available to you. You don't lose anything by using 2 way binding at all. In fact the current speed tests show Aurelia to be faster than React and Angular 2.

Drew (not verified):

I saw that Aurelia trumpets two-way binding on its list of features, and said "Next Please".

Was that a mistake? I have a similar passion for CycleJS that I have been using over the last 18 months and I just can't get over how much simpler, scalable, decoupled, testable, fast and less opinionated it is, so I admit a strong bias, but I want to make sure I am not missing something vital.

Is Aurelia functional or object oriented?

Protitude (not verified):

I haven't seen polymer mentioned anywhere. Is there a reason this isn't part of the conversation? I know there is still some browser adoption issues, but the community and eventual adoption seems pretty good.

Ryan Tablada (not verified):

Sorry to continue to comment, two more things to consider:

The weight of Drupal being able to influence the direction of a chosen framework's API:

In the case of Angular or React, the primary architecture of the API seems to be driven by the owning parties (Google and Facebook respectively). I think in a community that does not have a particularly owning interest, Drupal (as well as any contributor for that matter) has a bit more weight in API decisions.

Tooling and Dependency Management:

While I think Angular (with Angular CLI) and React have some similar stories, Ember has something REALLY special around addons with Ember CLI. I think that Engines ( will further this into some cool possibilities. While the full implementation is still yet to be seen the promise is something to the effect where the Drupal Admin area could be mounted into any Ember Project as an engine.

Jon Koops (not verified):

This is where server-side rendering of the framework comes into play. By rendering the page on the server first the user will have a page to work with even though the JavaScript is not yet loaded. This should help a lot of mobile users in terms of user experience and user perceived performance.

An excerpt from the document attached to this blog post:

"Server-side rendering of framework templates is important for SEO and performance. Over time, it allows us to migrate to unified templates across client and server and a server-side JavaScript-based render, whether via in-PHP JS execution or via a thin layer of Node.js."

Ryan Tablada (not verified):

For mobile another thing to consider is the tooling around webworkers. This can heavily improve performance.

I think the ease of writing and contributing would rule out plain old JS client apps in a OSS project.

highermath (not verified):

Perhaps we should put some resources into clarifying, if not resolving, some of the perpetual license incompatibility issues.

I know all too well that these are nor trivial, but even a little improvement could be very helpful.


I reached out to both the Angular and React communities about the suitability of each framework's license for Drupal.

Angular's technical leadership replied and told me they will check with Google's legal team about this matter. This happened during the holidays, so we're still waiting for a follow-up.

We also contacted a couple of React maintainers about their license but did not receive a response. I skeptical that React would change its license since we're not the first to bring this up; both React and Calypso contributors have discussed this at length in GitHub issues and pull requests without any real change from Facebook.

John Woot (not verified):

I believe vue.js is a strong contender and should be included in the comparison. It's stable (version > 1.0 with string adherence to semantic versioning) and it's already more popular that Elm or KO (12000 stars on GH).

Chris Weber (not verified):

I like the iterative approach that we're talking about here. Being able to pulling JS Framework driven solutions to complex administration pages like that Blocks UI, Node Construction UI (Fields), or maybe in the far-flung future Panels / Layouts UI.

I asked around with the JS Framework devs I worked with and they recommended staying away from Ember and React unless our intent is to build single-page applications (where those frameworks shine) and to consider combining Angular with Vue.js (for better data binding) and Web Components for creating a set of reuseable components

As you may know, I'm a big advocate for Web Components and think they'll help in the handling the complexity and organization of the various administrative components that we'll be making throughout this effort. I think these additional libraries should be apart of the discussion.


Chris, maybe you can try to turn one or more things in Drupal into Web Components so we can evaluate it?

Chris Ruppel (not verified):

Chris, ping me if you want maintainer access to web_components. We got a good start but the two people working on it have had to move onto other things. And we started so long ago that there's no D8 branch so the world is yours.

Sebastian (not verified):

> I asked around with the JS Framework devs I worked with and they recommended staying away from Ember and React unless our intent is to build single-page applications (where those frameworks shine) and to consider combining Angular with Vue.js (for better data binding) and Web Components for creating a set of reusable components

React and Ember also work well when not used in a single page context. In fact, thus far, that is the only way I've been using both.

Re "Data-Binding": I am assuming you are talking about two-way data binding since you also mentioned Angular (1?) and web components? In that case, I have to strongly disagree. Two-way data binding has proven itself useless and dangerous for anything else than a simple form or the likes that you want to quickly prototype with some interactivity. For anything more complex than a seriously simple widget it is a sure way to frustration. Even Google and the people behind Angular 2 must've realized that given that they've dropped support for it.

I am in doubt that Web Components would be the right choice. So far, I've been seriously disappointed with Web Comoponents in general. And that's not only because I believe that they aren't prime-time ready yet. It's still worth looking into though. But I would still like to see a prototype based on Web Components. It's surely worth looking into.

Jose (not verified):

I still don't get why it needs to be in core. I thought some time ago we mostly agreed contrib was a good place for this fights, let module usage decide.

If we settle for any of these frameworks in Drupal core then that will be the one and only option, well, unless you want to load two of the frameworks at the same time for your website, that will be fun.

I also think that most modules don't need to enforce any front-end framework, actually most modules don't need a fancy front-end. But once you provide that in core, they'll just use it, there's no way out.

As a prove: jQuery. Nothing really against jQuery, we did need some minimum js but... Can you build a Drupal web site without jQuery now?

So, again: Contrib is the place. If we find out half of Drupal sites happen to use the same framework in the future, that will be a nice option for Dupal 9, or 8.x or whatever.


I agree that many modules don't need a fancy front end. But there are also many that do, and for those projects, adopting a client-side framework would result in better JavaScript code reuse, a more consistent front-end developer experience, and better performance as we don't have to load multiple frameworks.

Contrib has traditionally been the space where we explore these ideas, but given that so many core modules would benefit from a client-side framework, and also given that some contrib modules are already forging far ahead with a client-side framework of their choice (Panels IPE, for example), it's important to address this at the core level.

Jose (not verified):

I'm not questioning the idea that having that framework in core would provide a much better UX out of the box. But on the other side by making a framework required we are seriously limiting the options for site builders to use any other framework, or not using any at all.

Also most modules don't need it. But by making it available in core they'll just use it. Then they will need it. Just like giving drugs to the kids for free...

I don't know whether people advocating for one or the other framework here are really aware that once we decide on one, it will be their one and only option if they want to use Drupal. Well, they can still do -again- a fully de-coupled Drupal with a framework of their choice..

So let's say I'm just 'pro-choice'.

And in any case, seeing the current landscape, it is just too early in the game to make *the choice*. Really, I don't see here that many Drupal developers needing a js-frontend. What I see mostly are js developers wanting a backend for free for 'their' framework.

The bad news is just one of them may win, all the others will lose.

Mark (not verified):

This debate seems quite similar to including a good WYSIWYG editor in core vs leaving it out of core and allowing any editor to be used. Making the choice for one does limit us in some ways but perhaps it helps Drupal in many more ways?

Andrew Eddie (not verified):

Something you might want to also consider is the interoperability of frontend and backend languages. For instance, Angular 2 is written in TypeScript which provides a backend PHP developer a valuable familiarity ("class", "interface", "extend" et al) once they learn the lingo. This could lead to traditionally isolated frontend and backend engineers being able to cover each others work over time with reduced impact on the cognitive gear shifting.

Ryan Tablada (not verified):

FWIW I would argue the opposite when it comes to typescript. While adding types makes it a bit more like PHP, Javascript is still a very different paradigm with asynchronousity and other things to account for. While typescript will give some type safety, I would say that it fragments the community and makes it a steeper barrier to entry since to really understand typescript you need to know the Javascript that it comes from (and ends up compiling down to).

Brandon (not verified):

For what it's worth, Ember CLI is almost reason enough on its own to choose Ember. It brings a lot of speed, convenience, and reliability to front-end development, and it also facilitates learning how to use Ember's architecture in a standardized way. Not sure why glimmer wasn't used in the benchmarks, but that's also a massive performance gain over handlebars. It should be known that I'm in love with Ember and haven't used other frameworks very often, though :) my opinion is quite biased

Matthias (not verified):

After the Twitter convo this weekend: I've posted my .2 cents on my blog:


1. ClientsideJS: Yes! / ServersideJS: No!
2. Selecting a framework is only a first step. Question: how do we approach decoupling? I think we should refrain from a separate single-page app (admin backend) and go for a reusable, extensible and flexible componentized architecture based.
3. Progressive enhancement FTW!! Which means: there is definitely a place for Twig and serverside rendering.
4. This is an excellent opportunity to rethink our tools for controlling / managing display and layout.
5. Challenge: keep a quality DX and be aware of friction between frontend and backend specialists.
6. Existing Drupal developers will need time and documentation to adapt to this new decoupled paradigm.

After hashing out the larger arguments (licensing, community support,...) I believe choosing between the remaining frameworks is not the biggest challenge. Ember, Angular, React or Polymer: it's hard to predict how each one of them will evolve 6, 12 or 24 months down the road.

The real question is: can we architect a flexible, reusable decoupled interface that adds value to the administrative backend for content editors, site builders, administrators, ourselves (developers)...? And can we do it without hurting aspects like accessibility, ease-of-use, developer experience,...

Personally, I would love to see web components (Polymer), but Sebastien is right pointing out that it hasn't seen widespread adoption (yet). React is great, but the patent/licensing issues are totally putting me off. Ember or Angular? I'm inclined to go with Angular because (1) I'm biased do to prior experience with 1.x whereas I never worked with Ember (2) They already went through an entire rewrite (1.x > 2.x) so one can assume that their core API's are landing in a more fixed space at this time.

Mathieu Spillebeen (not verified):
Matt (not verified):

Since Ember is a community governed project, it might be a better choice long term. If Drupal adopts Ember, our community is more likely to get a seat at the table and be able to promote future development directions that are compatible with our needs. That may be less likely in the Angular and React cases.

lebowski (not verified):

Having a specific framework for the administration section is fine; currently done with jQuery. However; why would you want to enforce a framework on the front end? This is a development decision based on needs. When implemented a front end framework should live in the theme layer. The most appropriate way to handle this is from contrib - yeoman builds, scaffolding themes which use tools such as npm.


This would only be for "progressive decoupling", not for "fully decoupling".

Mark Tinsley (not verified):

From an integration perspective, Ember will likely be the most difficult. I would personally like to see Vue.js adopted. But, given it doesn't meet the basic criteria I think Angular is probably the best option (thinking of integration). I would like to see Ember adopted as well. They have a great team and a solid product. I'd be most excited for Ember because their docs need some help and having another large community looking and contributing to them would be awesome. I think that's a big thing holding them back in the PHP ecosystem. Random thoughts probably a bit late. Enjoy.