
Silly Rabbit... Frameworks are for Prototypes - _getify
http://blog.getify.com/silly-rabbit-frameworks-are-for-prototypes/
======
icebraining
_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._

Agreed. For example, you should never use anything above assembly, and
especially not high-level languages like C++, Haskell or JavaScript, which are
filled with abstractions. Those are fine for prototyping, but for production
you should switch to good ol' NASM, only making calls to libraries when
appropriate.

~~~
cscurmudgeon
Assembly!? Kids these days! I start with a fresh copy of the universe everyday
for all my coding needs.

------
ricardobeat
There is _huge_ value in shared common knowledge, and the efficiency gains you
get from using a well-tested, documented and production-hardened framework
that has been improved by a hundred other people.

You _are_ reinventing the wheel, slowing yourself down and making maintenance
more difficult by creating everything from scratch everytime. I think that's
common sense among developers.

~~~
_getify
I am not reinventing "from scratch" every time. I rewrite a bit of light glue
code to weave together various bits I copy-n-paste in from previous successful
projects. That's hardly "reinventing the wheel".

~~~
blat001
I've heard of this before as "Not invented here" syndrome. Frameworks are
powerful as they give all developers a common language and methodology for
doing repeatable tasks, meaning that when I need to fix a bug in your code, I
know how it is architected and where the code should be because you have used
a framework I understand.

Not to mention that these frameworks undergo alot more extensive testing than
an average developers code will ever go through. By using a framework you
benefit from not having to go through the pain of dealing with all the
different browser models and quirks that every version introduces or takes
away.

For really advanced or incredibly high performance tasks you might be correct
but to me that is the 1% of tasks, for everything else a framework should give
you all the scaffolding you need allowing you to instead focus on tasks that
add real value into the product/service you are working on.

~~~
SkyMarshal
_> Not to mention that these frameworks undergo alot more extensive testing
than an average developers code will ever go through. By using a framework you
benefit from not having to go through the pain of dealing with all the
different browser models and quirks that every version introduces or takes
away._

This is particularly what I value in open source frameworks - the hundreds,
thousands, tens of thousands, maybe even million of man-hours that have gone
into debugging edge cases, cross-browserifying, and finding security holes,
stuff I would never be able to replicate on my own in any reasonable time
frame. Especially the latter, given the security situation on the internet
these days.

My SOP is, stand on the shoulders of giants, unless there's a particular
requirement that precludes doing so. Such requirements are rare, most client
work actively benefits from use of a framework.

------
arocks
Frameworks and libraries are tools of our trade. The reason to use them or not
to use them depends on the context. While it is foolish to become a 'Backbone
specialist' and look at every project with those eyes; it is equally foolish
to dismiss frameworks as prototyping tools.

Lots of frameworks interoperate well and are amenable to customisations. The
good ones are more than sufficient for most client needs, even for prolonged
production usage.

Most open source frameworks are results of thousands of man-hours of effort by
specialists from different backgrounds. Many aspects like security, modularity
and functionality are examined by hundreds of eyes. It is perhaps naive to
assume that one's knowledge of the domain is so good that they can roll out
their own framework much better than what anyone else has produced.

In fact, if that person is so capable, they should be encouraged to post their
code for a public review and help others (or possibly be severely critiqued
for their questionable design choices).

~~~
_getify
I post all my tools/libraries publicly on github. I would never have so much
hubris as to post some "framework" I created for some site as "The Getify
Framework" that everyone else should use. That's completely contrary to the
message I'm trying to get out.

Ironically, the site I vaguely referred to in the post WAS actually fully
open-sourced. But NOT so that people could look at that code and say "Ah, he's
saying that I should always do that same thing with every site I build".

~~~
arocks
I get the impression that you perceive building a "framework" as a self-
aggrandising exercise created for the sole purpose of standardising software
development into creating run-of-the-mill products. Such view would be too
hard on the not-so-trivial amount of effort that goes into creating a
framework that can be applied to a broad range of use-cases, far beyond what
it was originally conceived for.

In fact, the truth is that it is too easy in programming to skip the
painstaking effort of reading and adapting to someone else's codebase. It is
simply convenient to throw everything away and start from scratch embracing
the (in)famous "Not Invented Here" syndrome.

------
arithma
You plug your code into a framework. You plug a library into your code.

I think this definition is a good starting point for thinking about the
difference between a framework and a library.

~~~
_getify
No definition is perfect. I admit that. But I do think, as you say, it's a
decent starting point, to reason about how intrusive/assuming (or not) a piece
of code is when we build on it.

------
ceronman
If your goal is to learn and become a better developer, I agree, forget about
frameworks, learn how things are done from scratch, it's fun!

If your goal is to move forward on a complex project adding features instead
of re-inventing the wheel for n-th time, use a framework.

~~~
_getify
...again, the FUD that if you go framework-less, you're automatically re-
inventing the wheel. Total B.S.

~~~
andybak
You're not reinventing the wheel but you are essential inventing your own
framework.

So there are only 3 possible choices:

1\. reinvent the wheel 2\. use a framework 3\. write your own framework.

This 'light glue code to bind together my libraries' thing someone mentioned.
That. That IS a frikkin' framework! And it sounds clunky as hell.

~~~
_getify
First off, you can't just take the label "framework" and slap it on any
arbitrary piece of code which works together for one or more tasks. By that
logic, every site and app ever written is its own framework.

But...

> You know what I did? I wrote a framework for that site, and I called it “the
> site”.

The key differences between my "framework" and these popular frameworks:

1\. I'm not holding out my "framework" for that specific site as some general
reusable "best practice" for every other site on the planet.

2\. It's highly customized, and customizable, to the specific site. When I
don't like how events interact with views, I don't need to worry about forking
some general framework project (and creating upstream update nightmares) and
hacking into the guts of it to change the assumptions it makes. My "framework"
is much thinner of abstraction, and far less convoluted.

Not because my "framework" is better. Just because my "framework" is specific
to the task.

------
badman_ting
> jQuery/Dojo/YUI are not a frameworks.

Oh.

~~~
k__
They are libraries, but they are used so fundamentally, that replacing them in
a existing app is a pain, so most of them impose the problems of frameworks
too :\

~~~
_getify
The pain of removing jquery is indeed a problem. So I can see the point from
that angle. But the bigger point, about how much less assuming they are just
by virtue of being included... that's the distinction I cared most about.

------
Prefinem
One way to look at this is that frameworks are like a mechanics shop, or a
carpentry shop. They have their own work flow, their own set of tools, etc
etc... jQuery and small code snippets are the tools. The hammer, the wrench.
When building a site, you don't need the whole mechanic shop (most times) but
you need just the hammer. Along with that, a mechanic shop isn't going to work
for every case. What happens if you have a mechanic shop and now you are just
doing tires. Its not a hard change, but what if instead, you are a mechanic
shop, but now you have start building cabinets instead. That mechanic shop
isn't going to work. You can't change the lifts to start putting cabinets
together.

I think the best way to look at it, is use what you need. You don't need a 140
piece tool set to hammer a nail.

------
davidw
I use a CSS framework for
[http://www.LiberWriter.com](http://www.LiberWriter.com)

My customers do not care about it _at all_ , except for the fact that the site
looks better than if I had done it from scratch. My users probably do not even
have any idea what a CSS framework is.

~~~
_getify
...which "underscore"s the fact that you can make a great site prototype with
frameworks (JS, CSS, etc). My claim was not that they have no use. But that
you start with them, get a great site, then pull out the re-usable framework
stuff and leave the customized stuff that makes your site/app so great.

~~~
davidw
It's not a prototype. It's a business that makes money.

Yeah, if it makes more money, some day, I might consider dedicating some of it
to replacing the CSS framework. But it's really, really far down on my list of
things to do. There are lots of improvements I could make to the UI without
ditching the framework, for instance, that would add real value to my
customers, and/or increase conversions.

------
kachnuv_ocasek
If it ain't loading:
[https://webcache.googleusercontent.com/search?hl=en&q=cache%...](https://webcache.googleusercontent.com/search?hl=en&q=cache%3Ahttp%3A%2F%2Fblog.getify.com%2Fsilly-
rabbit-frameworks-are-for-prototypes%2F)

~~~
_getify
I've been meaning to rip out the terrible "wordpress framework" from
underneath my blog so that it doesn't suck when 20 people try to read it at
once.

~~~
davidw
You've been meaning to: but you have other things to do.

It's all about the economics and tradeoffs of different choices, in the end.
Sometimes a framework is a good tradeoff, sometimes it isn't, and it depends
entirely on the particular set of details involved in any given situation.

~~~
_getify
The fact that I have not taken out the wordpress framework yet (because I've
been busy with other "more important" things to do) doesn't mean that NOT
doing so is somehow justifiable.

------
yaph
Guess this blog is a prototype too, takes very long too load...

------
thatthatis
This article is horrible in so many ways, I don't think Im going to be able to
cover the full spread, but here goes:

1) the overall structure of these arguments is "I've found the one true way to
work, anyone who works differently is wrong, but I'm just sharing my opinion
so you can't critisize me back" aka "I'm right, you're wrong, IMO, neiner
neiner neiner"

2) the author claims that for a major site he wrote his own " URL history
management, navigation, Ajax’ing of links, templates, events, etc.". And that
this is a good thing. He, like framework authors before him, made inevitable
design decisions, created conventions and generally created a way of working
inside the app. Now people who aren't him are going to have to maintain this
work. Instead of giving his client a standard framework that new hires might
have experience in, he gave them MyFramework(tm). He has worked against long
term maintainability and then congratulated himself for it.

2b) as they learned more, he re wrote based on specific knowledge of his own
system. With an established framework, others could have opined, with his
self-rolled framework he was a key-man.

3) In his discussion of backbone he throws up an incomplete straw man of "only
2 of 10 know it" then concludes "therefore learning my framework is just as
reasonable.". False. First, backbone is extensively documented and almost
guaranteed to be easier to learn than a custom rolled framework. Second, time
invested by the other 8 in learning backbone is a re-usable skill they can
carry with them to their next job, as opposed to time learning your framework
that will not transfer. Third, backbone experts are available on call and on
demand, if they need to grow the team or you get hit by a bus your client can
replace you more easily if the app is written in backbone.

4) Maintenance. Here he claims that his framework is at least as well
documented as other frameworks, and implies that it is better documented. He
then says it is hard to write good code and good documentation without a
framework, so don't be lazy and do it. "it seems many people have trouble
building maintainable code without [frameworks]. Don’t be one of those lazy
people." His example here goes completely against his larger point in any
reasonable interpretation. If many people have trouble writing maintainable
code without a framework, all else equal, that's a very strong argument for
using a framework.

5) pain now vs later. He assumes here that all frameworks are optimized to get
going quickly to the detriment of long term maintainability. This is patently
false. Django and Ember come immediately to mind as frameworks that explicitly
make you do things a slightly harder way because future self will thank you.
Some frameworks (Wordpress comes to mind) optimize for getting started
quickly, but at best this article is an attack on those.

6) extreme narcissism. "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.".

6 cont) he happily puts his interests as paramount, then disregards the
perspectives of others. Managers care about the long term viability of the
project and hiring and budget, not just one person's happiness on the project.
Instead of saying "they don't care about our industry" perhaps the author
should spend more time positing that they are reasonable people whose requests
come from reasonable places. They have information and concerns that you
don't, stop waiving your hands and calling their perspective invalid.

This article is myopic. Self centered. Selfish. Unnecessarily inflammatory.
And, almost entirely wrong from start to end.

~~~
MetaCosm
I thought the article would be a conversation about the value of frameworks
versus libraries, opinionated versus generalized. Which is an interesting
conversation and worth having. I was very disappointed.

Instead I saw someone proudly bragging about reinventing the wheel and NIH
syndrome. Which is mind-boggling.

~~~
_getify
See other comments here about NIH. To attribute my post to NIH mindset is
laughable. You obviously didn't read it fully.

I use all kinds of public OSS'd libraries and tools. I just don't use
frameworks that prescribe an exact way those should be glued together, nor do
I stick my own opinions about how the glue should work out "there" to try and
convince others they should do it exactly like I do.

------
jamieomatthews
I like the article, some nice points.

I think mostly, you want to always know what the limitations of your framework
are, and never be afraid to dive into the source of the framework to see why
certain things are slow/buggy, etc. If you can do this, you will be in much
better shape than 75% of the users using that framework.

~~~
_getify
+1. totally agree with that sentiment.

------
namuol
Related material:
[http://www.pbm.com/~lindahl/real.programmers.html](http://www.pbm.com/~lindahl/real.programmers.html)

~~~
_getify
total strawman. language abstractions are not even remotely the same as
framework abstractions inside of a language. apples and palm trees, at best.

------
arithma
By the author's logic, once you're done with building your website, you should
remove the browser from below your website.

~~~
_getify
What on earth are you talking about? That comparison is from the looney bin.

------
thenerdfiles
Without Module Definition "re-use" in JavaScript is just hand-waving. It
amounts to re-use of HTML, and nothing more.

