6 ms·
Why a shame? What would Channels buy you if it were included into the framework? I would love to see Django split up into smaller official external packages an
by hrayr 10y ago
Why a shame? What would Channels buy you if it were included into the framework?
I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.).
I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.
- rukittenme 10y agoYou might as well use Flask at that point. You can use cookie-cutter to create the starter packs.
- cmdrfred 10y agoI love Flask. People say Django is easier to use but I had a much easier time with Flask. It's well documented and very flexible.
- knabacks 10y agoMaybe not easier to use in general, but you don't have to replicate all the daily stuff you maybe need for your project. With Flask you have to recreate many things (for example acc management) or rely on a thrid party-dev. In django you get core stuff from the core team(also with the freedom of recreating it yourself or use some app from a thridparty-dev).
- hrayr 10y agoSure, I love Flask but Django has it's own ecosystem and that's what I'm talking about. I know anyone can use cookie-cutter, but I'm talking about trimming Django itself. Externalize Forms, Templates, etc. and build several core starter packages (including current Django). This gives a few base starting points.
- jsmeaton 10y agoThere are two benefits to having subpackages in the way you describe. The first, as you mention, is to slim down the framework. I don't think this gains a whole lot except for trimming down deployment sizes. If you don't use the components then the code doesn't run. The other benefit would be so that the components could be used outside of Django. Using forms or templates might appeal to projects outside of Django. This isn't currently possible for a large majority of components since they depend on the global settings module, and/or other components. What could be done with the dependency constraints is to build in different templates that `startproject` would create for you. It'd only be able to modify settings and write out requirements files, but it'd achieve a structure for different app types.
- brianwawok 10y agoDJango 1.10 source download is 7MB. I don't know what is normal for Ruby. Basic crud app in Java tends to be 20-50MB, but DJango above doesn't have DB drivers or anything yet so I suspect it is similar. *seems reasonable.
- oliwarner 10y agoI think most Django developers would love to use their toolkit elsewhere (eg the ORM) but in practice, everything it held together by so much Django glue (setting and convention) that I don't see how it would be practical. By that point you may as well just import Django, bootstrap it and use what you need. The other side of this argument, is you allow each component to be developed at its own speed. Again, the integration between elements (Models→ModelForm→Forms etc) is so tight this isn't practical. Just as making them less integrated [probably] makes them harder to use for people who just want to use Django.
- kennydude 10y agoDjango isn't that big in terms of file size, and you can just turn off the batteries you don't need.