4 ms·

I find this article entertaining but ultimately stale and a reminder that as much as we like to criticize the present, the past was not as rosy as we remember.

by bhauer 13y ago

I find this article entertaining but ultimately stale and a reminder that as much as we like to criticize the present, the past was not as rosy as we remember. I haven't worked first-hand with a web framework that I would consider "enterprise" (and therefore encumbered by the kind of nonsense that is being pilloried in the article) in ages, certainly at least five years. Most frameworks I have worked with in the past five years focus on helping me get my job done while not fussing with annoying details. That is precisely what I want them to do. Better yet, the most modern of frameworks do that plus have put focus on performance, so they both solve stupid problems I don't want to deal with and do so quickly, giving me nearly the full capacity of the server's CPU to be wasteful/experimental/rushed with my coding style at first. Then I can optimize later to have a high-performance system because the framework itself is no longer the bottleneck it once was. I love frameworks.

Justsignedup 13y ago
Let's rename this post: Why I hate badly designed frameworks with unnecessary abstractions.
- 7mediaws 13y ago
  Yes, and that is really the issue here. Not all frameworks work the same way and some do come with an insanely amount of unneeded overhead.
- jeremysmyth 13y ago
  I think it's more appropriately named "I don't like the word 'factory' when used in frameworks, and I [don't|refuse to] understand how they are useful to developers in their daily jobs." I teach a Java web dev course that gradually works up from the servlet API through a bunch of different abstractions. I keep a drawn representation of the current stack at all points of the course, and keep a count of the lines of code required to do any particular thing. At the beginning, we need about 10 lines of code to process a basic GET request, and there are lots of explicit dependencies (inheritance, dependencies on HttpServletRequest etc.) and at the end, there are maybe two or three lines of code, and no explicit coded dependencies (several implicit, provided by the framework). Once you add in a few pieces of actual work (DAOs, collections, CRUD functionality, database connection pools, query abstraction), the code is an order of magnitude simpler when you use a framework than when you don't. It boils down to this: Using a smaller technology stack makes for an easier learning curve, but your day job after learning the basics involves ten times as much code ( == ten times as many opportunities for bugs, reinventing the wheel, antipatterns etc.), but investing in how to use a larger stack means your day job becomes much, much easier; you write less code, you focus more on your business logic, and you leave the dependency management and plumbing to the framework. Sure, you might have to use the word "Factory" a few times, but that means you don't have to write the code to implement your object pools and collection handlers. That's already done for you.
  - thedufer 13y ago
    The problem with frameworks at the time this piece was written (to be clear, I think they've gotten somewhat better since) is that the abstractions they provided were so horrendously leaky that you ended up writing more code, not less, because you need to do things that the framework was never meant to do, or was supposed to do but was bad at. This has been my experience anyway. Even recently, I've had this kind of problem (not to name any names, but socket.io), but only because what I'm working on is somewhat more specialized than in the past.
  - benjamincburns 13y ago
    I'm absolutely not trying to contradict you here. In general I agree with pretty much everything you've said. However you raise something that makes me wish to address the muddiness of the details. > Using a smaller technology stack makes for an easier learning curve, but your day job after learning the basics involves ten times as much code ( == ten times as many opportunities for bugs... I think you're implying here that not having written the framework abstractions yourself or in-house will reduce bug count. First, to be a bit pedantic, the opportunities for bugs is roughly the same over a given feature set between coded-with-framework and written-from-scratch. The the number of discovered and undiscovered outstanding bugs over that same feature set may be lower, but this doesn't necessarily reduce risk. By using a framework you're making the assumption that most major bugs have been found and fixed by the sheer volume of people testing the framework in the wild. In a general sense, this is often a valid assumption. However this is in no way a guarantee of good testing coverage. In my day job we decided to make further use of an open source tool to satisfy a particular security requirement. The tool in question has a community of nearly ten thousand users. However, it turns out that the advertised feature we wished to use was never really adopted by anyone in the community. Because of this we found a major "barrier to entry" type bug that had been outstanding for close to four years, and we lost nearly a month before deciding to scrap the effort and use something else. Beyond bug count, it's been my experience that when framework bugs do crop up they're more likely to be very costly or time consuming. I say this for a few reasons. First, let's make two fairly reasonable (I hope) assumptions: Assumption #1: Most people use frameworks to avoid having to worry about the details for which the framework offers a solution. This usually is the main value proposition of a framework (and the quote above alludes to this). This means that when you plan and design your software, you typically assume that the framework is correct. Most people don't budget time/expense for learning the framework's internals. Assumption #2: If the framework is battle-hardened, most of the bugs you'll probably find are in oddball edge cases and/or are very difficult to track down. In the best scenario your framework code is open and you can fix the bug yourself if need be. However you pay for this this with the original perceived value of the framework (no need to be an expert in its inner workings), and a lot of unbudgeted time. And let's face it; when we're in a time crunch, we don't do our best work. The probability of introducing new bugs when this occurs is quite high. Aside from the specific application details that you're now worrying about, you now have new unplanned-for operational overhead. How do you maintain the change to correct the bug? You'll either need to figure out the correct procedures/coding style/etc to submit a patch/pull-request, or you'll need to maintain your own fork of the framework. Or in the other case where you're working with a closed-source product you're just up a creek. Oh you paid for support? Isn't that cute... I don't say any of this to attack frameworks. I use them myself quite often. However I do say this to attack the idea that frameworks make it safe for developers to remain ignorant to the inner workings of their system, regardless of which parts were designed/built in-house, as the fact that something is made and supported by a third party, commercial or community, has no bearing on its quality alone.
specialist 13y ago
Sorry to pendant... A boss once asked me the difference between a library (API) and a framework. Hmmm, had to ponder that one. Besides the inversion of control -- eg don't call us, we'll call you -- I decided a framework is a prototypical (archetype) app, and you extend it. Whereas a library is standalone that makes few assumptions about your app's "architecture" (eg the visible set of design choices). I've written my own infrastructure (eg database wrapper, HTML generation, DOM & xpath, HTTP routing, logging, etc). I wouldn't call my loose collection tools a framework. I'm trying to update an Eclipse RCP plugin for 4.x. (Hot damn what a struggle.) The RCP is a framework. It makes a huge number of assumptions (for better or worse) and there's the Eclipse Way of doing things.
- bhauer 13y ago
  I'm not suggesting enterprise-style frameworks no longer exist, but simply rather that there are a wide variety of non-enterprise options today. Also, you are correct, many of the collections of software packages we today, out of convention, call a framework are actually just collections of APIs. DropWizard on the JVM. Gorilla on Go. I recognize the academic purity and the difference in approach (like you said: don't call us, we'll call you). But in practical matters, I find it easier to just consider these collections a framework. At the very least doing so allows you to communicate with others more easily. "What framework did you use to build that web app?" "DropWizard." "Cool." Or, you could answer, "No framework at all, but rather a collection of APIs." "You're some kind of smart aleck, huh?" :)

by bhauer 13y ago

Justsignedup 13y ago

Let's rename this post: Why I hate badly designed frameworks with unnecessary abstractions.

7mediaws 13y ago
Yes, and that is really the issue here. Not all frameworks work the same way and some do come with an insanely amount of unneeded overhead.
jeremysmyth 13y ago
I think it's more appropriately named "I don't like the word 'factory' when used in frameworks, and I [don't|refuse to] understand how they are useful to developers in their daily jobs." I teach a Java web dev course that gradually works up from the servlet API through a bunch of different abstractions. I keep a drawn representation of the current stack at all points of the course, and keep a count of the lines of code required to do any particular thing. At the beginning, we need about 10 lines of code to process a basic GET request, and there are lots of explicit dependencies (inheritance, dependencies on HttpServletRequest etc.) and at the end, there are maybe two or three lines of code, and no explicit coded dependencies (several implicit, provided by the framework). Once you add in a few pieces of actual work (DAOs, collections, CRUD functionality, database connection pools, query abstraction), the code is an order of magnitude simpler when you use a framework than when you don't. It boils down to this: Using a smaller technology stack makes for an easier learning curve, but your day job after learning the basics involves ten times as much code ( == ten times as many opportunities for bugs, reinventing the wheel, antipatterns etc.), but investing in how to use a larger stack means your day job becomes much, much easier; you write less code, you focus more on your business logic, and you leave the dependency management and plumbing to the framework. Sure, you might have to use the word "Factory" a few times, but that means you don't have to write the code to implement your object pools and collection handlers. That's already done for you.
- thedufer 13y ago
  The problem with frameworks at the time this piece was written (to be clear, I think they've gotten somewhat better since) is that the abstractions they provided were so horrendously leaky that you ended up writing more code, not less, because you need to do things that the framework was never meant to do, or was supposed to do but was bad at. This has been my experience anyway. Even recently, I've had this kind of problem (not to name any names, but socket.io), but only because what I'm working on is somewhat more specialized than in the past.
- benjamincburns 13y ago
  I'm absolutely not trying to contradict you here. In general I agree with pretty much everything you've said. However you raise something that makes me wish to address the muddiness of the details. > Using a smaller technology stack makes for an easier learning curve, but your day job after learning the basics involves ten times as much code ( == ten times as many opportunities for bugs... I think you're implying here that not having written the framework abstractions yourself or in-house will reduce bug count. First, to be a bit pedantic, the opportunities for bugs is roughly the same over a given feature set between coded-with-framework and written-from-scratch. The the number of discovered and undiscovered outstanding bugs over that same feature set may be lower, but this doesn't necessarily reduce risk. By using a framework you're making the assumption that most major bugs have been found and fixed by the sheer volume of people testing the framework in the wild. In a general sense, this is often a valid assumption. However this is in no way a guarantee of good testing coverage. In my day job we decided to make further use of an open source tool to satisfy a particular security requirement. The tool in question has a community of nearly ten thousand users. However, it turns out that the advertised feature we wished to use was never really adopted by anyone in the community. Because of this we found a major "barrier to entry" type bug that had been outstanding for close to four years, and we lost nearly a month before deciding to scrap the effort and use something else. Beyond bug count, it's been my experience that when framework bugs do crop up they're more likely to be very costly or time consuming. I say this for a few reasons. First, let's make two fairly reasonable (I hope) assumptions: Assumption #1: Most people use frameworks to avoid having to worry about the details for which the framework offers a solution. This usually is the main value proposition of a framework (and the quote above alludes to this). This means that when you plan and design your software, you typically assume that the framework is correct. Most people don't budget time/expense for learning the framework's internals. Assumption #2: If the framework is battle-hardened, most of the bugs you'll probably find are in oddball edge cases and/or are very difficult to track down. In the best scenario your framework code is open and you can fix the bug yourself if need be. However you pay for this this with the original perceived value of the framework (no need to be an expert in its inner workings), and a lot of unbudgeted time. And let's face it; when we're in a time crunch, we don't do our best work. The probability of introducing new bugs when this occurs is quite high. Aside from the specific application details that you're now worrying about, you now have new unplanned-for operational overhead. How do you maintain the change to correct the bug? You'll either need to figure out the correct procedures/coding style/etc to submit a patch/pull-request, or you'll need to maintain your own fork of the framework. Or in the other case where you're working with a closed-source product you're just up a creek. Oh you paid for support? Isn't that cute... I don't say any of this to attack frameworks. I use them myself quite often. However I do say this to attack the idea that frameworks make it safe for developers to remain ignorant to the inner workings of their system, regardless of which parts were designed/built in-house, as the fact that something is made and supported by a third party, commercial or community, has no bearing on its quality alone.

specialist 13y ago

Sorry to pendant... A boss once asked me the difference between a library (API) and a framework. Hmmm, had to ponder that one. Besides the inversion of control -- eg don't call us, we'll call you -- I decided a framework is a prototypical (archetype) app, and you extend it. Whereas a library is standalone that makes few assumptions about your app's "architecture" (eg the visible set of design choices). I've written my own infrastructure (eg database wrapper, HTML generation, DOM & xpath, HTTP routing, logging, etc). I wouldn't call my loose collection tools a framework. I'm trying to update an Eclipse RCP plugin for 4.x. (Hot damn what a struggle.) The RCP is a framework. It makes a huge number of assumptions (for better or worse) and there's the Eclipse Way of doing things.

bhauer 13y ago
I'm not suggesting enterprise-style frameworks no longer exist, but simply rather that there are a wide variety of non-enterprise options today. Also, you are correct, many of the collections of software packages we today, out of convention, call a framework are actually just collections of APIs. DropWizard on the JVM. Gorilla on Go. I recognize the academic purity and the difference in approach (like you said: don't call us, we'll call you). But in practical matters, I find it easier to just consider these collections a framework. At the very least doing so allows you to communicate with others more easily. "What framework did you use to build that web app?" "DropWizard." "Cool." Or, you could answer, "No framework at all, but rather a collection of APIs." "You're some kind of smart aleck, huh?" :)