Performance is a multi-faceted thing. It would be great if we could reduce it down to a single metric such as bundle size, but if you really want to cover all the bases, there are a lot of different angles to consider.
He digs into other factors that have an influence:
Handy helper tool by Wes Bos: simply press any key and see the results for KeyboardEvent.which, KeyboardEvent.key,KeyboardEvent.code, etc.
As a user with an AZERTY keyboard layout I often have a broken experience on sites that respond to first row of keys, e.g. QWERTY. As those sites respond to KeyboardEvent.key — which differs from layout to layout — I cannot simply use the first row, but have to reach for the Q and W keys on the second and third row.
To properly implement key presses independent of the keyboard layout, it’s recommended to use e.keyCode as that will yield the same keyCode. As per MDN:
The KeyboardEvent.code property represents a physical key on the keyboard (as opposed to the character generated by pressing the key). In other words, this property returns a value that isn’t altered by keyboard layout or the state of the modifier keys.
For example: pressing A on AZERTY will yield KeyQ. Pressing Q on QWERTY will also yield KeyQ as they’re the same physical key.
I avoid build processes.
I avoid transpiling.
I avoid the new and shiny.
I test EvErYtHiNg.
I optimize for performance and quality.
I use my own work
I use open source to my advantage.
Don’t agree 100% with the third point though, as React Hooks and Function Components — the example he mentions — are a big step ahead to me.
What I don’t do is try to keep up with all other frameworks though — an impossible task — but focus on one of them (e.g. React) and go really deep in it. (And of course I’m also going all-in on VanillaJS, a very safe bet to make 😉)