Live data from Hacker News

The GitHub website is slow on Safari

github.com

331–340 of 367 posts

Re: The GitHub website is slow on Safari

#331
post #330

Earlier quoted context omitted.

[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.

This is false, striking was illegal in the USSR. If you refused to do work you were an enemy of the state.

If your town didn't meet the farming quota they would starve your entire town.

If you went on strike you would get murdered and sometimes your family would get murdered.

If you deserted from the army or retreated you would get shot by barrier troops.

If you were injured or sick you would be disposed of or hidden on an island.

If you were a female orphan under the age of 15 there was something like an 88% chance you'd be used as a prostitute.

The USSR was terrible for workers. Some of this was hidden by lying about statistics, same as it is today with authoritarian countries.

Re: The GitHub website is slow on Safari

#332
post #62

Earlier quoted context omitted.

exactly. I don't want to do a "no true scotsman" to defend React, but circumstantial evidence suggests that they wildly misused the tool

A tool that lends itself to misuse so easily is a bad tool, period.

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.

Re: The GitHub website is slow on Safari

#333
post #90

Earlier quoted context omitted.

I’m pretty sure they used to do syntax highlighting on the server before and it was fast. Now they send down unhighlighted text that seems to choke the browser with anything but the smallest diffs.

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

> 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

Lots of developers are rather obsessed with writing good, performant code. The problem is rather that many project managers do not let them do these insane optimizations because they take time.

The only things that forcing developers to use slow machines will bring is developers quitting (and quite a lot of them would actually love to see the person responsible for this decision dead (I'm not joking) because he made the developers' job a hell on earth).

What you should rather do if you want performant software is to fire all the project managers who don't give the developers the necessary time (or don't encourage the developers) to write highly optimized code (i.e. those idiot project managers who argue with "pragmatism" concerning this point).

Re: The GitHub website is slow on Safari

#334

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…

Have you used gitlab every day in anger? I don't think you'd feel the same if you have.

GitLab’s CI is miles better than GitHub’s. I think it’s telling that every place I’ve been at that used GH also used some 3rd party CI tool (which also sucked, but that’s par for the course), whereas places with GL seemed to manage with its native capabilities.

Re: The GitHub website is slow on Safari

#335

Earlier quoted context omitted.

Firefox 115 is the last version that runs on 10.12, 10.13, and 10.14 (also Windows 7 and 8). At this point 115 is 2 years old and GitHub is only tested on bleeding edge browsers, apparently. So GitHub is usable but there are a number of UI layout issues and searching within a file is sometimes a mess (eg, highlighting the wrong text, rendering text incorrectly, etc. maybe that's true for all browsers. you're better o…

Does that change anything compared to running an old version of Safari that's also extremely slow because of a bug to boot? Modern websites are broken on abandoned browsers anyway, but if you install a less-abandoned browser you'll have a better experience on average. Firefox doesn't work on Windows 7 anymore but installing Firefox is still a hell of a lot better than sticking to IE.

Github is completely unusable on old Safari so it changes everything.

Re: The GitHub website is slow on Safari

#336
post #312

Earlier quoted context omitted.

MBA's ruin everything

Opportunity costs is something they are taught about in school but somehow seem to always forget about. I think it is more a question about incentives for the roles MBAs are usually hired into. Either that or the lack of knowledge of the actual product makes them too detached.

Who would even hire an MBA to improve such difficult to measurre things?

Maybe it will make a significant enough cumulative impact 5 years later that it can actuallly be noticed and defended in a meeting against other priorities.

But I’ve never heard of anyone hiring someone on minimum wage and deferring a huge bonus to 5 years later.

Even if it does makes a big impact, would anyone even take a such a job?

Re: The GitHub website is slow on Safari

#337
post #288

Earlier quoted context omitted.

Turing completeness never says anything about performance. Hypothetically, sure, you could emulate a newer computer on your current computer.

That implies having infinite memory.

So does turning completeness

Re: The GitHub website is slow on Safari

#338

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

> 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 Lots of developers are rather obsessed with writing good, performant code. The problem is rather that many project managers do not let them do these insane optimizations because they take time. The only things that forcing developers to use slow machines will bring is d…

> because they take time

No they don't. It's literally just a skill issue.

Re: The GitHub website is slow on Safari

#340

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 Lots of developers are rather obsessed with writing good, performant code. The problem is rather that many project managers do not let them do these insane optimizations because they take time. The only things that forcing developers to use slow machines will bring is d…

> because they take time No they don't. It's literally just a skill issue.

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.

Post reply on HN