However, I’ve a few concerns when using these starter kits. (I have not evaluated and assessed their code base, nor their dependencies)
While starter kits have included and structured various libraries, different libraries likely structure their code differently. This makes the kits hard to understand conceptually
I don’t know what assumptions were made while these kits were structured
In the medium term (3-5 years), these starter kits may not leverage new programming paradigms (i.e. async) introduced in mainline Django to make their code cleaner, more maintainable, and have better performance
Not sure if these concerns are valid, and how they are mitigated. I know too that if I end up building and integrating various libraries from scratch, I will likely not waste just time, but also make a mess out of project structure and maintainability.
I’ve a few questions:
How do you manage different libraries with different coding styles? One way I know is to write an adapter above these libraries.
While I know there isn’t a perfect starter kit, when do you all decide to just build from scratch (vanilla Django), use a starter kit as is, or remove what you don’t need from the starter kit?
Apart from cookiecutter-django and djangox, what other popular starter kits for Django are there? Ideally, the starter kit should be well maintained and have good and lasting traction.
While I know there isn’t a perfect starter kit, when do you all decide to just build from scratch (vanilla Django), use a starter kit as is, or remove what you don’t need from the starter kit?
I am biased (I maintain a starter kit), but I think ~every professional project likely benefits from a Starter Kit. Probably the best reason not to use a starter kit is if you want to learn the framework from the ground up. But even Django itself is a massive “starter kit” of sorts.
One of the benefits of starter kits is that they are just that starters. I think this should largely allay your medium-term fears (your point 3). If you want to add async to your project and your starter kit doesn’t support that, nothing prevents you from doing that. Additionally, most libraries should be treated like black boxes - you shouldn’t care what the code looks like inside them as long as you want to work with them. Plus, any cookiecutter-derived starter kit will likely have options to remove most options/dependencies at build time.
Apart from cookiecutter-django and djangox, what other popular starter kits for Django are there? Ideally, the starter kit should be well maintained and have good and lasting traction.
In terms of free and open source I think these two are definitely the dominant ones. If you are considering paid starter kits, that opens up others. Paid products also allay some of your concerns - e.g. they are more likely to be maintained, provide support, etc. But they also cost money.
In the vast majority of cases - especially when first getting started - there is absolutely no need or value in looking at the source of all libraries being used.
Most / any of the better supported kits document what pattern or problem they’re trying to solve.
Looking at their commit / update history would give you a pretty good idea as to how well they’ll be supported in the future. However, even if a starter kit is never updated beyond today, it may still be very useful today.
This is not something you need to worry about with Python. You’re looking to address an issue that doesn’t really exist.
Side note: Cookiecutter itself is not a starter kit. It’s a framework for creating starter kits. You can take a cookiecutter template and modify it for your own purposes. Cookiecutter-Django is only one such starter kit available. And as such, if you didn’t like the patterns or selections being used, you could use it as a starting point for your own cookiecutter.
I’m not personally familiar with DjangoX, but I know the author well enough to be able to trust whatever he publishes, and so I’d have no problems recommending or using DjangoX if I thought it would meet a particular requirement.
Actually, I can say the same about Cookiecutter-Django as well.
We don’t use starter kits - at least not from the perspective of the two tools previously mentioned. Our projects are generally based on one of three patterns, and so what we’ve done is create a skeleton project that we copy/modify for each new project.
Would we be better off if we turned these patterns into a cookiecutter? Quite possibly - but I’m not sure we’d save enough time to actually make it worthwhile, once you factor in the overhead of creating and maintaining the cookiecutter.
Sure - pattern 1 would be your typical Browse, Read, Edit, Add, Delete (BREAD) style app. It’s effectively the output of the combination of startproject and startapp with a couple of editing changes. (e.g., the default database is set to PostgreSQL, some standard-for-us apps are already in INSTALLED_APPS, and there’s a set of generic views in views.py along with the corresponding entries in urls.py.)
Pattern 2 are apps that don’t interact with people. We have a set of apps that are basically sets of management commands that are either run from the command line or are set up to run as long-running processes. Many of the changes are similiar to the first pattern, except for the views. Instead, there’s a directory for the commands and one skeleton command with some notes in it.
The third pattern (and the newest) is the one that I’ve started using for my Channels-based projects. It adds the Channels-related libraries to INSTALLED_APPS and includes the various files for handling websockets. In reality, it’s pretty much what you would end up with after you’ve completed the Channels tutorial.
There’s still a fair amount of editing to be done with any of them before they’re ready for use - they don’t get you 100% started, but they do eliminate some of the “boilerplate” you need to provide to get started.