Back Story

We've been building web applications for a long time. First with Perl, then with PHP, then with Django. Our time with Django has by far been the most enjoyable and most productivity. But in building enterprise applications, we've encountered a number of challenges.

Third-Party Apps

Like many frameworks, Django has a large number of third-party apps. We've found some that are fantastic, but sadly many projects fall by the way side. Only a handful of third-party apps enjoy enough community support to keep them going.

So it often happens that an app we've relied on presents some prickly problems when the next major release of Django comes out. Submitting pull requests still requires time of the authors or maintainers, and more often than not, pull requests are simply ignored. One member of our team even took over maintenance of a lagging project.

With SuperDjango, we decided to "own the race course" when it comes to certain functionality. It's on us if a Django release breaks the code, but we've been keeping up now across three versions (and seven years) of SuperDjango and in the end it's saved us lots (lots) of time.

Business Logic

Low-code and no-code tools and services have become popular over the last few years. These are interesting but always hit "the limit" -- a line of functionality that requires programming to fulfill business-specific logic. The approach we've generally seen is to provide an API or programming interface from within the tool. This is often JavaScript processed by a Node backend.

But if the goal is to provide the customer with something they can do themselves, the need to provide these sorts of interfaces is an admission that, at some point, programming is required. Furthermore, when programming is required, it is not in a powerful language such as Python and developers are severely constrained based on what the platform exposes.

With SuperDjango, we asked "what if there was a way to provide low-code, no-code for the basics while still providing a means to engage in programming as the need arises?" SuperDjango contrib, DB, and UI provide this kind of development. Define some models, configure a UI, and at least half of the work is done. All that remains is implementing business logic as needed.

User Interface

It's a matter of fact that the Django Admin is not for users. Attempts to re-design and improve the admin are all well and good, but at the end of the day, the purpose of the admin is not to provide a user interface for users.

The conventions behind class-based views help ease the burden of creating a UI and various attempts have been made to improve upon this approach. However, the basic functionality of the admin (e.g. automating CRUD) is something that can be automated.

We created SuperDjango UI for this purpose: To provide CRUD -- and then some. We asked "wouldn't it be great to configure a UI for handling forms and lists in a semi-automatic manner?" We also asked "wouldn't it be great if lists could be displayed as cards and calendars or as a kanban board or gantt chart?" Again, semi-automatically.

The Mission

Our mission is to promote the use of Django for enterprise solutions by providing high-quality, unified resources that both ease and speed Django development. This is not to detract from the many great, enterprise sites that run on Django. Our aim is to make enterprise-quality sites much easier to develop.

Project Expectations

We recognize that the monolithic approach to SuperDjango will be disagreeable to some. We struggled with this in the beginning, but after spending years building and re-building SuperDjango, we found that the benefits of one large code base outweighed those of maintaining smaller, separate packages. This better serves our mission and sets up the primary expectations we have for the project:

Code Quality

By quality we mean the non-functional aspects of the source code, including structure, readability (including comments), and style.

Unit Testing

Good testing is important to the evolution of any large project. A high degree of test coverage helps build confidence that organizations need to select a mission-critical dependency. Although it will take time, we hope to achieve 80% coverage for the SuperDjango within the first year of its release. Our goal is at some point to achieve 100% coverage. (We have achieved 100% coverage on some of our past projects.)

Documentation

Like good testing, good documentation is extremely important. Over the years, we've become masters at producing and maintaining usable documentation. It begins in the code and spreads into introductory materials, tutorials, and solid developer reference.

With regard to the developer reference, we like to achieve a minimum of 80% coverage of members.