Just saw a great conversation with Brian Mann (creator of a lot of Marionette educational material) in the #marionette IRC channel:
@brian-mann: When you're developing non blue print applications (which is every real application) -- all of those customized specific implementation details which control the behavior of the application have to be specified. Those are implementation details are impossible to abstract inside of a framework since those ARE the parts that are unique. But the infrastructure surrounding those bits can be abstracted which is what you get with Marionette
@brian-mann: there's not really any "magic" to backbone nor marionette, its all very straightforward, which is good
@brian-mann: it means you're essentially writing javascript rather than a DSL someone else came up with
@brian-mann: but Javascript being ubiquitous tells me its better to know how to write good javascript than a good DSL
@brian-mann: and at the end of the day, i've worked with other ember / angular devs
@brian-mann: productivity is about the same between an experience marionette vs the other 2
@brian-mann: the difference is really that the other frameworks have a prescribed "best practice" or "best way" to do something, whereas backbone doesn't. at all.
@brian-mann: but i think at the end of the day, when you're building a real application, its hard to make generalizations about the best approach. it's going to depend largely on the use case in almost every scenario. so i think thats a hard pill to swallow but its a more realistic one. you've really got to know what you're doing to build anything substantial, there isn't a blueprint
@brian-mann: its really about knowing a lot of patterns and then assembling those patterns in a method which is ideal for your application
@brian-mann: so instead of teaching blueprints i think we should be teaching patterns, and then the development team pull all of these patterns together to weave an application
This makes a lot of sense and it's inspiring in a way, but at the same time I think it's limiting. We would never have Django if we fully embraced this - we would have a request/response library, a template library, an ORM library, a forms library, etc. People would mix and match, you'd see a lot of people using Jinja2 instead, or SQLAlchemy, or Flask for the request/response structure. This would be good in a lot of ways, but it also carries a maintenance cost. The person Brian Mann was talking with made a good point:
ignu: back in my .NET days, where everyone reinvented the wheel, it was a constant struggle to learn every new application
With Django, you've got a reasonably good chance of being able to understand someone else's application written in Django without too much trouble. If we had the scatter-shot community I mentioned above, I think it would be much harder to get up to speed. From the Zen of Python:
There should be one-- and preferably only one --obvious way to do it.
Frameworks are our opinion on the right way to do things, and our attempt at making that way more obvious and cohesive. There are many pros and cons to coding within a framework, but I think Django has proven to us that it can be done well with a focus on clarity and maintainability and an aversion to magic.
Projects like Marionette are doing wonderful things in the world of client-side MVC, but I think there's still an opportunity to string together patterns to make a statement on the right way of doing it. In that respect, I think projects like Ember are doing the right thing. We need projects like this, even if we don't agree with their opinions on the right way. I like the Backbone style much better, and I would love to see a full-stack framework launched that can be refined and evolved over time to be a powerful tool like Django is to the Python world.