I think you can leverage these criticisms at about 90% of the framework software out there written in just about any language. Most developers like to create complex, complicated software mainly to show off their "cleverness" without thinking through the implications for the people that have to use it. It's as if they think that by cramming in every design pattern they can think of and using many different libraries together for no perceptible reason makes the software better when they could've achieved the same thing much more simply and cleanly if they had put a little thought into it. Such over-engineering is equally a problem as the spaghetti code of programmers who don't know better.
I'm not too familiar with Django but with several other frameworks and I definitely feel like this applies to lots of them out there.
In my experience though, I've worked on teams with developers who criticize frameworks for those reasons, choose a minimal or no framework at all, and spend a ton of extra, unnecessary time reinventing a worse version of a framework they decided 'sucked' once they realize they need security, error handling, form processing, an ORM etc... Over-engineering is an epidemic.
I almost went down this route on a project once. As soon as I noticed myself writing an identity map, I slapped myself in the face and just downloaded Symfony.
Funnily, this is the reason I adore Slim so much. In the PHP world, it gives me exactly what I require in a framework, and nothing else. Slapping it on top of a well-defined class heirachy becomes a simple exercise. I like it so much, that I'm porting it to Hack/HHVM[0]!
Symfony is awesome but I feel they try to stuff too much into the default framework configuration. I don't want all those silly annotations, for example.
Django actually seems to be one of the least offensive frameworks to me in that respect. It didn't really try to be clever and it did things that made sense with a minimal amount of magic.
Great point. That's probably the worst case, IMO, along with over-engineering and plain spaghetti. I should have mentioned it, but I think my PTSD from dealing with such engineers and projects is still overwhelming.
One of the more simple litmus tests I use when evaluating a framework: Does it provide (and require you use) its own versions of data types already provided by the language (or the language's standard libraries)? If so, it's a big red flag. Not necessarily a reason to disqualify, but definitely cause to apply extra scrutiny.
The thought process is: If I have to spend precious development time converting all my std::strings to and from YourStrings, then I can bet that there is plenty more un-necessary cleverness and complexity waiting to bite me once your framework gets its claws into my code.
There are many reasons not to use std::string, some of them more valid than others.
Judging a C++ framework by whether it implements its own string type probably isn't a good idea. C++ is inherently limited, and a string type is often the only way to have certain design guarantees. In a performance-critical context, it's sometimes crucial to control the exact pattern of allocation. And not just how they're allocated in memory, but also how often they're allocated. You can control std::string's pattern of allocation by using a custom allocator, but you can't control how often std::strings are created, for example, because std::string implements an interface which is guaranteed to construct temporary strings. This normally isn't a problem, but in contexts where every millisecond is crucial (like gaming) this can be disastrous, since it's very hard to optimize the performance characteristics of std::string once it becomes pervasively used throughout your codebase.
Another reason to make your own string type is for proper unicode support. Maybe C++11 or C++14 added features to help with that, so maybe this is less valid nowadays. I haven't kept up.
>One of the more simple litmus tests I use when evaluating a framework: Does it provide (and require you use) its own versions of data types already provided by the language (or the language's standard libraries)?
