There’s a running theme on this blog, if you’ve read many of my posts. It’s that most posts come as a result of some fireshit-storm I set off on twitter or wherever else when I make a claim that almost everyone seems to disagree with. I then feel the obligatory incumbency to at least explain myself in a detailed blog post. This post is no different.

On Saturday afternoon, I tweeted:

OH “frameworks are useful only for rapid prototyping. once you go to production, you should re-write and remove the frameworks”

This came from a conversation I had with a few people, and I paraphrased a few points into that one “OH”. Someone in the conversation later corrected me that “only” should have been “most”. OK, fine, whatever.

The context of our discussion was actually about CSS frameworks, like Twitter Bootstrap. The person who made the claim was railing against the use of such frameworks in production. He claimed they were bloated (slower load due to file-size) and they were quite obviously cookie-cutter. He basically agreed that they’re very useful for rapid prototyping, but as soon as you know what the site should look like and are happy with it, you should rip out all the frameworky stuff and make custom CSS for that design.

I liked that way of putting it. I suggested the same (well, kinda) was true of JS frameworks, and the others around the circle seemed to agree.

But oh boy, did I stab some sacred cow when I dared to tweet that claim out.

Religious flame-wars aside, people really seem to love them some JS frameworks. Emberists, Angulars, Backboners, unite! Down the with heretic who dare attack our way of life!


If you like your framework, fine. I’m not trying to tell you your framework choice is wrong. That’s for another post or conf talk.

But let me say this: almost all the reasons you use to justify why using said framework even once you push code to production, are IMO silly. I’ll grant you that you like your framework-of-choice, but I’m not going to grant you anything beyond personal preference as your foundation.

What’s in a name?

It’s important that I right-away give my definition for “framework”.

A framework is an opinionated tool which exerts a strong degree of influence over how you design and architect your code, and in so doing, makes a number of assumptions about how various tasks/problems should be solved, layers on auto-magical abstractions to hide the ugly parts, and bootstraps an awful lot of the basic structure for you.

Update: I recently came up with another metaphor to depict my definition of framework, and how it fits in between “tools & libraries” and “platforms”:

  • Tools/Libraries: a geographic map you can consult on a trip (either physical folded map or app with a blinking GPS location icon).
  • Frameworks: a turn-by-turn nav system with your destination pre-entered and which is chirping out directions on where you should turn, etc.
  • (Server) Platforms (like .Net, Java, etc): a driver-less car/bus that you’re riding along in as a passenger.

jQuery/Dojo/YUI are not a frameworks. They are libraries or tools. At most, they suggest certain ideas, but they just sit there latently, unassuming, unobtrusive to your page/app, but yet provide the utilities you need should you choose to grab them from the toolbox and put them to work.

Angular, Backbone, Ember… these are frameworks. There’s an enormous and obvious difference between a project built in one versus the others.

Other people define these things differently, and find different nuances to obsess about. I don’t care. Save your breath with the nit-picking. At least you know where I’m coming from in this post.

I have absolutely no problem with tools and libraries.

I actually don’t have a problem if you even choose to use a framework… except that I don’t think you should leave a framework in place once you’re ready to go to production.

And that word “ready” is where we likely differ. Because I’d say you’re not ready if you’re still relying on a framework.


Frameworks are awesome for rapid prototyping. In fact, some of them were originally created for exactly such purposes.

But somewhere along the way, I think we got off-track, and we decided that what’s good for the prototype is good for the production app. And so people started designing fancy complex frameworks that were intended from the start to be your production app foundation. This is where we went wrong, IMO.

I think frameworks should be used to rapidly prototype while you are conducting what I’d call “exploratory development” — figuring out the problem domain and how best to approach it. Frameworks excel at making such nimble and quick changes.

As you begin to understand the problem space better, and narrow down on how you’ll solve it, I think you should begin removing the framework bits.


Because abstractions are slow. Abstractions are harder for new people to learn from scratch. Abstractions hide necessary details when bug-triaging. Abstractions hand-cuff you into a certain way of thinking about things, a certain way of doing things.

Ivory Tower of Aloof

I’m sure by now most of you probably think I’m spouting off from some ignorant, aloof, ivory tower type of mentality and that I am ignorant of what the reality on the ground is, you know, in the real world.

Or you’re assuming that I have no idea how to work on teams and that this mindset only works for lone cowboys.

You know what they say when you “ass-u-me”, right?

I’ve spent over 13 years in the (web) development industry. I can’t even begin to tell you how many times I was forced to take code I deliberately intended only as a prototype and shove it into production, and then try to stomach the consequences of when they find out.

Just because that’s reality doesn’t make it right. Just because every boss and client out there insists on this, because that’s all they’ll approve a budget for, doesn’t make it right. Just because all your peers are doing it, and if you don’t, you’ll lose your job, doesn’t make it right.

I still feel bad for all those prototypes I let leak into the production world. There’s an awful lot of code I’m proud of, but there’s plenty more that I’m embarrassed by.


Frameworks are like color-by-numbers for painting. You can paint a nice looking picture color-by-color, number-by-number. You can even learn about painting technique, brush selection, color theory (mixing colors), etc — all that is great to learn in color-by-numbers painting.

But you wouldn’t take one of those paintings, clearly a cookie-cutter reproduction that a thousand other people could have produced, and call that salable art. The color-by-numbers painting you did is going to hang on mom’s refrigerator, not in the art museum. Let’s just be honest about that.

Once you learn how to paint, it’s time to actually paint. Original paintings. Custom paintings. Skillful and talented paintings. Paintings that are uniquely yours. Paintings that specifically capture some moment, some emotion, some experience. That’s how you make a career as a painter.

And that’s how you need to make a career as an application developer.

Patterns & Re-usability

I recently worked on a decently high-profile site with a team of other developers. It was a completely one-off, custom site, with very little chance of needing long-term maintenance beyond the initial release. Actually, each page was sort of its own little micro-site. All together, though, I’d say the site was a pretty good size, at least 20k+ lines of code. So we’re not just talking about a simple marketing page.

The overall site needed many of the basics of organizational architecture, like URL history management, navigation, Ajax’ing of links, templates, events, etc. I built all that. And I did it totally custom, as opposed to pulling out some framework from the popular-o-sphere.

Why? Because I already understood that (architecture) domain pretty well. I’ve done similar “single-page apps” dozens of times. I’m getting a little better each time I do it. I learn new lessons about easier ways to mix the pieces together with each project.

I had plenty of previous code I could dip into. I went and copy-pasted from a variety of previous projects to get me started. Before too long, I had a basic functioning skeleton of a site together. No frameworks.

But of course I had plenty of re-usability, because I already knew many best practices for those various tasks, having done them over and over before.

It would have been silly for me to eschew everything I knew beforehand and start from scratch.

But here’s one of the big myths about frameworks: they’re the only way you get rapid re-use and best-practice patterns into a new project. In other words, if you’re not using a framework, you must be re-inventing some wheel. Bullshit. Know your craft, and repeat what you’ve done right before. And even improve upon it.

The glue I wrote for these various bits was customized to various constraints of my project. But I didn’t need to reinvent how my link ajaxification worked, or how I managed templates, or even how modules communicate through events. This was all stuff I’d done before, so I just rinsed-and-repeated.

You know what I did? I wrote a framework for that site, and I called it “the site”. The other developers didn’t really have any trouble creating new “pages” in my architecture. Routing and page-bootstrapping were as simple as some basic conventions and patterns, which took half a wiki-page to explain. No problems.

And we of course set up some nice grunt tasks to automate any of the sticky parts, to make it flow even smoother.

It wasn’t all perfect, though. As we went along, I realized some of the “architecture” decisions I made weren’t optimal. Neither in terms of performance nor in terms of other developers being able to collaborate quickly. So I had to refactor and adjust. I had to ditch a few things I’d previously used and rewrite them.

But the task of doing such things was way easier since I’d written all the architecture myself. It would have been much harder if I was realizing “you know, Backbone models aren’t working for us, for X, Y, Z reasons, so I’m going to have to hack and customize them in the following 15 ways…”

There’s been lots of blog posts over the last year about people doing exactly those sorts of customization-hacks for all the major frameworks. And the description of the epic journeys into hackdom that these tasks require can leave your head spinning, and thinking “I’d never be able to do that much work to customize a framework on my own project.”

Why does this happen? Because the real world is messier than it appears in that framework’s online documentation. Because that framework had to make certain assumptions for the masses which may or may not fit your needs. Because… we have to adjust.

We have to be able to adjust. In fact, the ability to adjust rapidly is far more important than the ability to rapidly prototype. The stronger the opinions and insistence upon pattern that your “framework” brings, the harder it will be for you to adjust and refactor later.


By stark contrast, however, some of the developers on the team I was working on had never really worked on anything except with actual frameworks. Two of them came from a Backbone background. For their individual micro-site pages, again completely custom interactive (game-like) experiences, they seemed to struggle to understand how to organize their code.

Why? Because I hadn’t chosen Backbone as the overall framework for the site. Backbone seemed overkill for even my complex architecture bit. But it seemed ludicrously over-blown for these tiny one-off pages.

And yet, what they ended up doing was pulling in, for each of those pages, a subset of Backbone. They had mini-models (which were just a few config variables) and a mini-view (which just called out to the basic html templates I had set up). They didn’t even use the part that I like the best about Backbone: events. Because I already had an event system set up in my architecture’s “framework”. And it was perfectly suitable.

See, frameworks can, all too easily, become a crutch. You get so used to the framework doing stuff for you, when you’re tasked with doing something custom and specific yourself, you’re lost.

Here’s another tried-and-true analogy: when all you have is a hammer, everything looks like a nail. When all you have ever done is Backbone, everything looks like a Backbone to you.


Another myth that perpetuates around frameworks is that they’re so useful for teams because they let everyone collaborate together more easily.

True… and false. The “framework” I built for the aforementioned site did just that. But, it wasn’t really a framework, per se. It was a loose collection of good patterns, utilities, best-practices, lightly glued together, just enough for the task, no more, no less.

There actually was no value in picking an established, popular framework for the task, because only 2 of the 10 team members had ever used Backbone before. I’m sure a few others had used other ones, but it’s not like we had 10 hardcore ninja Backboners chomping at the bit to hack some awesome Backbone app together.

No, in the real world, the theory of “oh, everyone’s used Backbone before, this app will be easy for us all to work on” falls flat. Every developer comes from their own background, and your team is a hybrid mixture of various levels of experience. One dude saw Backbone done one way, and another dude saw it done totally differently. Getting those two to work together on a Backbone project is no less difficult just because you picked Backbone.

Whatever framework or “framework” we chose, everyone still had to figure out how to do what they needed to do within the context of the app. The framework was no silver bullet that meant we could all blindly start coding and everything would work perfectly.


Don’t substitute a “well known framework” as a means to code maintenance instead of good and proper documentation (both in code and outside of it).

Well written and architected code does not require a framework, but it seems many people have trouble building maintainable code without them. Don’t be one of those lazy people.

Write code that someone 6 months from now can read code-comments and your wiki pages and have a reasonable understanding of your “framework” so they can get up and going. That’s all you need. Popular frameworks don’t give you that automagically, so they’re not an adequate substitute for well-written and well-documented code.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

That’s an apropos quote here. But here’s an even better one, IMO:

Write each line of code as if you’re the last human being that will ever see it.

Write code that’s of quality, for the sake of quality, and if someone ever does have to touch that line later, it will be a maintainable line of code by default.

Pain: now or later

What this boils down to is that you almost never start off a project from line 1 of the code with a perfect understanding of how to build it. No framework out there is going to fix that.

What the framework will do is get you up and going quickly. In no time, you’ll have pages and logins and CRUD operations flying about. You’ll have nice looking standardized buttons and forms and multi-select lists galore. Your boss and your client will be happy because they see things quickly evolving, and that lets them get farther down the road of thinking about the problem domain.

They don’t want you to introduce them to any pain at this point. They certainly don’t want you to remind them, “hey we used a framework, it’s probably not sufficient for production, we need to build time into the release schedule for some refactoring.”

But you know what else they don’t want? They don’t want the app to fall over 6 months into production, either due to performance bottlenecks, or lack of flexibility when the problem domain suddenly changes out from underneath you.

THAT is often way more painful, and way more visible.

You’re going to have some pain along the way. Depending on how good you are, that will be more pain or less pain. But pain nonetheless. No magic framework you pick is going to isolate you from it. Put on your big-boy or big-girl pants and suck it up. This is going to hurt.

The question is, when do you want your pain? A little bit at a time, as you begin to refactor your app from the framework-prototype phase into production-ready, or after you have a million pissed off users because of too many Fail-Whales?


I love reminding people of this:

You will lose 100% of the battles you don’t fight. And only 99% of the ones you do fight.

This way of thinking about frameworks as prototyping tools rather than production app foundations is uncomfortable and will piss people off. You’ll have project budgets that get busted. You’ll have unhappy clients who will threaten to fire you.

Yeah, yeah, yeah.

But the more responsible way to act in this industry is to fight the harder battles, to push back and try to get the stakeholders to understand what you’re concerned about.

Your boss and your client don’t understand our industry, they don’t understand how the web platform works. And they will rarely care about such details. They’ll never care if you never help teach them by pushing back.

The 1% of the time when you win such a battle and you get some extra time to do things a little more correctly, and that means pulling some of the framework out and building custom-and-specific code for the task at hand, the overall quality of your project will go up. Just a little bit, but it’ll go up.


The next time you find yourself writing Angular, Backbone, or Ember code… just ask yourself: Is this really production-quality code, or am I just doing fancy prototyping?

The answer may surprise frighten challenge you.

This entry was written by getify , posted on Monday November 25 2013at 06:11 am , filed under JavaScript, Misc, UI Architecture and tagged , , , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

6 Responses to “Silly Rabbit… Frameworks are for Prototypes”

  • richard says:

    “production code versus fancy prototyping” is a great place to end the article and the thru line is generally difficult to argue with; with one exception. In the shortest possible way… the 10,000 hour rule is real and while hiring programmers out of high school, college grads or even interns seems like a great idea and way to save money… Your product is driven by responsible experts. Frameworks, whether they are “angular, ember, backbone, etc… or best practices or standards” may not be for production but they useful when trying to enforce certain standards that the noobs just don’t grock.

  • Darius says:

    I’m struggling with this problem framework vs clean [pick language] code. I totally agree that whole domain logic should be written without framework, but all what glues application and business logic with end user can be done faster and cheaper through framework. Especially when you don’t really like frontend part of the job like me 😉

  • Jeffery Moore says:

    Sure, and all generalizations are false. See what I did there?

    I agree with the spirit of this article but take issue with some of the specific statements you have made. The color by numbers analogy is way off. Some of the best most elegant code ever written utilities a framework or library. Does the code suffer? Not necessarily at all.

    It seems your point is that standardizing on a framework is stupid. True. Standardizing against all frameworks? Equally stupid. It’s up to the development team to weigh the pros and cons and how they interact with the tons of variables at play in a given project.

    Rewriting an entire project from being framework-based to using only native code is not something I would expect most teams/devs to be able to pull off. Not if the app is of any complexity. Is this a great idea in an ideal world? Absolutely. Is it realistic? Not a bit as far as I am concerned.

  • getify says:

    @Jeffery Moore–

    I think you’ve missed most of my point.

    It seems your point is that standardizing on a framework is stupid.

    Nope. I never said that.

    I don’t personally like frameworks. I find using boilerplate from previous successful projects and writing custom glue is a more effective approach for what I work on.

    But I recognize that some people and teams find it very effective to use some framework for the initial development. Good for them. I have no interest in working on such teams.

    What I *did* say was that it’s stupid (aka, “misleading”) to claim that standardizing on some framework magically makes it that they can easily hire any dev who’s heard of that framework and they’ll be able to get up to speed quickly. The “shared expertise” benefit oft cited as a pro for frameworks is, IMO, total myth bullshit. 10 “backbone” devs will have 10 different opinions on how to do “backbone”, and the other 9 of them will still struggle to understand the code of the first, as they would with ANY code base.

    Rewriting an entire project from being framework-based to using only native code…

    This is a strawman because I didn’t ever claim that’s how teams should proceed with frameworks.

    Briefly, what I suggest is that a framework is good for rapid prototyping, but that most of the generic and broad utility parts of it are unnecessary (if not used, obviously) once the project goes to production.

    I don’t think a team should ever rewrite the app from scratch. What I think they should do is go through the code and rip out the parts which are bloated generic utility, leaving only what’s needed for the app at hand.

    And as far as I’m concerned, the only reason such a thing is “not realistic” is because this industry is full of mostly-lazy developers with a lack of pride in overall quality who bend to the unrealistic constraints of bosses and clients rather than ever fight for what’s “right” for the platform.

    There’s no question that this is “unrealistic” for most developers, but not because they shouldn’t, only because they don’t have the ethic that values it, and collectively we’ve allowed clients and bosses and marketing departments and design teams and every other auxilliary industry to dictate to us that our industry is basically just a loose collection of commodity low-rate get-it-done-as-fast-as-possible developers, rather than engineers who care deeply about what they produce.

    And if that sounds overly harsh, sorry. I’ve been around for 13+ years, and that’s my take.

    I do hope that pointing out such things causes even a few people to take a step back and re-evaluate if they can be part of the solution rather than the problem. All it takes is to start asking a few probing questions and pushing back a little when the same old crap is shoved at you.

    Like I say, “you will lose 100% of the battles you don’t fight, and only 99% of the ones you do.”

  • Jeffery Moore says:

    The only point I seem to have truly missed is about rewriting things without the original framework, since even upon re-reading, it still sounds like you *strongly* suggest that teams do this. Almost sounds like you demand it.

    Again, I get what you are saying overall. Frameworks are not magic and they shouldn’t be used carelessly. And I agree with most of what you said and appreciate that you want people to think about framework decisions more thoroughly.

  • getify says:

    @Jeffery Moore-

    I went back and re-read my post, too. :)

    As you begin to understand the problem space better, and narrow down on how you’ll solve it, I think you should begin removing the framework bits.

    “hey we used a framework, it’s probably not sufficient for production, we need to build time into the release schedule for some refactoring.”

    as you begin to refactor your app from the framework-prototype phase into production-ready

    I honestly don’t see where I “strongly suggest” or “demand” any sort of “rewriting without the original framework”. What I think I’m clearly advocating is responsible refactoring that removes the unnecessary generalized framework bits and leaves the parts that serve the important app functionality, only.

Leave a Reply

Consider Registering or Logging in before commenting.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.