Latest Articles

What is the go-to component library these days? I’m not sure there is a clear winner right now. Bootstrap is still popular I’m sure. It seems stable but also sort on maintenance mode and the fact that they are recommending this feels like they are kinda done. I imagine the Sass dependency makes it slot into less and less new projects. The shadcn/ui project is having popularity boom, but the fact that it’s only for React also limits the reach.

Brad Frost kicked off discussion this year about what a global design system might be like. To my web-centric mind, the only answer to this is a component library of web components. And since that is the case, Shoelace is already on the job. I’ve only just learned that…

After setting the record in 2016 for the most funded and most backed software Kickstarter ever (both records still hold), the Font Awesome team is back with a new Kickstarter! Introducing: WEB AWESOME.

Essentially Shoelace 3 is now Web Awesome. Seems very smart. Building a business around what could become the go-to component library will help it become that and stay that.

I heard from a guy once who was incredulous I’d want to block the bots that scrape websites to train AI models. Why wouldn’t I want to help train the intelligence of the future? I get that perspective, I do, but shouldn’t it be up to me? The companies that are scraping my sites are for-profit and turning the access to them into paid products. And they aren’t cutting checks — they’re drinking milkshakes. Nor are they typically linking to or crediting sources.

The AI company bots say they’ll respect a robots.txt directive, which is a file that instructs the permissions of whole-internet roving bots on a particular site. They might, but given the level of respect shown so far, I wouldn’t bet on it. I like the idea of instructing your actual web server to block the bots based on their User-Agent string. Ethan Marcotte did just this recently:

First, I polled a few different sources to build a list of currently-known crawler names. Once I had them, I dropped them into a mod_rewrite rule in my .htaccess file:

Happy Friday!

Here’s a few ASCII “font” headers when you really need to make sure people know things when looking at your code or README document.

Joyee Cheung made some waves in Node land last month:

Since ESM was shipped in Node.js, for many years, it was possible to import cjs, but not possible to require(esm). The frustration of ERR_REQUIRE_ESM has bothered many and probably has been the primary source of wasted hours in the Node.js ecosystem. If package authors wanted to make sure that both CJS and ESM users can consume their package, they either had to continue shipping their modules as CJS, or ship both the CJS and ESM version

Apparently, it will go out in v22, which isn’t out yet but should be soon.

One of my recent moanings-and-groanings is the fact that seemingly no color-picker supports Display P3 colors. Display P3 allows you to use far more vivid colors then we’ve historically had access to in CSS, but now are totally supported in CSS through newer color functions like oklch(). Not even the built-in color picker to macOS.

Well it’s time for me to quit my bitchin’ because I’ve just seen two. I only looked at Mac stuff because that’s what I use. Feel free to chime in with options on other operating systems.

XScope can do it — but XScope is $50 and I find it heavy handed for the work I do. System Color Picker is free and I find very nice in it’s simplicity (it’s just a UX improvement over the default). The workflow I want, and it delivers, is: pick color from screen, have color on clipboard in OKLCH (that’s it).