Exploration to support Modules and Import Maps

As the web continues to evolve, so does our approach to building and managing JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. in WordPress. Looking to the future, a collaborative effort is underway to explore native support for modern JavaScript modules and import maps within the WordPress ecosystem. This exploration is geared towards enhancing the developer experience by embracing the capabilities of modern browsers.


JavaScript modules have transformed the way developers write and organize JavaScript code. They provide a cleaner and more modular architecture, making code easier to maintain, test, and reuse across projects. Today, the vast majority of web browsers offer native support for JavaScript module syntax, offering performance benefits and unlocking new possibilities in how we develop and manage client-side scripts.

In this realm, it becomes essential for WordPress to keep pace with these advancements and start experimenting with the addition of native support for registering and enqueueing JavaScript modules — including generating an import map directly within WordPress.

The primary objectives of this initiative are:

  • To leverage the native JavaScript module system available in modern browsers.
  • To streamline the development process in WordPress using JavaScript modules.
  • To determine the most efficient and effective methods for handling dependencies and optimizing loading times.

Prior discussions and experiments

The following links are some preliminary discussions and experiments that touch upon JavaScript modules and related approaches to script loading within the WordPress ecosystem:

However, the journey toward a modern, module-friendly WordPress is still in its early stages, and the next steps will be instrumental in deciding how best to integrate module support in a way that benefits developers and users alike, without disrupting the stability and familiarity of the current WordPress experience.

The experimentation phase

The current plan involves conducting initial experiments within the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. By exploring within this semi-contained environment, contributors will gain practical insight into constructing modules that are compatible with WordPress’ existing infrastructure. This experimentation will help make informed decisions on several fronts:

  • Deciding whether to extend the existing wp_enqueue_script function or introduce a distinct APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (like wp_enqueue_module).
  • Evaluating whether to maintain dependencies on the server vs relying completely on the client’s native resolution.
  • Establishing best practices for module identifiers, dependency registration, inline modules, preloading optimizations, and more.
  • Assessing integration challenges and ensuring backward compatibility.

It’s worth noting that while the experimentation will be kicked off using a separate API for simplicity’s sake, this doesn’t necessarily predetermine the final form of the proposal.

After conducting experiments, collecting insights, and incorporating the feedback received, an update that will outline a more specific implementation plan will be provided.

Potential enhancements such as dependency auto-detection and additional performance optimizations could be incrementally introduced later on.

Your input is important

Your perspective is crucial to the success of this initiative. Whether you are a plugin author, theme developer, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contributor, or anyone interested in the future of JavaScript in WordPress, join us in shaping a robust and forward-looking solution.

Get involved!

You are invited to participate in this exploratory phase and contribute your ideas, concerns, and suggestions. Below are some prompts to get the conversation started:

  • How do you currently manage JavaScript modules within your WordPress projects?
  • What challenges have you faced with the existing script enqueueing system?
  • In what ways can native support for JavaScript modules improve your development workflow?
  • Are there specific use cases or scenarios where you feel this proposal could greatly benefit you or the WordPress community?

Please share your thoughts in the comments below, on Trac, or participate in the ongoing discussions and experiments on GitHub. Your engagement is invaluable to work together toward a more modern, module-friendly WordPress.

Thanks to @youknowriad, @bph, @annezazu, @juanmaguitar, and @webcommsat for reviewing this post, and to the many contributors who have participated in the discussion around this enhancement already.

#core, #core-js, #javascript, #performance