Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

161–170 of 550 posts

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

#161
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…

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…

Commonly summarize simply as:

Libraries over frameworks.

If you chose not to use an existing framework and end up building your own instead, you just live long enough to become the villain of your own story, as it were. But it's really, really tempting to write frameworks.

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

#162
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…

> 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries

not sure what framework-free has to do with. I'd remove the word "framework-free" and it would still be just as true

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

#163

Earlier quoted context omitted.

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. This applies to whatever in-house monstrosities get built too, except that without docs or a million eyeballs to judge whether a workflow makes some sense to an outsider.

Right. I'm definitely not trying to say that apps on a framework are actually larger and nastier than frameworkless apps. They both get large and nasty.

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

#164

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 requires you to have imported settings.py and be connected to the database first, before you can even import a model. It makes it impossible to write modules with type hints and modules which are partially usable outside of Django context.

If that is not dictating how you write your code, I don’t know what is.

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

#165
Libraries that you can call from your code are conceptually much simpler than frameworks that call your code. I don't think this means that zero frameworks should exist, but frameworks are generally not composable (hard to use many in a single application) while libraries compose trivially.

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

#166

That brings up the old debate between framework vs library. My personal conclusion had been don't use frameworks, rather use libraries.

I am getting bit in the butt right now for using the ionic framework for building a multi-platform mobile app.

If I want to build a mobile app in JS, but not use a framework (ionic/cordova/react native), how do I proceed?

While I admit framework-driven cross platform mobile apps are bad, even native code is vulnerable to OS updates shifting the ground from underneath them.

How do you use a library in mobile app dev?

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

#167
Number of people here (apparently) confusing frameworks and libraries is kinda surprising.

With framework, your app becomes the framework and that framework becomes your app. There’s no abstraction and clear separation like with libs. Oh, maybe you can have abstraction with frameworks, but then why use the framework in the first place.

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

#168

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

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 this: escape out of the framework code into 'normal' code as fast as possible. The framework only calls glue code. All of your real logic and investment is in code that uses Plain Old data structures and that's it. That'll keep you sane.

It also is a great way to pop out bits of your logic into separate little programs where you can do things like write utilities that let you reason about the bigger system in bite sized chunks, or even to use benchmarking tools to do A/B testing of different implementation details of one subsystem, without the noise of the rest of the system getting in the way.

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

#169

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

I find it highly improbable you have never encountered a Facade pattern. ;)
Post reply on HN