It's not that you can't "build a sane architecture" as much as it is difficult to justify the time spent to do this when you can "bang out features" in 10 minutes that would take days to do manually. It's about the economics of code generation. When inventing structure and typing it out as code takes time, thinking deeply about architecture first makes sense. There is another factor, as well: "thinking deeply about the architecture" involves experimentation. You might go down a particular path while coding, and then realize some limitations and/or new ideas, etc. You ultimately craft something that will work well and play well with future code, and which may be easily understood. If somebody stops by your desk and says, "you finish that <3 day feature you were just assigned 2 hours ago> yet?", that'll be the last time you think deeply about anything at work.
Rather than arguing about the specifics, it's easier to point to numerous concrete examples, such as a fairly simple system - which should be easy to implement in 8-15k lines of code, depending on certain choices (I've been writing code long enough to estimate this relatively accurately) - being still-incomplete while approaching 150k lines. These kinds of atrocities are usually economically infeasible in hand-written code, for 2 reasons: 1) the cost to produce that much code is very high, and 2) the cost of maintaining that much code is insurmountable.
I guess you could say that AI is great at generating code that only AI can understand and maintain.
You are absolutely not alone, brother (or sister). In the past few years when a lot of the millennial generation started getting their first jobs, the shiny object syndrome took over and most everything being made now is a distributed monolith pile of spaghetti code trash.
There are endless tools available, and quick internet dopamine feedback loops, but almost no wisdom.
Give it a few more years and more inflation, and the remaining 35% of millennials will get out there to find their first jobs, and then the impact will be even worse.
It absolutely boggles my mind that nothing else exists to fill this spot. Fly and others offer varying degrees of easier-than-AWS hosting, but nobody offers true PaaS like Heroku, IMHO.
It's honestly just an example of ego and coping. These people are trading temporary gains in pseudo-productivity for training their replacements and atrophying their skills.
The truth of the matter is that the people who will choose to partake already weren't thinking; otherwise they wouldn't have chosen. This is the same with every bubble or major revolutionary thing that ends up having negative effects in the long run. GLP-1 is another great example of one that is still on the upward arc.
Sheep will always be sheep, and, in my opinion, this is the reason for the changes in hiring and the large scale encouragement of folks that obviously are not smart enough for this career to suddenly join in over the past 10 years.
I've had the misfortune of working in FastAPI a number of times, and, as somebody who has been using Django since 2008, Django developers have no idea how spoiled they are to have such a tremendous framework.
Django does not provide magic, but it's ORM is like pure sorcery compared to the garbage out there (SQLModel, etc.).
Django provides the necessary tools to build terrific software. However, it does not prescribe extra extraordinarily high-level architectural guidance, so it leaves that up to you. For example, if you are building an app that will have a main UI for users to login, a backend UI for managers to view reports, an API for consumption by outside developers, Django doesn't provide some kind of automatic recommended pattern for structuring your app to support all this. However, it provides the exact ingredients you need to do this on your own. In the example a gave, you would simply structure your directories to reflect the various UI / inputs modalities, and then point a path to each section (urls.py). If you want to host your API as a separate service, you just define a WSGI/ASGI app and pointed to a separate urls.py, then start that container using that WSGI/ASGI app, simple as that. Django does not have any kind of magical mono effect structure to it. It is just a collection of unbelievably useful and clean and simple API that you can use to compose software at least 5x more quickly then you can with e.g., FastAPI. I'm in the second team I've been in that is using FastAPI, and it is uncomfortably slow, you wouldn't even believe it. With FastAPI or other API/micro frameworks, I think the perception is that "it's just python" as if Django is something else, and so people start off app.py and they "see now I can start from this fresh canvas", and then they learn after spinning their wheels for two years that having a solid ORM is actually important, having migrations that are always correct and automatically generated is important, having an admin interface for viewing, creating, managing local/testing data while debugging things, etc. is important, having an ORM that lets you do aggregation and annotation so easily that you find yourself wanting to make reports just as an excuse to use these features, is important, having a template system that lets you generate dynamic pages without having to set up a full SPA for every little interface that you want to make allows you to make a quick prototype or even a permanent UI of some kind without having to involve a team of front end developers who will then begin to dictate your entire backend architecture through their litany of ever changing API endpoint requirements. Speaking of, the common pattern that I have noticed with SPA/API based develop is that the front end wants to be large and in charge, until it comes time to validate data inputs or have to do anything with data that requires looking at it holistically (for example, given a list of orders, if there are any orders that have items that are backordered, provide a warning at the top of the page… SPA developers completely crushed by this requirement, now the backend has to add additional information via the end point called "are there backorder items", etc.). So you end up with this hodgepodge of mess, instead of creating a prototype of your interface and then coming back and deciding which things need to be "reactive", and either shoehorning those things in or rewriting your UI because it's absolutely necessary.
This has become quite the rant, but as somebody who has worked on software for nearly 20 years and can hand write HTML, CSS, JavaScript, use Svelte / React, Python, Django, SQL, etc., I've learned a LOT and seen a lot and I can tell you absolute certainty that choosing Django for a new project is the absolute most effective choice you can make on your path to success.
IMHO, the "new generation" of designers is the problem. Same goes for the "new generation" of developers. Want to make a basic HTML page with a contact form? Better get React + 300 dependencies, require the backend to provide a REST endpoint... fast forward six months...
Why has this happened? Everything is too easy. You used to have to have pretty good intelligence to break into UI design and software development. Now, anyone can do it with 30 minutes of "e-learning", and, therefore, the average IQ of a UI designer/or software engineer has decreased, dramatically.
Yeah it's crazy, people use Django and they think the things that are making them productive are all these little contribs and built-ins, but the reality is it's the solid foundation that is the ORM. BTW, I discovered after writing my comment that tortoise ORM is essentially Django ORM, but written on asyncpg, making it way faster. So, if you're stuck in some other non-Django framework and would like to use the Django ORM, that's probably your closest bet.
I agree, type annotations need work. I just use stubs and then I have some rules to set some of the more common ones to be warnings instead of errors, and then I just deal with the fact that there's gonna be some yellow squiggles.
I sometimes think that the direction web development took is like some kind of bad dream that we will wake up from. It's unbelievable to me. The problems we faced before SPAs were things like "great we've got two forms on the same page and this widget on the top right needs to update when a message comes in from the back end… How will we ever solve this", and before anybody could come up with any good patterns google came on the scene with Angular, and ruined the entire direction of the Internet, forever.
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.
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. 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.
I know from the inside it feels like nothing is wrong, but if you're looking at the EU as a whole from the outside, the economies there have been coming apart for many years. You could even say the wheels have already fallen off. 100% of the economic woes in the EU are conferred by EU membership, and the web of inefficient, bureaucratic laws therein. Geographically speaking, Europe is positioned, perfectly, to be an economic powerhouse. It is close to the Middle East where much of the energy comes from, close to Africa where energy and other resources come from, close to Asia where certain base materials and manufactured components come from, surrounded by oceans everywhere, the Mediterranean has more than 1/5 of the world's coastline, giving ample opportunity to develop commercial ports, etc. The only reason the economies of Europe are in trouble is because of the EU. That is the only reason. The EU is the singular one only single reason. The EU. That is the single reason.
Cookie banners are just one tiny example that illustrates how death from 1000 cuts is a real thing. In the case of cookie banners, you could say it's death from 100 cuts, because, if you live in the EU, you spend probably one percent of your entire life clicking cookie banners. 7.2 minutes a day is all it takes to waste one percent of your productive life (assuming 12 hours of useful time per day). You might scoff at this, "I probably spend 10 seconds", but I spend probably a minute or more dealing with broken cookie banner garbage every day and I am an American. Just from American websites complying with GDPR nonsense, we have to waste some small portion of our lives here as well. Stupid laws written by stupider bureaucrats ruin everything for everyone. This is the description of an idiot by Dostoyevsky, somebody who does things that harm themselves and others.
So many of the basic features (e.g., automatic Python venv, Pyright running, etc.) have random bugs that pop up from time to time, making the basic editor unreliable.
My fear is, if they keep going in this direction (adding bloat without fixing basic functionality), they'll be a perfect fit for Microsoft acquisition, at which point I'll have to switch careers, because there isn't any other editor out there that I like.
I'm typing this on an iPhone SE 2022 (the last one with a home button). I'm done with iPhone as soon as I am no longer able to use this model. I don't like the new, oversized pieces of junk, and I also like the home button as opposed to the new Face ID/swipe up workflow.
For people that have good visual acuity, the smaller screen is ideal; it's such high resolution that you can fit a lot of things in a small area. For people that turn the font size up to 600, the bigger screen is obviously ideal, but nobody really wants to have to hold something that is bigger if they don't need it for the screen size. That's the market I fit in and Apple has abandoned at market, along with all common sense (re: liquid glass, the recent Apple/Google Gemini deal, etc.).
There is an extreme difference between outsourcing physical difficulties to mechanical advantages, and outsourcing your brain to a large corporation that is stealing all of the IP that we have collectively created, as a society, and using it to replace our brains.
It feels clever to make comments like yours right now, but in two years when the order of control flow moves up two more steps and you are no longer needed at all, it'll be frustrating to look back and think "I wish I wouldn't have given money to them."
$650 million is a rounding error.