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.

Unfortunately none of that works with the feature in TFA because it’s not supported by Declarative Shadow DOM.

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"

Tailwind and CSS in JS libraries that pre-compile to Atomic CSS solve the problems of bloated CSS files full of duplicated rules.

With Atomic CSS, the growth of CSS is tied to the number of unique styles used, not the amount of features developers are shipping.

For example, it’s common to reuse certain properties like flex everywhere. Rather than have these duplicated in stylesheets under different class names, we only pay that cost once. This is true for each property/value combination.

This is true in theory and when you stick to the very basic stateless utility classes. Check the CSS of any larger site using Tailwind and search for a CSS rule, you will see things like

    .opacity-100 {
        opacity:1
    }
    .hover\:opacity-100:hover {
        opacity:1
    }
    .group\:focus-within .group-focus-within\:opacity-100 {
        opacity:1
    }
 

Or this little screenshot https://twitter.com/css_tools_/status/1587392697857413120

It's definitely a trade-off between privacy/liberty and other benefits.

The spread of standardised time and clocks had a significant negative impact on individual liberty, and people would even sabotage clocks. They failed of course, as will the opposition against the cashless society, because cash is so much worse in most aspects.

If it's something you care a lot about, rather than going the way of the Luddites and opposing eSIM and electronic payments I would suggest focusing on using technology to find new solutions to the privacy/liberty problems.

Same background here.

I don’t believe in quitting cold turkey and I don’t think there’s anything available to fully replace all aspects of React. We’re instead gradually transitioning our internal ecosystem to use less React-specific stuff, positioning us to migrate (or not) in the next few years.

- Move from CSS-in-JS to vanilla CSS

- Avoid React-specific libraries, both developing them internally or when selecting third-party deps

- Keep business logic out of React components whenever possible

Etc

The iPhone 8 only compatibility means that many teams will be stuck supporting Safari 15.6 for a very long time. Anything under "no support" on this page will continue to be out of reach for years to come https://caniuse.com/?compare=safari+15.6&compareCats=all#res...

I think that would start to create some social nudging functions (i.e. payment for Healthcare) while being a bit more fair (i.e. service quality sometimes proportional to money put in).

An interesting definition of “fair” - in Sweden the principle is equal health care prioritized according to who needs or benefits most from the care, not how much you pay. If you see it from that point of view, tax is not a transaction where you pay for the services you receive. You pay for the society you receive, which includes people in general being more healthy, not just yourself.

The Swedish welfare state involved a lot of compromise and give and take. The system benefits workers in some areas and capital owners in others.

You ask Co-Pilot to write some tests

If your goal is to increase RTK adoption, rather than being reactively defensive whenever someone writes something remotely negative about Redux, may I suggest focusing on the highly positive feedback you mention? Writing up case studies on how RTK helped solve concrete problems, instead of being summoned anytime someone is wrong about Redux on the internet…

Anyone judging Redux differently if it has a 15% or 45% market share is making decisions based on the wrong parameters anyway.

This is built on the Lexical framework, which is exactly what you suggest - vanilla JS with optional React bindings. OP's project is an additional React-specific layer on top of Lexical, and since it's concerned with rendering the editor UI it makes sense that it's UI rendering library specific.

From my horizon the most significant adoption has been Netlify edge functions. So not exactly ship jumping, but adjacent and growing spaces.

Another developer here who’s been around for the tech you mention.

The evolution has been 2 steps forward but 1 step back. It’s how many complex systems evolve and it’s fine. Just because you see that some problems/solutions resemble what you saw 10 years ago doesn’t mean nothing was improved along the way.