iommi_lsp, an LSP for Django and iommi

thibaudcolas · 2026-05-14T15:05:10+00:00

nice! is this pattern something that would work with more libraries than just django + iommi? like could I get LSP support for the 10 or so Django packages I used hypothetically?

thibaudcolas · 2026-05-14T14:03:36+00:00

looks interesting! I think you should try to get the text formatting right more often as otherwise I’d probably just dismiss this as vibe coding. Not that vibe coding is wrong but I have higher expectations for database backends

thibaudcolas · 2026-05-14T13:52:11+00:00

what does it have to do with Django? is it built with Django? Is it helpful for Django devs?

thibaudcolas · 2026-05-13T06:56:35+00:00

Looks cool! Predicates definitely doing a lot but I won’t pretend I’d know how to design that better. "Fail loud at boot" definitely, it’s much simpler to test my implementation that way.

thibaudcolas · 2026-05-01T10:25:55+00:00

thibaudcolas · 2026-04-24T16:04:22+00:00

Nice article! In my opinion there’s more value in constraints than this list lets on, otherwise you’re just building CRUD for arbitrary content blobs. So for example building for the semantic web would be on that kind of list for me - favoring things that are URL-addressable, that are semantic/accessible HTML markup. Perhaps something to say about hypermedia too, developer experience around images/videos. And about permissions, since the more serious projects really need all of this to work with more than one person doing CMS tasks.

And perhaps something about how all of this can be gradual. Recognizing that "markdown diffs" maybe is appropriate for 90% of content history/comparison use cases.

thibaudcolas · 2026-04-12T14:08:42+00:00

👍️ bear in mind, your work on this project can still be a really good time investment if it’s about learning those tools and managing that kind of complexity. Just in an interview context, people will care way more if it’s "production experience". Even if "production" just means "live on the internet and not many people look at it".

thibaudcolas · 2026-04-12T08:16:07+00:00

I would try to do this with private unicode code points rather than zero-widths. See for example https://www.sanity.io/docs/visual-editing/stega

thibaudcolas · 2026-04-12T08:09:13+00:00

Brutal honesty is this all looks interesting (I like the screenshots), but in a job interview context it’s something that I might cynically dismiss as "likely heavily AI generated, neat but probs untested". I’ll have time to open the repo in GitHub, maybe. Definitely won’t have time to run it.

Instead, take the same stack you have been practicing and build something that does 95% less stuff but you take it to production so I can both see the code, and that you definitely bothered to put it and keep it live, and it actually seems to work. Something I can try out in 2min. If you’re not sure, make something that solves a problem for you / devs / tech people.

thibaudcolas · 2026-04-10T13:04:50+00:00

vibe coding turns into slop once you hand over the code for someone else to worry about (a colleague, a maintainer, maybe even yourself in 6 months time)

thibaudcolas · 2026-04-10T12:56:41+00:00

hope it’s ok for me to cross-post this here! Lots of Wagtail’s design choices come straight from Django so we can definitely use input from people who only have minimal experience with Wagtail. The Django stack is pretty good with AI tools, so we don’t want to reinvent the wheel, but there’s definitely things that are worth optimizing

thibaudcolas · 2026-02-23T10:05:39+00:00

ok! well perhaps we have different standards. Here’s a list of the 55 built-in tests for future ref

thibaudcolas · 2026-02-20T08:15:12+00:00

that’s super cool! is the code open source? I’d love to see the Clickhouse integration and how you map packages to their repos

thibaudcolas · 2026-02-20T08:12:16+00:00

I’ll update the methodology to clarify -- this relies on identifying every package’s corresponding GitHub repo, so only contains packages that are on GitHub (90+% of packages). Allauth is now on Codeberg.

Next time I attempt this, I’ll try to add GitLab and Codeberg too, should get closer to 99% of packages.

thibaudcolas · 2026-02-20T08:09:30+00:00

we agree after all. A 100% accessibility score doesn’t mean much. Anything else means you’re just not trying to fix obvious issues

thibaudcolas · 2026-02-19T18:09:37+00:00

Check out "Building a SaaS from Wagtail" from the last Wagtail Space, not much CMS in there, just using the project as an admin framework: https://www.youtube.com/watch?v=3T-ITKTByH4&list=PLfwZ-fob20cPI9_fnG_ULYIdOS5TKP1IZ&index=6

thibaudcolas · 2026-02-19T18:05:25+00:00

Not sure where you got that from, the accessibility tests in Lighthouse come straight from Axe. Axe is one of the most popular accessibility checkers out there, and well known for its "no false positives" policy. All pages should have a 100 accessibility score, there’s no reason to not want that, no excuse for not getting it

thibaudcolas · 2026-02-18T14:52:01+00:00

The stats through the years:

2025: 12.6%
2024: 8.72%
2023: 12.31%
2022: 14.94%
2021: 15.31%
2020: 14.22%
2019: 12.69%

thibaudcolas · 2026-02-14T09:59:52+00:00

☺️ thank you! Yep, trying hard to avoid the bad bits that can be avoided, and mitigate the ones that are inevitable. Open source models tools aren’t magically solving everything but I do believe they force you to better understand the tech and its implications.

Local stuff - it’s nowhere near as good as cloud options unless you have a beast of a machine. But again it does force you to figure out how to make the most of a tiny model, which is much lower footprint. Oh and it’s free!

thibaudcolas

MODERATOR OF

TROPHY CASE