
Removing jQuery from GitHub.com front end - brianmario
https://githubengineering.com/removing-jquery-from-github-frontend/
======
kodablah
Previous discussion on same topic but different posted link:
[https://news.ycombinator.com/item?id=17612540](https://news.ycombinator.com/item?id=17612540)

~~~
spankalee
This isn't just a different link, it's a new blog post with details posted
just today.

------
brendanr
The transition to CSS transitions seems primitive to me.
[https://developer.mozilla.org/en-
US/docs/Web/CSS/CSS_Animati...](https://developer.mozilla.org/en-
US/docs/Web/CSS/CSS_Animations/Using_CSS_animations) 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/](https://developer.apple.com/videos/play/wwdc2018/803/)

Am curious: have any web frameworks embraced this approach?

~~~
sampl
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.

------
1_800_UNICORN
I love the detail-oriented approach to this. Tracking jQuery usage and slowly
removing components from their custom jQuery library are both really clever
strategies.

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

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

~~~
dan-robertson
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.

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

~~~
dbbk
You can use the Web Animations API for this:
[https://developer.mozilla.org/en-
US/docs/Web/API/Web_Animati...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Animations_API)

~~~
opencl
The Web Animations API is nice but it's a working draft that's only supported
by FF and Chrome, no Safari or Edge.

~~~
dbbk
Safari (desktop and iOS) is actually getting it in the next release. It's also
well-polyfilled, we just add it to our Polyfill.io config.

According to caniuse, global native support is at 74%.

------
appleiigs
I haven’t removed jquery from my website because it’s probably the least bad
code to deal with. With Github’s complicated website, maybe they have bigger
fish to fry?

------
symlinkk
> Having static type checking helped us have greater confidence around those
> refactorings

Does Github use TypeScript?

~~~
reiyne
> 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 codebase which was
> largely untyped.

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

------
brianmario
Curious why this was marked as a dupe?

------
rpwverheij
nice list of polyfils at the bottom! Didn't know about `closest` yet for
example.

