JavaScript for WordPress Developers: Packages and When to Use Them

JavaScript-Libraries-Featured-Image
Quick answer: For a new WordPress block or editor extension, start with WordPress’s own JavaScript packages and the @wordpress/create-block scaffold. Use @wordpress/element for component UI, @wordpress/components for editor controls, @wordpress/data for WordPress stores, and @wordpress/api-fetch for REST requests. Add an external library only for a specific function these packages do not provide.

A WordPress developer does not need a long list of unrelated animation libraries. The first question is where the code runs: inside the editor, on the public page, or in both. That choice determines which WordPress APIs, script dependencies, and build tools you need. The Block Editor Handbook’s JavaScript guide is the starting reference.

Choose the package by the job

JobWordPress resourceWhen it helps
Start a custom block@wordpress/create-blockScaffolds a plugin with the files and build setup for a block.
Build component-based UI@wordpress/elementProvides utilities built on React for components and elements.
Add editor controls@wordpress/components and @wordpress/block-editorUse WordPress controls and block-editor APIs instead of recreating common UI.
Read or change editor state@wordpress/dataWork with WordPress stores, selectors, and actions.
Call the WordPress REST API@wordpress/api-fetchMake requests using WordPress’s API conventions and middleware.
Translate interface strings@wordpress/i18nMark strings for localization and handle translated messages.
Compile and check a project@wordpress/scriptsRun the standard build, development, and lint commands used by block projects.

These are packages and development tools, not seven interchangeable frameworks. Pick the few your feature uses. WordPress’s package reference lists their APIs and the script handles available in WordPress.

Build process or plain JavaScript?

For a new block with JSX and modern imports, the official create-block scaffold supplies a build setup using wp-scripts. Use its development command while writing the block and its production build before deployment. The scaffold is a starting point, not a substitute for testing the block in the editor and on the front end.

For a small editor enhancement, a build process may be unnecessary. WordPress lets you use packages through the global wp object. In that case, declare the matching WordPress script handles when enqueuing your file; otherwise your code may run before its dependencies are available. The handbook shows a block-variation example with wp-blocks in the dependency array.

Load code in the right place

An editor sidebar control does not belong on every public page. A front-end interaction does not automatically need to load in the editor UI. WordPress’s asset-enqueueing guide distinguishes code for the editor interface from code used by block content. Follow the relevant hook or block metadata and check both contexts after changes.

If your build uses WordPress packages, do not accidentally ship duplicate copies of those packages in your bundle. WordPress’s dependency-extraction tooling can map package imports to registered script dependencies. Inspect the generated asset file and the page’s loaded scripts when diagnosing a conflict.

When an external library makes sense

An external library is appropriate when the feature has a clear need, such as a specialized chart or interaction. Before adding one, check that it is maintained, has a suitable license, works with your supported browsers, and does not duplicate a WordPress or browser feature. Test keyboard use, reduced-motion preferences where animation is involved, and the effect on page weight.

For an existing theme or plugin, keeping a working jQuery feature may be sensible. For a new block, adding jQuery merely because it appears in an old tutorial creates another dependency without a clear benefit. The same applies to full-screen scrolling or animation packages: the effect should solve a user problem, not just decorate the page.

A practical starting path

  1. Describe the feature and decide whether it runs in the editor, front end, or both.
  2. Check the current WordPress package reference for an existing API.
  3. Use create-block for a new block, or enqueue a small script with explicit dependencies.
  4. Test saving, reloading, keyboard use, and the public page.
  5. Add a third-party library only after you can name the missing capability.

Frequently asked questions

What JavaScript library does WordPress use for blocks?

The block editor uses WordPress packages such as @wordpress/element, which builds on React, along with packages for block editing, controls, data, and more. Use the packages needed for your feature.

Should I use React directly in a WordPress block?

Start with the WordPress block-development tools and @wordpress/element guidance. The official create-block scaffold sets up the build process and package dependencies for a new block.

Do I need a JavaScript build step for WordPress?

A modern block using JSX and imports normally uses a build step. A small script can use WordPress packages through the global wp object without a build step if you declare its script dependencies.

How do I call the WordPress REST API from JavaScript?

The @wordpress/api-fetch package provides a WordPress-oriented wrapper and middleware for REST requests. Review its current documentation and the endpoint permissions your feature needs.

Is jQuery still needed in WordPress development?

Existing themes and plugins may use it, but a new feature does not require jQuery by default. Choose it only when it solves a concrete compatibility or implementation need.

How do I load JavaScript only in the block editor?

Follow the WordPress asset-enqueueing guide for editor UI scripts, and declare their dependencies. Code for block content and code for the editor interface use different loading contexts.