nice to see it closure support.

Great writing. I have similar feeling after using Copilot and Claude Code for the past couple of month. The way of programming is changing fast. How to tame it effectively still quite challenge. Quite some time, I feel my nosed dragged by LLM and get false productivity. Though it for sure generate a lot of dopamine.

That’s just bad code in general. In any language, when incompetent or very inexperienced devs write code, they tend to write brittle code that breaks entirely when one thing changes. CSS is not unique. It’s just that a lot of people wrote CSS without really learning it, so they wrote it incompetently.

Language design has a lot to do with it. CSS encourages much more global mutable state than even something like C, so of course it's going to be brittle in practice. The solution is writing the least amount of CSS possible and then just using components to build up a UI. Using CSS any other way feels patently insane.

I think this is best evidenced by our constant innovation of news ways to undermine the "cascading" part of CSS and introducing scope wherever possible.

The brittleness of badly written CSS is unrelated to its cascading nature. In my experience the “cascading” part is a good thing. If you want to make a paragraph red, you do want all other inline elements inside the paragraph to be red as well. Also, in my experience, most of the brittleness comes from an insufficient understanding of selector specificity, including both unintentionally broad selectors as well as unintentionally narrow selectors.

The solution is a careful consideration of scoping: most programming languages encourage the developer to carefully consider whether a variable should be local and global, and a similar amount of care must be taken in CSS too. The programmer needs to have a high awareness of which rules should apply to the whole document and which should apply to this particular component.

> touch one place the whole thing could collapse

That's one very strong indicator that you are doing it wrong.

Great approach. It can also prevent negative energy leak to passionate maintainers.

The first time saw it in my home town with my little boy, I thought it was a bee. Only realize that after staring it for a minute.

Thanks. The purpose is to have an universal object explorer for the cloud object store. So that no matter what type of file it is, just need one click (not two) to view it. So the full workflow continuity will be kept. Click Download then Open to me does not have a good UX, breaks the continuity of brain flow.

Thanks for digging it out. It is still quite large code base. 274052 lines.

That's 4000 pages, small enough that you could easily lift it. You could read it all in a week, though that wouldn't be enough time to understand much of it. It's half the size of glibc and a hundredth the size of Firefox or the Linux kernel.

Thanks for highlighting. Some invisible thing is really bad. Things will be easy if put everything on the table

Usually GitOps have flow like checkout => modify => commit => push => PR => merge => check result. Even if we remove the merge step, still have flow modify => commit => push => check result. In which the commit & push still could be removed