Twenty Sixteen: Replace frontend jQuery usage with Interactivity API

[sergiomdgomes]

jQuery is a large library, at around 90KB uncompressed, or 30KB gzipped. To make matters worse, it's usually enqueued in the head, and thus becomes part of the critical path, delaying first paint and subsequent metrics.

Nowadays, the library is being enqueued for relatively little gain in many situations, given that the platform supports much of the functionality. Twenty Sixteen is an example of this, as it's relatively trivial to reimplement its functionality in native JS.

This ticket focuses on removing jQuery as a frontend dependency for Twenty Twelve - specifically the frontend, as for example in the Customizer jQuery is loaded anyway (and performance is a bit less of a concern there).

See also #54171 and #54172, which do the same for other themes.

Reimplement Twenty Sixteen frontend JS without jQuery, and don't enqueue it as a result.

Trac ticket: https://core.trac.wordpress.org/ticket/55126

[sergiomdgomes]

Please note that the above patch attempts to preserve IE 11 compatibility, by implementing some utility methods for missing functionality in that browser.

If we deem that IE 11 compatibility is no longer desirable (even in the context of a theme which used to be IE 11 compatible), the code can be made smaller by removing those methods.

[sergiomdgomes]

An alternative approach to preserving IE 11 compatibility is to use a wp_get_script_polyfill-based approach ​/ like Twenty Twenty One does. Thank you for pointing me to this, @gziolo!

This would keep the code clean and would prevent polyfills / helper functions from being loaded in modern browsers, but the downside would be that it would require bumping up compatibility to WordPress 5.0.

Hi, I did a quick manual test of the PR and when there is no menu setup, I am seeing the following:

functions.js?ver=20220209:41 Uncaught TypeError: Cannot read properties of null (reading 'querySelectorAll')
    at forEachNode (functions.js?ver=20220209:41:22)
    at initMainNavigation (functions.js?ver=20220209:48:3)
    at functions.js?ver=20220209:96:2
    at functions.js?ver=20220209:293:4

Once a menu is assigned to the primary menu location, the JS error is gone, but the keyboard navigation is not working: I can not open submenu items with the keyboard only.

[flixos90]

@sergiomdgomes Given that WP core has dropped IE11 support, I would think we don't need to support it here anymore. I would think WP core includes WP core themes in that definition?

Regarding your suggestion of relying on wp_get_script_polyfill, if we still wanted to be a bit more graceful here, we could potentially use it, but only if the function exists in the core version used. That would essentially mean either the site owner has to update their WordPress version when they update the theme, or they lose IE11 support, which is a tradeoff to make. I personally think that's still a half-baked solution though, and I would prefer to follow core's decision to drop support for IE.

@desrosj Can you provide any insight what the decision to drop IE support means for themes in this regard?

Thank you for taking a look, @carolinan and @felixarntz! The issues you mentioned should now be fixed.

As for IE11, I'll wait a bit longer for a consensus before making any changes on that front.

[sabernhardt]

According to the ​post about dropping IE11 support:

No changes will be made to any of the default bundled themes as a result of this plan. No code related to IE11 support (or any other browser that may have been supported when each theme was released) will be removed from default themes.

Twenty Fifteen and earlier themes were built to support older IE versions, too, and still have the conditional statements.

[sergiomdgomes]

Hey folks! 👋 It's been a while since the last comments 😅

I'd like to revive this effort, as twentysixteen still sees a lot of usage, and it would be nice to drop jQuery on it.

@flixos90: What do you think we need to get the ball rolling again here?

Rebased on trunk.

[karmatosed]

@sergiomdgomes this is still with you as assigned, are you working on this or do you wish to have it unassigned. My expectation is the later but I didn't want to remove you from it yet as you seemed keen on completing this.

We have a lot of thoughts on this and I would love to get to some resolution on the ticket over have it sat because this is quite an older theme now. What are everyone's thoughts now some time has gone by? cc @sabernhardt and @flixos90.

[sergiomdgomes]

Hey @karmatosed, thanks for reaching out!

I'm happy to either do further work on this or to hand it off to someone else who's keen on seeing it finished.

It doesn't seem like there's a lot of interest from the community, however, so perhaps it is best to simply drop this change and close the associated PR?

[karmatosed]

Thank you @sergiomdgomes my own reflection is aligned with your last point that due to the older nature of this theme I would recommend in this case not going any further. That doesn't mean it couldn't be something to explore at a later date, but it does mean for now I would recommend only focusing on bugs not enhancement or foundation changes.

Aligned to that, I am going to add the close keyword as a recommendation. This absolutely could be something to discuss if doesn't fit though. Thank you everyone who has collaborated on this.

[karmatosed]

I am going to close this for now, thank you everyone for your collaboration.

[karmatosed]

Reopening and assigning to @flixos90 as discussed.

[karmatosed]

@sergiomdgomes and @flixos90 I have added needs refresh on this as whilst I understand there might be appetite to work on this, it will need refreshing most likely due to time.

[sergiomdgomes]

@karmatosed Thank you! In fact, given how long it's been, we may want to consider scrapping this code and restarting the work here. We could reduce and clean up the implementation significantly if we don't try to maintain compatibility with IE11, as I did in the above pull request.

But then again, even though we don't support IE any more, it may be worth preserving compatibility in older themes like this one.

In any case, at the very least this will likely need a rebase!

[flixos90]

Per https://core.trac.wordpress.org/ticket/61027#comment:10, I'm going to update the purpose of this ticket slightly: With the Interactivity API available, we should focus these efforts on using the Interactivity API instead of vanilla JS as a replacement for jQuery.

As such, this will need a refresh. Please read the linked comment on the overarching ticket for additional context.