Live data from Hacker News

Django 4.0

djangoproject.com

201–210 of 226 posts

Re: Django 4.0

#201

Earlier quoted context omitted.

What do you find hard in particular? systemd service + gunicorn is not that bad, I think. You can have simple deployment and graceful restarts[0]. [0] https://nts.strzibny.name/gunicorn-graceful-restarts/

Not sure that your link is an answer to my comment. Whatever the case may be, I can take a single VPS and multi-host a bunch of domains, each with it's own Wordpress installation, DB, etc. Virtual hosts makes this possible. It's stupid simple. Getting a single Django application running under a single domain on a VPS is a nightmare. Particularly when you consider everything you have to do to migrate from the developm…

I agree, although as my other comment states, the most frictionless way I’ve found is to make a quick docker-compose, and run maybe 5 Dokku commands on the server. Then from dev environment just ‘git push dokku’. That’s the level of friction we should also expect from Django built in.

Re: Django 4.0

#202

Earlier quoted context omitted.

>avoid fat models, use a service layer I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

Another classic is "c string".

And when you need to look up the Typescript playground, it's probably best not to abbreviate typescript as "TS".

Re: Django 4.0

#203
post #3

I must learn Django, it's got everything I'll ever need. No, Rails will make me happy and it's better for lonely devs like me. No I must learn a Modern Web Framework (TM) to prove I'm not stuck in the past. No way, I'm not a fashionista. Have you seen that Phoenix demo where the guy builds Twitter in like 4 minutes? That's the future. Hold on a minute, enough of this magic. I need to learn to build everything in Comm…

There are just so many makes and models of automobile and people get by. I remain so confused why choice paralysis is a thing in software. Maybe the libraries need to cost 30,000$ ;-)

Imagine each car model having different controls, different engine and components placement, some coming with rectangular wheels. That image is closer to SW frameworks.

Re: Django 4.0

#204

I still have a project that runs on Django 1.6. Can't imagine trying to migrate now, when it relies on so many old packages. Would probably be better of starting from scratch.

I would start by replacing the dependencies that are not maintained anymore (i.e. that don't support a relatively recent Python 3.x) with more modern alternatives one by one instead of rewriting it. The migration of the Django application itself should not be that hard.

Re: Django 4.0

#205

OT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidentl…

Django: Great if you are building only a backend or rest API with a separate frontend (an SPA in React, etc). The templates system is terrible, has no asset pipeline built in and frontend on it feels like developing in the 90s. You'll miss php a lot here.

Elixir: Technologically "mind blowing", although all the nice things come from the Erlang VM and not from Elixir itself in my opinion. You will likely not find any job using Elixir, if you do it is going to be full of people just learning the language so the codebase will be very likely a disaster. You will miss a lot of libraries and you will have to write code for things you'd take for given in the PHP ecosystem. Be ready to fight your editor plugins (depending on which one you use, and the degree of IDEisms you're used to).

I understand you want to learn something new, so the most "radical" one here that will teach you more new things is clearly Elixir.

But other than learning purposes, If I were to build something for real, I'd stick with PHP and Laravel, it's an incredible productive, well documented and well thought out platform to develop in.

Re: Django 4.0

#206

Where are we on the whole Django versus Rails debate? (Not cannonfodder, I am genuinely curious)

I'm biased because out of the two I've only used Django, however since learning Django my urge to learn Rails has gone down quite a bit. Its still there, and Rails does look fantastic, but so does the hundred other frameworks and languages on my todo list. I guess the only takeaway you can get for that is that Django, at the very least, works fine, and probably will solve the problem you come in with unless you want…

To be fair. Rails is very _fantastic_.

Re: Django 4.0

#207
post #143

Earlier quoted context omitted.

I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial, it's a mess of wires and plugs that resembles something like Django anyways but all maintained by you or your team. FastAPI seemed like something that's in a solid middle ground between something beefy like Django but something light like Flask and it's much easier to start with since…

> I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial Do you have specific examples? I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of…

> solo projects and working with small teams

As I said, any time a Flask app becomes non-trivial, it's a pain. Engineering scaled up from 10 to 30 and immediately it was apparent what a massive pain it all was. We had to implement auth, access control, caching, API documentation, admin panel etc etc all on our own. Flask plugins are very fickle with a lot of them not being maintained anymore that don't fit our use cases. If you need all these things in a customer facing app, you might as well just use Django. Performance suffers a little but the ease of developer onboarding and batteries included in the framework, coupled with a lot of well maintained popular plugins honestly make Django the de facto choice for web app dev that needs to scale. Flask is good for small services being maintained by small teams

Re: Django 4.0

#208

OT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidentl…

For environment management have a look at poetry https://python-poetry.org/

Re: Django 4.0

#209

Earlier quoted context omitted.

> function based views Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here: https://github.com/Alex3917/django_for_startups/blob/main/dj... If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting t…

Alex has written an excellent blog about Django best practices for startups. It contains wonderful insights about how you should structure code and why you should structure it that way. It has helped us a ton! https://news.ycombinator.com/item?id=27605052

The blog post itself is also archived here: http://archive.today/1cNZb

Re: Django 4.0

#210
post #143

Earlier quoted context omitted.

> I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial Do you have specific examples? I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of…

> solo projects and working with small teams As I said, any time a Flask app becomes non-trivial, it's a pain. Engineering scaled up from 10 to 30 and immediately it was apparent what a massive pain it all was. We had to implement auth, access control, caching, API documentation, admin panel etc etc all on our own. Flask plugins are very fickle with a lot of them not being maintained anymore that don't fit our use ca…

> As I said, any time a Flask app becomes non-trivial, it's a pain

Results may vary. Small teams doesn't mean small apps. You can have 150 models, dozens of screens, caching, background jobs, rate limiting, multiple payment providers, multi-tenancy, public APIs and other features you would expect in a decently sized SAAS app and it's fine. The popular Flask extensions for certain behavior are pretty well maintained. There's also a number of Python libraries that can get used in a Flask app that aren't specific to Flask but are very well maintained like SQLAlchemy and Celery.

I wouldn't say Flask is better than Django or Django is better than Flask but I think you can be wildly successful building an app with either one. It comes down to personal preference. Your post made it seem like Flask is some graveyard of dead libraries and you can't build anything successful with it but that's not the case.

Post reply on HN