13 ms·

The Decline of Django

• pydry 5y ago
  It might just be me but I really wish 95% web apps/sites didn't try to be single page apps. They have obscure failure modes, they're harder to QA, they require huge amounts of bandwidth and they're expensive to build. Django's postback model might not be a model of what front end developers want to use for their backend, but it's definitely a model of how I like my frontends to behave - sparse and minimalist with a limited number of possible behaviors.
• greenie_beans 5y ago
  I just want to point out the typo in the heading for the critique about bad documentation: > Oudtated Documentation
• kelsolaar 5y ago
  I don’t buy in “the dealing with two IDEs is not an option”, many people use many IDEs depending on what they do. I find myself jumping between PyCharm, VSCode and Visual Studio all the time at work. At home, I will have PyCharm running permanently as the core programming environment for the colour-science projects and VSCode also in the background for everything else.
• deleted 5y ago
  [deleted]
• languagehacker 5y ago
  I'm pretty happy with the Django projects I start out these days. Most of them are just GraphQL APIs that interact with a React SPA, with a nifty admin built right in. You don't necessarily need to use all of the components of Django to get a tremendous amount of value from using the framework. It used to be a very much "batteries included" framework, whereas now I'd consider a bit closer to "cafeteria Catholic". Still philosophically a far cry from "omakase".
• havelhovel 5y ago
  I appreciate the article as a list of ways Django could better align with the author’s personal preferences, but nothing here is a case for Django’s “decline.”
• mickjagger 5y ago
  What’s better?
  • bluewalt 5y ago
    I don't know Phoenix enough to make a fair comparison, but I'd say it have major features Django doesn't have (like LiveView), but the opposite is probably true. But as soon as you go to the JS world, you won't find any full-featured framework like Django or Rails. The Django's philosophy is that all components are built by Django team itself whereas in the JS world, existing frameworks tend to gather independent components and define conventions to make them work together in an elegant way, which is very different.
    • alsoicode 5y ago
      Keystone.js has an admin similar to Django, but nowhere near as full featured.
  • realce 5y ago
    Just using Django as an ORM and not a templeting library
    • DonHopkins 5y ago
      I really like the Genshi templating language, which TurboGears uses by default. Genshi is a descendent of the Kid templating language, but it uses a (debuggable) streams-based api instead of compiling templates to (undebuggable) Python code. You can use Genshi with Django, of course. https://en.wikipedia.org/wiki/Genshi_(templating_language) https://en.wikipedia.org/wiki/Genshi_(templating_language) https://pythonhosted.org/Genshi/templates.html https://pythonhosted.org/Genshi/templates.html https://genshi.readthedocs.io/en/latest/api/template/ https://genshi.readthedocs.io/en/latest/api/template/ https://pypi.org/project/django-genshi/ https://pypi.org/project/django-genshi/ https://github.com/phispi/django-genshi-template https://github.com/phispi/django-genshi-template
      • 5y ago
• deleted 5y ago
  [deleted]
• Jyoost 5y ago
  Django has never been more popular. The problem is the group of people who think it is only a back-end for react. Htmx and alpinejs are trying to debunk that stereotype.
• blacktriangle 5y ago
  Eh a lot of these seems like strengths of Django. Rails chasing the SPA dragon has been a source of endless pain.
  • the-dude 5y ago
    Could you elaborate? After a ~10 years hiatus I revisited Rails last year and whipped up a CRUD app with auth in no time. No SPA in sight.
    • blacktriangle 5y ago
      They've been mucking with the asset pipeline every single version and their forray into webpacker has been a disaster. Turbolinks and ActionCable have been attempts to compete with SPAs while still being SSR but both are just glitchy and a source of endless Heizenbugs. Thankfully Rails7 looks like they've restored sanity.
      • the-dude 5y ago
        I must admit that zhe Turbolinks does glitchy stuff with the theme I ripped ( project is in the Ask-for-forgiveness stage ). But you don't need to use Actioncable at all. But I do use it, to have my C/C++ clients communicate with the SaaS. Haven't experienced anything flaky there yet and I am glad a Websocket option was included.
      • louissm_it 5y ago
        I have high hopes that Rails 7 will be much saner. Importmaps are such a Railsy solution, and if you need anything more jsbundling-rails will provide easy starters for ESbuild, Rollup and Webpack.
    • pydry 5y ago
      This was always Rails' strength from day one. The problems came when you tried to do anything that didn't fit into the guardrails laid down by RoR.
• devwastaken 5y ago
  If I were to have a Django backend and only be serving Json responses, what combination of methods/libraries are commonly used for that? Such as input validation, client side request sending, etc.
  • fixmycode 5y ago
    I think the only real option here would be DRF, it's a very mature library to switch Django from website builder to API backend
    • tedmiston 5y ago
      Agreed, Django + DRF provides everything you need for this use case out of the box.
  • phn 5y ago
    That would be django-rest-framework.
  • JshWright 5y ago
    That's probably not the right use case for Django (I say this as someone who defaults to Django for new projects unless there's a compelling reason not to). Something like FastAPI would be better suited to a narrow use case like that, as that's what it specializes in.
    • tedmiston 5y ago
      I would also prefer to use FastAPI [with Pydantic models] for something like this today too. That said, this is Django + DRF's bread and butter, even if the framework itself is a little dated these days.
  • uyaij 5y ago
    I've recently started using Django Ninja at work, and I really like the FastAPI-like request/response schema handling. [1] https://django-ninja.rest-framework.com/ https://django-ninja.rest-framework.com/
• jonwhittlestone 5y ago
  what's the point of this post? what a neghead.
• toxik 5y ago
  "Not as hip as tiktok" and not modern because the page reloads when navigating? It's not suitable for an API because... no real reason given, and the myriad projects doing this left unmentioned. I think there are a lot of good reasons to criticize Django, this blog post failed to find them.
• zitterbewegung 5y ago
  Is instagram not hip anymore ? I’m using fastAPI after moving to flask for a personal project but all of these microfraneworks make me want Django for what is built in. Also , why not have backend frameworks in JavaScript? Everyone focuses on performance and disregards ergonomics. > I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
  • ensignavenger 5y ago
    You may want to keep an eye on https://github.com/vitalik/django-ninja https://github.com/vitalik/django-ninja Its still a bit young, but I like a lot of what they are doing. As for Instagram, I wonder if they replaced the ORM with their own in-house ORM or something else?
    • zitterbewegung 5y ago
      I’ve heard of another company that replaced Django’s ORM with sqlalchemy. Also, I am going to switch to Django ninja fastAPI is good but this is a backend to a video game so I’m going to need a backend and login information and you can add a CMS using wagtail which I will need so thanks for the link :)
• stuartbman 5y ago
  I can't comment on every use case, but I've recently been using htmx[1] with Django templates to provide sort-of async behaviour. For me it's the best of both worlds; I can specify my template and view as though it's a normal page load, and then use some hx- attributes to make it async. 1. https://www.mattlayman.com/blog/2021/how-to-htmx-django/ https://www.mattlayman.com/blog/2021/how-to-htmx-django/
  • NoGravitas 5y ago
    Yep. I wrote a web app a few years ago that was moderately popular in its niche, using Django and htmx's predecessor, intercooler to add interactivity. I think the big issue with this article is that the author fundamentally wants to write client-side apps, and Django is a server-side framework, so it's not really meeting his needs. The async issue is valid — I have wanted to use server-sent events with intercooler/htmx — but the answer seems to be just to use Django Channels, or be patient and wait until the async features are actually finished.
• habibur 5y ago
  "The decline of Django" -- should come with what replaces it note. Where people are fleeing from here? or which new tech is better for these requirements?
• deleted 5y ago
  [deleted]
• ldiracdelta 5y ago
  Never used anything but Django REST Framework as far as Django goes. Couldn't be happier. Love the ORM. https://www.django-rest-framework.org/ https://www.django-rest-framework.org/ (I have other controversial opinions like GraphQL is the new XML SOAP)
  • abledon 5y ago
    > (I have other controversial opinions like GraphQL is the new XML SOAP) Wow, that is a funny observation haha, hope to see a post expounding on that idea on HN someday
• phn 5y ago
  The only point I can sympathize with a little bit is the default admin UI looks, which could be a little more modern. In any case, I don't know of any one other framework with a remotely comparable admin interface in terms of capabilities and usability out of the box, so there's that. I'd be happy to be proven wrong. For everything else (even async with channels), as long as you don't stray too much from the django way, you'll be immensely rewarded by how neat and easy to navigate even large applications look.
• bwood 5y ago
  Seems like a strange bit of feedback to me. My company uses Django as the backend for our REST API and it's simply phenomenal. Django isn't a complete solution out of the box, but that's why things like Django REST Framework [0] exist. It supports JSON-based views and has an excellent serialization layer that can map directly to the ORM models. This setup does NOT help with serving our frontend app, but we're using React for that anyway and I'm not sure I'd want our frontend so tightly coupled to the backend. The fact that Django is mature and extremely stable between versions is a huge selling point for us. I'm not interested in making sweeping changes to our backend just because someone invented a new paradigm that may or may not be helpful to our app (eg, GraphQL). That said, rendering HTML templates server-side does feel pretty archaic these days. I think it would be great for Django to take a more API-centric approach for a default installation. I can imagine that anybody coming from the JS world would feel totally out of place in terms of how Django works out of the box. [0] https://www.django-rest-framework.org/ https://www.django-rest-framework.org/
  • mikepurvis 5y ago
    The core DNA of Django has always been conventional publishing / content management. It's usable for SPA, hybrid rendering models, and so on, but I would be nervous about putting in too much to make those first class, vs just steering people to other projects or frameworks for which those types of uses are the primary target.
  • sillycube 5y ago
    But the template renderer is so powerful. I can easily any print any data to the frontend. I do both Vue and Django in hybrid.
  • spookylukey 5y ago
    I think the case for server-side HTML rendering has never been stronger, and of all Django projects I work on, the ones I enjoy most are those that never got on the SPA bandwagon. From both a developer and user point of view I find them much faster and less painful. There are many cases where you really, really don't need the massive amount of extra complexity involved in designing APIs, adding JS frameworks etc. When you need a bit of extra UI goodness, htmx https://htmx.org/ https://htmx.org/ is a fantastic solution, and you can still use SPA-type approaches for things that need them. You can also benefit from massively faster (and more reliable) functional testing when you are mostly standard HTML - see django-functest https://github.com/django-functest/django-functest/ https://github.com/django-functest/django-functest/ for an example of this.
• rusbus 5y ago
  The fundamental premise of this post is that a boring web framework is bad, but making basic websites doesn't need to be an exercise in bleeding edge frustration. Django, many years later, still presents a straightforward solution to a straightforward problem, (almost) all batteries included.
• robertwt7 5y ago
  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)
  • ajford 5y ago
    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 get right to work without needing to get up to speed with a new framework. In regards to the documentation, the module index can help a bit. If you know the module space you need to be in (i.e. you need to do something with the DB), just jumping into the module index and looking for entries in relation to django.db can get you in the ballpark real quick.
    • mdew 5y ago
      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?
      • ajford 5y ago
        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.
• TameAntelope 5y ago
  1) Documentation is too verbose 2) Onboarding new developers lacks IDE specific tooling for free 3) Admin GUI isn't great 4) Async support is still incomplete 5) Static types aren't used in Django 6) Django is MVC which isn't useful if you just need a light V 7) People ignore other, newer tech because Django exists What??? 4 and 5 are legit complaints, the rest is literally the nittiest of picks, in my opinion. You don't like a framework because it's so good, people don't experiment with newer frameworks?? And that's in your article about the decline of that framework? This is a weird article, man. I am surprised they haven't figured out async yet, and I guess if you really like static types the lack of them in Django would be annoying, but otherwise this just seems like you set a goal to write about a topic, and forced yourself to come up with an article you thought hasn't been written before. Like, it feels like you wrote the title of the article, and then tried to come up with the rest of it after the fact.
  • dc-programmer 5y ago
    Number 1 isn’t a show stopper in any way but is it pretty annoying. The primary django docs are very textual and place more emphasis on developing intuition and understanding context, than something that can be quickly referenced. Also a lot of the method parameters are either not documented or not explained. I think Django would benefit from a more technical and complete but less dense secondary reference.
    • grenoire 5y ago
      I fully agree, it usually ends up being barely useful, and not enough. It does not explain how certain parts of the magic happen, what the best practices are, what the expected types for arguments may be, etc. It's not bad, but usually verbose in the wrong bits, and sparse in the details.
    • ianai 5y ago
      “ more technical and complete but less dense secondary reference.” Isn’t that basically just reading the source code? Like I get that’s probably not right to throw everyone toward, but reading source code is a staple task for working with FOSS.
• someotherperson 5y ago
  I don't really understand this article at all. It comes across as a rant rather than picking on anything that actually points to a decline. Django is fully featured and still fast as ever. There are dozens of packages out there that extend it and the nature behind the way Django was built it encourages those packages. It seems that the only genuine gripe is with documentation. Okay -- so contribute those changes? I've contributed documentation to lots of packages I use, including DRF, celery and so on. It's an open source project with an awesome community behind it. If you feel that docs need updating, then update them. It doesn't mean there is a decline in any way, shape or form just because it uses IRC as a support channel[0] rather than Discord. [0] Worth mentioning that the Django support channel is perhaps the best support channel for any similar project of this size you can find
• mtberatwork 5y ago
  Eh, "[insert stable, mature MVC framework] is dying/dead/etc" articles are a dime a dozen on the Web. I suppose it could be considered a badge of honor for a framework to have some internet punter declare the framework as "dead". But, just to nitpick... > Bad Official Admin GUI UX For anyone reading, Django's admin tool is designed for situations in which you need to stand up a quick admin or build some internal admin functionality. For more complex cases, you build your own admin to fit your user needs (including the UI/UX). From Django's own documentation: > The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around. [1] Also, regarding documentation, in my opinion I have yet to see any project have better documentation than Django. [1] https://docs.djangoproject.com/en/3.2/ref/contrib/admin/ https://docs.djangoproject.com/en/3.2/ref/contrib/admin/
  • arkh 5y ago
    > in my opinion I have yet to see any project have better documentation than Django I'm partial to Symfony. Good "getting started", per component documentation and links to cookbook-style articles for things people tend to want to do.
    • jgwil2 5y ago
      Symfony is a great project, I just feel like, in comparing it to Django, there are so few people who would choose PHP over Python that it's not really a fair fight.
      • kyriakos 5y ago
        I think that depends where in the world you are.
    • olorton 5y ago
      I've used Symfony for years, and Django for 2 years full-time, and I have to say that I find the Symfony documentation is much easier to learn from.
    • 5y ago
• olavgg 5y ago
  Same thing with the Grails framework, which is another Rails framework for Java eco-system. After Grails got refactored between 2.x and 3.x which broke all plugins, most new Java projects went with Spring Boot. Popularity of the Grails framework has declined a lot since the release of Grails 3.0. But the strong decline the last few years I mostly blame on all MVC framework not being interesting enough for new young developers. Only David Heinemeier Hanson has a loud strong voice telling the world about how fantastic the Rails and MVC web application really are. Which makes sense considering that I feel Rails is still super popular. But my preference is not Ruby, but rather Java :-) and I feel Grails is still awesome. And I also use Spring Boot for some projects.
• jonnycomputer 5y ago
  Found lots of things rubbed me the wrong way about this post, though tbh I really haven't done Django dev; only Flask. I'll just nitpick on their bagging on Pycharm. Pycharm is great. Frankly, I like it better than VS Code; though I do grant VS Code has its strengths, especially as a lightweight capable code editor.
  • Chris2048 5y ago
    Pycharm gets little love, esp comapred to the free alternative, VS code. I actually like, use, and pay for PyCharm, but it annoys me when JB chase new (ds) customers with DataSpell, or teams management stuff with "Space", When long standing, trivial Pycharm bugs have gone unfixed for years; https://youtrack.jetbrains.com/issue/PY-14743 https://youtrack.jetbrains.com/issue/PY-14743 [0]. I have no hope Pycharm will innovate any time soon, and will eventually fall behind more motivated IDEs. Also, the whole "IDE specific to one language/domain" thing is a little Janky when, IDEA with plugins vs the "specialised" IDEs can differ so much. I feel JB are trying to build a single code base to spawn multiple, separately marketed, product more than any advantage to end-users. For a while I had to keep switching from PyCharm to IDEA just for Jenkinsfile support.. [0] more context: https://stackoverflow.com/questions/27475432/pycharm-docstrings-linking-to-classes https://stackoverflow.com/questions/27475432/pycharm-docstri...
    • ajford 5y ago
      That's par for the course with JetBrains. I'm a big fan of PyCharm, don't get me wrong. It was the first IDE I've tried out of maybe a dozen that actually gave me a reason to convert from Vim with plugins and a number of self-written project mgmt/organization tools. That said, JetBrains often rolls out new things while sitting on long-standing bugs. There's three or four issues in PyCharm and TeamCity that I've been tracking for a couple of years that are older than my kids. Hell, I think one of the TeamCity issues is almost old enough to get a learner's permit.
      • jonnycomputer 5y ago
        This is true.
• jgb1984 5y ago
  An article of unsubstantiated nonsense with a flamebait title.
• dmtr78 5y ago
  The worst part of Django is ORM. Unfortunately, this is the main part, too.
  • megaman821 5y ago
    That was true maybe 8 years ago, but it is definitely top tier now.
• recursivedoubts 5y ago
  some decline: https://insights.stackoverflow.com/trends?tags=django https://insights.stackoverflow.com/trends?tags=django Would django benefit from a marketing refresh? Of course. Unfortunately, unlike rails, it isn't a passion project for an independently wealthy person. At the risk of self-promotion, htmx is making all of these excellent, mature server side frameworks relevant again. They are very good at producing hypermedia and, if you don't try to turn them into dumb JSON data terminals, they can be extremely productive and produce wonderful applications.
  • Mikeb85 5y ago
    Not sure I'd call Rails an independently wealthy person's 'passion project'. He's wealthy because of his startup, which Rails came from. Rails development happens because Basecamp makes things with it...
  • mdew 5y ago
    I wonder how seriously this kind of graph should be taken. IMHO, it surely correlates with the number of newcomers, but also, with how newcomer-friendly a topic is.
• nicolaslem 5y ago
  > If you're a 22 years old student, you probably never used and will never use IRC. It seems that the author does not realize that filtering out 22 years old students may be a feature, not a bug. If you need to be convinced just look at the dev mailing list before Google summer of code, lots of low effort proposals borderline on spam. I cannot blame maintainers for trying to shield themselves from some users. An advice from someone who was a 22 years old student not so long ago? Learn to use IRC, it's awesome!
• est 5y ago
  > But what if tomorrow, Microsoft launches a full-featured node/Typescript framework? You would get: > all modern features and tooling Django has failed to provide over the last years > having to master only one language as a developer. > safety of a big corp to maintain the framework, rather than relying on individuals Yeah that's called ASP.NET
• jmugan 5y ago
  I don't understand why a Python programmer would move from PyCharm to VS Code. PyCharm is pretty perfect as far as I can tell. I've tried to move to VS Code a few times to keep up with the cool kids, but I always seem to run into weird problems.
  • staticautomatic 5y ago
    I agree. VS Code is a perfectly nice general purpose IDE but for Python work there’s really no comparison to PyCharm.
• zzzeek 5y ago
  > Django looks like the 40 years old guy who feels "in" using Facebook, while everyone else is already using Instagram or TikTok. wow fuck ageist bullshit like this. everyone knows I'm no big Django advocate but what is the point of a blog post like this? I'm not seeing how effort spent on writing articles like this makes the world better for anybody, including the author. Go create something? >But what if tomorrow, Microsoft launches a full-featured node/Typescript framework? You would get ... In my opinion, a framework like this would nail it it's all you bro, *go write it* and show everyone how right you are!
  • tedmiston 5y ago
    I also found the comparison of web frameworks being cool or trendy like social media apps to be bizarre / nonsensical. I don't want my web framework(s) to be trendy, or cool, or in — I want them to be battle-tested and "just work" regardless of implementation language.
  • deleted 5y ago
    [deleted]
  • billyjobob 5y ago
    Especially since a 40 year old on Facebook today will have been using it since he was 26, or possibly 24 if he was at college at the time. So he’s going to be well aware that Facebook isn’t a new hip thing. (Although he might have seen the damage that Facebook did to his mental health over the years and wisely decided not to sign up for Instagram and Tiktok when they came along, so that part is not so unrealistic)
    • Aloha 5y ago
      Which is how those of us (few) holdouts still posting on LiveJournal feel, we know its not the in thing anymore, but we prefer it because of the advantages that it has.
    • daveslash 5y ago
      This hit home for me. I'm not yet 40, but I'm not too far off. I was using Facebook in college back in 2005. My usage had been tapering off for a couple of years, and I I permanently closed my account about around late 2015. I haven't signed up for any social network/platform since, except for Instagram that I use solely to post photos from my budding photography hobby. I only post photos in which there are either no people at all, or no recognizable faces. I only "like" photos that fit the same criteria, and I only follow people who I know very well in the real world. If I see a photo of a birthday, wedding, etc.. that I would like to "like" ~ I don't like it on Instagram; I pick up the phone and text/call/reconnect.
• FrameworkFred 5y ago
  Some of the author's complaints are legit, but they hardly constitute evidence of decline. First, I figured out how to do Django+Tornado in a day 8 years ago and PyCharm pays for itself over and over, every day. The rest of the arguments might deserve mention in a conversation about how the project could be improved, but it isn't clear to me that they presage Django following Visual Basic down the drain. I'm sure the Django maintainers would entertain PRs for any clear improvements over what's in place and lacking.
• deleted 5y ago
  [deleted]
• lewisjoe 5y ago
  This post radiates an idea that Django is a dying framework. I cannot emphasise how wrong the entire premise is. I’ve used a bunch of frameworks all over the python/nodes/jvm ecosystems. But every single time I come back to Django, it’s a breath of fresh air where I don’t need to plumb common patterns for my case. It’s so mature that any use case I run into, the solution is just a google/documentation away. If at all it’s true that Django is dying, I’d really be sad to see such a mature framework go :(
• jimhi 5y ago
  Every couple of a years Y Combinator CTOs do a survey of their MVP. Every single time Django on Heroku wins. If it's on the decline, I doubt it has fallen out of first place yet
• iainctduncan 5y ago
  This article is a cry for attention, at best. I suppose yet another dev bought into the "you should start blogging to become a thought leader". However, it reveals character traits that won't be helping the author: shitty writing, ageism, negativity, and blaming. Seriously author, you did not help yourself.
  • _hilro 5y ago
    He's "CTO as a service" Imagine turning up to a job and this guy is in charge of decisions...shudder.
    • mrzool 5y ago
      > CTO as a service Jesus Christ.
• ihuk 5y ago
  This guy sounds like a textbook example of CV driven developer. I've delivered large amount of value to business with boring technologies like Java, Django and made good money in the process. Sometimes all the client needs is a simple CRUD app. Coincidentally, I turned 40 this year.
• nostrademons 5y ago
  I mean, web development is kinda like that 40 year guy who feels "in" using Facebook. As an industry it's 25 years old and approaching maturity. The author cites Node and TypeScript as where the cool kids are, but that was where the cool kids were 8 years ago. The cool kids today are into cryptocurrencies, AI, and robotics. Even there, some of the frameworks you probably think of bleeding edge are already losing mindshare. TensorFlow is giving way to JAX, Bitcoin already gave way to Ethereum which is itself getting eclipsed by Algorand, Cardano, and Solana.
  • p1esk 5y ago
    The cool kids today are into cryptocurrencies, AI, and robotics That too is where the cool kids were 8 years ago... Even I was into all that 8 years ago and I was never a "cool kid". I have no idea what the cool kids are into these days. AI is still hot though, so perhaps they are building GPT-4.
    • nostrademons 5y ago
      Still there, just different frameworks. Think of AI 2012 = Web 1995, TensorFlow = Netscape, PyTorch = IE, and Jax = Firefox. We're at about 2004 and Chrome hasn't been invented yet. There's probably another "pole" of the ecosystem (analogous to server frameworks like Rails & Django) that also hasn't been invented yet. Or in the crypto world, Bitcoin 2009 = WWW 1989. Ethereum 2015 = Netscape 1995. Facebook Libra/Diem 2019 = IE5 1999, except less successful. Actually useful cryptocurrencies haven't been invented yet, although they probably exist in nascent form. Think of how the web came to be primarily used for social media, communications, discussions, information - all of which existed in the form of Fark, SomethingAwful, Xanga, etc. in 1999, but MySpace, Facebook, LinkedIn, Reddit, YouTube, Yelp, AirBnB etc. were all in the far-off future.
• Chris2048 5y ago
  Django is (or was) one of the "famous" Python frameworks (there was a time when most Python jobs where Django jobs, or the "gateway" to Python was via Django). Yet I also thought it broke a few Python conventions, being fairly tightly coupled..
• makeitrain 5y ago
  As a Drupal developer, I understand what this article is saying. The issue is that these systems are built for an older paradigm and not meeting the needs of today's developers. It's taking time to adjust existing code to the new ways, and the developer crowd that built them is interested in new things. Some projects need the rapid development capability of a CMS, but want the front end flexibility of a js app. The problem is that the plumbing produced by these systems are geared to serve whole pages, and not an API first app. We've added the ability to layer an app on top of the CMS, but most of the content and admin pages don't fully use ajax (at least in drupal). The reason for the current problem is that these open source frameworks required a ton of contribution to become successful. That effort has moved on to new projects with fresh architecture. But those still don't have nearly the same level of features as traditional platforms. One of the challenges I see for building the perfect system is having all the front end features and components integrated. In Drupal, a module may add a component with template and some css/js. Other modules are free modify or mix this component with others, so the data model, styles, and js all need to be compatible. Drupal solves this by standardizing on jquery, which was a wonderful solution for the last decade but now people don't want to use it. I think to get the same level of compatibility in a js app, you would have to define the components to be included by the system. These are the batteries they currently don't include. It's less of a technology issue and more of a challenge of defining standard ways of doing things that are not overly opinionated. I would love to have an easy point and click CMS that lets me quickly assemble 80% and a streamlined development experience for the rest. I can imagine something integrated with the cloud and IDE that is super quick and cheap to spin up a complex application. Sorry if I'm just complaining about drupal in a django thread. I think the issue for both is whether we can get where we want from here or if recreating the ideas in a new language will get more traction. Or if these platforms are good enough, they'll continue to have a place in the back end, allowing users to manage content and data for custom apps.
  • smashed 5y ago
    I've done both Drupal and Django work in my career. You are right they were both invented for the full html page generation on every request paradigm. Django's concepts are much simpler though. Building a headless, API only, back-end feels very natural. You just skip the html templates. You don't even need special libs like Django rest framework. Drupal was invented imho, to solve a much different problem set: the community-built CMS. This is where there are many different class of users going from anonymous to full admins that can perform wide range of write actions. It probably excels in this niche. Django can do it, but using custom code/calls where you'll implement most of the logic. Drupal exposes configurations that you can tweak (and have to manage). You hint on the combinating nature of Drupal modules where every thing can override anything. That is, for me, largely the reason I stopped using Drupal. The Drupal best-practices back in the days (6-7-8), led to awfully unmaintainable code bases for anything remotely complex.
• thomas-guettler 5y ago
  Django, Python and htmx.org are great. Neither old nor boring. It works. The docs are great. It works on raspberry up to huge cloud setups. Have fun
• erichanson 5y ago
  I wish there was still a "for me to poop on" app so I could poop on this. -40 year old guy
• midrus 5y ago
  Don't waste your time reading this.
• midrus 5y ago
  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.