Deciding What Development Tools to Teach in my JavaScript for WordPress Master Course

Since the beginning of 2016 I have been working on my JavaScript for WordPress Master Course.  In the first part of this course I have a section on JavaScript Development Tools.

For the past few moons I have been trying to figure out exactly what JavaScript Development Tools to include in this section and in what order to cover them. It has been quite a process figuring all of this out, so I thought I would share a bit about it.

First Off, What Tools Do We Include?

The first thing I had to figure out what exactly what tools I should include.  Here is the list I finally came up with:

1. Coding Environments
2. Command Line Tools
3. Code Repositories
4. Task Runners
5. Transpilers
6. Error Linting and Debugging
7. Testing

For the most part I had a pretty good idea of what to include from the beginning.  However, it did take a while to figure out the best order.  I’ll discuss that at the end, but first I thought I’d share a bit about the specific tools I chose from each type of tool.

Coding Environments

When I taught at Treehouse I used Sublime Text for all of the WordPress Development videos.  However, since then, Atom, from Github, came out and I have grown to like it for it’s sleek feel and powerful extensions.

In my informal surveying of WordPress developers, most folks use one of these two coding environments.  However, a few folks do use IDEs (Integrated Coding Environments) and I knew I had to include one in the course.

For the IDE, I chose WebStorm, the JavaScript IDE from the folks at JetBrains, who make the PHP IDE, PhpStorm.

In my course I primarily use Atom with a number of my favorite packages installed.  I do not really go into Sublime Text because it is so similar to Atom and because my course advisor, Wes Bos, has a book on Sublime Text.  I go into WebStom a bit to show what an IDE can offer and then refer people to Know the Code from course advisor Tonya Mork, who gets deeper into developing with an IDE.

Command Line Tools

One of the most important lessons I learned from doing the Week of REST Bootcamp with my friends at Human Made was that it is important to cover basic command line skills before getting into using other tools: navigating directories, understanding how commands and options work, etc. So I do a bit of that to start.

Luckily you do not need to know too much hard core Unix to use JavaScript Development tools, which is a good thing.  However, when installing and customizing tools it does help to have an understanding of the where different configurations are located and how to configure them for easier use.

When it comes to accessing the command line in the course I like to use Atom with the Terminal Plus Package.  However, I highly recommend folks check out the free Command Line Power User Course from Wes Bos for tips on how to use iTerm on the Mac with ZSH, Z and other goodies.  Although I do not explain how I do it in my course, I do have a customized command prompt 😉

Code Repositories

Two important code repositories stand out for JavaScript Development Tools: NPM and Github.

While npmjs.com is the go to repository for loading modern JavaScript libraries, it is also a development mindset in and of itself.  Rely on both libraries and small reusable bits of code from other developers.  I kind of think of it like as plugins are to WordPress so NPM packages are to modern JavaScript development.

In the course we use NPM quite a lot and really try to get folks used to using it as part of their development flow. I do not go into Github too much, just enough to clone repositories and manage your own projects a bit.  From there I recommend folks checkout the official Try Git interactive tutorial.

Task Runners

Task Runners help you run and manage other command line tools.  Three options clearly stood out for talking about in this course: Grunt, Gulp and Webpack.

In our last native JavaScript project of Part I, we use Grunt.  I chose this because it was the earliest of the bunch and has more similar configuration to Webpack in my opinion.  Although we do not use Gulp, I do show how you can do the same things with Gulp as we do with Grunt, just a little differently.

I don’t get into Webpack until later in the course when we get into JavaScript Libraries and Frameworks in Part II.  I figured it was a good idea to switch to this since most React developers prefer React from what I have gathered.  I also want people to have the experience of switching task runners, since being able to adept and switch between tools is an important skill set for a JavaScript developer.

In terms of what the task runners are doing, it generally breaks down to some combination of bundling files, minifying, linting, watching for file changes, and running a local server with live reloading on file changes.

Transpilers

The section on Transpilers exists primarily to discuss Babel, which we use to convert new JavaScript features into code that current browsers will understand.  Now that JavaScript releases new features on an annual basis, having a tool like Babel is essential for being able to let us use new JavaScript in our code and still have our apps work across environments.

In a later section in the course we go over a few of the features of ES6 and work on rebuilding our custom app, VanillaPress with ES6 conventions.  However, next year, there will be ES7 features and the year after that ES8.  I do not plan on updating the course with every new feature of JavaScript at this point, although I will cover the basics and links to resources like Wes Bos’s ES6 course that covers new features in depth.

Error Linting and Debugging

I love error linting tools 🙂  Something about knowing as I code if I’m making any mistakes saves some time, particularly searching for those silly misspellings and similar type things.  I explain the relationship between JSLint, JSHint and ESLint and show how you could use each with our task runners.  In terms of what to choose, I generally agree that ESLint is a good way to go.

For debugging I show how you can use Chrome Developer Tools to insert breakpoints and walk through your code for debugging, although we also get plenty of experience using console.log for simple stuff.  Although I don’t go into depth with it, I do mention that you can also do this internally with WebStorm.

Testing

This was the hardest section for me to do, mostly because I was not sure what testing framework to pick.  Most developers I talk to in the WordPress ecosystem do not take a Test Driven Development (TDD) approach in their projects.  However, I want folks who take my course to have a good foundation as a JavaScript developer outside of the WordPress world so I did feel it was important to at least get folks familiar with how testing works.

At first I thought to use Jasmine since it was one of the older and simpler testing frameworks.  However, a lot of folks like Mocha.  In the end, I decided to go with Tape, in part due to JS education guru, Eric Elliot’s, article on why he uses Tape over Mocha and in part because I felt it was the simplest of the bunch for someone new to testing.

In Part II of the course I will mention a few other testing frameworks as well, since some framework communities have preferred testing frameworks.

Now, What Order to Teach All of This?

In the end I settled on the order above for covering these different tools, however, it took me a while to settle on this order.

Earlier on I had covered Linting quite early and tried to save Git till the very end.  I also did not have command line tools in it’s own section originally and just talked about it in the Coding Environments section.

In fact, originally most of these sections were part of one big Task Runner or Coding Environments section since you commonly use most of these tools through your task runner or coding environment.

Learning about Tasks Runners before learning about the other tools does not give you much to do with a Task Runner, though.  For that reason we start off with a basic configuration for the Task Runners with a number of tools that we don’t get into until later sections.

This follows a teaching convention of dropping folks into a working project that might not make sense on a micro level but is helpful for understanding macro concepts.  Ultimately I felt this approach worked better than trying to talk about each tool individually before combining them in with a task runner, especially since it would mean running all the tools just from the command line to start, which is not really a common practice.

Did I Miss Something?  Have Opinions Otherwise?

My primary occupation is as a teacher.   I have a development background but do not code JavaScript applications day in and out as my primary gig (although that does appeal to me sometimes).

For this reason I rely a lot on people in the community who work with these tools regularly and encounter limitations and strengths of these (and other) tools in different types of environments and projects.  So, if you have thoughts on these different tools, as well as ones that I did not mention, please leave a comment and share your experience!

Want to Learn More?  Enroll in the JavaScript for WordPress Master Course

If you are newer to all of this I would highly recommend you enroll in my JavaScript for WordPress Master Course, where I go in depth into everything I talk about above, plus a whole lot more!