Starter kit and reusable scripts

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:

steps to writing js in 2017:

1. install node
2. configure babel
…
9. slowly beat the eggs into the flour and butter
…
35. open index.js

— I Am Devloper (@iamdevloper) October 10, 2017

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:

• Angular CLI
• Ember CLI
• Preact CLI
• Create React App
  
• Vue.js CLI

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:

• kcd-scripts
• react-scripts

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.