Hacker News Reader

Comment by hrayr | Hacker News Reader

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.

View on HN

You might as well use Flask at that point. You can use cookie-cutter to create the starter packs.

I 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.

Maybe 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).

Sure, 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.

There 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.

DJango 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.

I 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.

Django isn't that big in terms of file size, and you can just turn off the batteries you don't need.

Reply on news.ycombinator.com