Vue.js is the pragmatic choice for much of UI development

There’s certainly been no lack of radical ideas and libraries for UI development in JavaScript for the web.

Some of these have already started to fade away, with efforts such as AuraJS, Knockout and others falling to irrelevance. Angular and React have been the top-of-mind options, but Vue.js has been making strides in adoption lately.

Similar to React, Vue is essentially a component based view layer. In it’s recently released 2.0 major version it gained performance, some interesting new developer options like using the JSX syntax from Facebook and more. But most importantly it kept backwards compatibility changes minimal, so projects already using it could adopt the new version easily.

The backwards compatibility take underlines one key strengths that the Vue.js project has: a practical approach to real world projects. While the React ecosystem started from a very practical approach, it has quickly grown into an arena where things change constantly and the churn is enormous.

It is not React itself which is volatile, but the user base tends to be very bleeding edge and always going for the latest and greatest additions. This leads to some truly elegant solutions, maybe… but in many cases they’re not very practical for longer living projects. If you’re doing a short living project or something that is very limited in scope, it’s ok.

For larger teams working on longer term projects, a complete opinionated framework like Angular 2 can be a better option. Instead of needing to choose individual components, a complete toolkit is dictated by the framework. While pieces can be swapped, it is unlikely that someone will replace the routing component in Angular 2 projects for example.

A complete framework translates into longer term stability, but also some annoyances over how the framework was architected. In many practical projects there is room for something that’s in between of precision tools like React and “enterprisey” things like Angular 2.

This is where Vue has carved up a niche of it’s own. It is simple to adopt as a part of an existing project, many of which are CMS driven sites where some interactivity is needed, not necessarily a full blown decoupled CMS implementation. And it’s drop-dead simple to get started with.

You could go out and say that Vue.js is the modern day jQuery. It’s not the sexiest option out there, but it gets the job done well and is very easy to get started with. And now it’s got critical mass to give it staying-power.

Vue.js is the modern day jQuery

A true testament to the ease of use of Vue.js is that it has been selected by prominent open source projects as the front end UI development library of choice. From the comment from the Laravel framework lead on how low the barrier of entry is:

Current React learning status: overwhelmed. Learning @vuejs because it looks easy and has pretty website. 👍
-
Taylor Otwell

to adopting it as a recommended UI library in the popular PHP framework took only a bit more than a year. And Laravel is not the only project. Just yesterday the prominent startup GitLab announced that they’re going to use Vue.js for UI development. The reasoning behind this is similar to Taylor Otwell’s:

When I joined, all the JavaScript was written with jQuery. There is nothing wrong with that, except that it takes a lot more code to solve every problem. We knew we could do better. Once we started with Vue.js, we could immediately and consistently solve complex problems in much less time.
- Jacob Schatz

The key here is that they’re moving from jQuery to Vue.js. And it is simple and straightforward for them to do so. With both React.js and Angular 2 you’re easily sucked into a rabbithole of build tools, new shiny libraries and so forth.

This distracts you from what you actually needed to accomplish and could be pushed to the category of the notorious premature optimization:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
- Donald Knuth

So instead of trying to squeeze the last bits with Webpack from your package or to optimise the use of the Flux store of your choice. All for nothing if your traffic is limited to people with good connections and you’ll actually ever have a maximum of 1000 objects in your store. Raw execution speed is often secondary, as is minimising the number of HTTP requests (especially since HTTP/2) as is the fact if your JS payload is 30KB or 60KB.

Instead of optimising for technology, you should optimise for developers. Make it as sane and easy as possible for the next developer to pick up the work and be productive. With the current convoluted stacks that require complex build steps and grasping some rather academic concepts is simply not the case. A large majority of the web does not need all of this. At all.

There are places where a complete React.js or Angular 2 app is absolutely the tool you should use. But the next time you’re looking to add some interactivity to a content driven website, consider if all the complexity you’re adding is actually worth it. Does it add any value?

You might not need React.