←back to thread

446 points talboren | 4 comments | | HN request time: 0.871s | source
Show context
PedroBatista ◴[] No.45039192[source]
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 problem is not "Rails" or [ insert any other tech BS to deflect the real problems ].

replies(17): >>45039249 #>>45039365 #>>45039680 #>>45039841 #>>45040328 #>>45040430 #>>45041105 #>>45041125 #>>45041207 #>>45042280 #>>45042385 #>>45044131 #>>45046133 #>>45048521 #>>45050100 #>>45051138 #>>45062005 #
bob1029 ◴[] No.45039249[source]
> 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.

replies(10): >>45039310 #>>45039407 #>>45039686 #>>45040388 #>>45041936 #>>45043631 #>>45048845 #>>45049190 #>>45051019 #>>45051373 #
Zanfa ◴[] No.45040388[source]
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.
replies(2): >>45041029 #>>45041118 #
slt2021 ◴[] No.45041118[source]
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

replies(6): >>45041255 #>>45041536 #>>45043882 #>>45046904 #>>45047482 #>>45051651 #
1. aleph_minus_one ◴[] No.45051651[source]
> 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).

replies(1): >>45052060 #
2. otabdeveloper4 ◴[] No.45052060[source]
> because they take time

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

replies(1): >>45052460 #
3. aleph_minus_one ◴[] No.45052460[source]
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.

replies(1): >>45054315 #
4. slt2021 ◴[] No.45054315{3}[source]
the most common cause is architecture, not algorithms