Citation needed: the blogpost.
Less FUD on HN please and thanks.
Using a framework will harm the maintenance of your software
111–120 of 550 posts
Re: Using a framework will harm the maintenance of your software
#1121. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.
Or three or twelve of them.
Re: Using a framework will harm the maintenance of your software
#113Earlier quoted context omitted.
> I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess. Companies who try to build any type of codebase end up with a mess. Always. No exception. There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to…
> Companies who try to build any type of codebase end up with a mess. Always. No exception. I love how demonstratively wrong this is
Infinite real world edge cases says hello.
Re: Using a framework will harm the maintenance of your software
#114Even though he has a point about harming future maintenance and how the framework has no obligation to give a damn about what you need.
Ie, see React 18 introducing double rendering for state and useEffect on strict mode (on by default in Nextjs). Makes debugging harder when shit runs twice, all for some future update.
Re: Using a framework will harm the maintenance of your software
#115Earlier quoted context omitted.
I agree with a sibling commenter after reading the article. The main point, as I see it between the lines, is not to refuse to use functionality (app side), but instead how this functionality should be packaged preferably (module side). Nothing prevents the one “in control” to give it up and expose a meaningful degree of it to a user, along with default mode convenience for those who want boxed version. Frameworks ac…
> Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. Do you have a concrete non-hypothetical example? Because I don't think I've seen this.
Exactly. The framework I’m most familiar with, Symfony, specifically is arranged to be antithetical to this statement.
Re: Using a framework will harm the maintenance of your software
#1161. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs. Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this…
> But that's another problem with frameworks - you have to know the whole thing in order to use it well.
The difference is I have plenty of resources at my disposal to learn how to use a popular framework. I only have hopefully the one “architect” who thought their problem was a special snowflake to ask about their framework - if they are still at the company.
Re: Using a framework will harm the maintenance of your software
#1171. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Or three or twelve of them.
I want to credit both the reference (it’s about lisps) and my frame of reference (there are at least a couple of should-be lisps in projects I maintain, and at least one more I think would benefit from a going concern that seldom gets recognized as lispy but absolutely is).
Re: Using a framework will harm the maintenance of your software
#118Earlier quoted context omitted.
The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in…
The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…
+1 Django is a beautiful example of a framework you can use but doesn’t get in your way.
Re: Using a framework will harm the maintenance of your software
#1191. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs. Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this…
That has long been one of my complaints about Rails. It creates a nice directory structure for the framework's objects. But there's no obvious place by default to put business/application "your logic". So then all that stuff gets wedged into huge controller and model files. (in the old days there was a division between 'business objects' vs 'data objects' etc)
#1 is definitely true. I had my own halfassed 'framework', and have dug into enough older web apps to know that everyone else had one too. (Or at least the smart ones did.)
Re: Using a framework will harm the maintenance of your software
#1201. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…
> After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim
I also have 25 years of experience and started my career writing C and FORTRAN on mainframes without any real library let alone a framework and then wrote my own libraries in C for my next job where I had to write cross platform code that ran on x86 based PCs and mainframes.
My next job, involved maintaining a proprietary compiler/IDE/VM for ruggedized Windows CE devices. So I think I have experience working without frameworks. Not to mention by the time I graduated from college in 1996 , I was a hobbyist assembly language programmer on 4 processors for 10 years (65C02, 68030, PPC 601, x86)
I can say that it’s the fifth level of hell coming behind an “architect’s” half assed framework who thought their problem was so special that they didn’t want to use a mainstream framework to handle non business specific concerns.
There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it.