6 ms·

> was based on md5 hashed passwords without a salt. I kid you not. Yikes. :) Well yes, I suppose it comes down to where you draw the line about what should be

> was based on md5 hashed passwords without a salt. I kid you not. Yikes. :) Well yes, I suppose it comes down to where you draw the line about what should be coupled or not, but perhaps more importantly is the ability to opt-out of certain components or be able to substitute them. For me personally, I mostly care about separating the common service tiers (e.g. frontend/clients, server/api, database/queue/etc). Django's ORM works with multiple databases and is entirely optional either way. Also it has little opinion of how the frontend should work. This is great because we've used at least four different databases and three different frontend JS frameworks with Django. I'm confident any of the service tiers could be replaced (including the Django tier) without disrupting the others.

sametmax 10y ago
> to opt-out of certain components or be able to substitute them. I agree. One of the problem I see currently is that you have either: - a good integration and a huge coupling - loose coupling but poor integration A good framework must provide movable parts to customize your stack, but a high level API to integrate the default provided part together to that if you don't swap them, they feel like a whole. I used vues, react, jquery and angular with Django, and I love the fact it doesn't requires me to use a particular front end tech. But I wished at least a contrib app would provide some help for the front end: routing, auth and all are just not DRY ATM.