6 ms·

I personally categorize frameworks into heavy and light frameworks. I don't have very good explanation what I mean by heavy/light framework, this is the best I

I personally categorize frameworks into heavy and light frameworks. I don't have very good explanation what I mean by heavy/light framework, this is the best I can do at the moment: Heavy frameworks in my understanding are the ones that force constraints on your development process, application design, choice of other technologies and frameworks, on the types of products you can make with it, etc. On the other hand light frameworks are like extensions of your fingers. They don't pretend to know better than you what you are trying to achieve. They just make a particular task easier for you. The issue here is that heavy frameworks do not compose together very well. You can safely have one heavy framework in your application. When you start putting multiple heavy frameworks, they start colliding with each other and you start spending more and more time on resolving various problems that are not inherent to the domain problem that you are trying to solve but rather are completely accidental due to the technology choices you have made.

foxbarrington 5y ago
I think of it as whether or not your app is a cog in the framework machine or the framework is a cog in your app machine.
- mejutoco 5y ago
  This is a useful perspective. I have often seen the first case called framework, and the second library.
  - denton-scratch 5y ago
    > useful I don't agree that it's useful (not sure if you were being ironic). All of the "frameworks" I've used were determined to make my cog their subject. I haven't come across a framework that was content to be a cog in my machine. [Edit] Subject, as in royal or imperial subject.
    - mejutoco 5y ago
      Not being sarcastic. Let me rephrase, because I think we are saying the same thing. No framework was happy to be a cog. The ones that were I like to call libraries instead. I say this point of view is useful because it seems like an elegant/simple way to distinguish them.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
echelon 5y ago
Another perspective is whether the framework is declarative or imperative. If your code describes what is to be done without making the motions itself, you're using a very heavy framework or, honestly, DSL. These types of frameworks have lots of magic built into them and favor convention over configuration. If your code performs actions imperatively, and moreover if it's explicit rather than implicit, then it can be easy to wrap or replace the framework. It's like a library.
- andybak 5y ago
  I've always liked Django's balance of declarative and imperative. The former gives you a clean and terse approach for the common use cases but there's always an escape hatch into the latter.
- DeathArrow 5y ago
  But some frameworks allows you to have both convention and configuration. In ASP.NET you start with convention, which is good for the development speed. If you need to replace a functionality provided by the framework or do something in another way, you can do that with ease.
dnautics 5y ago
I think you want a framework that is heavy but swappable for stuff that is critical and easy to get wrong (e.g. authentication, http header parsing, input validation, routing, preventing sql injections etc) most of these things are "finalizing" concerns anyways, so you don't really need them to compose. And light for everything else (e.g. authorization, operations, templates, etc).
- lmilcin 5y ago
  Being able to swap things out is one way to make a framework lighter. Light ones: if I have a problem with the framework, I am guaranteed to have a local solution without getting rid of entire framework. For example, if Spring Framework does not let me create an object in a particular way, I can write my own function to create the object. If the way configuration is being located does not suit me, I can replace the mechanism without getting rid of Spring Framework or even configuration -- just by implementing couple of interfaces. Heavy ones: if I want to do something that has not been planned for by framework creators I can potentially run into problems that I have no way out of without getting rid of it all. An example would by systemd: it is built in an unnecessarily heavy way by insisting on you using it all. For example, if you don't like journald or can't use it for some reason -- tough luck. The only way to get rid of journald is to get rid of entire systemd.
  - archeroed 5y ago
    artix and devuan devs like this post.
selfhoster11 5y ago
Composing light frameworks can make for a frustrating developer experience. Individually lighter, when combined, the end result may end up more "uneven" compared to the cohesion of a single heavy framework. VS Code is one example of the composition of lights approach.
- treeman79 5y ago
  Rails community sees this a lot. Rails is fairly heavy and there are some great lightweight solutions like Sinatra. But what I’ve seen many times is that by the time you finish adding all the missing bits you end up with something as heavy as Rails, but non-standard. So now maintaining it is a huge burden.
  - andybak 5y ago
    Yep. Been there with Django vs (insert flask based solution here)

foxbarrington 5y ago

I think of it as whether or not your app is a cog in the framework machine or the framework is a cog in your app machine.

mejutoco 5y ago
This is a useful perspective. I have often seen the first case called framework, and the second library.
- denton-scratch 5y ago
  > useful I don't agree that it's useful (not sure if you were being ironic). All of the "frameworks" I've used were determined to make my cog their subject. I haven't come across a framework that was content to be a cog in my machine. [Edit] Subject, as in royal or imperial subject.
  - mejutoco 5y ago
    Not being sarcastic. Let me rephrase, because I think we are saying the same thing. No framework was happy to be a cog. The ones that were I like to call libraries instead. I say this point of view is useful because it seems like an elegant/simple way to distinguish them.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

echelon 5y ago

Another perspective is whether the framework is declarative or imperative. If your code describes what is to be done without making the motions itself, you're using a very heavy framework or, honestly, DSL. These types of frameworks have lots of magic built into them and favor convention over configuration. If your code performs actions imperatively, and moreover if it's explicit rather than implicit, then it can be easy to wrap or replace the framework. It's like a library.

andybak 5y ago
I've always liked Django's balance of declarative and imperative. The former gives you a clean and terse approach for the common use cases but there's always an escape hatch into the latter.
DeathArrow 5y ago
But some frameworks allows you to have both convention and configuration. In ASP.NET you start with convention, which is good for the development speed. If you need to replace a functionality provided by the framework or do something in another way, you can do that with ease.

dnautics 5y ago

I think you want a framework that is heavy but swappable for stuff that is critical and easy to get wrong (e.g. authentication, http header parsing, input validation, routing, preventing sql injections etc) most of these things are "finalizing" concerns anyways, so you don't really need them to compose. And light for everything else (e.g. authorization, operations, templates, etc).

lmilcin 5y ago
Being able to swap things out is one way to make a framework lighter. Light ones: if I have a problem with the framework, I am guaranteed to have a local solution without getting rid of entire framework. For example, if Spring Framework does not let me create an object in a particular way, I can write my own function to create the object. If the way configuration is being located does not suit me, I can replace the mechanism without getting rid of Spring Framework or even configuration -- just by implementing couple of interfaces. Heavy ones: if I want to do something that has not been planned for by framework creators I can potentially run into problems that I have no way out of without getting rid of it all. An example would by systemd: it is built in an unnecessarily heavy way by insisting on you using it all. For example, if you don't like journald or can't use it for some reason -- tough luck. The only way to get rid of journald is to get rid of entire systemd.
- archeroed 5y ago
  artix and devuan devs like this post.

selfhoster11 5y ago

Composing light frameworks can make for a frustrating developer experience. Individually lighter, when combined, the end result may end up more "uneven" compared to the cohesion of a single heavy framework. VS Code is one example of the composition of lights approach.

treeman79 5y ago
Rails community sees this a lot. Rails is fairly heavy and there are some great lightweight solutions like Sinatra. But what I’ve seen many times is that by the time you finish adding all the missing bits you end up with something as heavy as Rails, but non-standard. So now maintaining it is a huge burden.
- andybak 5y ago
  Yep. Been there with Django vs (insert flask based solution here)