Live data from Hacker News

Making our new homepage fast and performant

github.blog

111–120 of 144 posts

Re: Making our new homepage fast and performant

#111
post #70

Safari has become the new IE in a lot of ways as far as compatibility. A good first step would be to stop gating Safari updates behind OSX updates.

It really hasn't. Most of the shiny new features that Chrome pushes are actively objected by both Mozilla and Webkit teams.

Re: Making our new homepage fast and performant

#112

Talking about nice looking homepages that load fast the first one that came to mind is Stripe's. It starts with 952.83 KB / 364 KB transferred and goes to 1.70 MB / 482.03 KB transferred on final load (once you reach the bottom of the page) Github's starts with 3.10 MB / 969.27 KB transferred and goes to 6.64 MB / 4.54 MB transferred Yeah, Github's homepage has more content, it's true... but what I find really amazin…

Wow. It's been a while I hadn't a look at the Stripe homepage. This is raising the bar. How does one go about drawing those nice device mockups with code? I assume it's a combination of svgs and canvas, but probably built using specific software?

Re: Making our new homepage fast and performant

#113
post #107

Earlier quoted context omitted.

Is there anything novel here? GitHub is nowhere close to a delight as people make it out to be. Settling for GitHub creates as many problems as it solves. This is not a recent development, and there's nothing surprising about any of this (at least it shouldn't be considered surprising at this point). What's interesting that if you ask people why they love GitHub, they'll probably say, "because of its community and it…

What's the five-dollar bill in this metaphor? I'd like to use it. Currently my employer has told me to use a one-dollar bill. As I continue with your metaphor, I struggle to see what insight it's giving.

Critique at Google is pretty great, but internal-only. I don't know of any commercially available tools that are even close.

This commenter says reviewable.io is closeish: https://news.ycombinator.com/item?id=19102930

Re: Making our new homepage fast and performant

#114
When browsing static/non-animated web pages, sometimes I get a feeling that the developers wanted to draw, had to make a website instead, and tried to combine those two, so users are then forced to appreciate their art. But with animated ones it's rather like making a game -- and once again the users are forced to run and complete it in order to proceed to what they were after. Good that it's optimized (although it's still a 60% CPU load and laggy here), but I'm rather curious how it may seem like a good idea in the first place.

Re: Making our new homepage fast and performant

#115
post #79

Earlier quoted context omitted.

I have hit the final crater you mentioned so often, I now manually visit the url /myorg/myrepo/compare/old-master...my-new-feature to start the PR instead of clicking "Create PR" or "Compare"

I use the hub[0] cli tool to manually specify the branch when I create a PR. [0]: https://hub.github.com/hub-pull-request.1.html

Git aliases to the rescue:

    pr !open "$(git remote -v | grep origin | grep push | cut -f 2 | cut -d " " -f 1 | sed -e "s|git@\(.*\):\(.*\).git|https://\1/\2|")/pull/new/$(git rev-parse --abbrev-ref HEAD)"

Re: Making our new homepage fast and performant

#117
post #70

Safari has become the new IE in a lot of ways as far as compatibility. A good first step would be to stop gating Safari updates behind OSX updates.

Gating? Safari 14 was released sep 16, Big Sur came in november

Safari 14 only supports webp in Big Sur. If you want that "update" you have to upgrade OSX. Sometimes it's version number, sometimes like in this case it's just the feature.

From a browser compatibility perspective though it's not much different. We are waiting on lagging support for certain browser features because Apple is gating them behind OSX upgrades.

Re: Making our new homepage fast and performant

#118
post #70

Safari has become the new IE in a lot of ways as far as compatibility. A good first step would be to stop gating Safari updates behind OSX updates.

It really hasn't. Most of the shiny new features that Chrome pushes are actively objected by both Mozilla and Webkit teams.

Yeah, but there are a growing number of areas where Chrome and Firefox have nearly identical behavior and Safari is the odd one out. Text overflow ellipsis inheritence handling and sticky elements in a scrolling flex container off the top of my head. But there seems to be lots of those things where it works fine in FF and Chrome but not Safari.

Further, Apple seems to show little interest in improving. About what you'd expect from somebody high on their own market position(dominant on OSX and exclusive on IOS until recently). So, a lot like IE back in the day IMHO.

Re: Making our new homepage fast and performant

#120

Talking about nice looking homepages that load fast the first one that came to mind is Stripe's. It starts with 952.83 KB / 364 KB transferred and goes to 1.70 MB / 482.03 KB transferred on final load (once you reach the bottom of the page) Github's starts with 3.10 MB / 969.27 KB transferred and goes to 6.64 MB / 4.54 MB transferred Yeah, Github's homepage has more content, it's true... but what I find really amazin…

Wow. It's been a while I hadn't a look at the Stripe homepage. This is raising the bar. How does one go about drawing those nice device mockups with code? I assume it's a combination of svgs and canvas, but probably built using specific software?

I thought that quite a bit of it was really, really good use of CSS.
Post reply on HN