4 ms·

Likewise, rich frameworks like Django, Laravel, and Rails tend to handle needs you didn't anticipate. They build collective experience and familiarity into your

by brylie 6y ago

Likewise, rich frameworks like Django, Laravel, and Rails tend to handle needs you didn't anticipate. They build collective experience and familiarity into your project far beyond the capacity of a single organisation. For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.

enriquto 6y ago
> For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead. You cannot seriously believe this.
- brylie 6y ago
  For example, some Django projects implement only a REST interface. Since those projects don't rely on HTML templates, they don't likely incur any runtime costs from Django's template modules. In effect, you can choose which parts of the Django project you import. The parts you don't import aren't likely to get in your way. I think this is generally true for modular software.
setr 6y ago
The problem I think is the inversion of control — django owns your code; you’re just a citizen within its confines. You’re typically hooking into the framework’s runtime, and thus everything you do is mediated by the framework — great when you’re doing what the framework wants you to do, and a massive PITA when you stray from the golden path. Not to mention it bifurcates the library ecosystem — you end up with a react forms library versus an angular forms library versus a vue forms library that are all fundamentally the same yet somehow split, by nature of the framework they hook into.
- fermienrico 6y ago
  On the other side of the fence: Your own shitty framework owns your code, it locks you into this custom frankenstine thing that is a ball of mud that also smells bad. No one wants to look at it, it brings the best developers to their knees and the docs are impossible to relate to. One dude knows how it works and the tech debt is deep. I'll take a Django project instead, thank you very much. This is an age old discussion about appropriate abstraction.
  - tartoran 6y ago
    You seem like you didn’t really read the article so whatever you say here is not quite relevant. Using a framework is not excluded and they certainly have their place, but it really does depend on the project or the organization the system is developed and run in. There are places where a web framework is entrenched at a core of a business and Im sorry to say it but this is really misguided. Just using a framework doesn’t absolve you of the responsibility of architecting and thinking a solution through. Spaghetti with mudballs is not shy to take over code that happens tobe written in a framework, it is just a function how much care is given for a codebase. In cases where a frameworks help it does provide some structure that can be used as an organizing unit but it should not be followed dogmatically.
  - 6510 6y ago
    > This is an age old discussion about appropriate abstraction. It's not finished. I think the last change was that you don't need to worry anymore that something awful might be hiding under the hood. Sitting there, waiting to take your project where no man wants to go.
- cryptica 6y ago
  This argument makes sense. One of the principles I abide by for all my new projects is that I want the dependencies to be more generic (not specific to the current business domain) than their dependents. The code hierarchy 'tree' is made up of components which are generic at the leaves but as you get closer to the trunk, the logic becomes more fitted to the business domain. A framework is generic and yet it requires to be used as the trunk (entry point, top level wrapper) of the project so it reduces the flexibility of the code. Sometimes this is desirable (e.g. maybe reducing the flexibility helps to scale), sometimes it doesn't add anything.
- abunuwas 6y ago
  I feel the influence of the framework is stronger in the case of libraries like vue, angular, or react. In those cases, your application lives within the shell of those frameworks, and migrating to a different framework means reimplementing almost everything. Frameworks like Django, Flask, FastAPI and others are different. It depends how you use them, but they're just libraries for the interface layer of your application. Like you say, inversion of control is the key: you want to make the interface depend on your code, and not the other way around. It should be possible to switch between frameworks without having to make changes to your controller/business layer.
  - akvadrako 6y ago
    Flask might be better than React, but it's still a framework. The ideal framework is just a library, which nobody is arguing against.
- globular-toast 6y ago
  Django is for receiving and responding to HTTP requests. If you want to do something that isn't that then I don't know why you would even use Django. In Django you can write views as functions where you receive the request as an input and return the response. What you do inside your function is completely up to you.

by brylie 6y ago

enriquto 6y ago

> For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead. You cannot seriously believe this.

brylie 6y ago
For example, some Django projects implement only a REST interface. Since those projects don't rely on HTML templates, they don't likely incur any runtime costs from Django's template modules. In effect, you can choose which parts of the Django project you import. The parts you don't import aren't likely to get in your way. I think this is generally true for modular software.

setr 6y ago

The problem I think is the inversion of control — django owns your code; you’re just a citizen within its confines. You’re typically hooking into the framework’s runtime, and thus everything you do is mediated by the framework — great when you’re doing what the framework wants you to do, and a massive PITA when you stray from the golden path. Not to mention it bifurcates the library ecosystem — you end up with a react forms library versus an angular forms library versus a vue forms library that are all fundamentally the same yet somehow split, by nature of the framework they hook into.

fermienrico 6y ago
On the other side of the fence: Your own shitty framework owns your code, it locks you into this custom frankenstine thing that is a ball of mud that also smells bad. No one wants to look at it, it brings the best developers to their knees and the docs are impossible to relate to. One dude knows how it works and the tech debt is deep. I'll take a Django project instead, thank you very much. This is an age old discussion about appropriate abstraction.
- tartoran 6y ago
  You seem like you didn’t really read the article so whatever you say here is not quite relevant. Using a framework is not excluded and they certainly have their place, but it really does depend on the project or the organization the system is developed and run in. There are places where a web framework is entrenched at a core of a business and Im sorry to say it but this is really misguided. Just using a framework doesn’t absolve you of the responsibility of architecting and thinking a solution through. Spaghetti with mudballs is not shy to take over code that happens tobe written in a framework, it is just a function how much care is given for a codebase. In cases where a frameworks help it does provide some structure that can be used as an organizing unit but it should not be followed dogmatically.
- 6510 6y ago
  > This is an age old discussion about appropriate abstraction. It's not finished. I think the last change was that you don't need to worry anymore that something awful might be hiding under the hood. Sitting there, waiting to take your project where no man wants to go.
cryptica 6y ago
This argument makes sense. One of the principles I abide by for all my new projects is that I want the dependencies to be more generic (not specific to the current business domain) than their dependents. The code hierarchy 'tree' is made up of components which are generic at the leaves but as you get closer to the trunk, the logic becomes more fitted to the business domain. A framework is generic and yet it requires to be used as the trunk (entry point, top level wrapper) of the project so it reduces the flexibility of the code. Sometimes this is desirable (e.g. maybe reducing the flexibility helps to scale), sometimes it doesn't add anything.
abunuwas 6y ago
I feel the influence of the framework is stronger in the case of libraries like vue, angular, or react. In those cases, your application lives within the shell of those frameworks, and migrating to a different framework means reimplementing almost everything. Frameworks like Django, Flask, FastAPI and others are different. It depends how you use them, but they're just libraries for the interface layer of your application. Like you say, inversion of control is the key: you want to make the interface depend on your code, and not the other way around. It should be possible to switch between frameworks without having to make changes to your controller/business layer.
- akvadrako 6y ago
  Flask might be better than React, but it's still a framework. The ideal framework is just a library, which nobody is arguing against.
globular-toast 6y ago
Django is for receiving and responding to HTTP requests. If you want to do something that isn't that then I don't know why you would even use Django. In Django you can write views as functions where you receive the request as an input and return the response. What you do inside your function is completely up to you.