441–450 of 550 posts
Earlier quoted context omitted.
Another, a bit less gray zone, distinction is that you can have only one framework in your program, but can use multiple libraries.
In the Java world, at least, you can absolutely have multiple frameworks in your program.
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…
All a framework means is that there is a coherent, repeatable model for implementing the building blocks out of which the application is built.
Even a simple command line program with hardly any functionality soon runs into the issue of having more than one command-line argument or environment-variable based configs. And a sensible, maintainable approach to this involves someone spotting ‘hey! We can abstract the bits that all our command-line parameters have in common so processing them all is consistent’. And then you have a framework. Because now ‘adding a new command line parameter’ has to be done in the standard way - you register a validator here and you add a help string there.
Building something without a framework is a rejection of patterns, or of the value of establishing repeatable structure.
Software that facilitates encapsulating chunks of functionality as standard building blocks is more maintainable over time. It’s much easier to work on a system where you can take a user story and interpret it as ‘okay, so we can implement that as a new Task type and then add a Tool to the Tool Library that lets users who have the right Role create a Schedule to run the task’. any time a system is sufficiently structured that you can think that way, it’s essentially become a framework.
Frameworks can be lightweight or heavyweight, sure, and they can be open to being overstepped or closed - and choosing when to prefer to structure your framework to make it easier or harder for someone to step outside the lines is just an engineering choice like any other.
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…
> 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…
The interesting thing to me is that this is how Django, one of the canonical big backend frameworks, came into being. It was based on what a newspaper's website's staff were actually using in practice.
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…
Any time a piece of software abstracts a repeatable pattern, that’s a ‘framework’. All a framework means is that there is a coherent, repeatable model for implementing the building blocks out of which the application is built. Even a simple command line program with hardly any functionality soon runs into the issue of having more than one command-line argument or environment-variable based configs. And a sensible, ma…
With that definition all programming languages are frameworks.
The first part of the article defines what the author means by a framework, which is different from libraries, and programming languages in general.
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…
It is quite telling of HN's audience if they honestly think that "every sufficiently complex framework-free application contains a [buggy] half-framework." The precise definition of a framework may be a bit hard to pin down, but most any experienced practitioner knows it when they see it. Things I look for:
* coupling of a blessed architecture, libraries, and patterns. Some choice of libraries may be allowed, but they must conform to a framework-prescribed interface.
* difficulty of isolating behavior for fast unit testing when using framework as prescribed (not always, but this is right more often than I want still)
* inversion of control as a core building block instead of straightforward composition. (This point gets fuzzier in callback-centric langs.)
* main() (or its moral equivalent) ends up being a framework bootstrap call, or is hidden entirely.
* related to last points: emphasis on hiding as many execution details as possible to present a simplified view of what the framework author believes is important.
* reliance on extension points to customize behavior (via subclassing/hooks) rather than simply exposing primitive operations that users can call alongside custom code.
* documentation beyond API docs and tutorials, usually necessitated by the number of novel concepts introduced by the framework
* heavier-than-normal emphasis on marketing, often leading with social proof from a megacorp, sometimes with big promises on how this framework is not like the others
The main takeaway should be this: a framework is not something that wants to blend into the background of your application. It is extremely visible and it is something that you program to, and often must take what it wants into account when designing. Without a framework, you can literally do whatever you want, including making a huge mess, or something small, functional and minimal.
I believe that should disqualify most of the rather absurd claims that all libraries/patterns/libc are "frameworks."
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…
I've written a number of frameworks, plugins, and extensions, and refactored existing ones. I've used a number of them. I tend to customize stuff, which isn't always conducive to using "heavy" frameworks. I've enjoyed "bald" ones. Done some big stuff.
Some came out great ... some ... not so great.
The "not so great" stuff tended to be early in my career. Refactoring existing ones, helped me to learn how to do it right.
I think the first one that I refactored, was PHP Nuke. It emitted terrible HTML, and my refactoring made sure the output would validate (and WAG the dog, so to speak). I ended up binning it, when they did their first upgrade. Learned a harsh lesson, there.
I wrote a framework in Perl. That was ... challenging.
These days, I tend to use a lot of modules and connectors, and use whatever framework is built into the OS (I write native Swift). I've heard great things about Laravel, but I have never used it.
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…
I've tried to answer that in the article. Anything that I should have clarified even more?
Do note that I make an explicit distinction between libraries and frameworks. I'm not expecting a one-man-show to write the SSL libs or even the HTTP routing: there are perfect libs for that.
When this HTTP library lives on the side of your app, abstracted away behind e.g. ports&adapters there really isn't any issue. It could be Sinatra, Flask or such.
My article wasn't meant to argue against code-reuse, au contraire. It was meant to explain that there's "dangerous" code-reuse, and good code-reuse. That with the wrong re-use of existing code, you'll paint yourself in a corner that might easily prove impossible to get out of. Frameworks, I argue, are such code-reuse. Libraries, used and layed out in architectural patterns is, I argue, the alternative that allows for longer living projects.
Earlier quoted context omitted.
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…
I'd say by this definition (your code calls a library, a framework calls your code), Flask is every bit as much a framework as Django; I write functions that are called by the router just like I do for Django views. Sure, I can swap out the ORM and the templating library; I might even be able to swap out the routing library, but here be dragons. But a standard Flask application and a standard Django application are very similar. And if I wrote an application using Flask, it would be more or less a rewrite to swap in something else for Flask, because I'd be depending on Flask's request and response objects, at minimum.
This is partly why I don't think this definition is very useful, too. Clearly Django and Flask are different, but this isn't why.
Quoted post unavailable.
A case was Celery, where despite countless other options for async tasks - we must use Celery because that's what the framework says. It was a bad fit as well.
I do stress that I do not lump all framework proponents in this bucket though - that seems like an overgeneralization.
Earlier quoted context omitted.
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.