Live data from Hacker News

Plain – a web framework for building products with Python

plainframework.com

21–30 of 168 posts

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

#22

Django still lacks typing support. Does Plain improve on this at all? I didn't see typing mentioned in the docs..

Relatedly, in case it's useful, the django-stubs package provides mypy compatible type stubs for Django:

https://github.com/typeddjango/django-stubs

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

#23

> Plain is a fork of Django Why. This makes me sad. Plain looks great, but Django's strength is its maturity and amazing, enduring community built on contributions from thousands. Forking it will at best split contributions and mean infrequent merges, and at worst means Plain users lose out on Django improvements and Django users lose out on Plain patches. It seems like Plain could be just a set of Django packages kn…

Has no mention of it being a fork of Django in the README. https://github.com/dropseed/plain

I guess the author didn't think credit was due: https://plainframework.com/about/#credit-where-credits-due

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

#24

> Plain is a fork of Django Why. This makes me sad. Plain looks great, but Django's strength is its maturity and amazing, enduring community built on contributions from thousands. Forking it will at best split contributions and mean infrequent merges, and at worst means Plain users lose out on Django improvements and Django users lose out on Plain patches. It seems like Plain could be just a set of Django packages kn…

The author actually addresses all of those points in the about page https://plainframework.com/about/

I understand the frustrating with Django progress (and, to be honest, I would like for Django to more agressively upstream stuff).

I'm curious about what he would want to get into Django that feels like he couldn't though. Since this _is_ a fork of Django, he's still gonna hit a lot of issues that people wanting to improve Django hit.

Backwards compat is an issue, but "all of this code within the library is built off of existing assumptions" is _also_ an issue.

If all the improvements could be third party packages, just making plain be a big third party omnipackage that also has a helper to "fix" settings feels like it would go a long way.

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

#25

> Plain is a fork of Django Why. This makes me sad. Plain looks great, but Django's strength is its maturity and amazing, enduring community built on contributions from thousands. Forking it will at best split contributions and mean infrequent merges, and at worst means Plain users lose out on Django improvements and Django users lose out on Plain patches. It seems like Plain could be just a set of Django packages kn…

The author actually addresses all of those points in the about page https://plainframework.com/about/

The author discusses these points in the about page, but for me, does not sufficiently address them.

My experience of contributing to Django does not match theirs, and I don't feel this page sufficiently justifies this being a fork. In fact it actually makes me suspect that Plain will/has diverged enough that it won't be able to pull in changes from Django. As a user this would concern me, as Django ships meaningful changes regularly, as well as having a mature approach to security disclosures.

I have disclosed vulnerabilities in Django and they were handled very well and quickly. I actually went to see if Plain was vulnerable to the issue I disclosed, but my issue was around the memcached integration, and it seems Plain has completely removed all caching (except from a database-backed cache), making it in one way less batteries-included than regular Django. This puzzles me, for a project that is all about including more batteries, and as a potential user would lead me to further question the project.

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

#26

How come Plain looks so much like Django?

Third sentence on the page. Third sentence.

I usually click through to the repo, and it isn't in the README for some reason. I don't blame GP for missing it. https://github.com/dropseed/plain

Of course, GP would've noticed it's like Django on the web page. The screenshot containing Django-like example code is above the fold, though - the Django mention is below the fold.

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

#27

Django still lacks typing support. Does Plain improve on this at all? I didn't see typing mentioned in the docs..

If you want strong typing in a web framework, why wouldn’t you just use a language with strong typing?

Because people want strong typing, but also want other things. It's possible to want multiple things, and bemoan that whwat you use is still missing things you want.

Concretely, Django is way more usable than basically any web framework from the "strongly typed" space, especially for "dumb" CRUD stuff. And you're not hit with making decisions about how to do a bunch of things (though you can swap out mostly any part of Django for something else if you want to).

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

#28

Earlier quoted context omitted.

I don't get it, if you don't like it, don't use it, but why feel sad about it? Someone is developing something new and giving it out for free.

They aren’t sad about being forced to use something. They are expressing their opinion about split efforts in the Django community.

Exactly. I look at things like this and contrast with what friends like Adam Johnson do[0] with their community contributions. Adam has many Django packages, along with many other non-Django Python packages. Crucially though, they're not forks that reduce the focus of the community, they're contributions that increase what the community can do collectively.

[0]: https://github.com/adamchainz?tab=repositories&q=django-&typ...

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

#29
Trying to run the starter kit, it tries to download mkcert, but that download fails with a ssl.SSLCertVerificationError... how ironic :)

brew install mkcert fixes this.

Also, a starter kit that asks for my password right away is a bit too intrusive for me:

    Downloads/new-project [master {origin/master}|]: uv run plain dev
    Generating SSL certificates for app.localhost...
    Created a new local CA 
    Note: the local CA is not installed in the system trust store.
    Note: the local CA is not installed in the Firefox trust store.
    Run "mkcert -install" for certificates to be trusted automatically 

    Created a new certificate valid for the following names 
     - "app.localhost"

    The certificate is at "/Users/me/Downloads/new-project/.plain/dev/certs/app.localhost-cert.pem" and the key at "/Users/me/Downloads/new-project/.plain/dev/certs/app.localhost-key.pem" 

    It will expire on 29 June 2027 

    Adding app.localhost to /etc/hosts file. You may be prompted for your password.

    Password:
I generally don't like to rely on ssl for development anyway. Make it optional maybe ?

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

#30
post #27

Earlier quoted context omitted.

If you want strong typing in a web framework, why wouldn’t you just use a language with strong typing?

Because people want strong typing, but also want other things. It's possible to want multiple things, and bemoan that whwat you use is still missing things you want. Concretely, Django is way more usable than basically any web framework from the "strongly typed" space, especially for "dumb" CRUD stuff. And you're not hit with making decisions about how to do a bunch of things (though you can swap out mostly any part…

That makes sense! My personal feeling is that a web framework is not the right place in the stack to introduce typing.

There’s also probably an argument to be made that part of the reason for Django’s “batteries included” success and wide adoption is in part because it is built on an untyped language.

I get wanting both, though.

In my own work, I find most of the benefit of static types to be ensuring correctness at compile time, so I just don’t expect that in Python. I also have just not lost that many cycles to type errors. But I know some have strong preferences here.

Post reply on HN