DjangoCon 2026: The Web Is Getting Simpler, Smarter, and More Interesting

Fun Chicago fact: in the late 1850s, Chicago raised large stretches of its streets by roughly four to five feet so the city could install sewers with enough slope to drain properly. Buildings had to come up with them. Even large brick hotels, banks, and business buildings were lifted to the new grade.

That feels like a pretty good metaphor for DjangoCon US 2026.

I spent three days hearing people talk about applications that have been running for years, frameworks that have been evolving for decades, browsers that keep absorbing jobs we once handed to JavaScript libraries, and databases that are quietly becoming capable of things that used to require another system entirely. The recurring idea was simple: keep improving the foundations while the application keeps running.

I came away with pages of notes about Django itself, but the most interesting lessons were really about web development in 2026. Mature tools are getting better. The browser is getting surprisingly powerful. Postgres keeps eating more of the stack. AI coding agents are useful when the surrounding engineering system gives them good constraints. Human judgment still shows up everywhere.

Twenty years in, Django is still finding useful things to absorb

The biggest Django-specific news came from Karen Tracey during her keynote on Django 6. Karen walked through a release that adds several capabilities I would have expected teams to solve with separate packages a few years ago.

Django 6 now has a background tasks framework, built-in Content Security Policy support, template partials, and support for Python's modern email API. Django 6.1 is already pushing further with model field fetch modes and a new mailers configuration.

The background tasks work especially caught my attention. Django now gives applications a standard API for defining and enqueueing work outside the request cycle. The execution backend stays pluggable, so an application can match the machinery to the actual job.

That same theme came up in Matías Bordese's talk about teaching Django Tasks to speak Celery. Matías showed how the new task API can sit above different execution engines. Application code talks to Django's task interface while the backend decides how the work runs.

This is the kind of framework evolution I love. A common application need gets a shared vocabulary. Projects gain a stable interface. Teams still have room to choose the operational complexity they need.

Will Vincent made a similar point from the deployment side. Modern Django deployments still involve databases, static assets, HTTPS, background workers, monitoring, and a release process. Will's walkthrough made the whole thing feel much more finite than the giant cloud architecture diagrams we tend to imagine. The application still has a request, some code, some data, and a set of services around it. Most teams get farther by understanding those pieces well than by collecting infrastructure.

The frontend keeps getting interesting by getting closer to HTML

One of my favorite clusters of talks was about frontend development. Several speakers arrived at the same general place from different directions: there is a huge amount of power available before reaching for a large client-side application framework.

Natalia Bidart demonstrated this beautifully in her talk about HTMX and Django views. Natalia started with a normal server-rendered Django application, then layered in HTMX a little at a time. Django 6 template partials let the same view return either the full page or the fragment HTMX needs.

The result keeps one template as the source of truth. An inline rename can swap a display element for a form. A POST can update one piece of the page. The Django view and template stay at the center of the flow.

Kasey Kelly explored the same territory from the design-system side. Kasey showed how quickly frontend structure can become its own source of friction. One example started with AI-generated frontend code and ended up as a 16,000-line app.tsx file. His broader point was about building reusable patterns that fit the framework and remain understandable later.

Then James Stuckey Weber finished the conference with a reminder that the browser itself has been busy.

James ran through modern browser capabilities including popovers, anchor positioning, lazy image loading, container queries, view transitions, and newer text layout controls. He also pointed to Baseline as a much better way to reason about when features are consistently available across major browsers.

I had several moments during that talk where my reaction was simply, "The browser already does that?" CSS can now handle interactions and layout behavior that once triggered a hunt for a JavaScript library. HTML has gained richer primitives. The platform has been moving while many of our mental models stayed parked several years back.

There is a nice architectural consequence here. Every behavior the browser handles directly is one less custom behavior your application has to own.

Framework benchmarks are much less interesting than real workloads

Calvin Hendryx-Parker and Frank Wiles gave a Django versus FastAPI talk that spent surprisingly little time trying to crown a winner. That made it much more useful.

Their benchmark contract included pinned Python versions, multiple concurrency levels, latency, throughput, errors, and resource use. They also built realistic scenarios instead of leaning on a single requests-per-second number.

In one lightweight lookup scenario, FastAPI posted a lower p99 latency than Django. Their larger point was about scale and workload shape. A few milliseconds can become important at enormous request volumes. Most applications encounter bigger gains or losses in database access, data structure, query patterns, and surrounding architecture.

The line I wrote down was that async is a workload property. That is a much more useful way to think about it than treating async as a general synonym for faster.

They also talked about the leverage provided by Django's batteries and ecosystem. A mature package can bring years of accumulated design decisions into a project. That leverage comes with ownership because dependencies age and maintainers move on. AI may make fresh implementation cheaper, while maintenance still belongs to the team shipping the application.

Postgres keeps volunteering for more jobs

The database talks may have been my favorite technical rabbit hole of the week.

Tobias McNulty and Gerald Carlton showed fuzzy name matching across a dataset of 54 million records. Their starting problem sounded ordinary: let staff search for people whose names may have been entered differently over time.

Then reality arrived. People have multiple valid names. Names change. Clerks make typos. Character sets vary. Two people can hear or transcribe the same name differently.

Their solution combined several techniques instead of chasing one magical fuzzy-search algorithm. Prefix indexes handled cases that could be narrowed cheaply. Phonetic matching helped with names that sounded alike. Levenshtein distance handled controlled edit distance. Django's ORM could still expose database functions that Django does not wrap natively.

The coolest part was the scale. Search-as-you-type over tens of millions of records sounds like a problem that automatically demands a separate search platform. Tobias and Gerald showed how far PostgreSQL can go when the query strategy and indexes are designed around the actual search behavior.

Elizabeth Christensen then gave everyone a tour of PostgreSQL 18 and 19, and the list of capabilities was kind of ridiculous.

Postgres 18 brings UUIDv7 support, virtual generated columns, temporal constraints, async I/O improvements, OAuth 2.0 support, and more. Elizabeth also covered work landing around graph queries, richer conflict handling, query planning, and extensions that connect Postgres to object and columnar storage.

Postgres increasingly feels like a platform hiding inside a database server. Search, geospatial work, graph-shaped relationships, analytics, and application data can live much closer together than they once did.

AI coding gets better when the codebase gives the agent somewhere obvious to stand

AI showed up all over DjangoCon, but Josh Thomas gave the talk that stuck with me most.

Josh described debugging a production issue from a Disney World line. He handed an agent audit logs from a failed workflow. The agent proposed fixes and a test, and Josh was able to review enough of the result from his phone to get the incident moving.

The fun part of the story was the remote debugging. The useful part was everything that made it possible.

Josh had spent years building a reliable development loop around the application. The project had tests, CI, deployment conventions, and a codebase shaped by long-running domain knowledge. The agent could operate inside a system that already knew how changes should move toward production.

His strongest advice was to go with the grain of Django. Agents know common Django conventions well. Custom patterns require more context. Clear models, relationships, and constraints also give both humans and agents an obvious place to begin.

Josh also showed the danger of plausible local fixes. An agent can produce code that passes tests while introducing a new pattern that slowly spreads through the codebase. Cheap code generation can create expensive cognitive debt when every small fix invents a new way to solve the same problem.

Dawn Wages approached AI from a wider angle in the opening keynote. Dawn talked about agency, experimentation, community, and the responsibility to interrogate the systems we are being handed. Her message fit the technical talks better than I expected. Developers still choose the world their tools create. We still decide which abstractions become normal, which defaults get copied, and who gets room to participate.

Testing still works best when each test pays for its own complexity

Monica Oyugi gave one of the most immediately practical talks with a walkthrough of the testing pyramid in Django.

Her rough target was a large base of fast unit tests, a smaller layer of integration tests, and a thin layer of end-to-end browser tests. The exact percentages are less interesting than the decision behind them: use the cheapest level that can prove the behavior you care about.

One line from Monica went straight into my notes: keep the middle of the system real and use mocks at the edges. Integration tests should still exercise the real database and the real application behavior. External boundaries are where controlled fakes become useful.

Before adding a slow test, ask whether it needs the database. Before adding an end-to-end test, ask whether it needs the full request and browser flow. Those small choices compound into a test suite developers can actually afford to run.

Code review is still one of the most human parts of software development

The most memorable talk about code had surprisingly little code in it.

Sarah Boyce used emails from her grandfather about her paintings to explore how people receive feedback. She broke difficult feedback reactions into three triggers: truth, relationship, and identity.

That framing maps painfully well to code review. A comment can be technically wrong. A comment can land differently because of who wrote it. A tiny criticism can feel like a verdict on your ability as a developer.

Sarah also talked about the limited supply of reviewer attention in open source. A contribution can sit for weeks because volunteers have limited time. Silence often means capacity is gone for the moment.

Her phrase "human attention is the prize" stuck with me. Review is where code becomes shared knowledge. It is where someone else checks whether the change works, fits the project, and can still be understood after the original author has moved on.

That becomes even more important as AI lowers the cost of producing code. Generating another patch is cheap. Careful review, domain judgment, and long-term ownership remain scarce.

My big DjangoCon takeaway: the web platform has more leverage than I remembered

I went into DjangoCon expecting a lot of Django. I left thinking much more broadly about the web stack.

Django is absorbing common application patterns such as background tasks and template partials. PostgreSQL is handling search workloads and growing into new data shapes. Browsers are shipping layout, interaction, and transition features that remove whole categories of custom frontend code.

At the same time, the talks kept coming back to judgment. Choose a framework based on the workload. Shape data so the domain is obvious. Give AI agents conventions they can follow. Put expensive tests where they earn their keep. Spend human review time on the decisions that affect the future of the application.

That combination made DjangoCon feel unusually optimistic to me.

The coolest web development in 2026 is coming from understanding how much the tools already know how to do, then putting the pieces together with a little more intention.

Chicago once solved a massive infrastructure problem by raising the city while everyone kept going about their business. Django and the web seem to be pulling off their own quieter version of the same trick.