Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

151–160 of 550 posts

Re: Using a framework will harm the maintenance of your software

#151
post #17

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…

bug ridden mess maybe, but probably not slow. with 0 overhead, things to be fast by default. frameworks add weight.

Re: Using a framework will harm the maintenance of your software

#152

I'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…

There is no reason to be stuck on a previous version of Laravel.

With the help of rector, it should be an afternoon's work to upgrade.

https://github.com/rectorphp/rector

Re: Using a framework will harm the maintenance of your software

#153

Earlier 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…

> or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application

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

#154

Earlier 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.

If that were true, what would be the difference between a library and a framework? Is a library not also factoring out common parts? Or is a framework just a bunch of libraries?

No, this definition doesn't describe what people understand as frameworks.

Re: Using a framework will harm the maintenance of your software

#156

So, 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.

No, the article is saying "frameworks are bad, unless you follow nonstandard advice about loose coupling.

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.

Easier still, Spiral-development doesn't have to plan anything except the next feature... works right up to the point it implodes.

Thank you, I will see myself out... ;)

Re: Using a framework will harm the maintenance of your software

#159
post #12

Frameworks 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.

I'm not a java developer so I don't pay much attention to spring.

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.

Post reply on HN