Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

171–180 of 550 posts

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

#171
It's been a whilst since we've had one of these on HN. What a bit of fun. My 2c. There's a choice about the work you do. does your work satisfy a business requirement, or does it satisfy your ego.

I need a site for work for a 3 year project, CRUD, users, auth, sessions. Django's perfect for my team of 1.5. It wouldn't be responsible to roll my own, when I can have the bare bones of that site up and ready to go within a day.

This is like complaining that X company is locked in because of a chipset, and suggesting they branch out into lithography to ease that burden.

Is your core business getting things done, or is it flexing by rolling your own framework.

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

#172

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

Django is definitely a framework.

Its not just Django that locks you in, it's all the third party apps people end up adding. All these integrate tightly with Django.

They often block upgrades as they have different python and Django version requirements.

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

#173

Earlier quoted context omitted.

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. That's the difference. If you make abstract to make it suitable to port to another framework. Then you are writing yet another framework on the top of a framework. In my opinion, it's even worse.

In my experience, I lack the talent for truly graphic swearing that would be required to adequately communicate just how much worse it is. Wrapping frameworks is like throwing water on a grease fire. Or maybe like someone else throwing water on the grease fire while you're standing inside the splash radius. The only way to win is not to play, but the best way to minimize the damage if you can't avoid it entirely is t…

I like your garden path sentence.

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

#174
>> A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow..are amongst the lowest performers.

It is a matter of degree. If teams responsible for this are legitimately trying to make things better (and not just trying to infallible high priests), it can be helpful. If there are established ways of doing things, it can sometimes alleviate the need to make the same decisions over and over again.

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

#175

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

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. That's the difference. If you make abstract to make it suitable to port to another framework. Then you are writing yet another framework on the top of a framework. In my opinion, it's even worse.

You can affect this by picking the framework properly.

The chances of Spring Framework, React or .Net being deprecated are zero to none. Even if they are sunset, there will be a) years of warning b) a cottage industry of open-source options.

Or you can hamper your project by abstracting EVERYTHING in your software to be 100% free to switch any library or framework at a moment's notice with minimal work. In essence building a meta-framework yourself :)

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

#177
post #50

Earlier quoted context omitted.

No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and…

This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the…

Even if this were true (and sibling posts make compelling counterarguments), you've completely overlooked that the value of a unit of engineering time varies wildly. Spending weeks of engineering time re-implementing all the security features Django provides out-of-the-box is suicidal when you're trying to get off the ground. It doesn't matter that it could save months down the road if your project literally doesn't exist anymore.

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

#179

Earlier quoted context omitted.

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. That's the difference. If you make abstract to make it suitable to port to another framework. Then you are writing yet another framework on the top of a framework. In my opinion, it's even worse.

I find it highly improbable you have never encountered a Facade pattern. ;)

One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference.

My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work, as it could apply to software.

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

#180

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…

I’ve upgraded a large application all the way from 5.2 to 9. It does take a long while, but is well worth it in the end.

They provide an upgrade guide which is pretty comprehensive.

Im not saying it’s simple, but it certainly wasn’t as bad as I imagined it would be.

Good luck getting through it!

Post reply on HN