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.
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.
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.
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.
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 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.
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.
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…
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.
What Meteor promises is what it delivers – highly interactive, high performance, realtime applications built quickly in one consistent language.
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.
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 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.
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.