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