Optimize for change. It’s the only constant.
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.
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!
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".
No two apps are the same, so we optimize for change. It’s the only constant.
References and further reading
- 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.
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.