Hacker News Reader

Comment by setr | Hacker News Reader

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.

View on HN

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.

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.

Flask might be better than React, but it's still a framework. The ideal framework is just a library, which nobody is arguing against.

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.

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.

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.

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

Reply on news.ycombinator.com