171–180 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.
2to3 gets you pretty far and theres not much in the rest.
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.
Rails tries to more tightly integrate with the front-end which causes a lot of turn over the years. Django projects from 10 years ago are still upgradable in a day or two. Rails does include some nice stuff though, but I much prefer Django's code first database models than Rail's ActiveRecord.
Those Django models are a pain to work with if you have to access the database with any other tool that is not the original Django app. The only sane way to design a database managed by Django models and migrations is not using any inheritance between models or you'll end up with a number of tables, each one adding a few fields. Django ORM will join them for you but you are on your own if you ever have to write queri…
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?
>Or there were more reasons to it? Internet was slower in both latency and throughput is one reason. The other is general tendency to separate things into smaller pieces. Faster feedback to user is the third. Consider a typical form with 10 fields in django. You define the schema on a backend, some validation here and there, a db lookup and form-level rules (if this field is entered, make the other field optional). T…
Earlier quoted context omitted.
>Or there were more reasons to it? Internet was slower in both latency and throughput is one reason. The other is general tendency to separate things into smaller pieces. Faster feedback to user is the third. Consider a typical form with 10 fields in django. You define the schema on a backend, some validation here and there, a db lookup and form-level rules (if this field is entered, make the other field optional). T…
You still end up separating frontend and backend in full js codebases, but it's not as explicit and can lead to wacky/confusing/unpredictable behavior if you get it wrong. I've never found a perfect solution to the frontend/backend boundary but I've found a mix of declarative container type libraries (pydantic on backend, TypeBox on frontend) with some code generation is a good solution.
If somebody were to reproduce the Django ORM, with full native asynchronous support, it would change Python forever. I know there are people who come from SQLAlchemy and swear by it. As somebody who has used both I can tell you, at least when working with a small team on enterprise software, the ORM blows SQLAlchemy out of the water, in terms of being able to produce quality software, quickly.
For anyone new out there thinking about using FastAPI... don't. You'll find 1 million people on the Internet happy to tell you that it's terrific, and 90% of these people have not built real software. The performance gains are lost, by double when you attempt to build real real software with it. I've worked with it in three different apps, and in all three cases it was used because the front end team insisted that all we needed was REST. In all three cases I have seen page load times that are slower than the 90s, 3 to 10 seconds or more before everything is done on the page. It's actually unbelievable to me that that is the direction a lot of Python backend development has gone in, relegating all the important logic, and, in a lot of cases, security, to frontend niceties.
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?
TBH I also think that Alpine and HTMX are just as dastardly and disgusting, maybe even worse. I don't know why nobody can figure out a good way to just put in reactive components where you need them. All of the frameworks support that, Svelte seems to be the one that is the least against that, but I still don't see anybody using it that way. Front end developers, which tend to have the least business logic experience, somehow captured the entire SDLC. This is why literally all software is just completely riddled with insufferable bugs, beyond anything anyone in the 90s could have imagined.
Good job, template partials looks like a nice improvement ! 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 ty…
> Background Tasks. Amazing. If this means no more management of Celery workers, then I am so happy! So nice to have this directly built _into_ Django, especially for very simple task scheduling.
I see a lot of people in here talking about the "batteries included" aspect of Django, as if that's where it really shines. those batteries are definitely helpful, but the biggest benefit, by far, is the absolute best ORM in existence. If somebody were to reproduce the Django ORM, with full native asynchronous support, it would change Python forever. I know there are people who come from SQLAlchemy and swear by it. A…
I’ve tried every orm in node and nothing compares to Django orm. The way you can scaffold an apps data models is amazing.