In this week’s JavaScript weekly (check it out if you like a weekly round-up of JS news and buzz!), there was a link to a presentation on “Angular.js from an Ember.js perspective”.
Before I get too far, let’s clarify quickly: I have not watched the presentation, only checked out the slides. They are good, and you should probably watch the talk. What I’m going to talk about is how we think of “frameworks,” especially in the JavaScript world.
The first point Alex starts with is “Ember.js is a framework, Angular.js is a toolset.” It’s a true statement. However, when we talk about “frameworks” I posit that we actually mean this:
frame·work [freym-wurk] noun :
1. The means by which I’m going to build this fucking app.
2. A place to start from in building an application, because my app is not a special unicorn, and I’d rather to 80/20 (80% of stuff I’m doing has been done on the web before, 20% is my special sauce*)
So while Alex is 100% correct, framework also means different things to different people. To me (and I think a lot of people), when we say “I’m choosing a framework” we mean the above, not the technical distinction between a framework, a library, a polyfill … when you get down to it, it gets hairy. “Framework” has become our short-hand for the kit we need, whatever trappings it comes in.
* Sometimes that’s more like 90/10 or 99/1. Building an eCommerce site? Welcome to the 1%.