4 ms·

Silly Rabbit... Frameworks are for Prototypes

18 points by _getify 13y ago

badman_ting 13y ago
> jQuery/Dojo/YUI are not a frameworks. Oh.
- k__ 13y ago
  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 13y ago
    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.
- rjknight 13y ago
  I too am confused by the claim that Dojo and YUI are not frameworks, but Backbone is.
  - thenerdfiles 13y ago
    Yeah, all three have Collections and Views.
    - _getify 13y ago
      The fact that Dojo and YUI can be used like a framework (so can jQuery, with jQuery UI, etc) is not the point. The point is that, at the point-of-inclusion, those 3 tools/libraries are far less intrusive to the architecture of your site than including Backbone/Angular/Ember.
thenerdfiles 13y ago
Without Module Definition "re-use" in JavaScript is just hand-waving. It amounts to re-use of HTML, and nothing more.
davidw 13y ago
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 13y ago
  ...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.
  - arithma 13y ago
    Why would you want to remove the framework? This would just be a huge waste of effort for no gain, as the grandparent shared. A decent un-bloated framework would account most of the time to a half-assed image. Not worth the trouble.
  - davidw 13y ago
    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.
arithma 13y ago
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 13y ago
  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.
icebraining 13y ago
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 13y ago
  Assembly!? Kids these days! I start with a fresh copy of the universe everyday for all my coding needs.
- thatthatis 13y ago
  No, you're missing the point. Frameworks are abstractions the author doesn't like. Languages are abstractions the author is fine with so they aren't frameworks.
- angersock 13y ago
  There's a really great metaphor for how to manage complexity in abstraction. We're all familiar with spaghetti code--you know, functional flow that winds its way through the source files and ends up in a big tangle. "Aha!" we say, "This is awful, let's fix it." So, we build all these layers of abstraction, with the hope that we can swap out any layer at random and things will be fine. This is lasagna code, and ends up being a gooey mess whenever you try to change a layer--you can always add layers, mind you, but actually removing one in the middle can prove to be quite messy. The fix is ravioli code: Little self-contained bits of code with small, well-defined boundaries and implementations well-isolated from the outside world only communicating through messages. ~ The author does make a valid point, though: debugging through lots of abstractions is kind of a pain in the neck, and depending on the app a bunch of custom concrete code can be a lot simpler to maintain. That's the siren song, though...that code is much easier to deal with until it isn't and then you're screwed.
- flipchart 13y ago
arithma 13y ago
By the author's logic, once you're done with building your website, you should remove the browser from below your website.
- _getify 13y ago
  What on earth are you talking about? That comparison is from the looney bin.
ricardobeat 13y ago
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 13y ago
  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".
  - ricardobeat 13y ago
    So the code you are copying-and-pasting from previous projects is your own framework or collection of components, you're just keeping it private. That's exactly how everyone else develops (but using open-source libraries): use a module system and glue together things from previous successful projects (made by other people). Why your own private framework is better than what is out there is a whole different matter.
    - _getify 13y ago
      Did you read the post? I said basically that. The difference is, I don't hold my "framework" out as THE general reusable pattern that everyone else should use. It's also extremely disconnected (without the glue code) and really makes no hard assumptions or influences over how you use it. And, btw, it's not private. Most of my code is on github. I just don't try to force it down others' throats.
      - deleted 13y ago
        [deleted]
    - Prefinem 13y ago
      Frameworks are different from a set of tools that allow you to accomplish a task. Picking up bits and pieces from old code isn't a framework. Its a specific tool. Think of Backbone or Ember or Angular as a mechanic shop. Things work a very certain way. The copy and paste code from other sites is a hammer, or wrench. You don't have to use them a certain way, but when you have them, you can use how they are intended.
ceronman 13y ago
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 13y ago
  ...again, the FUD that if you go framework-less, you're automatically re-inventing the wheel. Total B.S.
  - andybak 13y ago
    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 13y ago
      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.
yaph 13y ago
Guess this blog is a prototype too, takes very long too load...
Prefinem 13y ago
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.
kachnuv_ocasek 13y ago
If it ain't loading: https://webcache.googleusercontent.com/search?hl=en&q=cache%3Ahttp%3A%2F%2Fblog.getify.com%2Fsilly-rabbit-frameworks-are-for-prototypes%2F https://webcache.googleusercontent.com/search?hl=en&q=cache%...
- _getify 13y ago
  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 13y ago
    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 13y ago
      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.
namuol 13y ago
Related material: http://www.pbm.com/~lindahl/real.programmers.html http://www.pbm.com/~lindahl/real.programmers.html
- _getify 13y ago
  total strawman. language abstractions are not even remotely the same as framework abstractions inside of a language. apples and palm trees, at best.
jamieomatthews 13y ago
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 13y ago
  +1. totally agree with that sentiment.
thatthatis 13y ago
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.
arocks 13y ago
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 13y ago
  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 13y ago
    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.

18 points by _getify 13y ago

badman_ting 13y ago

> jQuery/Dojo/YUI are not a frameworks. Oh.

k__ 13y ago
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 13y ago
  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.
rjknight 13y ago
I too am confused by the claim that Dojo and YUI are not frameworks, but Backbone is.
- thenerdfiles 13y ago
  Yeah, all three have Collections and Views.
  - _getify 13y ago
    The fact that Dojo and YUI can be used like a framework (so can jQuery, with jQuery UI, etc) is not the point. The point is that, at the point-of-inclusion, those 3 tools/libraries are far less intrusive to the architecture of your site than including Backbone/Angular/Ember.

thenerdfiles 13y ago

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

davidw 13y ago

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 13y ago
...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.
- arithma 13y ago
  Why would you want to remove the framework? This would just be a huge waste of effort for no gain, as the grandparent shared. A decent un-bloated framework would account most of the time to a half-assed image. Not worth the trouble.
- davidw 13y ago
  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.

arithma 13y ago

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 13y ago
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.

icebraining 13y ago

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 13y ago
Assembly!? Kids these days! I start with a fresh copy of the universe everyday for all my coding needs.
thatthatis 13y ago
No, you're missing the point. Frameworks are abstractions the author doesn't like. Languages are abstractions the author is fine with so they aren't frameworks.
angersock 13y ago
There's a really great metaphor for how to manage complexity in abstraction. We're all familiar with spaghetti code--you know, functional flow that winds its way through the source files and ends up in a big tangle. "Aha!" we say, "This is awful, let's fix it." So, we build all these layers of abstraction, with the hope that we can swap out any layer at random and things will be fine. This is lasagna code, and ends up being a gooey mess whenever you try to change a layer--you can always add layers, mind you, but actually removing one in the middle can prove to be quite messy. The fix is ravioli code: Little self-contained bits of code with small, well-defined boundaries and implementations well-isolated from the outside world only communicating through messages. ~ The author does make a valid point, though: debugging through lots of abstractions is kind of a pain in the neck, and depending on the app a bunch of custom concrete code can be a lot simpler to maintain. That's the siren song, though...that code is much easier to deal with until it isn't and then you're screwed.
flipchart 13y ago

arithma 13y ago

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

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

ricardobeat 13y ago

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 13y ago
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".
- ricardobeat 13y ago
  So the code you are copying-and-pasting from previous projects is your own framework or collection of components, you're just keeping it private. That's exactly how everyone else develops (but using open-source libraries): use a module system and glue together things from previous successful projects (made by other people). Why your own private framework is better than what is out there is a whole different matter.
  - _getify 13y ago
    Did you read the post? I said basically that. The difference is, I don't hold my "framework" out as THE general reusable pattern that everyone else should use. It's also extremely disconnected (without the glue code) and really makes no hard assumptions or influences over how you use it. And, btw, it's not private. Most of my code is on github. I just don't try to force it down others' throats.
    - deleted 13y ago
      [deleted]
  - Prefinem 13y ago
    Frameworks are different from a set of tools that allow you to accomplish a task. Picking up bits and pieces from old code isn't a framework. Its a specific tool. Think of Backbone or Ember or Angular as a mechanic shop. Things work a very certain way. The copy and paste code from other sites is a hammer, or wrench. You don't have to use them a certain way, but when you have them, you can use how they are intended.

ceronman 13y ago

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 13y ago
...again, the FUD that if you go framework-less, you're automatically re-inventing the wheel. Total B.S.
- andybak 13y ago
  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 13y ago
    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.

yaph 13y ago

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

Prefinem 13y ago

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.

kachnuv_ocasek 13y ago

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

_getify 13y ago
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 13y ago
  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 13y ago
    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.

namuol 13y ago

Related material: http://www.pbm.com/~lindahl/real.programmers.html http://www.pbm.com/~lindahl/real.programmers.html

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

jamieomatthews 13y ago

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 13y ago
+1. totally agree with that sentiment.

thatthatis 13y ago

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.

arocks 13y ago

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 13y ago
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 13y ago
  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.