The current documentation emphasizes that Flask is best suited to smaller projects of under 4000 lines of code. While this may be currently true, it may also put people off trying out Flask for a new project, as even small projects have a tendency to grow. With the upcoming module support however, it should be possible to build larger applications using Flask, as you can break up your view code into any number of modules. Previously it was more difficult to have a large number of views because of circular imports and other issues. Using an ORM such as SQLAlchemy (or equivalent no-SQL solution) it should be possible to manage a complex model layer regardless of the web framework. Once module support has been added, what barriers still exist in being able to build large, complex applications in Flask ? Or should the documentation be updated accordingly ?
Hi, On 2010-05-05 6:00 PM, Dan Jacob wrote: > The current documentation emphasizes that Flask is best suited to > smaller projects of under 4000 lines of code. While this may be > currently true, it may also put people off trying out Flask for a new > project, as even small projects have a tendency to grow. The emphasis in the documentation should probably be changed to *unmodified* Flask. The idea of Flask is that when you grow out of it, you have the strong foundation of Werkzeug and Jinja and with a couple of lines of changes to the flask.py you can easily adapt for larger applications. > With the upcoming module support however, it should be possible to > build larger applications using Flask, as you can break up your view > code into any number of modules. Previously it was more difficult to > have a large number of views because of circular imports and other > issues. With the module support branch, the documentation should probably be improved in that regard. > Using an ORM such as SQLAlchemy (or equivalent no-SQL solution) it > should be possible to manage a complex model layer regardless of the > web framework. Speaking of No-SQL, there should probably be examples of Cassandra or other similar stores in the documentation and how this can be used. > Once module support has been added, what barriers still exist in being > able to build large, complex applications in Flask ? Or should the > documentation be updated accordingly ? Generally, no framework scales perfectly from small to large applications, that would be unrealistic. Flask goes the very simple approach here: it decides some things for you that might work out well for a reasonable sized project, but if you hit the border the idea is to take the code and modify it. I mean, there is not that much code in Flask and the underlying libraries are not having and limitations regarding scaling big. If anyone has some ideas how to improve the wording of the documentation to better reflect that, I would love to apply some patches there :) Regards, Armin
Of course nobody has built a large application yet, so we'll have to see what limitations they reach and how they get around them. I've worked on large Django projects, and generally with Django the problem tends to be that it tries to do too much, which gives you an initial boost but leads to frustration and lots of workarounds later (for example user authentication). So as long as Flask remains small and focused - with a healthy ecosystem of external libs/snippets/patterns - it shouldn't run into these issues. That doesn't mean that Flask limits you to small projects - quite the contrary. The larger or more complex the project the more you end up doing yourself, and it's far easier at that point to be dealing with a small framework that doesn't get in your way and is easy to fork or subclass than a large, tightly coupled framework that makes a lot of decisions for you. On 5 May 2010 17:10, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 2010-05-05 6:00 PM, Dan Jacob wrote: >> The current documentation emphasizes that Flask is best suited to >> smaller projects of under 4000 lines of code. While this may be >> currently true, it may also put people off trying out Flask for a new >> project, as even small projects have a tendency to grow. > The emphasis in the documentation should probably be changed to > *unmodified* Flask. The idea of Flask is that when you grow out of it, > you have the strong foundation of Werkzeug and Jinja and with a couple > of lines of changes to the flask.py you can easily adapt for larger > applications. > >> With the upcoming module support however, it should be possible to >> build larger applications using Flask, as you can break up your view >> code into any number of modules. Previously it was more difficult to >> have a large number of views because of circular imports and other >> issues. > With the module support branch, the documentation should probably be > improved in that regard. > >> Using an ORM such as SQLAlchemy (or equivalent no-SQL solution) it >> should be possible to manage a complex model layer regardless of the >> web framework. > Speaking of No-SQL, there should probably be examples of Cassandra or > other similar stores in the documentation and how this can be used. > >> Once module support has been added, what barriers still exist in being >> able to build large, complex applications in Flask ? Or should the >> documentation be updated accordingly ? > Generally, no framework scales perfectly from small to large > applications, that would be unrealistic. Flask goes the very simple > approach here: it decides some things for you that might work out well > for a reasonable sized project, but if you hit the border the idea is to > take the code and modify it. I mean, there is not that much code in > Flask and the underlying libraries are not having and limitations > regarding scaling big. > > If anyone has some ideas how to improve the wording of the documentation > to better reflect that, I would love to apply some patches there :) > > > Regards, > Armin >
I can agree with that. One of the annoying and great things in django (depending on the project) is the tight coupling of the admin interface. I plan on building a medium-to-large flask project soon on my own time. I did build a simple beta - sign up with it just to test it out and everything worked great. On Wed, May 5, 2010 at 11:44 AM, Dan Jacob <danjac354@gmail.com> wrote: > Of course nobody has built a large application yet, so we'll have to > see what limitations they reach and how they get around them. > > I've worked on large Django projects, and generally with Django the > problem tends to be that it tries to do too much, which gives you an > initial boost but leads to frustration and lots of workarounds later > (for example user authentication). So as long as Flask remains small > and focused - with a healthy ecosystem of external > libs/snippets/patterns - it shouldn't run into these issues. > > That doesn't mean that Flask limits you to small projects - quite the > contrary. The larger or more complex the project the more you end up > doing yourself, and it's far easier at that point to be dealing with a > small framework that doesn't get in your way and is easy to fork or > subclass than a large, tightly coupled framework that makes a lot of > decisions for you. > > > On 5 May 2010 17:10, Armin Ronacher <armin.ronacher@active-4.com> wrote: > > Hi, > > > > On 2010-05-05 6:00 PM, Dan Jacob wrote: > >> The current documentation emphasizes that Flask is best suited to > >> smaller projects of under 4000 lines of code. While this may be > >> currently true, it may also put people off trying out Flask for a new > >> project, as even small projects have a tendency to grow. > > The emphasis in the documentation should probably be changed to > > *unmodified* Flask. The idea of Flask is that when you grow out of it, > > you have the strong foundation of Werkzeug and Jinja and with a couple > > of lines of changes to the flask.py you can easily adapt for larger > > applications. > > > >> With the upcoming module support however, it should be possible to > >> build larger applications using Flask, as you can break up your view > >> code into any number of modules. Previously it was more difficult to > >> have a large number of views because of circular imports and other > >> issues. > > With the module support branch, the documentation should probably be > > improved in that regard. > > > >> Using an ORM such as SQLAlchemy (or equivalent no-SQL solution) it > >> should be possible to manage a complex model layer regardless of the > >> web framework. > > Speaking of No-SQL, there should probably be examples of Cassandra or > > other similar stores in the documentation and how this can be used. > > > >> Once module support has been added, what barriers still exist in being > >> able to build large, complex applications in Flask ? Or should the > >> documentation be updated accordingly ? > > Generally, no framework scales perfectly from small to large > > applications, that would be unrealistic. Flask goes the very simple > > approach here: it decides some things for you that might work out well > > for a reasonable sized project, but if you hit the border the idea is to > > take the code and modify it. I mean, there is not that much code in > > Flask and the underlying libraries are not having and limitations > > regarding scaling big. > > > > If anyone has some ideas how to improve the wording of the documentation > > to better reflect that, I would love to apply some patches there :) > > > > > > Regards, > > Armin > > >
If flask stays small, it will lower the barrier entry for people to learn a lower level framework. The thing I like about Flask is it makes starting with werkzeug less intimidating, its small and I know exactly what it is trying to do, and can easily use it as the basis for a custom framework. -- Thadeus On Wed, May 5, 2010 at 3:42 PM, Glen Zangirolami <glenbot@gmail.com> wrote: > I can agree with that. One of the annoying and great things in django > (depending on the project) is the tight coupling of the admin interface. > I plan on building a medium-to-large flask project soon on my own time. I > did build a simple beta - sign up with it just to test it out and everything > worked great. > > On Wed, May 5, 2010 at 11:44 AM, Dan Jacob <danjac354@gmail.com> wrote: >> >> Of course nobody has built a large application yet, so we'll have to >> see what limitations they reach and how they get around them. >> >> I've worked on large Django projects, and generally with Django the >> problem tends to be that it tries to do too much, which gives you an >> initial boost but leads to frustration and lots of workarounds later >> (for example user authentication). So as long as Flask remains small >> and focused - with a healthy ecosystem of external >> libs/snippets/patterns - it shouldn't run into these issues. >> >> That doesn't mean that Flask limits you to small projects - quite the >> contrary. The larger or more complex the project the more you end up >> doing yourself, and it's far easier at that point to be dealing with a >> small framework that doesn't get in your way and is easy to fork or >> subclass than a large, tightly coupled framework that makes a lot of >> decisions for you. >> >> >> On 5 May 2010 17:10, Armin Ronacher <armin.ronacher@active-4.com> wrote: >> > Hi, >> > >> > On 2010-05-05 6:00 PM, Dan Jacob wrote: >> >> The current documentation emphasizes that Flask is best suited to >> >> smaller projects of under 4000 lines of code. While this may be >> >> currently true, it may also put people off trying out Flask for a new >> >> project, as even small projects have a tendency to grow. >> > The emphasis in the documentation should probably be changed to >> > *unmodified* Flask. The idea of Flask is that when you grow out of it, >> > you have the strong foundation of Werkzeug and Jinja and with a couple >> > of lines of changes to the flask.py you can easily adapt for larger >> > applications. >> > >> >> With the upcoming module support however, it should be possible to >> >> build larger applications using Flask, as you can break up your view >> >> code into any number of modules. Previously it was more difficult to >> >> have a large number of views because of circular imports and other >> >> issues. >> > With the module support branch, the documentation should probably be >> > improved in that regard. >> > >> >> Using an ORM such as SQLAlchemy (or equivalent no-SQL solution) it >> >> should be possible to manage a complex model layer regardless of the >> >> web framework. >> > Speaking of No-SQL, there should probably be examples of Cassandra or >> > other similar stores in the documentation and how this can be used. >> > >> >> Once module support has been added, what barriers still exist in being >> >> able to build large, complex applications in Flask ? Or should the >> >> documentation be updated accordingly ? >> > Generally, no framework scales perfectly from small to large >> > applications, that would be unrealistic. Flask goes the very simple >> > approach here: it decides some things for you that might work out well >> > for a reasonable sized project, but if you hit the border the idea is to >> > take the code and modify it. I mean, there is not that much code in >> > Flask and the underlying libraries are not having and limitations >> > regarding scaling big. >> > >> > If anyone has some ideas how to improve the wording of the documentation >> > to better reflect that, I would love to apply some patches there :) >> > >> > >> > Regards, >> > Armin >> > > >