Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Decline of Django

david-dahan.com

Post reply on HN
Print view View original

161–170 of 173 posts

Re: The Decline of Django

#161

Post by mdew »

ajford wrote: post #139
robertwt7 wrote: post #38

Django is good. But I’ve used laravel and .bet core a lot before trying django for my personal projects. Honestly I get what the author meant by the docs is overly documented. It’s not to the point, also it’s hard to find things. Aside from all the sweet things you get with django, creating an api only project feels very “hacky” for me with an extra package to install (DRF)

That's my main issue with Django, and why I prefer a "bring your own modules" framework like Flask. Django is very "batteries included", but if you're not using the full Django paradigm, it gets more finicky. That said, Django with DRF to float an API-only project/backend is almost standard at this point, and a great option if the devs are already familiar with Django. They can leverage the existing experience and ge…

People basically don't know what they want. That applies to developers as well. Sometimes we want things to be built-in. Sometimes we want to bring our own modules. Can we just agree to do and choose whatever works best for us at any point of our developer's life?

Re: The Decline of Django

#162

Post by montblanc »

innocentoldguy wrote: post #64
mickjagger wrote: post #2

What’s better?

Here’s my subjective suggestion and a list of things I like about it in no particular order: As someone who has used Django, Rails, and Node, I’d recommend Elixir and Phoenix. Elixir has excellent tooling and dependency management, is functional and therefore easier to write concurrent applications with, it stores threads in private memory and uses the actor model for interprocess communications, and since it is trul…

Phoenix/Elixir is so niche I don't know how you can put it in the same line as Django/Rails/Node. There are major consquences to picking something so niche most companies will not go along no matter how awesome the tech is.

Re: The Decline of Django

#164

Post by midrus »

Looks like the typical naive person that would critique the admin UI, the ORM, the documentation, the template system, etc and would then opt for doing his own thing in pure python and just flask and this other library and end up with a terribly worse implementation of everything he was complaining about.

I've seen this with my own eyes in the past.

Re: The Decline of Django

#165

Post by midrus »

jmstfv wrote: post #20
mickjagger wrote: post #2

What’s better?

Rails. Switched from Django two years ago and never looked back. Having worked with both, Rails is more polished and pleasant to work with. Side note: if you're building a business and already know Python/Django, stick with them!

I love the fact that rails also provides a solution/opinion to the frontend part. Django sounds like nowadays can only be used for backend.

Re: The Decline of Django

#166

Post by innocentoldguy »

montblanc wrote: post #162
innocentoldguy wrote: post #64

Earlier quoted context omitted.

Here’s my subjective suggestion and a list of things I like about it in no particular order: As someone who has used Django, Rails, and Node, I’d recommend Elixir and Phoenix. Elixir has excellent tooling and dependency management, is functional and therefore easier to write concurrent applications with, it stores threads in private memory and uses the actor model for interprocess communications, and since it is trul…

Phoenix/Elixir is so niche I don't know how you can put it in the same line as Django/Rails/Node. There are major consquences to picking something so niche most companies will not go along no matter how awesome the tech is.

Niche? Maybe in some areas. There are at least 10 companies using Elixir within biking distance of my house. I've been working with Elixir professionally for six years and have never had an issue getting a job or hiring people. Things may be different in your area.

Re: The Decline of Django

#167

Post by montblanc »

innocentoldguy wrote: post #166
montblanc wrote: post #162

Earlier quoted context omitted.

Phoenix/Elixir is so niche I don't know how you can put it in the same line as Django/Rails/Node. There are major consquences to picking something so niche most companies will not go along no matter how awesome the tech is.

Niche? Maybe in some areas. There are at least 10 companies using Elixir within biking distance of my house. I've been working with Elixir professionally for six years and have never had an issue getting a job or hiring people. Things may be different in your area.

Yes, niche, as in not in the top 50 in Tiobe index, as in less than 25k people on the Elixir subreddit, as in around 1000 jobs in the whole of the U.S which is a fraction of the popular stacks. Niche. No matter which measurement I go with Elixir isn't anywhere near the top 20. The third one (spectrum) is actually a combination of 11 measurement metrics, so before you yell at me that Elixir devs don't use Stackoverflow - Elixir isn't niche only on Stackoverflow. It's just niche, period.

https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2... https://www.tiobe.com/tiobe-index/ https://spectrum.ieee.org/top-programming-languages/

Re: The Decline of Django

#168

Post by montblanc »

Chris2048 wrote: post #54
rmoriz wrote: post #40

Earlier quoted context omitted.

Someone needs to coin the term "mansion-shedding": Bikeshedding, but it's about the choice between two or more proven, reliable, working solutions.

I'd argue it's not the same thing. Bike-shedding happens over trivial, subjective things where any opinion is as valid, and hard to rebuke because of the subjectivity . When it comes to arguing over large projects, the difficulty to rebuke comes not from subjectivity, or trivial-ism, but from the project being so complex there are few with the context/experience who can properly compare the two.

There is tons of subjectivity in software development; people can't even agree when types are better than duck typing and vice versa. Even if there is some definite answer to all these questions we are not all ever going to agree on it in big numbers, so yes I think language framework wars can be called bikeshedding in most cases. Especially considering comparing Rails and Django is comparing two very very robust, "old" and proven solutions with about equal performance and feature set. Even the syntax is pretty similar. If one is objectively "better" it's not gonna be by much. It's not gonna matter at all to your average project which one you choose.

Re: The Decline of Django

#169

Post by ajford »

mdew wrote: post #161
ajford wrote: post #139

Earlier quoted context omitted.

That's my main issue with Django, and why I prefer a "bring your own modules" framework like Flask. Django is very "batteries included", but if you're not using the full Django paradigm, it gets more finicky. That said, Django with DRF to float an API-only project/backend is almost standard at this point, and a great option if the devs are already familiar with Django. They can leverage the existing experience and ge…

People basically don't know what they want. That applies to developers as well. Sometimes we want things to be built-in. Sometimes we want to bring our own modules. Can we just agree to do and choose whatever works best for us at any point of our developer's life?

Totally agreed. That's why I pointed out the difference. I've used many frameworks, and each brings it's own flavor and benefits to the table.

I wasn't disparaging Django, just commenting on my issue with it. I still used it for 2yrs, but the batteries included nature of it is something that most of my projects don't call for. When I was primarily working on web apps, I made heavy use of Flask for back-ends and APIs, with various flavors of JS for front-ends.

In one role however, we had an entire CMS/CRM/Subscription engine written in Django, and it was rather solid. Since everything was in Django, it all worked together well. When I started working with this app, it was in poor shape (and a couple versions out of date) but when we brought it up to date it was real nice. We could make good use of Django signals for all sorts of things with little extra effort, and the variety of plugins available was just fantastic.

I think the biggest skill a dev can develop is learning to recognize the pros and cons of a framework or language or tool without developing too much of a prejudice for any given one. Recognize that they are all just tools, and some are better suited for some tasks then others. Doesn't mean you can't press one into service if it's a poor fit, just means you'll need to do extra work.

Python might be a poorer fit for a highly parallel real-time task compared to something like Rust or Go. Doesn't mean you couldn't use it, but using a better option would make things easier. If you want something with an ORM, template engine, signaling system, and caching layer all built in with minimal fussing about with other libraries, Django is perfect. If you JUST want a rest api, perhaps FastAPI or Flask might be a better choice.

Re: The Decline of Django

#170

Post by ledauphin »

nuerow wrote: post #121
ledauphin wrote: post #115

Earlier quoted context omitted.

I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet.

> I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet. You should really refrain from filling in the void in your understanding or knowledge of anyone else's experience with output from your imagination. Also, I'm not sure you noticed the absurdity of trying to s…

I took the point of the article to be that Django is making no effort to enter the now fairly idiomatic world of static type checking in Python?

I guess we could reasonably debate about the meaning of "nice-to-have", but for some people including me, I would find working with a framework that thwarted my efforts to statically type my code to be more than just "not nice" - I would actively avoid it. Which, again, I believe gets at the heart of the article. There are plenty of folks who will choose not to use Django precisely because it seems not to be evolving alongside the language.

Post reply on HN