Party of Five: Building in Every Major JS Framework

There’s a lot of vague talk around frameworks, and not a lot of concrete knowledge of where they differ and excel.

Starting more than a year ago I wrote a relatively popular trilogy of articles. The first one was about how great every framework was. It was a “fan’s” view of the frameworks, uncritical and positive. The second was the polar opposite. It was aggressively critical, sledging every current JS framework for sins real and imagined.

The intention wasn’t to state that frameworks were bad. It was to talk about the way we discuss frameworks and technologies in general. The intellectual dishonesty, the handwaving of flaws, shifting of goal posts. Both of these articles were written with no intention of ever saying anything untrue. It’s critically important to the point to make it about spin and preconception, rather than any actual untruths.

Naturally, the second article was an order of magnitude more popular than the first and is still routinely liked and shared — everyone loves a hater. So I wrote a third article of a more balanced position that better reflects my actual views, but moderate and reasoned isn’t that interesting.

There was something that was missing from all of these, however: concrete, real-world experience. So I’ve decided to do fix that.

The Projects

I have built a simple ToDo app in each of the major frameworks I’ve written about previously, with one change. I have removed Meteor — it is no longer a frontend framework and could be considered more a backend Node framework. I have also omitted AngularJS aka Angular 1.

A ToDo app is a poor choice. Frameworks, especially the more advanced ones, only really reveal their benefits at scale. ToDo is small enough that potential architecture benefits don’t really apply. A jQuery app would probably be smaller. But it provides a small enough app to be a viable test case.

The projects are single page apps, possessing a homepage describing the project, an “about us” page with only static lorem ipsum content, and a list of todo items. The items come from an existing generic REST server running Laravel. Minor server tweaks are permissible, but shouldn’t typically be necessary. The individual items are editable with a form that edits in place. Items are added with an identical form at the bottom visible only on clicking a button.

What I’m looking for

I’m a senior developer with about 20 years experience in this field and probably 10 with JavaScript. I’ve written production code in jQuery, Prototype, React, Ember, Backbone, Knockout, Durandal, AngularJS, Vue, and more.

As a result, I’m not necessarily looking at the same bullet points many juniors might be trying to hit. I’m focused on developer experience, maintainability and scalability of the frameworks’ inherent architectures. I’m looking for a lack of surprises, unexpected, undocumented, or unintuitive behaviours. I’m not looking for “easy to learn”, I’m looking for “easy to solve real problems in”.

Performance is not a big factor. I’m not even going to measure it. Typically it’s a premature optimisation at best, and most often a synthetic benchmark that doesn’t really reflect user experience. I consequently outright reject the term “bloat”. It’s just a synonym of features for stupid people.

I can’t describe how little I care about Github stars. Probably about as much as I care about Google trends.

Requirements

The actual requirements are pretty simple. The app has to be contemporary and production-ready. This means it has to be of a standard that could be given to a client, no shortcuts or copouts. All apps are to be idiomatic to their framework. That means .vue files for Vue, TypeScript for Angular, JSX for React, etc. Apps must export as a single app.js file, and a single app.css stylesheet file. Apps must change HTML5 push state, rather than using #/about-us style routing, and must implement a proper router. They must be written to a modern professional standard — this means ES6. While Sass or an equivalent is a must for a modern app there wasn’t enough CSS for me to bother in this case, and implementation of it would have been trivial in any of these frameworks. Definitely not a point of difference.

For the most part I didn’t use any framework specific ui components libs. This isn’t any attempt to normalise the apps, it’s just that I think they’re near-universally garbage. I’ve occasionally used them, but mostly to ease import of their stylesheets, not their prebuilt components.

I also tried to avoid state management tools initially. These are powerful tools for complex apps but didn’t seem necessary in this naïve app. The exception was Ember, whose state management and store is built in and ties in with its http access and model layers. That said, even in this app (and to my surprise) some degree of state management was needed in React, especially.

I’ve made no distinction between one way and two way binding. Whatever the framework most easily supports is fine. One way bindings are definitely the preference on a real app, as two-way can lead to conflicting state that is harder to reason. But in the scope of this it’s not really covered. I’ll discuss it a bit more in the conclusion.

There are a few specific requirements to be met. First of all, the applications need to include Bootstrap. Not from a CDN, but pulled into the application build. This is mostly to see what they’re like at handling their asset pipeline.

Another requirement flows from that. Bootstrap wants its active element to be the li tag, not the link itself. Resolving that is the sort of real-world problem a framework should be able to deal with.

Another task is to install FontAwesome. This is slightly more complex than the Bootstrap case because of the presence of font resources that need to be moved and linked correctly.

Um why not just read TodoMVC?

Because they’re not great apps. They don’t test how the framework handles editing, they’re not bundled, and typically aren’t idiomatic examples of the framework. Many are out of date. They don’t even have any form of persistence. More particularly they provide no context of the developer experience. Was it hard? Were parts of it more difficult than expected? Easier? Were there areas that the documentation covered particularly well or badly? What about the community? Are there specific pain points? Seeing an example app written by someone who might be literally anyone from a newbie dev to the creator of the framework provides little basis for real comparison, and certainly little for discussion.

Some kind of dickish final points

Not all of these frameworks are technically frameworks. React and Vue specifically are libraries. When used in conjunction with a router and an ecosystem, etc, it’s more fair to call them frameworks. Just for simplicity I’m going to call everything a “framework” regardless of whether it’s “technically just the V in MVC” or whatever.

There’s no nicer way to say this. If you’re going to comment to ask why I don’t have your pet framework or library in here, the simple answer is that I just don’t give a crap about that framework. Sorry.

This will not be over quickly. These articles are written largely based on the process rather than some sort of summary or conclusion. They will be long, and full of code and general nerd talk. I wanted to break them up with nice diagrams and stuff. And jokes. But for the most part it’s dry as hell. Sorry.

I’m writing this based on my own experiences. Yours may differ. But mine aren’t wrong. I’m not saying at all that I’ve fully mastered these frameworks. I have a lot to learn.

As a final point, I’m happy to talk about opinions and experiences, especially on technical points with objective facts. But misrepresenting my comments to score points for your tribe doesn’t deserve a grown up response and won’t be getting one. It’s insulting and it shits me to tears.

Meet The Contenders

Below are the five biggest frameworks in current use. They will be released shortly, two a week on Monday and Friday.