1. 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…
Using a framework will harm the maintenance of your software
151–160 of 550 posts
Re: Using a framework will harm the maintenance of your software
#152I'm experiencing this with Laravel. I'm stuck on 5.2 while they're on v9 now because the author thought it would be a good idea to arbitrarily change some method signatures because he regretted his decisions earlier, while not providing any additional value and I don't have the time to hunt all these down and refactor everything, and I feel unmotivated when he's made it clear he's a bad steward. He refused semver for…
With the help of rector, it should be an afternoon's work to upgrade.
Re: Using a framework will harm the maintenance of your software
#153Earlier quoted context omitted.
> 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…
> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the la…
That's not what people commonly understand as a "framework". Nor is it a helpful definition because then where does "abstracting things" and "framework" start and end?
No, the main difference between frameworks and what you describe is the IOC. In the framework world, the framework calls you and then something happens behind the scenes until the framework decides to call some code that you provided via the frameworks API.
With libraries it's the other way around: you call the library and then you do something with the result and then use it to call the library again and so on until you have the desired outcome.
The difference is, for example, that you can call the library and when it returns something to you, you can inspect it and choose to ignore it. You can do so in an arbitrary way. In the framework case, if the framework does not provide any way for you to interact with it in the way you want, then you are screwed.
Re: Using a framework will harm the maintenance of your software
#154Earlier quoted context omitted.
> 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…
A framework is what happens when you write a ton of similar apps and factor out the common parts. The quote here is no more literally true than the original lisp quote, but (just like the original) that doesn't stop it from being true in spirit.
No, this definition doesn't describe what people understand as frameworks.
Re: Using a framework will harm the maintenance of your software
#155My personal conclusion had been don't use frameworks, rather use libraries.
Re: Using a framework will harm the maintenance of your software
#156So, frameworks are bad, unless you follow standard advice about loose coupling? I'd think most things would be bad if you failed to follow that advice about them, and the frameworks I'm most familiar with (aspnet core, ef core) seem to be pretty good about making it easy to follow.
Re: Using a framework will harm the maintenance of your software
#157tl;dr: NIH
Re: Using a framework will harm the maintenance of your software
#158"Frameworks are designed to take your project hostage" Wow, that is some enterprise level FUD, and with zero citations to back up that assertion. While one could possibly see 3rd party external dependencies pose a variable cost, service risk, or security issue... a standalone/maintainable site should not have 25 domains for every lame js widget a designer thought looked cool. Those who do not use a good framework, ar…
You don't need a framework. You can control execution and use libraries. Once you use a framework changing back is hard. Removing a library on the other hand is easy. Because for libraries you control execution, and for frameworks you have to fuck your code so it will obey the requirements of that framework.
Thank you, I will see myself out... ;)
Re: Using a framework will harm the maintenance of your software
#159Frameworks come and go. What is trendy today will be deemed obsolete a few years later. By the time when the community no longer interested in said framework, it will feel like the rug got pulled leaving many projects stranded.
13 years into my professional career I'm still seeing Spring everywhere.
But I think the overarching point also includes versioning. For example, asp.net 1 app will still run today just fine, not so for many of these frameworks. RoR, Laravel, et al, all become a rat wheel of upgrading every 1-2 years.
It's a problem.
Contrast that with CakePHP which is still supporting CakePHP2 (I think, it's EoL is coming up soon though) over many many years. I do worry they're increasing their cadence and becoming like most other frameworks in this regard, so I may have to stop praising them for their attitude for support of older versions.
Re: Using a framework will harm the maintenance of your software
#160Every major version change is basically an Armageddon.
This is one reason why micro service design is popular, you can throw away everything later.