Could the next-gen version control system just store ASTs? Does this already exist?

Every user gets their own preferred formatting, and linters and tools could operate on already-parsed trees

The Unison programming language is built around that idea: https://www.unison-lang.org/docs/the-big-idea/

BABLR is building that! It's entirely fair to say that BABLR takes Unison's approach and allows it to be used with every programming language.

This is an idea that comes back often, and has merit of course.

The thing is that this means sacrificing the enormous advantage of plaintext, which is that it is enormously interoperable: we use a huge quantity of text-based tools to work with source code, including non-code-specific ones (grep, sed…)

Also, code is meant to be read by humans: things like alignement and line returns really do matter (although opinions often differ about the “right” way)

And of course the lesser (?) problem of invalid ASTs.

I don't think invalid ASTs are a "lesser" problem, it is a pretty big one: we want to be able to source control work in progress and partially complete things. There's a lot of reasons you might not want to or be able to finish a bit of code and yet you still want to record what you've done and where you are (to pick it back up later, to get other developers' eyes on a sketch or an outline, to save it to backup systems, etc). Those are often important steps in development, though it is easy to forget about how common they are when you think about software as finished/buildable artifacts only.

I know a lot of people think source control should only have buildable code, but that's what CI processes are for and people use source control (and diffs) for a lot of things that don't need to pass CI 100% of the time.

I don't understand why it can't just use an AST if it parses, and fall back to plain text diffs if it doesn't.

Churn in the diffs is a big reason, if the point of wanting a semantic diff is to have a smarter diff for smarter patches/merges. The smartness of your merge is generally a lowest common denominator operation. If most of your intermediate diffs are dumb plain text diffs, your final merge operation is to some extent mostly going to still be a dumb plain text merge.

That may be fine if you are happy with the plain text status quo, but if your goal is to avoid or minimize merge conflicts (as most people want when talking about semantic diff), you don't really solve that as well as you'd like.

(Additionally, and it is a lot less of a concern for git on disk storage but for some git-based email flows and other VCSes patch size matters and a consistent style of diffs between patches can be a useful storage or transfer optimization. Plain text diffs are more likely to produce a lot bigger patches compared to optimization wins you might get from a semantic diff; a mixture of merges between semantic and plain text diffs is often a worst of both worlds case in overall patch sizes as they churn against each other.)

These are all solvable problems, and I know because I have built a solution the demonstrates how they can all be solved at the same time.

you might want to check out eyg lang (eat your greens) as I think the idea is explicitly that syntax is user preferences and the ast is the _real_ language

Isn't this one of the basic ideas of Lisp?

You can even benefit from the default messages if you want that, grabbing `input.validationMessage` and rendering it as you wish.

Any article about rebase is incomplete without the mention of `git commit --fixup fb2f677`. When committing you usually already know which commit you’re “fixing” so you specify that.

Then you run `git rebase -i --autosquash origin/main` instead and the commits are already in the right order.

Even when I do know which commit I am fixing I usually don't know the commit hash without looking it up - and doing that takes as long as manually reordering the lines in an interactive rebase.

```

const $ = document.querySelector.bind(document);

$('.box').hidden = true;

$('.box').hidden = false;

```

1. Not really.

jQuery is designed not to fail. So if there's no `.box` on the page, jQuery will not do anything.

`querySelector` may return null, so `$('.box').hidden` will hard break your page if you're not careful enough

2. `$('.box').hide()` is just one such example.

The hilarious https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs

jumping in on this bandwagon... I sometimes look https://youmightnotneedjquery.com when I forget how to do something with jQuery.

Also, do you know if there is a jQuery-like that actually throws exceptions? Having `$('.box').hide()` tell me there is no `.box` would be pretty useful.

"The concrete description of what is going on here is spread atom-thin across several websites, all of which expect you to know the terminology. Each of these websites provides you with a tiny piece of the puzzle and you are expected to combine it together on your own."

Oh how I unironically love these types of quests.

There's a shift though, just the last couple of years. Today all browsers support native modals with the dialog element, accordions with details/summary, everything but Firefox supports popovers (dropdowns, tooltips, menus, etc) in plain HTML.

I'd honestly love to be a beginner again learning modern HTML and CSS today, it's not bad at all.

It’s built in to VS Code, see editor.foldingImportsByDefault.

Yes, the biggest drawback of Tailwind is React. Or specifically, relying on components as the mechanism for style composition.

External css files are render blocking, meaning any content after a <link rel=stylesheet> will not be visible until the css has been loaded.

Looks a bit like tire inserts - basically foam rings you put inside the tire, common on mountain bikes. I just installed that on my bike, which not only protects my rims but also lets me ride home from the trail with a flat tire. https://www.bikeradar.com/advice/buyers-guides/best-tubeless...