There’s a bit of a kerfuffle right now in Angular.js land because, lo and behold, the 2.0 release contains drastic differences and there isn’t really an upgrade path.
If you want to upgrade you'll likely need to completely re-write your app!
The structural updates they're proposing all sound like good improvements, but if you built a large app on 1.x and want to upgrade it doesn't really seem like you'll be able to use much of your code.
Losing your religion
Ok, so what should you do? Pick another framework?
As developers we seem to have a tendency to get really religious about frameworks. We invest a bunch of time learning a tool and then hold onto it tightly.
But, it doesn't really buy us anything to be religious about tools. Simply converting to another big framework doesn't protect us from a similar situation in the future, does it?
Why don’t we anticipate that things will change from the start?
Change is the only constant. How can we optimize for change?
Well, how do we deal with change in other large systems?
By not building large systems, but instead composing many small, independent things into a large system.
As it turns out, we’ve gotten to the point where clientside JavaScript apps are large systems!
Refactoring, rewriting, and rebuilding from scratch is expensive. Buying into a single framework is risky. On the other hand, not leveraging anybody else’s efforts and solved problems is wasteful and painful. So what do we do?
The biggest takeaway I’ve had from building stuff with Node for the last four years is to build your code as small, focused, re-usable modules.
This type of architecture lets us change a leaky faucet without having to burn the whole building down.
We can apply these same approaches in our clientside apps. This means we can mix and match and install solutions to the specific problems that we’re facing.
We’re doing that with Ampersand.js. But I’ll let you in on a little secret:
Ampersand isn’t actually a thing–it’s a bunch of little things.
The only reason we gave it a shared name is so we can talk about is as a thing. But it’s really a loose collection of a bunch of optional modules. In fact, we call it "Ampersand.js". But good luck finding a file to use by that name, it doesn’t exist!
If you want something to model and fetch data from your API, but then use React for your views, go for it. Just use ampersand-rest-collection and ampersand-model
Need something smart to manage state while tracking touch events in your multi-touch library? Use ampersand-state by itself.
Just need something to manage clientside routing? Use the router.
And we don’t just mix it with our own modules, we grab all sorts of other useful stuff from npm. We keep a small collection of a our favorites on the tools site, but that’s just like a bookmark directory. There are a whole slew of tools available for clientside apps on npm.
Tools like Angular and Ember require that you go "all in".
As a leader on a dev team, I personally consider it too risky to invest our team’s energy in learning the intricacies of a particular framework; I want our team to learn how to solve problems in JavaScript by combining the right tools for the job. At the end of day, tools are just tools. Find and use what works best for you and your team. I just urge you to consider architectures that mitigate risk of marriage to a particular framework.
No two apps are the same, so we optimize for change. It’s the only constant.
References and further reading
- Ampersand.js
- My book, Human Javascript
- sneak peak at angular 2.0
- Reddit reactions to "drastically different"
- this whole twitter thread is gold
- My Opinionated Rundown of JS Frameworks
We’d love to help
If you’re looking for help moving from an "all in" toolkit like Angular to a completely composable approach, optimized for change, let’s talk. &yet provides advanced JS training and consulting to teams all over the world.
See our client Glenn Scott’s recent Node Road talk as a good example of how we work to make JavaScript apps maintainable and fun to work on, while capable of evolving over the long run.
P.S. I'd love to hear your feedback on twitter @HenrikJoreteg
edited 10/29/2014 23:45pm: The first version of this post was excessively critical of Angular. Angular is incredibly popular and growing like crazy. It's a brilliant, powerful framework that makes it easy to get started and really empowers developers. I disagree with some of the technical choices that have been made in the project, but that doesn't negate the fact is there are some really awesome people working on Angular. I respect them and their work very much. The engineering chops and dedication required to build a framework like Angular is inspiring. I was given frank feedback about the harshness of the original version of this post and I'd like to genuinely apologize to the Angular team.