I don't know how they perceive the performance. I see 41 network requests. That's 2.1 MB of CSS over the wire, blocking rendering and hurting painting and loading speed. There's 400 KB of Tailwind, 87 KB of general CSS, plus another 200 KB of other general CSS. They need to embrace functional CSS properly. I'm sure they could have a single CSS file under 80 KB that renders everything.

Using GitHub everyday, I haven't really noticed an improved performance. Actually i'd say pages are becoming slower. Browsing issues with many comments or big PR has a terrible experience as not everything gets loaded

I'm still a bit salty they fiddled with the Lists UI when star'ing a repo and adding it to a list.

The emojis I had at the beginning of the list name don't render anymore (they show up as :eyesore_emoji_name: instead) and the list is sorted alphabetically now instead of by last modified. Also it's one looong list instead of a small scroll-able container like it used to be.

This is on Firefox btw. Now I'm seriously thinking about moving these GitHub "bookmarks" into a separate place like a bookmark manager even if I lose a bit of convenience.

Unfortunately the original blog post introducing the great CSS-in-JS system being removed is not in the "Related posts" section, would be nice to compare the thinking in the two

There's room for improvement still. Currently, the production build is using long-dev class names. e.g. `DirectoryContent-module__Box_3__gl6dE` could be compiled to a shorter hash like `gl6DE3a2`.

If you use Vite:

  css: {
    modules: {
      generateScopedName: mode === 'production'
        ? '[hash:base64:8]'
        : '[name]__[local]___[hash:base64:5]',
      }
    }

The improvement would be shipping human-readable structure to allow easier user overrides, not that hash abomination

Minor nit: it's not all hash. DirectoryContent-module__Box_3__gl6dE is already mostly readable, only the last bit is a hash. But yeah, nobody should write user styles against those, since they can change every build.

Those class names surely gzip better than hashes over the wire?

Mostly, yeah. The repeated module prefix turns into cheap back-references after the first occurrence, while a short hash is high-entropy and barely compresses. Shortening helps raw HTML size and parse cost more than transfer size.

Perhaps we should never ever use hashed class names?

We tried this on a big CSS-modules app. Short hashed names saved about 3KB on a ~300KB stylesheet, barely noticeable. Deduping identical rules across modules shrank it far more, so I'd look there first.

Would you need a source map then for prod debugging?

Any time I see criticism of CSS in JS, and a move to CSS modules, I get sad they didn’t just do a bit more research. You can have both, while also not shipping any JS runtime for CSS in JS! And with TypeScript support.

https://vanilla-extract.style/

The Achilles heel of this class of library (including stylex, Linaria, etc.) is precedence. You either have to use a runtime and some complicated merging rules (e.g longhand overrides shorthand) or compile every possible combination of the styles at build time.

At the cost of pretty bad build time performance when the application grows. We migrated a >1M LOC codebase to CSS Modules from VE for a ~30% build time speed improvement and much better tree shaking on Next.js

I thought that whole point of CSS in JS was about building the CSS with JS in build time, to get managed and optimized output, who madman runs in in runtime?

We went from stylesheets to CSS-in-JS to compile-it-back-to-stylesheets in about ten years. Now native nesting, variables and @layer cover most of it. Another build plugin to babysit is a hard sell, typed or not.

Once (like a year ago or so) stumbled upon some person's post asking for someone to help them to "fix" some section at their website. It was done !important over !important over !important over !important. Said person was really convinced all it needed was another bunch of !important because apparently that was what ai spit for them, at least at that time

Sometimes, [GitHub] posts a [blog post in which they move away from] some terrible [way of doing things] I've never heard before, and it's a weird indirect way to learn how awful their other [design choices] must be.

https://xkcd.com/2071/

And yet, there's been a glaring overflow bug on every repo page if the repo has a sponsor button on Firefox Android for months.

You either "improve performance" or "ship more ___", never both.

The performance must also improve because all iDevices on iOS < 16.4 can no longer view GitHub in Safari due to old WebKit. I blame Apple for not allowing Webkit to be updated independently of the iOS firmware.

Thankfully we now have the Reynard Browser (sideload/trollstore) that uses GeckoView so supports more modern web standards.

css-in-js? Rofl. Whats next? Html-in-js?

What else do you think React was for?

Website-from-prompt?

Yes.

Honestly, hats off to them. It's hard to get anything done with Copilot so I'm amazed they even managed to do this.

Ship more CSS to go faster. Next year's post: ship less CSS to go faster.