Investigate where and how a frontend framework could be used

Suppose listing of menu items and taxonomy terms are nice examples to try

Added #2573119: [plan] Determine process for big UX changes

the biggest problem now is "Missing a Model Data Layer in Drupal's JS". Therefore, we can't redirect the flow to other client-side system easily.

Some problems, For example:
#2662932: Fix file upload progress bar
We can see that binded the events everywhere.

#2561619: Drupal Ajax objects and settings grows endlessly
We keep settings but missing sync. It pretty useless in most cases. also, there's no way to get the target instance from Drupal.ajax.instances.

#2542050: Toolbar implementation creates super annoying re-rendering.
It's using Backbone. However, I think it's misused this framework in many way (I called it Drupal-Backbone-Way). It didn't fully use Backend Model for data. It's almost unable to change pre-made features. Stuff also mixed in different controllers, also almost all events binded to .render()... (very hard to understand / test basic things)

#2293803: Replace confirm password element with a new element that allows toggling to view the typed password
Almost all Drupal's JS functions are not accessible in public scopes (also, not configurable, I also called it as Drupal-Style, always design for Core only).

Taking above issue as example, if we want to change a bit of code, it's not that easy:

+++ b/core/misc/revealpass.js
@@ -0,0 +1,59 @@
+  var showPass = Drupal.t('Show password');
+  var hidePass = Drupal.t('Hide password');

To me,
First: a new workflow for Core Issue (both JS and HTML/CSS), deploy it to development branch as quick as it can. To commit 99% good patch in ultra fast mode for 99% users and don't let the 1% blocking other patches bug fixing. If we checking other GITHUB projects / WP, that's working in this way. Most of developers are not fully funded by Drupal Firms, we can't spend our lifetime to a simple issue and no results (Just keeping reroll it and reroll it for nothing). We're drained.

#1931632: [META] Make core compatible with jQuery native-API selector
I thought it's a week of work. But in Drupal is few years and no results. Is it just because Drupal has no JS testcases? I doubt it honestly.

Second: Introduce a better Design Pattern for JS.

Third: I think it's good to pick a super lightweight client-side script and implement the Model part first.

the biggest problem now is "Missing a Model Data Layer in Drupal's JS". Therefore, we can't redirect the flow to other client-side system easily.

This is exactly what I've been thinking lately! You have to enable the REST module, then modify rest.settings.yml, then grant permissions, then write lots of code that deals with D8's REST API peculiarities (Drupalisms). That's a huge, huge obstacle.

I think Drupal core should ship with a core/backbone-drupal-models asset library. If you depend on that library, you'll be able to do this in your JS code:

// Fetch a node.
var nodeEntity = new Drupal.Backbone.Models.Node({id: 5});
nodeEntity.fetch();

// Now update it.
nodeEntity.set({title: 'Hi Dries'});
nodeEntity.save();

That'd drastically reduce the barrier to entry. You won't need to know about the CSRF token you have to request and send, or the exact routes to talk to, or which fields of an entity type should not be sent on PATCH requests, or the fact that you MUST specify the bundle for entity types that have bundles even though that kind of violates the previous point, or the fact that you have to remember to set the Content-Type request header, or …

The vast majority of those small obstacles then disappear. Yes, it'll be Backbone. But contrib could provide it for other JS libs/frameworks too.

IMO this would hugely reduce the number of steps you need to perform before you can even start to experiment.

#2542050: Toolbar implementation creates super annoying re-rendering.
It's using Backbone. However, I think it's misused this framework in many way (I called it Drupal-Backbone-Way). It didn't fully use Backend Model for data.

I agree. Jesse Beach first brought the Toolbar to core together with others (#1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop), but the result was extremely painful to debug & maintain. Then we had Backbone in core and she refactored it on top of Backbone (#1860434: Refactor the Toolbar JavaScript to use Backbone; fix several poorly functioning behaviors), which was a vast improvement (consider the issue summary there: After several months of use, it has become evident that the Toolbar JavaScript code is unstable and buggy in several places. — quite telling!).
But we all know how annoying the delay is between the page showing up and the toolbar being rendered (#2542050: Toolbar implementation creates super annoying re-rendering.). So clearly, there is still a lot left to be desired. Unfortunately, Jesse is not around anymore, if she were, I'm sure she'd have taken up improving this a long time ago.
We used to have much bigger problems before getting Drupal 8 out, but now that it is out, I think this has become a very important problem to address. I think nobody would oppose a refactor (which for some parts of it could amount to a rewrite) of the Toolbar's JS to make it behave better.

the biggest problem now is "Missing a Model Data Layer in Drupal's JS".

+1000. To me this is exactly the crux of the matter. I was hoping this is what backbone would bring to D8. Like @wimleers #8 outlines specific examples. I would favour something lightweight that allows easy and proper model definition in js.

+1 to a robust model data layer.

Exposing entities and standardizing the way we surface interaction and content relationships within Drupal to a model data layer sounds like a sane first-step towards exposing OO data in a rich and predictable format, not just for applications to consume, but also for surfacing contextual relationships users, organizations, and a wider-variety of platforms.

For consideration, Snowplow demonstrates the need for a "Universal Event Grammar" or "Lego Data Layer" which allows analysts to make sane interpretations of user interactions.

To me, exposing Drupal's entities to a standardized data layer is the first step towards enabling integrated systems safely interface with Drupal in a consistent and dependable way—be those systems applications (JS, etc), analytics platforms (Snowplow, Google Tag Manager, etc), or quite simply the minds of any developer who is not acclimated to Drupalisms.

Lets collect some examples of interactions that would benefit from a smarter and more capable frontend: #2675320: A list of interactions that could benefit from having a smart frontend framework

I often think one of the issues is people don't know how to use drupal's ajax system as it is. Poor documentation is certainly a problem for that (general performance of the ajax system is second to that). Mixing in another JS tool for the sake of doing so or saying "we're using that too!" isn't a good idea. Personally, I find that's happening too much with Angular right now.

As for finding a way to judge and categorize all the JS tools that 'could be used'. Both the strength and weakness of them. With attention to their release stability and clarification of the API's. Choose solid tools, not just cool ones! please!

sorry, rant comes in relation to: https://www.drupal.org/news/turning-drupal-outside-in

Comment #12 was to collect example in a separate issue. That issue has been closed with a comment that it was resolved with Drupal Canvas.

What still needs to be done here?