PIcking Your Javascript Mobile Framework: Part 21 - Vue

Vue occupied a special place in my heart when I saw it required the least code to write. That’s a feat of its own, especially considering how lazy I am (despite being a terrific typist) and how error-prone (strike the part on being a terrific typist).

The vuejs.org web site has no clear tag line. This is what I liked best about their self-description: It is not a full-blown framework – it is designed to be a view layer that is simple and flexible.

The main trick is MVVM, or model-view/view-model bindings. What that means is that the model (coming from storage) determines the view, but when you change the view by interacting with it, that automatically changes the model. That is slightly different from MVC, because there is no explicit controller. Instead, it is always assumed that the model and the view are faithful reproductions of each other. Derived quantities are generated by listening to model and view changes.

This reduces flexibility, but it turns out that the flexibility removed is more of a headache than is worth fighting for. In a sense, it’s all those advanced options in C++ few people use because they are terribly complicated to figure out, don’t work in many compilers. and are easily reproduced using simpler code, anyway.

The code has few surprises. The index.html file is complete, so no external templates are used.** Elements are tagged with “magic markers,” this time prefixed with v-**. The same toggle for completed we have seen before is rendered as:

<input class="toggle" type="checkbox" v-model="completed">

That is, it’s just a regular checkbox, with the additional attribute v-model, set to “completed”. That means that the input has a one-to-one correspondence to the completed attribute of the model’s todo item.

When you go and look at the Javascript, it does precisely what I think it should do about completed: nothing at all. You told the model and the view where they link up, so whenever the view changes, the model does, and vice-versa. You don’t need to specify that, because it’s obvious.

(Obviously, you’ll have strange results if you tie a boolean variable in the model to a slider control on the page, but that’s a different story.)

The Javascript piece is really amusingly tiny. In the sense of amusement that is no humorous, but uplifting. There are three files: routes.js and store.js, that define the routes and the store. Frankly, they are as short as you can make them without making automatic assumptions (which is not a bad idea, but really not worth contemplating at this point).

The bulk of the code is in the app.js file. Even that is puzzlingly (in a good sense) tiny. There are 114 lines of code in it, which is already microscopic. Turns out a great many of them are just empty spacers or closing parens. If you get rid of those, you are left with only 69 meaningful lines of code.

I’ll let that sink in. there are a grand total of 69 meaningful lines of code in app.js, the only meaningful file in the Javascript folder. There is lots of magic in the index file, of course, but even the additional “weird” magic attributes don’t detract from that.

I’ll repeat: there are a grand total of 154 meaningful lines of code in the entire application, and 61 of those are HTML in the index.html file. You can either pick a framework that wants you to write 400k of code, or one that is content with 2,460 bytes. It’s totally up to you. And by the way, they do the exactly same thing. Only that Vue is not glitchy.

Vue, let’s face it, is a majestic achievement. It zeroes in on the requirements of mobile web development like nothing else. Even if I don’t end up using it, I have to applaud its maker. Vue is a thing of beauty, elegance, and utmost utility.