Drupal (admin) as an application: More JavaScript in core?

In recent months, much debate has revolved around the compelling user experiences increasingly accompanying the runaway growth of JavaScript frameworks. Some argue that Drupal already has many moving parts and should evolve toward more seamless user experiences with existing tools and better processes. Some argue that Drupal should address this trend with additional capabilities for JavaScript in the form of a JavaScript framework. Some argue we should look at using modern PHP and JavaScript technologies that don’t require a JavaScript framework. Others have positions that fall both inside and outside this spectrum!

• What are the advantages and disadvantages of more JavaScript-driven administration for both users and developers?

  • Advantages could include limited page refreshes, better perceived performance, and seamless state changes through client-side rendering, state management, and templating, as well as a more modern front-end developer experience.

  • Disadvantages could include delaying the initial rendering of some admin content until after the browser downloads and parses a JavaScript framework or potentially complicated workarounds to generate the initial render with Drupal, when these frameworks tend to be executed server-side with Node.js.

• How can Drupal concretely improve the front-end developer experience for veteran contributors who have long worked on Drupal as well as novice contributors who work in other paradigms and may never have heard of Drupal?

• Does Drupal need a new JavaScript framework or library to supersede Backbone?

• The JavaScript ecosystem is evolving rapidly: given that it will take time to integrate any new framework, how do we deal with the possibility that whatever framework is selected could be considered outdated once we finish Drupal integration, just like what happened with Backbone?

• What are some alternate approaches to reducing server roundtrips and providing optimistic feedback through newer PHP and JS technologies that might not need a client-side JS framework but which may result in incurring higher infrastructure costs or making Drupal more difficult to install?

• What are the next concrete steps as a result of this discussion?

This will be a neutral and unopinionated core conversation generously moderated by neutral observer Dani Nordin (Pegasystems) — thank you Dani! — and facilitated by Marc Drummond (Lullabot) and Preston So (Acquia).

Also see Drupal's front-end future: A compilation of ideas for more background.