Gutenberg: A Change of Vue?

If you haven't heard the news already, Matt has decided to move Gutenberg, the new WordPress editor, off of React, over people's reaction to the recent response from Facebook's legal team.

Some parts of Facebook's response seem odd, but I also have no idea what the legal landscape is like for one of the largest most publicly visible companies in the world. I don't think there is malicious intent in React's licensing, but at the same time I think it is a wise decision from Matt to ease growing tension in the WordPress space over the use of React in Gutenberg. Any company, organization, or project that feels wary of taking on the legal uncertainty surrounding React, is a project that would no longer be able to use WordPress; an unfortunate price to pay for using React.

What's next?

It is not clear what will be chosen as the replacement for React, and in many ways I wish React did not need to be replaced, because it is awesome. Vue seems to be the chant ringing through all channels of the WordPress community. I have been meaning to learn Vue. The recent news was the final push. After I finished up my tasks Friday, I jumped straight into Vue. It took me very little time to get Vue running, with Vuex to boot, to create a todo list app. It took about two hours. Vue is great! Magic! I can definitely see why people love it. In many ways Vue is solving the same problems React solves. There are many similarities between Vue and React, but also many differences, and many misconceptions the WordPress community seems to have about that relation.

I did not fully dive into Vue yet, by trying out routing etc., but through a cursory glance, Vue Router seems A LOT better than React Router. However it is important to note that with the way React works, React Router is not a good choice, and instead I would recommend Redux First Router, if you are using Redux. If you are purely using React, godspeed. There are many things I haven't tried out yet in Vue, but I think I have a pretty good grasp of it, and here is my take on its differences with React, and how that could potentially impact Gutenberg and the WordPress ecosystem.

Potential of Vue

Claims about Vue from the WordPress space

1. Vue is easier to learn.

One of the reasons I think Vue is regarded as "easy to learn" is that you can write out UIs with a template syntax similar to HTML and make use of "directives" to accomplish things like conditional rendering, rendering lists, and much more without touching any JavaScript. That is definitely very cool, and could be useful in the WordPress space to help developers ease into front end development using JavaScript.

The template language for Vue is really cool. It is all valid HTML, so you can create a Vue template as HTML, then simply instantiate Vue on the root element. This is really cool and lets you get up and running instantly. Most template languages however, become additional overhead on top of learning a core language, and in the long run are probably not very useful.

All of the templates you create in Vue are transformed into "render functions". This is what I ended up using in my todo list app, as this approach was more familiar to me. From what I can tell in Vue, there are five main ways to create your Vues: html files using vue templates, template strings, .vue files, x-templates, and render functions. All of these break down to just render functions, and you could even write your own template language to compile to these render functions, if you really wanted. Custom compiling is how Vue offers JSX support, same with React.

Here is a quick look at the Vue Syntax vs. Custom Rendering functions.

Vue template syntax, using ES6 template strings: ( the ` ` )

Vue.component( 'my-list', {
  template: `
    <ul v-if="items.length">
      <li v-for="item in items">{{ }}</li>
    <p v-else>No items found.</p>
  props: [ items ]
} )

and now a custom render function:

Vue.component( 'my-list', {
  render: function ( h ) {
    if ( this.items.length ) {
      return h( 'ul', function ( item ) {
        return h( 'li', )
      } ) )
    } else {
      return h( 'p', 'No items found.' )
  props: [ items ]
} )

The Vue template syntax is more concise, but you can only use a limited set of JavaScript in it. To get flexibility out of the template system, directives like v-if and v-for are used. In the render functions approach, much like React, you can use whatever JavaScript you want. Using JSX in Vue, like React, may provide a more condensed "easy" to read template syntax, that won't limit your use of JavaScript.

Once you start using render functions in Vue you might as well be using React. They are very similar at this point, to the point where it is almost staggering. So why would Vue be "easier to learn" at this point if React was already deemed more difficult. I think the argument is that you get a nice ramp up in Vue, whereas React expects you to make the leap from HTML templating right into JSX, and build processes galore.

The reality though is that you will eventually hit the same wall you would have hit while learning React, so it is hard to argue it is truly "easier" to learn it, because there is honestly much, much more to learn in Vue. In fact, because Vue does so much more than React, I would argue Vue is more difficult to learn, because you have so many more options on how you want to configure your use of Vue. React: you learn once and use anywhere ( their slogan ). Vue: learn multiple ways to use Vue and use some of those methods in different contexts for different situations.

2. Vue is simpler than React

I could not disagree more with this after using Vue. Vue's API surface is much larger in comparison to React, but this is not necessarily apparent. React takes a purist approach that only focuses on doing one thing, and doing it really well. React's primary objective is to keep your UI in sync with your data. It accomplishes this with minimal headaches, by using a declarative API, and component based structure. You do not need to worry or care about anything else in React aside from, providing data. Vue takes care of UI sync and then some.

Out of the box Vue offers a lot of really useful tools in addition to the more bare bones approach of React. Vue supports different templating approaches, animations, component slots, and is more loosely based on the upcoming W3C web components spec.

There are some very subtle differences in the Vue API approach vs the approach taken in React. The main export object Vue, is actually a stateful object, whose state ultimately affects the rendering functionality. Where as the approach taken in React, the main export React serves as more of a namespace for all of React's utilities. React's internal state is handled inside a black box we cannot touch, which is a good thing.

Typical Vue:

// Some HTML
<hello-wordpress id="app" />

// Some JS
Vue.component( 'hello-wordpress', {
  template: '<p>Hello WordPress!</p>'
} )

new Vue( {
  el: '#app'
} )

Typical React:

// This would usually be JSX, but not gonna use it.
const helloWordPress = () => React.createElement( 'p', {}, 'Hello WordPress!' )

ReactDOM.render( document.getElementById( 'app' ), helloWordPress )

Vue, once again, is slightly more concise. With the additional conciseness comes additional hidden complexity. Any reference to the root Vue instance could be used to override or goof up whatever Vue is doing. There is even an API used to interact with the main Vue instance after instantiation. In a project like WordPress where people often do whatever they want and write very yolo code ( me ). This unbounded extensibility could be a bad thing. React has only one way to extend itself; through creating and composing more components, which is simply how you use React.

In Vue you can create custom directives, components, mixins, many other customizations, all of these changes will need to happen before Vue instantiates, causing a time dependency. React, at the beginning, did similar things but the React team moved away from mixins etc. and instead started to reduce their API surface, taking a minimalist library approach.

3. React is potentially more flexible and powerful than Vue.

This is something I assumed would be the case. Flexible and powerful have ill-defined meanings in coding, but after taking Vue for a spin, I would have to argue that it is more powerful and flexible than React. However, the ways in which Vue is more flexible, are not necessarily always a good thing, and the ways in which React is more flexible, in the long run are most likely a good thing.

As said before, there is one way to do things in React, and many in Vue. On the surface this seems to be an aspect in favor of Vue. However, what happens if we need to switch off of Vue for some unforeseen reason in the future? Well it will certainly be much more difficult than the switch off of React is going to be. The fragmentation in the way Vue can be used will make an eventual departure away from it very difficult, and even while it is adopted there will probably be multitudes of conflict prone situations in an ecosystem like WordPress. There will certainly be much more technical debt accumulated by using Vue compared to React or Preact, but maybe that is not totally a bad thing.

If a strong commitment was made to Vue, maybe its additional feature set would be ultimately more useful than whatever technical conflicts could potentially arise out of the use of Vue. I got Vue up and running no problem, and someone who is new to the JS world could really do a lot with x-templates in a short amount of time. Vue and React, in my experience, from a purely productivity centric perspective, are major steps up from using jQuery and Backbone, when creating non trivial interfaces. Some of the additional syntax Vue uses in its template language make it really, really quick to get something up and running.

Is Vue the right fit for Gutenberg?

Not that my opinion matters or has much weight to it; I would have to say no. That is not a hard no by any means, and if Vue is chosen I will be happy. Vue is awesome and has many benefits, but for what Gutenberg is trying to achieve, I am not sure Vue is the ideal choice. I really have no idea what the ideal choice is to be honest, so, to wrap up, I will outline what is truly good about Vue, and what is not.

Why Vue could be the best fit

  1. It seems to have a lot of support from people in the WordPress community.
  2. It honestly does have a shorter learning curve for getting started. This is not something to be discarded, as I originally had thought.
  3. Productivity in Vue is great, but I haven't used it enough to know what walls are lurking in more complex uses of it.
  4. The Vue community is not currently larger than React's, but it most likely is larger than Preact's, and most of the other contenders'.

Why Vue might not be the best fit

  1. The vast ways in which Vue can be used, could further fragment WordPress.
  2. Although the initial learning curve is tame, the more advanced uses of Vue appear more complex than using React. There is also a considerable amount more to learn in Vue than React.
  3. Due to the nature of Vue's architecture, integrating with other libraries like TinyMCE ( a fundamental aspect of Gutenberg ), might be more difficult.
  4. Extensibility will probably be more challenging to implement in Vue as it further abstracts away from the core JavaScript language.
  5. Vue's divergence from the pure library approach, makes it a significant amount of extra technical debt to bring into Gutenberg.

That's five to four, Preact clearly wins. Just kidding. I do think Preact would be the most sensible choice though; speaking from a technical perspective. It is important to understand that the library chosen will not impact plugin/theme developers nearly as much as those who are contributing to Gutenberg/WordPress Core.

There are many efforts underway to allow custom blocks for Gutenberg to be written in just about any kind of JS you like. The choice of the library will have implications for WordPress developers though, because it will definitely make sense to use the same library, but it is important to understand that you are not being forced to use whatever library is chosen.


Yeah, this was a long post. Vue is really cool, I am enjoying it a lot, but ultimately I do not believe it is the right fit for Gutenberg, because despite what people assume, it carries more technical debt than a library similar to React does. The funniest part of all this debate is that realistically all of the options are quite good and phenomenal in their own way, so it is really hard to be certain that one option is better than the other.

I hope you stay tuned for more Gutenberg related content. I have some really awesome stuff that I will have ready soonish. I think Gutenberg will open up lots of opportunities beyond what WordPress, or anything for that matter, has really done before. Follow my blog if you want to keep up with Gutenberg related content, and see where the future might lead! I hope the original negativity that clouded this project will begin to fade and people will rally behind this project and support the Gutenberg team, who have been doing truly phenomenal work!

Falling Short — WP GraphQL

Hi everyone! I set a ridiculous goal of trying to have WP GraphQL be production ready before the new year. I knew it was not attainable but sometimes when you set something ridiculous you can really motivate yourself to complete it. A lot of progress was made on WP GraphQL, but it is still very far off from production readiness. I think by late June 2017, WP GraphQL will actually be ready, given the same level of work being steadily put into it. The holidays were great and were a necessary refresher for heading into the new year. What’s left to finish off WP GraphQL 1.0.0?

Roadmap, where WP GraphQL is at.

Version 0.1.0 will mark the completion of the initial type system.  What is the type system? The type system in GraphQL defines what can be done in GraphQL. In WP GraphQL there needs to be a type system to support posts, comments, pages, menus, plugins, themes, sites, networks etc… Not only does the type system need to support each basic WordPress type, but fields within each type may have a type themselves. For instance any field that is a url is not just a string but a special url type. Laying the foundation of the type system is the bulk of the work that needs to be done. Currently WP GraphQL almost supports every default type of content laid out in WordPress.

WP GraphQL version 0.2.0 will focus on improving the architecture of serving GraphQL requests. Currently the code to serve a GraphQL request is very ad hoc and sloppy. Improving the design of serving a GraphQL request will enable the ability to start improving the extensibility of WP GraphQL.  Version 0.2.0 will also focus on making WP GraphQL Relay compliant. WP GraphQL version 0.3.0 will focus on locking down the API and making it secure, support authentication, and respect the privilege system of WordPress.

What’s Next?

After this is done WP GraphQL will be production ready. At this point it should be determined whether mutation queries (create, update, delete) should be shipped before or after the 1.0.0 release.  The current goal is to provide a read only GraphQL API as that is where GraphQL really shines.  I think the way REST is structured, makes it alot better suited towards updating, deleting, and creating resources. WP GraphQL, in the future, might just wrap its mutation queries around the WP REST API.

I look forward to seeing how WP GraphQL shapes up over this year, and hopefully more people will want to get involved as well! If you would like to learn more about WP GraphQL head over to the GitHub repository and introduce yourself.



A new year; WordPress & GraphQL

Excited about WordPress!

Hi everyone! I am really pumped after watching this year’s State of the Word.  If you haven’t checked it out yet, then I suggest heading to the WCUS Live Stream and watching it.  WordPress is really cooking and I think it is only going to get better.  I really feel like WordPress is going to a new level this coming year, and I can’t wait to get involved and see how things shape up.

Now what does this have to do with GraphQL and WordPress?  With my energy level set on high right now, I am going to make a crazy deadline and try my best to make it happen.  I want to have WP GraphQL be ready to use on production sites by the new year.  What do I consider production ready?

  • Cover as many WordPress content APIs as possible.
  • Offer secure authentication methods, with proper privilege checking of fields.
  • Provide an easily extensible architecture.
  • Provide a documentation site that covers the above items.

Although WP GraphQL already features a lot of ways to get data, WP GraphQL is way behind the WP REST API in areas concerning authentication, security and permissions checks and extensibility.  These areas need to be on point for anyone to consider WP GraphQL ready to use on a production site.  So what’s the plan?

The Plan

Every day until December 23rd, I will resolve at least one issue of WP GraphQL. After Christmas, I will then do one issue or more a day.  I honestly think with this steady investment, WP GraphQL can be in a really great place over the course of December.  Daily contributions may be made for the documentation site or the codebase; maybe both! I am probably crazy to think that it can be completed so quickly, but I am going to try.

So if you are excited about using GraphQL with WordPress keep your eyes out on the WP GraphQL repository. What do you think will make WP GraphQL production ready?


WP GraphQL Documentation Site

The beginning of the Documentation site for WP GraphQL is now up.  I am very excited to have this running.  To contribute to the documentation please head over to the WP GraphQL documentation repo, it is synced to the GitBook.  Feel free to open any issues if you have questions about the documentation or about WP GraphQL


Currently, WP GraphQL will be using GitBook for the documentation site. I think GitBook is a sensible choice for right now.  Eventually, the goal is to have the documentation site running on WordPress (maybe even powered by WP GraphQL!). For now GitBook is quick and easy to set up, but lacks some extensibility power.

If you are interested in learning about GitBook, check it out!

Documentation Goals

The next step for vastly improving the documentation will be to have a cookbook for common WordPress related GraphQL queries. The cookbook queries and tutorials will go straight into the Gitbook for easy access.

Another priority for this project is to create a reference WordPress site running WP GraphQL with some demo data for people to mess around with.  This will involve purchasing a decent domain name, setting up WordPress with dummy data, and possibly running an Express server alongside it for GraphiQL support. The reference site will use the GraphQL introspection system to enable automatic viewing of WP GraphQL’s type system.


I am really excited about this project and hope you will be too.  Let me know what you think of the documentation site so far, and what could be better!

WordPress GraphQL

Hi everyone! Love WordPress? Interested in GraphQL?

There are many projects starting to creep up to push GraphQL support forward for WordPress.  I will be throwing my hat into the ring as well, because I feel it will greatly expand interest in WordPress and provide some awesome functionality to it.  Today I started up a plugin that will provide a GraphQL API for WordPress.  Head over to GitHub to check out WP GraphQL!  I am incredibly excited about this project and hope you will be too. Hopefully, we can build something amazing together!  If you are interested in contributing, go to the GitHub repository linked above and comment on this issue and introduce yourself; feel free to post any questions you might have as well.  I will get back to you as soon as I can.

What is GraphQL and why does it matter?

GraphQL is a new specification, created by Facebook, that can be used to create an easy way to reason about your application. One of its biggest strengths lies in the ability to specify exactly what you want client side and have it be taken care of in one request! This makes matching data to what you need in your UI much, much easier. Lets look at a made up example.  Imagine we are going to make a single post view for a WordPress site. A GraphQL query might look like this:

  post(id: 7) {
    author {
    comments {
      author {

You would send this as a string to the GraphQL API endpoint, and in return you would get JSON data giving you the post title, content, author name and gravatar for post number 7. You would also get back a list of comments for the post each with their matching content and author’s name and avatar. It is probably more clear why potential GraphQL queries are so powerful. You can declare what you want client side and bring the JSON data you need into whatever language you want to use. When work on WP GraphQL is further along, I plan to use it for a lot of JavaScript based projects!

More to come in the future!

I am just overwhelmed with excitement about this project and hope that you will feel the same.  Don’t be intimidated by something new. I strongly encourage you to try and contribute to this project. I will personally try to help as much as I can.  We will both be learning GraphQL alongside each other as we go; which should be awesome!

Let me know if you are excited about bringing GraphQL to WordPress as I am!  If you are having trouble installing the plugin open an issue on the WP GraphQL github repository.