4 ms·

Here's my experience with frameworks: They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But

by Zelphyr 12y ago

Here's my experience with frameworks: They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But that last 10%... its like pulling teeth. With tweezers. Covered in grease. That last 10% is the thing you need done to successfully deliver the project but which the framework designers didn't consider. In my experience you always run into that last 10%. The net result is that all those speed gains you realized early on are completely lost (and then some) because you're fighting with the framework. So sure, understanding the framework might help you with that last 10%. But I personally think you're better served mastering JS, the DOM, and how the web works. Which really isn't that hard by the way! And anyway, if frameworks were so great why are there so many? It seems like a new framework gets announced every week here on HN. The shear tonnage of frameworks alone makes me question their value[1]. Now if none of that can convince you, consider this; the company I work for got rid of all their framework programmers and replaced them with me and a couple other software developers who have experience building products without using frameworks. And they pay us more money than they paid the framework programmers. Why? Because we did more work with better quality in the first six months than those other guys could do in 2 years of gluing framework code together. That last 10% hit them HARD and cost them their damn jobs! 1: I do recognize that frameworks provide value. My argument is that they are way overused. Great for building working or semi-working prototypes in order to test an idea in the market. Terrible for building anything that needs to be continuously maintained.

mercer 12y ago
Put that way, I fully agree. If I were to hire programmers for my company, I'd rather have a few like yourself than a bunch of Rails devs that don't really know Ruby nor Rails' internals (for example). And I've worked at a bunch of places where the effects of using frameworks without fully understanding them were readily apparent. I took issue mostly with the blanket statement that frameworks are bad, because I think there's a lot of variety. Backbone, for example, is so basic that it might be useful for 'master' programmers, whereas Rails is a monster framework that is a bitch to handle if you get to that 10%. And I'd argue React, which is more of a library, could be a very useful abstraction that leaves you free to do things your own way, or even replace it eventually. But I might be wrong about that! I'm not a master... Also, I guess in the context of the framework/library-explosion it makes sense that you'd point out the problems with a little less nuance :). And it's a good reminder for me as a young framework-raised, self-taught whipper-snapper to make sure I become a master at my 'craft'. And not just because it pays better.
kadhjasdkj 12y ago
So if i may ask, what do you use? Just raw DOM manipulations? I feel like your argument is partially valid, but your argument also sounds like it effectively argues for pure Assembly. Anything ontop of that costs you a ton at the 10% mark. Now, i understand there's a difference between a Framework and a Language, but i hope you can understand my point. I feel like you're going to one extreme, and arguing against another. Arguing opinionated frameworks with equal opinionated design seems odd to me. Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye. If it's cleanly written, with a framework that makes sense, isn't it far easier to maintain than raw JS? (Not specifically about React, just in general) Disclaimer: I like React quite a bit. But i don't think you're "wrong", we just see things differently.
- Zelphyr 12y ago
  I prefer libraries. I'm partial to jQuery[1] for DOM manipulation, simple effects, and AJAX. I love Underscore. Both libraries allow me to pick and choose which parts of them I can use without imposing on me to do it The $FrameworkName Way. That said, when I can use pure JS I do. Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye. You're right, they don't always see eye-to-eye. Frameworks are handy if you need to "get it done". You also need to educate your customer that you will have to make trade-offs and cut corners when trying to just "get it done". But I also argue that with enough experience you can, in fact, get it done and make it maintainable. I've seen that time and again. The reason I don't believe you can write something cleanly with a framework and it be easier to maintain is that the framework is a black box of unknowns. So one option, as someone else has mentioned, is to try to fully understand that black box. But then you've just tied yourself to that framework. Wouldn't you be better served mastering the technology that the framework is written in? 1: jQuery proper. jQueryUI isn't too bad but is still a little more black box than I prefer. I really dislike jQuery Mobile for all the reasons I dislike frameworks.
  - mercer 12y ago
ulisesrmzroche 12y ago
That's a terrible argument my dude. Do me a solid, what do ya'lls variable names look like right now? Or just real quick, LOC on the smallest file you got.
- Zelphyr 12y ago
  What kind of useful metric could variable names and lines of code possibly provide?
  - ulisesrmzroche 12y ago
    Frameworks decrease LOC, which drastically improve readability. Any shorthand variables decrease readability. Frameworks are great at enforcing these rules. If your average LOC is ever more than 200 lines or so, you've got a messy app.
bokglobule 12y ago
The trouble is that many devs can't see past that 80% to see the 20% that's left. They whip up a little app at night, it works really nicely and they assume this means the app they're working on during the day should be "rewritten" in the framework-du-jour. Then they hit that 20% "wall", blame the framework as "lame" and start hunting for an alternative. Rinse and repeat. Last year I got excited about NodeJS and started working with it quite heavily. Then I started to see holes - difficult debugging, so-so tooling for development, mixed bag of JS components, and so on. I then stepped back and realized that although it was interesting, and I can see it useful for some specialized server-side development, I don't see it as compellingly different than current alternatives (Rails, .NET, PHP, etc) to try to build a whole web app with it. To extend your argument, I would state that frameworks are only about speeding up the initial creation of an application that fits into a narrow set of assumptions. Frameworks, by their very nature, capture a set of decisions by their designers about how an app should work (or behave). As long as your app fits nicely into this box and you can live with the downstream risk that maybe it won't one day, then go for it.
- Zelphyr 12y ago
  I agree with the clarification that there are differences between Rails, .NET, PHP, and NodeJS. Rails & .NET are frameworks (strictly speaking, .NET is an amalgamation of frameworks and languages). PHP and NodeJS are languages.

by Zelphyr 12y ago

mercer 12y ago

Put that way, I fully agree. If I were to hire programmers for my company, I'd rather have a few like yourself than a bunch of Rails devs that don't really know Ruby nor Rails' internals (for example). And I've worked at a bunch of places where the effects of using frameworks without fully understanding them were readily apparent. I took issue mostly with the blanket statement that frameworks are bad, because I think there's a lot of variety. Backbone, for example, is so basic that it might be useful for 'master' programmers, whereas Rails is a monster framework that is a bitch to handle if you get to that 10%. And I'd argue React, which is more of a library, could be a very useful abstraction that leaves you free to do things your own way, or even replace it eventually. But I might be wrong about that! I'm not a master... Also, I guess in the context of the framework/library-explosion it makes sense that you'd point out the problems with a little less nuance :). And it's a good reminder for me as a young framework-raised, self-taught whipper-snapper to make sure I become a master at my 'craft'. And not just because it pays better.

kadhjasdkj 12y ago

So if i may ask, what do you use? Just raw DOM manipulations? I feel like your argument is partially valid, but your argument also sounds like it effectively argues for pure Assembly. Anything ontop of that costs you a ton at the 10% mark. Now, i understand there's a difference between a Framework and a Language, but i hope you can understand my point. I feel like you're going to one extreme, and arguing against another. Arguing opinionated frameworks with equal opinionated design seems odd to me. Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye. If it's cleanly written, with a framework that makes sense, isn't it far easier to maintain than raw JS? (Not specifically about React, just in general) Disclaimer: I like React quite a bit. But i don't think you're "wrong", we just see things differently.

Zelphyr 12y ago
I prefer libraries. I'm partial to jQuery[1] for DOM manipulation, simple effects, and AJAX. I love Underscore. Both libraries allow me to pick and choose which parts of them I can use without imposing on me to do it The $FrameworkName Way. That said, when I can use pure JS I do. Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye. You're right, they don't always see eye-to-eye. Frameworks are handy if you need to "get it done". You also need to educate your customer that you will have to make trade-offs and cut corners when trying to just "get it done". But I also argue that with enough experience you can, in fact, get it done and make it maintainable. I've seen that time and again. The reason I don't believe you can write something cleanly with a framework and it be easier to maintain is that the framework is a black box of unknowns. So one option, as someone else has mentioned, is to try to fully understand that black box. But then you've just tied yourself to that framework. Wouldn't you be better served mastering the technology that the framework is written in? 1: jQuery proper. jQueryUI isn't too bad but is still a little more black box than I prefer. I really dislike jQuery Mobile for all the reasons I dislike frameworks.
- mercer 12y ago

ulisesrmzroche 12y ago

That's a terrible argument my dude. Do me a solid, what do ya'lls variable names look like right now? Or just real quick, LOC on the smallest file you got.

Zelphyr 12y ago
What kind of useful metric could variable names and lines of code possibly provide?
- ulisesrmzroche 12y ago
  Frameworks decrease LOC, which drastically improve readability. Any shorthand variables decrease readability. Frameworks are great at enforcing these rules. If your average LOC is ever more than 200 lines or so, you've got a messy app.

bokglobule 12y ago

The trouble is that many devs can't see past that 80% to see the 20% that's left. They whip up a little app at night, it works really nicely and they assume this means the app they're working on during the day should be "rewritten" in the framework-du-jour. Then they hit that 20% "wall", blame the framework as "lame" and start hunting for an alternative. Rinse and repeat. Last year I got excited about NodeJS and started working with it quite heavily. Then I started to see holes - difficult debugging, so-so tooling for development, mixed bag of JS components, and so on. I then stepped back and realized that although it was interesting, and I can see it useful for some specialized server-side development, I don't see it as compellingly different than current alternatives (Rails, .NET, PHP, etc) to try to build a whole web app with it. To extend your argument, I would state that frameworks are only about speeding up the initial creation of an application that fits into a narrow set of assumptions. Frameworks, by their very nature, capture a set of decisions by their designers about how an app should work (or behave). As long as your app fits nicely into this box and you can live with the downstream risk that maybe it won't one day, then go for it.

Zelphyr 12y ago
I agree with the clarification that there are differences between Rails, .NET, PHP, and NodeJS. Rails & .NET are frameworks (strictly speaking, .NET is an amalgamation of frameworks and languages). PHP and NodeJS are languages.