The year of 2015 has been a pretty crazy ride for Vue.js. The project has grown way beyond my expectations, so I’d like to take a look back and put things in perspective.

Stats

General

• NPM downloads: 382,184 ytd, ~52k/month current
• GitHub Stars: 11,357 current

Unfortunately Bower and CDNs do not offer download statistics - there should be at least equal if not more usage from these sources, since a considerable portion of Vue.js users use it for non-SPA purposes and pull it directly from a CDN.

The GitHub star count saw a whopping 7.6k+ growth since February. In comparison, the project collected a total of ~3.6k stars in its first year (Feb 2014 - Feb 2015).

Repo Activity

• Releases: 54 ytd (from 0.11.5 to 1.0.12, including alpha/beta/rc releases)
• Commits: 1,023 ytd
• Issues Closed: 1,014 ytd
• Pull Requests Merged: 69 ytd from 43 contributors

Vuejs.org

• Page views: 3,761,728 ytd
• Unique visitors: 363,365 ytd
• 30 Day Active Users: 76,090 current

Highlights

Adoption in the Laravel Community

It all started with this…

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

— Taylor Otwell (@taylorotwell) April 20, 2015

Taylor Otwell, the author of Laravel, picked up Vue.js instead of React as he was searching for a new front-end library. Soon afterwards Jeffrey Way created a screen cast series on Laracasts which popularized Vue.js in the Laravel community. Today some of the most active Vue.js users are from the Laravel community and there are really cool open source projects like Koel built with the two technologies combined.

Shipping 1.0

1.0 was some really hard work: careful considerations had to be made on what to deprecate, and there was lengthy, heated discussion around the template syntax overhaul. But in the end I believe we ended up with something most of us are happy with. With the goal of providing a painless migration path, I’m also quite proud that I was able to provide 1.0 builds that are fully backwards-compatible with deprecation warnings.

The release of 1.0 was a great boost to the project’s adoption. The release post stayed on HackerNews front page for quite a while, gathering more than 300 upvotes. The GitHub star count surged, and Vue has stayed in the GitHub JavaScript trending list almost every day since then. In Google trends, the curve for Vue.js is showing strong growth and recently surpassed Backbone and Ember.

Growing Ecosystem

In addition to Vue.js core, we now also have a whole suite of official libraries/tools that help with building larger applications:

• vue-loader and vueify for component-based build workflow;
• vue-router for routing in SPAs;
• vue-devtools for live inspection and debugging;
• vuex for explicit state management in large scale applications.

Of course, there are also many awesome community contributed projects - a big shoutout to the community for sharing what you’ve built!

Podcasts!

I did a bunch of podcasts this year, mostly talking about Vue.js. These podcasts touch upon some pretty in-depth topics about Vue.js, so if you are interested about the nitty-gritty details, they are probably worth listening to!

• JavaScript Jabber
• The Changelog
• Fullstack Radio
• Teahour.fm (Chinese)

Reflections

The Progressive Framework

People often ask me how Vue.js compares to other frameworks. There are of course a lot of technical details, but I’ve talked enough about them in the podcasts. The more fundamental question is why does Vue.js exist and what purpose does it serve. To be honest, I often asked that question myself - especially when almost everyone is talking about React in 2015. But despite React’s dominance, there are still a lot of people liking and using Vue.js - in fact, more and more of them. Every few days I’d get a Twitter mention about how Vue.js has made someone’s life easier. This makes me believe that Vue.js is filling some right gaps in the world of web development.

The web is extremely versatile and the web developer population is immensely diverse. From static content sites to complex enterprise applications, people use and build for the web in drastically different ways. Every solution comes with tradeoffs for the specific type of problems it is trying to solve. For example, when trying to manage the inherent complexity of large scale applications, fully-opinionated frameworks often introduce non-trivial accidental complexity in terms of architecture, concepts and tooling, which renders them cumbersome for simple scenarios. On the other hand, when stitching together micro-libraries to handle large scale apps, the amount of research, wiring and plumbing can be intimidating.

What I believe Vue.js got right, is that it starts with solving the most essential problem of web development - declaratively mapping state to the DOM - in the least intrusive way possible. If that is all you need, then the complexity level can be grasped within minutes. When the app becomes bigger, you will probably start using components, but it doesn’t necessarily have to be an SPA. For real SPAs, you can introduce vue-router, but it’s still up to you whether to use a module build system. Finally, for a full-blown, modularized SPA, it’s still up to you whether you want to manage your state with Vuex…

This is what I call a “Progressive Framework”: the key is that we can scale up the framework’s complexity incrementally, only when the project’s inherent complexity demands it. And when you do scale up, you don’t have to shop around between dozens of competing solutions for every single piece of your stack, because there are well-documented official solutions that are designed to work together. (You can still swap them out for something else, of course.) With a progressive framework, your framework-specific knowledge can be applied to projects across the entire complexity spectrum, instead of a narrow subset of it.

There are still a lot left to be improved in 2016 - but it’s only going to get better ;)

Vue.js is a library for building web interfaces. Together with some other tools you can also call it a “framework”, although it’s more like a set of optional tools that work together really well. Now, if you’ve never heard of or used Vue before, you are probably thinking: great, yet another JavaScript framework! I get it. Turns out Vue isn’t particularly new — I first started working on its prototype almost two years ago, and the first public release was in February 2014. Over the time it has been evolving, and today many are using it in production.

So, what exactly does Vue offer? What makes it different? Why in the world would you want to learn about it when there are already Angular, Ember and React? This post attempts to shed some light on these question by taking you through a brief tour of Vue.js concepts, and I hope you will have your own answers after reading it.

Reactivity

Keeping the state and the view in sync is hard. Or is it?

Let’s start with the most basic task: displaying data. Suppose we have a simple object:

var object = {
  message: 'Hello world!'
}

And a template:

<div id="example">
  {{ message }}
</div>

And here’s how we bind the data and the template together with Vue:

new Vue({
  el: '#example',
  data: object
})

Looks like we just rendered a template. What should we do to update the view when the object changes? The answer is… nothing. Vue has converted the object and made it “reactive”. When you set object.message to something else, the rendered HTML updates automatically. More importantly, there’s no need to worry about calling $apply in a timeout, or calling setState(), or listening to store events, or creating framework-proprietary observables like ko.observable() or Ember.Object.create()… it just works.

Vue also provides seamless computed properties:

var example = new Vue({
  data: {
    a: 1
  },
  computed: {
    b: function () {
      return this.a + 1
    }
  }
})

// both a & b are proxied on the created instance.
example.a // -> 1
example.b // -> 2
example.a++
example.b // -> 3

The computed property b tracks a as a dependency, and is automatically kept in sync. No need to declare the dependencies yourself, because you shouldn’t have to.

In addition, POJO-based reactivity makes it trivially easy to integrate with any type of data-source or state management solutions. For example, here’s an integration that enables Vue.js components to bind to RxJS Observables with less than 30 lines of code.

Components

Ok the data binding is neat for small demos. What about big apps?

When it comes to structuring complex interfaces, Vue takes an approach that is very similar to React: it’s components all the way down. Let’s make our example a reusable component:

var Example = Vue.extend({
  template: '<div>{{ message }}</div>',
  data: function () {
    return {
      message: 'Hello Vue.js!'
    }
  }
})

// register it with the tag <example>
Vue.component('example', Example)

Now we can use the component in other templates simply as a custom element:

<example></example>

Components can contain other components, and they form a tree that represents your UI. To make them actually composable, Vue components can also:

• Define how it expects to receive data from its parent using props;
• Emit custom events to trigger actions in parent scope;
• Compose parent injected content with its own template using <slot>.

We are not going to go into the details here, but if you are interested, checkout more in the official guide.

Modularity

It’s 2015 and we shouldn’t put everything in the global scope!

Let’s use a module bundler (Webpack or Browserify) and use ES2015. Each component can just be in its own module. Since Vue will automatically convert option objects into component constructors, we can simply export an object:

// ComponentA.js
export default {
  template: '<div>{{ message }}</div>',
  data () {
    return {
      message: 'Hello Vue.js!'
    }
  }
}

// App.js
import ComponentA from './ComponentA'

export default {
  // use another component, in this scope only.
  // ComponentA maps to the tag <component-a>
  components: { ComponentA },
  template: `
    <div>
      <p>Now I'm using another component.</p>
      <component-a></component-a>
    </div>
  `
}

Pretty nice, huh? Wouldn’t it be even better if we can encapsulate a component’s template, styles and JavaScript logic in the same file, and getting proper syntax highlighting for each? With tools like Webpack + vue-loader or Browserify + vueify, you can:

<!-- MyComponent.vue -->

<!-- css -->
<style>
.message {
  color: red;
}
</style>

<!-- template -->
<template>
  <div class="message">{{ message }}</div>
</template>

<!-- js -->
<script>
export default {
  props: ['message'],
  created() {
    console.log('MyComponent created!')
  }
}
</script>

Wait a minute, did we just re-invent Web Components? But your CSS is still global!

Well, sort of, except:

• You can have style encapsulation. Just add a scoped attribute to the <style> tag. And it does not leak down to nested child components.

• Each Vue component is compiled into a JavaScript module, and doesn’t need any polyfill to work all the way down to IE9. You can also wrap it inside a real Custom Element if you want.

• ES2015 is supported by default in <script> tags.

• You can use any pre-processor you want in each language block.

• When using Webpack + vue-loader, you also get to leverage Webpack’s full power for static asset handling, because the template and styles are piped through html-loader and css-loader that can handle asset URLs as module dependencies.

So yeah, if you want you can have components that look like this:

Oh, and did I mention Vue components are hot-reloadable?

Animations

Can I make fancy stuff with it?

Vue ships with a built-in transition system that is very simple to use. There are many award-winning interactive sites built with it.

Vue’s reactivity system also makes it trivially simple to do efficient state-based tweening, which turns out to be quite a hassle in frameworks that use dirty-checking or Virtual DOM diffing. When you tween a piece of state at 60 frames per second, Vue accurately knows which bindings are affected, so it efficiently updates the affected bindings, and the rest of the app is unaffected. In both dirty checking and Virtual DOM diffing, changing a piece of state means the whole affected sub-tree (be it scopes or components) needs to be digested/re-rendered. Although it is usually “fast enough” in small demos, it most likely won’t be when you are triggering changes 60 times per second in a large app. Even if it manages to be fast enough, it will be draining device battery for all the wasted cycles. Check out this talk to get a sense how much effort is needed to animate things efficiently in React. Vue apps are just optimized by default in these scenarios.

An example of state-based tweening with Vue:

See the Pen Vue.js elastic header component by Evan You (@yyx990803) on CodePen.

Routing

So I want to build an app, but where’s the router?

Like React, Vue itself doesn’t come with routing. But there’s the vue-router package to help you out. It supports mapping nested routes to nested components and offers fine-grained transition control. Here’s a simple example:

import Vue from 'vue'
import VueRouter from 'vue-router'
import App from './app.vue'
import ViewA from './view-a.vue'
import ViewB from './view-b.vue'

Vue.use(VueRouter)

const router = new VueRouter()

router.map({
  '/a': { component: ViewA },
  '/b': { component: ViewB }
})

router.start(App, '#app')

The template for app.vue:

<div>
  <h1>This is the layout that won't change</h1>
  <router-view><!-- matched component renders here --></router-view>
</div>

For an actual example, check out this HackerNews Clone built with Vue.js, vue-router, Webpack and vue-loader.

Stability

A personal project? Seriously?

Yes, this is a personal project. So if you are looking for an enterprise backed dev team, Vue is probably not the one. But I’d rather look at the numbers. Vue has maintained 100% test coverage on every single commit since the 0.11 rewrite, and that will continue. GitHub issues are closed within an average of 13 hours, and there has been 1400+ of them. As of this writing, there are literally zero open and reproducible bugs.

Vue just recently reached 1.0, which means it’s production ready. The API is going to stay stable. For the 0.12 -> 1.0 upgrade, there is a migration build which ships with all the new features while remaining fully backwards compatible. The deprecation warnings will essentially guide users through the upgrade process. And that is going to be the case for any future breaking releases as well.

Well, I hope I’ve convinced at least some of you to take a deeper look at Vue. I believe it provides a valuable alternative to what’s out there, and I’d love to see you build some great stuff with it. Feel free to check out the docs, or come hangout in the forum and gitter channel. Oh, and even if you don’t want to use Vue, you should follow me on Twitter.

I just launched an open source project that I’ve been working on for quite some time: Vue.js. It’s a library for building web interfaces using MVVM data bindings with a very simple API. If that sounds interesting to you, you can check out more details at vuejs.org and the GitHub repo. The motivation and reasoning behind the library is probably best explained in a separate post - this post is mostly about the personal experience of my first serious attempt at building, launching, marketing and maintaining an open source project.

Before Launch Preparations

Marketing Plan

Almost two years ago I recreated the Clear iOS app with HTML5 and it enjoyed a decent level of PR success. It all happened without a plan though: I hacked the rough initial version in 2 days, posted a video on Vimeo, and then tweeted at the guys who made the original app. It was not really a serious open source project, more like a shoot-and-forget demo. Then the next day it showed up on HackerNews front page and I got blasted by emails.

Now that I think about it, the reason it worked was because native-like HTML5 interface was still new to a lot of people back in 2012. But this time it’s totally different. The JavaScript MV* space is totally over-saturated as of now. Although I do believe Vue.js offers something unique to the table, it can be a challenge to convince people to even give it a try. To cope with that I would need to actively promote the project instead of waiting for things to happen. The Mozilla blog had an excellent post on this topic. For my project specifically, I prioritized these channels:

• HackerNews
• Reddit /r/javascript
• EchoJS
• The DailyJS blog
• JavaScript Weekly
• Maintain a project Twitter account

The details of these channel’s respective impact will be talked about later in this post.

Website and Documentation

The website is built with Hexo, a nice static site generator which is essentially Jekyll in Node.js. This allows me to write documentations and guides in Markdown while retaining full control over the site - including visual design and embedding examples. The documentation is written separately in Markdown because personally for me writing all the docs in source comments hurts code readability quite a bit. The site is hosted on GitHub pages. It is also open sourced so users can contribute to the contents. One day after launch I got a pull request fixing Bruce Lee’s email address. You see, open source is awesome.

Tests

There’s no way people would use an MV* library without decent test coverage, so for Vue.js a comprehensive test suite is a must. It was fun and exciting when I was hacking away in the beginning, but when the internal architecture stablized I knew I had to start writing tests. I started running Mocha unit tests in a headless PhantomJS instance with grunt-mocha. After the API matured a bit, I added functional test cases with CasperJS, and later on switched the unit test runner to Karma so I can automatically run unit tests in real browsers (which is awesome). The code currently has a 96% coverage.Shortly before launch I configured the unit tests to be also run on SauceLabs in all target browsers to ensure compatibility. Gotta have those shiny build: passing badges in the README!

The Week After Launch

Day 1

Stats:

• Vuejs.org unique visits: 10245
• GitHub Stars: 212 (+181)
• GitHub unique visits: 1880
• Star Rate: 9.6%

Exposure:

• HackerNews front page
• Reddit /r/javascript top spot
• EchoJS top spot

I submitted the website link to HackerNews, EchoJS and the /r/javascript Sub Reddit on Sunday Feb 2nd, in the late evening, because I just finished writing the documentation. Had I done enough research, I would have realized it was probably one of the worst time choices to submit links. Luckily, the HackNews submission still made the front page and stayed on it for quite a few hours. The EchoJS and /r/javascript submission both climbed to the top spot, both very encouraging signs. The peak visits/hour was at 9AM Monday, which falls in line with the analysis in the previous linked post. Based on Google Analytics data from now (Feb.11th), about 41.42% of the traffic were identified as direct visit, among which a large portion probably came from HN. Reddit accounts for 10.08%, and EchoJS only 1.81%.

Despite over 10k unique visits to the website in Day 1, the repo only got 1.8k visits. Compared with the following days this is a particularly low conversion ratio. The possible cause was that when the site was first launched, the examples section only had three text links with source directly linked to GitHub. Even worse, the front page also had no code example at all. Google Analytics data shows that among all the visitors that stayed after landing at the home page, nearly 50% visited the examples page next. I think having interactive examples like the current jsfiddle embeds would probably help visitors grasp the gist of the library much better.

Day 2

Stats:

• Vuejs.org unique visits: 2892
• GitHub Stars: 382 (+170)
• GitHub unique visits: 1266
• Star Rate: 13.4%

Exposure: Featured on DailyJS blog.

I submitted Vue.js to DailyJS on Day 1 and it was featured on Day 2. The aqcuisition stats up to today show that DailyJS made up for around 4.77% of total website visits. It is worth noting that visitors acquired from DailyJS had the highest pages/visit (4.64) and the lowest bounce rate (17.01%) among all referral sources. DailyJS also generated 500+ unique visits directly to the GitHub repo, which is the highest referral count except for the Vue.js site and GitHub itself. Day 2 also had the highest GitHub visit/star rate so far.

Day3

Stats:

• Vuejs.org unique visits: 1257
• GitHub Stars: 420 (+38)
• GitHub unique visits: 455
• Star Rate: 8.3%

There was nothing too exciting on Day 3. I reached out to a few more sources including the Changelog, Smashing Magazine and Peter Cooper (@peterc, curator of the JavaScript Weekly newsletter). The Changelog agreed to cover the library but nothing happend so far. Smashing Magazine made no response. Peter responded that they’ve already queued Vue.js for the week.

Day4

Stats:

• Vuejs.org unique visits: 1512
• GitHub Stars: 459 （+39）
• GitHub unique visits: 330
• Star Rate: 11.8%

Exposure: Tweeted by @JavaScriptDaily.

Day 4 @JavaScriptDaily (49.6k followers) tweeted about Vue.js. By this time, Vue.js have had a fair amount of retweets about it, and for all time data Twitter referrals account for about 10.69% of total visists. However, Twitter visitors had a whopping 55.28% bounce rate and only 2.72 pages/visit, lowest among top 10 referral sources.

Day5

Exposure:

• Featured in JavaScript Weekly email newsletter.
• Vue.js TodoMVC benchmark on /r/javascript front page

Stats:

• Vuejs.org unique visits: 2825
• GitHub Stars: 518 (+59)
• GitHub Unique Visits: 495
• Star Rate: 11.9%

The JavaScript Weekly newsletter has a really large audience (>65k subscribers). So far referrals identified from JavaScript Weekly account for 10.42% of the traffic, the highest among all referral sources. (It is a bit puzzling because it doesn’t show up in the web version of Google Analytics but is included in the Android version.) As a result the falling site visits and GitHub star count saw a decent comeback on Day 5.

As expected, the TodoMVC benchmark stirred up some controversy. People love and hate benchmarks - it all depends on whether the results fit their expectations. Having said that, I readily admit these benchmarks do not reflect the whole picture (in fact a very limited case) and should be taken with a grain of salt.

Day6

Exposure: Landed in TodoMVC and retweeted by @tastejs.

Stats:

• Vuejs.org unique visits: 1826
• GitHub Stars: 581 (+63)
• GitHub Unique Visits: 552
• Star Rate: 11.4%

Day 6 is pretty exciting because Vue.js landed in TodoMVC. I actually submitted the pull request on Day 1, but it took a week to finally get merged in. I implemented TodoMVC with Vue.js very early on as a testbed for designing the API, and had a pretty comprehensive CasperJS test suite for it that was run on every commit. Interestingly, when I submitted my pull request, the TodoMVC team had just started screening submissions with an automated WebDriver test suite. Thanks to the CasperJS tests it didn’t take me much time to pass all their tests.

I haven’t found a way to quantify the implication of being included in TodoMVC, but based on the traffic it’s not too dramatic. Nonetheless, this is a really good testimonial for the competence and value of Vue.js, considering it was accepted right after the TodoMVC team wrote a post on Yet Another Framework Syndrome.

Day7

• Vuejs.org unique visits: 1529
• GitHub Stars: 615 (+34)
• GitHub Unique Visits: 399
• Star Rate: 8.5%

Sunday everything slowed down, which is likely a natural weekly pattern. What’s exciting though is that Vue.js merged the first pull request from the community. In fact, three pull requests were merged or partially included on Day 7. People have also started to hang around in the #vuejs IRC channel, discuss issues and ask questions. There’s certainly some momentum going on :)

Acquisition Stats as of Feb 11th

Now

Since I released Vue.js I have received kind words and suggestions from many people. Considering the current state the JavaScript MV* scene, the reception has been well beyond my expectation. To all of those who like it, I want to say thank you. And finally, thank YOU for reading this far. If you made it here, I assume you are somewhat interested in Vue.js - so checkout the site at vuejs.org, get in touch via @vuejs, or even better, contribute on GitHub.

If you don’t frequently type in a non-latin language, e.g. Chinese, then most likely you’ve never heard of Composition Events. Even for a Chinese developer, it’s rare that these events are needed in development. In fact I didn’t learn about their existence until recently, when I was trying to alter an input field’s value as the user types. Everything works perfectly when typing English letters, but it turns into a mess when I tried Chinese. Let me explain.

The way IME composition works is that it buffers the user’s keystrokes until a character/word selection has been made, finalizing the input. The buffered keystrokes are temporarily displayed, but not actually inserted into the DOM. However, when I change the input field’s value during a composition, the composition gets terminated early and these buffered keystrokes get inserted into the input field.

As I was banging my head against the wall trying to find a solution using key events and async updates, I discovered composition events. They are exactly what I need! But not before I get bitten by the various inconsistencies across major browsers. According to the spec, this is the expected behvaior:

• fire compositionstart when composition starts.
• fire compositionend when user selects a character/word and finalizes the input.
• fire compositionupdate on every input during composition, including immediately after the start event and immediately before the end event.
• input events should fire after composition events

What’s actually implemented in major mordern browsers:

• Firefox 26 : working according to the spec.
• Chrome 31 / Safari 7 : doesn’t fire compositionupdate immediately after the start event or before the end event. For compositionstart, the event’s data value is wrong (undefined where an empty string is expected).
• IE10 : fires only one compositionupdate right after compositionstart, then no more.
• IE9 : fires input before composition events.

Pretty annoying, but luckily not too complicated to work around with for my case. All I had to do was listening for compositionstart and compositionend and avoid changing the input field’s value during the whole composition - and voila, problem solved!

Recently a new front-end build tool, Gulp, has been getting quite some attention. What makes it really elegant is its use of Streams to orchestrate the build flow. Since everything is passed down in the buffer, it gets rid of the need to create temporary on-disk files.

It already has an active community contributing plugins for it, but still lacking a few plugins that I need for testing purposes, so I have to stick with Grunt for now. I can of course use Gulp and Grunt side by side, but I really don’t want two build systems in a single project. The other problem I have with Gulp is its task concurrency model. Everything runs in parallel by default and it’s a bit awkward when you simply want to have a list of tasks to run in order (which Grunt does by default).

Luckily, one of the authors of Gulp has refactored gulp’s file system out of its core as a standalone module: vinyl-fs. Its .src() and .dest() methods are actually all you need to leverage existing Gulp plugins. The module is not in npm yet as of this writing, but you can install it using its github shorthand:

$ npm install wearefractal/vinyl-fs

With vinyl-fs we can easily use Gulp plugins inside Grunt tasks:

var fs = require('vinyl-fs'),
    gzip = require('gulp-gzip')

grunt.registerTask('zip', function () {
  fs.src('./build/build.js')
    .pipe(gzip())
    .pipe(fs.dest('./build'))
    .on('end', this.async())
})

You might have noticed that some Gulp plugins really just do one trivial thing, like renaming, adding a header, adding a footer, etc. I’m okay with these tiny extra dependencies, but what annoys me a little bit is the fact that almost all of these plugins have the entire event-stream module as a dependency but really only uses its .map() function, which is available as the standalone map-stream module. Also, what if I want to do something to the file that doesn’t have a plugin for?

It’s in fact super easy to hand-roll some of these functionalities with just map-stream:

var fs = require('vinyl-fs'),
    map = require('map-stream'),
    zlib = require('zlib')
grunt.registerTask('zip', function () {
  fs.src('./build/build.js')
    .pipe(map(gzip))
    .pipe(fs.dest('./build'))
    .on('end', this.async())
})
// all you need to do is modify the file's
// contents and then call the callback.
// Just remember it's always buffer in and buffer out.
function gzip (file, cb) {
  zlib.gzip(file.contents, function (err, buffer) {
    file.contents = buffer
    file.path = file.path + '.gz'
    cb(err, file)
  })
}

By piping things through a mapped Stream, you can do whatever you want with the file — alter the contents, change file name, etc. The nice thing about this is you can use raw dependencies (e.g. just use uglify-js for an uglify task) with a custom script, run it with Grunt, make, npm run or whatever you like instead of waiting for someone to write a gulp plugin for it.

I seriously thought Riot.js was a parody making fun of all the gazillions of MV* frameworks out there. Turns out it is not — obviously they are pretty serious and published a lengthy blog post discussing how awesome their framework is compared to other popular ones. I guess anyone would be intrigued by how much they can do with just 1kb of code. But does it really hold up to the claims? I quickly checked out the source code and its TodoMVC implementation. Well, you probably already know my conclusion from the title of this post.

I have no problem with the library’s implementation itself. In fact I am a big fan of a minimal boilerplate + compose-it-yourself approach to developing applications. For smaller-scale projects this gives you maximum flexibility to adapt to changing needs, and brings in minimum amount of cognitive barriers. These are real benefits. But at the same time you will have to spend much more time thinking about the implementation details and how to structure your code to keep it maintainable as the codebase grows. There’s nothing wrong in choosing this approach under the right situation, but it is simply a tradeoff rather than an advantage. The real problem with Riot.js is that its authors are marketing a project with major tradeoffs as if it’s superior in every aspect, with hyperboles and misleading comparisons.

Less to Learn. Sure there’s less to learn about the framework itself, but there’s also so much more to learn outside of the framework! The equivalence of “less to learn” is “we are not really offering much”. Talking about MVP when you don’t provide actual implementation is like saying “You should have a model, a view and a presenter, but you have to figure out how to build them yourself.” That’s pretty helpful, thank you Riot.js! If I already know how to implement a model, why would I even need you?

Less proprietary idioms. Frameworks enforce idioms and conventions so that multiple team members using the same frameworks will understand the same set of concepts and can understand each other’s code more easily. It’s an initial commitment to smooth out later collaboration costs. When too little is abstracted away and too much is up to the developers, you will end up having to dig into other people’s implementation details to understand what’s really going on once the codebase starts to grow, and that will cost more than the initial hours spent learning the framework.

Less bugs. Sure, less bugs in the framework. But again, what about outside of it? When you have direct jQuery manipulations scattered all over the place in the Presenter? There’s in fact no so-claimed “auto updating view” because you have to manually emit change events. The more logic the developer has to manage, the more bug prone the entire project is. By delegating logic bookkeeping to the frameworks via features like computed properties, we are transferring a part of the debugging burden to the frameworks, which most popular ones have solid test coverage and a community reporting bugs for them. What Riot.js is doing is simply putting the burden of making sure things work back to the developer, and I wouldn’t call that an advantage.

Embeddable. When you have jQuery as a hard dependency? That alone makes its size close to Angular.

Faster. Oh of course, let’s all write our applications in asm.js, that’s going to be damn fast! On a more serious note, again you are making tradeoffs. You have to weigh in how much functionality you are giving up before you talk about speed. Eviltrout already pointed out it’s simply unfair to compare Riot.js’ templating function to other engines because it doesn’t even do loops, partials or conditional statements. Also with Riot.js you are throwing away entire chunks of DOMs and recreating them on every refresh, and what happens when you have thousands of elements in a single view and you are only updating one value? That’s terribly inefficient.

Cheaper. Good luck building an Amazon-scale application with Riot.js. You’ll probably spend more money on additional refactor hours than the saved bandwidth cost.

Clean separation. I want to emphasize that the framework itself does not enforce anything. You can’t claim that a framework does X because something that utilizes X can be written while accidentally using the framework. The framework has to enforce X as an obvious or even inevitable choice to qualify for that claim. I can write MVP style code with a simple event emitter library too, can I call it an MVP framework? In Riot.js’ case the MVP separation is in no way exemplified in the source code itself, and even when using it you can still easily end up with shitty code unless you are already good enough to have clean separation without it.

Less application code. Let’s take a look at the TodoMVC example. The example itself is still missing features as of this writing, and against what the site claims it actually uses more SLOC than Angular’s both TodoMVC implementations. You have to manually emit model changes. There’s no computed property so you have to manually keep track of updating all the properties that depend on other properties (the counters). You have to manually create, inject and modify the DOM or listen for events in a ton of places. By scattering selectors all over the place the HTML template and the JavaScript code is tightly coupled so when you change one place you need to manually change the other place as well. Let’s admit that the gzipped code size is not an accurate metric to reflect the amount of work you need to do as a developer, neither is TodoMVC a good indicator for how well a framework can deal with large scale applications.

I’d like to repeat that I have no problem with a minimal approach in building web applications. I’m just really bothered by the way Riot.js is being marketed. If you are a novice and need help from a framework, it offers too little guidance; If you are a competent developer, it offers too little functionality. The advantages it’s boasting are in fact tradeoffs.To me its use case is really narrow and the value it offers doesn’t justify the hype it gets.