At DrupalCon Vienna, Dries proposed a new strategic initiative to test and research how our admin UX could be improved by using a JavaScript framework. As a first step, we have to choose which JavaScript framework will be used as part of the research.

Proposed resolution

At DrupalCon Vienna, Core committers, all of the JavaScript subsystem maintainers, the Project Lead, as well as developers with real-world experience building decoupled applications using Drupal’s API’s agreed:

  1. Adding a JavaScript framework to Drupal core now is a good idea.
  2. We need to continue researching this before making a final decision.
  3. We want to have sufficient real-use experience to make a final decision prior to 8.6.0’s development period (Q1 2018).

Additionally they decided React would be the preferred solution #2913321: Proposal to experiment with React for building Drupal’s administrative UIs however there has be a strong opinion with some users and developers that Vue.js meets these criteria and would be a better option. The library does not seem to be up for debate in that issue so this is as alternative approach to meeting those requirements.

Proofs of concept

  1. written in Vue by @Chi

Benefits of Vue.js

Growing vibrant ecosystem.
Great documentation.
Approachable my novice's, React developers, and Angular developers alike.
Designed for incremental adoption which will allow Drupal to ease in to decoupling its frontend.
Other big projects, Laravel, Gitlab, Pagekit.
Industry adoption Alibaba, Nintendo, (
Never had a license concern?
Frontend development and career.

Vue growth stats[?]:

NPM downloads: 1,943,567 total, 1,531,217 YTD (up from 382,184 in 2015, +300%)
Core repo GitHub stars: 37,664 total, ~26,000 YTD (up from ~7,600 in 2015, +240%)
Core repo Pull Requests merged: 350 total, 258 YTD (up from 70 in 2015, +268%) page views: 21,424,759 YTD (up from 3,761,728 in 2015, +470%) monthly active users: 358,405 (up from 77,836 in 2015, + 360%) Side note: 42% of user sessions are from China.
Chrome DevTools extension weekly active users: 84,098 (no prior year stats)


Vue.js's release cycle is not tied to our so is likely an issue similar to Reacts.
Decoupling could be an issue but should be limited by Vue.js's approach and could be developed piece meal through multiple releases. Gitlab's approach would be a bit of a roadmap.

Getting started

Vue.JS is a JavaScript library for building user interfaces.

Next steps

Probably similar to the React issue:

Gauge community interest, and flesh out any hard blockers (this issue)
Replicate a “proof of concept” project—Database Logging UI—in Vue.js, to give the core team real-world experience developing Drupal core features with Vue.js.
Identify changes to our supporting infrastructure, e.g. do we need new/changed build tools for packaging, testing infrastructure, etc.)
Research release cycle and develop a plan.

Your feedback

I think the framework war is mostly flamed out in other issues. I think both issues probably need to focus on how to move forward to best demonstrate the technologies and identifying problems and blockers.

A precaucious note from the Vue Maintainers:

  1. Please only comment in those discussions if you have some meaningful argument to contribute. Don't clog them with useless "I vote for Vue" comments or something similar. That won't help use in any way.
  2. If you intend to critizise React, do so in a fact-based and civil manner, and argue for Vue rather than against React.
Members fund testing for the Drupal project. Drupal Association Learn more


neclimdul created an issue. See original summary.

galactik’s picture

A curated list of awesome things related to Vue.js

Comparison with Other Frameworks (from Vue authors)


Vue Router

Server Side Rendering + NUXT.JS

Vuex (~Redux):

Electron & Vue.js


Weex (Cross mobile)

An experience using Vue with Drupal: «Why we chose Vue.js over React»

adubovskoy’s picture

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.

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

cilefen’s picture

Project: Drupal core » Drupal core ideas
Version: 8.5.x-dev »
Component: javascript » Idea
Category: Task » Plan
Related issues: +#2913321: Proposal to experiment with React for building Drupal’s administrative UIs
nod_’s picture

Issue tags: +JavaScript
webchick’s picture

Title: Proposal to use Vue.js for building Drupal’s administrative UI’s » Proposal to use Vue.js for building Drupal’s administrative UIs

Just your friendly neighbourhood grammar police. ;)

effulgentsia’s picture

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.

Chi’s picture

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.

Chi’s picture

Issue summary: View changes

I suppose it should be about Vue.js

sarathkm’s picture

Check out comparison between VUEjs with various other JS frameworks

ivanjaros’s picture

sarathkm’s picture

Round 6 evaluation by Stefan has great evaluation for different JS latest framework

And another great company that uses VUE is Baidu

List of awesome VUE contributions that can be used

tonystar’s picture

+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.
tonystar’s picture

Help me to involve Vue.js Team:

Artnetik’s picture

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

davidhernandez’s picture

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.

tonystar’s picture

Issue summary: View changes
thamas’s picture

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?

Chi’s picture

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.

tonystar’s picture

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

Chi’s picture

@tonystar, its referenced in #8.

tonystar’s picture

Issue summary: View changes

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

cfbauer’s picture

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.

segovia94’s picture

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.

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>
{% 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.

jwilson3’s picture

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

jwilson3’s picture

yohannca’s picture

+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, and also a new test utility

hoter’s picture

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 ( allows to divide HTML, CSS and JS, but nevertheless they will be in one file.

fishfree’s picture

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

andrewmacpherson’s picture

@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.

pthurmond’s picture

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 ;).

rumblestrut’s picture

Vue has my vote.

pthurmond’s picture

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?

webchick’s picture

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.

freelock’s picture

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

neclimdul’s picture

Issue summary: View changes

@webchick I added some stats from Vue.js' 2016 run down. Not included is this cool stat:

Trivia: Vue is now the 10th most starred JavaScript project on GitHub, and is the 3rd most starred among all projects in 2016 (1st if excluding non-source-code projects).

As far as current stats all the github stats are pretty close to React, when I checked React was trending at 16 and Vue at 17. React's downloads from npm are insane but Vue.js has like 200k per week which is more then all of the reporting d8 sites so pretty respectable. I'll leave a real comparison to the review process.

lauriii’s picture

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
  • 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.

metalbote’s picture

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

ressa’s picture

Google trends

Vue.js recently overtook React in Google Trends:

Google trends React vs Vue.js Oct. 2015 Oct. 2017

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.

Github star trends Oct. 2017


segovia94’s picture

@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 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 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

aleksip’s picture

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?

thamas’s picture

@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."

Chi’s picture

I just remembered another example of Vue in Drupal.
#2828882: Add REST application 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.

REST Application DBlog UI
Vue version 2 1
Backend REST resource Custom controller
Data Custom table watchdog table
Operations CRUD Read only
ES6 Yes No
Filter On matching string Dropdown
Table sort No Yes
Pagination No Yes

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

Andrej Galuf’s picture

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.

yyx990803’s picture

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.


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.


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.)


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.

Niklan’s picture

+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.

cosmicdreams’s picture

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?

attiks’s picture

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

neclimdul’s picture

Thanks Evan! I've tried to sort out a good way of stating several of those points like the talent metric clearly and I'm glad you did. The development process/graph insight is great to know.

Another point I've been considering is that Drupal seldom forces anything on developers. It seems likely investigating and investing in multiple frameworks at the same time will lead us to a solution that, while one may be adopted in core's admin interface or even core themes, other options can be swapped in with minimal effort. The old "three implementations" metric only makes Drupal as a content repository stronger.

effulgentsia’s picture

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!

elstudio’s picture

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

The 8.x-2.x branch has the Vue 2 code:

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.

ressa’s picture

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

tacituseu’s picture

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 ?

Andrej Galuf’s picture


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.

Chi’s picture

@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.

effulgentsia’s picture

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.

effulgentsia’s picture

Specifically, I'm curious if:

It also returns options for a filter.

is supported by JsonApi or not.

MiroslavBanov’s picture

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:

Specifically the picture at the bottom is worth a thousand words:
Only local images are allowed.


Andrej Galuf’s picture

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

webchick’s picture

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 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:

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

effulgentsia’s picture

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.

elstudio’s picture

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.

effulgentsia’s picture

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, 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.

dawehner’s picture

You can easily use a view for this purpose: 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.

Chi’s picture

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' => [
  '#data_callback' => '::getRecords',

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

freelock’s picture

+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.

cosmicdreams’s picture

@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

dawehner’s picture

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

fgm’s picture

Just noticed this: : 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:

aleksip’s picture

reinchek’s picture

Mingsong’s picture

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,

segovia94’s picture

Issue summary: View changes
Dublin Drupaller’s picture

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:
mature community,
easy to learn.

effulgentsia’s picture

@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.

d_f’s picture

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

Dublin Drupaller’s picture

@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".

fadonascimento’s picture

+1 for Vue
-1 for React

ehmprah’s picture

+1 for Vue
-1 for React

MarkoC’s picture

1+ Vue.JS!

taivu’s picture

Vue +1!