PIcking Your Javascript Mobile Framework: Part 22 - Conclusions and My Pick

This was a long journey, for sure. We went through 77 Javascript frameworks (including combinations) to find the ones most suitable for the development of a mobile single page application, to be used as the foundation of a cordova app.

We went on a tangent to see how there was a seminal year, 2012, where a great many frameworks suddenly sprung up. Before that, the selection was small. After that, things got quiet again.

We saw different approaches to the integration of HTML and Javascript. They ranged from a completely programmatic approach, where there virtually is no HTML coding (Mithril) to one where the Javascript injects itself into a stand-alone HTML page, and everything in-between.

We have seen frameworks that require tons of external dependencies (React) and others that are proud to do what they do completely stand-alone (again, Mithril). Some require you to write tons of code (Thorax), while others are perfectly happy to do all the work for you (Vue).

We have also seen how mobile app development differs from mobile web development, and how that in turn differs from web development more in general. Mobile app development stores most of the information on the phone, while it needs to be downloaded on every new tab in the mobile web. Thus, mobile web apps can load a lot more dependencies on startup than mobile web sites. Desktop applications, on the other hand, have to worry a lot more about supporting all kinds of different browsers, which the mobile web doesn’t (since there are no old web browsers on smartphones, since smartphones are new).

With all that in mind, there are only four candidates left to consider:

• Ampersand
• CanJS
• Mithril
• Vue

All the other candidates we looked at in depth were perfectly competent and are even recommended for specific use cases listed below. But these four are the ones that show the most promise.

You’ll notice that all four of them are relatively new. Only one, CanJS, is from the Cambrian Explosion of 2012; the other three are even newer than that, all of them from 2014. That makes them all vulnerable to early project jitters. You should probably count on a number of fundamental bugs in each of them. On the other hand, you may get a chance to influence the development of the framework: all of them are kept on GitHub, and active participation is encouraged.

I would normally shy away from projects that young. Fact is that all four of these are incredibly helpful: they are much faster than the competition, the code you have to write is much shorter, and as a result your investment is richly rewarded.

But before I reveal which one of these I am going to use for my next project (suspense!), let us just look at the honorable mentions:

Most Battle-Tested Framework: This award goes to Angular, which has become ubiquitous in MVC development. It’s a great framework, for sure. Sadly, it hasn’t really been able to keep up with the times.

Angular development starts with old facts: you have HTML and have to make it do something. So a lot of the time, you take HTML and give it magic properties that you then have to back with code off stage. That’s great if you start out with HTML. But if you are starting from scratch, you may want to look at something that is more concise and performant.

Most Pervasive Framework: There is no doubt that Backbone is held in incredibly high regard. It is small, it is fast, it is flexible and adaptable. In fact, one of the final finalists (Ampersand) specifically says that Backbone was their inspiration.

The Backbone/Marionette/Require combination has also the distinction that it was the best performer in our speed tests. That’s quite amazing, of course.

In the end, though, there was a lot of code to write to make the combination happen. Additionally, it’s great to be able to mix and match frameworks, but it also means that you have to follow the possibly very different philosophies of each.

Most Used Framework: jQuery is currently impossible to beat. It’s in desktop browsers, it’s in mobile browsers, and thanks to jQueryMobile also in a growing number of mobile apps.

In its history, jQuery has looked at its deficiencies and has improved. For instance, since it was born before the quest to save bytes, it was a little bloated. A competitor, Zepto, sprung up to cut down on the bloat and was starting to get traction. So jQuery learned and came out with a much slimmed and trimmed version 2.0.

So, now I am hoping the good folks at jQuery will see that there is a need for a more frameworky type of framework, and they’ll follow up with something that stuns and kills all other frameworks. Maybe they’ll just take one of the winners of this comparison and incorporate it.

Best Framework Documentation: Far and away KnockoutJS. It’s not that Knockout is not a standout on its own – all the frameworks that made it this far are. But the documentation that Knockout offers is truly outstanding.

Really, go and try it out!

Best Framework for Beginners: As concise as some of these frameworks get, they can look really weird. That’s particularly true for Mithril, where you are in essence coding HTML without ever seeing a single “<” or “>”, unless you are comparing numbers!

Maybe it’s because it’s not made by Geek Org, maybe it’s just a wise architect, but it’s truly easy to follow the organization and logic of Ractive code. The counterindication is that a lot of people have gotten used to the weirdness of things like Angular, so the experienced web developer may find it weird, in turn.

Most IBM-like Framework: There used to be the adage that you could never get fired in IT if you bought IBM. Now, of course, IBM has nothing to sell, so you could never get fired just because of that.

React has the same feel. It’s pushed by Facebook, which is a solid backer of its own projects. Let me say this again, this is unlike Google, which just seems to love sending projects out in the wild and then yanks them again with little warning. There were no fewer than six Google Javascript frameworks in the early stages of this evaluation!

At the same time, React has its own programming language which is just a slightly weird variant of Javascript. It’s essentially Javascript married to the mixed code/HTML syntax of PHP. You don’t really have to worry about that, because you can develop React code in vanilla Javascript. But, really?

Most Underrated Framework: A technology that has been around for years and “nobody” is using it? What’s the deal with that?

Obviously, that’s not reason enough to diss a framework. Still, before you invest a ton of time into Stapes, you should consider that it’s the best framework nobody is using. That’s a little odd.

Maybe you are the kind of person that likes to bet against the crowd. Go with Stapes. Personally, I hate creating a project and then find out the infrastructure I used is not going to grow with me. The problem is that at some point there will be some innovation that your old framework is not going to be able to deal with, and what happens then? You start from scratch.

Most Surprising Framework: I have a friend that works at WalMart IT, and it’s not the kind of place that inspires the geek vibe. But Thorax is convincing. Some of its functionality is clearly targeted at large retail sites, but that doesn’t have to worry you. Thorax does well in mobile apps, is easy to use, and easy to learn – if a little too verbose.

Now To the Final Shootout!

If all the candidates of the final round are worthy of your consideration and each might be the perfect fit for what you want to do, the four remaining frameworks are standouts for the case at hand: creating fast, responsive, single page mobile apps that require little code to be written by the creator.

These projects all have the same downside, and you should be aware of that: they are young. All but one are a mere months old, and that should make you concerned.

At the same time, they are all very functional and incredibly powerful. What does it matter to you if you have to throw away the dozens of lines you wrote in Vue or Mithril? The only downside is that you might have to end up using a framework that requires you write thousands of lines to do the same.

Also, it’s not entirely clear how some of these frameworks integrate with others that are essential for mobile app development. One of the things that web sites don’t have to worry about is skinning – making the app look like other apps on the platform, let the same app code be an Android app on a Nexus and an iOS app on an iPhone. None of the MVC frameworks does that, it’s up to you – or some other framework.

This is particularly a concern with Mithril, which doesn’t even have HTML for other frameworks to attach to. I am pretty sure that can all be worked out fairly easily, but I don’t know how to go about it right now.

For the other three contenders in the finals, the question is how important their relative selling points are to you. Vue shines with the most perfect solution to typing angst. CanJS has been around the longest and is the most mature, with lots more people to support it and offer solutions to your questions. Ampersand is backed by an entity bigger than just the framework and is gaining traction faster than the other frameworks.

Once more: these four are amazing frameworks that – each on their own – blow my mind. Looking at the landscape in 2014 and comparing it with the days before the Cambrian Explosion is like looking back from the moon and wondering why people think flying from Los Angeles to New York is such a big deal.

But I have to pick a single framework to write my next app, and that’s going to be Vue.

Let me explain: I wanted it to be Mithril, but I just couldn’t help falling in love with Vue. It’s easier, it’s more rational, it maps the “things that are” more closely to the “things you write”.

The fact is that everybody is saying that the browser is not a document renderer, it’s an application platform. In it, there is a widget tree (the DOM) that is stateful. An input box is not just a rectangle on the screen that you can type things into. It’s also the repository of something in the model.

MVC models on the web all suffer from the same problem: they think of the view as something the HTML provides, while the model is something that comes from some storage. The controller mediates between the two. **But on the web, the view **is the model.

What Vue understands – and is at the core of the MVVM movement – is that it’s pointless to have manipulators mediating between model and view, because they are just not necessary.

Remember what Thorax did with the “completed” checkbox. The view was tagged with a “toggle” event. The toggle() function then got the current value of the model’s completed flag. Then it set the new value to the opposite of what it had been.

Vue doesn’t do that. It says that the model’s completed flag is the same thing as the state of the checkbox. You change one, you change the other. It’s not miraculous, it’s not magic, it’s just easy.