This is our 50th issue, so we’re doing a look back on what we’ve done right building up Mastering JS. Check out our archive to see our old issues!

We first published masteringjs.io in April 2019. Our hypothesis was simple: JavaScript developers are looking for simple, pragmatic solutions to everyday problems.

The last thing the world needs is yet another handwavey 80 page tutorial about how to build a to-do list with React, Redux, Webpack, Babel, Immutable.js, Helmet, Redux Saga, and 9001 other useless packages. We write about high value, transferable concepts that you can apply in a wide variety of paradigms and team compositions.

Thus far, our hypothesis has held up well. In the last 18 months, Mastering JS has grown from 0 to over 300k page views per month, and we have over 600 subscribers! Here’s 3 lessons that have been key to our success so far.

We don’t publicize this much, but the Mastering JS site is hosted as a public repo on GitHub. If you look through the commit history, you’ll see that almost all of the commits are new tutorials. Other than a few 5-10 line changes to add breadcrumbs or add CTAs to tutorials, we have barely touched our trivial for-loop-based build system since our initial commit.

That’s because readers don’t care too much about your build system. Writing is scary, but writing is also what gets you results. Tinkering with the build system is a waste of time unless it makes the end product better. Our rule of thumb is only spending 1-2 hours per year on the build system.

Once you start writing, how do you get people to read your content? One great way is to figure out what people are searching for, and tie your content into what people are already looking to read.

We’re big fans of SEMRush.com for figuring out the questions that developers are already typing into their Google searches.

Our build system compiles markdown tutorials into HTML, and then we serve the HTML files using Netlify. Netlify’s integration with GitHub is seamless in our experience: we almost never have to log in to Netlify. We just merge PRs into master and our changes ship to masteringjs.io. Setting up Netlify took us 10 minutes about 2 years ago, and we haven’t touched it since.

That means no downtime, no worrying about managing a database or VMs, and negligible devops headache.

If you’re looking to build an efficient business that takes minimal time and effort to manage, a static site is an excellent choice. If you’re building a blog or affiliate marketing site, there’s no reason why you shouldn’t just structure it as a static site.