Node module wars, complexity convection & plus minus next journaling

Welcome to the tenth edition of Growing the Stack!

Before we dive in I’d like to ask: what did you think of the links shared in the previous issues? What would you like to see more or less of? My inbox is open, I’d love to read your feedback!

This week we have a handbook on JavaScript module systems, an essay on business complexity (that’s highly applicable to software projects), and a new way to keep a journal.


📦 Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

Dan Fabulich wrote an extensive piece on the difference between JavaScript ES modules (the import syntax we’re getting used to) and CommonJS (module.exports).

As an occasional JavaScript library author I consider this one of the largest drawbacks of the ecosystem today. It’s frustrating how much knowledge you need about this stuff to write a module that works in environments.

Calling CJS from ESM and vice versa is possible, but it’s a hassle.

Here are the rules, which I’ll explain in more detail below:

[A very long list]

These rules are painful. Worse, for many users, especially newbies to Node, these rules are incomprehensible.

🔄 Complexity Convection

At some point, every software project (the article talks about businesses, but it applies here too) becomes too complex for many new users. Software gets bigger so it can continue to fit the (sometimes niche) needs for existing users. That means there’s room for a new, simpler, solution to pop up.

The essay uses website builders like Wix and Squarespace as a case study. While they’re very powerful today, the amount of features they’ve amassed over the years make them scary for new users.

First, let’s acknowledge that it’s really hard to build a simple product that’s also flexible enough to create whatever you want in the first place. There’s some inherent complexity here that is difficult to overcome and should be expected. The only way to create a truly DIY website builder is to constrain the design to the point where users have very little control. This is a difficult trade-off.

Second, as the company’s initial customers mature, they grow more complex needs. What was once a review blog for a cult favorite TV show turns into an e-commerce store that sells T-shirts with iconic quotes from the show. If the platform wants to retain its customers, it has to evolve with them and offer services like payments, storefronts, newsletters, etc.

📓 Plus Minus Next journaling

More and more resources point out that keeping a journal is a great way to grow as a developer, and as a person. I’ve tried it a few times but it never seems to stick. Anne-Laure Le Cunff shares her way of “Plus Minus Next” journaling.

Open your notebook, write the date at the top of a page, and draw three columns. At the top of each column, write “+” for what worked, “–” for what didn’t go so well, and “→” for what you plan to do next. […]

Then, fill it with events from the past week. I personally like to do this on Sunday evening, when it’s quiet at home, but some people do it on Monday morning to start the week on the right foot. Feel free to add professional and personal stuff in there. Whatever went well or made you happy goes in the first column; any negative events or inaction on your part in the second column; and all plans for the following week in the last column.

I like the idea of this approach because of its format. Three columns are a lot less daunting than a blank page.


In closing, here’s some proxy voodoo Christopher Pitt shared on Twitter to create magic getters and setters in JavaScript classes. Handle with care!