Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

401–410 of 550 posts

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

#401
post #390
post #367

Earlier quoted context omitted.

The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).

At which point it is no longer C, rather a programing language that vaguely resembles ISO C.

Of course it is still C. You've just opted not to use some of the functionality.

Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either.

The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless.

Even if we postulated the inversion of control was there, the fact you can replace all parts of it still means it does not fit the article definition.

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

#402
On contrary. Not using frameworks (when you have need for them) actually means you build 60% of framework your self, and then you have to maintain your app and your framework. Which is waste of time and resources. In my experience as freelance developer the worst project I could possibly get is from people who invent their own "frameworks" (they just call it "lib") because they thought they were smart avoiding frameworks like next.js, laravel or springboot. It is a mess to maintain and to implement anything new on that codebase.

Complaining that framework wont support you forever because you were too lazy to maintain the software incrementally, is like complaining why php 1.0 or why windows 98 is not supported anymore. It simply doesn't make any sense.

My advice was always focus on your product, on your app, use as little dependencies as you can, but do not waste time on things that are solved already. Don't write your own framework to avoid using some other more mature and better maintained framework or lib. Sure you do not need library dependency which will tell you is something boolean or not, but if you need to add router to your app, use the lib.

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

#403
post #160

The problem with using a framework is that the upgrade tax is steep. Every major version change is basically an Armageddon. This is one reason why micro service design is popular, you can throw away everything later.

I think that says more about the maintainers than libraries vs framework. Some maintainers value backwards compatibility and some don't. Some value the time of their users more than the purity of their platform/framework. React as a framework seems to value it's users -- upgrading isn't that hard. Angular 1 to 2 didn't. Microsoft and x86 worship backward compatibility -- 30 year old programs frequently run without a hitch on the PC platform, thus showing that they value backward compatibility. Anything written against a Google sdk or api or platform will need to be reworked every 2-3 years or the app will break.

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

#404

Every time I see anti framework posts I am forced to frusteratedly chime in. This mentality makes me fume... not all of us work on massive teams where building stuff without a framework is even an option. And even then, whats really a "framework"? You could argue it's even the language itself. Android apps used to be written in Java, and now they are pushing Kotlin way harder (and it may even be the default soon). Ev…

also typescript apps that haven't had active development in the last 10 years will be a pain to work with again. Toolchains need maintenance and upkeep.

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

#405

Earlier quoted context omitted.

A library is not a framework. You can write framework-free apps while using libraries (in fact, most do - not wanting to be burdened with a framework doesn't mean you have to write all functionality yourself). A framework is either about inversion of control (it calls your code, e.g. you write web request controller logic, and it sets up the infrastructure for calling your controllers), and/or a set of ways to struct…

Well to be pedantic, the CRT invokes a callback called 'main' with preprocessed (command line) parameters, in the 'main callback' you're expected to do something with the parameters that have been passed to you (for instance read data from stdin, process it and write back to stdout), and then return from the 'main callback' with a success or failure code. Ok, I'm throwing together the CRT and standard lib here, but i…

Yes, in the same sense that "all programs are just permutations of 0 and 1 in the end".

Similarly, "libc is the same as a framework" is not an abstraction/assumption at any meaningful level, or really pertinent to the discussion.

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

#406

Most sufficiently complex codebases that aren’t “framework” based will have a poorly implemented, feature-lacking, bug-ridden version of a framework eventually. If Django doesn’t fit the use case for your thing, don’t use it? Just don’t use flask and then start reimplementing Django. Also, Rails is better Django. It’s not even a close comparison.

Every flask REST implementation I've seen has been a bespoke library combinatorics mess compared to something that could have been written in Django REST framework.

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

#407

Earlier quoted context omitted.

A library is not a framework. You can write framework-free apps while using libraries (in fact, most do - not wanting to be burdened with a framework doesn't mean you have to write all functionality yourself). A framework is either about inversion of control (it calls your code, e.g. you write web request controller logic, and it sets up the infrastructure for calling your controllers), and/or a set of ways to struct…

By this definition everything is a framework. You're never the one calling code, it's always the BIOS, the bootloader, the kernel program loader, etc. I don't want to go all ad-reductio, but this is one of the points I have against the anti-framework people: the code you write is actually a pretty small percentage of the total code that makes up your system/application. Good engineering is working to make sure that c…

>I don't want to go all ad-reductio, but this is one of the points I have against the anti-framework people: the code you write is actually a pretty small percentage of the total code that makes up your system/application

Which is neither here, nor there.

We're talking about a specific kind of inversion of control and forced structure within the codebase.

Else we could just go down an irrelevant rabbit hole, and it would like being a lawyer in a criminal case and arguing that your client is innocent, because "ultimately everything, including the murder, is just deterministic after-effects caused by the Big Bang".

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

#409

Write small, well tested services in the easiest to use framework you can find. If the service becomes hard to maintain then replace it. This should be a simple job guided by the tests.

People talk about services like libraries aren't a thing. That exact same statement with `s/services/libraries/`.

"Write small, well tested libraries..."

If you have a library with a solid, small public interface and you carefully maintain compatibility on that interface with great testing, you can be decoupled. Plus you don't have 2 network interfaces and the internet injected into a call to the interface.

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

#410
post #19
post #13

It matches TFA, but I think 'Framework' in that capitalisation (incorrectly) implies it's about Framework ( https://frame.work ) the company. I think quotes - 'framework' - would be better, both here and in the OP; we can fix one of those.

I'm so old, I thought of the productivity suite from the 1980s: https://en.wikipedia.org/wiki/Framework_(office_suite) I still think about that suite, because it had a certain kind of elegance: Everything was frame, and therefore text documents and spreadsheets were frames, and you could embed a frame in a document, which correctly implies you could put a spreadsheet in a text document. But the cells in a spreadsheet…

Even their website uses frames. https://framework.com/
Post reply on HN