EvanYou

Just so you know Vue 2.0 supports both templates AND JSX (or hand-written render functions): https://github.com/vuejs/babel-plugin-transform-vue-jsx

vue core, vue-router and vuex 2.0 all have typings shipped directly in the NPM packages.

Vue 2.0's vdom is actually forked from snabbdom ;)

In particular if you don't need hot updates, adding Object.freeze() to your data will make the rendering 2x faster than React.

Knockout's perf on large re-renders is below average: http://mathieuancelin.github.io/js-repaint-perfs/knockout/ It also doesn't allow you to use programmatic render functions, nor does it have server-side rendering.

Vue 2.0's vdom implementation is mutation resistant - as long as you don't replace the element directly controlled by Vue (same as 1.0), the rendering will not run into problems. If you are really concerned you can always create a custom component that returns an empty element so that you can do arbitrary manipulations inside.

1) Vue itself has little to do with FRP. "Reactive" doesn't necessarily imply FRP in any way. However it's pretty easy to use Vue with RxJS: https://github.com/vuejs/vue-rx

2) & 3): See http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/ and http://vuejs.org/guide/comparison.html

The `@click` and `:class` are in fact shorthands for `v-on:click` and `v-bind:class`. All directives start with `v-` by default. Shorthands are provided because these are two most often used directives.

Re moving away from JS classes: ES2015 class is inadequate due to the lack of static property initializers, and I don't want to force users to use stage 0 transforms. A Vue component definition is essentially an object of options, which is in fact easier than having to extend a base class. Also see https://medium.com/@dan_abramov/how-to-use-classes-and-sleep...

For the template, that's just because it's a one-pager demo and I don't want to use an inline string template. The proper experience is using single file Vue components: http://vuejs.org/guide/application.html#Single_File_Componen...

`replace: true` is a legacy option I forgot to remove in the demo :P

In Vue two way data binding is just syntax sugar for handling form input events. If you are talking about component state, the default mode of passing data in Vue is in fact one way.

Having to call `setState` kinda becomes a big deal when you want to separate state manipulation and make your components dumb. Both dirty checking and Virtual DOM are pull-based mechanisms - i.e. nothing happens when the state itself changes, you have to give the system a signal to pull and apply. This means when manipulating externalized state you need to hold a reference to all the components that are interested in it, or do it by registering events - which is why the original Flux is unnecessarily complex. It becomes less awkward when you have a single state atom, and that's why Redux is an improvement over vanilla Flux.

There are babel transforms for it: https://github.com/openjsx In fact I've seen a user use JSX-to-HTML for his Vue templates.

Author here - thanks for the submission, I was actually planning to do it tomorrow :)

Anyway, for those of you who are not familiar with Vue, here's a blog post explaining why it's worth taking a look at: http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/

I never implied which predates which. Read again.

I'm not familiar with OCaml, but this looks very similar to the reactivity model used inside web front-end libraries like Knockout, Vue.js - in which each "binding" in the template is essentially a self-adjusting computation that updates the DOM. In addition, the Tracker library in Meteor enables similar dependency-tracking computations across the entire stack. It's interesting to see this type of reactivity model used in different contexts.

This is quite an interesting hack, and I enjoy seeing novel solutions to the async problem (especially on the browser side, where ES6 is not universally available yet). But still, I would probably never use this in production, given that I can just transpile ES7 async/await with babel.

With ES6:

  r.table('users').filter(row => row('age').gt(30))

Relying on "standard JS style" is as reliable as relying on ASI without knowing how it works.

If what you are saying is with "standard JS style" you will never add a newline after return, then I can also assume with "standard JS style" you will not:

- start a line with ++ or --

- start a line with a regex literal

- split a for statement into separate lines

So, the only issue you need to be aware of when writing semicolon-less javascript is when you start a new line with ( or [. Easy enough to remember, no?

I've personally been writing semicolon-less JS for almost two years now, and this one simple rule has been more than enough.

That's why I don't like guides that suggest people to mindlessly add semicolons everywhere. If you don't really know how ASI works you are always living in the fear of missing a semicolon somewhere. Actually learning how ASI works liberates you from that fear and you can still opt to use or not use semicolons.

Don't confuse quality with style. If you want provide a quality guide, include only rules that actually improve the quality of the code, don't include style preferences. Style is subjective by nature, but quality not so much. Some rules being enforced in this guide are heavily opinionated and yet have no direct correlation with code quality. What does the indentation being 2 spaces or 4 spaces or tabs have to do with code quality? And a semicolon-less codebase can be as clean, readable and performant as one with semicolons, your arguments against ASI is simply FUD. As many have pointed out, for these stylistic disagreements the only rule should be "just be consistent".

Had to wonder if the "root" guy on the leaderboard actually hacked the game :)

Note the author is not a native English speaker, and the book in its current form probably hasn't gone through the editors yet.

Virtual DOM is fast, but it's not the only way to provide free and fast DOM updates. The author removed the Vue.js implementation from the benchmark, which does not use Virtual DOM but is as fast or even faster than Mercury and Elm.

Disclaimer: I'm the author of Vue.js. The benchmark is a fork of a fork of the Vue.js perf benchmark (http://vuejs.org/perf/).

Specifically for these experiments though, CSS 3D transform has been implemented based on the same working draft for quite a while, and it's mostly being edited by folks from Apple. Firefox being slow really has little to do with people optimizing for Chrome.

One thing I noticed about the circle drawing jsFiddle is that it’s clocking each loop synchronously, which is… totally inaccurate because repaint can happen outside of the JavaScript event loop. The proper way to measure the actual time taken to render the change is to clock the loop asynchronously at the beginning of the next iteration.

A fork of the fork from the article using async measuring: http://jsfiddle.net/yyx990803/VrLjY/

It's easy to notice that the majority of the time is actually spent on the repaint and the difference between implementation becomes much less significant. The only takeaway from this benchmark is that innerHTML/DOM thrashing your entire view is slow, and as long as data binding is implemented in a sane manner, it is almost never the bottleneck.

The arguments against DOM templating are, as the author admitted, pretty opinionated. Personally for me I much prefer working with real HTML and find it more readable. However, I do agree the real advantage of a virtual/parallel DOM implementation is the ability to render isomorphically on both client and server, and it is something most DOM-based templating solutions haven’t been able to properly address yet (although not impossible).

Author of Vue.js here, I'm glad you included Vue in your framework comparisons. Here's some thoughts regarding your comments on Vue.js: the reason Vue chose to use ES5-only features is that it enables Vue to provide plain POJO syntax without having to resort to dirty checking or virtual DOM diffing. Granted the auto-magical POJO syntax is a somewhat leaky abstraction, but I'd argue that not all leaky abstractions are bad (since by definition any non-trivial abstractions are leaky) - it all depends on its leakiness vs. the benefits provided by the abstraction. TCP is the canonical example of a leaky abstraction in Spolsky's original post yet it has been the foundation of everything we build on the web all along. In fact, even the concept of virtual DOM is a leaky abstraction in itself. My point is, I don't think the leaky abstraction argument raises anything inherently problematic about Vue.js.

That said, I really like the project because I'm also a big fan of simplicity. Curious to see if there will be a TodoMVC implementation with Mithril for easier horizontal comparisons of actual code.

"Though I do wish it was smaller. I wish I could cut all the support for old IE bits and the event handling abstractions."

Shameless plug here because author's site doesn't have comments: maybe you could try Vue.js: it is <12k gzipped, support IE9 and above only, and even less opinionated.

http://vuejs.org

Vue.js removes all the directives during compilation, so your compiled markup would be completely clean. If you are still worried, you can change the prefix using `Vue.config({prefix: 'data-v'})`.

Because the strike through is applied with a CSS class (done).

$data has to be an object, but yes you can share data between multiple ViewModels simply by assigning them. Note however this won't create nested scope between the two. To allow the child to get full access to the parent's data you need to compose them with v-component.

It makes heavy use of Object.defineProperty to achieve the plain object syntax instead of dirty checking. Unfortunately in IE8 Object.defineProperty only works on DOM objects and there's no way to shim it for plain JavaScript objects.

The biggest technical difference is probably the model observation mechanism - Vue.js observes model objects by converting their properties into ES5 getter/setters and make them implicitly emit events instead of dirty checking.

Design decision wise, it's mostly about simplicity, so no dependency injection, no pre-compiling jsx, no $digest/$apply, no services/factories etc... it's mostly up to you how to structure your app.

It also does not include routing/ajax/REST resource parts and focuses on the interface only. It is designed to be module ecosystem friendly (e.g. Component/Browserify) so you can easily leverage other libraries to fill in the missing pieces.