Live data from Hacker News

Django 6

docs.djangoproject.com

61–70 of 192 posts

Re: Django 6

#61
post #31

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…

And because Django is so popular in open source projects and it has been around for such a long time, there's tons of code out there for AI to train on.

Re: Django 6

#62
post #31

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!

Re: Django 6

#63
post #2

Show of hands for backend web services development - Who uses Django, Rails, or similar full-featured frameworks? Who uses micro-frameworks like Flask? Who uses enterprise Java, Jetty, Dot Net, etc.? Who uses an entirely Javascript stack? Who uses a non-traditional language that has become more web-servicey, like Go, Rust, or Swift? Who uses something so wildly untraditional that it's barely mentioned? OkCupid using…

In a company that uses a traditional web framework like Django to actually build the frontend and backend, not just as only for implementing the APIs, I would even consider doing parts of frontend work again, making everything responsive and so on. That's what I do for a not-yet-startup project.

Re: Django 6

#64
post #22

Earlier quoted context omitted.

- Strict team separation (frontend versus backend) - Moving all state-managament out of the backend and onto the frontend, in a supposedly easier to manage system - Page refreshes are indeed jarring to users and more prone to leading to sudden context losses - Desktop applications did not behave like web apps: they are "SPA"s in their own sense, without jarring refreshes or code that gets "yanked" out of execution. S…

These days with 90% of SPAs being broken piles of browser standard breaking stuff, I find a page refresh or page load to be a soothing experience. They are like checkpoints in the process of using a website. Points to which I can go back using my browser's back button, and I can trust, that my browser keeps track of them. In contrast, when I see an SPA, I need to worry about the whole site going to shit, because I bl…

I feel you. It's definitely a tradeoff. SPAs do tend to be buggier but I can't deny that, when done right, they also tend to be better.

Unfortunately, there's _more_ people, building _more_ stuff, so there's _more_ terrible stuff out there. The amount of new apps (and new developers, especially ones with quite limited skills) is immense compared to something like ten years ago. This means that there's just more room for things to be poorly-built.

Re: Django 6

#65
post #43

Earlier quoted context omitted.

why would you need batteries included? the ai can code most integrations (from scratch, if you want, so if you need something slightly off the beaten path it's easy

I think the logic can be applied to humans as well as AI: Sure, the AI _can_ code integrations, but it now has to maintain them, and might be tempted to modify them when it doesn't need to (leaky abstractions), adding cognitive load (in LLM parlance: "context pollution") and leading to worse results. Batteries-included = AI and humans write less code, get more "headspace"/"free context" to focus on what "really matte…

Maybe if they could learn how to switch their intelligence on, that would help more?

Re: Django 6

#66
post #39
post #13

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?

Because the web was made to render documents, but users want apps. CSS in part is so confusing because its original incarnations pulled heavily from traditional print media layout terms. Everything since then was an attempt to leverage JS to turn documents into applications. Why? Ask any user.

I don't think blaming this mess on users makes much sense.

Smartphones on the other hand...

Re: Django 6

#67
post #62
post #31

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!

CSP is literally in this release, and background workers are intentionally not part of Django because you usually want to offload tasks to other nodes so your CPU can keep serving HTTP requests.

Edit: Background tasks for light work are also included in this release.

Re: Django 6

#68
post #37

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?

As long as you don't give a shit about data integrity, you don't need foreign keys.

Re: Django 6

#69
post #13

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?

Google Maps. Gmail. OWA. There were suddenly pages that let you do things without a white flash between clicks.

It's ALL about the refreshes. Everything else came after.

Re: Django 6

#70
post #22

Earlier quoted context omitted.

- Strict team separation (frontend versus backend) - Moving all state-managament out of the backend and onto the frontend, in a supposedly easier to manage system - Page refreshes are indeed jarring to users and more prone to leading to sudden context losses - Desktop applications did not behave like web apps: they are "SPA"s in their own sense, without jarring refreshes or code that gets "yanked" out of execution. S…

These days with 90% of SPAs being broken piles of browser standard breaking stuff, I find a page refresh or page load to be a soothing experience. They are like checkpoints in the process of using a website. Points to which I can go back using my browser's back button, and I can trust, that my browser keeps track of them. In contrast, when I see an SPA, I need to worry about the whole site going to shit, because I bl…

Not being able to new tab to a new instance of the app is terrible. Even super complex SPAs like Facebook let me for the most part right click new tab to create a new instance while preserving the old one.
Post reply on HN