Removing jQuery from GitHub.com front end | Hacker News Reader

Removing jQuery from GitHub.com front end

githubengineering.com

71 pointsbrianmario24 comments

Previous discussion on same topic but different posted link: https://news.ycombinator.com/item?id=17612540

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

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?

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.

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.

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

Right, I can visualize how that'd look from a top-level, but it'd be cool if they could share details. What sort of data did they pass along? Was this a standalone little dev tool on everyone's machine? Talk to a server?

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.

As a guess, wrap each method in a function that records access and run original method? That way you can get stats for each method.

That sounds like a case for decorators!

Couldn't you just count the number of $ to get a decent idea?

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

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

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

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?

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

I've never used Flow, but that sounds the same as `--noImplicitAny` or `--strict` in TypeScript.

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

The posts suggest that they're using flow

Curious why this was marked as a dupe?

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

Reply on news.ycombinator.com