Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The GitHub website is slow on Safari

github.com

Post reply on HN
Print view View original

321–330 of 367 posts

Re: The GitHub website is slow on Safari

#321

Post by MereInterest »

whstl wrote: post #275
NetOpWibby wrote: post #270

Earlier quoted context omitted.

Based tbh

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 feed…

> Pedantism is the lowest form of pseudo-intelligence.

You can’t just lay this bear trap of an opportunity and expect me to not pedantically state that the word is either “pedantry”, the activity performed by pedants, or “pedantic”, to describe such activities.

“Pedantism” would be a philosophy or viewpoint that extols pedantry. Pedantism would be to pedantry as deontology is to rule-following, a justification of an activity. As such, pedantism would be a slightly higher form of pseudo-intelligence than mere pedantry.

But only slightly.

Re: The GitHub website is slow on Safari

#322

Post by [deleted] »

yrds96 wrote: post #83

Isn't the opposite? No one in this thread even cogitating how bad Safari is in terms of performance and supporting web standards? There's in one even partially blaming both. Github isn't the best example of a fast website, but if you can run it in Chrome and Firefox, even on rudimentary browsers like Palemoon (I tested) on decent hardware (even mobile), there's something clearly wrong on Safari.

[deleted]

Re: The GitHub website is slow on Safari

#323

Post by m0llusk »

can16358p wrote: post #207
slt2021 wrote: post #116

Earlier quoted context omitted.

the problem is developers having fast modern machines. if they were forced to use slow machines, they would not be able to put out crap like that

While I agree about devs should be testing on slow devices, the particular target audience of the site generally have pretty decent machines (including two that I have) and there isn't much reason for the site lag. It's not really doing any 3D rendering with complex shaders or video filtering; it just shows changed lines in two files. That shouldn't lag.

I code on ten year old laptops and use Bitbucket CLI in part because of all this.

Re: The GitHub website is slow on Safari

#324

Post by hellcow »

mehdix wrote: post #303
willvarfar wrote: post #286

Earlier quoted context omitted.

I only used phabricator on a side project that other devs, with meta history, had set up. And although not a heavy user, I rather liked it for being very basic which I thought was a very good thing. My memory is fuzzy but I think it was on phab that I discovered and loved to use stacked merges. This is where you have a merge request into another open merge request etc. Super useful. Miss that in the git world.

Can't you simply make a PR against the other PR's branch?

Yes, but the UI isn’t great for it. When you make a change in a base branch and push all the branches ahead of it, GitHub litters the UI with “force push” activity, even when no one has even started reviewing the PRs yet. This creates tons of visual noise in the PRs to sift through.

Re: The GitHub website is slow on Safari

#325

Post by guappa »

gloosx wrote: post #310
guappa wrote: post #307

Earlier quoted context omitted.

compare slack with telegram-desktop for example, which has similar functionalities but is way faster.

It would not be faster without some kind of a tradeoff, so it does use way more RAM.

What are you talking about? It runs on the pinephone.

Re: The GitHub website is slow on Safari

#326

Post by sgarland »

bob1029 wrote: post #15
PedroBatista wrote: post #11

The Github website is slow everywhere. It is truly a piece of shit software both in terms of performance but also UX/UI and everything in between. It's a product of many cooks and their brilliant ideas and KPIs, a social network for devs and code being the most "brilliant" of them all. For day to day dev operations is something so mediocre even Gitlab looks like the golden standard compared to Github. And no, the pro…

> And no, the problem is not "Rails" The problem is they abandoned rails for react. The old SSR GitHub experience was very good. You could review massive PRs on any machine before they made the move.

Glad it’s not just me having faulty memory. I was reading a file - not a PR, just a file in our codebase - that was pretty large, like 15K lines, and it was dogshit slow. I was astonished, and thought I had remembered it being much snappier years ago.

Meanwhile, I opened a 100K line CSV in Neovim and while it took a couple of seconds to open and render highlighting, after that, it was fine.

Re: The GitHub website is slow on Safari

#327

Post by muglug »

const_cast wrote: post #234
shadowgovt wrote: post #106

Earlier quoted context omitted.

Ideally, you automate a check like that. Because the answer turns out to actually be "humans are profoundly bad at that kind of pattern recognition." A computer will be able to tell that the 497th has a misspelled `CusomerEmail` or that change 829 is a regexp failure that trimmed the boolean "CustomerEmailAddressed" to "CustomerEmailed" with 100% reliability; humans, not so much.

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!

What if I told you there were tools for that

Re: The GitHub website is slow on Safari

#329

Post by sgarland »

scrollaway wrote: post #237
zozbot234 wrote: post #96

Earlier quoted context omitted.

They're not even saving any money. Syntax highlighting is a trivial workload, whereas the average SPA spends a lot of time in pointless roundtrips that have the server send more data down the pipe than the SSR equivalent.

Sending data is what’s trivial compared to compute… syntax highlighting is not trivial workload compared to that, you don’t know what you’re saying.

You say that, until you’re one of the unlucky people who discover that cloud DBs are just cloud VMs in disguise, and those cloud VMs have network throughput limits.

A fun part of a retro at my company last year was me explaining to a team, “had all of your pods’ requests succeeded, the DB would have been pushing out well over 200 Gbps, which is generally reserved for top-of-rack switches.” Of course, someone else then had to translate that into “4K Blu-Rays per second,” because web devs aren’t typically familiar with networking, racks, data centers…

Re: The GitHub website is slow on Safari

#330

Post by guappa »

ants_everywhere wrote: post #81
terminalbraid wrote: post #38

Earlier quoted context omitted.

As someone who has worked in and with large orgs, the better question is "why does this always happen?". In large organizations "ownership" of a product becomes more nebulous from a product and code standpoint due to churn and a focus on short-sighted goals. If you put a lot of momentum behind a product with that mentality you get features piled on tech debt, no one gets enthusiastic about paying that down because it…

[flagged]

> Is it your theory that working on large projects was better when you had communist masters?

It is. Unemployment was virtually non-existant in the ussr, and healthcare was not connected to employment status. So a worker there knew that saying no to their boss was not going to be a life-or-death decision. They might of course be less wealthy and so on but the worst case didn't look as bad.

Post reply on HN