JavaScript Frameworks Are Great
We are not victims of javascript fatigue — we are kids in a candy store
The front end web-dev world is strangely antagonistic. It’s a world where there are more good options for any type of development than ever before. A world where we push capabilities and requirements and can deliver products unthinkable only a few years ago. And yet, people seem to be more and more passionate about how everyone else is wrong.
It’s a tribal industry. We invest so much time in our technologies that we feel the need to continually justify that decision. It can be hard to discuss honestly. The choice of framework we like depends as much on how the solution fits with our own mental mapping as it does on any objective standards and this makes any other choice not just different, but clearly wrong.
I’ve been doing it too. So I decided to look around. To try and figure out why people are just so gosh darn wrong and why they aren’t using the correct framework. In doing so I tried to look at each framework and express why it is that fans of that framework advocate it so passionately.
The Frameworks
Angular
Old-school Angular 1 hasn’t gone anywhere. It’s easy to look at the cutting edge of development and assume it matters, that the shiniest objects have the most value. But business doesn’t care. Angular is a tried and true, battle-tested, well established system with a solid pool of developer talent.
Angular is still the skill the most in demand from employers, with React following close behind. Angular is still one of the stand-out options for new developments.
One of the reasons for this is that it’s simple. There’s value to a lowest common denominator solution. It’s common – common sense, common ground. Angular uses JavaScript. Just plain JavaScript, not ES6/ES2015. Not TypeScript. Angular doesn’t rely on the shifting sands of complex build tools. There isn’t any mystery to Angular, it’s all well known and settled, a solved problem. Angular is also a centrepiece of the excellent MEAN stack, a completely JavaScript full-stack solution.
Angular offers a stable platform. It’s so stable and well-established that any question or requirement will have dozens of solutions, modules, tutorials, and stack overflow answers. The number of learning and training tools is well above any other solution.
It’s easy to dismiss Angular as a legacy tool. But it’s just as easy to forget that enthusiasts like us play at the breaking front of the adoption bell curve. Business is heavily invested in Angular, and newer approaches are just as often being investigated or discussed as implemented. With a solid skill set available in Angular it’s a completely reasonable choice for new application development without a heavy burden of new knowledge.
Enthusiasts often forget the sheer cost of new knowledge to business. Angular is the most accessible and the most valued framework today.
Angular 2
Essentially this is the inheritor of the successes of Angular while also being able to provide a more modern, performant and better architected solution.
These benefits start right from the beginning. Angular 2 implements a command-line interface (CLI) that assists with scaffolding of new projects and boilerplate during ongoing work.
Angular 2 is a “batteries-included” framework. There’s not a lot of need for build scripts, and you’ll find the developer experience as a whole more consistent. For example, documentation will cover something very like your application, instead of using a different build tool or state management component or router like a React app.
It’s also the framework that really brings TypeScript into prominence. TypeScript is an emerging standard that allows a developer to work in a statically typed language, which is much easier to get static analysis, intellisense, etc. It can also help remove a common class of bugs that occur when the wrong types are used, for example when the code expects an integer and gets a string of the integer.
Angular 2 is the first framework to really implement the Observables pattern. Observables are a step up from Promises. They’re particularly good for “streams” - live updated, realtime data. There’s an excellent video on how and why to implement the pattern.
For large applications that are going to need a lot of functionality (such as routers, state management, templating, API connections, etc) it makes more sense to use a comprehensive framework than assemble chunks of poorly integrated functionality. And Angular 2 is undoubtedly the biggest fish in that pool, with the most support, the largest community, and the most commercial relevance. Angular 2 will undoubtedly get the greatest tooling support, the most community support, and is the best option for career development.
Aurelia
In many ways, Aurelia offers the best of both worlds. Architecturally and syntactically it’s not unlike Angular. Its core developer, Rob Eisenberg, had a solid following with an early framework Durandal. As an aside, I still work with Durandal daily. He was invited to work on the Angular 2 project, but parted ways due to some pretty valid differences of opinion, and decided to release Aurelia instead.
Aurelia is genuinely modern. Aurelia featured native support for ES6 before it was cool and now also natively supports TypeScript.
Aurelia is unique, in that it’s a highly modern and very standards-compliant framework. And yet there is surprisingly little… surprise. There’s little to no “magic” hidden in the framework. All of the modules are very much just standard JavaScript, typically exporting a standard JavaScript class, and using standard JavaScript properties and methods. You basically never see code referencing or unique to Aurelia, nothing is wrapped or extended or watched. While it provides a great deal of utility in its binding and templates, it pretty much invariably simply gets out of your way.
Aurelia is based on a clear and comprehensible pattern — everything is a component. Components can nest other components, and be replaced or created dynamically. These components also conform 100% to the upcoming web-components standards.
Another thing Aurelia offers is an exceptional CLI. Though still in beta it is extremely capable of serving, bundling, generating boilerplate, versioning, and running tests.
All of this combined makes for a highly capable, highly efficient framework that unobtrusively facilitates your development, rather than getting in your way. Which is exactly what a framework should be doing.
You can get an excellent idea of what Aurelia’s going for with this talk from Rob Eisenberg.
Where Aurelia excels is in its ability to do only what is needed to help, rather than hinder. Any properties available on the component javascript area available in the template. All the syntax is pure JavaScript and it’s very easy to follow.
Ember
Despite an undeserved reputation for being difficult to learn, Ember stands out as being the single most productive JavaScript framework. It does this in a number of ways. For a start, there is Ember CLI. Other frameworks have a command line tool of varying degrees of capability, but Ember’s is turned up to 11. It’s a comprehensive development environment, handling scaffolding, boilerplate generation, testing, dependency management, serving, deployment, and the entire build chain. It is lightning fast end helps to enforce (while also benefiting from) Ember’s rigid conventions.
These conventions are another major benefit of Ember, nearly eliminating configuration and redundancy through logical and clearly defined defaults. A lot of Ember goes without saying, making some of it’s code, such as the router, impressively terse while also being clear and expressive.
The near draconian conventions also have another benefit. All Ember apps look the same. They all have the same structure. They all have the same build chain. They all have the same set of features and functionality.
Ember has another feature that is curiously missing in other frameworks: http abstractions and a rich model layer. Most frameworks simply use javascript objects returned from an XHR call as their model. Handling these calls is up to the developer. Handling the equivalent calls for persistence is as well. By contrast, Ember uses Ember Data, essentially an API ORM that abstracts the entire persistence layer. The conventions are handled in an adapter and serializer, meaning persistence calls are as simple as let model = store.find(‘post’, 123) or model.save(). Standard conventions such as REST work out of the box.
Ember is also developing rapidly and progressively. It was an early champion of technologies like ES6 and Promises, both of which are now central to both Ember and Javascript itself. It’s enthusiastically pushing towards web components as well, with the goal of Ember to quickly deprecate its own functionality in favour of built-ins wherever possible.
Recent changes to the framework have given us Glimmer 2, a high performance new view engine that can actually be used separately to the rest of Ember.
Probably the most impressive thing about Ember, however, is its incredible ease of use and overall developer experience.
For example, setting up and installing something like Bootstrap is literally a matter of typing ember install ember-cli-bootstrap, which will pull in and set up Bootstrap. You can begin typing classes and immediately, no need to pull in the css, add it to your build definitions, etc.
An even more impressive example: ember install ember-cli-fastboot
This creates a complete server-side app that runs in NodeJS, making your website isomorphic (or universal) with trivial amounts of effort. And then there’s ember deploy…
Another area Ember has excelled is in preventing JavaScript Fatigue. Many other methods of front-end development have suffered from a rapid pace of change, especially in the area of build tooling. While other frameworks and patterns have fragmented and shifted and changed, Ember with its CLI has remained a place of calm in the storm. Its CLI tool already does what other approaches are awkwardly lurching towards.
Ember’s overall architecture is slightly unusual for a front-end JavaScript framework. But it’s actually near identical to many backend frameworks, including Rails, and Laravel. With only a bit of introduction it’s actually a hugely comprehensible and logical pattern, and a big part of what makes Ember so productive so quickly.
Meteor
Meteor is unique of the frameworks shown here. It is a full stack framework. This means that as well as being a comprehensive JavaScript framework, Meteor can also seamlessly transition to being a backend framework as well. Newer versions of Meteor can even use something like React as their frontend framework, making it a no-compromises solution.
Traditional stacks split the roles so that the front end handles the display, while an API backend handles saving and retrieving data. This means that going from end to end on an application means transferring to a different process, and usually even a different language. This effectively doubles the amount of knowledge required of the developer. Or potentially doubles the number of developers required.
Meteor is one language, from the database to the user’s browser.
It doesn’t just stop at the web, however. Meteor is intended for cross-platform development. That doesn’t just mean cross-browser. It means mobile, iOS, Android, and desktop applications can all be created with the framework.
Even just used on the web, however, Meteor offers features that are unique. In particular, Meteor allows something termed “full-stack reactivity”, meaning database changes and content updates can be sent directly to the browser. The experience can update in realtime. This isn’t something you have to implement — it’s how Meteor works.
Meteor also has a complete library of add-ons, called Smart Packages, which can be easily installed from the command line. Simply run meteor add accounts-ui to get access to a pre-packaged accounts management system. There are thousands of packages to simplify and optimise your workflow.
There’s no need to worry about the latest gulp or grunt tooling. Meteor will automatically compile LESS/SASS code, coffeescript conversion, minification, etc, though its own CMS, which uses the best tools for the job, but wraps them in a user-friendly way. This is a huge boon for productivity and a perfect example of why Meteor goes out of its way to make you more effective and productive.
Meteor runs a clean MVC architecture, and that means it also provides nice clear templates. The template structure is an extension of the popular Handlebars template library for JavaScript. This gives it familiar and effective syntax.
What Meteor promises is what it delivers – highly interactive, high performance, realtime applications built quickly in one consistent language.
React
React has been one of the biggest shakeups of JavaScript in the last decade. It was built as a view binding layer by Facebook, and introduced the concept of a Virtual DOM. The vdom is an in-memory representation of the state of the DOM. Use of this, rather than the actual DOM for comparisons and updating meant an incredible improvement in performance. This strategy has been adopted for every new framework, or resulted in new rendering engines for some existing ones.
React is the “in” framework right now. It’s not just enthusiasts, most high profile startups and innovators use React as the core of their frontend code. AirBnB, Netflix, Atlassian, Expedia, OkCupid, and Tesla Motors. It’s not just startups, either, established publishers like the BBC, NBC, IGN, and the New York Times and web veterans like Paypal have moved to it.
React is only one piece of a puzzle, but it forms a core around which there are now an enormous range of solutions for every possible need, from advanced Single Page Apps to consolidating simple web components.
React has broken the mould in a lot of ways. Its component-based system returns something called JSX, an XML-like construction that puts the layout code directly in the component JavaScript code, elegantly tying all the pieces of the component into a consistent whole.
React has also introduced a number of other innovations that have found support in other systems, such as Redux. Redux is a pattern for managing state by laying down a series of immutable state change objects to get a consistent and reliable representation of the application. It takes a little bit to come to grips with it, but when fully understood it is an elegant and powerful solution to the difficult problems of JavaScript app state management. This now has representations in other frameworks as well.
Another one is Flux. Flux is an architecture pattern that realises the inherent dangers of “two-way binding”, in which changing an input affects the model, and changing the model affects the input field (for example). This can lead to issues where things get out of sync. In the sort of simple examples used in demos this isn’t an issue. But in a larger application with lots of potential interactions the chances of something both disastrous and very, very difficult to find, increase drastically.
Flux ensures that data changes can only pass down the chain, while request are passed up. This has been influential in other frameworks like Ember and Angular 2, which have implemented similar patterns often under different names.
Demand for React developers is off the charts. Only Angular 1 has more demand and that’s typically for legacy applications. The development world has changed from the days of Angular. Smaller, faster, more focused libraries combined to build a custom solution are increasing more popular than the one-size-fits-all approach of the monolith frameworks. React is the king in that space.
Vue
Vue is probably the newest kid on the block in terms of popular frameworks, and its profile isn’t as high as any of the others here. That said, Vue is probably the fastest rising new star as well. Vue fits in a similar niche to React. It’s not on its own a full framework, but a binding library, the “View” part of an MVC or MVVM application. Hence the name.
There is a lot to like about Vue. It’s intended to be used as a progressive framework. Pieces of it can be added a bit at a time. Initially it might be just used with the library pulled in from a CDN, and used to make simple components. Over time more functionality can be added, such as a router, state management and http abstraction, and a comprehensive build pipeline implemented to tie it altogether. But none of that needs to be done up front.
This means that Vue’s “buy in” is reasonable and manageable. You don’t need to commit to learning a complex tool to solve simple problems. You can use a simple tool to solve simple problems, then increase to more complex solutions to match those problems. And critically, you can learn that tool a bit at a time, progressively.
Vue is also fast. Very fast. Though React pioneered the virtual DOM pattern, Vue has gone the furthest in optimising that process. It is now (and in many cases by a significant margin) the single fastest of the frameworks listed here.
The success of Vue is in part due to the support of the Laravel framework, which has wisely made Vue a first-class citizen, providing some simple optimisations to make it even easier to get Vue running on a Laravel app. With so much support and an enthusiastic community, Vue is a solid bet for any project, from the simple to the highly advanced. It’s already gone from being a small edge framework to being highly visible and discussed in communities like Reddit.
Confession
I started this post with an agenda. I was going to do two parallel articles, one about why every framework sucks, and one about why every framework is exceptional. The intent was to show how easy it is to put any framework in either a positive or negative light, while still keeping it all entirely reasonable and “true”.
But the more I wrote, the more I had to read about frameworks and try to figure out sincerely what was the appeal of each of these frameworks. And the more I realised this was by far the stronger article.
It felt dishonest to trawl through documentation and discussion to find things to not like, or to make up objections to approaches that I actually don’t have a problem with.
There are too many people talking about what is wrong with JavaScript. Too many arguing about what is wrong with a given framework or approach, or blindly seeing only the benefits of their own and dismissing clear advantages.
Look around.
There are some amazing options for JavaScript development in the modern web, and some very smart people making stuff that you can use right now for free. Maybe trying another option could make you a better developer, or maybe there are approaches or patterns that your preferred framework could do with. But until we lose our blinkers and tribalism we’re not going to see it.
