jacobr

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

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.

```

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

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

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

```

"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...

Because it’s easier to just not use lodash.

* * *

I hear you. I think Shadow DOM is very useful for a handful of roots on your page, encapsulating third-party widgets or DOM-heavy components like a nested navigation.

Custom Elements on the other hand are useful for attaching behavior to HTML, sort of like jQuery plugins.

Not at all sold on the frameworks promoting using Shadow DOM for every button or whatnot.

For example, encapsulating a third party widget, cookie banner or your main navigation. That way any CSS added inside the shadow DOM only affects those elements - you can safely write selectors like `h1` or `button` and they’ll only match what’s inside that same shadow root boundary.

Almost all examples of Shadow DOM uses Custom Elements, but that’s not required. I think this conflation harms adoption of Shadow DOM.

As an example of what you can use the Shadow DOM for - it works fine as the node to render a React app/component in. So if you need a couple of React components on a page to not affect each others style, you can do React.createRoot(myShadowRoot) and they’re fully encapsulated.

Isn't a shared BFF an oxymoron, considering that you typically build a BFF specifically for one client and its needs? Maybe you just have a backend :)

SSR was mentioned though.

Great post. It's similar to CUBE, https://cube.fyi and the creator of CUBE even wrote about using "Tailwind as the U in CUBE"