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

Removing jQuery from GitHub.com front end

githubengineering.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Removing jQuery from GitHub.com front end

#12

Post by rhacker »

reiyne wrote: post #3
symlinkk wrote: post #2

> Having static type checking helped us have greater confidence around those refactorings Does Github use TypeScript?

> Finally, we wanted to start annotating types with Flow to perform static type checking at build time, and we concluded that the chaining syntax doesn’t lend itself well to static analysis, since almost every result of a jQuery method call is of the same type. We chose Flow over alternatives because, at the time, features such as @flow weak mode allowed us to progressively and efficiently start applying types to a c…

Typescript will probably be force-dog fed at some point. However, I don't think it will be a mistake.

Re: Removing jQuery from GitHub.com front end

#13

Post by brendanr »

The transition to CSS transitions seems primitive to me. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animati... makes it sound very much like a fire-and-forget approach.

My concern, also when building UI with React, is that web design is often only interested in end-state of an interface, playing a bunch of fire-and-forget animations to transition between states.

The reality, that only games and Apple seem to have embraced, is that it's far more sophisticated for animation to reflect a state that can change at 60 or even 120 frames per second, depending on what the user is doing.

This is a great presentation from Apple, Designing Fluid Interfaces, that captures the concept: https://developer.apple.com/videos/play/wwdc2018/803/

Am curious: have any web frameworks embraced this approach?

Re: Removing jQuery from GitHub.com front end

#16

Post by sampl »

brendanr wrote: post #13

The transition to CSS transitions seems primitive to me. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animati... makes it sound very much like a fire-and-forget approach. My concern, also when building UI with React, is that web design is often only interested in end-state of an interface, playing a bunch of fire-and-forget animations to transition between states. The reality, that only games and Apple seem t…

Amen. I’ve been waiting for a React web animation/gesture lib that does exactly that.

The gestures and animations in that video are a million miles away from the best I’ve seen on the web.

Re: Removing jQuery from GitHub.com front end

#18

Post by dbbk »

russellbeattie wrote: post #15

I don't use jQuery anymore, but damn do I miss the simplicity of fadeIn() and fadeOut(). Trying to do the same with CSS transitions is much more complicated and brittle.

You can use the Web Animations API for this: https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...

Re: Removing jQuery from GitHub.com front end

#19

Post by dan-robertson »

notyourwork wrote: post #7
ghiculescu wrote: post #5

> Set up metrics that tracked ratio of jQuery calls used per overall line of code and monitored that graph over time to make sure that it’s either staying constant or going down, not up. Would love to know how this was done.

I would think you could wrap $ or jQuery or whatever in a hook for metrics.

I think this is wrong though. If you do a bit of trivial jquery to every element of a list, every time someone changes the “selected” element, then that could count as lots of jquery calls, even though there are few call-sites and not much to change to remove it.

I think the more concerning call would actually be some crazy selector, animation, and implicit state change which could be done in just a few calls that happen rarely.

With this in mind I think the right metric is #call-sites and not #calls: most of the time the effort required to refactor a jquery call away is not proportional to the number of times the function is called.

Post reply on HN