161–170 of 192 posts
Earlier quoted context omitted.
wouldn't it be faster/safer to upgrade to latest django/python rather than rewrite it in React/Go?
Python 2 to Python 3 in a Django codebase ... may be a full rewrite anyway.
Earlier quoted context omitted.
I feel very comfortable with Django on the frontend, what are you missing there? I usually use Tailwind or Bulma, with HTMX and AlpineJs. I feel like the experience can be very much React like, even if you leave out HTMX. The frontend game of Django really changed about 2 years ago (at least for me).
Glad to hear that works for you. But nothing of what you are mentioning is part of Django, nor an official package,etc. And I’m not going to get into the details of whether that stack would work for non backend developers, developers working on medium/large projects and/or medium/large teams. That’s a separate and unrelated discussion. But compare what Django brings you (Stone Age templating system and that’s it) to…
Earlier quoted context omitted.
In what sense is Go not a traditional language for web services? They're almost the only thing it's good at, and it's been doing them for 13 years.
I agree that Go is a good choice for web services. I disagree that it's the only thing Go is good at. DevOps tooling and CLI tools immediately spring to mind.
Earlier quoted context omitted.
Django is a modern web framework. It simply doesn't follow the hype around JS SPAs. However, if you really want to, you can of course still render static content + serve a JS framework like Vue to the client, and then have dynamic widgets rendered on the client side. If you want to build an SPA anyway, then Django is not the right framework to start with though.
I use Django + DRF for SPA. SPA bundle is served from an nginx container, but I don't see any problem building it into the django image either. What is the right framework for building SPAs?
One thing Django has going for it is that the "batteries included" nature of it is perfect for AI code generation. You can get a working site with the usual featuers (admin panel, logins, forgot reset/password flow, etc) with minimal code thanks to the richness of the ecosystem, and because of the minimal code it's relatively easy for the AI to keep iterating on it since it's small enough to be understandable in cont…
On top of this, it's understandable to humans when reviewing generated code. There's no 2000-line FooBarAdmin component where bugs could be located. And if you're having it generate HTML templates, you can see exactly what backend model property/method was used without needing to follow the indirection through backends and prop drilling. And when you do create backends and React components, you can have a known-good…
That being said, the current state of type annotations is a pain: django-stubs works on mypy but with a plugin (and mypy is slow as hell), django-types is a fork a django-stubs that works on pyright but is usually out of sync and pylance ships its owned stubs forked from django-types.
My biggest wish for next Django release would be that they finally ship type annotations themselves where it is possible. I don't need the crazy inheritance parts or the crazy stringly typed parts to be have proper type annotations, but just some simple stuff like HttpRequest, HttpResponse, View, Model, etc would help a LOT !
Can someone remind me how we ended up in the SPA era and why exactly? Was it about not seeing the loading spinner? Or there were more reasons to it?
No one has mentioned it: mobile! Mobile apps became a thing, and there was a strong argument to have one common backend for your web app and your iOS app and your Android app. Plus the mobile UX (especially with iOS apps at the time) was such a gamechanger that there was a natural shift to replicate it in the browser. That said, even though I still build SPAs at work, but I can't wait for the day that I get to build…
PWAs/Webviews/etc are not really practical options.
Earlier quoted context omitted.
Because JS is bad, and JS have a MASSIVE user base, so whatever they do is the web. And because JS is on the frontend, solutions are front end , even the ones that eventually run on the (js) back-end. Is like how people use a RDBMS but never do foreign keys, views, etc and re-invent all, poorly.
I had similar thoughts, but how does one use an RDBMS without making use of FKs? Do they put all in one huuuge table, that has all the columns and is super sparse? Or some other fever dream of bad design?
One of them, not even use "date"/"decimal" types and all is mostly strings, there is not views or anything else, and the tables AND fields are called "F0001..".
One thing Django has going for it is that the "batteries included" nature of it is perfect for AI code generation. You can get a working site with the usual featuers (admin panel, logins, forgot reset/password flow, etc) with minimal code thanks to the richness of the ecosystem, and because of the minimal code it's relatively easy for the AI to keep iterating on it since it's small enough to be understandable in cont…
Ruby and Rails are even better candidates. CSP, Background workers, and many other features that Django still lacks have been standard offerings for sometimes 10+ years!
I worked at an org which has a ‘modern’ NodeJS+React codebase and an ancient legacy Django app on Python 2.7 which is nearing 15 years old. I was worried that the old codebase would be a pain to work on. It was the complete other way around. The Django app was a complete joy to work with and I literally had so much fun tidying it up and working with it that I’ll be sad when they finally retire it in favor of the new…