Slides are in Google Docs, with two options:

• Read-only mode: The Future of Django
• Commenting mode: The Future of Django

The goal

Why would we do this? Well to reduce our carbon footprint of course! The main carbon emissions related to conferences are from transportation, specifically flights from attendees who aren’t local. We can reduce this by encouraging people to use lower-footprint modes of transport, like trains.

Who this is for

A lot of people! For a conference in Prague, right in the middle of Europe everyone who’s in the green areas on this isochrone map centered on Prague can reach the city within a day by train:

Vienna, Warsaw, Budapest, Berlin, Bratislava are in there. Large swaths of Poland and Germany. Outside this map, avoiding flights is definitely still possible – with overnight trains! Check out the European Sleeper, which has services to Prague from Brussels and Amsterdam, or NightJet, or PolRail. This makes Prague easily reachable by train from Belgium, the Netherlands, the UK, France, Switzerland, Italy, Poland, and more!

It’s a much longer journey than flying, and occasionally more expensive too. But also much lower-carbon, more relaxing. And more adventurous!

How the carbon footprint compares

Here’s the results of my calculations, comparing the footprint of flights vs. train routes starting in European cities that allow travel to Prague within this extended “night train one-day trip”:

On average that’s about 76% lower carbon footprints! Numbers will vary a bit for actual journeys but the math here is pretty solid.

Note: train travel figures come from Eurostar sustainability figures, and those of European Sleeper, and Datawrapper for Berlin - Prague. Flight figures come from Google Flights, cross-referenced with Green Events Tool.

If you want the details, here’s the spreadsheet: Travel emissions to Prague - EuroPython 2025.

The journey

For travel within that 8h isochrone map, you’ll have no problem putting it together with Trainline or Omio or the local train companies! For night trains, check out the Man in Seat 61 on the European Sleeper.

Here’s a good graphic describing the European Sleeper routes, which is relevant for people in Belgium, the Netherlands, France, and the UK:

If we all did this

If you spend some time projecting those emissions reductions as if everyone attending from those places took the train instead of the plane, you arrive at:

• Emissions from UK attendees going from 57 to 10 tons of CO2
• Netherlands travel emissions going from 34 to 5 tons
• France (Paris) from 14 tons to 3 tons
• Belgium (Brussels) from 6 to 1 tons

All in all, if everyone within this isochrone “day trip” map made the trip via train, it would take the conference’s total travel footprint from about 450 tons of CO2, to 300 tons.

Do it!

The EuroPython 2025 schedule is looking epic already, give it a go with train travel!

Credits: By Halidtz - Own work, CC BY-SA 4.0

DjangoCon Africa 2025 represents an excellent opportunity to meet new faces and get new ideas in the Django world. It’s the second edition of the conference after a beautiful start in 2023, and I thought it might encourage more people to attend from overseas if I spent time documenting some of the steps. So here we are – how to get a visa!

When to apply

For me, the online process from “submit” to “visa granted” took 11 days, which matches what the official guidelines say. It’s also possible to apply for a visa on the spot once you land there. While that‘s not the recommended option, it’s well explained online. But the benefits of applying online ahead of time are to be more confident in the results, and skip the queue at the airport (those are lengthy forms to fill).

How to apply

See the official instructions from DjangoCon Africa organizers: Visa information.

Important points to note:

• You will need a plane ticket / travel booking. Either get a reservation without paying, get a refundable ticket, or chance it!
• The steps all work well, except for the last payment processing, which hasn’t been reliable.

The steps

There are a lot of steps but nothing particularly surprising for a visa application.

Homepage & navigation

This is where we start, visa.immigration.go.tz

Start a new application

Once you hit Start New Application, the system generates an Application ID so you can interrupt and resume your application at any point.

Record this ID somewhere safe, it’s also useful so you can check on progress after submission.

You’ll also receive an email from services@immigration.go.tz containing the application ID.

Enter personal information

First actual form step! On the Personal Information page, not many surprises there.

Contact, address & employment

Here the “employment” fields will changed a bit depending on your status.

Passport information

No surprises there either.

Travel information

Here’s where it gets detailed:

• Type of visa depends on your personal circumstances. In particular different countries are expected to use different types. See the official guidelines which are clear about that.
• Purpose of visit - I used “tourism” but there is also a “meetings and workshops” that seems somewhat appropriate for a conference.

The subsequent fields likely reflect my selection on those two.

Travel plans

At this stage you might not need travel bookings to fill this in, but this will be asked later.

Local host & accommodation

It’s not super clear to me how essential the “Local host” is, but for DjangoCon Africa we chose to recommend people use the conference organizers as their local host. See our DjangoCon Africa 2025 visa information page for more details.

Upload supporting documents

Finally, upload digital copies of:

• Passport-style photo (JPEG/PNG, ≤ 300 KB)
• Passport bio-data page (JPEG/PNG, ≤ 300 KB)
• Return ticket (PDF, ≤ 1 MB)

Note .jpg files aren’t supported, only .jpeg! (and -60.avif).

Declaration

Before payment, you’ll see a summary of all your inputs on the Declaration page.

Payment options

Once you’ve declared, you’ll arrive at the Payments page. There are three methods, only one of which worked for me:

1. ❌ Bank deposit: none of the payment details were visible on the page, so can’t do this.
2. ❌ Visa or Mastercard: the payment form never loaded, so I don’t think this works either (“500, An error occurred while processing your request.”)
3. ✅ GePG ePay: it was tricky but did work!

That last payment option is in the bottom left corner, hard to spot. Grab your Control Number, click the link and move on.

GePG gateway payment

This is what worked for me but it was very unreliable and took about 45 minutes of trying many times.

GePG timeout error

In those cases I would go back and retry.

GePG bill prompt

I arrived on that step twice! “Pay Now” didn’t work the first time, but did work the second time.

NMB bank card checkout

This worked fine the one and only time I got to it, except I never saw the next “success” page, only the proxy error below.

Final proxy error

Even after a successful payment, this is what I saw. However I could already go back to my application and see that the payment was confirmed.

Upon refreshing I got to this different (but also irrelevant) error page:

Application completed

Once payment is confirmed, the system shows an Application completed! page with your Application ID and submission date.

Checking visa status

To track your application later, go to Check Visa Status and enter the details you’d started your application with: Application ID, email address, security question and answer.

Status: pending approval

This is what you’ll see once you submit your application.

Status: on progress

After a few days it switched to this different status.

Approved

After 11 days, I received an email confirmation the visa was approved! With instructions on documents to print and bring to Tanzania 🎉

So, not the most straightforward, but definitely not too hard either! Get your visa sorted and join us in Tanzania for DjangoCon Africa 2025! 🇹🇿

This is a links-heavy version of what we discussed, for people who want to follow references.

The recording

Get it here:

It’s also available on YouTube if you’d prefer to watch Chris and I talk.

The topic

We had a few things lined up but the overarching theme was the importance of considering the carbon footprint of software in open source projects. As Wagtail Product Lead at Torchbox, and President of the Django Software Foundation, I’ve spent a fair bit of time thinking about the footprints of Wagtail and Django, and considering how we can take ownership of reducing said footprint. Which isn’t easy, as we have little control over how people use our software!

A good illustration of this is the total carbon footprint of Wagtail sites mapped across regions of the world:

Most of those sites, I’ve never heard of. That’s just how our relationship with users tends to be in open source software.

Extended show notes

Why and how to measure digital carbon footprints

We started by discussing the necessity of measuring digital carbon footprints and my history getting up to speed on this topic.

• I looked into dark mode’s energy savings in 2022 (and went further just a few months ago).
• At Torchbox, we spent a lot of time on this for our 2022 impact report, reviewing the emissions of 50-100 websites we built or worked on.
• Recognizing the scale and complexity involved, we expanded this effort to estimate emissions across the entire Wagtail ecosystem, encompassing thousands of websites.

For Wagtail, we’re talking on the order of 10-20,000 websites, each with a footprint on the order of 0.5 to 1.5 tons of CO2 per year. So 5000 to 15000 tons of greenhouse gas emissions per year. For Django, best case scenario is about 20x that.

Choosing methodologies

For websites, here’s our four go-to methodologies at Torchbox, and their suitability for different types of initiatives:

This is from our 2022 work on methodologies to quantify site emissions, still very relevant in 2025: Announcing our Digital Emissions Methodologies

Wagtail’s footprint

Wagtail’s 2023 Estimating Wagtail websites’ emissions was our first attempt at this. We’ve since further refined our approach but haven’t shared the updated 2023 / 2024 / early 2025 numbers yet, because the numbers are changing due to a lot of factors that are hard to reason about:

• The main model we use has switched from Sustainable Web Design v3 to v4, which reports generally lower emissions 🔽.
• It’s based on sites’ page weight, which has gone up, which is bad 🔼.
• It’s also based on the Ember electricity grid carbon intensity data, which has generally gone down, which means sites might still use the same amount of energy but pollute less (which is good!) 🔽.
• But the number of sites has gone way up, so the total emissions are still increasing 🔼.
• And our estimations of Wagtail sites’ page views have gone down, which means lower emissions 🔽.

So this is pretty confusing! But hey if you want to explore,

• The Wagtail sites emissions dashboard spreadsheets have all the unreleased data.
• Sustainable Web Design emissions calculator as a spreadsheet covers the formulas we’re trying to use for SWDM v4.
• ranking-to-pageviews is my side project to extrapolate page views from website Chrome UX report rankings, which is the main data source for Wagtail sites’ page views.

Current goal is to release this data with a representation as Digital Carbon Ratings, but even that adds another layer of indirection, so we’ll see. It looks like that currently, for 2024 figures:

That’s a neat representation of overall performance of Wagtail sites, but even understanding that requires a lot of context. For example, the way the ratings are designed, the number of sites falling in each category isn’t meant to be proportional! More on that in a future post.

Anyway, the tentative number of sites for 2025 goes up from 4889 to 6431 sites in the dataset. With a footprint still on the order of 5000 - 10000 tons of CO2 per year.

Using other models

All of the above is with Sustainable Web Design. We’re also experimenting with other ways to estimate or even measure a site’s emissions:

• With GreenFrame and Green Metrics Tool, on a traditional site setup: bakerydemo-gold-benchmark
• Comparing different site setups (headless vs. static vs. traditional), with just GreenFrame: benchmark-wagtail-demo
• With the Firefox profiler: How much power do web assets use?

Here’s a sample from that last article, showing the power consumption of different animation techniques in CSS and SVG according to this profiler:

Practical steps towards greener websites

On the podcast, we reflected on how Wagtail actively works on reducing websites’ footprint through initiatives like Google Summer of Code (GSoC). Over three years, our GSoC projects have tackled different sustainability improvements:

1. Leaner images, lower footprint, at scale showcases adoption of modern image formats and responsive image techniques to significantly reduce image weights.
2. The (still work in progress) low-carbon template is our attempt at reducing the footprint of newly-built sites. The designs are finalized and heavily optimized (see below), but the implementation still needs work.
3. And in 2025, grid-aware websites present the opportunity to deliver sizeable reductions on existing sites.

Low-carbon designs by our GSoC contributor Nandini Arora:

There are lots of other steps that projects can take. See for example my assessment of the Web Sustainability Guidelines. The latest Web Sustainability Guidelines are an excellent resource to explore all the possible ways to improve digital sustainability.

Taking responsibility as an open-source community

Unlike corporate structures with reporting and accounting standards defined by frameworks like the GHG Protocol, we don’t have such clear definitions of how to track direct and indirect emissions in open source. My go-to is GHG Protocol Scope 3 Category 11: Use of Sold Products (PDF), which is optional to report on in most accounting frameworks, but definitely important in my opinion. However it fits much better to appliances, than open source libraries to build sites and apps with.

I’ve learned a lot from Mozilla’s pioneering work on including Firefox usage emissions in their reporting (2020: Release: Mozilla’s Greenhouse Gas emissions baseline, latest: Mozilla’s Emissions Data). This chart specifically:

Quoting their work, emphasis mine:

Per the Greenhouse Gas Protocol, Mozilla is not required to calculate or report the product use emissions (scope 3, category 11) associated with using our products such as Firefox, Hubs and Pocket. However, Mozilla aims to lead by example and support transparency by reporting this optional data, and we began doing so in 2019. By taking this step, we hope to encourage our peers in the technology industry to do the same.

[…]

In 2022, the total emissions from using Mozilla’s products was 533,463 tons of carbon dioxide equivalent (tCO2e).

That’s 533,463 tons for use of Firefox and other projects, compared to 15,281 for all other aspects of Mozilla’s operations. 97% of the total emissions. Similar factors are at play with Wagtail, Django, and most likely lots of other open source projects.

Setting norms for the open source ecosystem

So we need to bring this type of thinking to more of the open source ecosystem, and the Python world in particular!

For Wagtail, I put together RFC 90: Sustainability roadmap, a roadmap for sustainability in Wagtail, supporting contributors and setting clear goals. This was with help from Lauri Apple, so the roadmap covers possible features / product enhancements but also clear ways to engage our community in those efforts. The changes we can do in this space are entirely dependent on adoption by users, so it’s crucial they understand what’s at stake and why to spend time on this. And formalizing our goals to reduce our footprint also helps us communicate how impactful we think any contributions in this space can be!

Bringing this to the wider Python world though, it takes time to find enough people working on this across projects to get together and move things along. I started on the Python forum in Who works on digital sustainability in the Python world?. Will keep things moving for Django and Python as much as possible.

Beyond measurements and reductions, a concrete step that projects can take is to create a sustainability statement, like Wagtail’s Sustainability page. This helps in communicating intensions, policies if any, and just results to date on how the project is working towards reducing its footprint.

Looking ahead

Finally, Chris and I touched on the importance of nurturing sustainability expertise within open-source communities and the broader technology industry. ClimateAction.tech is the best resource here in my experience, a community of technologists who consistently share their knowledge and experiences in digital sustainability.

And for Wagtail, the next step for us is to complete the grid-aware websites project put together by the Green Web Foundation! Hopefully we’ll be able to report back with quantified results in the next few months.

I already wrote a post for the DSF, DjangoCon Europe and beyond, and for Wagtail, DjangoCon Europe 2025 vibes and photos 📷️. But here are my personal notes!

The talks

To be completely honest, I was wearing many hats at the conference (DSF, DjangoCon Europe Code of Conduct, Wagtail), so I only managed to catch one talk from start to finish: Europe, Django and two-factor authentication by Agnès Haasser. I also attended Jesús Escribano’s workshop, Building an unique voting system in Django: is possible?. Both were great and I learned a lot :) I also caught almost all of Mia Bajić’s The Most Bizarre Software Bugs in History (will think of axle counts for the rest of my life), and Vince Salvino’s One Thousand and One Django Sites. And the lightning talks.

The tasks

I did watch other talks but was heavily multi-tasking. I spent most of my time at the conference talking to people, but also doing specific tasks:

• Preparing for a DSF Board Q&A with Tom Carrick and Sarah Abderemane.
• Preparing, running, debriefing the Annual meeting of DSF members.
• Social media for Django channels.
• Code of Conduct team for the conference. There were only two of us in person at the event, so we had to be paying close attention to comms. Transparency report coming soon!
• Distributing Django stickers.
• Social media for Wagtail channels.
• Preparing a mini Wagtail meetup!
• And a Django accessibility team meeting.
• Preparing for the sprints

The pictures

Quick picture from the annual meeting of DSF members (I don’t remember who took it, sorry!) – was a really good session:

The birthday

We’ve been preparing super secret birthday celebrations for Django’s 20th birthday. Kept things casual at DjangoCon Europe, but we did sing “Happy birthday” twice 👀.

The first time:

And that second time. Apparently people can tell waiters your name is Django and they just get it done:

The idea for the Inclusive Web devroom started at FOSDEM 2024, where we discussed the importance of showcasing accessibility and inclusivity work in open source, in web development and beyond. The Django accessibility team got to work on a FOSDEM 2025 proposal. Lo and behold, it got accepted, and here we are with a room full of people interested in those topics, and a great lineup of speakers!

The room was full for most of the day with about 70 attendees, with the conference also providing a livestream for remote participants. We had a great mix of talks, covering a lot of the aspects of the Inclusive Web that we wanted to showcase.

The talks

Top Accessibility Errors Found in Open Source Through Automated Testing

In the first talk of the day, Raashi Saxena shares insights on the most common accessibility errors in open-source projects, based on manual and automated testing. She highlights real-world case studies to help developers improve accessibility in their projects – and warn against the legal risks of poor accessibility!

Solving the world’s (localization) problems

Eemeli Aro and Ujjwal Sharma introduce MessageFormat 2, a new standard to address long-standing localization challenges. They discuss its potential applications and the tools being built around it. This standard is very promising for Django developers working on multilingual applications to provide better translations for users, and better capabilities for translators.

Alternative Text for Images: How Bad Are Our Alt-Text Anyway?

Mike Gifford explores the importance of alt text in web accessibility and how often it misses the mark. He demonstrates his alt text scan Python script for auditing alt-text across websites. Alt text is a common issue on Django projects, and the AI generation showcased by Mike has the potential to move the needle.

Secure and Inclusive: WebAuthn for (Multi-Factor) Authentication

Storm Heg explains how WebAuthn (Passkeys) offers a secure and user-friendly alternative to traditional authentication methods. This talk covers how it works, its accessibility benefits, and how Django developers can integrate it into their projects. Storm showcases his django-otp-webauthn package and other alternatives.

How do we work out the environmental savings from accessibility?

Chris Adams discusses how supporting older devices through accessible digital services can reduce e-waste. He explores research on hardware obsolescence, data-driven methods for measuring environmental impact, and policy changes in digital sustainability. This builds upon previous work by Chris showcasing the parallels between web accessibility and sustainability.

Growing inclusive communities: Djangonaut Space program

Raffaella Suardini shares the success of the Djangonaut Space mentorship program in fostering sustainable contributions and welcoming new contributors. She provides strategies for building inclusive tech communities, which are crucial to the success of open-source projects like Django 💜.

Multilingual Speech Technologies That Understand You

Jessica Rose discusses how Common Voice’s crowdsourced speech dataset helps developers build speech technologies for underrepresented languages. She highlights the challenges of linguistic diversity in tech – which are very relevant for a project with such an international and multiligual user base as Django.

ATAG accessibility audits: worth your while

Thibaud Colas introduces the Authoring Tool Accessibility Guidelines (ATAG) and explains why they are essential for content creation tools, like the Django admin. He shares highlights of where projects can learn a lot from ATAG, making this talk valuable for Django developers working with content publishing.

All recordings

You can watch them all on the FOSDEM website:

See you in 2026

We had a blast running this devroom, and we’re looking forward to doing it again in 2026 if we get the chance! Thank you to our speakers, devroom organizers (Saptak, Tom, Sarah, Thibaud, Eli), and helpers (Alex and Storm) for making this event a success! 🎉

We have a bit of a DjangoCon Europe tradition going on with Tom Carrick to always go for a swim during the conference, no matter the location, time of year,… weather 😬 I swear it’s fun and you should try it out!

This year, there’s great spots on the Irish Sea just 10 min away from the conference venue. This one’s called Forty Foot (pic by Vladimir Zakharov).

Today I learned docs.python.org Plausible analytics are publicly available, which is pretty cool! Right away my eye was drawn to the stats on visitors from around the world:

Notice how in this, the US of A is shown _so much_ brighter than anywhere else in the world? The 30-day visitors count is at 999k.

It’s interesting how much that country-level binning is misleading, and accordingly, how big Python actually is in Europe (and other regions) if you look at more granular numbers. It only takes 8 of the top European countries to get above the 1M visitors mark:

1. 🇩🇪 Germany, 245k
2. 🇬🇧 United Kingdom, 227k
3. 🇫🇷 France, 177k
4. 🇪🇸 Spain, 93k
5. 🇵🇱 Poland, 80.2k
6. 🇮🇹 Italy, 78.6k
7. 🇳🇱 Netherlands, 74.4k
8. 🇺🇦 Ukraine, 66.5k

That’s without counting Russia, some of which is very much in Europe, but I’m not sure how much. The top 7 countries are in the European Union 🇪🇺, and we arrive at 974k visitor. The addition of Ukraine takes us over the 1M mark.

What it means

For me personally, it’s interesting because 10 years ago I was delighted to land a Python gig compared to the PHP and Java jobs that were the norm in my local sphere. Now it feels like Python (or at least Django) gigs are all over the place in Europe. Just look at the latest 10 offers on Django News Jobs, majority are there.

For projects like Python / Wagtail / Django, I hope it also means a renewed focus on multilingual capabilities, and localization. It’s almost comical how bad gettext is, there’s a big need for a better baseline (MessageFormat 2, Fluent, I’m not sure). And then building beyond that baseline, more focus on support for other languages than English – translated docs, multilingual online content, etc.

In the short term – I guess that means we’ll see you all Europeans at DjangoCon Europe 2025 in April and EuroPython 2025 in July? And for Wagtailers… Wagtail Space 2025 plans TBA soon 🤫 Cue Eurodance music!

The goal

Why would we do this? Well to reduce our carbon footprint of course! The main carbon emissions related to conferences are from transportation, specifically flights from attendees who aren’t local. We can reduce this by encouraging people to use lower-footprint modes of transport, like trains.

Who this is for

For a conference in Dublin, everyone who’s in the green areas on this isochrone map centered on London can reach Dublin within a day by train and ferry:

This includes all of England, Wales, Belgium, Luxembourg, the Netherlands. And lots of major cities in France, Germany, Switzerland. Outside this map, avoiding flights is definitely still possible – but would require overnight trains or multi-day trips.

It’s a much longer journey than flying, and likely to be more expensive too. But also much lower-carbon, more relaxing. And more adventurous!

How the carbon footprint compares

Here’s the results of my calculations, comparing the footprint of flights vs. train + ferry routes starting in European cities that allow travel to Dublin within this “one-day trip”:

On average that’s about 80% lower carbon footprints! Numbers will vary a bit for actual journeys but the math here is pretty solid.

Note: Ferry figures come from. Stena Line ferry carbon footprint calculator. Train travel from the UK government train travel emissions figures, and Eurostar sustainability figures. Flight figures come from Google Flights, cross-referenced with Green Events Tool.

If you want the details, here’s the spreadsheet: Travel emissions to Dublin - DjangoCon Europe 2025.

The journey

If you’re interested, The Man in Seat 61 is the best resource to prepare trips like this. But here’s the rough route plan:

.

The TL;DR; is you should get yourself a SailRail tickets by Transport for Wales, which is about 120 euros for a return trip, and includes train travel in the UK and the ferry crossing. Then get a Eurostar ticket to reach London. Trains depart from London in the early morning and early afternoon. Roughly-speaking, if you can make it to Brussels or Paris by 1pm, you’ll be in Dublin by the end of the day.

If we all did this

If you spend some time projecting those emissions reductions as if everyone attending from those places took the train and ferry, you arrive at:

• Emissions from UK attendees going from 7 to 1.6 tons of CO2
• Netherlands travel emissions going from 8.5 to 1.5 tons
• Germany (Frankfurt) from 8.5 to 1.2 tons
• France (Paris) from 3 tons to 0.5 tons
• Belgium (Brussels) from 1.5 to 0.25 tons

All in all, if everyone within this isochrone “day trip” map made the trip via the ferry and train, it would take the conference’s total travel footprint from well above 100 tons of CO2, to well under it.

Do it!

I got my tickets today! If you can make it with the ferry and train, great. If not, whether due to travel times or cost, definitely come anyway! See you at DjangoCon Europe 2025.

.

With time zones in the way, it was an event I could only share the very beginning and end of, having to sleep in the middle! But I really enjoyed the bits I managed to attend.

Talks

The program had lots of different things. I personally really like to see mixed-language events like this. I only know a few words of Japanese, but I could understand a few words (mizu, neko, etc 🥲). But more importantly, the event had live subtitles and captioning! So both Japanese-language and English-language talks had English and Japanese captions.

My favorite talk was about project architectures / structures with DRF. Unfortunately the speaker’s name was provided in kanji only, and I just don’t have enough skills in Japanese to romaji it! But thank you 野呂有我!

Birthday

DjangoCongress were the first event in 2025 to acknowledge Django’s 20th birthday. Django has roots in 2003, but 2005 was when the project got started as an open source endeavor named Django. In particular, July 2005 is when the code was open sourced and the website set up. November 2005 was the first official release (0.90).

It was lovely to see DjangoCongress JP organizers showcase this history during the event! In my mind the whole of 2025 is Django’s birthday, so we’ll see other events celebrating this later in the year too.

Thank you

🫶 I had a great time! Thank you DjangoCongress JP organizers for putting so much thought into making the event accessible for non-Japanese speakers, I’d never seen this done so well before and it was truly impressive.

Packages already declaring support

There’s 23 released on PyPI, which were tested with the Django 5.2 alpha 1 release. That’s out of about 1394 packages that declare which versions their support (out of 17k packages in total).

• django-csp v4.0b3
• django-bird v0.14.2
• django-filter v25.1
• django-tailwind-cli v4.1.0
• django-appconf v1.1.0
• django-rich v1.14.0
• django-mysql v4.16.0
• django-perf-rec v4.28.0
• django-version-checks v1.14.0
• django-read-only v1.19.0
• django-permissions-policy v4.25.0
• django-linear-migrations v2.17.0
• django-watchfiles v1.1.0
• django-minify-html v1.12.0
• django-cors-headers v4.7.0
• django-htmx v1.22.0
• django-harlequin v1.5.0
• django-browser-reload v1.18.0
• django-auto-prefetch v1.12.0
• django-ditto v3.5.0
• django-syzygy v1.2.0
• django-extra-checks v0.17.0a1
• django-admin-groups v0.3

For a community-driven project like Django, community-driven testing efforts are essential. It’s excellent to see this work happening ahead of the final release. Benefits are clear:

• Potentially catching bugs in the new release ahead of it being generally available.
• Making it easier for users to upgrade to Django 5.2 when they start adopting the new version in April.

Django versions support overview

There’s more package releases with tentative Django 5.2 support everyday. As of today, here’s the numbers through the whole package ecosystem:

This is only packages that already explicitly declare support for specific versions. There are tons of packages that don’t use classifiers for this but would support those versions in any case. With Django having such a strong commitment to API stability, there are a ton of scenarios where new releases “just work”. So this won’t account for:

• Packages that don’t use trove classifiers to declare compatibility.
• Packages that do, but haven’t published a new release (maybe Django 5.2 works with no code changes).

I love how fellow Djangonaut Baptiste Mispelon put it when trying out Django 5.2 alpha 1 on djangoproject.com:

We just updated the dependency file and everything worked.

– Baptiste Mispelon

And for those interested in numbers crunching – this data is from the PyPI dataset on BigQuery. Here’s the query: package-ecosystem-latest.sql.

How you can help

Try out the pre-releases on your projects or packages! And if you find any issues, investigate and consider reporting them back. Even better if you:

• Configure your packages’ continuous integration to run with Django 5.2 pre-releases already
• Spend time to adopt specific features listed in the Django 5.2 release notes, to further stress test any additions.

And if you maintain packages – consider running your tests against Django’s main? My colleague Sage recently talked about how it helps catching issues and contributing to Django with pretty concrete bug reports:

Here’s an overview of all countries using Django in their government websites. That’s 89 countries according to my dataset.

Top users

Here are the top 10 highest numbers of Django sites by country.

There’s a lot of room for this to be affected by how countries choose to assign domain names to their websites, rather than accurately reflecting Django usage. But it’s interesting nonetheless!

Showcase

I thought I’d share some of the sites I find particularly noteworthy, from that top 10 and otherwise. With the caveat that there are lots of governments and sites I know little about, so there’s some bias towards things that are closer to home for me.

Ireland

I know very little about ireland.ie – but I know that DjangoCon Europe 2025 will be in Dublin, Ireland! ☘️ So it’s very topical. See you there?

As far as government websites in Ireland, there are other heavy-hitters on the list like gov.ie. The website’s design is very simple, behind the scenes I’m sure there is a lot of backoffice work going on.

Sweden

Visit Sweden I know a tiny bit more about, only because the Fröjd agency who did the work published the site on Made with Wagtail. I believe they also published some of the site’s building blocks on GitHub, like django-react-templatetags (just what it sounds like) and Wagtail-Pipit (a Next.js + Wagtail starter kit). Thank you Fröjd for sharing your work!

France

Sites faciles from the French government is pretty meta – it’s a starter kit for other government websites built with Django and Wagtail! And it’s fully open source, at numerique-gouv/sites-faciles on GitHub.

I’m also very interested in what the French government is doing in Django because they have one of the most advanced set of guidelines on digital emissions / the carbon footprint of government websites, the Arcep Digital Sustainability info page is great, and links to an english version of those guidelines (“General policy framework for the ecodesign of digital services (RGESN)”).

United States

A picture of the Pillars of Creation by the James Webb Space Telescope on the front page of a Django site… isn’t that the coolest thing ever? The JPL website at NASA is built with Django, and they also open source some of its components: the Explorer 1 Design System, and tools to manage an ecosystem of websites. Their friends at Caltech also have a lot of open source Django projects, and elsewhere at NASA the NASA NAS data portal and the STEM Gateway are also built with Django!

I find this one particularly cool because beyond the open sourcing, they were also able to talk about their experience and tools at conferences – which is rare in the public sector! Check out their DjangoCon US 2022 talk, A Management Layer for Scalable, Multitenant Django with Addison Hardy and James Ray.

Also in the US – the Consumer Financial Protection Bureau website is worth a look too!

This one I find extra special because the whole site is open source, available on GitHub at cfpb/consumerfinance.gov. This is one of the best examples I know of using Jinja at scale – and I wish we saw more of that in the Django world!

Argentina

Some of Argentina’s government portal is built with Django – specifically their miArgentina authentication service! And, you guessed it, some of it is open source too.

Czechia

MojeID from Czechia is another Django authentication service. Maybe we’ll meet their team at EuroPython 2025 in Prague?.

New Zealand

In New Zealand, RealMe is another online identity service that uses Django :)

Mexico

MéxicoX is an online course platform from the government of Mexico, built with Django. Pretty cool to see this type of web app in the public sector!

Ukraine

Back in Europe, the Ukraine government services guide is also built with Django. They also have open source code on GitHub, sadly not this specific website.

Tunisia

Tunisia’s national open data platform is built with Django! Interestingly, so are the open data platforms of Bahrain and of Lithuania. Also in the Python world, the CKAN platform is very popular – and it’s built on top of the Flask framework.

Chad

Also in Africa, Chad’s Covid-19 online information and pass platform uses Django, a great example of how the framework contributes to public health.

Sudan

Sudan’s passport and immigration online booking system! Sudan isn’t too far from DjangoCon Africa 2025 in Tanzania, there will definitely be travelers from Sudan using this platform as part of their travel logistics to attend.

Türkiye

In Türkiye / Turkey, the Ministry of Education website is built with Django!

Uzbekistan

The Uzbekistan parliament website is also built with Django!

Canada

Another pretty cool open data portal, this time from Canada: Open Government Portal. And part of it is open source – Open Canada Solr Search (OCS), a Django + Solr search application.

Thanks Gavin Anderegg for the suggestion!

Romania

The Romanian National Institute for Research & Development in Informatics is built with Django (and Wagtail).

India

Last but not least, in India, we have the National Test House website from the Department of Consumer Affairs. And the Delhi Tourism board website is also Django. Django is big in India – DjangoCon India, anyone?

Methodology and data

That’s a lot of sites, but really just the tip of the iceberg. My Django in government dataset is just shy of 1000 websites, and that’s only based on the most predictable domain name patterns:

select origin, rank, dj_version, last_modified
from w_dj
where regexp_matches(
  origin,
  '\.((gov|government|gob|gouv|gv)\.?[a-z]{0,2}$|gc\.ca|gouv\.fr|govt\.nz|go\.kr|overheid\.nl|admin\.ch|europa\.eu|bund\.de|(gop|gos|gkp|gob|gog|gok)\.pk|canada\.ca|bund\.de)'
);

The original dataset I collected by crawling about 20M websites from the Chrome UX Report dataset, running common checks to detect Django: Static files URL patterns, sessionid cookie, csrfmiddlewaretoken, etc. See Detecting Wagtail in the wild and my Detect Wagtail project for more information about how this type of detection works.

Cross-referencing those 50k websites with other sources, we’re likely to be an order of magnitude below the actual number of Django projects out there, accounting for public sites that aren’t detectable, internal sites, and mobile apps or other projects that aren’t publicly visible in any way.

Missing countries

There are lots of gaps on the map I’m surprised about! In particular Germany, Iceland, China, Japan. If you’re aware of government websites in those countries that are built with Django, please let me know!

Note: This is the blog post version of my FOSDEM 2025 talk. If you want the original, view the slides: ATAG audits: worth your while 🔎 @ FOSDEM 2025 and view the video recording of the talk.

You can also watch it on YouTube if you prefer:

Why we’re here

We’re here because Standards, Authoring tools, Accessibility by default, and the Authoring Tool Accessibility Guidelines in particular can help us create better, more accessible web experiences.

95.9% of home pages have accessibility issues

Percentage of home pages with detected WCAG conformance failures over time. 2024 WebAIM Million

According to the WebAIM Million Project, a staggering 95.9% of home pages on the web have accessibility issues. And that’s just what automated tools can find — it’s definitely worse when manual testing comes into play.

We need accessibility standards

We have a bunch already, and we definitely need them:

• WCAG: Web Content Accessibility Guidelines
• ATAG: Authoring Tool Accessibility Guidelines
  • ☝️ Our focus here
• UAAG: User Agent Accessibility Guidelines
• WAI-ARIA: Web Accessibility Initiative – Accessible Rich Internet Applications
• EN 301 549: Accessibility requirements for ICT products and services

Most people have heard of WCAG — the Web Content Accessibility Guidelines. ATAG, or the Authoring Tool Accessibility Guidelines, focuses on ensuring that the tools people use to create content, are accessible and produce accessible content.

We need authoring tools

The majority of web content isn’t crafted by hand as HTML. We need support for social media posts. Blogging. Apps. Videos. Slides. Livestreams. Chat. Crafting HTML by hand is possible but error-prone. These tools should provide accessible defaults so that content creators aren’t forced to “reinvent the wheel” when it comes to building accessible content.

Authors need:

• Assistance
• Documentation
• Templates
• Quality control
• Accessible defaults

Authoring Tool Accessibility Guidelines (ATAG) 2.0

Version 2.0 in 2015. Today we’re looking at it at a high level. The most important is understanding the distinction between the two halves of ATAG:

• A. Make the authoring tool user interface accessible
• B. Support the production of accessible content

This post showcases a few highlights in Part A, and then way more in part B, which is where in my opinion there’s the most opportunity to find novel ideas that can make a big difference.

ATAG example: in a Content Management System (CMS)

Here – we’re looking at the Wagtail v6.3 page editor, with page preview opened. This screenshot is a good representation of ATAG. The editing form and sidebar to the left: that’s where Part A helps. What happens in the preview box to the right, showing the live web page: that’s where Part B “accessible content” manifests itself. But the whole CMS interface will evolve based on the requirements of both parts.

ATAG in practice: Part A

My highlights – things that go far beyond WCAG 🚀

Part A: Make the authoring tool user interface accessible

• A.2.1. Make alternative content available to authors
  • What that means: in an authoring tool context, we need alt text for all images, decorative or no!
• A.3.2.1 Auto-Save
  • Either no session time limit, or auto-saving. Auto-saving is (kind of) a requirement to meet ATAG!
• A.3.5. Provide text search of the content
  • Browser built-in search and hidden="until-found" to the rescue?
• A.4.2. Document the user interface, including all accessibility features
  • 💅🎉👏 pretty fundamental, and cool to see this in such an established standard.

Documenting features: for developers and for users

Screenshot of the Wagtail user guide homepage

An often-overlooked part of tool development is documentation. Clear, accessible documentation helps both developers (who need to maintain and extend the tool) and end users (who rely on it to create accessible content). Documenting features isn’t just an afterthought—it’s a critical piece of making an accessible tool.

In Wagtail – it’s a journey. I would say our “docs coverage” is at:

• 80% for devs
• 35% for editors (52 of 145 features)

ATAG in practice: Part B

To infinity… and beyond WCAG! 🌈 Part B is where I see the most potential for us to move the needle. We’ll look at specific guidelines, and concrete examples of where they apply.

B.1. Fully automatic processes produce accessible content

One major goal is to have systems that automatically produce accessible HTML behind the scenes. For instance, when using a tool like Google Forms, there’s an opportunity to streamline things such as autocomplete for fields like “email” or “name.” When these automated processes work properly, they take a big load off the author. Here’s a Google Forms example:

It’s very convenient to set form field labels and help text, even some validation rules. But there’s no way to set the autocomplete attribute, which helps make forms easier to use (and meet specific WCAG criteria like 3.3.7 Redundant Entry).

B.2.3. Assist authors with managing alternative content for non-text content

As in – help people creating alt text (and captions). Images and other non-text content need alternative descriptions (alt text). Consider a social media post editor like Mastodon: when you add an image, the tool warns you if you’ve not added alt text and even offers a “detect text from picture” feature. This is a perfect example of guiding authors toward better accessibility.

This is the Mastodon alt text UI. I particularly like it because in addition to providing clear indications of whether an image is missing alt text, they also have a “Detect text in image” feature which will automatically populate the alt text field based on the visuals.

B.2.4. Assist authors with accessible templates

Supplying accessible templates, kind of feels obvious no? But in practice it’s not always so easy. And by “templates” – here we should interpret this as any building blocks for web pages, so whether the templates are just “content formats”, or web components, or page sections to combine. Or even whole site templates - say site starter kits.

One example I love comes from WordPress: they have an accessibility review process for site themes. In their marketplace, themes are tagged as “Accessibility Ready” themes, making it easier for authors to pick a design that already meets accessibility criteria.

B.3.1. Assist authors in checking for accessibility problems

Here, there’s lots of room to make a dent in the number of issues found with automated tools. Tools like Sa11y can be embedded in web pages to automatically scan for accessibility errors. Imagine a browser widget that notifies you when your page has issues—this is exactly the type of integrated feedback that ATAG recommends.

This should be built into every Content Management System if you ask me. Note Sa11y itself is GPL-licensed so won’t be the best option for projects using more permissive licenses, but certainly a good example of the concept. In Wagtail, we chose Axe to build our built-in accessibility checker.

B.3.2. Assist authors in repairing accessibility problems

It’s great to flag problems — but even better if the tool can help authors fix them. For example, when it comes to alt text, an authoring tool could automatically generate several AI-based suggestions. The user can then choose one or edit it as needed, streamlining the repair process and ensuring higher-quality output. When we say “AI” here – it doesn’t necessarily have to be Large Language Models. There’s been great results with OCR (when images contain text), and computer vision models based on deep learning neural networks.

For Wagtail, our accessibility team compared the alt text of real-world Wagtail images, with results generated by GPT-4 Vision. For 89% of images, the AI alt text was better than average; compared to 43% for the existing alt text. Very promising. Here’s what our manual scoring looks like summarized as a bar chart:

We did this review for Global Accessibility Awareness Day 2024 if you want to read more.

B.3.2. example implementation

For Wagtail, we took on implementing this pattern as a Google Summer of Code 2024 internship. It’s still work in progress, but here is our desired “end state” alt text interface, based on ATAG and those AI capabilities:

This is defined contextually, prompting authors to add alt text where they use the image, rather than only on upload. It offers multiple options, which could either be generated by AI, or come from other contexts in which the image is used. Ultimately the author still has agency to decide if they’d rather type their own alt text, or reuse any of those suggestions. See We 4 Authors Cluster - alt text for more on the topic of contextual alt text interfaces.

Get started

Alright, ATAG is great, but how do we get started with it! I blogged about my recommended ATAG 2.0 getting started resources back in 2021. Lots of useful links on there. Here are the top 3-5 “official” ones I would recommend in 2025.

Prerequisites

You can get there iteratively, but here’s the baseline I’d recommend before getting going with an audit specifically:

1. Good documentation of project features
2. Good demo setup to test said features
3. (Some) knowledge of ATAG
4. Report format

And that’s it! 🎊 👀 Well – for some projects the above is already a tall order. But good docs and demos help ATAG or no, and for knowledge and report formats, there’s help!

Report templates

To help streamline that last bit about report formats, I spent a good deal of time building a template in Markdown: atag_wagtail_template.md. This is my preferred format if you wanted to audit collaboratively with others. If you do multiple audits over time, it also helps to be able to diff them to see what’s changed from one to the other. For example here’s Wagtail’s version 6.3 vs. 5.2 diff.

And if you’d rather manage audit findings directly in GitHub – there’s a template for that too 🌈 All set up with custom fields to track issues according to both WCAG and ATAG: GitHub Projects template. Here’s a peek at what it looks like when put to use:

ATAG Report Tool

The W3C Web Accessibility Initiative (WAI) also offers a report tool — a form wizard that guides you through each guideline, making it easier to perform an audit. Here’s an example of what a completed audit looks like in there:

Authoring Tools List

And once you have spent the time creating an audit – consider submitting it to the W3C WAI authoring tools list. Sharing your results not only helps improve your own tool but also aids the broader community.

Beyond WCAG and ATAG

If you’ve already read the whole of ATAG and want to consider more standards to take you further, those are the two I would recommend:

• Web Sustainability Guidelines (WSG)
• Accessibility Maturity Model

Thank you!

Again, accessible authoring tools are critical to the bigger picture of accessibility. Any questions about this material – please say hi!

• Mastodon: @thibaudcolas@fosstodon.org
• Bluesky: @thibaudcolas.bsky.social
• X: @thibaud_colas
• LinkedIn: Thibaud Colas
• GitHub: @thibaud_colas

Bonus: progress for Wagtail

I didn’t end up covering this on stage but this is where we got after a year of learning from ATAG!

Conformance levels and classification per the ATAG report tool.

Slides are in Google Docs, with two options:

• Read-only mode: Shifting DX expectations: keeping Django relevant 🫣
• Commenting mode: Shifting DX expectations: keeping Django relevant 🫣

I’m really happy with this! And particularly that the pace at which we gain new members is increasing. Those 400 members all contributed to Django’s future. For a community-driven project like ours, individual contributors are essential.

Nominate more people

We really do need more people. 400 members is a lot, but at the scale of Django that’s probably around 0.01% of the framework’s users. Nominate more people, and ask your friends and colleagues to do the same! Of the 152 people who joined the Foundation since October 2023, I nominated 50. It only takes a few minutes.

1. Read our membership FAQ to know what qualifies for membership.
2. Fill out the linked form.

If in doubt – please reach out! The TL;DR; of eligibility is we’re looking for people who make substantial or sustained contributions towards the goals of the Django Software Foundation:

• Support development of Django by sponsoring sprints, meetups, gatherings and community events.
• Promote the use of Django among the World Wide Web development community.
• Protect the intellectual property and the framework’s long-term viability.
• Advance the state of the art in Web development.

Note how that last goal doesn’t even require contributing to Django itself.

Oh and for people who might want a deeper dive, here’s the underlying data for the above chart.

Late last year, we ran a survey of people who build headless sites with Wagtail, or are considering developing a headless site with Wagtail. It’s a follow-up to our 2022 Wagtail headless survey. We’ll use those survey results to inform Wagtail’s direction as part of RFC 100: Headless support improvements.

46 people responded (thank you!), compared to 29 in 2022 – here are the key results.

How often developers work on headless Wagtail

There is a big jump between 2024 and 2022 results, with people reporting that “Most work is on headless” going from 24% to 46%. We expect this is a combination of headless architectures gaining popularity, and the survey being targeted more towards people who choose this type of stack.

Using Wagtail in headless mode is particularly popular for larger projects, where the CMS might only be one of many services providing content or data for the site or app’s pages.

Deployment of headless websites

There is a clear pattern here, with “Same as CMS” leading at 66%, followed by Other at 25%, Vercel at 18%, and Netlify at 7%. The overall breadth of platforms is likely as big as shown in our deployment survey.

Familiar front-end tools for Wagtail developers

React and Next.js are still the most commonly known tools. There is a small dip in Vue and Nuxt usage, though this could be down to the survey’s small sample size. Astro usage is taking off! Introduced in 2023, there are currently on the order of 30,000 websites built with the framework according to Wappalyzer.

Frameworks for future projects

Similar trends are reflected in what developers say they would consider using for future projects, here with Astro on par with more established options like Nuxt or Remix. For Wagtail, knowing what developers are interested in will help us decide what technologies to use in tutorials or demo sites.

Front-end rendering

While a lot of modern front-end frameworks make the line between static and dynamic rendering blurrier, it’s interesting to see the distribution in practice! We will want to consider how Wagtail could support each and every one of those use cases.

Integration method with the backend

REST is as popular as ever, whether with Wagtail’s built-in Django REST Framework support, or a custom integration to leverage OpenAPI schemas, or Django Ninja. The question wording of “When building headless sites, which method of integration would you consider?” makes it clear multiple answers are ok, so it’s interesting to see so many people considering both REST and GraphQL.

And for the one person using Elasticsearch for this – you’re not alone! Though they might not be in our survey respondents, there are a reasonable number of websites sharing Wagtail and Django solely via a search backend.

The future: priority areas to improve headless support in Wagtail

This list is a good overview of all the options for us to improve headless support – and the voting really helps making it clear what gaps Wagtail developers think are worth addressing. In addition to this quantitative data, we also got some great feedback in individual comments:

• Reduce the need for custom serializers
• Support generation of OpenAPI specifications for documentation, and to generate TypeScript type definitions
• Consider how to support Django Ninja
• The documentation needs more examples – say StreamField blocks in GraphQL.
• HTMX support – where does this get factored in.
• An official JS client API like wagtail-js?

Review our RFC: Headless support improvements

As part of RFC 100: Headless support improvements, we hope to create a solid overview of all possible improvements, and make it clear which ones are ready for people to contribute to. And in the meantime, if you’re considering headless Wagtail – take a look at our headless developer docs, and our overview of headless Wagtail!

This badge reflects our ongoing commitment to fostering a diverse, equitable, and inclusive community for all Djangonauts. It’s part of the CHAOSS DEI Project Badging initiative.

Our new Diversity, Equity, and Inclusion Project Statement details all the ways in which we want to create an environment where everyone can participate and thrive, and complements our pre-existing Django Community Diversity Statement. From inclusive leadership structures to Django events, we strive to ensure our community is welcoming, transparent, and supportive.

Thank you to everyone in the Django community who contributes to making our project inclusive, accessible, and welcoming 🫶. Thank you to Sarah Boyce, who led the work for us to be awarded this badge as part of . We view this milestone as part of a continuous journey for our project and community to improve, and look forward to building an even more vibrant and supportive community together.

I know, right! You might be wondering what that means, I do too. Truth is a lot of the roles and responsibilities at the Foundation have a nebulous definition. But we’ll figure it out.

What it means for me

More than anything, it’s an honor to be in such a role, and a mandate for me to do more of what I’ve already been doing at the Foundation. Plain and simple, I want to keep Django and its community on an upward trajectory. Make it more of the Django Community Foundation than Django Software Foundation. Help our people navigate today’s societal challenges and be a driving force in our industry.

My statement for the officer elections

While members of the Board of Directors are elected by the DSF membership, the officers are elected by the Board. I’ve been pretty critical of Django and its governance in the past, like in my personal statement for the 2024 Board elections. I kept that theme going in my statement for the officer elections. Here is how I put it:

Operationally, the Django community as a whole isn’t functioning as well as it could be. We have motivated individuals, excellent ideas, but lacklustre coordination. In the Foundation in particular, our brilliant volunteers need a better baseline of organization to do their best work. And we need this too when partnering with others, or when hiring.

In my second year on the board, I’d like to help improve this by taking on more responsibilities as President of the DSF. This will be behind-the-scenes work to map out organization maturity gaps (docs, infosec, fundraising, etc), and coordinate with new and existing contributors to resolve them. And external-facing work too: creating more sustainable relationships with our partners, and accountability and transparency towards our community.

I believe Django and the Foundation need that kind of (constructive) criticism to grow. And transparency from its leaders. We have a good community-driven project, and a thousand ways in which it could be better. I’m elated and honored to be part of that.

My plans

I’ll strive to find the right balance between working on the issues I care about (accessibility, Django’s carbon footprint, diversity, social equity) – and working on the fundamentals of organizational maturity and governance. And the business as usual of a non-profit like ours. I’m sure I will drop the ball on some of those, and hope to be able to count on my Foundation colleagues to call that out and help me make it work. We have an outstanding team so I know it will.

I don’t see myself sustaining this kind of sustained levels of volunteer involvement with the non-profit open source world beyond 2025, so we’ll also need to work on creating more opportunities for high-impact contributions so others step in. I’m sure we’ll get there. Onwards! 🌈

Results

Straight to it – those numbers are the median of three runs:

Measured with Webpack, for Wagtail, in the context of Sass deprecation warnings fixes. This is on a 2019 MacBook Pro. macOS Sonoma 14.4, 2.4 GHz Quad-Core Intel Core i5, 16 GB DDR3.

How much code

The above is for 130 .scss files, with 8756 lines of code. Here’s the full cloc output for Wagtail.

Why there are multiple Sass implementations

Historically Sass was written in Ruby and C/C++ I believe. The C/C++ implementation, LibSass, was the most popular for Node tooling users via node-sass. Since then, new implementers took over and rewrote Sass focusing on a Dart implementation: Dart Sass. This is the official implementation now, and it ships as two packages – sass which is a JS-compiled version of the Dart code, and sass-embedded which is a very thin wrapper around a native Dart binary.

For Wagtail – currently we use sass to alleviate any risks of cross-platform compatibility issues (for example macOS users relying on Node tooling within Docker and directly on their machine). In the future we might switch to sass-embedded in the interest of performance.

Full results

Sass

Webpack production build (webpack --config ./client/webpack.config.js --mode):

webpack compiled with 40 warnings in 16705 ms
webpack compiled with 40 warnings in 18468 ms
webpack compiled with 40 warnings in 16815 ms
27.55s user 3.44s system 164% cpu 18.820 total
27.51s user 3.37s system 150% cpu 20.473 total
27.07s user 3.20s system 160% cpu 18.900 total

Webpack development build in watch mode (edits on core.scss):

webpack compiled with 11 warnings in 3183 ms
webpack compiled with 11 warnings in 3212 ms
webpack compiled with 11 warnings in 3314 ms

Sass embedded

Webpack production build (webpack --config ./client/webpack.config.js --mode):

webpack compiled with 40 warnings in 15307 ms
webpack compiled with 40 warnings in 17473 ms
webpack compiled with 40 warnings in 14926 ms
25.05s user 3.51s system 168% cpu 16.948 total
26.02s user 3.56s system 150% cpu 19.681 total
24.80s user 3.22s system 165% cpu 16.952 total

Webpack development build in watch mode (edits on core.scss):

webpack compiled with 11 warnings in 2400 ms
webpack compiled with 11 warnings in 2221 ms
webpack compiled with 11 warnings in 2335 ms

Full cloc output

For future reference, this is Wagtail:

--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Python                         8332         284435         313969        1631855
PO File                        3617         260968          95300         759786
JSON                            503            332              0         179094
HTML                           1122           5423             43         108638
JavaScript                      572          12091           8303          73143
Markdown                        233          11704             91          27626
XML                              11             12           3193          27275
Text                            250           1259              0          16329
TypeScript                      145           2118           2647          14170
SVG                             189              0              4          10851
CSS                              79           1910            855          10759
SCSS                            130           1746            789           8756
reStructuredText                153           2469           1291           4565
TeX                              27            298           2525           3952
YAML                             22             45             89           1883
SQL                               4              0              0           1405
C                                 3             89             33            450
make                              3             55              8            239
TOML                             14             14             13            164
Bourne Shell                      5             30             22            139
Bourne Again Shell                1             13              9             91
Fish Shell                        1             19             14             70
INI                               2             19              0             68
PowerShell                        1             12              3             46
Dockerfile                        2             24             52             44
C Shell                           1             13              7             35
CSV                               2              0              0              8
--------------------------------------------------------------------------------
SUM:                          15424         585098         429260        2881441
--------------------------------------------------------------------------------

Those reflections are from two meetings about the project, the very beginning, so there’s lots to figure out still! But here we are.

For context – read Introducing our grid-aware websites project from the Green Web Foundation, and for even more context, Hannah’s Reflections on our first advisory group meeting for Grid-aware Websites. For the TL;DR; context, this project is about making websites more energy-efficient as and when needed. It’s a collab between the Green Web Foundation, and a panel of Content Management Systems representatives:

A visual representation of the grid-aware websites advisory group. Credit: Green Web Foundation

In practice - if you want a quick real-world example, see the Branch Magazine website.

My TL;DR; take on the grid awareness concept

Lots of site users and stakeholders want lower-footprint websites. Grid awareness makes that possible, since there is so much data available now, live, on how carbon-intense the electricity grid is. The Green Web Foundation’s approach also has the potential to be simple to retrofit onto existing sites and web apps, Wagtail or no. Rolling this out on a site will also increase users’ and stakeholders’ awareness of sustainability, which is a win for all of us.

Project framing

We were asked to reflect on whether, or how, we could make the case that:

A grid-aware website means a better experience for the user.

I’ve struggled a lot with this, as I generally start from the position that we should focus on making a singular default experience better for everyone. However – some people do want lower-footprint websites! It’s a fallacy to assume we can make the one canonical version of a website the best for everyone, as is clear from working on accessibility. Websites, and the web platform generally, are excellently suited to adapt to user needs (color themes, font sizes, responsive, etc).

So 👉️ I believe a grid-aware website can be a better experience if we put users in control of their experience, and their browsing’s footprint. In that scenario, with perhaps different themes or versions of a site available for users to choose from: grid awareness means a better default experience for all, while adapting based on the gri. A good, low-footprint site when needed according to the grid – and users can switch back to a higher-footprint version when they want.

For the project group, in as few words as possible, I put it as:

Website users care about their footprint. They fiddle with website or app controls to lower it. Those added user controls increase user agency, but also cognitive effort. Grid awareness means a safe default. Grid awareness helps users lower their footprint, by automatically adjusting the site when it matters.

Additionally, I believe there are obvious benefits for battery life and data costs of mobile devices. See for example the Save-Data header, and how it’s used by Opera and Android devices. Win win win 🎉!

Grid awareness mental model

It’s been hard for me to have a good mental model of the “grid-aware” mindset, and deciding based on what criteria to switch between the “regular” and “low-footprint” versions of a page. I’m wondering about things like:

• How to communicate this with stakeholders and users who might or might not be aware of the electricity grid, its energy mix, or carbon intensity.
• Whether / how much to try to align this with any website goals (say a target on carbon intensity per page view, or overall Net Zero goals)
• How much to grapple with any social equity considerations. There are a lot of configuration options where the “grid aware” mode would kick in 100% of the time for people in countries with carbon-intensive energy grids. I’m not sure if that’s a good thing or not.

I’ve arrived at those questions when reviewing the options to switch between the “vanilla” and “low footprint” versions of the site. I believe there’ll be lots of people asking themselves which of those to choose from based on their needs.

Terminology for the methodology

One other thing I’ve struggled with a bit is terminology. Is “grid-aware” referring to the website across all versions, or just the one that has a lower energy use? And for site users, how we would communicate what version of the site they’re looking at? (Branch Magazine uses the term “Grid intensity view” which can be “Live”, “Low”, “Moderate”, “High”).

Design philosophy

The last conceptual element I grappled with was when comparing the two modes on the site, which one to consider as the “default”, if any. For example in Responsive Web Design, there was a switch towards a Mobile First design and coding approach. In front-end dev, there’s the progressive enhancement and the graceful degradation philosophies.

A UI-UX catalogue to demonstrate grid awareness

This would be excellent! With assorted case studies, possibly measurements with the excellent Firefox Profiler’s support for power usage metrics.

I’d also like to see very solid examples of grid-awareness on/off controls for site users. Where to place them on the page? Header? Space is at a premium. Footer? Will never be found.

Sharing the project

For Wagtail, I’m hoping we will be able to kick off adoption with a Google Summer of Code project. Beyond that, a solid “zero to grid-aware” tutorial in say 30min (conference workshop friendly format) will also be excellent.

Up next

I’m glad to be part of this! And impressed at how well the Green Web Foundation team facilitates a positive collaboration on such a tricky topic as website sustainability, with so many different stakeholders involved. I’m looking forward to the next meeting!

And for Wagtail – look out for a grid-aware version of our Wagtail.org website, or of the Wagtail user guide website.