The JavaScript ecosystem has reached a very interesting point in its history. There are members of the community overwhelmed by the learning curve required to start a new project and based on that they express JavaScript fatigue. There are also contradicting opinions announcing renaissance of JavaScript because it became truly general purpose language and dominated front-end development. So the question is, how to take advantage of all existing tools but at the same time change the first impression in a way that makes the following joke irrelevant:
Existing solutions
It turns out that this topic has been already explored by the JavaScript community members and the authors of popular frameworks. The solution that comes first to my mind is starter kit (aka boilerplate, generator or scaffolding). The idea behind this concept is to kickstart an initial project structure using all available best practices. It is also accompanied with the required tooling which allows to start working on newly created app seamlessly. I think Yeoman was the first one that popularized the idea on a larger scale. Nowadays, most of the framework vendors provide their own official project generators, e.g:
Command-line interfaces help to turn bootstrapping an app into a pleasant experience, but it is still not enough to keep it easy to maintain in the long run. Developers are left on their own to keep all configurations and dependent tools up to date. This problem multiplies when they own more than one project which shares the same setup. Fortunately, there is another pattern that can simplify maintainers life – reusable scripts. This idea boils down to moving all the necessary configurations and scripts to one single tool dependency. In most cases, it should be possible to accomplish all tasks using the default settings, but some customization is allowed, too. With all that in place updating all projects becomes a very straightforward task. Some existing examples that I found are:
If you found this idea interesting, you might want to find out more and see a related talk by Corey House from NEJS CONF 2017:
WordPress and Gutenberg
It has been already 2 months since I joined Gutenberg team to help develop the new WordPress editor. Historically it has always been easy to customize WordPress installation using themes and extend it with plugins. It won’t be any different in Gutenberg, where the main extension point that needs to be emphasized is creating new content blocks. However, the vision is much more ambitious in the terms of providing various opportunities for developers. You can check what is currently being discussed here.
When you take a look at Gutenberg repository you can discover that 70% of the code is written in JavaScript, which is a valid confirmation to what Matt Mullenweg said back in 2015 at the State of the Word:
I believe quite strongly that JavaScript and API-driven interfaces are the future of not just WordPress but the web.
Matt Mullenweg
Given the perception that kickstarting JavaScript rich projects can be a very challenging task, we need to find a way to make it easy for plugin developers to integrate with Gutenberg. I’m pretty confident that the answer greatly aligns with the following excerpt from the interview with the React.js Team about WordPress & Gutenberg:
If WordPress were to adopt React, it would make sense for it to also provide a zero-configuration build environment. We are happy to offer some of the packages we developed as part of Create React App for reuse: for example, our interactive build error overlay with editor integrations.
Dan Abramov
I would like to focus on the zero-configuration build environment part. WordPress will remain PHP based solution forever and its community already created an impressive native command-line interface which makes Create React App obsolete. WP-CLI allows to manage content, themes, plugins and a way much more. It also provides wp scaffold plugin command, which seems like a solid foundation to enable support for creating Gutenberg blocks. This would make extending new WordPress editor as easy as executing one command.
It’s important to make it clear that there is no need to use any advanced JavaScript tooling to extend Gutenberg. Riad Benguella did a great job explaining in his article how to build a few different plugins using only PHP and vanilla JavaScript. However, we should also consider providing reusable scripts that could allow to flawlessly incorporate more advanced JavaScript tooling like build step, code transpilation, linting, testing and so on.
Finally, if you also want to hear from Dan Abramov about the topic of bootstrapping and maintaining JavaScript projects, I recommend watching his very recent talk from the ZEIT day in Berlin:
Further reading
- Announcing vue-cli – from the official Vue.js blog.
- Create Apps with No Configuration – from the official React blog.
- The JavaScript Checklist Manifesto: You Need a Starter Kit – an article by Corey House.
- The Past, Present and Future of Angular CLI – from the official Angular blog.
- Tools without config – an article by Kent C. Dodds.
- Your last ESLint config – an article by Tomasz Netczuk.
- Why robots should format our code – an article by Artem Sapegin.
This post is brought to you by the new Gutenberg Editor.
Comments
9 responses to “Starter kit and reusable scripts”
Nice read, Grzegorz! Also, thanks for the mention of WPCouple’s interview of the React.js team. I happen to agree with a lot of you wrote up there. I’m sure you’ve taken a look at the Gutenberg Boilerplate — trying to help developers get started with Gutenberg development.
Something else I am working on, will share it soon.
Very interesting interview, I enjoyed reading it 🙂 We are also looking at wp-cli and its scaffolding feature to improve onboarding experience. See https://github.com/wp-cli/scaffold-command/issues/88.
Yes, I have been reading about it, actually Josh Pollock started the conversation following my Gutenberg-Boilerplate project. https://github.com/wp-cli/scaffold-command/issues/106
I have actually been using a Node base solution for this and will be open sourcing it this next week. To help kick start things in the community in relation to Gutenberg.
BTW Thanks for your explanation on ESLint + Prettier situation with WordPress
Super cool to have both PHP and JS solutions that will help developers coming from both worlds 🙂
Awesome, thanks for your support 🙂
Awesome, thanks for your support 🙂
[…] — Riad Benguella (@riadbenguella) March 16, 2018 The Gutenberg Development Course from Zac Gordon Starter kit and reusable scripts […]
I personally just use create-guten-block to create blocks in gutenberg.
It’s easy to use for extending gutenberg.
Talking about extending gutenberg I have one question to ask you Grzegorz.
It’s about MediaUpload. Few weeks ago I try to build a parallax block with MediaUpload but I came to the pb that is how to wrap the select image in div with data-parallax attributes.
Is there a way to get the select image of MediaUpload and wrap a div around it ?
For now I use the default parallax of cover image.
But I find interesting to build my own.
[…] Starter kit and reusable scripts for Gutenberg – the new WordPress editor (Nov 7, 2018) […]