As user experiences evolve from static pages to application-like experiences, end users' expectations of websites have become increasingly demanding. The Facebook newsfeed, the Gmail inbox, and the Twitter live stream are all compelling examples that form a baseline for the application-like experiences users now take for granted.

Many of Drupal's administrative interfaces and Drupal sites could benefit from a similarly seamless, instantaneous user experience. Drupal's user interfaces for content modeling (Field UI), layout management (Panels), and block management would benefit from no page refreshes, instant previews, and interface previews. These traits could also enrich the experience of site visitors; Drupal's commenting functionality could similarly gain from these characteristics and resemble an experience more like the commenting experience found in Facebook.

As Drupal's project lead, I ask myself: how can our community feel enabled and encouraged to start building rich user experiences?

In recent years, the emergence of decoupled architectures with client-side frameworks and libraries have helped our industry build these experiences. Does that mean we have to decouple Drupal's front-facing site experience (for site visitors or end users) and/or the administration experience (for content editors and site builders)? If so, should Drupal decouple the administration layer differently from the front-facing site experience? By extension, should a client-side framework guide this change?

Here is my current thinking: in the short term, Drupal should work toward a next-generation user experience under progressive decoupling for both the administration layer and the end user experience. At the same time, we should enable fully decoupled end-user and administrative experiences to be built on Drupal too. In my view, the best way to achieve this is to formally standardize on a full-featured MV* framework (e.g. Angular, Ember, Backbone, and Knockout) or a component-based view library (e.g. React, Vue, and Riot). In this blog post, I want to kick off the discussion and walk you through my current position in some more detail.

Should we decouple Drupal itself?

Should we decouple drupal framework responsibility
A framework can assume responsibility over very little, such as with Backbone, or a great deal of the stack, including the rendering process.

The question we have to answer is: do we stand to benefit from decoupling Drupal? In this context, decoupled Drupal refers to a separation between the Drupal back end and one or more front ends. In a decoupled architecture, the back end is built in a server-side language like PHP, the front end is built using a client-side framework written in JavaScript, and data is transferred between the two. Decoupling your content management system gives front-end developers greater control over an application or site's rendered markup and user experience, and using a client-side framework gives them better tools to build application-like experiences.

There is no doubt that Drupal's administration layer is very application-like and would benefit from an experience that is more interactive. For the end-user experience, a decoupled implementation is not always the best option. Some sites may not need or want the application-like interactivity that a client-side framework would provide, since not every site needs interaction. For instance, news sites or blogs do not need much interactivity, custom applications need a great deal, while e-commerce sites lie somewhere in the middle. It's not clear-cut, so let's look at our options in more detail.

The first option is to preserve traditional Drupal, the status quo where there is no decoupling. This would leave the Drupal theme layer intact apart from additional JavaScript embedded freely by the developer, but as a result, the onus is on the developer to introduce client-side user experience improvements. The likely outcome is that different modules will start using different client-side frameworks. Such a scenario would steepen Drupal's learning curve, impede collaboration, make Drupal more brittle, and damage performance on pages whose display is influenced by front-end components of multiple modules.

The second option is to work toward full decoupling, in which Drupal is solely a themeless content repository for client-side applications. But fully decoupling both the Drupal administrative interface and the front end would require us to rebuild much of our page building functionality (e.g. site preview, layouts, and block placement) and to abandon many performance benefits of Drupal 8. Moreover, more JavaScript, especially on the server side, means complicating infrastructure requirements and a large-scale overhaul of server-side code.

The third option is what I call progressive decoupling, where Drupal renders templates on the server to provide an initial application state, and JavaScript then manipulates that state. This means we can have the best of both worlds: unobtrusive JavaScript and all the out-of-the-box performance advantages of Drupal 8 — a short time to first paint (when the user sees the page materialize) via BigPipe as well as interface previews and static fallbacks during the time to first interaction (when the user can perform an action). Plus, while some additional JavaScript would enter the picture, progressive decoupling mitigates the amount of change needed across the stack by using a baseline of existing theme functionality.

Approach User experience Developer experience Ease of implementation
Traditional coupling Page refreshes
No immediate feedback
Interrupted workflow
Theme layer preserved
Modules in mostly PHP
Ad-hoc client-side code
PHP and minimal JavaScript
No server-side change
No client-side change
Progressive decoupling No page refreshes
Immediate feedback
Uninterrupted workflow
Theme layer preserved
Modules in PHP and JavaScript
Unified client-side code
Both PHP and JavaScript
Some server-side change
Some client-side change
Full decoupling No page refreshes
Immediate feedback
Uninterrupted workflow
Theme layer replaced
Module rewrites in JavaScript
Unified client-side code
Primarily JavaScript
Much server-side change
Much client-side change

How should Drupal decouple its user experience?

Should we decouple drupal front end experiences
This diagram shows some of the possible front-end experiences that could rely on a single Drupal back-end. In full decoupling, a custom application built using a client-side framework encompasses the entire front-end. In progressive decoupling, JavaScript manipulates an initial state already provided by the theme layer.

Drupal's administration layer (content editor and site builder experience) is effectively an application. Fully decoupling may be the appropriate call to achieve the best possible user experience for creating, managing and presenting content. However, rewriting the administration layer from the ground up is a monumental task, especially since its modules provide powerful interfaces that allow site builders to build robust, complex sites without a line of code.

The same expectations for application-like interactivity often hold for the end-user experience: users expect shopping carts, comments, notifications, and searches to be updated instantaneously, without having to wait for a page to load.

For both the administration layer and the end-user experience, I believe the Drupal front end should not be fully decoupled out of the box. We should advance from our traditional paradigm and default to progressive decoupling. It allows us to achieve the user experience we want without significant downsides, since not every use case would benefit from fully decoupling. Through progressive decoupling, Drupal could potentially reach the ideals of the assembled web more quickly by preserving a tight link between Drupal modules and their front-end components.

Nonetheless, we should empower people building fully decoupled sites and applications. Depending on the use case, Drupal 8 is a good match for decoupled applications but we should improve and extend Drupal's REST API, enhance contributed modules such as Services, and shore up new features such as GraphQL (demo video) so more functionality can be decoupled. Front-end developers can then use any framework of their choice — whether it is Angular, Ember, React, or something else — to build a fully decoupled administrative application.

Should Drupal standardize on a single framework?

All things considered, I do believe Drupal should standardize on a single client-side framework, but it should only make such an explicit recommendation for progressively decoupled Drupal, not fully decoupled architectures. It would result in a more seamless user experience, better compatibility across interactive components in modules, maximum code reuse, a more consistent front-end developer experience, more maintainable code, and better performance as we don't have to load multiple frameworks.

Despite the potential benefits, there are also good reasons not to embrace a single client-side framework. New front-end frameworks are being created at what feels like an unsustainable pace; every nine months there is a new kid on the block. It's hard for a project as large as Drupal to embrace a single technology when there is no guarantee of its longevity.

For instance, Backbone, with its underlying library Underscore, currently powers interactions in the toolbar and in-place editing in Drupal 8. Though Drupal could expand the scope of Backbone in core and encourage front-end developers to build with it, it means buying even further into a framework that is quite old among its peers.

To deal with the fast-evolving nature of the front-end landscape, we need to be thoughtful about which framework we choose, to reassess our choice from time to time, and to make sure we can migrate fairly easily if we so decide.

What client-side framework should Drupal standardize on?

Assuming we agree that embracing a single client-side framework makes sense for Drupal, there are actually three additional questions: what framework to standardize on, how to do it, and when to decide.

I'm the first to admit I'm not the best person to answer the first question. As I'm not a front-end developer, I'm looking at you, the Drupal community, to help answer this question. I'd hope that the chosen framework aligns well with both our architecture (modular, flexible) and community (collaborative, community-driven).

The second question — how to standardize on a framework — I can help answer. On the one extreme, Drupal could be opinionated and ship a client-side framework with Drupal core, meaning that every installation of Drupal ships with the chosen framework. This would be much like the adoptions of jQuery and Backbone.js. On the other end of the spectrum, Drupal could recommend a specific framework but not ship with it. Finally, somewhere in between, Drupal could provide a default standard framework in core but make it easy to replace with it a framework of a developer's choice, though the likelihood of this is quite small. This is akin to Drupal core shipping with a template engine (i.e. PHPTemplate) that could be (but was rarely) replaced with another. Ultimately, I think we get the best result if Drupal ships with a specific framework—much like the adoption of jQuery in Drupal 5.

The last question, when to standardize on a framework, is important too. I would recommend we experiment with possible directions as soon as possible in order to decide on a final vision sooner rather than later.


I believe that, for now, it makes more sense to progressively decouple Drupal sites and their administration layer by first building our pages with Drupal. Once the page is loaded, we can let a unified client-side framework take over as much of the page as needed to foster a next-generation user experience without reinventing the wheel or alienating developers.

Whatever the result of this debate, Drupal needs your help. We will need initiatives to build a foundation for better decoupled experiences. For all decoupled implementations - whether full or progressive - we will want to redouble our efforts on existing web services to create the best APIs for client-side applications. As for progressively decoupled experiences, we will need a process for selecting a client-side framework and defining how the existing Drupal JavaScript behaviors system would need to evolve. Finally, we will need to coordinate all of these efforts to focus on offering a better administrative experience.

That is not all! We will need module developers to bring rich interactions to their user interfaces with the help of the framework we choose. We will need designers to guide module developers in building a graceful user interface. We will need front-end developers to demonstrate how they want to develop the user experiences that will define Drupal for years to come. We will need users to test and validate all of our work. It will be tough going, but together, we can ensure Drupal stays ahead of the curve well into the future.

Special thanks to Preston So and Wim Leers for contributions to this blog post and to Moshe Weitzman and Gábor Hojtsy for feedback during its writing.


Julien Pivotto (not verified):

You are missing a column in your table, which is the extra cost on user side devices. Some frameworks are really bad for mobile device users performances.


Good point and important to consider. Mobile performance, or even performance in general, probably belongs in the 'User experience' column rather than a new column. What do you recommend I add to the table?

roidelapluie (not verified):

Not sure that it needs to be added to the table but it should probably be present somewhere on the article. Smartphones are not different from desktops and if Drupal takes the path of more decoupling that can have a huge impact on those devices.

Anoop John (not verified):

Progressive decoupling or even complete decoupling on the client facing side of Drupal to facilitate better control over the front end interface is definitely something that will lead to better looking Drupal applications. That would also allow more Drupal developers to specialize on the 'back-end' side of applications while allowing HTML+CSS+JS developers to build out the user facing side of the applications. This should also allow Drupal development companies to grow faster whereby Drupal developers are not constrained by their need to know HTML+CSS side of the system to allow building Drupal based applications.

Darren Woods (not verified):

It's got to be Angular, surely! But version 1 please, no unnecessary enterprise complexity thanks :)

Mike C (not verified):

Wouldn't backing AngularJS v1 be like backing an old dead horse? There's a lot of documented problems with performance of v1 that makes it worth avoiding at this late stage in its life.

Mike B. (not verified):

That is a common misconception among people not using or keeping abreast of the latest Angular news. (No idea if that applies in your specific case.)

Using the latest version of Angular 1.a and following best practices, you shouldn't have any significant issues with performance.

Plus, the Angular team is working really hard to make sure v1.x is maintained and that upgrading to v2 will be as simple as possible when that time comes. V1.x is in no way a "dead" end.

Mike B (not verified):

Not at all. That sounds like a question from someone that reads blogs, but doesn't actually use Angular regularly or keep up with the Angular news. (Note: I don't know if that actually applies to you obviously.)

Angular v1.x is under active development, and the performance problems are generally in older versions. As for "backing a dead horse", the Angular team is working very hard to ensure that when v2 is released, there is a migration strategy in place. Also, they will continue to support v1.x until that is no longer necessary (based on usage, inquiries/stats on the Angular v1.x website). And v1.x and v2 will be able to co-exist, so it will allow for transition to v2 without needing to rewrite all of the existing v1.x code to do so.

Obviously I can't cover everything the Angular team is doing to ensure a smooth transition, but hopefully that's enough to indicate why there isn't an issue using v1.x right now, while waiting for v2 to come out.

Jon Koops (not verified):

Let's be honest here. I have been using Angular 1 for a long time, and it comes with a lot of legacy that makes it very hard to have a mental model of how an Angular app is structured.

Some folks use controllers, some don't. Need a component? You probaby want a transcluded isolated scope element restricted directive (yes. this is a thing). But what way would you pass the values to this component? Well, there are about 10 ways. Angular doesn't even have an established router solution. Not one that can deal with components or nested views anyways.

Angular is amazing and you can do a lot with it. But it lacks an established way of structuring your app. The only thing you've got are community 'best practices' and even those vary wildly.

I just don't believe Angular is a good choice for this purpose.

Adam G-H (not verified):

Drupal's Panels In Place Editing (Panels IPE) was always very reliant on JavaScript, but a decoupled approach is precisely what it's taking in Drupal 8. The Drupal 8 version of Panels IPE is written on top of Backbone. The Lightning project for Drupal 8 will be integrating Panels IPE as its standard UI for layout management.

I've written a Backbone-based widget to integrate media handling functionality (the media_entity module and its various children) into CKEditor. Trying to do it using Drupal's built-in server-side rendering was excruciating, especially once Ajax functionality was introduced into the mix. (You can give it a spin at Username is "admin", password is "lightning".)

So I generally agree with your thinking on this. I'm a big fan of highly intuitive "don't make me think" user experiences that "just f*king work". Drupal provides a lot of structure and power under the hood, but as I've become more experienced I find it less and less amenable to building the kind of highly dynamic, responsive interfaces demanded by things like Panels IPE. I find the classic Ajax throbber antiquated -- infinite scrolling, instant auto-completing keyword searching and faceted searches are better experiences.

Personally, I'd like to see Drupal divided this way -- content rendering, like nodes and users, should continue to take place on the server. Interfaces, both user-facing and admin-facing, should be built primarily in JavaScript (including replacing the HTML-generating parts of Form API with client-side JavaScript).

John Hannah (not verified):

I think standardizing on a FE framework will be very challenging. There is so much instability with these frameworks (which you note) that tying Drupal - which tends to be a very slowing moving project - to something with a lot of churn seems like it will be really difficult. The move from Angular 1 to Angular 2 comes immediately to mind as an example of how a big investment in a FE framework can become a problem in a hurry, but all of them are very dynamic. It would be kind of like yoking a plow horse (Drupal) to a race horse.

There are already a lot of enterprise projects using a decoupled Drupal approach and naturally they use a lot of different frameworks, but the one I see used the most is React. In fact on the project I'm working on right now, the organization is going all in with React. If Drupal settled on Angular, for example, how would it affect the organizations that are making big investments in other frameworks? Maybe I don't understand completely how it might work, but the choice of a single framework seems like it could be divisive and disruptive - disruptive in a bad way, not the SV way.

I think making decoupled architectures easier is great and should be something Drupal does, but it should do so in a way that is agnostic about the FE framework used.


I 100% agree with you that we shouldn't make an explicit recommendation for fully decoupled Drupal implementations -- people should be able to use Angular, React, Ember, or something else. We should continue to invest in fully decoupled Drupal and welcome patches that extend or improve our APIs. We would also benefit from one or more "reference implementations" that people can use as a starting point or accelerator.

I do believe Drupal should standardize on a single client-side framework for progressively decoupling though. You don't mention progressive decoupling in your comment so I'm not sure we agree on that part or not ...

John Hannah (not verified):

I think standardizing on a framework for progressive decoupling will be problematic as well. I'm not sure why Drupal needs to do progressive decoupling because server-side rendering is available with some FE frameworks now. I may not fully understand the case for progressive decoupling, but it seems like selecting a FE framework that handles server-side rendering takes care of the problem without getting Drupal involved.

I also think that if Drupal selects a FE framework, it will widely be seen as an endorsement of that framework and using that framework may become considered, 'the Drupal way'. That would potentially create a lot of difficult conversations with clients who come in the door wanting to use the 'recommended' framework. In the long term I can also see this creating pressure to standardize on the framework that Drupal chooses and I don't think that would be good. When it comes to decoupling, I think Drupal should remain agnostic about the front end.

Mark_L6n (not verified):

John Hanna said much of what I would, so I'll +1 and add:
Fast-moving front-end technologies are providing serious and ever-more complete solutions—I believe Drupal needs to work with them in the future or become irrelevant. But you have the catch-22 of wanting to focus on 1 main framework, while the frameworks are evolving much faster than Drupal. To help mitigate this problem, it might help to target using smaller, less monolithic frameworks. Here, React would be preferable to Angular would be preferable to Meteor, for example.

Mark_L6n (not verified):

Clarification: giving a +1 more to John Hannah's 1st post.

But more importantly, a different point related to using something like GraphQL for the front end to efficiently get data from the back end: Facebook's Relay adds things like caching and optimistic updating to GraphQL; Netflix's Falcor is an alternative; garnering a lot of attention is OM Next: here is a great overview talk that is useful for overviewing the issues involved, what parts of Relay and Falcor are great ideas but what are some limitations they have, and other ideas OM Next has used:
This is a still-developing area, but one in which Drupal could contribute to, with its wealth of experience in multiple forms of caching and DB access, etc.

Jeff Eaton (not verified):

It's great to see more attention focused on the ways that Drupal can facilitate decoupled builds. For a long time there's been a sense that simply providing JSON feeds and REST endpoints for basic CRUD operations would be sufficient, but very few of the decoupled projects we see are simple "Drupal serving JSON to a client-side JS app" systems. Instead they use Drupal to feed a lightweight canonical content storage system.

Given that, I definitely agree with your comment that the best approach for Drupal on a fully decoupled project is to handle the administration and workflow tasks, then *get out of the way*. The best candidates for fully decoupled projects are multi-channel projects that need to deliver on web, app, and other diverse platforms, so anything Drupal handled on the front end would be of limited value anyways.

Another thing that's worth noting is that "decoupled Drupal" is far from theoretical — there are loads of real world projects, large and small, that have been built that way over the years. CNBC has been running a fully decoupled Drupal site since the days of Drupal 6 with a custom PHP frontend, Lullabot's last redesign has a React-based front-end with server-side rendering in Node, and I know of at least two or three very large clients who are using the D8 upgrade cycle to make the jump to a fully decoupled architecture.

A couple of our engineers have been writing a lot about the lessons learned (,…,, and in particular) and I'd love to see more teams dig into the ups and downs of their decoupled projects.


Thanks for your comment, Jeff! I agree that decoupled Drupal is not new or theoretical -- thanks for pointing that out as I glossed over that in the blog post. Like you, I'd love to see more teams build decoupled websites, and contribute back to Drupal in the process.

amitaibu (not verified):

I do believe decoupled is the right way. No doubt it poses challenges. And it doesn't really remove work - it just shifts it form one place (backend) to another (frontend).

However, as someone who does headless Drupal on a daily basis I wouldn't wish to go back. In fact, the server side becomes much simpler - modeling the content, setting up the permissions and exposing entities via RESTful.

I think a possible way forward is to start experimenting with this idea. For example with this Hedley example (Drupal backend, Elm frontend), we were able to get some Elm devs to start using Drupal! They saw the immediate benefits that Drupal brings to the table as a proper RESTful server.

Marc Drummond (not verified):

As a front-end developer, I'm genuinely not clear on what you're proposing here.

It seems like you're suggesting that you'd like to continue to handle rendering server-side with Drupal's PHP-based theme layer, while enhancing client-side interactions with a JS framework.

Most JS frameworks of the sort you're referencing (Angular, Ember, etc.) handle both the initial page render and subsequent interactions with JS entirely on the client-side. React's special sauce is handling the initial page render on the server with the same templates that are subsequently user for client-side interactions. Those don't line up with PHP-based server rendering and JS-based client interactions.

One of the challenges of the progressive decoupling that you're proposing is that even if there were a post-render JS framework for client interactions, that might require an entirely separate set of templates, depending on how extensive the interactions need to be. If the goal is to avoid page reloads, probably very extensive. If somehow the server-side Twig templates could be reused in conjunction with client-side interactions, that might reduce markup duplication. However that sounds like recreating Drupal's theme layer in a JS framework.

As others have mentioned, while client-side JS frameworks avoid page reloads, they can have very negative impacts on mobile performance because of the need to load the entire framework before rendering the page. So I am encouraged to see you looking at handling the initial render of the page on the server.

I would be genuinely interested in some examples of the sort of JS frameworks you think could fit the goals you are talking about, because that is where I am most unclear on what you are trying to achieve.

On another note, I have felt very good about how Drupal 8 has been able to pull in numerous new contributors to work on improving Drupal's front-end. We made big strides on improving Drupal's default markup, the way that markup is edited with the addition of Twig, allowing CSS and JS to be loaded only where needed, and generally making Drupal more mobile friendly, along with a host of other theming improvements.

Replacing all of Drupal's front end with a JS framework would undo all of that effort. It sounds like what you're looking at is not as all-encompassing as that. You are the benevolent dictator and can of course make decisions on the direction for Drupal. However since it is Drupal's contributors who actually need to implement that direction, it feels like it would be helpful to check in with Drupal's front end contributors before making a huge change in the direction of Drupal's front end. There is still time to do so.

Let's keep talking!

There are definitely areas to continue to improve Drupal's front end. Despite the improvement's with D8's caching of authenticated traffic, that doesn't really affect Drupal's admin pages, which can get pretty slow on a large site. Maybe more rich JS interactions would help with that, maybe not.

It feels like this post is at least in part a reaction to WordPress's announcement of Calypso. Hopefully we can focus on making the decisions that are right for Drupal's future rather than reacting hastily to what another CMS is doing, particularly when you have talked over and over how WordPress is not Drupal's true competition.

Shane Vincent (not verified):

You're spot on here. When I first started looking in to Drupal 8's new theme layer I immediately assumed that the switch to Twig was driven by the desire to render page element templates either server-side OR client-side. I was let down when I found this not to be the case. It seems silly to consider rewriting basically the entire front-end in JavaScript when so much of it could instead be reused (ie via Twig). We're already requiring developers to adapt to a new templating engine, so why not make that front-end / back-end agnostic, and let developers choose their desired approach? There's also graceful degradation to consider. Moving to an entirely separate decoupled front-end with no corresponding server-side theme generation means that pages will render empty without JavaScript enabled. I realize that JavaScript support is at an all-time high, but are we moving forward with the intention of making it a requisite to all web browsing? A shared templating system which could be leveraged be either client or server-side would solve this problem.


Thanks for the feedback, Marc! I wanted to kick off the debate by putting forth a position, but of course it's important for us to have an open, transparent discussion about what this means for the Drupal theme layer and Drupal's front-end community. The goal of this blog post is to get that conversation started.

Short term, I think it's out of the question to move to a 100% JavaScript-based stack. I believe that a progressively decoupled approach helps us take advantage of all the improvements we made to Drupal 8. As PHP developers, we can continue relying on Twig templates and the traditional theme layer we're familiar with rather than moving over completely to a JavaScript-based front end. Similarly, progressive decoupling also allows us to take advantage of BigPipe and other important performance and scalability improvements we made in Drupal 8.

Longer term, it could make sense to move from Twig to a JavaScript-based templating system where templates can be shared across client and server. I believe this could (1) give us a unified templating experience for the initial page render and subsequent interactions, (2) provide consistency and code reuse between coupled, fully decoupled, and progressive decoupled implementations, (3) attract even more front-end developers to Drupal as they no longer will have to learn multiple languages/systems (e.g. PHP/Twig and JavaScript), and (4) maintain good performance with no need for duplicate templating code.

I'm not recommending we start working on that today; it requires a lot more thought, discussion, experimentation and planning. I certainly don't have all the answers, and might well be wrong in my thinking, but I'm keen to explore this more to help make sure Drupal is well positioned for the future.

As for WordPress' announcement of Calypso -- I actually started writing this blog post before Calypso was announced. I don't believe my position was influenced by Calypso.

Max R (not verified):

"Short term, I think it's out of the question to move to a 100% JavaScript-based stack."

Why not? JavaScript is the only executable on the web and will remain that way for the foreseeable future. Drupal might as well may provide end-to-end ecosystem instead of limiting itself more and more the the server side and ceding ground to JS-based frameworks. It's not just templating, it's form validation logic and millions of other things that are better implemented once in one language.

It seems like Meteor is currently trying to fill the void in the JS world, but there is no reason Drupal can't be built alongside or event on top of it. And in this case we probably even need a name change in order to make it clear. DrupalJS may no longer be a joke. :)

Erik Ebsen (not verified):

What if the answer isn't a full JS framework but just a Twig-compatible JS template library?

Look at the examples for Mozilla's Nunjucks templates ( Other than the file extension, they're syntactically identical to Twig (and enjoy broader community support than does twig.js). That seems promising to me.

In this scenario, one of the more popular Twig/Jinja2-like template languages (Swig is another example) could "take over" rendering once the JS on the client is ready. That sounds more like the "progressive" decoupling Dries describes and in a way that isn't either a huge duplication of functionality/code (as with a full MV* JS framework) or a huge shift in development mindset (as with React/Vue.

If the point of progressively decoupling is to allow certain highly interactive portions (components) of a page to update without a full page reload, I just don't see how a "full" MV* JavaScript framework like Angular or Ember is going to allow it. Those kind of framework demand control of the entire rendering process (as I understand them).

And yet, the whole mindset of the "just the View" JavaScript libraries like React and Vue require a very different, more functional/reactive, approach to development than what Drupal and Twig offer right now. Even if you could hand off the rendering to one of them, you're either writing (and maintaining) templates in both Twig and JSX/Vue components or you're writing your interactive bits in JSX/Vue components inside your Twig components. As a front end developer myself, that sounds rather terrifying.

I could be completely wrong. Maybe something like Nunjucks can't or doesn't work like I think it does. Maybe a full framework is really needed. (I'm not opposed to blessing one option; Wim's arguments here and elsewhere convinced me.) But I would hate to overlook something simple and I've often wondered whether something like this wouldn't work. It does seem (to my mind) closer to the middle-ground approach that Dries wants to explore.

I'm very excited to find out where the discussion leads. :)

Lauri Eskola (not verified):

I agree that the Theme system in general needs rethinking. Stable and Classy are one of the good examples how Drupal's Theme system has reached its limits. These themes fix some of the issues we have in the Drupal core, but they don't support contributed module projects at all. Module projects have to figure out their own ways to get over those problems. If they would apply the same fix as we do, each of the modules should be providing their own theme.

I believe most of the value of decoupling out of the box would be in the content editor interfaces. However in Drupal there is no 100% separation between end user facing website and content editor mode. There is also content editing components inside the end user facing website (contextual links, quickedit, live preview and block demo mode). I believe these features would benefit the most out of using some of the component-based frameworks. I'm concerned if it would be difficult for the modules to extend this.

What would decoupled Drupal mean for the site builders? What should happen when you install a new module for your site, if all the frontend logic is on the application level. Wouldn't it be hard to make this work with the modules?

One of the ideas we've had to solve similar kind of problems is to create universal component library. Module depends on components so that multiple modules can use the same component. In the application level, themes could decide how the component should be displayed, or if they prefer to use different component (I think this change should be done, even if we decide not to decouple).

JavaScript frameworks moving fast is not a problem if we can make Drupal work so that it could run with pretty much any framework, and in the end that could be decided in the application level.

Preston So (not verified):

I agree that most of the value from decoupling Drupal itself is in providing a richer content editing experience. Part of the rationale for progressive decoupling is to maintain consistency across how people would end up building both end user experiences and content editor experiences. After all, this unified theme layer is one of the most recognizable aspects of Drupal’s front end.

In my opinion, we could improve the site builder experience through progressive decoupling. Since both front-end code (in asset libraries, which could be shared across modules) and back-end code would live in the same Drupal module, in the future, simple installation of a module could allow a site builder to place an interactive block on a page just as easily as a static block can be placed on a page today. Of course, it'd take some hefty investigating and conceptualizing to attain this vision.

A universal component library (I assume by this you mean reusable UI components) sounds like a great idea as the logical next evolution of front-end asset libraries and looks beyond both full-featured frameworks and the view-focused UI component libraries that are in vogue right now.

Ron Northcutt (not verified):

+1 for Progressive Decoupling.

Fully decoupled Drupal is not only difficult to keep up to date across the project, but I also think it really devalues alot of the features and underlying functionality in the system. The fact that we *can* use Drupal in a decoupled way is great... but that shouldn't be the default. However, we can ensure that Drupal core is primed for a decoupled application with the ability to easily turn on the services (views) that are necessary. This could also make it easier to offer a decoupled admin app (or several) that is easy to turn on.

I think we can have a really powerful system with a BigPipe style, progressively decoupled Drupal out of the box. Users don't have to worry about how to set it up, or how to manage the caching and clearing... it "just works" (tm). A vast majority of the users of Drupal will benefit from this, and either don't need a fully decoupled app or don't have the time, skills, or resources to build and maintain one. In my mind - this is the greatest opportunity for us.

I also think we have a great framework to "extend" a progressively decoupled setup by using a JS framework inside of Twig templates to decouple bits and pieces of the system as needed... without ever having to decouple the entire front end.

Overall, I think we need to make it easy to decouple when and where it makes sense without forcing people to go "all of nothing." Some default progressive decoupling in core would not only cover the most common use cases, but also provide the example.

Frank Anderson (not verified):

My initial choice would be React, for this reason. It is designed to work as an isomorphic front end framework already; that means that it is already giving us the ability to do a partially decoupled front end in node based apps. So long as we are able to give it what it needs client side then it shouldn't care what rendered it. This will allow us to make good use of Drupal 8's performance improvements in the initial render of the page.

David Hwang (not verified):

The jQuery bullseye aside, Drupal hasn't had the best record at picking technological winners (witness the resounding thud that was RDFa, a once-proudly touted major-release feature, among others).

Deciding to -- for example -- ship a bunch of React components with Drupal 8.2 Mountain Leopard would likely generate lots of buzz in the short term, but just as likely saddle Drupal with a weighty burden when the landscape suddenly shifts (and it most definitely will) and all the cool kids go into the other room, metaphorically speaking.


It's not about shipping with what the cool kids use; it is about evolving Drupal's user experience. If not standardizing on an existing framework, what do you suggest we do? Not evolve the user experience? Write our own JavaScript library? I'd love to hear what you think we should do. As is, your comment doesn't add a lot of value to the conversation (and overlooks *many* technical decisions we got right).

David Hwang (not verified):

We can absolutely evolve Drupal's UX, and that massively so, but I'm very wary of predicting potential winners in the current JS arms race, especially since Drupal's front end bets have historically been very hard to walk away from when they reveal themselves to be not the best decisions in the long term (cf. Render Arrays, etc.)

My point, poorly articulated as it was, is that I believe our focus should be on making it as easy as possible for decoupled apps to be built, in all fronts -- developer experience, radically extensible web services, thoroughly revamped UX, yes to all that -- but avoid being prescriptive lest we back ourselves into a corner we can't pivot away from down the line when the overall landscape changes -- which it will, and that sooner than we expect. Better a CMS that works pretty well with many, many front end frameworks, than one that works _amazing_ with one, but mostly just that one.

Jingsheng Wang (not verified):

In your vision, the progressively decoupled Drupal can bring a lot of advantages as you explained. I'd like to extend your definition of "page component" a little bit further in the context of Web Components.

In your article: The future of decoupled Drupal (, You implicitly meant "page component" that built by Drupal will be used/consumed by Drupal. For example, BigPipe ships many page component in priority. On the other hand, Web Components ( define three more primitives, the new tools allow the whole web to be componentized. It means that the "page component" built by Drupal, if following the format of Web Components, can be used or consumed by anybody including Drupal. In the example of BigPipe, the page components can be assembled by web browser instead of Drupal (lower the work on Drupal side), more detail:

In a more general use case, some one can run a Ruby on Rails site or WordPress site, and they can consume a Drupal "page component" by declaring one line of code (except HTML imports)

<Drupal-Views id="news" display_id="frontpage" limit="10"></Drupal-Views>


<Drupal-Webform id="coupon-code" submission_limit="1"></Drupal-Webform>

Therefore, the front frameworks you mentioned in this blog will work well for the near future. But, if look further, the challenge is whether or how can we decouple Drupal in a way that the "page components" can be re-used by the rest of the web instead of a particular frontend framework.

As a note, the Polymer framework unlike its sibling AngularJS is built on Web Components.


Jingsheng, the ability to share content/functionality across sites and platforms is very compelling and certainly aligned with my vision of the assembled web. I has lots of potential and warrants more exploration. Are you working on this, or planning to work on this?

Jingsheng Wang (not verified):

I am in the process of upgrading my own simple site to Drupal 8. I am using Polymer for the front end. I am trying to develop a solution to let Drupal 8 generate Web Components for comments and comment forms.

I like this progressively decoupled approach more, comparing to my alternatives:

1. Using Disqus service (I don't get to own the data)
2. RESTful API (A lot of effort/work just to match what Drupal has many years ago)

Preston So (not verified):

While I agree that Web Components could be ideal for progressively decoupled Drupal, the main issue is browser support. Web Components have been touted around for several years now, but support is still poor across the board. In my view, it seems to me this is because of much greater investment in improving JavaScript performance rather than supporting emerging W3C standards (I'm looking at you, Google).

Gehongru (not verified):

In China, WeChat development is very popular, this is our choice:
1, use Ionic + AngularJS to build the front layer,
2, use Drupal + Solr as the backend layer
it is great, we could build Android app, IOS app, WeChat app using the same code through Phonegap.

My recommendation:
First choice: AngularJS
Second choice: ReactJS

Kalin (not verified):

In my opinion, decoupling Drupal is not a question of being futuristic anymore. It's a question of surviving the quick pace of change in the other worlds like JavaScript. Take Meteor.js as an example - many of the concepts are similar to Drupal. They have similar issues of split opinions about commercial decisions and open source contributions, etc. However, they really embrace other frameworks and libraries, and this is the only way to keep in pace re-using solutions from other communities (say all the products from the big players here). Drupal 8 is already on a good path with embracing Symfony and REST API architecture in core, so full decoupling doesn't seem like a revolution to me at least.

John_B (not verified):

Taking a step back, the Web will always be good at what it was designed for: a structured collection of documents, containing structured data, with very low barriers to publishing. Organisations who have keep their feet on this ground (Wikipedia, Drupal) have flourished and will flourish in the long haul. Facebook, who started that way and got more appified, and Twitter who did not start that way (though they benefit from simplicity) have obviously attracted a gigantic user base, and hope for huge profits; and given their market penetration they will probably survive though their slick UX can be a problem (I am among those who gave up on FB). The magic of Drupal has been its strength in supporting this model which is at the heart of the Web. Drupal and will still florurish provided UX improvements are not made at the expense of the Web's enduring USP of serving documents with a transparent and predictable structure. What does that mean for a decoupled frontend? That it should remain an optional extra, available to those who like to flirt with fashion.

Michael Haggerty (not verified):

I am glad to see decoupled Drupal getting more attention, and I agree it's an important question. But we may benefit from thinking about the question more broadly, and from the perspective of people who work with other technologies besides Drupal.

Drupal should move in this direction slowly, taking small steps while getting acquainted with the norms of other communities. A big benefit for Drupal, which may be secondary but important, would be to grow the pool of developers using it and see the benefit of contributions from them.

Most of the devs I see using with Angular, Backbone, React or Express have a very different set of norms than those of someone working with PHP applications. They tend to start with application scaffolding set up by something like Yeoman, which creates the environment they will work in (including the development server.) They use Grunt / Gulp to automate tasks and do the actual build of the site. They are working in the MEAN stack, and get a lot of their data through direct calls to Mongo. They are using Jasmine, Karma and Phantom JS for testing.

The point of all this is the process of setting up a website, and all it's dependencies, is a different way of thinking about building web applications. The value is in rapid setup, building fast with automated tools, scaling huge and having effective testing tools that just work. So much of the setup is automated, developers really don't spend too much time making decisions about modules / libraries / anything that's not already baked into the stack. Downloading a CMS, searching a big set of modules to add functionality, and the like would seem foreign and alien compared to this setup.

What I think this all means is:

  • It's not about whether or not to decouple, it's about what goes into Core to support decoupled Drupal. BigPipe and REST servers are important, even if there are few sites that would ever use both.
  • The distribution matters more than extensibility. Having the ability to easily distribute specific builds through channels other than d.o. is a big deal, but being able to find those on d.o. is still important.
  • Decoupling is about way more than what happens with the theme. There are other capabilities (permissions integration, form generation, preview, etc) that go along with decisions like this, and they are probably not solved strictly with traditional approaches to problems.
  • How we think about the Drupal way of doing things should reflect how modern web applications are built. We want to compliment what people in this area are doing, not ask them to learn a new (old) way of doing things.

When I think about decoupling, I think about more than the UI. A lot of the value in using Drupal lies in tools that do something besides node CRUD operations.

Something I am really hot for right now is a javascript implementation of Drupal's permissions system, that uses plain javascript objects to define a set of things users can and cannot do. It would be independent of any front-end library and simply something that could be included in code. There's also user handling, menus with access checks, form generation, file management, drag and drop tools, access to search engine results, being able to index the static pages that often appear in Angular applications, and other things to consider. Being able to do these things in a way that does not tie someone's website to a specific front-end UI or require code to be wrapped in some container, would be important.

From this perspective, I don't think the choice of which front-end UI to support for the backend makes much of a difference. The Angular projects I have been involved with at Trellon all run as static web apps that call data through web-services. The fact that backbone is installed in Drupal is not really important since most users never actually see a page generated by Drupal.

Likewise, the options laid out for decoupling don't make much sense. If the goal is to provide uninterrupted workflows and no page refreshes, there's a case to be made, but it's not as important if it only affects administrators. It's more of a nice-to-have, and it might not be as important as support for MongoDB, Yeoman generators, native javascript implementation of core features, Grunt / Gulp integration, and the like.

If I had to vote, I would be in favor of support for progressive and fully decoupled Drupal as part of Core. It's not a binary decision and doesn't have to be an all-or-nothing approach, even when you consider the labor involved. Drupal benefits from having multiple approaches to problems and this could be the best example of the utility of the platform.

Kevin Oleary (not verified):

When you talk about the build process for projects being very different for JavaScript developers, that's true but relevant more to the question of decoupled customer-facing sites rather than standardizing on a client-side framework on the administration side, as Dries is suggesting.

In that world the Drupal site builder is the *customer* of the framework more than the developer of it, and little if any of the discussion so far has focussed on the needs of that user. What I'd like to hear from the JavaScript crowd is which framework would serve that user best, (balanced, of course against the needs of the module builder).

What are the needs of the site builder?

You put it well when you said it's not about performing simple crud operations. Ultimately they should be able to create and edit content in place with true theme preview. They should be able to edit a view, for example, right from the rendered view. They should have the ability to add and entity from within another entity—and not just a taxonomy term in a form—a full Article from within a block on a landing page. They should be able to collaboratively edit like google docs and edit offline like Evernote. They should have fully draggable and droppable blocks and hot-swappable layouts. They should be able to drop a comment on a revision of a media file at specific coordinates like Invision. They should be able to preview the site masquerading as another user under many different contexts like Optimizely.

What's the best framework to do all that?

Campbell Vertesi (not verified):

Dammit I wrote a massive comment about this, but in the end it made more sense as a blog post:… . In short, I think this isn't an abstract problem for the future, it's one we're already facing NOW in 8.x. The PHPTemplate model is getting straw-man treatment; the situation isn't analogous at all. And we do have a better model of how to deal with development-pace-delta problems.


Campbell, thank you for your blog post. Lots of food for thought.

In addition to PHPTemplate and jQuery, Drupal's WYSIWYG module comes to mind; it might be a good model for what you are advocating. Drupal's WYSIWYG support was swappable and abstracted CKEditor, EpicEditor, FCKeditor, jWysiwyg, markItUp, NicEdit, openWYSIWYG, TinyMCE, Whizzywig, WYMeditor, and YUI editor. Now we picked one WYSIWYG editor for inclusion in Drupal 8 core, we have much better/deeper WYSIWYG integration and a better WYSIWYG experience as a result of it.

If we can make it easy to swap client-side frameworks to handle the rapid-changing landscape of front end frameworks, I'm all for it. The question is: can we make client-side frameworks swappable with reasonable compromise? How much can be abstracted? How much do we loose in the process? I'm skeptical about it but I'd love to see us discuss this more -- and possibly experiment with it too.

webchick (not verified):

Right, I'm along the same lines of thinking. The jQuery analogy is really apt here. It pays to read over how that decision was made.

When we chose to add a general front-end library to core, we did not put in a client-side library abstraction where one could seamlessly swap in and out Dojo, jQuery, Prototype, Moo.fx, etc. We picked exactly one, and then standardized on it across all of Drupal. This directly resulted in easier education, more code sharing, less duplication, and all the good things. (Versus having to pick a rating/review module that works great with Angular, but wanting a shopping cart library that works well with React, and BOOM.)

What makes this tricky is it doesn't feel like in 2015 there's "the one" JS MVC framework yet. Then again, in 2006 there wasn't "the one" either. There were lots of choices, and we ultimately made ours based on a variety of factors such as modular architecture, light footprint, responsiveness/heplfulness of the maintainer, strength of community. And I think at least in part, that decision helped propel that project. That's been my observation with our choice in Symfony as well.

Wim Leers (not verified):

The WYSIWYG module in Drupal 6/7 did something extremely ambitious: it wanted to let you write a WYSIWYG plugin once, and let it work in every WYSIWYG editor.

After all, every WYSIWYG editor is manipulating HTML upon clicking a button in a toolbar, right? (Or that was at least the assumption.)

While that was a very laudable goal because it'd save a lot of similar/duplicate code, it never really materialized. Every WYSIWYG editor has its own particular features/subtleties. The tight integration necessary for a great UX implied writing a WYSIWYG-specific plugin after all…

If we now put things into perspective: writing a WYSIWYG plugin that is agnostic of the WYSIWYG editor it will need to work in/with is clearly multiple orders of magnitude simpler than writing models/views/controllers/templates/application logic/etc that are framework/library-agnostic. So I don't see how this will ever be achievable.

See also my comment on Campbell's blog:….


Wim, that is exactly the point I was trying to make. Abstracting a client-side framework so they are pluggable doesn't seem like a viable idea.

Manuel Alejandro (not verified):

As this much decoupling happens, I wonder, what makes Drupal, Drupal? If we are moving to a time where Drupal will provide REST endpoints for things not only related to content but to page components as well, it becomes increasingly easy to have many implementations of front ends, using a myriad of frameworks. I think that is a good thing, people should be able to chose.

What makes Drupal Drupal, in my opinion, is the content management approach, the extensibility architecture, the many modules available, and the community around it. Right now, PHP is part of the Drupal definition, but will it always be if we move to a fully decoupled world? So it's interesting to ask ourselves this question.

I see a day where I will be able to pick the jQuery implementation of the front end, or the Angular.js one. I see a day where certain parts of the server (as they are REST services) could be decoupled and replaced by other components (think of testing environments, optimized components written in C or other languages). Fully decoupling Drupal would mean overlapping of communities, and some technologies being used to solve things that weren't possible before.

I know this transition should be concrete, and within certain limits, not to fall in a theoretical world of pretty ideas. But, it's good to think about the new possibilities it would open.

I see people debating over "which one to pick" but I think that the beauty of decoupling lies in having options and being able to replace one by another.

So the bottom line is, we should consider first, standardizing interfaces (behavioral), schemas and writing the laws that will govern the decoupling, writing the standards, etc (what makes Drupal, Drupal) and then progressively adding layers of REST endpoints to perform all sorts of tasks.


Scott Shipman (not verified):

I have built Drupal sites for government, entertainment, travel and education industries. My experience has been that the level of user interactivity that required a true full decoupling is usually limited to only a portion of a site's overall purpose. In most cases, presentation of content had a shelf life that suggested a cacheable MVC over a multi-dimensional interactive model. You mentioned a few good examples, like a comments section, or a portion that is more HTTP service based, like chat or real-time collaboration widgets. But, in all these cases, I think we are building widgets, not full site scoped presentations that demand this decoupling.

And if you really need this level of decoupling, maybe Drupal isn't the platform you should use. Its ok.


Scott, per the blog post, I agree that not every use case benefits from fully decoupling -- this is why I recommend we default to progressive decoupling, certainly for the visitor experience. I do think Drupal should (continue to) support fully decoupled architectures though.

Pierre Buyle (not verified):

IMHO, Drupal core needs to standardize on a good DI container for front-end code and (polyfills for) standard APIs. So front-end frameworks and libraries can easily re-use lightweight decoupled services and standard APIs. AFAIK there is no reason for a Entity services on the front-end to rely on any framework. It can query the REST (back-end) services using the Fetch API. And it can expose a clean API to Entity application code using any framework or view library.

This way, any view library or framework could be used on the front-end and would be able to leverage these services (this may require some adapters, depending on how stubborn the frameworks are).

Once this is done, using a components based approach, Drupal core could then standardize on a view library for its own components. Having a clean separation between the services (and the DI) and the view library would allow Drupal core to adopt and switch the later more easily. It would even allow the administration backend to move at a different speed than the visitor front-end. Or will also minimize overhead should two view libraries be used during a transition period. Better having React and Polymer loaded on the page, than loading Ember And Angular.

With this scenario, using component based (view) library would make more sense. During transition period, Drupal could mix two of them without to much overhead. And when/if Web Components reach its goal, it could switch to it without a full rewrite of its front-end.

This is in phase with Campbell Vertesi's conclusion (on his blog), making it easy for contrib to handle the ever-changing, rapid landscape of front-end frameworks (and libraries).

PS: Module loading is already standardized in ES2015, so Drupal core could provide the backend features needed for efficient JS modules loading (ie. resolving a JS module name to files provided by Drupal module, creating bundle on the fly, etc.) on the front-end independently of any frontend framework (or the toolbox specific to one), but based on the ES2016 specs.

Marc Drummond (not verified):

I took another look at to better understand what you mean by progressive decoupling.

If the question is whether we should settle on one particular JS framework to use, and if so, which one—as we did with jQuery and CKEditor and Symfony and other third-party code in Drupal—I think it could be helpful to know more about which frameworks might be particularly well-suited to the task of progressive decoupling.

You've said that what you don't want to change Drupal to have its front-end output with client-side JS rendering. My understanding is that's typically what Angular and Ember do.

You've also said you don't want Drupal's front-end output to come from server-side JS rendering, which is React's main strength.

The framework that has typically filled the role of enhanced client-side interaction after non-JS-based server rendering is... jQuery.

I'll be honest that I'm not entirely clear where Backbone fits into this. I know we're using it in Drupal 8 for things like the toolbar, and I think we're initially generating that markup through Twig, but I'm not entirely clear on that.

jQuery and Backbone are already built into Drupal 8, though. So if we don't want server-side or client-side initial renderings with JS, I'm just not clear on what commonly used JS framework out there fits the bill of what you'd like to see with progressive decoupling.

It might be helpful for you to have a follow-up post to go into more detail with examples of the sort of interactions you'd like to see that aren't possible now. You could also help clarify what you mean by progressive decoupling, because I don't think that's entirely clear right now, at least to me.

It's great to think through these things and look to the future. Thank you for focusing on the big picture of where Drupal fits into the larger web landscape, Dries.

John Albin Wilkins (not verified):

I think that progressive decoupling as I've understood it from your blog post is going to be extremely difficult. The issue is with data binding.

JavaScript frameworks think in terms of components. A component is a JavaScript object with bound data that can be rendered into HTML. Angular and Ember render the JS objects using light-weight template systems and React renders with pure JS calls or with HTML-like JSX that transforms into those JS calls.

And the frameworks are also using JSX or templating to define how the data is bound to the HTML. You can't create a component in those frameworks without also writing the HTML in their native systems. And those JS frameworks (like React) that do have isomorphic server-side rendering are still using their own markup solutions to render the HTML and create the required client-side JS to dynamically update that HTML.

So, in order for Drupal to render and hand off HTML to a JS framework, you'd have a couple equally horrible options to pick from:

  • Have Drupal templates render exactly the right HTML and JS that can be consumed by the JS Framework. In reality this would mean that the developer would need to do all the work in the JS framework first and then figure out how to convert the rendered HTML and the corresponding JS equivalent of the component into Drupal's system of Twig templates and attached JS library assets. That's double the work of just doing the whole thing in Drupal or the whole thing in the JS framework.
  • Have Drupal templates render into the native templates. Instead of comment.html.twig, you'd have comment.jsx.twig or comment.hbs.twig. And you'd have to convert twig data from nested theme hooks and render arrays into the JSON context that the frameworks are expecting. Come to think of it, this option may not allow nested components since a parent JS component needs to have JS object references to its child components. And nested components are essential in the interactive apps I've seen.

Anyone have a better idea on how to get Drupal to do the original rendering?

So, that leaves us with a fully decoupled solution. But do we need to decouple the _entire page_?

In my experience on real sites, doing a fully decoupled _page_ for an article page is waste of effort. If the end goal is static HTML, Drupal can already do that with no extra development. You don't need to replicate how an article renders in the JS framework because the article doesn't need dynamic data binding. You get the data (article text and images), you render it, and you have no reason to ever touch it again.

Front-end JS frameworks shine when you have interactive data, so why not render the static bits of the page with Drupal and the dynamic bits in the JS framework? And, I mean, do them both on the server. Surely, JSX isomorphic server-side rendering can be cached and then consumed like a Drupal block! There'd still be some challenges, but much fewer I'd think.

So what JS framework should we standardize on? Let's look at our requirements first:

  1. Must have server-side rendering ability. Loading up a JS framework in the browser before any HTML is rendered is a horrible front-end performance penalty and unacceptable.
  2. Excellent front-end performance.
  3. Good open-source community to collaborate with and learn from.

IMO, Angular.js version 1 does not meet those requirements. Web component polyfills like Polymer wouldn't be a good fit either given their current performance. I think Ember.js and React.js are the 2 best options and I'm really liking React's Virtual DOM. Here is one of the best resources I've found that compares the two:…

Wim Leers (not verified):

Front-end JS frameworks shine when you have interactive data, so why not render the static bits of the page with Drupal and the dynamic bits in the JS framework?

I think that's exactly what Dries means when he says "progressive decoupling". At least that's exactly how I understand it :)

moshe weitzman (not verified):

John Albin is suggesting that we render javascript on the server which implies a major new infrastructure addition. Drupal sites would need to run a Node.js server in addition to a LAMP stack. I'm not so sure that this is what we mean by progressive decoupling.

Preston So (not verified):

While we could limit the use of Node.js to solely execution of the framework and the render process, I agree that infrastructurally this is a very fraught decision that opens the door to increasing amounts of server-side JavaScript. I'm not sure we want to go down this slippery slope, because many Drupal sites are perfectly happy remaining on a LAMP stack. There are alternatives such as executing JavaScript on the server through PHP (v8js), as react-php-v8js does, or interpolating Node.js into an existing Linux server and running it in the background with the Forever package, but these both comprise uncharted wilderness from a scalability perspective.

Over all, we need to make a big decision about whether the render process should stay in PHP/Twig, and if so, how we handle UIs that increasingly leverage a JavaScript-based render system. Either way, in my humble opinion, separate server-side and client-side templates are out of the question.

Preston So (not verified):

I agree with Wim in that your and Dries' notions of progressive decoupling aren't actually that distant from each other. We all agree that it isn't a good idea to hand over all rendering of the entire page (especially for content-rich sites) to a JavaScript framework. We only want some of the page to be dynamic, to facilitate things like a single-page shopping cart or a single-page commenting system limited to the sidebar of a content-rich page.

In my current understanding, there are only two options if we only want to decouple parts of the page ("progressive decoupling"): introduce some server-side JavaScript (render some JS templates and render some Twig into a unified page on the server) or let Drupal render the initial state first (Twig and JS templates not in sync). Both would be extremely challenging and consequential, but for different reasons.

As you summarized eloquently, having Drupal render the initial state and then hand over (re)rendering responsibilities to the framework is not something any of the currently fashionable JavaScript libraries or frameworks are designed for. But there needs to be some kind of server-side rendering that offsets and provides static fallbacks for the framework's initialization, and Drupal—irrespective of how—already does this eminently well. To resolve the problem of two coexisting template languages, I'd be more inclined to make Twig's output more closely mirror framework templates in order to prevent two types of templates, rather than abstracting the issue away with a Twig-to-Handlebars converter or the like.

I do like the idea of rendering both static (Drupal) and dynamic (JS) portions of the page on the server. But this either requires execution of JavaScript in PHP using v8js (the approach that takes) or introduces Node.js (even if it is only a thin layer encompassing just the framework and the render) into the mix. Some interesting projects like twig.js explicitly require Node.js on the server. Nonetheless, my fear is that introducing server-side JavaScript will be only the first step in a slippery slope that ends with full JavaScript isomorphism, which is anathema to those who want to remain on a LAMP stack. The infrastructural and architectural implications of such a move for Drupal would be huge.

I'd love to see us experiment with both approaches. Even minuscule proofs of concept will point us in the right direction!


This has been a lively discussion! Thanks for all your input, and please, keep sharing your thoughts. I wanted to summarize some of the feedback to help the discussion along.

It seems we all agree that there is huge demand for improvements to the experience of using Drupal and that the current way of doing things is not going to help us get there. We seem to be divided into two groups.

No one objected against supporting a "fully decoupled Drupal". Many seem to really want fully decoupling. In this scenario, you would enter Drupal to perform basic content editing and workflow tasks and then build your front end entirely in a client-side framework. Per my blog post, I support the use case of fully decoupled Drupal and believe we need to improve Drupal's support for it.

Many appear to agree with me that we need more than full decoupling. We want Drupal to ship with default user interfaces that are modular and easily extendable by non-developers. Not everyone has the resources to explore fully decoupled implementations or has a need for more application-like experiences. We'll need to face difficult challenges like sharing templates between client and server, but in short, it seems many agree with the broad philosophy of progressive decoupling: the entirety of the page should not be decoupled, especially pages consisting of primarily content.

In general it seems that people agree that to support progressive decoupling we'd benefit from standardizing on a single framework. However, many are worried, correctly so, that the landscape for client-side frameworks is still too unstable for Drupal to make an endorsement, and they argue that Drupal should remain entirely framework-agnostic. Are we early to standardize a framework? Yes! Is it hard to pick a framework? Yes. Can we afford not to standardize on a framework for progressive decoupling? Probably not, unless there is an easy solution that gives us 1) future-proofing that is on par with the evolution of UX and 2) a developer experience that will bring more front-end people to Drupal. Long story short; we shouldn't pick a framework yet, but we also can't afford not to pick a framework ...

Sushil Kumar (not verified):

Good summary that outlines the needed changes to support a divergent client experience for front-end development and admin functionality.

I agree that a progressive decoupling approach would work the best and will help phase-in the needed changes, while driving to an end vision of complete de-coupling.

As for a client-side framework, this is a tougher nut to crack. While there are the Angular, Node and other JavaScript frameworks, picking a particular one and trying to ride it for the long run is fraught with danger. These frameworks are constantly evolving and you also have the continually evolving cross-browser support issues to deal with. Perhaps it requires a more conservative approach initially and identify a couple of leading ones as possibilities.

Matthias Lünemann (not verified):

I am just an occasional observer of JavaScript frontend frameworks. None the less I'd like to share some links.

James Shore reviewed Angular, React and Ember on his "Let’s Code: Test-Driven JavaScript" screencast site. These Reviews are somewhat unconventional. E.g. he wants to use his "best fit" architecture and not be limited by the opinionated framework architecture. Other criteria are lock-in, accidental-compexity, testability, server-side rendering. React rated best, Ember was mixed, Angular was worst.

His blog posts on Angular and React:

The Ember review is only available as paid video:

A framework I'd like to add is Ampersand It's a decoupled version of Backbone. My impression is, their mix and match approach could be a good starting point for progressive-decoupling. It should be easy to use any templating-engine like twig.js. Downsides could be it's build-dependency to NodeJS and I haven't found anything about server-side rendering ...

@jbingold (not verified):

@JohnONolan's post about the importance of choosing for #ghost as an"opiniated and at times inflexible" framework seems very relevant:

"One of the most important reasons that we ultimately chose Ember was precisely because it is so opinionated and, at times, inflexible. Because in a fully open source team, that’s a huge advantage. There is a definitive right or wrong way to do things in our client-side app, and it is exactly the same as every other Ember app. We never need to have any debates or discussions about implementation. The framework puts us on the same page.

As anyone who has ever painted a bikeshed before will attest: The cognitive benefit of this simply cannot be overstated. It makes open development so much more cohesive.

It appears, at least from the outside, that Automattic selected React based on their own internal needs and biases without any specific thought to how the decision would translate into public development after releasing Calypso as open source. While this was great for 20 months of private work, I think it will present a serious - though not insurmountable - obstacle to bringing this stack into the rest of the WordPress ecosystem.

React, as a view layer which mixes arbitrary JavaScript components in with HTML and CSS, is a predictable choice for a team which is used to doing the same things with arbitrary snippets of PHP. Unfortunately, the pitfall of it being very easy for everything to turn into a giant spaghetti mess is a constant for both.

Significantly, this is a pitfall which WordPress has always dramatically failed to overcome.

It will take a great deal, here, to prevent history from repeating itself."

As we are "late comers" it may be interesting to observe what is happening right now in the WordPress ecosystem.

Deji Akala (not verified):

Glad to see this interesting discussion on decoupling Drupal. Progressive approach sounds dynamic - decouple in steps, pause and evaluate the landscape, decouple more maybe in a different direction. Even a progressive approach would have a final goal. Will that be a fully-decoupled Drupal or what?

In choosing a front end framework we shouldn't forget about the other side of the equation - the impact of Drupal on such framework(s). I'd like to imagine that the adoption of jQuery, Symfony components and CKEditor has benefitted those projects too. I'd like to think Drupal is also one of the cool kids others want to hang out with.

philsward (not verified):

Coupled vs Decoupled vs Hybrid Decoupling...

As a front end site builder, I can say that I do believe we need some sort of change with how we interact with Drupal. Which framework to use or how to use it, I'll leave that up to the professionals.

Within this topic, I feel like we are discussing the bottom end theme layer, layout layer, the presentation layer, the user experience layer and the top end theme layer.

"What can Drupal do, so organizations don't have to decouple because Drupal is so good, it doesn't have to be Decoupled?". I realize there will always be the few use cases, but I believe organizations are currently decoupling because they have to, not because they want to.

Up to Drupal 8, the release cycle was such that new features were baked in at the next release. With the new system of point releases, it "should" be very easy and seamless for core to pick a method at release, and add an additional framework after the fact. For example, D8 uses underscore. Let's say another comes along that is better. Drupal 8 can still include underscore for backwards compatibility, but also include the new one that will become the defacto in 9. Over the course of 8, all core functions can be slowly moved over to the new system, allowing contribs to either build on the new or old. When 9 hits, underscore is gone.

Point is, I've see a lot of discussions about "which framework will stand the test of time?!??". The problem is that Drupal spend so much time trying to figure out what to use, that by the time a decision is made, that framework is no longer valid. Evaluate what's available at the time, choose the best contender and move forward. The web is constantly evolving and that will never change. Instead of sitting back and waiting, be proactive and make a decision. If it's wrong, correct course and move on.

Drupal, especially with 8, is in a position that it could PUSH the web. Instead, it is being pulled by the web.

Ever wonder why a guy with ADD is usually more successful in life than a methodical and analytical person? It's because they make 100 mistakes and learn from those mistakes in the same time it takes most people to make 1 mistake. Experience helps make more efficient plans so the mistakes become fewer. It also teaches how to overcome mistakes more quickly.

I feel like Drupal is more concerned with not making any mistakes, so it never gets anything done. Just look at all of the "mistakes" Google has done over the years ... Are they pulled by the industry or pushing it?

I say: "Make a decision and go with it". The key is setting up the foundation so a course can easily be changed. Spend more time setting up the foundation so Drupal CAN change course easily, and less time figuring out if we picked the right course.

I hate to say it, but from where I sit, Drupal is behind the times. What needs to be done to make Drupal the leader, not the follower?


Evaluate what's available at the time, choose the best contender and move forward. The web is constantly evolving and that will never change. Instead of sitting back and waiting, be proactive and make a decision. If it's wrong, correct course and move on.

Hey, that is why I started this conversation and what I'm trying to get accomplished! :)

philsward (not verified):

@Dries I'm glad you ARE asking these questions. It shows as a leader that you value the opinions of those who use Drupal. :)

I'd love to get on my soapbox about how the web (and Drupal) needs a concrete layout framework more than it needs more presentation layers or theme frameworks, but I'll save that for elsewhere.

I'd say the main goals the presentation needs to accomplish are: fewer page loads through dynamic updating of content and better overall user experience. I'm sure there are a few more goals, but figuring out what needs to be accomplished specifically, might help in figuring out how to accomplish it, followed by a foundation that can withstand minimal migration to other frameworks down the road.


Théodore Biadala (nod_) just posted a great blog post reminding us that most internet users don't have powerful smartphones and that JavaScript frameworks are too slow for many, if not most, people in the world. Quote from his blog post:

"I'm not saying that if you use Angular, Ember, or React in their current state you don't care about people, I'm simply writing it."

His post convinces me even more that, per my blog post above and previous blog posts, we have to support the whole spectrum: from coupled/traditional, to progressive decoupling, to fully decoupling.

Dean Reilly (not verified):

I wonder how long this is going to be the case though? Nod_'s previous post points out the short lifetimes of these mobile devices and processing power is continuing to quickly increase. I'm not sure a large engineering effort now is warranted for what might only be a temporary problem which resolves itself in 18 months.

nod_ (not verified):

For one thing I haven't seen a JS framework getting simpler over time. As devices get more power overall it'll be easier to say "let's just put that in the framework, now devices can deal with it fast enough". And things never get better overall, they stay about the same.

As shown by the pivot of FirefoxOS to connected devices (…) optimizing for cheap opens new doors we might not have though of. And smartphones are not the only devices browsing the web. We never know what might be the next Apple Watch.

I wouldn't mind keeping what we have now if it were great architecture and code-wise, unfortunately that is not the case. Since we need to evolve might as well evolve in a direction promoting speed.

willy (not verified):

It's worth noting that similar options/packages are available for several of the frameworks. It's also worth noting that with regard to performance/load times, both Google/Angular and Facebook/React are pursuing growth in emerging markets where these concerns over slower connections arise; so they'll presumably need to address this is a similar manner to Drupal.

furious snail (not verified):

+1 Speed, code quality is what I like to see too.

philsward (not verified):

Theoretically, couldn't a layout framework handle the issue of multiple devices and viewports?

Several years ago, Google did this page speed initiative to punish sites if they weren't fast. Then, back in May, they did the mobile initiative to punish sites that weren't responsive. The problem with the responsive craze is that people were so busy making responsive frameworks that they completely forgot about the speed issue...

Looking at all of the responsive frameworks out there, they take a single set of code and resize it according to viewport. Effectively they are vomiting desktop code at a mobile device and then hiding stuff through CSS. The only performance gain is a slightly faster loading DOM. If a site is using a bunch of jquery libraries for desktop, all of those libraries are being sent to mobile even though the responsive strips all functionality away from what those libraries can do. Point is, a load of unnecessary code is being sent to mobile.

If a platform had a layout framework, it could detect the viewport and even go as far as the device itself, then build the code on the fly for the requesting viewport and only send exactly what that device needs. Use the platform to handle what is sent instead of relying on the device to hide a bunch of stuff. Extend this to the presentation layer where the site determines if a device can't handle dynamic presentation. It will gracefully fall back to static elements.

Imagine if twig was simply the template language the theme and layout code needs to be written in. A device hits a site, the site determines the viewport, then looks at the backend to see which template it needs to generate based off the pre-defined layout for the page. It then generates the template on the fly, caches it to file and sends that template. Instead of one template for a page that deals with desktop layout and expects CSS to manipulate it, you end up with multiple templates that specifically deal with a degree of screen sizes or even device capabilities. Why in 2015 we are still coding templates by hand for layout of elements with all of the capable tools at our disposal to do it for us, is beyond me. (Speaking for the web in general, not just Drupal)

This was a start:

Point is, if tools were in place for devs to deal with layout at a system level, they could leverage whether code gets sent to a mobile or not. Instead of modules each dealing with responsive on their own, they would let the system handle it. Extend this to the presentation and Drupal could figure out ahead of time whether it should send static code or send a JavaScript framework to handle presentation.

It would be a lot of code to deal with, but as the web moves forward and requirements become larger, there will always be the issue of devices that can't handle the latest and greatest. It also means that even though internet gets faster and apps become bigger, there will always be people that don't have fast internet or big data plans.

So, it sounds like now, that we should ask: "how do we figure out if a device can handle decoupled presentation and if not, send coupled presentation". I really believe it is going to need to be a hybrid for best compatibility. Is there a way to have say, React sit on top of Drupal instead of integrating into Drupal? Drupal determines if a device can handle the framework, and routes everything through the framework. If not, fall back to the core methods. In theory it would allow that framework to be swapped out with another down the road, or an organization could strip it and go with something different.

Sorry for getting on my layout soapbox but I feel like it might provide tools that can help deal with other aspects like presentation, UX, site speed, development speed and more.

Paul Fernhout (not verified):

Dries- Please add Mithril.js (by Leo Horie) to the list of front-end libraries to consider as a standard for Drupal. Mithril is a brilliant software library with great documentation. As with React used with the Flux architecture, Mithril redraws the entire GUI on any model change (but quickly, using a vdom approach, like React). Eliminating the need to have models send onchange messages and establish dependencies on models for updating specific parts of the GUI also makes applications easier to develop and debug (compared to, say, Backbone's or Dojo/Dijit's approach). Mithril has a more elegant design than React though, so Mithril is smaller in footprint, faster, and also easier to understand and use than React. According to one benchmark listed at the website, Mithril loaded more than 50X faster than React (in part from Mithril needing less core code but supporting more core functionality than React). Mithril also rendered about 8X faster than React (because Mithril does not have an extra unneeded layer of indirection for most rendered components that React does).

Mithril's default behavior is to update the GUI after any user interaction that changes a configured GUI property, which reduces the number of bugs produced when developers forget to do that if it is needed explicitly as in many GUI libraries. Mithril templates are also safe by default, i.e. you can't unintentionally create security holes unless you explicitly call on some string of HTML (which makes such cases easy to find and review, and which you rarely need to do).

Mithril runs very close to basic HTML and CSS, which makes it fairly easy to debug. Mithril's approach to building HTML using nested JavaScript function calls makes it easier to create complex and refactorable GUIs compared to using React's suggested approach of the JSX templating language and a typically large number of supporting component files (many of which typically do little but create performance overhead).

Here is an example of a one-line Mithril template in JavaScript which defines a simple web page including the potential for CSS styling by using CSS selectors in defining DOM nodes:

var template = m("html", m("body", m("div#greeting", ["Date: ", "2015-12-11", m("hr"), m("span.salutation", "Hello!")])));

A downside with Mithril compared to React and some other popular libraries is that it has a much smaller community than React. However, if Drupal made Mithril the default frontend JavaScript library for decoupling, then that community size issue might solve itself just from Drupal users taking an interest in the Mithril library.

React is certainly a popular framework though, in part due to Facebook's presence everywhere. It has a big community, which is only going to get bigger now that Automattic used React in WordPress/Calypso. However, React currently has a software patent license issue that essentially says (among other things) if your company sues Facebook over an unrelated patent issue, you lose the right to use any patents related React. React used to have a standard Apache 2 license before Facebook started changing it last year, and as React has an explicit software patent license, the implicit software patent license that covers most MIT, BSD, or other permissively-licensed software in practice no longer applies. So, please carefully review that legal situation and what it might mean to the Drupal community before choosing to use React in any projects. I posted some more information on the patent issue to the WordPress Calypso issue tracker just after Calypso was released after I read it used React -- but it was sadly too late at that point to make much of a difference; see:

I created a single-page decoupled webapp called NarraFirma with about forty virtual pages using Mithril (after refactoring from another UI toolkit) and found Mithril a joy to use compared to some other frameworks. The source code for NarraFirma is available on GitHub (GPLv2). You can try a demo at to see Mithril in action in a complex webapp with nested forms, long scrolling grids, D3 charts and clustering diagrams, statistics, dialogs, and more. That decoupled application only needed a small amount of PHP as the backend (about 1% of the total codebase).

Mithril also works well with TypeScript (which is how I used it). As an additional suggestion, please consider using TypeScript from the start in any decoupled Drupal apps to help support easier learning and refactoring of the codebase compared to JavaScript which is hard to deal with once you get a hundred or more files. The Angular and Dojo projects have both decided to use TypeScript for the new versions, which was a big vote of confidence when I considered TypeScript myself. Typescript is just a better JavaScript overall -- especially for a significant webapp project.

Feel free to contact me if you want to discuss my experiences with Mithril and/or TypeScript further.

nod_ (not verified):

Great to see so much love for the frontend :) I agree in general.

*Putting my JS maintainer hat on*

As an overall feeling what I get is that the website theme should be like today, as little JS as possible. There is a case to make for the admin to use progressing decoupling by default. But that is another topic, I'd like to answer a few of the questions that came up in the post and comments.

> Should Drupal standardize on a single framework?

jQuery showed it, if/when we're going to go with this: we need to standardize on one framework because contrib will be a nightmare and people will have to load 2 or 3 different libraries to display their page.

> What client-side framework should Drupal standardize on?
> what framework to standardize on, how to do it, and when to decide.

Talking about the 'what': I can say right now that it will not be a direct vote. Just like we did for WYSIWYG we'll have a set of criteras (we could possibly let some of critera up to a vote) and we'll do our homework to compare everything that looks like a good fit. We'll take extra care of not repeating the mistakes made during the WYSIWYG selection process. In general I'm biased for speed and vanilla JS so the critera will probably reflet that to some extend.

For the 'how', if the framework can be used in regular situations as well as in the progressive decoupled model (which it should). We should just ship it, just like jQuery.

As for the 'when', I agree that the sooner we start the better. It'll take a while to do the comparison, especially since I'd like to have implementation mockups for each framework seriously considered.

*Putting down maintainer hat*

Some general comments on the comments:

I have doubts on the viability of Twig.js as a solution, and havings templates on the client side at all as a solution. I mean if the data requested from the server is only used to render templates, then the server should return the HTML from the start. I would imagine a graphQL-like call style where you put what you want to get, add a view mode and bam, you get back HTML to inject in the page. Pretty sure the heavier Ajax request is less overhead than rendering template on the client especially on cheap devices.

Also can we drop the 'isomorphic JS' terminology and call it for what it is: Shared JS (

Relevant to the conversation:…


People in other communities are starting to talk about "progressive decoupling". Jeremy Keith has a great blog post about "progressive apps": He mentions that the recent redesign of Google+ is true case study in building a performant, responsive, progressive website:

With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page. Once the page is loaded and the user clicks on a link, we do not want to perform a full round-trip to render everything again. This is where client-side rendering becomes important — we just need to fetch the data and the templates, and render the new page on the client. This involves lots of tradeoffs; so we used a framework that makes server-side and client-side rendering easy without the downside of having to implement everything twice — on the server and on the client.

Wim Leers (not verified):

Funny that you mention Jeremy Keith. I just listened to the The Web Ahead podcast, episode 110, which features Jeremy Keith. In there, he talks —with Jen Simmons, whom I'm sure you also know :) — about the importance of progressive enhancement, and they take a look at the big picture of the web today, the past few years, and many years ago. I found it a refreshingly sober view on current and past trends. Worth listening to and learning from.


flip101 (not verified):

The issue raised is pretty interesting and not surprising. Drupal trying to serve a wide range of use cases, from static content to fully fledged apps, makes it necessary to have the provisions to be able to do this. And this goes into the direction of more and more JavaScript. Even on the server side requiring a change in infrastructure. This requirement is definitely bad right now. Yes crappy cheap shared PHP hosts are still a thing. Setting a requirement that Drupal should be able to run on low grade PHP hosts seems like a good thing to do. However that does not mean all effort should go into making it the optimal user experience when Drupal is being run on such hosts. Site admin's and developers must take the responsibility themselves to provide adequate hosting in order for the user experience to be optimal.

To me it seems very acceptable to make use of JS templates. On PHP-only hosts this would mean all rendering would have to be done in the browser thus making for a lesser user experience. If this was the critical requirement for people they would have probably chosen one of those static site generators. However if they do choose Drupal, then it must be for the extra features that Drupal provides, and that will make it more understandable that they can not have all the best features while staying on old infrastructure. So for those people there seem to be 4 choices.
1. stay with an older version of Drupal or use another CMS altogether
2. find it acceptable that rendering is done in the browser
3. install node.js (templates rendered server side does not mean the JS libraries need to be loaded on the client-side as well, this is optional).
4. use a *light* twig only theme (this is discussed later in this post)
Additionally the problem might be tackled with technologies like HTTP caching.

But wait let's consider the possibility of giving first grade support to PHP-only AND giving first grade support to JS templates. This would basically require to write every template logic double. This is just not fun and also error prone. Alternatively a compiler could be build converting from a twig template to a JS template or vice versa. However this is not 100% possible because the compiler would become too complex to provide 100% coverage on the template abstractions. Though just covering the low hanging fruit like loops and branching would already come a long way and potentially help a great deal in maintaining two sets of templates. Since the longer we wait the better hosting infrastructure will become, this compiler idea would just be there to kind of "bridge the gap". And in my opinion energy is just better spend elsewhere.

The admin area performance doesn't need to be as high as the visitor performance (I'm still talking about the case where you don't have node.js installed on the server). Admins just have more patience :) It seems okay to go all out on the admin area with a JS framework. For the visitor site however i find it questionable to standardize on one framework. It seems like a better idea to just show case a few alternatives using different kind of JS frameworks (and also a twig-only alternative). This would have developers get started on their own theme. Kind of like the TodoMVC but than more elaborate. That would be energy well spend and also fun to do make. Even better would it be if themes consisted out of modular, reusuable components! One question that i have is about the scenario is .. would it be possible for a developer who uses react to write a small admin component which could then plug into an ember.js admin area?

But this would leave the need for having one full featured theme to have a good out-of-the-box experience. For this theme i would recommend using the same JS framework as used in the admin area. This would be a great help for people new to JS frameworks so that they don't have to learn several frameworks and can just get started with the recommended theme. Ok maybe this _is_ standardizing on one framework. But to me standardizing sounds like you are f****d when you want to use any other framework. No support, no documentation, no examples. In fact i would find it more important, almost from a philosophical standpoint, that more energy is spend on helping developers make their own stuff work on top of Drupal than to explain how everything is implemented using the standardized JS framework. As Dries says "We want Drupal to ship with default user interfaces that are modular and easily extendable by non-developers.", i agree with that, the default interface should be geared towards non-developers. So yes it seems possible to have "a developer experience that will bring more front-end people to Drupal" meanwhile having a standarized framework for non-developers. Hopefully, by enabling developers (developers, developers), people can find a more organic way of finding what works for them. And in time, perhaps, a different framework may take the upperhand (for drupal). This framework would then already have been integrated with the drupal backend. Making changing the standarized framework for non-developers a smoother transition.

What i would do is make the admin area and full-featured theme in ember.js (for non-developers). Make another two *light* themes in twig and react with documentation (for developers). Meanwhile start an initiative on figuring out how parts (components / blocks) can be made modular so that different technologies can be mixed and matched.

Will Vincent (not verified):

D8 already has the plugin system, as such would it not make the most sense to leverage that paradigm and make the frontend fully pluggable? Seems to me, that would ultimately allow for choosing to use a fully coupled, fully decoupled, or somewhere in between approach.

Obviously that's kind of over simplifying things a bit, and there would be a great deal of effort involved in realizing such a thing, but it seems to me that not forcing adoption of a specific frontend framework would be preferable.

Edward Faulkner (not verified):

(By way of introduction: I am an Ember core team member, and I have helped several organization build advanced JavaScript apps on top of traditional CMS backends -- including Drupal.)

My high-level takeaway from this discussion is that the Drupal community is serious about finding shared solutions to common problems. Which is great, and matches the Ember community's philosophy. That might sound trite and obvious, but much of the wider JavaScript ecosystem is only slowly catching on to the value of comprehensive community solutions. I see a lot of organizations incurring long-term technical debt because of the misguided belief that things will be simpler if they hand-curate their entire JavaScript stack out of micro libraries and "pure JavaScript" -- a phrase you'll hear depressingly often that really just means "written entirely in-house instead of leveraging community-supported abstractions".

Drupal users can achieve an awful lot without writing a line of code, and a big piece of that is the wonderful module ecosystem. That kind of success is only possible through a lot of community building, shared conventions, and thoughtful API design. The Drupal community should definitely evaluate JavaScript communities through that same lens. To get the benefits of standardization, consider what the Drupal-standard solutions would be for JavaScript build & deploy tools, dependency management, data fetching, state management, and template rendering. A lot of popular libraries only solve a few of those pieces and have no community consensus around the others, which makes plug-and-play module ecosystems much harder to achieve. My pitch as an Embereño is that we work together to find or build the best possible standard solution in each of those areas, and provide it as the default choice -- without foreclosing the possibility of customizing any area when its truly important to your app.

Regarding progressive and full decoupling: there are two important competing forces to balance. The first is that I'm a big believer in steady evolutionary improvement over radical rewrites, which is an argument in favor of progressive decoupling. Drupal's community and technology are both built on PHP-driven rendering, so it's very clear that PHP-driven rendering needs to be first-class.

However, the second competing force is that maintaining two separate rendering systems adds friction and complexity. This is why JavaScript is inexorably swallowing so many applications -- it's much easier to move your JavaScript to the server than your PHP to the client. The optimal place to render any given piece of content may change even within a single user session. So over the long-run, I am betting strongly on architectures with predominantly JavaScript-driven rendering.

Overall I agree with Dries' assessment that progressive decoupling is the best path forward for Drupal. There are elegant hybrid approaches, and I have shipped examples of them for organizations who wanted client-side interactivity & persistence without sacrificing their existing investment in traditional CMSs. In the Drupal context, I think we could take advantage of the existing block abstraction to build a nice bridge between the JavaScript and PHP worlds so that existing PHP-driven blocks can happily coexist with JavaScript-driven blocks.

Tactically, I think the best way to discover what's going to work for the Drupal community is to build one or more prototypes of Drupal's own admin interface as decoupled apps. The admin interface is very clearly an application (as opposed to a content page), and its complexity makes it a great test case.

Finally, one piece of a related content that may be interesting: John O'Nolan's reaction to the Calypso announcement goes into some detail on how the Ghost team went through a similar process of examining demo versions of their admin interface in multiple JavaScript frameworks before settling on Ember:

Jon Koops (not verified):

Disclaimer: I have never used Drupal.

The front-end community is very divided, just like the back-end community is divided by choosing between WordPress, Drupal, Rails, Laravel etc. We all use different build tools, packages and frameworks. If Drupal were to choose a single 'blessed' framework, it would surely alienate a lot of folks invested in different solutions.

Sharing templates between a client-side framework and Drupal is unrealistic. Many (if not all) client-side frameworks have their own templating system that cannot be translated one-to-one. Things like helper functions that format a currency, action handling definitions like click, hover, onchange, etc. are all different in each framework.

In my opinion as a frontend developer I think the best way to accommodate us is to expose parts of Drupal core via some kind of API. In this manner libraries could be made for client-side frameworks such as Ember, Angular, etc. This would also allow frameworks that support rendering on the server to do so isolated from Drupal.

cfischer83 (not verified):

I've been using Drupal for 5 years now, and the theming is already complicated. Why complicate it more? Either go all in and decouple it or make existing theming simpler.

furious snail (not verified):

Theming in Drupal 8 is really nice. I don't think it can be any simpler.

Henri Putseys (not verified):

I think Drupal should definitively walk the modern web way and improve the user experience via extending the package with decoupling the user interface. Given the variety of websites (most have no urgent need for a more complex decoupling approach) and given the current state of play (still rapidly evolving) in the client side frameworks, a progressive decoupling strategy seems most appropriate. Both administrative and user interface should be in scope on the long term, but via a progressive path. I guess, I am agreeing with the progressive decoupling reasoning explained by Dries.

Adam (not verified):

I like what others have said about making some sort of theme API available to front-end frameworks. The amount of work to integrate one in D7 is not the easiest or most intuitive, and, in a lot of cases, leads to losing the lightweight, quickness that a front-end library offers.

Tory Trone (not verified):

There should be some level of support for client-side frameworks inside of Drupal. It the direction the industry seems to be going and Drupal should address it. I prefer the Progressive approach.