Live data from Hacker News

Plain – a web framework for building products with Python

plainframework.com

151–160 of 168 posts

Re: Plain – a web framework for building products with Python

#151

I appreciate this effort and am surprised by the negative sentiment. I evaluated the big 3 frameworks (Laravel, Django, and Rails) last year and Django felt like the worst of the lot. I really wanted to like Django more since I use python at $dayjob, but it seemed so far behind Laravel and Rails terms of DX and features. Also the ecosystem seemed fragmented and a lot of packages looked stale. For example, I remember…

Django may be popular, but it isn't necessarily the best.

A lot is built-in, but there is less modularity compared to say flask.

The ORM is generally inferior to SQLAlchemy, and things like Generic FKs are Django-specific (middleware) that gives you a structural dependency on a framework-specific feature, as well as DB logic in the app layer. Also, (might have changed since I last used it), it's not patricularly pythonic.

async frameworks (awsgi) are the new hotness, and FastApi is gaining steady traction.

Re: Plain – a web framework for building products with Python

#152

I appreciate this effort and am surprised by the negative sentiment. I evaluated the big 3 frameworks (Laravel, Django, and Rails) last year and Django felt like the worst of the lot. I really wanted to like Django more since I use python at $dayjob, but it seemed so far behind Laravel and Rails terms of DX and features. Also the ecosystem seemed fragmented and a lot of packages looked stale. For example, I remember…

> a static files pipeline for Django with whitenoise, how is that not included by default?

It is. They have a file server in debug mode and recommend something like nginx for serving files in production (and provide a collectstatic command to make that easy).

People shouldn’t be using a WSGI server to serve static media. Whitenoise shouldn’t exist.

Re: Plain – a web framework for building products with Python

#153

I appreciate this effort and am surprised by the negative sentiment. I evaluated the big 3 frameworks (Laravel, Django, and Rails) last year and Django felt like the worst of the lot. I really wanted to like Django more since I use python at $dayjob, but it seemed so far behind Laravel and Rails terms of DX and features. Also the ecosystem seemed fragmented and a lot of packages looked stale. For example, I remember…

I am continually impressed with Laravel. I have been using Django since 2008 and if I were starting a simple CRUD app I would consider Laravel before Django if I didn’t need anything Python specific. And with sqlc I would probably pick Go over both if I was forced to have a SPA pattern.

Re: Plain – a web framework for building products with Python

#154
post #149

Earlier quoted context omitted.

Another project I'd fund: Making Django an async-first (not async-only) framework over the next decade. It's easier to mix sync code into async than the other way around.

So glad that's not actually true so I didn't have to rewrite sqlalchemy from scratch

It's more straightforward to call a sync function from an async function than the other way around. That's a pretty uncontroversial statement. Adding async support to a library doesn't mean starting starting over.

I'm not fully understanding your thought. Can you say more?

Re: Plain – a web framework for building products with Python

#155

Earlier quoted context omitted.

> First thing that I don't like is the settings being strings that reference classes. Those classes can reference the settings, so including them as strings is done to allow that to work without creating circular imports.

Ah yeah, didn't remember that constraint in Python. I thought I read something about a future version fixing that when it comes to just type hints, but I suppose that wouldn't work here, since it's not really a type hint, right?

Yup, you're thinking of "postponed evaluation of annotations", which is currently optional with `from __future__ import annotations`. But as you said, would not fix the circular import here.

Re: Plain – a web framework for building products with Python

#156
post #92

Earlier quoted context omitted.

I've successfully replaced django.contrib.auth multiple times. It it not easy, but it is not too hard either. Honestly, everything else they do could be a regular Django app. Looks to me like forking a big project became a marketing move rather than technology necessity.

100% agree. Let's hope they maintain compatibility so stuff developed for Plain works with Django.

In the FAQ they said that extensions would not be compatible

Re: Plain – a web framework for building products with Python

#159

Related, "Django's REST (Framework) Problem" — https://news.ycombinator.com/item?id=43510495 I'm not sure that many people who rely on Django Rest Framework are aware that last month the bug tracker was made private and the project is looking for new maintainers. I love Django but the project needs to go through something similar to Angular's renaissance (and Angular needs to learn from Django docs.) I'd love to help…

Yep – I've been using Django since 2007. The big win used to be the admin, ORM, database migrations... but now oddly enough a lot of that has become a pain. I'm someone who knocks small solutions together for fun or to scratch and itch, so I'm looking for low maintenance. The problem I need solved has shifted and now Django is too much boilerplate (APIs and models are perhaps too distant as concepts), and too much ma…

Django dying the Drpal death of becoming a generalised case of nothing but itself?

Try Flask.

Re: Plain – a web framework for building products with Python

#160

Earlier quoted context omitted.

It would be a long list. I will post some examples but you can summarize it as "Django is not ideal choice to build a modern SAAS applications" and "Django developer experience is lacking". 1. REST/HTTP API building needs to be built in for a batteries included framework. In 2025 it is already so so late. REST Framework is "finished" and even if it wasn't the third-party extensions including Ninja feel alien. They ne…

Regarding #3, you can already do this with Jinja2 template functions perfectly well. You can also do it with template tags, but it isnt as nice. 100% agree with #5, the diaspora of Django's community, dev process, and lack of a single decision maker when consensus isn't quickly reached, makes it virtually impossible to correct past mistakes.

> Regarding #3, you can already do this with Jinja2 template functions perfectly well. You can also do it with template tags, but it isnt as nice.

This is exactly the problem tho. Every Django solution is "install this thing that replaces or adds a component that should be standard". People adopt frameworks to help them stay on track, not because they want to immediately install 5-10 packages just to correct the framework. Not to mention this just creates a big split when every project will be very different.

Post reply on HN