With Gutenberg, we made the choice to use JavaScript heavily in order build the UI of the editor, not because we’re nerdy hipsters but essentially because it is the perfect fit to address the UI and UX challenges of a heavily interactive interface in the browser.
As a consequence, we’ll start to see a shift in the WordPress community. Plugin developers are required to use JavaScript more in order to extend the editor. Most blocks need to be developed using this technology. The modules Gutenberg provides (Components, data module, i18n, apiFetch…) will also encourage developers to extend other parts of WP-Admin in JavaScript. Instead of writing HTML/CSS screens from scratch and rendering them from the server, developers are able to bootstrap and prototype fully accessible new screens in WP-Admin by composing these components in a small number lines of code.
Learning process
But when we talk about JavaScript in general, we can think of two different approaches:
- Using untranspiled ES5 code.
- Leveraging build tools like babel, webpack… and write ESNext JavaScript code (ES2015 and more).
Most plugin authors are already writing ES5 code in their PHP rendered UIs or in their themes and the Gutenberg APIs can continue be used this way. But our role as Core Contributors should also be to educate people to get on the ESNext train as it can be a huge improvement in terms of productivity and development experience.
That said, learning ESNext and all the tools involved in the process can be a bit overwhelming if you’re coming from a PHP background without any prior heavy JavaScript experience. To help with the transition, the WordPress community started working and providing tools (Like Create Guten Block).
Using these tools can feel like “magic” though. It works but as a developer, you don’t really know what’s happening behind the scenes. Debugging code can be a challenge if you don’t understand how everything fits together.
For this particular reason, I created the WordPress JavaScript Plugin Starter. Unlike other starters thought, it’s written as a tutorial. Each commit of the repository is a step further in the setup and the README goes through each one of these steps and explains it.
Hopefully, At the end of the day, you’d be able to use the starter as a way to start a WordPress plugin but also master how this plugin works and how all the tools fit together to ship a production ready JavaScript plugins.
7 responses to “Let’s start building JavaScript plugins for WordPress”
We develop custom plugins since years without any local servers or node or whatever other tools or libraries.
We use a subdomain on customers $5 PHP/SQL webspace and develop there directly via Notepad++ and a mounted driveletter via SFTP.
So we can’t and won’t write any “compiling” code for Gutenberg, because we don’t have the unpaid time and also no motivation at all to change everything for a way too complex approach which even has less features for our clients than the current simple PHP/jQuery plugins.
Without developers WordPress is nothing. Remember that.
I feel your pain, I’m really sorry to hear that and I really hope you’ll be able to catch up at some point. WordPress needs to evolve, like any other technology, if it doesn’t evolve, it’ll die. I don’t want to enter a long discussion here about why this is a necessary change as this has been discussed for long in several posts and Core meetings.
It’s also important to note that developers these days do not start by learning PHP like we used to do in the past. Most developers learn JavaScript as their first language and this change will make WordPress accessible to a whole new generation of developers. It is a big transition for developers only familiar with PHP and I understand that it takes time and investment. Our role as core contributors is to help in this transition and that’s why I wrote this tutorial (take a look, maybe it’s not as complex as it seems).
“If you don’t like change, you’re going to like irrelevance even less.”
As your target group seems to be “a whole new generation of developers”, simply fork WordPress to “GutenPress” or similar and leave the current core for the way bigger generation of existing developers who made WordPress what it is now. Or just add it to wordpress.com, as it has been done with Calypso.
I can understand your point of view completely, but the current concept with build tools etc. collides with most real world WordPress usage and the simple & quick maintenance & fix possibilites. Many “part time developers” and “hobby webmasters” will stop to add any code to installations because they would need a dedicated dev-machine instead of simply using any PC anywhere with a quick download of some random SFTP-client. Not everybody works in an office and has one “own” machine. E.g. I work from random internet cafes around the world.
And as a sidenote, another problem is the new debugging. From reading hundreds of github issues and wp.org support questions, there seems to be no real exception handling, always lots of “undefined this and that” in browser console, each and every possible fail has to be taken care of. There should be not a single breaking js as it influences the whole page.
And as second sidenote: Writing meaningful quotes does not help anything.
Riad, I really appreciate this contribution – just like lots of other WP devs out there, open to invest in the great WP tech switch.
I guess the comments above by Webdev are the frustrated last cries of one specific kind of WP workers – and this type will shortly “die out”, metaphorically and financially, simply because they’ll stop being competitive. But I wouldn’t call these internet café guys serious WP developers, and they’re obviously not a majority.
“WordPress needs to evolve, like any other technology, if it doesn’t evolve, it’ll die.”
Sure, but we know what this sentence really means: business and money. WP needed Gutenberg simply because of the competiton – not because it so wanted or so needed to evolve. And that’s a cruel world, and this business decision now forces thousands and more developers to learn new technologies – from this point of view I can understand the frustration.
Learning React and including Webpack in my everyday tech stack wasn’t amongst my plans for 2018 and 2019 either. But I like the idea to make WP win the competition with an in-built, awesome content builder/editor, and I also like the idea that I’ll be a better programmer, and like this, more competitive myself.
I also like the idea that there will be less WP specialists. This will bring us more jobs, more money – so, generally, I think those who are open to this change will win on the longterm.
And your plugin starter looks to be a precious helper of the transition.
So – thanks again!
Thank you for the great post 🙂
After going through all “stages” of your tutorials, I genuinely appreciate your effort to create this tutorial. Using GitHub commits as chapters is a great idea and presented the relatively complex topic of writing plugins using JavaScript quite well.
Since this article is several years old, without any updates in GitHub, I would think that it is not up to date any more. The problem seems to be that the syntax of the “edit” and “save” functions in the “index.js” (“commit 6”) as shown below:
`
> wp-js-plugin-starter@1.0.1 start C:\wamp64\www\wp-content\plugins\wp-js-plugin-starter
> parcel watch src/index.js
× C:\wamp64\www\wp-content\plugins\wp-js-plugin-starter\src\index.js:11:11: Unexpected token (11:11)
9 |
10 | edit: function() {
> 11 | return Hello Editor;
| ^
12 | },
13 |
14 | save: function() {
`
This post is a year old post and I’m reading it now!! But, I’ll check your Github repository and try to build something from it.
Also, I’m very happy after reading this post because of newbies are learn the latest knowledge from either paid courses or by searching itself and they have such amazing content.
And This post is one of them. Thanks for sharing.