Javascript Chat Summary: August 13, 2019

Below is a of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Shared Core Dependencies

Slack

The Google Doc Agenda has much of the content of what was discussed, but as a summary:

Package/Bundle size for assets is a significant concern for frontend use as WordPress continues to expand javascript as a first class citizen in its ecosystem. Some examples where this surfaces are:

  • using wp.element on the frontend. It has a dependency on lodash which adds weight to page load.
  • implementing various components or blocks on the frontend (wp.components itself has significant size).

Some potential ways to resolve/improve this for not only frontend but also admin are:

Load externals via CDN.

Externals such as react, react-dom, lodash etc could still be registered but the source would be from CDN. The advantage here is with WP’s wide reach, it’s much more likely that client browsers will have cached the asset for visitors to WP sites. Currently that’s less likely because of every site hosting it’s own assets by default.

Action: @adamsilverstein is going to raise this in the hosting meeting to get feedback from there.

Size of packages.

Here, the focus is on how big are we willing to allow various bundles to get? For instance wp.components is 553kB minified.

  • should we start thinking about setting some comfortable limits on how big we allow bundles to get? (tools like bundlesize could help with that)
  • what ways can bundles be further reduced in size (example of @wordpress/server-side-render being extracted into it’s own package) – audit packages and see what other extractions/groupings can be done?
  • WP core supports script-aliases (enqueuing wp-components could actually enqueue X different files behind the scenes, all populating the wp global).
  • Reduce external dependencies: Example is lodash dependency removal from @wordpress/element. Much of the functionality of lodash can be implemented via native js.

Action:

  • It’d be good if those interested in javascript in WordPress start thinking through some of what’s been discussed in this item and contribute some proposals on how to improve things.
  • On the last item, removing lodash dependency from WordPress packages has been proposed. It’d be nice to get a decision on moving forward there. Please contribute your thoughts to the issue!

Agenda: Lazy Loading of Images and Frames

Slack | Trac | lazysizes library | Native lazy-loading for the web article

The discussion here centered around whether lazy loading of images is something that should be implemented in WordPress core and some initial ideas on what would be involved in doing that. Some highlights of the discussion (though no concrete decision was made):

  • opt-in for now
  • possibly implemented via add-theme-support
  • include for wp-admin as well (eg. Media Library)

Action:

  • continue to contribute to the trac ticket. Possibly explore landing something for wp-admin first.

Open Floor

  • @joyously asked about the status/possibility of updating jQuery (see trac ticket (slack convo). Nothing concrete from the discussion. Current blockers are the difficulty in resolving issues with the update and conflicts/failures with the customizer and media. Also reluctance exists to invest effort in something that may become obsolete due to changes in framework used (moving to more react heavy admin). Joy did note that the biggest problem existing right now are the flags raised by security scanners detecting the version number (author note: vulnerabilities in jQuery bundled with core are patched, but security scanners still detect it as a vulnerable version).

#javascript, #meeting-notes