A WordPress plugin is just JavaScript and PHP talking to each other through a documented set of hooks — and if you already know React, you already know 80% of how modern WordPress plugins are built. The block editor itself is a React application, which means the skills you use daily (components, hooks, JSX) transfer directly into the WordPress ecosystem.
Why This Is a Good Time for a JS Developer to Learn Plugin Development
WordPress still runs roughly a third of all measurable websites on the web, more than seven times the size of the next CMS. Underneath that scale sits a plugin ecosystem of over 63,000 plugins — and a real gap.
Only 5.8% of those plugins — about 3,649 out of 63,418 — ship a single Gutenberg block. Of those, nearly 69% ship exactly one block. The remaining 93%+ of the plugin ecosystem was written before Gutenberg existed, or has never engaged with it at all. That’s not a dead category. It’s a market that hasn’t caught up to where the platform actually went, which is exactly the kind of gap a JavaScript developer is positioned to close.
The reason for the gap is structural. Gutenberg is built on React, registered through the Block API, and configured with block.json. That’s a genuinely different skill set from the PHP-and-jQuery approach that built most of the existing plugin economy — and it’s why WordPress core’s own developer guidance in 2026 is blunt: learn JavaScript and React if you haven’t, because PHP-only plugin development is increasingly limited to legacy maintenance work.
What a JS Developer Already Knows, Mapped to WordPress
| What you already know | Where it shows up in WordPress plugin dev |
|---|---|
| React components & JSX | Block edit functions, registered via registerBlockType() |
| React Hooks (useState, useEffect) | @wordpress/element and @wordpress/data stores for block and admin state |
| REST API consumption | The built-in WordPress REST API, plus custom endpoints via register_rest_route() |
| Frontend state management | The new Interactivity API — a WordPress-native way to add frontend JS without hand-rolling jQuery |
| Command palettes / keyboard shortcuts | The Commands API (useCommands hook) for adding actions to the Cmd+K palette |
The one piece that doesn’t map from a pure React background is PHP. Server-side rendering, dynamic blocks that pull live data, and the Block Bindings API all still run through PHP. The realistic 2026 skill profile for a WordPress plugin developer is both: JavaScript and React for the editor experience, PHP for what happens on the server. If you’re coming from a Next.js background, that split will feel familiar — it’s not far from the client/server component split covered in Server Components vs Client Components in Next.js.
Building Your First Block: The Actual Pieces
A minimal Gutenberg block plugin has four moving parts, and every one of them will look familiar if you’ve shipped a React component before.
block.json— the manifest. It declares the block’s name, attributes (its props, essentially), supported features, and which scripts to enqueue. This is the closest thing WordPress has to a component’s prop-types definition.edit.js— a React component. It receivesattributesandsetAttributesas props (functionally identical to state and a setter) and renders what the editor shows.save.js— a pure function that returns the static markup saved intopost_content. For dynamic blocks that need live PHP data, this is replaced by arender_callbackon the server instead.@wordpress/scripts— the build tooling. It’s a pre-configured webpack setup maintained by the WordPress core team, so you’re not hand-rolling a bundler config; it’s closer to using Create React App than configuring Webpack from scratch.- Scaffold with
@wordpress/create-block. It generates a working plugin skeleton in one command — no manual webpack or Babel setup required. - Build one static block first. Something with a few attributes and a simple
edit/savepair, before touching dynamic rendering or REST endpoints. - Learn just enough PHP to register and render. You don’t need to be a PHP expert — you need
register_block_type(), a render callback, and basic sanitization functions. - Add a settings page or custom post type once the block works. This is where
@wordpress/dataand the REST API start doing real work together.
Once a block is registered, it behaves like any other block in the inserter, works inside core/group and core/columns layouts, and can be styled with the same theme.json design tokens as core blocks. If you’re also touching custom post types or REST endpoints for your plugin’s data, the underlying API is the one covered in WordPress REST API Explained: A Developer’s Guide.
Where PHP Still Matters
Three things in a typical plugin can’t be done in JavaScript alone. Registering the block server-side with register_block_type() so WordPress knows it exists. Rendering dynamic content — a block that shows the latest 5 posts, current weather, or live pricing needs a PHP render_callback, because save.js only outputs static markup. And security: nonce verification, capability checks (current_user_can()), and data sanitization on anything the block sends back to the server are PHP-side responsibilities that don’t have a JavaScript equivalent inside WordPress’s security model.
This is also the layer where a plugin and a headless WordPress setup diverge. If you’re building for a decoupled frontend instead of the block editor, the relevant reference point is Headless WordPress: Using WordPress as a Backend for a React or Next.js Site rather than block development specifically.
A Realistic Starting Path
If your plugin ships alongside a custom theme rather than a marketplace listing, the theme-building side of this workflow is covered separately in Custom WordPress Theme Development: Where to Start in 2026.