4 ms·
I wonder if this creates more problems than it solves. For example, imagine there are a bunch of startups trying their hardest to shoe-horn contributions in Dj
by systemvoltage 5y ago
I wonder if this creates more problems than it solves.
For example, imagine there are a bunch of startups trying their hardest to shoe-horn contributions in Django main branch. It puts a lot of load on core developers at Django to reject frivolous features and unnecessary bloat.
The end effect would be that we get features no one asks for and Django becomes even more bloated.
Django is already a very popular framework and has many contributors.
- davegaeddert 5y agoYeah I could see that argument too. Lots of hard decisions and interesting questions in terms of how to navigate what people want/need. Honestly I don't envy their situation. It has even made me think crazy things like what a Django fork would look like... the thing has some bloat that could stand to be removed too. And some legacy decisions that are super hard to change, but also need to be changed.
- tony 5y agoI wouldn't limit django patches to just being new features. Ample room for incremental improvements. There are some parts of django core that are stable, but fundamentally broke for non-trivial apps. Let's just take /admin: - Can inline admin models be paginated? Searched? Both? Asynchronously? - Use autocomplete_fields by default via ID/PK lookup / when `search_fields` exist. Right now related fields will load the whole table into a <select> box. This is an absurd default. Other opportunities that'd be universal: - Integrate channels into admin - AJAX form validation - Revision history that includes actual values / diffs / undo
- systemvoltage 5y agoGood response, I agree that these changes would benefit Django.