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
marginalia_nu 6 minutes ago [-]
Yeah. It used to be unusable on mobile and great on desktop. But desktop has in my experience honestly been slipping pretty bad last few years. Maybe I live too far from the data center or something.
One weird tangentially related thing is checking whether a PR is merge:able after solving a conflict in this repo[1] for some reason takes several minutes. Maybe because there are 1000 commits in the same file. Doesn't seem UI related but weird regardless.
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.
karolusrex 2 hours ago [-]
These type of comments often come from a place of arm-chair reasoning where you might not sit on the experience of working hands-on in a large team on a large product. While it’s probably true that X kB sufficient, that amount of performance optimisation is usually not warranted at this scale. Maintaining a design system, working with scoped classes, legacy code, and dealing with the complexities of chunking and probably further challenges we are not aware of from the outside. It seems like a common sentiment on HN (maybe not you in particular) is that engineers should drop everything and work overtime on optimizing performance, when it comes to web apps
eviks 45 minutes ago [-]
> that amount of performance optimisation is usually not warranted at this scale.
Indeed, you need to waste a few years hurting user experience before investing a few years into migration and writing another "improved performance" blog post.
> that engineers should drop everything and work overtime on optimizing performance
The opposite, they should work less time instead of more doing a worse job that results in scraping all their output later in a redesign
jchw 11 minutes ago [-]
Isn't this backwards? Optimizing assets becomes more important with scale, not less. Not saying it is actually prioritized that way or that it would be easy but IMO the more traffic you have the more important it is to be frugal with bits.
meerita 2 hours ago [-]
The beauty of functional CSS is that you can progressively transform everything. GitHub runs on entire modularized codebase, they can clean up the entire codebase within weeks, days if they use agents and see the effects of performance instantly.
austin-cheney 2 hours ago [-]
The shitty team excuse.
Performance is not complicated. You measure something and compare the numbers. Through my career I have encountered the following failures repeatedly:
* The complete inability to measure things. This is common among people with low social intelligence. Many people in this line of work cannot measure things and form all kinds of bullshit excuses. Cannot do it all as if they are disabled. Sometimes it is laziness, sometimes it’s autism masking, and sometimes it’s stupidity/ignorance where they believe they shouldn’t have to or are superior from convention alone.
* The shitty team argument. It’s common for people to intentionally avoid or discard measures because there is fear superior performance may indicate an operating deficit. The last thing anybody in software wants is to change approach if they are on a shitty team, because corporate developers are allergic to training people. This is often justified by asking what happens if you work on a team or about new hires.
* Throwing performance data away and lying about it. This is very common when performance data provides evidence that current conventions or favorite tools harm performance. If, for example querySelectors measure 100,000 times slower than some other approaches developers will pretend the performance evidence just doesn’t exist.
* Guessing. When people suck at what they do they invent their own performance realities. When people guess at software performance they are supremely wrong more than 80% of the time and tend to be wrong by multiple orders of magnitude.
karolusrex 41 minutes ago [-]
You measure and improve the metric, but at what cost, when should you stop? Have you worked on a 1mill+ loc web app?
catlifeonmars 1 hours ago [-]
You’re confidently making a lot of assumptions that don’t generalize.
For example:
> performance is not complicated
Not to mention all your assumptions about the motivations of people who don’t do optimization well. That one can’t possibly generalize.
DrBazza 15 minutes ago [-]
FWIW, a very quick look at other comparable sites (what seems to be the main css files):
sourcehut's 128kb raw, and 28kb over the wire.
codeberg is 420kb raw, and 66kb over the wire.
efortis 3 hours ago [-]
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`.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
Onavo 3 hours ago [-]
Would you need a source map then for prod debugging?
eviks 3 hours ago [-]
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
Gualdrapo 3 hours ago [-]
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
lloydatkinson 46 minutes ago [-]
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.
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.
One weird tangentially related thing is checking whether a PR is merge:able after solving a conflict in this repo[1] for some reason takes several minutes. Maybe because there are 1000 commits in the same file. Doesn't seem UI related but weird regardless.
[1] https://github.com/MarginaliaSearch/submit-site-to-marginali...
Indeed, you need to waste a few years hurting user experience before investing a few years into migration and writing another "improved performance" blog post.
> that engineers should drop everything and work overtime on optimizing performance
The opposite, they should work less time instead of more doing a worse job that results in scraping all their output later in a redesign
Performance is not complicated. You measure something and compare the numbers. Through my career I have encountered the following failures repeatedly:
* The complete inability to measure things. This is common among people with low social intelligence. Many people in this line of work cannot measure things and form all kinds of bullshit excuses. Cannot do it all as if they are disabled. Sometimes it is laziness, sometimes it’s autism masking, and sometimes it’s stupidity/ignorance where they believe they shouldn’t have to or are superior from convention alone.
* The shitty team argument. It’s common for people to intentionally avoid or discard measures because there is fear superior performance may indicate an operating deficit. The last thing anybody in software wants is to change approach if they are on a shitty team, because corporate developers are allergic to training people. This is often justified by asking what happens if you work on a team or about new hires.
* Throwing performance data away and lying about it. This is very common when performance data provides evidence that current conventions or favorite tools harm performance. If, for example querySelectors measure 100,000 times slower than some other approaches developers will pretend the performance evidence just doesn’t exist.
* Guessing. When people suck at what they do they invent their own performance realities. When people guess at software performance they are supremely wrong more than 80% of the time and tend to be wrong by multiple orders of magnitude.
For example:
> performance is not complicated
Not to mention all your assumptions about the motivations of people who don’t do optimization well. That one can’t possibly generalize.
sourcehut's 128kb raw, and 28kb over the wire.
codeberg is 420kb raw, and 66kb over the wire.
If you use Vite:
Besides download size, smaller names improve parsing speed too.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
https://vanilla-extract.style/
https://xkcd.com/2071/