The GitHub Website Is Slow on Safari

Oh, certainly, didn't mean that you had to avoid using your IDE to autorename a variable yourself (to avoid the boolean issue) and diffed results to those of the PR

Or that you had to avoid Ctrl+F "CustomerEmail" and see whether you had 1000 matches that matches the number of changed files or only 999 due to some typo.

Or using the web interface to filter by file type to batch your reviews.

Or...

Just that in none of those cases there is anything close to our memory/attention capacity.

We already automate that, it's called a compiler. The human review is just for kicks for this type of thing.

Of course some languages... PHP... aren't so lucky. $customer->cusomerEmail? Good luck dealing with that critical in production, fuckheads!

You're not just reviewing the individual lines, but also which context, and which files are impacted. And automating that part would still mean reviewing the automation and the 1000+ changes to move to it.

Sure 1000+ changes kills the soul, we're not good at that, but sometimes there's just no other decent choice.

Serving static files off highly efficient, distributed CDNs is a solved problem. There's no "4K blu-rays per second" when you're talking about gzipped, highly cacheable text data.

If github has a million users visiting it per day on a FRESH cache, and all of them have to download at least 10 megabytes of text data (both of these numbers are far too high), you are at ... 0.015 "4k blurays per second". Yeah I think MS's datacenters will survive.

why do you say "easily"? it took them considerable effort to make that atrocity, I'm pretty sure. The fact that tens of people worked on this and yet this is the result is way more telling of the team and company culture than it is of the specific tool.

Not necessarily. Sharp tools are often sharp because someone needs it.

I’m not a frontend dev, and have next to zero experience with anything beyond jQuery, but an analogy is shell. Bash (and zsh, though I find some of its syntactic sugar nicer, albeit still inscrutable) will happily let you do extremely stupid things, but it also lets you do extremely complicated things in a very concise manner. That doesn’t mean it’s inherently bad, it means you need to know what the hell you’re doing, and use linters, write tests, etc.

The front-end is usually just a thin layer on top of a database, sometimes with backend services (queues/processing). Having a bad language on the front-end actually helped. You don't want to write code because of the bad language, you write less code, less code is less bugs. You had to be invested to increase the lines of code. It's like the hard chair of programming languages. If you don't want programmers to dwell there, bring the hard chairs.

MBA's ruin everything

But taxpayers keep bailing them out... so how did they lose?

  > Which, unfortunately, cannot be measured 

This is such a subtle but important thing that so many people do not understand about data analysis. It's even at the heart of things like survivor bias[0]. Your measure is always a proxy and this proxy has varying degrees of alignment with what you want to measure.

I know everyone knows the cliche "The devil is in the details" but everyone seems to continually make these mistakes because nuance is hard. But then again what is a cliche if not words of wisdom that everyone can recite but fail to follow?

  > Its all fun and games until you cut quality over and over so much your customers just leave.

The alternative is you develop a Lemon Market. Which is a terrible situation for all parties involved. Short term profits might be up but these are at the loss of much higher long term rewards.

[0] You infer where the downed planes were shot through the measures you can make on recovered planes. But that is very different than measuring where downed planes were shot. You can't just take the inverse of the returned planes and know where to add plating from there.

Various comments and links throughout the discussion of this post indicate that the problem is a mix of the sheer number of nodes and css. It has nothing to do with React or being a React SPA, which it's also not, unless you have some proof otherwise.

> When native software is slow, it's bad software. When web software is slow, react is bad software.

This is such a tired trope.

So? You can still do a PR of 1 line and the diff will only show that 1 line.

Fast algorithms are often more complicated.

To give just one simple example: to get the textbook complexity bound for the Dijkstra algorithm, you need some fancy mergeable heap data structures which are much more complicated, and thus time-intense to implement than the naive implementation.

Or you can get insane low-level optimizations by using the SIMD instructions that modern processors provide. Unluckily, this takes a lot of time and leads to code that is not easy to understand (and thus not easy to write) for "classically trained" programmers.

Yes, you indeed need a lot of skills to write such very fast algorithms, but even for such ultra-smart programmers, finding and applying such optimizations need a lot of development time, which is why this is often only done for code parts that are insanely computation-intense and performance-critical such as video (and sometimes audio) codecs.

I love the explanation in the linked site:

> Writing on the internet can be a two-way thing, a learning experience guided by iteration and feedback. I’ve learned some bad habits from Hacker News. I added Caveats sections to articles to make sure that nobody would take my points too broadly. I edited away asides and comments that were fun but would make articles less focused. I came to expect pedantic, judgmental feedback on everything I wrote, regardless of what it was.

https://macwright.com/2022/09/15/hacker-news

Which is true. Pedantism is the lowest form of pseudo-intelligence.