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…
Using a framework will harm the maintenance of your software
391–400 of 550 posts
Re: Using a framework will harm the maintenance of your software
#3921. 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…
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
#393Earlier 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…
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
#394Earlier 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 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
#395Traditionally, 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
#396Earlier 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…
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
#397Earlier 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…
Re: Using a framework will harm the maintenance of your software
#3981. 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…
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
#399Earlier 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 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
#400That brings up the old debate between framework vs library. My personal conclusion had been don't use frameworks, rather use libraries.
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.