How and why GraphQL will influence the Sourcehut alpha

The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features.

Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a mini-framework, with custom email and validation components[2][3]. In the ‘main’ project we can see the views that power mailing lists and projects[4][5].

I’m totally biased, but I can’t help but think “why Flask, and why not Django” after seeing all of this. Most of the repeated view boilerplate would have gone ([1] could be like 20 lines), the author could have used Django rest framework to get a quality API with not much work (rather than building it yourself[6]) and the pluggable apps at the core of Django seem a perfect fit.

I see this all the time with flasks projects. They start off small and light, and as long as they stay that way then Flask is a great choice. But they often don’t, and as the grow in complexity you end up re-inventing a framework like Django but worse whilst getting fatigued by “Python” being bad.

1. https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/pastesrh...

2. https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/emai...

3. https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/vali...

4. https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/hubsrht/bl...

5. https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/hubsrht/bl...

6. https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/pastesrh...

Some devs prefer clear, flexible and performant/unambiguous code to 20 layers of abstraction.