I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple. Django has a monstrous "middleware" piece and a bunch of other cruft that is really just bothersome dead weight. It's not that there's no use for it, it's just that similar things are accomplished in much more concise, fast ways in other frameworks.
Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put into the system. But I don't think it really has much to offer in present-day for people developing new, serious platforms. I feel the same way about most other "full-fledged" MVC frameworks, because they all seem to far exceed what ought to be the logical bounds of their influence. In many cases you feel like you're writing Django, Cake, or Rails and not writing the actual language based on, because these frameworks mandate so much and require special integration to do much of anything. In something like Pyramid, you write Python, and Pyramid provides the pieces that make it easy to bundle together and publish as a website.
I've had positive experiences with Sinatra, too. "Microframeworks" and close cousins like Pyramid are really much more appropriate dev platforms, imo: modular, unpretentious, exist simply to help you get your program onto the web in a fast, concise, and simple way, without attempting to inject a rewrite of the standard lib or force you to conform to their unique flavor of MVC, their crappy ORM, etc.
I develop a new, serious, widely-used platform and I love Django. I've definitely been around the block, have developed python-based web apps without frameworks, etc.
I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.
>I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.
I don't really understand this. Other frameworks don't require you to "make a decision about every little thing" either. It's not like they're just a blank file that says "<WRITE FRAMEWORK CODE HERE>". They come with defaults, things that are in place automatically. They come with suggestions and recommendations for optional stuff. They come with docs and tutorials. They just don't make illegitimate mandates, they don't revolve around a specific ORM or a specific template.
If you start a clean Pyramid project with the "alchemy" scaffold (recommended) right now, you'll have Chameleon, SQLAlchemy, and URL routing automatically chosen for you. You don't have to make any more decisions. You just have to open up views.py and start coding.
To you it may be "illegitimate mandates" but to a django dev it's a blissful ignorance. You might just have to agree to disagree.
Let's say you want to add a column to your database. Because the django ORM is so popular and monolithic, it has amazing tools for the job that do it auto-magically when you modify models.py. And that's just one facet of many.
For some folk, the flexibility of Pyramid is nothing but a bother.
No, because you don't have to use the flexibility. Pyramid comes with defaults. You can blissfully just use what comes out of the box, or you can, relatively easily, use something else. There is no cost to the programmer who simply wants to ignorantly use the default tool set.
I've used pretty much all of the major python frameworks in a professional capacity, and have also dipped toes into the RoR world as well as the various php frameworks. Django isn't "the one true way" - I've been known to reach for Tornado often - but it certainly works (ORM, templates, middleware included) for the majority of projects I've undertaken, and I've had success advising others to adopt it.
Also strange to hear that Django has a unique style of MVC, it seems pretty standard to me (and from what I see a lot of new frameworks are aping it).
> Also strange to hear that Django has a unique style of MVC, it seems pretty standard to me
some people are confused because of the semantics (view is controller, template is view). in the end, as you say, it's still (yet another flavor of) MVC.
I don't intend offense. I'm just suggesting an explanation for why you may feel Django is not problematic. When all you have is a hammer, everything looks like a nail. I've met many-a-programmer fairly early in their careers who praise things like Cake, Rails, or Django, but in my experience at least, as they mature, they prefer less invasive solutions.
My 2 cents in response: I use C#, JavaScript and Python daily. I spent 6 months learning Ruby but decided it wasn't for me. I also use Objective C for iOS and enjoy optimising SQL in my database layer.
However the three platforms I use in order are .Net MVC, Django and node.js. Before I chose Django I wrote my own Python-based web framework but decided I'd rather build applications than frameworks. Django has a massive community built around it that I couldn't find anywhere else (note - I _have_ been using Django since 2007).
The main reason I use Django? because I, personally, know what I'm doing, where everything lives and can get it done quickly. It works for me and it clearly works for other people, so you can't knock it.
What I _wouldn't_ do, is advertise for a 'Django' developer. You have to know Python and understand what your framework is doing under the hood.
Django is great, I'm sure Pyramid is great as long as you understand what it's doing and have read the code, but most importantly, what we all are is Python programmers.
In a few years you'll probably get to the point where you don't prefer less invasive solutions but will pick the right tool for the job.
If you know you'll be iterating rapidly but will stay within the confines of 'standard CRUDdy app' then e.g. Django, RoR, Spring Roo e.a. will be probably be good to you. If you expect to go beyond those confines you'll be burnt.
In general it's about finding what I like to call the 'grain of the tool' and pick the ones where you can go with the grain.
I prefer less invasive solutions because they are generally the right tool for the job for serious web platforms, which is the niche to which I limited my comments. And for the record, I've been around for some years.
If I just want a basic CRUD app that will basically never exceed the capabilities of Django's automatic admin interface, then sure, Django will be fine for that because all I'll have to do is define models and I'll be done. I can then query the SQL database directly if necessary, or write a separate application that generates reports on the data.
Most "serious platforms", however, do much more than this. For platforms that run companies, least-invasion is a good principle, because it allows you to adapt quickly as changes are necessitated. Django, Rails, et al often world-break if you try some "funny business". Next-gen frameworks like Flask and Pyramid have almost no reasonable condition that qualifies as "funny business" from the framework's perspective, so they're much easier to iterate upon or pivot from.
> serious web platforms, which is the niche to which I limited my comments
That is exactly the kind of grain I was talking about.
If you were running a startup that's focusing on finding product-market-fit and quickly iterating on the UX to get conversions up and attrition down Django (or RoR) might be a better fit.
When you start outgrowing Django you can just start splitting off components and rebuild them in a more 'serious' way.
you're doing an terrible job explaining your beliefs. you come across as mostly incoherent with an ideological obsession with "unobtrusiveness". to me that sounds like an indicator of a barely contained case of not-invented-here syndrome.
maybe you can explain your language more explicitly and help alleviate the bad impression I (and others) have got from your posts. what is a "serious" web platform? how is django less appropriate for "serious" web platforms than Flask or Pyramid? can you give an example of something breaking due to django "funny business"? it would help if you gave a real example. i've seen people complain about this alot but i've never seen an example of it causing any more problems than an annoyed developer having to do it django style instead of whatever way he/she wanted to (due to ideology).
Just as a note to everyone, you can use Mako/Jinja2, SQLAlchemy and really any other Python tool/library out there with Django.
What Django does well is provide a pre-built and (IMHO) easy to use set of default tools. This does not mean that you must use these tools, they are just there by default if you need them. You could really just use Django as an HTTP routing tool.
I admit it's been a while, but when I tried django-sqlalchemy in the past, it was not in a pleasant state. Last I came around, it was certainly not just a simple drop-in thing.
While I'm sure you're right that it's not a hard requirement in that you can figure out how to make it work, it's not an easy thing, and you'll be fighting the framework and the conventions all along the way as interdependent stuff stops working. Again, in my experience. If things have improved significantly, I'd like to know.
When toys ship "batteries included", it's easy to pull them out and replace with a different brand, if you want. Django, and most other web frameworks, don't make that interoperability a serious concern, afaik. When you use a framework, you are essentially adopting its code into your project all at once, and you become responsible to make sure it works and adapts to your needs even if upstream dies out or makes a decision that renders new versions unusable for your use case. "Non-removable batteries" are therefore a major design flaw in your project, even if you haven't had occasion for it to be exposed yet. The batteries of monolithic, "opinionated" web frameworks like Rails and Django may be partially removable, and maybe they've improved recently, but newer frameworks like Flask and Pyramid don't have this issue at all, and it makes them much more flexible.
Just wondering if you have any tips (that you recall) for making django and sql alchemy work together. sql alchemy seems like the best ORM to work with and django has a nice ecosystem. If sql alchemy only does read operations on django models, will that make the integration simpler?
For people developing new platforms I think Django has a great deal to offer and should be a serious contender if you are looking into Python based web frameworks.
A few specific things I like about Django:
1. A decent app ecosystem
2. Lots of documentation and a fairly mature codebase.
I never really loved them until I started working on a massive Django project with Oracle. South doesn't support Oracle, and now I have to manually tweak tables every time I update a schema.
The company I work for just switched _to_ south from a custom migration system and it has been really awesome. It streamlined out development process a bit as well.
He never said they were specific to Django, he was mentioning a few specific things he liked about Django.
It's great you like Pyramid, but honestly, a lot of this is just a matter of taste. I personally find the way Pyramid fits together and its documentation less appealing than Django. In my dabblings with Pyramid, I found the community less responsive and helpful. But that's all subjective and anecdotal, just like your take on Django (which is why this is a boring discussion).
The truth is, good engineers can do great things with far less than Django or Pyramid. The choice of framework is a very boring discussion, since most modern, widely used options are going to be "good enough" in the right hands. Your idea and its execution are front and center. If you're sufficiently skilled, your framework shouldn't be a huge factor in your execution.
Pick something that you like, and just get to work.
Right, I never said it was impossible to build something useful in Django. I just believe it's a non-optimal choice, in almost any situation. I don't believe "it's just a matter of taste" to have a web framework that knows its place and makes it simple to adapt, or unpretentiously allows you to code with minimal rigidity. I don't find any contrary arguments presented thus far convincing.
Saying that Pyramid's documentation and overall "fit" is "less appealing" is a matter of taste. Indicating that Django is much bigger is a matter of fact, and that it provides little if any additional benefit and increases rigidity and practical obligation to conventions is a matter of informed analysis. The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done.
It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived. it's nothing personal to Django or the people involved in it (I've even submitted patches, but to my knowledge, they were not merged). It's just a thing that has been superseded, and that happens in tech. Now it's just a matter of how long until everyone else can drop the religion and admit they're wasting time on compliance and rigidity that shouldn't be there.
I'm not saying Django is the least productive framework in existence. I'm not saying it'll ruin your company or life if you use it. I know people who use it and we are able to get along. I work with it occasionally. I'm just saying, "it's unwise", for almost any large-scale new project.
> I just believe it's a non-optimal choice, in almost any situation.
And this is where your argument loses every bit of credibility, this is an awful, unsubstantiated blanket statement. I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day.
> The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done.
I think you're missing the point entirely. Your claims of rigidity aren't applicable for everyone. For a very large number of users, Django doesn't need to be super de-duper modular/interchangeable (it's good enough for many/most). In fact, some people don't want the complexity of SQLAlchemy. Some don't even know/care what jinja is (I personally haven't felt the desire to switch to it, as I feel it has problems of its own).
Django is batteries included. Pyramid is not. These are two different approaches that each have tradeoffs.
> It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived.
Again, not everyone wants these pieces you are talking about. While SQLAlchemy is a great piece of a software, it is a complex piece of software with a steeper learning curve than the simple Django ORM. There are plenty that don't need/want something as heavy duty as SQLAlchemy. In my case, if I need the absolute best performance or advanced features, I am writing SQL instead of dealing with any ORM that makes bad choices for me. More ORM is not attractive to me, I tend to dislike them for anything but the most simple cases (ie: the basic Django ORM operations).
That is where your blanket statement falls to tatters. Differing requirements, different priorities.
> I'm just saying, "it's unwise", for almost any large-scale new project.
And not all advice is created equally :) I'd say that it is appropriate for some large-scale projects and teams, and inappropriate for others. It's flat out wrong to make a blanket statement like yours.
No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture.
If you want simple, you can use adaptive frameworks simply. They come with defaults just like Django does. The difference is that it's easy to swap or mix-and-match components, and it's an intended use case. On Django, if you don't go with vanilla, it's a hack.
As I wrote elsewhere, "batteries included" doesn't (or shouldn't) mean "batteries hard-welded". It's fine to include stuff and have defaults; adaptive frameworks have these too, but they considered the fact that someone may want to do something irregular at some point and that it shouldn't be a world-breaking experience for that to happen. A framework that understands its place is all gain, in that it doesn't intrude and try to force something, and no loss, in that it also comes with defaults that you can just use if you aren't yet at a stage where you'd have a reason to replace them, and therefore, from an objective technical standpoint, it is a better choice. Perhaps social issues override this in some situations, but those can't be considered in our removed, objective, technical context.
>I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day.
It doesn't matter if there are success stories. I'll repeat myself, I guess, and say that I don't intend to say that Django is useless or terrible or that it does nothing and will ruin your life. The point is that most people who choose Django for technical (not social like "we all already know django") reasons are making an incorrect choice. For now "we all already know django" is acceptable, just like "well we all already know SVN" was, but at some point it won't cut it anymore, and you'll be expected to adapt.
>Django is batteries included. Pyramid is not.
I disagree. Pyramid comes with batteries. It has a full stack ready to go for you if you just want to open it up and code, just like Django does. The difference is that Pyramid allows you to tweak or swap freely as necessary, and Django makes it difficult.
>It's flat out wrong to make a blanket statement like yours.
No, it isn't. My blanket statement is generally but not all inclusive. Is it wrong to say "Using Windows 2000 as the primary hosting platform for new projects is almost always wrong"? Things change in tech. Rigid generic frameworks that try to dictate templaters and ORMs are old hat, they are plainly incorrect for all but the most esoteric use cases. There is no good reason to do this.
Is Django going to disappear overnight? No, but I hope that people can get past their holy wars and take a serious objective analysis. Consider that you're actually against a useful feature set just because the less-powerful solution is often "good enough". That's not a reason to choose a thing, it's just a reason not to flee from a thing. I'm not saying every Django app needs to be rewritten, but I do think it's silly to settle on "good enough" for new stuff when "much better" is available at little or no downside.
> No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture.
This reminds me of when ROR came out and "opinionated frameworks" were the new black. I can kind of see where parent is coming from - lightweight frameworks are lightweight because they rely on external components (eg, ORM, form-handling libraries...) which are so many moving parts, and not always well integrated with the framework. On the other hand, I've found that the Flask plugin ecosystem works pretty well as very lightweight glue with other components.
And let's face it: even with a "batteries included" framework, you'll eventually have to go out and get a third-party battery which was not included.
Django rigidity with the ORM and template language brings one major advantage: Reusable applications developed for Django are pretty much guaranted to use them. So you can aggregate them without having to deal with 3 different ORM or template languages.
Yes, django reusable apps are not always top notch quality and always maintained properly. And sometimes you will need to dicth all the templates and create your own. But you sometimes get an important piece of software for free or at least a good base to start your work.
I feel that with a more "flexible" framework the integration of apps coded by different teams will be more problematic.
I'm sorry, there are just too many absolutes and far too much hyperbole in your response for it to even be taken seriously.
This "Rigid" term you keep throwing around is absolutely ridiculous. It seems to be the entire basis of your argument, but you fail to back it up at all. Django makes some decisions for you, but you can almost always go another route. It's all just Python.
"<Vague blabbering about 'rigidity'>. Boo Django, yay Pyramid!" - cookiecaper
The problem is that someone has to create that project as anything more than a shim in the first place. There is no reason a generic web framework should require a full-fledged compatibility effort to switch out what should be "just another library". Note that there are several incompatibilities with "true" Jinja2 at the bottom of that readme, and that support for built-in "Django tags" is necessary.
This is far less adaptable than Pyramid, which makes most internal functionality like that accessible via the request object, which can be accessed by your template language's typical variable evaluation syntax, and which can use Mako or the default Chameleon with just a one-line configuration change, or Jinja2 and others by installing a simple shim layer that is mostly boilerplate.
Personally, I've tried to use mako with django and found it unwieldy to pass the correct information across the controller-template barrier. This was some time in the past, however, so perhaps either the adapter or documentation has improved and the problem no longer exists. The real issue, however, is that a generic web framework would make it difficult to replace unrelated user-facing libraries in the first place.
Given the callback nature of the Django templating library with template tags, includes, and other goodies, it is not as simple as "call foo_template() and return string". As soon as a template tag is involved, internal data structure needs to be exposed, with makes * everything* much harder.
Jingo serves purely as a minimalistic bridge between Django and Jinja2. Coffin attempts to reduce the differences between Jinja2 templates and Django's native templates.
If separation of duties is a concern, Django's templates (IMO) get it more right than anything else.
I remember, at one point, that I felt Django templates were limiting me, and started swapping them out piecemeal for Jinja, and my designers started to absolutely hate me. Not because they had to convert anything, I converted everything by hand, but just that the amount of syntax you can cram in there keeps everything less pure.
Since then, I realized I was trying to do too much in the template and started putting things where they belonged, and now, whenever I work with Jinja or Mako, it feels a little too much like editing Wordpress themes or something in PHP.
Long story short, I learned the hard way that if you're putting logic in the templates, you're probably doing something wrong, and I agree that it is not only a reasonable design, but a very good suggestion as well.
I built http://www.modewalk.com/ from scratch using Django. I do have "plenty of exposure", and the default template engine worked just fine. The default ORM is just fine. Most of the defaults are just fine.
Hey, very interesting site indeed. I had a few questions about what other stacks/technologies you've made use of. Drop me a line or two on rashid.aden.omar@gmail if you could. Thanks
Again, the issue isn't whether "the defaults are just fine". It's a larger design problem, where a framework makes illegitimate assumptions and imposes illegitimate requirements, making it difficult to swap out components that shouldn't be mission critical. This is excused as "opinionated design", which, as I explain in another comment, is another way to say "bad design with an attitude".
It is very easy to say "Django has large design problems" and go on about how it "imposes ilegitimate requirements". Truth is that Django is a framework and by definition, frameworks give you a way/structure to do things. If you don't want a framework, then there are several other options.
The strength of Django comes from the huge quantity of packages you can swap in/out. You mentioned you don't like the Django Template engine and that Jinja s better. Easy to swap. Don't like the authentication? Swap it out for something else or use a custom one. Don't like the ORM? Dont't use it... sadly you'll be missing out on south which has saved me from sql schema and data migration headaches. Caching? Redis, Memcache, or write your own. It plugs easily. Async processing? Celery is only a few lines of code away. Indexing with Sphinx search or Lucene is trivial. Want to add automatic CSS/JS minification + bundling + sprite generation + cache busting? There are django apps for that. Need analytics? You only need two methods for middleware. I could go on forever... The point is that this is exactly what I expect from a framework. If the framework doesn't do it, the somebody has to - and that means it is me.
It's about the rigidity of the structure given. A framework is supposed to give me the tools and structure I need to do what I brought the framework in to do. On a web framework, that is to pipe I/O over the web, give me access to web-layer stuff like the request object, and provide a few other simple structural niceties like MVC (which itself is quite flexible in Pyramid (optionally, of course)). I don't want it constraining me to the point where the world breaks if I decide the default ORM or template is not making the cut.
As for all the things you've mentioned, it's perfectly plausible to have those things occur in Sinatra/Flask/Pyramid/whatever. The structures they provide are sufficient to hook up the kind of things you've mentioned. It's only that smaller communities have fewer pre-packaged solutions. In most cases, if you're building a new, serious platform, you'll want to use something that you can believe in technically, even if initially you'll have to contribute some of those modules yourself. You must be willing to invest in things you believe in, or they will die.
I am sorry, but I am still failing to see your point. Let me address the specifics issues you brought up:
Accessing the request object? In Django, there is a RequestContext that can be accessed all over the place (e.g. middleware, views, templates or wherever else you wish to pass it through). It has many helper methods that parse several thing only one method call away.
The template engine? I have used Jinja in some projects with Django. It literally takes less than five lines of code to swap out. Look it up.
The Django ORM? Don't make the calls. I have done a handful of projects where doing everything through the ORM would have been a really bad decision since the web app was mostly about being a front end for an analytics system with processing that took from hours to days to complete. Instead, I wrote raw PostgreSQL/PostGIS SQL queries all over the place that ran asynchronous and hooked up Hadoop Clusters for other items... everything being controlled through django-celery. It was really easy to do. The state currently uses it to do "serious" pollution, health and city growth analysis, hence why I fail to see your point.
You mentioned Sinatra/Flask/Pyramid and such. Thore are good frameworks, but you also acknowledge that there are "smaller communities in few cases" and my point is that is exactly where django shines: the ecosystem.
I like to build "new serious platforms", too. To do that, I use whatever is appropriate from Django and the community and I have yet to stumble upon something that keeps me stuck because of the decision I made.
Granted, it is a hammer and sometimes you need a drill. Let me give you an example: One of the apps I needed to write is a realtime geolocation service. For that, I use websockets and node.js because of its non-blocking and persisted connection nature. Does that mean that I need to ditch Django altogether? Hell no, I let the front reverse proxy direct the websocket traffic to node.js and the rest to django. My node.js code is so tiny because it is just a Pub/Sub client proxy. Most of the work is done in async Celery/RabbitMQ workers (that use the Django ORM by the way). Doing this with Django is easy (well, to be fair, the credit should go to the vast amount of python libraries).
I "believe [in Django] technically"... why? Because in the four years I have been using it I have yet to get stuck because of my decision to pick it. I don't use it for everything, but I do for 99% of web related work. Once again to the risk of repeating myself, I pick and choose the Django parts I need in a per-project basis. Funny enough, I still laugh everytime somebody complains about some performance thing and I pretty much see their face jaw drop to the ground when I install varnish in front, change two lines of code to tweak the expiration headers, and deploy the static content with a good CDN. 5x performance is not surprising. Yes, there are several Django apps that make this trivial to do.
Sorry I still don't see the specifics of the points you are trying to make.
Opinionated design is not "bad design with attitude". You may disagree with the opinons, but those opinions are thought through and made for the best interests of all the users. It is not uncommon for you to sit in the outside the "norms" the framework is shooting for, but that is not a problem for either you or the framework. A framework that tries to be all things to all people generally sucks for everybody.
>A framework that tries to be all things to all people generally sucks for everybody.
Right, I agree. I like a framework that tries to be a generic web framework for most people who want to write a typical web application in Python. That seems adequately specific to me. I don't consider that "opinionated design", it's simply identifying a market.
"Opinionated design" is an excuse to make interopability and cross-compatibility difficult. There are, generally speaking, few good reasons to do this. Things that are totally out of scope obviously shouldn't be integrated, but if you feel the need to bundle a certain type of library with your framework, shouldn't it be sensible that someone might want to tweak that someday, or replace it with another library that does the same thing in a different way? Opinionated design is about copping out of that logic and putting a smooth sheen on it, it's saying "OK, we understand this is a reasonable, in-scope requirement, but we're opinionated and cool, like Steve Jobs, so we're just going to say you have to use this library or you're SOL. Remember, we are cool like Apple, and that's why we can tell you off in this fashion". Not "only projects that implement this prudent, adaptive, and objectively important-for-our-use-case protocol will work", but "only this library" or "only this way".
Projects that don't suffer from scope creep or far-fetched, irrelevant integration aren't called "opinionated design", they're simply called "well-managed". It doesn't come from having an opinion and telling everyone else to shove it. It comes from having goals and the discipline, reason, and structure in place to stick to them.
>I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple.
Define awful in concrete terms.
I've not been much constrained by Django in any way.
Even if all of those are "better" in some spec-listing way, Django could still be better by offering better integration for it's tools.
Like the iPhone, in actual use, beats phones that are better than it "spec-wise".
Really not a fan of this terminology, popularized by DHH/37S. The term "opinionated design" is basically an excuse to make a rigid, unadaptable behemoth, because it's easier to just say "if you don't like it, you don't have to use it" than to address some of the problems. There is a balance, of course, and you can't spend all your time abstracting out to support the most transformative, irregular use case, but something like mixing ORMs or templating languages is actually a great example. Look at Pyramid v. Django/the others. A web framework should simply be about piping your program's I/O to the web. Templating and ORM shouldn't even be in scope. Having reasonable defaults is fine, but claiming it's OK to tightly couple your general-use web framework with user-facing unrelated libraries as hard dependencies (i.e., forcing users to use a certain ORM/templater) because it's "opinionated design" is silly. It's simply bad design.
> A web framework should simply be about piping your program's I/O to the web [...] Templating and ORM shouldn't even be in scope.
nope. that's what a server gateway interface is for. giving you a set of reusable tools and conventions to help you work - that's what a framework is for. the scope of the framework can be wider or narrower and it depends what you like - it's just, like, your opinion, man. the so called microframeworks are cool, but they are not a remedy to every problem out there.
> forcing users to use a certain ORM/templater
forcing? not sticking with the defaults and building an exotic combo leaves you out of re-using a lot of the ecosystem apps, but certainly you are not "forced" to do anything.
I think it's important to note that not everyone wants or needs to choose every single component in a project. In fact, this can be a big waste of time and added complexity for some projects, particularly the more simple ones. Even for a larger project, your choice of template language is nowhere near as important as the quality and cohesiveness of your overall design (you know, the actual important stuff). With the move towards heavier API-driven client-side stuff, the choice of frameworks gets to be even more boring.
Django is easy to hire for, it's easy to get help for, it's easy to Google around for. I can plug in an intern and have him productive very quickly due to the great documentation, and the "opinionated" nature of Django (there are widely known best practices for lots of things) is great in this case. He doesn't have to wade through all of my glueing of pieces together, figure out this lesser known, lesser documented, lesser supported framework (Pyramid). He just says "Oh, this is Django, I get it."
I don't make the claim that Django is better than Pyramid, but I think it's probably foolish to do the reverse as well. They are just two different ways of doing things: minimalistic/bring your own lunch versus batteries included.
And you lose a lot of the benefits of Django, to be fair. We use Jinja2 on DrawQuest but it was a bit messy to add back features like the Django context processor.
I'd love to hear more. We are considering Django with Jinja2, primarily because I think some of the Django template opinions are a bit wrong. I don't want to fight one direction in my efforts to keep from fighting another, though. I'd prefer the details I know. :)
Every time I find myself in another platform, working away, there is always a point where I stop and say to myself - I wouldn't be doing this if I was using Django.
> I wonder if perhaps your people just don't have much exposure
Having used and rejected each of the things you mentioned for various reasons, I think you're making the common mistake of assuming that other people have the same challenges and preferences you do.
It's particularly pointless to do this in a project release announcement thread – if it really doesn't work for you, just skip over it rather than flaming.
the only thing I agree with in your entire post is criticism of the django template language. its a pretty bad system that encourages sloppy work arounds. jinja would be nice. fortunately the template system is one of the easier things in django to swap out.
i think you're wrong about the ORM. django's ORM is actually really good, its just that the api is optimized for different use cases than SQLAlchemy. django ORM does a better job of simplifying the most common queries. its worse at complex queries. thats a reasonable trade off and i think you go way too far when you say its "awful".
Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put into the system. But I don't think it really has much to offer in present-day for people developing new, serious platforms. I feel the same way about most other "full-fledged" MVC frameworks, because they all seem to far exceed what ought to be the logical bounds of their influence. In many cases you feel like you're writing Django, Cake, or Rails and not writing the actual language based on, because these frameworks mandate so much and require special integration to do much of anything. In something like Pyramid, you write Python, and Pyramid provides the pieces that make it easy to bundle together and publish as a website.
I've had positive experiences with Sinatra, too. "Microframeworks" and close cousins like Pyramid are really much more appropriate dev platforms, imo: modular, unpretentious, exist simply to help you get your program onto the web in a fast, concise, and simple way, without attempting to inject a rewrite of the standard lib or force you to conform to their unique flavor of MVC, their crappy ORM, etc.