Over the summer I published a series on coding tactics: the everyday craft of ifs, loops, and the reasoning behind them. Eight posts, one thesis, best read in order. This is the map.

The last post argued that break, continue, and labeled jumps are structured goto — disciplined jumps that keep code linear. Two ordinary language features are jumps in disguise: yield, which suspends a function and later resumes it in the middle, and throw, which leaps across stack frames to a waiting handler.

In 1983, Tom Duff needed to copy memory into an output register faster than his compiler could manage, and wrote the most famous abuse of switch in the history of C. I ported his device to JavaScript and raced it against the plainest possible loop — and the verdict changed with the engine, the engine’s version, and the CPU underneath.

“Go To Statement Considered Harmful” is one of the most-quoted titles in programming, and almost nobody reads past it. The argument underneath is narrower than the slogan it became — and the reflex it bred, avoiding every jump, produces code worse than the goto it was meant to replace.

We spend a lot of effort making code run and almost none making it argue. An invariant is the cheap proof tool that turns “I think this loop is right” into “I know it is” — and we already use them without naming them.

Tests are a cornerstone of modern development, and somewhere along the way we started treating a green suite as proof. It isn’t: it tells you the cases you thought of still pass, not the ones you didn’t. That confusion was always with us — and it matters more now that an AI agent might be the one chasing the green.

The third article in the series, still on conditions. The previous installment was about their shape — merging ifs, factoring shared decisions, dropping checks that earn nothing. This one reaches for the other lever: the algebra of the conditions themselves — not a textbook tour, just the handful of transformations I lean on in everyday code.

The second article in the series. The first was about control flow; this one stays with the same tactic — reshaping code — one layer down, at the condition. Here: merging ifs, factoring shared decisions, and dropping checks that earn nothing. The Boolean algebra of conditions — De Morgan and friends — is a different lever, and gets its own installment next time.

You can find plenty of articles about design — where and how to use SQL, NoSQL, message queues, Redis, VMs, and so on. Almost nobody writes about tactics: the actual coding. It borders on style, but it isn’t just style. This is the first article in a series on tactics I use day to day. Highly opinionated — I don’t expect you to follow it. Look, chuckle, think about it, and use what you like.

How a slow first cut, a surprising benchmark, and a tour through V8’s regex engine landed five small libraries on npm that still earn their keep a decade later.

As programmers we rarely have a luxury to write a project from scratch. Usually we have to retrofit existing projects with all cool things we need. If a new component, or a library we want to use introduces new concepts that bleed outside its boundary, we have a “culture clash”, when old code is unaware about new concepts have to work with it anyhow. Sometimes the clash is so bad that we have to give up on using shiny new things, or have to significantly rework their code, which requires time and efforts we cannot afford.

Incomplete objects allow us to concentrate on important properties of JavaScript objects ignoring the rest: we don’t need to specify every single property, and we can deal with cyclical graphs.

Incomplete arrays is a complimentary feature to inspect only the first few array items.

Both features are very useful for patterns, and heya-unify provides rich facilities to automate creating incomplete objects: they can be marked up explicitly on per-instance basis, recursively with a special utility, and we can specify how to deal with objects by default during unification.

Custom unification in heya-unify allows us to deal with our specific objects in JavaScript, create unification helpers, and even custom logical conditions. It is there to bridge unification with our existing projects.

Looking at the 1st part and the 2nd part of the series is recommended before diving into details.

Custom unification

Unification makes comparing simple objects a cinch no matter how complex they are, and we can easily apply it to JSON-like trees as is. Additionally heya-unify “knows” how to unify other common JavaScript objects: dates, and regular expressions. Yet in Real Life™ we are faced with complications like that:

Unification for JS introduced heya-unify — a practical mini library to leverage unification in JavaScript. This post explains when it makes sense to use unification, and gives practical examples of how to use it.

When to unify?

Below is my laundry list for unification. As soon as I see a project, which deals with items on the list, I investigate if it makes sense to use heya-unify .

Unification is a very interesting programming tool. Originated from logical programming (its the foundation of Prolog) and used in functional programming (e.g., Haskell) it helps to compare objects for equality, identify known patterns, and reassemble results differently.

Wikipedia gives a somewhat complex definition of unification, but many people see it as an extended equivalence comparison, a pattern matching tool, and some even find parallels with XPath queries, CSS, and even jQuery, all operating on regular objects. See it for yourself.

ClubAjax invited me to speak about technologies behind Heya , specifically about code generative solutions behind heya-pipe . Pipes are built on a firm foundation of functional programming (FP), and it allows us to use a wide range of technologies to optimize their performance including generating code on the fly (code generation AKA CG).

As soon as we are talking about CG, the first question to ask is: “How to debug such code?”. Heya provides answers for that too. But no spoilers.

I spoke at ClubAjax about optimization of modern web applications. Usually I speak about theoretical matters, but this time I decided to go practical. This is a huge topic and it was blogged/debated/presented to death, including my Improving performance… . Yet I decided to add to it after realizing that many things have changed in last years, including how we build web applications. I concentrated on technical aspects completely bypassing all other areas (e.g., a psychological angle).

Once I wrote a blog post On JavaScript, EDP, and 0ms timeouts , which discussed a "smart" trend to pepper code with timeouts of … 0ms: setTimeout(f, 0). Authors of those "programming pearls" genuinely believed that this code reschedules a function call to the next available time slice after the code that set the timer was executed without introduction of a delay (after all it is 0ms!). In reality a typical delay was 10-20ms. With new generation of browsers it starts with 4ms and jumps to 1000ms for non-current/hidden tabs.

Finally: my open source JavaScript project DCL is built on ideas described in this article. Available for node.js and modern browsers, it implements OOP with mixins and AOP at "class" and object level. Read documentation and background articles on www.dcljs.org , clone its code on github.com/uhop/dcl , and follow @dcl_js .

Once again I was invited in ClubAjax to speak about JavaScript. This time I did a presentation based in part on my previous blog post OOP and JS . Slides and talk revisit OOP, mixins, AOP, chaining, and other related techniques I discussed in my blog. Of course, OOP deficiencies were discussed at length too. I suggest to look at slides and read the blog post - it will give you a better picture.

Finally: my open source JavaScript project DCL is built on ideas described in this article. Available for node.js and modern browsers, it implements OOP with mixins and AOP at "class" and object level. Read documentation and background articles on www.dcljs.org , clone its code on github.com/uhop/dcl , and follow @dcl_js .

Almost any Java programmer, who starts to study JS groking its OOP facilities and a dynamic nature of JS, thinks that they can be greatly improved and starts its own OOP library/helpers. Majority of them left forgotten when their authors learn more and more details and patterns of JS, yet some grow to fruition and being marketed. This article is dedicated to such people.