3 ms·

That's how it works with micro-frameworks, you pay for what you use. Now, it's not necessarily a problem, last time I checked, there was a decent list of functi

That's how it works with micro-frameworks, you pay for what you use. Now, it's not necessarily a problem, last time I checked, there was a decent list of functional Flask components. What do you feel is the advantage of having a huge 'contrib' folder, as long as the extensions are maintained? Because the advantage of not having an ORM bundled per default, and easily switching something like the templating language are pretty clear to me.

jsmeaton 13y ago
I have a django project that swapped out the django templates for mako. Mako templates are awesome to use. The problem is it becomes extremely difficult to use packages that have bundled templates of their own. I would think it'd be the same with flask, no? Making assumptions about the available ORM and templating package allows 3rd party modules to do more of the work for you.
- collyw 13y ago
  I have been tempted to switch the Django ORM for SQL alchemy, but I would loose the Django Amdin interface.
  - jsmeaton 13y ago
    ..and every 3rd party module that contains their own models, which would be a very large number. If you want to use SQL Alchemy, you're better off using a different framework. I'm currently trying to decide if this is the angle I should follow for my next project, which requires fairly sophisticated SQL (comparable to the django ORM anyway).
- mercurial 13y ago
  Jinja 2 is a Flask dependency, it is always configured, so that's a bad example (though I have to confess that I don't know how a Flash webapp with a different templating engine works with an extension using Jinja 2 for its views). As for the ORM, yes and no. Many extensions have no need for it, but I think 99% of the others use SQLAlchemy, because it's the most popular. But if you want to make a website backed by a NoSQL solution, you don't need to depend on an ORM. Obviously, any extension based on SQLAlchemy will not work, but baking the ORM into the framework offers no solution to that.

jsmeaton 13y ago

I have a django project that swapped out the django templates for mako. Mako templates are awesome to use. The problem is it becomes extremely difficult to use packages that have bundled templates of their own. I would think it'd be the same with flask, no? Making assumptions about the available ORM and templating package allows 3rd party modules to do more of the work for you.

collyw 13y ago
I have been tempted to switch the Django ORM for SQL alchemy, but I would loose the Django Amdin interface.
- jsmeaton 13y ago
  ..and every 3rd party module that contains their own models, which would be a very large number. If you want to use SQL Alchemy, you're better off using a different framework. I'm currently trying to decide if this is the angle I should follow for my next project, which requires fairly sophisticated SQL (comparable to the django ORM anyway).
mercurial 13y ago
Jinja 2 is a Flask dependency, it is always configured, so that's a bad example (though I have to confess that I don't know how a Flash webapp with a different templating engine works with an extension using Jinja 2 for its views). As for the ORM, yes and no. Many extensions have no need for it, but I think 99% of the others use SQLAlchemy, because it's the most popular. But if you want to make a website backed by a NoSQL solution, you don't need to depend on an ORM. Obviously, any extension based on SQLAlchemy will not work, but baking the ORM into the framework offers no solution to that.