Does Drupal needs a javascript framework in core

Lately there is a lot of discussion about adding a full javascript framework to Drupal core (either 8 or 9)

Dries' blog post

Related core issue Select a new client-side framework for Drupal 8 core's admin UIs

Some thoughts ....

The issue summary

The fluid experience in well-written single-page applications today far exceeds what Drupal’s admin layer provides

This isn't really a fair comparison, you cannot compare a single-page app to a full blown CMS

Thanks to the adoption of Backbone, parts of core already have this type of behavior, but many now consider Backbone obsolete

Not sure what many is supposed to mean, but is doesn't look dead to me, https://github.com/jashkenas/backbone/issues. It might have lost some of it attraction, but to me it still looks like a solid framework

We need to accelerate the pace of these improvements to match users’ growing expectations

Yes we do, but the question is what needs to be improved, to me it seems more logical to first create a list of - known - problems with the current UI. As a proof of concept, I created Dream permissions, in the mean time it is a stable module for Drupal 7, and a Drupal 8 port is on the way.

For example, it is no longer acceptable to experience a full page refresh when deleting a node or applying filters to searches of content

It would be nice if we have some figures to back this, none of our clients ever complained that they had to wait too long while deleting a node.

It is also extremely important that when performing any action, users get immediate feedback (or even optimistic feedback, in which the user sees the result even before getting a response from the server from their action, e.g. liking a Facebook post triggers an instantaneous response)

Immediate feedback is indeed vary valuable, but most of the time this can be accomplished using the already build in jQuery, for instance diable the submit button after the first click, add a progress bar/spinner so people know there's something going on.

Comparing this to liking a facebook comment is not a good comparison. Facebook is a single app (a large one), not a CMS.

PS: The liking can be mimiced using the flag module, and it will also be instant

Application-like UIs in Drupal (e.g. Views UI and block placement) would benefit from a standard framework to enable a fluid experience

Yes, we need to standardize, but it isn't only about the front-end code, the user permissions page does not scale, so in most cases we need to solve both the PHP and the javascript side. The other huge problem is that Drupal is fully extensible, almost any form/list can be altered in lots of ways. So moving all that logic to the javascript side will be a daunting task if not impossible.

Adopting a framework with a better front-end developer experience would also attract new front-end contributors to Drupal.

No, I don't think so and the front-enders I know feel the same way, if we want to attract more people and especially front-enders, we need to change the way we work: switch to sass (or less), provide grunt (or gulp) scripts, provide guidelines, style guides, components, linting, testing, ...

Why adopt a framework?

Since the issue didn't mention the downsides:

  • Load time of the page, no matter which framework is chosen, it will increase a lot
  • Render time of the page, given a lot of mobile phones need 500ms to parse jQuery, I expect it to be a lot more
  • Accessibility, the page should still be usable when javascript is disabled

Comments

The fact Drupal 7 selected jQuery

I think it was the right decision 5 years ago, but the biggest problem is that all sites got stock with it, the last 2 years we released most of our sites with the jQuery removed, because most of the time it was not needed at all or too slow for what we wanted to accomplish.

Contrib is a great place to handle the ever-changing, rapid landscape of front end frameworks

I have to agree, as long as we're talking about 100% back-end pages, the risk otherwise is that sites might end up with multiple (non-compatible) frameworks running side by side on the same page. Full comment at https://www.drupal.org/node/2645250#comment-10726864

Optimistic feedback without having the logic on the client means taking shortcuts while doing the preview, and possibly replacing that instantaneous-but-low-fidelity preview with a high-fidelity preview upon getting a response from the server

Yes, this sounds like a great idea, trick the user so he/she believes his/her comment got saved, use some ajax magic to save the comment and get the real comment in return. That was the what I tried to do in Dream comments.

My conclusion

Do we need to do something? Absolutely, but that is the easy part. We should improve the UX of the admin pages, make them snappier. But I'm not convinced that adding a framework as a first step is the way to go. We should make a list of known problems and figure out how to solve them. If solving them requires adding a framework, we should do it.

Regarding contrib, it would rather not see just a framework added to core, unless we add all the needed tools, some pre build components so they can easily be re-used by contrib, .... Most contrib module developers do not excel in javascript, so we should help them. The same goes for theming, we should make it easy for developers to follow best practices.

List of interesting remarks/questions

  • Crell: No matter what Javascript-based fancying up we do, the page must still be usable without JS
  • Marc: What about UI components that appear for authenticated users on user-facing pages
  • David: On the overall issue, wouldn't it benefit from first having a specific design/mockup/prototype for exactly what Drupal's user interface (or at least an example part of it) should look like in the future, and then pick a framework afterwards?
  • Pierre: Contrib is a great place to handle the ever-changing, rapid landscape of front end frameworks. All Drupal core has to do is make it easy.
  • Corbacho: Sounds too risky to bet on a big strongly opinionated JS framework at this point
  • mrf: I feel like we have jumped straight to "which JS framework should be in core" skipping right past the discussion of whether or not it is a good idea for us to rely on a JS framework in core, and how much we want to rely on it on that framework outside of the administration interface.
  • Wim: network latency is a problem we cannot ignore

PS: I've not added all of them, if I missed an important one, let me a note and I add it.