Proposal to use Vue.js for building Drupal’s administrative UIs

A curated list of awesome things related to Vue.js
https://github.com/vuejs/awesome-vue

Comparison with Other Frameworks (from Vue authors)
https://vuejs.org/v2/guide/comparison.html

Vue CLI
https://github.com/vuejs/vue-cli

Vue Router
https://router.vuejs.org/en/

Server Side Rendering + NUXT.JS
https://vuejs.org/v2/guide/ssr.html
https://nuxtjs.org/

Vuex (~Redux):
https://vuex.vuejs.org/en/

Electron & Vue.js
https://github.com/SimulatedGREG/electron-vue

Apollo/GraphQL
https://github.com/Akryum/vue-apollo

Weex (Cross mobile)
https://weex.incubator.apache.org/

An experience using Vue with Drupal: «Why we chose Vue.js over React»
http://pixeljets.com/blog/why-we-chose-vuejs-over-react/

Thanks for this proposal! I like it much more in use then react. With vuejs much easier gradually increase js-components in your drupal-sites.

Advantages:
- Really small learning curve
- it's easier to separate logic and templates
- routing in core

Just your friendly neighbourhood grammar police. ;)

In #2645250-183: [META] Start using reactive declarative JS programming for some new core admin UIs, I opened #2909485: JavaScript VDOM library evaluation: slots vs. vnode props and #2909481: JavaScript VDOM library evaluation: components returning multiple root nodes as child issues. I just now reparented them to this issue. I probably need to do a better job at explaining why I'm troubled by those issues with respect to Vue, but for anyone interested, let's have a discussion there about them. I'll try to write clearer comments / issue summaries there this week.

Replicate a “proof of concept” project—Database Logging UI—in Vue.js.

This is exactly what this project was built for. It is powered by Vue 1, but it should be possible to take the same approach for Vue 2. No need for any Node JS tools.

I suppose it should be about Vue.js

Check out comparison between VUEjs with various other JS frameworks https://vuejs.org/v2/guide/comparison.html

Round 6 evaluation by Stefan has great evaluation for different JS latest framework
http://www.stefankrause.net/wp/?p=431
http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts-result...

And another great company that uses VUE is Baidu

List of awesome VUE contributions that can be used
https://github.com/Dafrok/awesome-vue

+1 for Vue
-1 for React #2913321: Proposal to experiment with React for building Drupal’s administrative UIs

1. Single framework. Are you sure React will work well on non-admin pages? Me - not. Vue is much more friendly but still flexible enough for admin UI purposes that makes it perfect single framework for both admin and non-admin UI.
2. SPA. React is good for single page apps, but Drupal is another beast. Vue is easier to use on server-generated pages.
3. Maintainability. Drupal core's js is hard to maintain and React will make it much more complex for most of Drupalers.

Help me to involve Vue.js Team: https://github.com/vuejs/vue/issues/6737.

Definitely a +1 for Vue.js. I would rather dump Drupal then have to deal with React :)

Not to open up a bikeshed, but it might be helpful if those that participated in the decision to prefer React provide some points as to why they didn't prefer Vue.

Adding a note from Vue maintainers from https://github.com/vuejs/vue/issues/6737#issuecomment-334191864.

Hey people, what does that mean for the current situation that––as it is mentioned in #8––
there is already (?) a Vue.js implementation of the Database Logging UI?

there is already (?) a Vue.js implementation of the Database Logging UI?

Yes. It only replaces admin/reports/dblog page with Vue implementation.
Deletion was not implemented because of #2506449: Transform "Clear log messages" submit button into a link in admin/reports/dblog which happened right about that time.

Feel free to test it.

@Chi, how/where? everyone here is interested! share with us!

@tonystar, its referenced in #8.

@Chi, thanks! link is sooo noteless. Adding it in the issue description.

One thing I've noticed after attending Drupal Camps (and one Con) is that core contributors are often asking others to join the cause of helping with Drupal. One challenge for that is having enough developers with the skills to do so. Vue.js's easier barrier to entry is a step in the right direction. I think if Drupal is looking for more contributors, then making contributing to Drupal easier is a good way to start.

For those new to Vue and wondering how to define markup, here is a good breakdown of the different ways that templates can be defined. https://vuejsdevelopers.com/2017/03/24/vue-js-component-templates/

Although not my first choice in a normal project, Inline Templates (#4 in the article) might be the best bet for trying to make vue play nice with Drupal. This way the markup can go inside a normal Twig template. Wrapping Vue markup in twig's Verbatim Tag makes sure that twig doesn't try to parse Vue code.

{% verbatim %}
  <my-checkbox inline-template>
    <div class="checkbox-wrapper" @click="check">
      <div :class="{ checkbox: true, checked: checked }"></div>
      <div class="title"></div>
    </div>
  </my-checkbox>
{% endverbatim %}

By having it in normal twig files it allows themes to override or extend the twig file. This is really important in the long run to make sure that theme's have the ability to change markup as needed.

This is huge ^ and is the main thing I am also concerned about with React. One of the gold standard tests for which framework to adopt should be "ease/cleanliness of altering a single admin ui component" for a specific client need. Don't know enough about React to know how this could be done. I assume though because react ties template+css+js logic all into one component, you'd have to override the entire js file somehow.

Echoed in comment #229 here: #2645250-229: [META] Start using reactive declarative JS programming for some new core admin UIs

And a similar note about bundling on comment #209: #2645250-209: [META] Start using reactive declarative JS programming for some new core admin UIs

+1 for inline templating and Twig. It makes a lot more sense for server-side apps.

It's worth noting that Vue now has a style guide https://vuejs.org/v2/style-guide/, and also a new test utility https://vuejs.org/v2/style-guide/

I believe that Vue is the best solution for Drupal. It's very simple. We don't need to use JSX (sometimes it's very hard to read such code). Single file components (https://vuejs.org/v2/guide/single-file-components.html) allows to divide HTML, CSS and JS, but nevertheless they will be in one file.

I prefer Vue.js to React.js. Vue.js has a more promising community ecosystem.

@jwilson3 - re: #25 - can you make that comment in the #2913321: Proposal to experiment with React for building Drupal’s administrative UIs? That sounds like the kind of concern they want to hear about.

We have started using Vue.js heavily here at VML. Specifically on both a D7 and on multiple D8 projects. Our lead JavaScript developer had previously been doing a lot of React development when it was suggested to him that we use Vue.js for the D7 project. He spent a little bit of time learning it and liked what he saw. So he pulled the trigger and started using it for that D7 project.

Since then he has told me numerous times how much better it is to work with Vue.js over React. I, personally, have been doing some Vue.js dev work for these projects and can tell you that it is a powerful, amazing, decoupled JS framework. It has quickly become our goto. We won't even consider React or Angular. Instead we use Vue.js with Vuex immediately.

On top of all of this, from what I have heard from the community, is that devs are draining back away from React faster than they are moving to it. They are finding alternatives to be better, especially Vue.js. Maybe I am misunderstanding things, but usually I have a decent handle on these things. It would be unwise to add a tool (React) that is quickly losing popularity.

Given what I have seen and experienced, I think it would be a huge mistake to use React. Using Vue.js is the right choice and really the only good choice ;).

Vue has my vote.

Quick point, if we want to push Vue.js then we need to do more legwork.

According to Webchick in that React post:

The issue summary pretty clearly states that the group that's behind React only has bandwidth to pursue pushing React. So folks advocating for other technologies (Vue, Web Components, what have you) would need to present their own research, their own prototypes, etc. alongside. This would be a great thing to do; the more, the merrier; the more data we have, the more sure we can be of the decision. However, Web Components/Vue aren't going to shine by having people behind a different technology trying to cobble something together; the folks really pushing for those will do a much better job, but will need to put in the work.

Later she says this:

Well, no. This issue is specifically about:

Please keep discussion focused on whether or not React would be a viable solution for Drupal, not the promotion other frameworks.
Specifically in the format of:

React does X in this way
It is an issue because Y

Framework Z is better because it solves the issue in that way.
If you want to merely voice your support for framework X, you can do so at #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs (though it must be said that you're highly unlikely to sway people that way...)
If you want to put forward your support for framework X in the form of a complete proposal that includes detailed research, implementation that can be compared/contrasted against React, etc. you can do that at another issue such as #2913628: Proposal to use Vue.js for building Drupal’s administrative UIs

But this issue is specifically all of the people listed above saying, "We support React as the framework of choice, and furthermore we are all willing to put time/effort into making it happen. If you have reasons why React is not a viable solution, speak now."

It'd be great if we could refocus discussion in this issue on that, because hard data with examples will be a far more effective way of swaying people away from React, if that's your goal.

Anyone want to spearhead this?

Another tip: "what I have heard" type comments about community/developer velocity between the two projects would also be a lot more compelling if they came backed up with data/stats (google trends, job trends, github trends, that sort of thing) vs. personal anecdotes.

Just checked out Chi's module, from the comment on the React thread...

Very fast! Definitely seems like a subtle, but good improvement... however, I would think we would want to show more than just a replacement for the current dblog. And having the demonstration implement features/functionality that really benefits from a front-end framework seem very useful to this discussion... Off the top of my head, I'm thinking:

1. Live updates -- get a stream of updated logs matching the current filter, polled if nothing else
2. Filter on matching string, user
3. Pause live updates
4. Show detail in a separate pane, instead of on essentially another page
5. Support (or document) how to load Vue from a local copy instead of CDN

The following comments were collaboratively prepared by members of the core JS group who proposed the parent issue.

Learning curve

We believe the learning curve between two of these are close. However, this is very subjective, so we suggest to not use this as an argument to one side or another. Being said that, we agree that the documentation for Vue.js is slightly better.

Build tools

Vue.js can be used without build tools, so can React. It doesn’t matter which framework we choose but I think we should use build tools (as we already do in core) since modern tools will make creating UX with rich interactions easier.

React being maintained by Facebook

We are aware of and share some of the expressed concerns about Facebook, but this is a tradeoff we are comfortable with now that React has been relicensed as MIT. Drupal have also depended on other technologies backed by enterprises, such as MySQL which is backed by Oracle. We should also remember that this doesn’t only come with downsides.

If there are new concerns in the future, then we will revisit this point. A good example is Backbone, which at the time probably was a good decision, but now we’re slowly moving away from that.

We considered Vue.js as part of our conversations in DrupalCon Vienna. The main concerns we had about Vue.js are:

• Maintainership: Vue.js is mainly maintained by a single contributor https://github.com/vuejs/vue/graphs/contributors
• Stability: Vue.js had backward compatibility breaks a year ago. This may not happen again but without a proven record of stability it is more difficult to predict.
• Familiarity: The core developers involved have much more expertise and experience in React, allowing them to focus on the more difficult problems involved with this initiative.
• Depth of talent pool: Many frontend jobs require React knowledge, meaning that it is easier to find people with React knowledge.
  For example on Stack Overflow jobs, there are only 10 openings mentioning Vue.js whereas there are over 100 openings mentioning React.
• Breadth of ecosystem: React’s broad adoption means it is easier to find support when we run into problems. It is also much more likely that there exist libraries that match with our requirements. For example, Vue.js has 2600 npm packages whereas React has 16000.

It is important to keep in mind that the big problems we likely run into are missing APIs and other framework independent problems, not which JS framework we use.

Please also be aware that this will be an experiment, if this choice doesn’t suit our needs it can be rolled back, while we still gained a lot of knowledge/fixes for our API layers.

+1 for Vue, sometimes ago there was this idea of Progressively Decoupled Drupal, vue serves this idea much better than react.

Google trends

Vue.js recently overtook React in Google Trends:

Interest over time in the two frameworks October 2015 - October 2017: Google Trends

Github starred trends

React and Vue.js are the 4th and 6th most starred repositories of Github as of October 2017, 77.500 for React and 69.200 for Vue.js. The trends in GitHub stars indicate that Vue.js might overtake React within the next six months.

From: http://www.timqian.com/star-history/#vuejs/vue&facebook/react

@lauriii thanks for the transparency on what the core team was evaluating when making their decision. It's much appreciated. One thing I will point out on the commit graph for maintainership, in an AMA with the Vue core team https://hashnode.com/ama/with-vuejs-team-cj7itlrki03ae62wuv2r2005s they mention that they are:

using the 'Squash and Merge' feature on GitHub when merging PRs, so the commit count isn't very representative of the community contributions.

As for the backward comparability break, it was pretty painless and nothing like the Angular transition. A recent article https://codeburst.io/an-overview-of-vue-js-and-the-future-of-the-framewo... addresses the future with version 3.

The main idea of ​​the Core team is simply to refine the API and internal code, as happened from v1 to v2

We are aware of and share some of the expressed concerns about Facebook, but this is a tradeoff we are comfortable with now that React has been relicensed as MIT. Drupal have also depended on other technologies backed by enterprises, such as MySQL which is backed by Oracle. We should also remember that this doesn’t only come with downsides.

@lauriii Is this the answer to the concerns about React not adhering to Drupal's values? Or if not, do you know if there will be a more detailed answer later?

@chi and all

Got this message about the Vue.js implementation mentioned in #8, #18, #19 #22 #35 on Twitter from nod_ (emphasis from me)

"A patch would be welcome. No time to track down code these days."

I just remembered another example of Vue in Drupal.
#2828882: Add Vue.js example

It also kind of outdated, I believe many things have been changed in Vue.js for the last year.

Below is a quick overview.

Perhaps it should be published somewhere on GitHub since it failed to get into Examples module.

This is a huge +1 for Vue.js from me. We've gone through a number of javascript frameworks just this last year to consider the best one for our security platforms. This means we went through the test development of a simple test use case four times - with Angular 2/4, Ember, React and Vue.js.

Our test: Single page drag & drop UI builder that spits our a json to the API endpoint. Since the json is used to construct a PDF, client-side conversions between px and pt and scaling from on-screen size to A5 format are needed.

Here are the results of this test:

Ember: royal PITA; The only way to construct this UI is to pass actions from components to controller and/or route, spilling the business logic all over the place, which means painful maintenance in the long run.

Angular: a bit better encapsulated, but one notices that Angular was designed as a full solution, a lot of which our use case didn't really need. Still, it could handle our test, if with more overhead.

React: Impossible to complete the task with originally planned layout. Why? Because JSX is a sorta kinda maybe xml/html/js/schmoo hybrid frankenstein's monster, which among other atrocities expects a single render wrapper. This leads me to my honest opinion that React is shit, because JSX is shit. Furthermore, I expect native support for Web Components out of the box these days. React has that kindaish, but breaks its own API for it (hi className, I mean class... what?).

Vue.js: a breeze and refreshingly simple to work with. Data bindings could not be simpler and since it tracks them internally, you don't need to mess around with shouldComponentUpdate() that React forces upon you. The end result (fully functional) was less than 200 rows of code between one main js and two components for the entire use case. Yes please, any time, every time.

It's thus no wonder we settled on vue as our prime candidate. Familiarity and Ecosystem be damned when a new developer can get into Vue within a day and when building an own extension can be done within minutes. In fact, I was so impressed with Vue.js that I've thrown away what I've planned with my own website (would-be Ember-based) and plan on rebuilding it in Vue instead.

Vue author Evan You here. I'd like to respond to @lauriii 's comment here regarding his points.

First of all, I totally respect whatever decision the Drupal team makes, because this is their decision to make; I personally do not use Drupal, and do not have a strong interest in pushing Vue to become its framework of choice. That said, I think it would be beneficial to provide some perspective on the issues raised against Vue, to help the team make a better informed decision.

Learning Curve

I don't believe learning curve is subjective. When a developer tries to learn a new framework, how fast he/she becomes productive is something that can be objectively measured. The real issue is the lack of accurate measurements or statistics to properly support the arguments. My opinion is that ruling out learning curve as a selection criteria due to "subjective-ness" is wrong, and the broader Drupal community should be surveyed to take this into account.

Build Tools

What people often miss when they say "So can React" is the fact that you either use raw render function code with `React.CreateElement` (which I don't believe many enjoy), or you have to include an on-the-fly babel transipilation setup which makes it prohibitively expensive to ship to production, both code-size and perf wise. In comparison, you can safely ship a sans-build-tools Vue app to production by switching to the minified production build. "You can use it without a build tool" and "You can use it without a build tool in production without significant overhead" are very different claims.

Sustainability

The GitHub contributor graph is misleading in several ways:

• - The large amount of commits in Vue core before September 2016 are mostly from me alone because that was the initial development phase of the 2.0 rewrite.
• - After the 2.0 release, to maintain a clean commit log, all core contributors commit code via PRs and we merge them using GitHub's "Squash and Merge" feature. This results in only 1 commit for each PR most of the time. Which means a core contributor who has landed 30 PRs may only have 30 commits in the graph.
• - Vue.js core is still primarily maintained by me, but if you look at the amount of PRs we merge in recent months you'd see it's definitely not "by a single contributor".

As a project, Vue.js has come a long way to reach what it is today. It has grown from a small experiment into a mature framework that is used by hundreds of thousands of developers all over the world. It has also grown from “yet another side project” into an ecosystem with over 300 contributors across the vuejs organization, and maintained by a core team of over 20 active members across the globe. Core team members have taken up responsibilities such as core library maintenance, documentation, community engagement, and major new features such as type declaration improvements and test utilities. Saying that Vue is a “one man project” is no longer accurate and would be disrespectful to all the amazing contributions from the team and the community.

Stability

The only breaking change we had in the entire past 2 years was the 2.0 release. I'm not sure if that's a good enough track record for you, but we take stability very seriously as well, because there are close to 300k developers using Vue in production around the world. We have no intention in introducing breaking changes without a good reason, and we don't have plan for breaking changes in the foreseeable future. (we have discussions of a version that drops legacy browser support, but it won't have breaking API changes and it will released alongside the current version.)

Ecosystem

There's no doubt React has a larger ecosystem, but I believe the size of the ecosystem has a threshold of diminishing marginal returns, and the difference between the two wouldn't make material difference especially in the long run. With Vue's current ecosystem size it's also very unlikely that you'd run into a problem that doesn't have a corresponding solution.

Talent pool is a metrics with a big delaying factor because the broader industry is generally slow in adoption and are often trend followers. Vue had close to no job listings at all a year ago but we are seeing rapid growth now. In terms of familiarity, if the current team is already heavily invested in React, then indeed it might be a strong reason to just go with React.

Overall, I feel that the situation with Drupal is very much similar to that of Wordrpess: the team already has investment in React, and the decision is made primarily considering core development. The question of how much the choice will affect community usage (e.g. plugin/extension development) is not clear to me from the information disclosed so far - but personally I think that should be more thoroughly discussed. If all community developers would have to use the framework chosen to develop extensions, I believe Vue would be a much more approachable choice and would benefit the community; but if that's not the case, then I have no objections with Drupal going with React.

+1 For VUE. Integrated it in some project to try it. It's easy to use, easy to integrate and easy to learn. It can be attached just like jquery library and work only with some parts of the page, very clearly what happens and can be easily used with hook_theme + libraries API.

In regard to the effort of making the database logging UI with Vue:

What are our objectives.

I've only seen one mockup for what the UI should look like. Does the React team have a set of mockups / designs / list of stated goals that the new UI should accomplish that we can use as a way to somehow compare the end results we're working towards?

Created a new issue at #2915262: Define the new DBlog UI to discuss the UI

I'm very happy that the discussion on this issue is discussing multiple factors, not solely popularity. Please keep that going. For those interested in a discussion on popularity, I opened a child issue: #2915294: JavaScript VDOM library evaluation: popularity. Please discuss popularity there rather than here, in order to keep this issue less distracted by that. I'll open other child issues for other side discussions as well. Thanks!

@KayLeung has updated @Chi's dblog_ui example for Vue.js version 2.

The 8.x-2.x branch has the Vue 2 code: https://github.com/Chi-teck/dblog-ui/tree/8.x-2.x

At this point the module duplicates the existing core dblog UI. It relies on dblog to actually do the logging.

Please try it out. Feedback/issues/pull requests are welcome.

Nice work @KayLeung and @Chi, your "Recent log messages"-page with Vue.js is very smooth and fast.

Looking into it I was a little bit surprised it didn't depend on core's 'RESTful Web Services' and instead used custom controller with JsonResponse().
So the question I have (which is not framework specific, but since it is the first one to be implemented and the Polymer one is based on it) is what are the challenges of making it use things like:
1. dblog's @RestResource (core\modules\dblog\src\Plugin\rest\resource\DBLogResource.php), or @RestResource in general since the one in core is very basic.
2. REST export display type in Views
to show tighter integration with Drupal ?

@tacituseu:

I'm not sure why it was chosen to pick a custom controller, but the data in Vue is whatever you map to the data object. You'll usually be loading that data somehow (in the example through the app's "mounted" method). Whether that's a custom controller, a rest api or a jsonapi doesn't really make a difference.

Truth be told, I've been thinking of sacrificing the coming weekend to show an alternative approach with the core rest anyway, as the above result does not yet match #2915262: Define the new DBlog UI. Vue is capable of so much more, so let's show it properly and give the alternatives a run for their money.

@tacituseu I started originally with REST resource but then found that custom controller is much more convenient for this purpose. The application is read only and callback for reading log entry took about 30 lines.

As of using views for building backend side I think it has no benefit in this case. The one cannot change view without changing code of client side application. And besides the controller provides a bit more than just a list of log entries. It also returns options for a filter.

Alternative way could be creating a special Views display type, say Vue View to output records using JS framework.

The API-first initiative is planning to move JSON API into core at some point. We still don't know when, but I think for purposes of React/Vue/Polymer/etc. exploration, it would be fine to use that module, if you think it provides the cleanest implementation.

If there are benefits of a custom controller or custom Views display type over JsonApi, please write up an issue explaining what those benefits are, so that the API-first initiative can potentially incorporate that into their planning. Thanks.

Specifically, I'm curious if:

It also returns options for a filter.

is supported by JsonApi or not.

Pretty cool that Vue.js author wrote comment on this issue (#45).

Overall, I feel that the situation with Drupal is very much similar to that of Wordrpess: the team already has investment in React

Or is it?

I don't know that Drupal has made a large investment in React, but large companies such as Acquia might have a large investment. Just look at the latest blog post of Dries:
https://dri.es/the-evolution-of-acquia-product-strategy

Specifically the picture at the bottom is worth a thousand words:

¯\_(ツ)_/¯

@effulgentsia the base JsonAPI specification does not define filters, however the API does forsee them. You can read more here:

http://jsonapi.org/recommendations/

To set the record straight on the FUD in #58, Acquia uses a variety of JS libraries for its products—Angular, Ember, React, etc. and https://dri.es/announcing-node-js-on-acquia-cloud explicitly is framework-neutral, because most of our customers are in the same boat. Dries previously came out explicitly against React last time this conversation came around because of the patent clause: https://dri.es/selecting-a-client-side-framework-for-drupal

So let's stick to facts in these threads, not to unfounded accusations, thanks.

To address the other question in #58:

I don't know that Drupal has made a large investment in React

It hasn't. I think @yyx990803 was either referring to the WordPress team rather than the Drupal team, or if he was referring to the Drupal team, then he might have inferred that based on #37's comment that:

The core developers involved have much more expertise and experience in React, allowing them to focus on the more difficult problems involved with this initiative.

And that's true: of the people who discussed Dries's proposed initiative in Vienna of building a new admin UI in Drupal with a modern JS framework and were interested in actually doing that work, those people were more excited about trying it with React first, partly because they already have a lot of expertise and positive experience with it. It's awesome that there have emerged additional teams of people wanting to try it out with Vue and Polymer.

We have a ways to go with backend API support for even this trial task.

@effulgentsia re #56 JSONapi does not seem to support querying of dblog entries at all currently -- perhaps because these aren't standard entities. While JSONapi can do filtering and paging generally, it's not clear how the message types or numeric severity filter options that @Chi refers to can be exposed by that api.

Core rest does not seem to provide a means of querying a list of watchdog entries at all, although individual records can be returned once we know the watchdog id.

Views/rest comes closest to what we need. It can expose a list of watchdog entries, and this can be paged and filtered. However the filter for severity requires a numeric value, which does not seem available to be queried directly. Nor is it clear with paged JSON input how to get a complete list of error types, which is accomplished by a db select in the current dbblog module.

So Dblog in its current form can provide almost what we need only through views/rest -- except for the filter options, which will require a custom controller. @Chi's code combines both this and what views/rest provides in a single custom controller.

In any case, I would suggest that how we pull JSON-formatted dblog messages is not really in scope of this particular issue. It has no bearing on a choice of Vue, React, or any other contemporary javascript framework. Whatever front-end framework is chosen, javascript requires JSON data to work with, and in this case core/jsonapi or whatever backend will have to be modified a bit to provide what we need.

Thanks for the info in #62!

I would suggest that how we pull JSON-formatted dblog messages is not really in scope of this particular issue

I agree. I'm perfectly ok with the proof of concept continuing to use a custom controller for it, and that will not harm Vue's evaluation. If people working on it want to experiment with alternative approaches (e.g., making a custom Views display type, or enhancing JsonApi with http://jsonapi.org/recommendations/), that's great as far as collecting more knowledge that could lead to Drupal core improvements regardless of JS library, but it's not necessary.

You can easily use a view for this purpose: https://gitlab.com/dawehner/admin_ui_elm/blob/8.x-1.x/config/install/vie... but I think it really doesn't matter how we end up implementing it. Its really just an implementation detail, and it actually more important to figure out which APIs are missing.

One more approach to consider is extending render API for building common used elements (tables, forms, modals, etc) to make the code reusable.

Something like this.

$build['log_records'] = [
  '#table' => 'vue_table',
  '#filters' => [
    'type',
    'severity',
  ],
  '#data_callback' => '::getRecords',
];

Developers could make use of it even without touching client side. This would be similar to Drupal ajax framework way.

+1 to #65, for simple core things like Watchdog, there should be easy ways to filter via the API.

However, for more general use, we're really excited about GraphQL. I think it's well beyond the scope of this initiative, but if we find that there are so many filters, configurations, and server-side work to do to provide broad enough coverage when we expand beyond Watchdog, I do wonder if we should just go straight to GraphQL and make sure that's a solid, 1st class API.

@freelock: I think it would certainly be awesome if the React team could demonstrate GraphQL integration for the dblog challenge at : #2913321: Proposal to experiment with React for building Drupal’s administrative UIs

Let's not talk about graphql here. Its totally out of scope and would require a solid year of work probably upfront.

Just noticed this: https://twitter.com/rauchg/status/918959056722653184?s=09 : Vue server-side rendering being compatible with PhpV8JS (the V8 engine as a PHP extension), meaning no need for a Node server for SSR. Seems like a huge painpoint removed for many sites.

More details in the Vue 2.5 release notes: https://medium.com/the-vue-point/vue-2-5-released-14bd65bf030b

I have opened a related issue for discussion: #2916453: Decide on committing to and adopting W3C Web Components standards

+1 Vue.js
-1 Recat.js

I developed an experiment module that demonstrates how to adopt the Vuetable component of Vue.js into Drupal 8 as a render element.

Here is the module,

https://www.drupal.org/project/vuetable

the drupal team I am with at the moment in Switzerland went through the pro's and con's of which framework to use to decouple and we ended up with vuejs. It was a tight call and it was last year when we made the decision. We are pleased with that decision and hope vuejs is the preferred choice for the core admin proposal. I would echo the other positive points made on here about vuejs with the caveat that their license was a factor (REACT changed theirs recently to be more restrictive and then backpeddled).

key pros for us:
modular,
lightweight,
mature community,
scalable,
easy to learn.

@Dublin Drupaller: Thanks for posting your experience. I'm glad to know you've been pleased with your decision so far.

A question about this statement though:

license was a factor (REACT changed theirs recently to be more restrictive

What do you mean by that? React changed their license in version 0.12 (3 years ago) from Apache2 to the controversial BSD+Patents with a strong retaliation clause. I agree that this move made it more restrictive. Is this the "recently to be more restrictive" change that you're referring to? Or are you referring to something more recent than that?

and then backpeddled

By this, are you referring to the change a couple months ago to the MIT license for version 16? That's not exactly backpeddling, since it's the first time they're licensing it as MIT.

Regardless of the above, I think you made a completely reasonable choice, especially at the time that you made it, when React's license truly was problematic. And I think it's also reasonable for teams to still prefer Vue over React for various other reasons unrelated to license. I just want to make sure there's more clarity on this issue about the license factor, considering that as of now, Vue and React have the exact same license.

Also, Vue has no issues with webcomponents/custom elements whereas the same cannot be said for React

https://custom-elements-everywhere.com

@effulgentsia you are correct, licensing was one of the factors in not adopting react last year. In simplicity, we didn't want to invest in a framework we wouldn't be able to use due to licensing restrictions. In the same breath...that is related to the context our team was in when choosing...large organisation (100k+ employees) with strict guidelines on acceptable licenses. That same context wouldn't be applicable to a lot of drupal teams, I guess.

While I am on, I would also echo what @d_f said about the modular, component based approach to vuejs...we like that a lot and fits with my experience of the "drupal way".

+1 for Vue
-1 for React

+1 for Vue
-1 for React

1+ Vue.JS!

Vue +1!

Vue +1, agree to it and I will build it in 2 weeks. That is how easy it is!!. I have been doing React for over two years still didnt understand half of it. If we do Vue we will gain half of China, just think about that!

I think what we really need here is to build a framework that allows a PHP or JS developer to easily integrate Vue.js into an existing Drupal site or module.
I have done a couple of experiments using Vue to connect to an existing Drupal module to provide reactive functionality. Some of the choices I had to make:

1. Do I use .vue component files (which would require compilation) or do I use plain .js files with twig-rendered template files? Because of Drupal's libraries system and twig, it is seamless to just build a .js file and use Drupal's libraries system to manage the dependencies. But the convenience of seeing templates, js and css in the same file is lost.
2. Using .vue files meant that I had to duplicate the templates in .html.twig files into the <template> section of the .vue files. Essentially, all twig templates would need to be rewritten as Vue.js templates with reactive variables embedded.
3. Do I write new controllers to handle the Ajax endpoints that Vue needs to communicate with the back end? Or do I try to modify the existing controllers that were designed for existing functionality?
4. Do I use a node.js backend with server-side rendering? Or do I use a direct connection to Drupal API's?

Fortunately, Drupal 8 now has a maturing REST API with potentially JSON API module also going into core soon, so there can be some agreement on best approaches to entity CRUD.
The one area that is still very challenging to deal with is Drupal's Form API especially the Ajax aspect of it.

It would be interesting to see and hear how others are dealing with these types of issues.

I guess, what I'm saying here is that all of us who have shown interest and done something with Vue in Drupal should share experiences and ideas and come up with something to build upon.

To get this kickstarted, I have create a new #vue channel on Drupal Slack. All those interested can join and share.

We may have to raise a couple of issues to discuss and agree on the best approaches to solve some of the questions raised.

In addition, I think we should also have a Community Initiative around this, since a greater proportion of the Drupal community favors Vue over React.

Hi,

I've done a couple small Vue/Drupal experiments, too, with similar open questions. I built a simple Vue app with a few components, all contained in a Drupal module and dropped onto the page as a block. This was very easy to put together and get working -- however, I did not make it reactive -- I was just making a read-only version of this: https://vue-blog-demo.netlify.com/ ... backed by a Drupal content type.

To load the data, I used GraphQL, which seems like a fantastic way to get data in and out of Drupal (though you need to create the GraphQL mutations you want to support server-side).

So the issues I ran into:

1. Not reactive -- I have not (yet) figured out how to make the client side update automatically from the server, using Vue as a Drupal block in a module that loads the library
2. Progressive Web App vs Single Page App -- the way I built this, I essentially have a single Vue application embedded as a block -- but we want to build a bunch of others that may end up dropped on the same page. Is there much of a resource issue if you have a bunch of active Vue apps on a single page? If there is, how might we bundle and pack components across several different Drupal modules, to end up with a single Vue app, without going the whole "Single Page App" approach?

Obviously we can go fully de-coupled and just build a single-page app in Vue that loads all its data from Drupal, but I'm looking for a middle ground here -- make use of a lot of Drupal, and mix in a bunch of Vue components for particular widgets.

To address @almaudoh's questions:

1. I used .vue files, dropped an entire tree into the module using Vue CLI. I modified the webpack configs to remove hashes from the generated css/js filenames, and added the built files to a module libraries.yaml file. This worked great! But it does mean that you need to build the files, and presumably ship your module with those files built. And I'm not sure how you would build these across modules.
2. I'm not seeing how to avoid this -- especially if you want to support older browsers. Webpack and Uglifyjs allow you to write current Javascript and (mostly) backport it to whatever browser level you need. I don't see how you can do that with Twig, because the twig gets compiled at request time, while Vue gets compiled long before.
3. The core JSON APIs should be workable, but they are wordy and take a lot of work to use. If you want to use FormAPI, you have a couple extra data conversions to do, seems like a waste of time to me. Much better than either: GraphQL, or JSONAPI -- these have libraries that relatively directly load the data into Vue, and greatly reduce the amount of work you need to do. Between those, JSONAPI is more of a RESTful interface, and seems pretty great for simple components. GraphQL is more like RPC -- or more like SQL compared to CSV -- way more powerful but the client side needs much more knowledge of the back end. And you need to create server-side plugins for any data you want to update from the client.
4. The one place node.js might be useful/necessary is for pushing updates from the server to the client. Otherwise I would use the Drupal APIs (one of those better ones, anyway) exclusively.

I haven't spent a lot of time on this just yet, and it's been a couple months since I did our Vue experiments -- but am very interested in doing more of this going forward....

Thanks @freelock for your response. As it happens, I used more or less the same approaches as you did.

1. Used .vue files compiled with webpack / uglify using Vue CLI. However, you've asked pertinent questions. Ideally, IMHO a better approach would be to compile each .vue component to a separate Drupal 8 library. Figuring out how to do that is an interesting experiment I want to do. In addition, it would be nice to still have Vue loaded separately rather than compiled in.
2. One way to solve this is to provide Vue components that map to given Drupal render and form elements as well as theme functions. The twig variables that are supplied to these can then be supplied as props to the Vue components. This will allow reactivity to be achieved by updating the props. I have started work on a new Drupal module Vue Elements that hopes to achieve that.
3. I agree on this that JSONAPI and GraphQL are the most likely approaches to use for connecting with the back end.
4. +1

I'm a Drupal developer who has never had to use a js framework. I know basic js and jquery but the writing is on the wall; I'm going to have to learn one of these frameworks soon. From what I've been reading, vue is the most accessible and possibly the best. This article for example:

Why you should leave React for Vue, and never use it again.

https://blog.sourcerer.io/why-you-should-leave-react-for-vue-and-never-u...

@robbdavis well the best thing would be to try both frameworks, before making up your mind. Because right now it sounds like you prefer Vue even though you never worked with it, which is not really beneficial for this discussion.

I think it should be interesting to read for clarifying the picture: https://news.ycombinator.com/item?id=17636940 .

And one quote from the comment https://news.ycombinator.com/item?id=17639874:

... but to point out that fundamentally Vue doesn't seem to offer any different core concepts than other frameworks. I think it just hit a sweet spot timing of being a React competitor, when developers who didn't like (or, I suspect, don't fully understand) React's fundamentally paradigm and convention shift. ...

As a full stack guy mostly working on the back-end I really don't have a dog in the hunt. What I am looking for is coexisting UI technologies that can be leveraged together within a single site for 'real world' application needs. Primarily Twig, Web Components, js.

Going completely headless makes no since for me, and likely for the majority of other site builders and their clients as the increased cost / time to market would not justify doing so. The final product is the objective, and marginal perceived performance gains experienced by end users who have absolutely no concern of underlying presentation technologies has to be rationalized.

Each of these methodologies have a role and ideally could & should be combined within a site application where and when needed.

I spent some time exploring React for no other reason than the majority of initial work and discussions within the Drupal community suggest React was gaining momentum. I have integrated some simple React components within existing d8 sites. OK, but still not in any camp yet.

Leveraging custom elements & web components in Drupal will be a major factor(for me) on which js framework/library is a best fit and after taking a look at the tests here... https://custom-elements-everywhere.com/ I have begun taking a harder look at Vue.

Foremost Vue should be able to perform components as blocks functionality and work in a partially partially decoupled environment along side standard twig presentation rendering and web components.

Looking forward to giving Vue a fair shot.

https://www.youtube.com/watch?v=pLcM3mpZSV0 is an interesting video of Laravel's new Nova admin interface. It uses Vue.js components that are controlled via PHP. This is a great approach because it allows the developers to continue using their existing PHP knowledge.

@segovia94 Nova looks very nice. Here's a good rundown: https://medium.com/@taylorotwell/introducing-laravel-nova-7df0c9f67273

My two cents. I'am VUE advocat and this is list of why I prefer VUE over other libraries:
- Fully support web component library which is goal to be decoupled from decision of what library can be used: https://custom-elements-everywhere.com/
- Compatible with JSX, React, Ember and other. No name collapse, no fuss about mixing thinks if somebody like.
- Inline template - huge benefit in term of admin panel where less people change somethink
- Vuex is working and is properly connected and mature.
- Vuex, vue router and some other libraries are supported by same core team
- Performance gain as more declarative approach to template.
- Lock down features - hooks are from 2.x but less feature will be added. Core team propose to build extension rather than bloat vue. Treeshakeable to even less bargain in every pull. Huge mind change in term of what other advertise.
- Mature framework now with decoupled core and added Typescript checking for whole solution
- Better quality as they start earlier and learn from React/Angular ("steal best thinks" xD). Core team understand other libraries and built on experience other failures. Think about next iteration of React
- No big company stand for license (Facebook change react license and that will be catastrophic, learn from history - https://www.freecodecamp.org/news/facebook-just-changed-the-license-on-r...)
- Proper, full documentation with DX on mind
- Tests, Typescript and fully polished framework to ci/cd approach. Focused to bring more tests and polish everyday.
- Component approach is more "template" than "utility" but component can be wired in Drupal easily and clean.
- Designed for incremental adoption
- Accessibility aware in core, docs and outside (Docs: https://github.com/vuejs/vuejs.org/issues/974, https://vue-a11y.com/)
- Static site can be generate and this library is friendly for solutions like that - example: Nuxt. So this can be used as SSR site.
- PWA friendly
- Webpack friendly - key aspect for many people
- Extension to Debug data in browser
- XState compatible and easy to use - proper adapter exist. This is usefull to design state of every screen and transitions.
- Hooks is introduced to better wire components together as mixins are less featured. In 3.x as part of it.
- Native solution exist - https://vue-native.io/

There is caveats:
- React ecosystem is bigger but not mature. More bugs can be introduced. Other framework have smaller ecosystem but polished.
- As a Component approach is forcing some way to code. It is little more opinionate than React where you can do in any way you like.
- React and other libraries are battle tested as small like vue will have his first time to be introduced in such a big framework and scale. What we mean is real number of different problem. Facebook tested it in heavy way and this is first think that anybody is look for it. Vue take part of solution to their core so it's not big difference.
- Community is young, less professional in term of what is inside in core packages.

@patryk padus: I do not know which is better React or Vue. What I do know is that the persons who are building the new administrative UI what to build it with React. And that is why React is chosen.

Comment removed as I can't find where development discussion is now.

As I like Vue better than React I'd give this an upvote as well +1

Google trends

Vue.js and React have been neck-and-neck in Google Trends during the past 12 months:

Interest over time in the two frameworks June 2019 - June 2020: Google Trends

Github stars

Vue.js and React are the 3rd and 5th most starred repositories of Github as of June 2020,

1. Vue.js: ~165.000
2. React: ~150.000

#teamvue +1

Vue +1!

+1 for Vue.js!

I think it's easier to learn and it has a big community.

Vue is the best. :)

It's easy to learn and it's easy to understand even for people who don't know Vue yet.

I saw this post #3145958: [META] Re-evaluate use of Backbone.js in core yesterday, and I thought - Vue could probably be a good replacement for whatever backbone was used for!

I appreciate the enthusiasm for Vue. I really do. However, code speaks louder than upvotes ;-). Drupal has backend APIs in place for making this possible. Gather a team. Start a project.

Drupal it's a do-cracry, if you want something in core the best aproach is do-it in contrib and then push to include in core.

I think that the best oportunity to see a vue back in drupal should be to create first as a contrib theme or module.

I bet the greatest starting point is implement Drupal.ajax, autocomplete, tabledrag then inline editing

I think part of the problem with all these "+1" posts is that we don't have a mechanism for users to vote or express their interest in an initiative any other way. Using the "follow" button doesn't really convey that

There is a roadmap.

Step 1, claro is done. So if people want to do a step 2 in Vue.js. It just takes some people who will take the lead and start a new project, communicate about this and find other people who will join and help.

https://www.drupal.org/about/strategic-initiatives/admin-ui-js

I think Drupal's initiatives are not transparent enough. It should not ask or invitation only to join in private to get extra information or make their contribution. Talented developers are busy and shy.

You can get the thing done and very controllable. But your products are standard quality only, or lower than standard. When an alpha/beta enough module released on Core Issues, it's too late to make a change.

Avoiding the echo chamber.

I would suggest to look at https://www.drupal.org/project/ideas/issues/3170260 which outlines a smaller initiative around decoupled menus. https://drupal.slack.com/archives/C016N3HTHRD is the slack channel if you want to tune in.

I was exploring Vue as a replacement for Backbone and made a proof of concept converting the Tour module's use of Backbone to Vue. The patch + more details are here #3145958: [META] Re-evaluate use of Backbone.js in core. It's not entirely clear to me what the proposed use of Vue is here, but my experience with the prototype makes has me thinking it would be a useful library to have in Core even if we're not delivering SPA admin UIs or whatever. It seems like Vue would be a nice library to have around even if it doesn't wind up the library of choice for the full-on modern JS Admin UI experience

Followup on #109
I had previously created a Vue prototype for the Tour module. It was pointed out that Tour's JS use is so simple, it's not a particularly good way to demonstrate the benefits of Vue. So, I created prototype that replaces Contextual's use of Backbone with Vue. This was accompanied by an equivalent prototype that replaces the functionality with Vanilla JS. The prototypes are here: #3145958: [META] Re-evaluate use of Backbone.js in core. Using Vue for these prototypes got me quite interested in the possibility of having it added to core, so I felt it was particularity important to provide a vanilla prototype to facilitate objectivity.

I'd like to be sure there isn't an impression that Vue is still in consideration for decoupled admin UI. React was the selected after significant deliberation, and that decision should be respected. The progress of the React-based admin UI be found here.

Adding Vue to core as a library that benefits our existing Admin UI is something different, and that's something I'd like to look into further. I think Vue could potentially make it easier to remove Drupal's dependency on jQuery, and I can think of several Claro issue I've been working on that would be much easier to address with Vue.
One of my immediate concerns is Vue is not a small library. I'd like to be sure the benefits are either worth the additional bandwidth or if Vue could potentially "pay for itself" by reducing the amount of Javascript needed.

I opened a new issue that also deals with adding Vue to Drupal, but differs enough to warrant a separate issue #3201871: Document benefits/drawbacks of adding Vue as a core JS library

• Much of this discussion is specific to adding Vue as the framework used by the Decoupled Admin UI. The Decoupled Admin UI efforts stopped some time ago and it's unlikely they will resume. The new issue deals with Vue as an addition to existing core JavaScript, not the framework powering an entire new Admin UI concept.
• This issue is full of great information regarding why Vue is a good overall framework. The new issue is looking for ways that Vue would specifically benefit Drupal core. We've proven here that Vue is good. Over there is an opportunity to specify how it would improve Drupal

@bnjmnm coming here 2 years later, I'm wondering if we should close this issue just like #2913321: Proposal to experiment with React for building Drupal’s administrative UIs has been closed?

I'm still 100% Vue (or Svelte) supporter, as both communities are very similar to the Drupal community (bottom up) instead of Reach (top down), but this is a very huge framework decision and the better choice would surely be openness and web standards.

the fact instead of going all in with an open solution like web-components instead of a monolithic Javascript framework such as React seems like a bad idea to me. React maybe cool today, but Drupal has Backbone.js in it now, people thought that was gonna be the thing...

(#212 by @gr8kicks in #2913321: Proposal to experiment with React for building Drupal’s administrative UIs)

So to sum it up, all these libraries are super awesome and Vue and Svelte are more close to the Drupal way in the community perspective, but making the decision for one is really, really dangerous and might be too heavy. So how to proceed here?

OHI @Anybody:

With the inclusion of Single Directory Components (SDC) I believe we have a path to success (that I'm also pursuing for Web components). Assuming you're up to date on what SDC is, let me jump right to Next Steps

Next Steps

1. See if there already exists a "theme" written in Vue either in Drupal contrib or in Vue's larger ecosystem. If not take an existing admin theme like Claro
2. Convert that theme's components into SDC. Make it a Vue component, if not already one.
3. Add tooling to handle npm imports, proper support for Vue development workflows / development expectations
4. Storybook 7 support

I built similar support in a new module I made https://www.drupal.org/project/pokemon_card.

I understand this effort is not a full solution. If we think about solving the problem of creating a Vue-driven admin theme in phases, we can start with smaller challenges and build momentum to completing this. With Drupal 10.1 / 11, support is already there to build components for Vue or any other js framework. Getting that far will help us understand what remains to be solved.

Maybe I'm an outlier, I'd much rather have something that is specifically designed to layer on top of server rendered HTML from the ground up for both reliability reasons and not duplicating what we already have with Drupal's theme layer. The Turbo framework (developed by the people at Basecamp) has been adopted by Symfony, and it's something we on the RefreshLess module want to implement (when I have the time): #3238865: META: Incorporate Symfony UX Turbo Into Module

This may no longer be relevant, Project Browser has been built using Svelte, and so it would be rather strange to have two different frameworks used to build different parts of the admin UI.

@AaronMcHale nothing against Svelte, but is that an official framework choice by Drupal or a (Trojan Horse) point to set Svelte as the Drupal future framework choice through Project Browser?

I'm writing this with a sense of humor, but of course we should take care to not make such an important future decision based on something that wasn't chosen to be the final choice for whole Drupal.

So I'm totally fine with this choice, and it should be communicated and documented officially then, if the choice was made.
But if it was kind of a Trojan Horse through Project Browser, we shouldn't cancel the general choice at this point, but review what went well with Svelte in Project Browser, what didn't and what the other pro's and con's of the options are?

From a technical perspective, I totally agree that it wouldn't make much sense to combine React / Vue / Svelte in one project! But it might be a much more important choice for the future of Drupal than it was for the future of the Project Browser.

PS: I think any of these frameworks is an important but also risky choice for Drupal, as picking the "wrong" framework might lead to huge discussions in the Drupal Community and I guess there are many strong opinions around for all of them ;)
We *might* lose a lot of folks, like we did from Drupal 7 to Drupal 8, in worst case.

@Anybody to be honest I’m not sure how “official” the decision is at this point, but PB is pretty far along so I would be surprised if the decision hasn’t received buy-in from the core committer team.

That said, I was just making an observation, and I know one big advantage of Svelte is that the built JS is vanilla and so the browser only has to download the compiled JS and not a whole JS framework, which is an advantage for those on slower connections or on low powered devices.

Just discovering this too. Seeing how the popularity order of frameworks has been mostly unchanged for years as React > Angular > Vue > Svelte, especially in Drupal where tools tend to be built mostly over React, this makes me fear we are going to have Svelte as that exotic dependency to remove just like we had to remove Backbone not too long ago.

Ha, I've been promoting and using Vue.js for years as a much better, lighter, faster, easier alternative to React. But if there's one JS framework that I see as possibly better than Vue, it's Svelte.

I think React would be a mistake to put in core. If you want reasons, follow Alex Russell -- here's a representative post outlining why the proliferation of front-end frameworks is bad: https://infrequently.org/2023/02/the-market-for-lemons/ -- and see he lists both Svelte and Vue as having the right motivations of putting the end user's experience first, ahead of the developer experience.

Some clearer posts about why: https://thenewstack.io/too-much-javascript-why-the-frontend-needs-to-bui... , https://www.spicyweb.dev/the-great-gaslighting-of-the-js-age/ .

So that said, I would hope that SDCs would support using any of these libraries, and that modules can choose whatever front-end framework makes the most sense to them. That's how this all works, anyway -- the people doing the work make the choices. I'm all in favor of making it easy to make good choices here, and if there is support added for particular frameworks, that choice needs to support goals we all have -- making a great user experience, keep the performance high, stick as close to standards as practical, get wide testing and review before anything happens that might make it exclude other approaches...

To clarify things a bit, svelte has been approved to use in project browser more than 2 years ago when the implementation was getting started, see #3263443: Consider removing SvelteJS in favor of vanilla JavaScript. This is not meant as a way to encourage people to use svelte or even add more svelte to other areas of core. PB is self-contained (in the UI at least) so we could choose whatever got the job done.

Svelte is an implementation detail of the PB feature, not a building block of the Drupal framework. So the situation is closer to what #118 outlines (except I'm less pessimistic about it :p)

In terms of popularity gauged by Github stars, Vue.js and React are neck and neck, but Svelte is doing fine.

• 215K React (Facebook)
• 205K Vue.js
• 92K Angular (Google)
• 74K Svelte

Made with https://codetabs.com/github-stars/github-star-history.html (It looks like data points stop after a set number ...)

@ressa
The 205k Vue.js is for Vue.js 2

Vue.js 3 has also 41k stars
https://github.com/vuejs/core

Thanks for the clarification @nod_

@freelock provided some really good links there in comment #119, I think the performance and amount of data that a framework results in being sent to the client is a really important consideration.

The other thing I find interesting about the discussion of whether Drupal should adopt some kind of JS framework for the admin UI is that Drupal has a pretty good Ajax system that works nicely with the render and form API, which Views uses. So in theory, there's no reason we couldn't just use that for more parts of the admin UI. That would also allow us to continue to use server-side rendering (which apparently is the new buzzword these days 😔), resulting in a consistent way of building blocks/Views/theming/forms/controllers/etc for the front-end site and the admin UI. I'd worry that if the end result was a completely different way of doing all-of-the-above-mentioned-things for the admin UI than the front-end site, we'd end up with a poorer user and developer experience overall. I understand there are big advantages to a framework, but there's definitely something to be said for using something that already works with Core and is well integrated.

Thinking mainly about the user experience here, one of the hurdles with PB was that we ended up with a separate breadcrumb trail for the Svelte app which was disconnected from Drupal's breadcrumb trail. Now, those are challenges we could overcome if the whole Admin UI was a JS app, but it's something to consider, especially in any intermediate step where only some parts of the UI are built using JS.

@AaronMcHale I agree that based on the discussion above and the many good points given to keep Drupal neutral from these techniques. And it might be best to close this issue at this point.

If one day the time will come that Drupal has to make this decision, it will be a very hard and controversial one, and I don't think we'll ever be able to find a final result in this issue.

And if we would, there are still more important people than us to decide this finally? ;)

The worst that can happen is in my eyes, that Acquia, Dries or whoever decides this, does it without the community! Hopefully Drupal can just stay agnostic from this and let people solve their needs in contrib.

I would second @Anybody in recommending we close this (or postpone it maybe?).

We're probably better off focusing the discussion on something (hopefully) less controversial, like web components, that might be a more natural path at this point:
#2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering)
#2914759: Proposal to use Lit / web components for building Drupal’s administrative UIs
#3230518: Figure out how we want to incorporate web components in Drupal 10
#3230518: Figure out how we want to incorporate web components in Drupal 10

As a closing remark, I think going forward any conversation like this needs to be framed around what is the actual problem that we're trying to solve, and then considering what the best tools are to do that, focusing first on the user experience. This issue feels a bit lacking in that regard.

I would think it's fine to close this, I'm not hearing any substantive disagreements here...

To clarify, the one thing I would not want to see is adopting some big heavy framework that forces us all into a particular way of doing things -- e.g. React.

I'm all for webcomponents, single-directory components, Svelte and Vue and whatever other components people would like to build in -- I think most of these can coexist and/or complement each other. Let each module choose what's best for their needs -- generally more of this can be done using vanilla js and native browser functionality, keeping the JS layer lean and mean.

I do think there are many admin user stories that would benefit from a rich client layer, though, and I personally greatly prefer JSON:API or a simple JSON endpoint over Drupal's Ajax layer...

101% agree with @freelock and @AaronMcHale and find it interesting to hear, that most of us agree with "React would not fit Drupal" ;D

But let's not restart this... enough said. I'll set this "Postponed" as I can't see which of the "Closed"-status would really fit.

Postponed sounds good.

I might also go with “Closed (won’t fix never ever ever)” but that might just be me 😂

I'm just skimming the recent comments and wanted to also throw my proverbial hat into the pile for reusing what we already have, i.e. Drupal's theme system, etc. On that topic, and as a follow up to what I posted about previously: I actually have a basic implementation up and running in #3393105: Hotwire Turbo minimum viable implementation which layers on top of Drupal's existing server-rendered HTML to progressively enhance it into something that feels like an SPA. I need to record an updated video, but it already plays nicely with Drupal core's Ajax framework and other things. If you want to help out, we need to refine the implementation somewhat and add a bunch of functional JavaScript tests.

Just to leave a note here, a better option for Drupal instead of Vue, React and Svelte might be HTMX to simplify the AJAX part of Drupal that has been quite complicated ever since.

That might also end the "framework war" ;) between Vue, React, Svelte for Drupal, as it might just fit a lot better by design.

HTMX should not be seen as "just another React, Vue, Svelte". but a really different and lightweight concept! When reading about it (and I love Vue and Svelte and will do so) I thought "whao, this could potentially simplify reactivity / AJAX in Drupal a lot!"

If anyone agrees, we should also discuss that, a separate issue should be created and answer the question: "Which problem does it solve" first! :)