The Module Pattern in Modern JavaScript: What Still Matters
ES modules made the old IIFE module pattern obsolete — but the thinking behind it is still the thing that separates a tidy codebase from a tangled one. Here is what I keep from it.
Backend engineering, system design, and the practical tradeoffs behind shipping software that holds up in production.
ES modules made the old IIFE module pattern obsolete — but the thinking behind it is still the thing that separates a tidy codebase from a tangled one. Here is what I keep from it.
EventEmitter, DOM events, React state, Redux subscriptions, RxJS — it is all one pattern wearing different hats. Understanding it once makes every one of them easier.
Classes and `new` are fine until you need to return different shapes, delay construction, or validate inputs before committing. Factory functions handle all three without ceremony.
Exporting a shared instance is fast to write and fast to regret. Dependency injection costs a few extra lines and pays them back every time you write a test.
We started with Stripe. Then legal needed a regional provider for one market. Without the strategy pattern this would have been a three-week rewrite. With it, it was a 200-line file and a switch in config.
A pure function does not reach outside itself, does not remember, does not surprise. It sounds austere until you have to refactor 2000 lines of side-effecty code at 2am.