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

Making our new homepage fast and performant

github.blog

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Making our new homepage fast and performant

#71

Post by Shared404 »

milkytron wrote: post #59
pier25 wrote: post #34

Earlier quoted context omitted.

I find them quite annoying. I'm pretty sure the only people enjoying these kind of animations are the designers themselves. Most people don't go to a website to have an "experience". They just want to find some information as fast and easily as possible.

> Most people don't go to a website to have an "experience". Well, with the things that people do routinely, they rarely do it for the experience. But that does not mean they do not experience it. That experience should certainly be prioritized while keeping the goal of the users as a top priority.

That experience is prioritized by keeping the goal of the user as the top priority.

The only thing I want is some info and to get out. Very few people go to a business website to enjoy the animations.

Edit: No one goes -> very few people go, shout-out to DylanDmitri and Stripe.

I like Stripe's page a lot better than this one though, for reasons I mention in my response to DylanDmitri.

Re: Making our new homepage fast and performant

#72

Post by tppiotrowski »

remolacha wrote: post #47
tppiotrowski wrote: post #37

The never ending tug of war: Developers decrease load speed from 3 seconds to 1 second. Company decides they now have 2 extra seconds of load time to include more analytics, larger splash videos, animations, etc. Before long, the site is back to loading in 3 seconds and a richer (more bloated) web experience is born. History moves in a spiral.

And hopefully, some of those extra analytics, animations, and experiences add value. One great thing about high performance on the fundamentals is that it let’s us move to a higher level of abstraction.

It's nice when performance improvements can be abstracted away or optimized in the browser. HTTP2/3 are good examples.

Something like lazy loading images could be implemented in the browser, but instead we each spend time devising our own lazy loading hacks. Vendors add W3C specs like IntersectionObserver to an ever growing list of web API's that must overwhelm new comers.

I guess it's nice that we have complete control over everything but the web reminds me of Android (more control/complicated). I want Apple (works well enough/simple).

Re: Making our new homepage fast and performant

#73

Post by Shared404 »

DylanDmitri wrote: post #61
pier25 wrote: post #34

Earlier quoted context omitted.

I find them quite annoying. I'm pretty sure the only people enjoying these kind of animations are the designers themselves. Most people don't go to a website to have an "experience". They just want to find some information as fast and easily as possible.

To be fair, I go look at Stripe's homepage every couple months just because it's pretty.

It also doesn't animate text though. The content is all in place, with pretty animations and such in the background.

Not my preferred look, which is admittedly pretty spartan, but it works.

Edit: It does animate the code being typed. But that seems less critical to me then the main body. I would still prefer it to be static personally, but it works.

Re: Making our new homepage fast and performant

#74

Post by tppiotrowski »

Rapzid wrote: 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.

Isn't this what Safari Technology Preview is supposed to be? Although even that release cadence is sluggish compared to Chromium/Firefox...

https://developer.apple.com/safari/download/

Re: Making our new homepage fast and performant

#75

Post by pwdisswordfish0 »

masklinn wrote: post #23

You know what pages I'd like to be fast and performant on github? The PR discussion and diff page. When a PR gets really large (thousands of LOCs and hundreds of comments) (yes I know it's bad to do that, that doesn't help me a lot when it happens), despite them hiding everything so you need dozens of clicks in order to be able to actually read and search through it's slow as hell and it's a mess. This is not helped…

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 its UI — they're great!" and if you ask people who hate GitHub why they hate it, they'll agree that it's about the community and the UI — except, from their perspective?: "They're terrible." It's not hard to figure out what's up with the disparity.

GitHub is a two-dollar bill: better than a one-dollar bill, and worse than a five.

Re: Making our new homepage fast and performant

#76

Post by alphabet9000 »

"This post is the third installment of our five-part series on building GitHub’s new homepage"

Imagine the ridiculous amount of money that has to have been spent on the spinning globe thing. Enough not to have a random blog post talking about, it but a five-part SERIES!!!

The frontpage eats up almost 90% CPU on firefox on my computer[0] and not as much, but still high in chrome. Maybe that has something to do with graphics acceleration, or my computer isn't good enough, or some other thing where it's my fault.. But it's ironic the situation exists for a site with a five-part series describing how "performant" it is.

Scrolling down the site loads up 4.5 MB of bandwidth transferred, 6.5 MB resources loaded, and 110 requests. Could be worse, but the fact this almost seems 'normal' now is a sad state of affairs.

As an aside, I understand this is GitHub's primary marketing vehicle to really Impress and Wow newcomers to the site -- hoping to blow them away with neon graphics and slick animation. But honestly, is this kind of dribbble.com-esque readymade really impressing anyone these days?! Have years of A/B testing determined that a neon space adventure yields the highest level of new user signups??[1]

[0]: https://i.imgur.com/vSFxUO9.gif

[1]: https://i.imgur.com/5IWdM3e.png

Re: Making our new homepage fast and performant

#77

Post by dudul »

alphabet9000 wrote: post #76

"This post is the third installment of our five-part series on building GitHub’s new homepage" Imagine the ridiculous amount of money that has to have been spent on the spinning globe thing. Enough not to have a random blog post talking about, it but a five-part SERIES!!! The frontpage eats up almost 90% CPU on firefox on my computer[0] and not as much, but still high in chrome. Maybe that has something to do with gr…

> As an aside, I understand this is GitHub's primary marketing vehicle to really Impress and Wow newcomers to the site

The thing is, who are these newcomers? Who ever ends up on GitHub's homepage? What company is gonna take this globe thingy into account when deciding to use GitHub or not?

This looks like such a waste of money/time.

Re: Making our new homepage fast and performant

#78

Post by stinos »

pwdisswordfish0 wrote: post #75
masklinn wrote: post #23

You know what pages I'd like to be fast and performant on github? The PR discussion and diff page. When a PR gets really large (thousands of LOCs and hundreds of comments) (yes I know it's bad to do that, that doesn't help me a lot when it happens), despite them hiding everything so you need dozens of clicks in order to be able to actually read and search through it's slow as hell and it's a mess. This is not helped…

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…

Fair enough, but is there a viable alternative? Continuing withe the OP's main complaint: Gitlab's PR review is also slow and not even for a 1000 LOCs, feels even slower to me than Github actually.

Re: Making our new homepage fast and performant

#79

Post by _jjkk »

masklinn wrote: post #23

You know what pages I'd like to be fast and performant on github? The PR discussion and diff page. When a PR gets really large (thousands of LOCs and hundreds of comments) (yes I know it's bad to do that, that doesn't help me a lot when it happens), despite them hiding everything so you need dozens of clicks in order to be able to actually read and search through it's slow as hell and it's a mess. This is not helped…

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"

Re: Making our new homepage fast and performant

#80

Post by stefan_ »

masklinn wrote: post #23

You know what pages I'd like to be fast and performant on github? The PR discussion and diff page. When a PR gets really large (thousands of LOCs and hundreds of comments) (yes I know it's bad to do that, that doesn't help me a lot when it happens), despite them hiding everything so you need dozens of clicks in order to be able to actually read and search through it's slow as hell and it's a mess. This is not helped…

GitLab also does the PR thing, always suggesting the default branch when there are thousands of commits between them instead of the branch that is just a fast forward.
Post reply on HN