November 25th 2015
Most of the time productivity tools are focused on one of 6 areas. They make it easier to learn concepts, easier to write code, easier to read code, easier to architect applications, easier to maintain applications, or easier to debug applications. Here are some examples of each
Easy To Learn
Backbone on the other hand, attempts to be easy to learn in two ways. First, there just isn’t that much to learn. Backbone is a small library with only 6 core concepts (Models, Collections, Views, Events, and Router) each of which should be familiar to developers coming to it from other UI focused frameworks. That simplicity reduces the load on new users. At the same time Backbone strives to have libary source code that is both short and readable. It’s quite possible to read the code for the whole library in under an hour, and the core concepts are obvious when looking through the code.
Easy to Write
Ember.js aims to make it easy to write application code in at least 2 ways. First it provides tooling to help generate the boilerplate necessary for an ember application. You can give ember-cli a model name and it will generate the file for that model in the correct place. In addition Ember abstracts away many of the connections between classes so that you can load the correct files simply using naming conventions, resulting in less code.
Redux and React Hot loader are an attempt to develop a programming idiom that allows for drastically reduced latency between making a change and seeing a result. A React app using redux and a hot loader can be updated instantly without losing state and cycle backwards and forward through state updates. Lower latency between writing code and seeing the results makes it much easier to iterate quickly towards good code.
Easy to Read
Type annotation tools like TypeScript and Flow also aim to increase code readability, but not by clearing out bloat (annotations can actually make the code feel more crowded and less readable at first). Instead they add additional information to the code, making the structure and expectations of the code more apparent to a reader.
Easy to Architect
Ember really shines when it comes to making it easy to architect apps. By providing clear guidance on how to structure apps, it can increase productivity by reducing bike-shedding. In Ember every state of the UI is tied to a URL and each route is tied to controllers that display components. Communication between components happens with actions and data is managed by Ember Data. Thats a reasonable architecture thats general enough to work for most large web applications (Embers target).
Unfortunately examples of innovation in this area are much more sparse than the others here, probably because it’s hard to demonstrate in a todo app. There’s been a recent spate of interest in application architecture from all of the Flux implementations that have popped up for React apps. I’ve also seen interest in the architecture model of Elm. But most of the major MVC frameworks have much less community agreement on architecture than they do on smaller scoped issues.
Easy to Maintain
At the framework Backbone addresses the idea of maintainability by keeping small and flexible enough to remain usable as requirements change. React deals with it by simplifying the programming model enough that its easier for new developers to see whats going on. And Ember deals with it by maintaining a disciplined process for continually improving the framework to “keep up with the web” without leaving developers behind.
Easy To Debug
Other than tools though, Frameworks can have some features that make them easier or harder to debug. React and Angular both make a big deal of being easy to write tests for. In Angular this is true because of their dependency injection system. In React this works out because React components are basically pure functions that take state and properties and return DOM. Pure functions are easy to test, especially compared to traditional UIs that are tied to the global mutable DOM. Backbone also contributes to easier debugging by presenting a relatively straightforward and readable source that developers can trace through without becoming baffled by “library mystery meat”.
Not saying that this is the best way to make things easy to learn, just that it is a goal.↩