ThibWeb

Data on the number of releases comes from ecosyste.ms which was very convenient to do this while comparing with other packages outside PyPI. For what it’s worth, Rails is at 510 on there, which I believe is all releases since 2004. And Laravel is at 247 but there’s 2-3 years missing

it’s my 1st attempt at reporting on CI downloads specifically. Interpreting this is more of an art than a science, I’d love to hear if others have ideas on what to do with this data!

for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more

Between this and the relative color syntax, looks like much cleverer theming options are on the way, yay for more control for end users. For anyone discovering APCA, aside from it giving better results, I’ve also found it super interesting to read about the logic behind the algorithm. The Easy Intro mentioned in the article (https://git.apcacontrast.com/documentation/APCAeasyIntro) is well worth the time and it has all the relevant follow-up resources.

ty! We have no plans to rewrite Wagtail in Rust but I hope there’s ways in which we can make the developer experience better, particularly around dependencies management

yep, I really appreciate their current efforts, but still think it’s a point of concern. Feels risky to have so much of an ecosystem resting on so few people (bus factor, governance, etc). Hopefully with Astral being a for-profit business they’ll find ways for their work to be more sustainable than other package managers’ maintainers.

A lot of Wagtail usage is with Poetry. Tends to be projects with 30-50 dependencies. It "just works" but we see a lot of people struggle with common tasks ("how do I upgrade this package"), and complain about how slow it is. I don’t have big insights outside of Wagtail users but I don’t think it’s too different.

With the caveat I only have the package installers usage data for Wagtail downloads – pdm usage has fallen off a cliff, from 0.2% of downloads in January 2024, to 0.01% in January 2025. Roughly matches the uptake of uv.

Doesn’t make pdm bad in itself but that means there’ll be fewer pdm users around to report bugs, potentially fewer contributors to it too, fewer resources, etc.

Sure – and I think it’s certainly proving to be a good thing so far! My concerns are more longer-term. I see two primarily:

(1) As uv’s governance is driven by a for-profit company, I see incentives that will eventually compromise on its benefits.

(2) Python packaging has historically been very fragmented, and more recently there’s been lots of work on standardization. That work will be impacted when users massively shift to one package installer.

Neither of those things are clear negatives, but they’re worth being aware of.

Well, seems like 100% what’s going to happen (for the majority of Wagtail users at least) if the current trend continues. I’m not sure if that’s a good thing to be frank. But we’ll have to adjust regardless.

See the proposed moveBefore API [1] which is meant to solve those issues at the platform level. In the meantime, htmx has their morphdom extension, which I’d say is a must when replacing any page content with interactive elements within. Aside from that one major gotcha, the main issues with htmx are the poor accessibility of the examples in the docs [2]. In particular seeing so much ARIA without the corresponding keyboard support.

[1] https://htmx.org/examples/move-before/ [2] https://github.com/bigskysoftware/htmx/issues/1431

Gotcha, thank you. The reasons you mentioned are excellent, definitely a pattern that’s best avoided unless there are no other alternatives.

Thanks for chiming in! Do you think it’s desirable for it to stay "ugly" then if it’s for "internal use"?

I can understand the admin isn’t meant to have a "consumer" UI but it still feels like there are lots of user experience & accessibility improvements needed to bring it in line with modern standards (WCAG for example).

I see three quotes from past contributors in the article, that seems like valuable knowledge to me? Anecdotally as someone who contributes to the Django admin I see the interest is there. I’d say it being clunky is for other reasons (for example there being more back-end developers contributing to the project than other skillsets).

Sorry I’m not sure I understand your question? I wasn’t on the internet before web 2.0, by modals I mean things like custom-styled <dialog> element[1] and the `dialog` ARIA role, which I would say are a more recent pattern than pop-up windows. "Modern" might not be the best term here, I should have just said more "usable" perhaps.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

Any particular styling extension you’d recommend? Have to confess I’ve only ever used the vanilla admin myself.

Text contrast is actually one of the most common issues with the Django admin. Just on the screenshot in the article, the white text against the light blue breadcrumb and nav headers background is too low contrast as per WCAG 2.0 calculations.

I’d say because you can lose context more easily when having to move to a separate browser tab / window to complete a task? And I suspect the multi-window paradigm is also harder to navigate for keyboard / screen reader users (as opposed to an in-page modal which correctly captures the keyboard focus while open).

Yep, the different button styles for no clear reasons is one. This is even more apparent on other views. On that screenshot, you can also spot questionable alignment between e.g. checkboxes and the title text in the table. Contrast issues with text against different background colors. And I’d also question whether UPPER CASE TEXT is necessary.

It is certainly simple but I’d disagree it’s functional _enough_, because of the numerous basic accessibility issues with the fundamental UI components.

On extending the admin – perhaps there’s something to be said about the admin coming with more UI components built-in? For example it lacks any dialog / modal window implementation, or an "accordion" / disclosure pattern. Or things like support for keyboard shortcuts.

"Ugly" might not be the best one-word description but there are a lot of basic accessibility issues with the Django admin. The general user experience could also really benefit from using more modern design patterns (for example modal windows over pop-up windows).

I’d be really interested in this as well (disc. – I work on Wagtail). This feels so similar to our vision for the CMS aside for the fact the project has been running for a while and is in Python land.

Wagtail core developer here – here are our sprint notes [1] that demonstrate what this funding means for us in practice. The TL;DR; is being able to address long-term technical debt in the UI, improving accessibility throughout, having proper UI customization capabilities – as part of a redesign & new features.

[1] https://github.com/wagtail/wagtail/discussions/7739

I share the same sentiment, but it would be even better if what’s shared was more factual / less dogmatic – or in this case if sourcehut itself was a better example. At a high level it’s somewhat correct that sticking to HTML-only features is better, but otherwise there are a lot of issues with the specific guidance in the post:

Don’t use JavaScript to create custom input elements like text boxes

Sure. But some JavaScript would be valuable, for example to display validation errors without a full page reload (try typing special characters in https://git.sr.ht/create). This means screen reader / keyboard users have to navigate back through the page, to the field, and discover what the error is. A skip link would be nice too, that only takes HTML.

A good way of simulating the screen reader experience is to view your page with Lynx. Conveniently, Lynx does not support JavaScript.

Please don’t waste time in Lynx if you want to simulate the screen reader experience – if you’re knowledgeable enough to have Lynx installed and use it, you can learn to use a screen reader. There are good, free ones with every OS these days. They are much more capable than Lynx, and support JavaScript just fine.

Avoid littering marketing garbage, superlatives, and ads for other parts of the site (or even ads outright) throughout your page, as skipping these is more difficult for a screen reader than for the typical visitor.

If your ad is wrapped in a `<section aria-label="My ad">` or aside, then it should be very easy to skip.

The general guidance here is to focus on plain language. Sourcehunt should avoid error messages like "Name must match [A-Za-z._-][A-Za-z0-9._-]*"

In summary, if you want to get accessible quick, a good start for your new website might eschew npm install in favor of this:

Please update this template to have the `html` element with its `lang` attribute defined. Not having "lang" defined means screen reader users have the page read out in their browser’s default language, rather than the page’s language, which can make the content unintelligible.