Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

391–400 of 550 posts

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

#391

It seems that there are mostly 2 types of devs: - those that use tools, learn them and master in them, - those that always want to create their own tools, and will usually oppose adopting and learning existing ones. I belong to the first type. I love frameworks because they give publicly available documentation that plenty of people contribute to - so my project will have access to all of it even if I'm gone. Another…

There is a third type: those of us that work with frameworks and build our own with libraries when needed. The right tool for the job essentially. The "right" framework is absolutely a net benefit, even in academia, but it can be very hard to pick the right one. Sometimes none of the available framework options are "right" either. The downsides of picking the wrong framework for a project are massive and worse than custom code in my experience. I rarely hear pro-framework-only people talk about the downsides, and I always wonder how experienced they are. Have they never seen a project go sideways by picking the wrong framework?

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

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

I would add though, that if the framework consumes much of the attention of the developers, then it is still a loss.

And I would add to the title, that using a overly _hyped_ framework will harm the maintenance. Using some framework, simply because it is new or hyped, that will get teams and companies in trouble.

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

#393

Earlier quoted context omitted.

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

> then where does "abstracting things" and "framework" start and end?

It doesn’t. If you abstract things enough there is your framework.

The only things I’ve seen that were truly without a framework were raw php files that did everything contained within that single file. And even these had headers that combined some common functionality.

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

#394
post #209

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…

Maybe you should master your tools before using them. You can use frameworks where they fit, and not where they don't. Knowing when to do which takes time and experience, but it is definitely do-able, and better. Frameworks allow you to update, and maintain your app for free, since others will do it for you. If you do it yourself, you have to do all the work and that's keeping you from adding value elsewhere. To not…

The voice of reason. Frameworks just work for a reasonable cost, offer an easy upgrade pathway to follow, and facilitate the integration of new devs. In most case (depending of your business domain, of course), they should be more than adequate.

The cold hard truth is that most developers are not the genius hackers they fancy themselves to be.

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

#395
Disclaimer: I'm a DevOps, not a developer, but enjoy writting software side projects at home where I am free to chose whatever I want and don't suffer from real world engineering decisions. So, take my opinion on this with that in mind.

Traditionally, I've always used Python with whatever framework (Django, Flask, FastAPI) but always had this feeling that I am learning a framework, not digging into the language which is what I would like. Django, for instance: you end up feeling that a big part of it is magical, which is something that I personally dislike.

A few months ago I found Go and fell in love with it's pragmatism and its non-written (as far as I am aware) rule of not relying on frameworks but instead on just libraries. I find it great, but again, I don't have direct experience in the real world to know the trade offs on multiple levels this can bring.

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

#396

Earlier quoted context omitted.

Where do you draw the line between using and not using framework. Programming language is a framework over machine language. Java garbage collector is a wrapper around manual memory management. Java Servlets is a pretty thin wrapper over HTTP request/response, is this a framework already? How about Java JAX-RS, it is built on top of Java Servlets and built to handle mostly REST type requests. Same with database conne…

It appears you are falsely using the word framework to describe abstraction . Language is not a framework. APIs are not frameworks. A framework is a tool providing conventions that dictate exactly how to proceed, typically demonstrated as a packaged architecture. The appeal, it seems, is not having to independently form many minor decisions. It appears bias, and possibly even neurological limitations, largely account…

> I tried without a framework once and produced a framework anyways, so therefore you must use a framework

In my experience, the correct way of saying this is: I tried without a framework once, and I found myself rebuilding everything that the framework previously gave me. Therefore, I must use a framework (for things that are remotely similar to the thing I built a framework for).

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

#397

Earlier quoted context omitted.

It appears you are falsely using the word framework to describe abstraction . Language is not a framework. APIs are not frameworks. A framework is a tool providing conventions that dictate exactly how to proceed, typically demonstrated as a packaged architecture. The appeal, it seems, is not having to independently form many minor decisions. It appears bias, and possibly even neurological limitations, largely account…

>The appeal, it seems, is not having to independently form many minor decisions. No. It's also to make the work easier and do the heavy lifting, too. Conventions alone are useless if the work becomes more difficult. It's a vague term but it is pretty darn obvious what the desired intent is behind frameworks and why the endless discussions on their costs and benefits exist. Frankly, most developers couldn't care less…

Easier versus decision avoidance... I don't see the difference. When you have confidence easiness is dictated by the goal, not the approach.

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

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

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

In my current job, I have written a small framework. It's very limited in scope and hasn't changed much since the initial implementation, so it works fairly well. But, there is a big issue with getting other team members to understand how to use it. That alone is enough that we're replacing it soon.

Another team member has developed frameworks for both infrastructure management and creating services exposed over http. Here there is a large value in using the same internal tooling over 20+ projects. But once again, being an internal-only tool means that the documentation is severely lacking, and often we need new features in the frameworks. All of that is essentially blocking on the single team member. In this case we're keeping the frameworks, but it definitely has its caveats.

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

#399

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…

> 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

I don't think you're even being reductive; it's just irrelevant. The saying is to do with the software you're writing right now - do you include a framework (e.g. Django, Ruby on Rails, Spring) or do you include libraries that you could swap out (e.g. Flask - which terms itself a "micro framework", but is a library for this definition, ReactJS, SQLAlchemy) and your code is in control. You're right that the code will run on one or more operating systems, but abstracting out that far elides the useful conversation application developers can have about eggs and baskets.

> the code you write is actually a pretty small percentage of the total code that makes up your system/application

This is almost always true, but seems again irrelevant. How I write my application is worthy of discussion in and of itself, if for no other reason than, with a few exceptions, I'll spend a lot more time and money on making my application than I will thinking about how the Linux kernel works.

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

#400

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

Once you go to the grocery store and pick the 25 different libraries fundamental to your application, congratulations! You've created a completely new interaction between those sets of libraries and you get to debug those interactions instead of your own code for a portion of your time.

I've seen this with python flask REST environments where folks pull all these tiny pieces off the shelf and stitch them together. Meanwhile Django REST Framework has a mostly common baseline that you adopt and then diverge from as needed.

Post reply on HN