DEV Community: JSLab

Line-anchored output and the filter chips

JSLab — Mon, 02 Nov 2026 00:47:28 +0000

JSLab feature notes: one docs page, explained. Today: The output panel.

JSLab is a JavaScript & TypeScript scratchpad for macOS. You type, it runs, and the output panel fills up. This note covers the two things that make that panel readable: every row knows its line, and four chips filter what you see.

Every row knows its line

Each result, log and error appears as a row tagged with the line that produced it. The link works both ways:

Hover a row and its line lights up in the editor.
Put the caret on a line and its rows light up in the output.
Click a row's line number and the caret jumps there.

Try it with the example from the docs:

const width = 12;
const height = 5;
width * height;
width + height;
Math.hypot(width, height);

Three rows: 60, 17 and 13, each tagged with its line. In a five-line file that's a nicety. In a two-hundred-line one it's the difference between reading output and searching for it.

When you re-run, rows whose values changed tint for a moment, so you see what your edit affected. Rows on the line you're typing on don't flash.

The four chips

Above the output sit four filter chips: All, Results, Logs and Errors. Each shows a live count, and the counts stay visible at zero, so "Errors 0" is a thing you can glance at.

What counts as what:

Results: values from Auto Log and magic comments.
Logs: console.log, and also console.info and console.warn.
Errors: thrown errors, plus stderr and a failed console.assert.

Here's a run that throws: 9.99 is a result tagged :9, the error is tagged :4 with its stack frames, and the chips read All 2, Results 1, Logs 0, Errors 1.

(L10:1)." width="800" height="500">

The same filters are commands: Output: Show All, Output: Show Results, Output: Show Logs and Output: Show Errors, in the command palette (⇧⌘P).

Two small things

Text written with process.stdout.write gets its own rows, without a line number, since no single line produced it.
Right-click empty space in the panel for Copy All, which copies every entry the current filter shows. Filter to Errors, Copy All, paste into an issue.

Turning it down

Both display options live in Settings → Appearance: Output Highlighting colours values by type, and Output Line Numbers shows the source line beside each row. Both are on by default.

JSLab launches Nov 15. The full page, with a runnable example for each section: https://js-lab.app/docs/output

Log inside a loop without touching the code

JSLab — Sun, 01 Nov 2026 18:59:32 +0000

Loops are where console.log goes to multiply. One log per pass is fine for 8 passes and useless for 8,000. Here are the techniques I reach for, from "edit the code" to "don't touch it at all".

The loop we'll debug finds spikes in a list of readings:

const readings = [12, 15, 11, 40, 14, 13, 90, 12];
const spikes = [];

for (let i = 0; i < readings.length; i++) {
  const delta = readings[i] - (readings[i - 1] ?? readings[i]);
  if (delta > 20) spikes.push(i);
}

spikes; // [3, 6]

1. Log only what matters

Logging every pass buries the answer. Log the passes you care about:

for (let i = 0; i < readings.length; i++) {
  const delta = readings[i] - (readings[i - 1] ?? readings[i]);
  if (delta > 20) console.log({ i, delta });
  if (delta > 20) spikes.push(i);
}
// { i: 3, delta: 29 }
// { i: 6, delta: 77 }

Logging an object ({ i, delta }) instead of two loose values means every line says what it is.

2. Collect rows, print a table once

When you do need every pass, collect them and print once at the end:

const trace = [];
for (let i = 0; i < readings.length; i++) {
  const delta = readings[i] - (readings[i - 1] ?? readings[i]);
  trace.push({ i, reading: readings[i], delta });
  if (delta > 20) spikes.push(i);
}
console.table(trace);

One table with eight rows reads far better than eight scattered logs, and you can see the pattern (a big positive delta, then a big negative one) at a glance.

3. `console.count` for "how often?"

Sometimes you don't need the values, just how many times a branch ran:

if (delta > 20) console.count("spike");
// spike: 1
// spike: 2

4. Don't edit the code: logpoints

Every technique above changes the loop. That's a risk: you add a log, the bug moves, or the log ships. Debuggers solved this long ago with logpoints, a breakpoint that logs instead of pausing. Browser DevTools and most editors have them.

JSLab, a JavaScript & TypeScript scratchpad for macOS, has them too, without starting a debugger. Click the gutter beside a line, or press F9 with the caret on it, and that line is logged on every run. Its text doesn't change.

Put a logpoint on the const delta = … line and you get one row per pass, each tagged with that line, while the code stays exactly as you wrote it.

Here's a logpoint in a real JSLab tab: the dot beside line 5, and the 33.74 row tagged :5 that it produced. Line 5 itself is unchanged.

A few details from the docs worth knowing:

A logpoint follows its line as you edit above or below it.
Toggling one schedules a run, even if nothing else changed.
⇧⌘F9 clears every logpoint in the tab.
Logpoints belong to one tab and aren't saved, so they can't leak into a file.

If you'd rather mark it in the code, a magic comment before the loop's opening brace logs each pass too:

for (const r of readings) /*?*/ {
  // ...
}

Bonus: the loop that never ends

While you're editing a loop, you'll write while (i < 10) and forget i++. In JSLab, loop protection stops a loop after 2,000 iterations by default and the error names the line, so a slip doesn't hang the run. The limit is Loop Limit in Settings → Advanced.

Which one when

Need the answer once: a conditional log.
Need to see the pattern: collect rows, console.table.
Don't want to touch the code: a logpoint.

JSLab launches Nov 15. Logpoints and loop protection are documented here: https://js-lab.app/docs/editor

Try a React component without creating a project

JSLab — Sun, 01 Nov 2026 16:02:43 +0000

You want to check how a hook behaves. The usual route is a new project: scaffold, install, start a dev server, delete the boilerplate. That's a lot of ceremony for twenty lines.

Today's twenty lines: a useDebouncedValue hook, the kind you write for a search box so it doesn't filter on every keystroke.

The hook

import { useEffect, useState } from "react";

function useDebouncedValue<T>(value: T, ms = 250): T {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), ms);
    return () => clearTimeout(id);
  }, [value, ms]);

  return debounced;
}

How it works: every time value changes, the effect starts a timer. If value changes again before the timer fires, React runs the cleanup first, which cancels the old timer. So debounced only catches up once the input has been still for ms milliseconds.

Two details that bite people:

The cleanup is the debounce. Without return () => clearTimeout(id), every keystroke schedules an update and you've built a delay, not a debounce.
ms belongs in the dependency array. Leave it out and changing the delay does nothing until value changes too.

A component to try it in

import { useEffect, useMemo, useState } from "react";

// useDebouncedValue from above goes here

const fruits = ["apple", "apricot", "banana", "blueberry", "cherry", "grape", "mango"];

export default function App() {
  const [query, setQuery] = useState("");
  const debounced = useDebouncedValue(query, 300);

  const matches = useMemo(
    () => fruits.filter((f) => f.includes(debounced.toLowerCase())),
    [debounced],
  );

  return (
    <div style={{ fontFamily: "system-ui", padding: 24 }}>
      <input
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        placeholder="Filter fruit"
      />
      <p>
        {matches.length} of {fruits.length} (typed: "{query}", filtering: "{debounced}")
      </p>
      <ul>
        {matches.map((f) => (
          <li key={f}>{f}</li>
        ))}
      </ul>
    </div>
  );
}

Showing both query and debounced on screen is the trick: type fast and you can watch the second one lag behind, then snap into place.

Running it without a project

I ran this in JSLab, a JavaScript & TypeScript scratchpad for macOS. Click + in the tab bar and pick React: JSLab sets the tab's language, runtime and framework, installs the packages it needs, and opens starter code. Paste the file over it.

JSLab renders it into a Web View tile beside the console. Edit the JSX and it rerenders as you type. Change 300 to 1000 and you feel the difference on the next keystroke.

Here's a smaller component running the same way in a real JSLab Browser tab: a Counter mounted with createRoot, ticking in the Web View beside the code.

The console still works alongside it. Add a line like this inside the effect and the logs land in the output panel, tagged with their line:

console.log("debounced →", value);

Want styling? Turn on Tailwind in the status bar and the utility classes your code uses get compiled into the page, with nothing to install.

When to make it a real project

A scratchpad is for the question "does this hook behave the way I think?" Once the answer is yes, move it into your app with its tests. The point is not having to pay for a project before you know you need one.

JSLab launches Nov 15. The Web View and framework docs are here: https://js-lab.app/docs/web-view

npm in a scratchpad: install without leaving JSLab

JSLab — Sat, 31 Oct 2026 21:47:34 +0000

We make JSLab, a JavaScript and TypeScript scratchpad for Mac, so this is show-and-tell, not a review.

The video shows JSLab's package sheet.

Press ⌘I, search the registry as you type and click Add, or type name@version and press Return. Packages install into one project that every tab shares, so a package you add in one tab is available in the others straight away, without restarting.

Import something you don't have yet and JSLab offers to install it:

// dayjs isn't installed yet: click Install on the error row, or the lightbulb on line 2.
import dayjs from "dayjs";
dayjs().format("dddd, MMMM D");

Once the install finishes, the tab runs again by itself, and the editor picks up the package's types.

Docs: npm packages

JSLab launches Nov 15 for Apple Silicon Macs (macOS 14 or later), with a 14-day free trial: https://js-lab.app

AI Chat in JSLab: ask about your tab, review the fix as a diff

JSLab — Fri, 30 Oct 2026 21:46:32 +0000

We make JSLab, a JavaScript and TypeScript scratchpad for Mac, so this is show-and-tell, not a review.

The video shows JSLab's AI Chat panel (⌃⌘I).

No pasting. Each message carries the current tab's code and, by default, its most recent output. When the last run failed, the empty chat offers a starter: Why does line N fail?

Your provider. Ollama on your own Mac (at its standard local address, nothing leaves the machine), or OpenAI, Anthropic or Google Gemini with your own key, kept in the macOS Keychain. There are no bundled credits.

Nothing changes until you say so. Preview Changes shows a reply's code as an inline diff in the editor. Apply accepts one change, Apply all accepts the rest, Discard throws them away.

Docs: Ask AI · AI providers and keys

JSLab launches Nov 15 for Apple Silicon Macs (macOS 14 or later), with a 14-day free trial: https://js-lab.app

Inspect any value without console.log

JSLab — Fri, 30 Oct 2026 15:00:56 +0000

You have a chain. Something in the middle is wrong. You want to see the value between two calls without rewriting the chain into five consts.

Here's the chain we'll poke at:

const orders = [
  { id: 1, total: 120, paid: true },
  { id: 2, total: 80, paid: false },
  { id: 3, total: 45.5, paid: true },
];

const revenue = orders
  .filter((o) => o.paid)
  .map((o) => o.total)
  .reduce((sum, n) => sum + n, 0);

revenue is 165.5. But say it wasn't, and you want to know what .map handed to .reduce.

1. The `console.log(x) || x` trick

console.log returns undefined, so console.log(x) || x logs x and then evaluates to x. Drop it into any arrow function and the chain keeps working:

const revenue = orders
  .filter((o) => o.paid)
  .map((o) => console.log(o.total) || o.total)
  .reduce((sum, n) => sum + n, 0);
// logs 120, then 45.5

It works everywhere. It also looks like a bug to the next person, so take it out before you commit.

2. A `tap` helper

If you do this often, give it a name. tap logs a value and passes it through unchanged:

const tap = (label) => (value) => {
  console.log(label, value);
  return value;
};

const revenue = orders
  .filter((o) => o.paid)
  .map(tap("paid order"))
  .map((o) => o.total)
  .reduce((sum, n) => sum + n, 0);

tap shines in promise chains, where each .then gets one value:

fetch("https://api.github.com/zen")
  .then((res) => res.text())
  .then(tap("zen"));

3. Split it and read the pieces

The honest fix is often to name the steps:

const paid = orders.filter((o) => o.paid);
const totals = paid.map((o) => o.total);
const revenue = totals.reduce((sum, n) => sum + n, 0);

Now each step is a line, and you can log any of them. The cost is three console.logs you'll add, read, and delete.

The same thing in a scratchpad

This is the loop that JSLab, a JavaScript & TypeScript scratchpad for macOS, is built around. Two features cover all three cases above.

Auto Log. Every top-level expression is logged beside its line, so a bare name is enough:

const paid = orders.filter((o) => o.paid);
paid;          // logged: the two paid orders
paid.length;   // logged: 2

Assignments, x++ and console.* calls are never auto-logged, so the output stays readable.

Magic comments. End a line with //? and JSLab logs exactly that statement, even inside a function or a loop. /*?*/ works mid-expression, so you can look inside the chain without breaking it:

orders.filter((o) => o.paid) /*?*/ .map((o) => o.total);

That logs the filtered array, before .map runs. And //? $.length logs an expression built from the value, which is $:

const totals = orders.filter((o) => o.paid).map((o) => o.total); //? $.length

That logs 2 instead of the whole array.

Here are all three in one JSLab tab: //? inside a function (line 4), /*?*/ on a loop (line 7), and //? $.length (line 12), which logs 2.

Every row in the output is tagged with the line that produced it, and clicking the line number jumps the editor there. Nothing to remove before you commit: there's no console.log to forget.

Which one when

Shipping code, or code someone else reads: split it into named steps.
Quick look in a real project: tap, or || x if you promise to delete it.
Working something out in a scratchpad: let Auto Log and //? do it.

JSLab launches Nov 15. The docs for Auto Log and magic comments are here: https://js-lab.app/docs/editor

30 seconds of JSLab: every result beside the line that made it

JSLab — Fri, 30 Oct 2026 04:42:31 +0000

We make JSLab, a JavaScript and TypeScript scratchpad for Mac, so this is show-and-tell, not a review.

The video shows one rule: every result lands beside the line that made it.

You type, and Auto Run executes the tab on Bun a moment after you stop (300 ms by default). Each value, log and error is tagged with its source line, and clicking a row jumps to that line. There's no project to create and no build step.

Two ways to see a value without writing console.log:

const orders = [40, 15, 0];
const paid = orders.filter((total) => total > 0);

paid //?        // a magic comment shows this value
paid.length     // Auto Log: a top-level expression logs itself

Docs: Your first tab · The output panel

JSLab launches Nov 15 for Apple Silicon Macs (macOS 14 or later), with a 14-day free trial: https://js-lab.app

One editor, three runtimes: Bun, Browser, and the one in between

JSLab — Fri, 30 Oct 2026 00:24:16 +0000

Here are five lines of JavaScript:

"document" in globalThis;
"Bun" in globalThis;
globalThis.process?.versions?.bun ?? "not Bun";

import { readdir } from "node:fs/promises";
(await readdir(".")).length;

What do they print?

It depends on where they run. Run them in Bun and there's no document, there is a Bun, and readdir counts your files. Run them in a browser and document is there, Bun isn't, and that node:fs import doesn't make it past the build.

Most of us switch between those worlds all day. This post is about turning that into one switch per tab, in JSLab. It's our own tool, so discount the praise accordingly. The snippet above comes straight from the runtime docs.

Three runtimes, one menu

Each JSLab tab runs its code in one of three runtimes. You pick one from the runtime menu in the status bar, from Actions → Runtime, or from the command palette.

Runtime	What your code gets	Web View
Bun (default)	Bun and Node globals and the full Node API surface, with no DOM	No
Browser & Node APIs	A real page, with the DOM and web APIs, plus a Node compatibility layer	Yes
Browser	A real page only, with no Node APIs at all	Yes

Your code is bundled before it runs, so importing an installed package works in all three.

Bun: the default

New tabs open in Bun. Your code runs in a separate Bun process, using the Bun that ships inside JSLab. You get fs, path, child_process, http and the rest, and no DOM.

This is where scripts, data wrangling and algorithm sketches go. Because it's a separate process, an infinite loop or a crash doesn't take the editor down with it.

Browser: a real page, nothing else

The Browser runtime is a real WebKit page with no Node at all: a blank HTML page with your bundled code running in it.

document.body.innerHTML = "<p>Plain browser page</p>";
navigator.userAgent.includes("AppleWebKit");

fetch is the page's own, and CORS applies exactly as it would on a website. That's the point: if you want to know what a site would actually see, this is the honest runtime. Import a Node module and the build fails with a code frame pointing at the import.

Browser & Node APIs: the one in between

The surprising one. It's a real page with document, canvas and requestAnimationFrame, plus a Node compatibility layer bridged out to JSLab:

import { createHash } from "node:crypto";
import os from "node:os";

document.body.innerHTML = `<h1>Hello from ${os.platform()}</h1>`;
createHash("sha256").update("JSLab").digest("hex");
document.querySelector("h1");

A page that renders a heading and hashes a string with Node's crypto, in one file, with no server.

You get fs/promises and the callback-style fs functions, child_process.exec, execFile and spawn, plus os, path, crypto, buffer, events and friends. And fetch goes through JSLab, so it reaches any URL without CORS getting in the way:

const response = await fetch("https://api.github.com/zen");
response.status;
await response.text();

It's not all of Node. Synchronous fs, http, net, tls, dgram, worker_threads and vm aren't available. Call one and the message offers to switch the tab to Bun. For a synchronous fs call, it also names the async alternative.

The Web View

Both browser runtimes render into a Web View tile beside the console. Bun has no page, so it has no Web View. Toggle it with ⌥⌘W.

Every run reloads the page, so the DOM starts clean each time. Nothing from the last run hangs around. The page starts with a single <div id="root">.

Now the fun part: React. You can mount a component the usual way, with createRoot, and it renders in the Web View like it would on any page:

But you don't have to. Default-export a component and JSLab renders it for you:

import { useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <h1>Hello from React</h1>
      <button onClick={() => setCount(count + 1)}>Clicked {count} times</button>
    </div>
  );
}

No createRoot, no index.html, no dev server. Auto Run fires a moment after you stop typing, so you change the JSX and the component rerenders in the tile.

JSLab works out the framework from your imports: React, Vue, Solid or Angular. The Framework menu in the status bar shows what it found, and you can override it. You need the framework's renderer package installed (react-dom for React); if it's missing, the console tells you which one. The quickest start is the + button in the tab bar. Pick a framework and JSLab sets the tab's language, runtime and framework, installs the packages and opens starter code.

It isn't only components. Canvas, Three.js and Web Audio run in the Web View as they would in a browser.

The rule of thumb

You can use this even if you never touch JSLab. Choose a runtime by asking what your code needs to reach:

Only data and the file system? Use a Node-style runtime. No DOM means no accidental browser assumptions.
Only a page? Use a plain browser with real CORS, so what works is what will ship.
A page and a file or an API? That's the in-between case, the one we usually solve with a dev server, a proxy and a script.

Try it

JSLab is a JavaScript and TypeScript scratchpad for Apple Silicon Macs on macOS 14 or later, with a 14-day free trial. It launches on November 15. Until then, read Choosing a runtime and The Web View. Then guess what those five lines print in each runtime, before you can check.

Every value should know where it came from

JSLab — Wed, 21 Oct 2026 16:51:08 +0000

You run your code. Something prints 42.

Which line printed it?

If you had to stop and think, this post is for you. It's about one small idea that makes feedback loops better: every value should carry the address of the line that produced it.

The problem with a flat list

Here's a small script. Nothing exotic.

const orders = [
  { id: 1, total: 40 },
  { id: 2, total: 15 },
  { id: 3, total: 0 },
];

const paid = orders.filter((o) => o.total > 0);
const revenue = paid.reduce((sum, o) => sum + o.total, 0);
const average = revenue / paid.length;

console.log(paid.length);
console.log(revenue);
console.log(average);

Run it and you get 2, 55 and 27.5. Fine. But those three numbers have lost their origin. You know the order they appeared in. You have to remember which console.log was which.

Now imagine this script at 300 lines, with logs in loops, helpers and callbacks. The output is a pile of values with no return address. You end up writing labels by hand: console.log("paid.length:", paid.length). That works, but you're doing bookkeeping the machine could do for you.

The idea: anchor output to the source

Give every result, log and error a line number. Then three nice things fall out.

1. You stop labelling. The line number is the label.

2. You can navigate both ways. Hover a row in the output and the matching line in the editor lights up. Put your cursor on a line and the rows it produced light up. Click a row's line number and you jump to the code.

3. Errors get an address. A stack trace is a list of places. If those places are your lines, the trace becomes a set of links instead of a puzzle.

We build JSLab around this idea, so it's the worked example here — it's our own tool, so discount the praise accordingly.

Fast loop, anchored output

JSLab is a JavaScript and TypeScript scratchpad for macOS. You type; it runs. Auto Run fires after a short pause in typing (300 ms by default, and you can change it in Settings → Advanced). ⌘R runs on demand.

Each result, log and error shows up beside the line that produced it. The output panel has four filter chips, All, Results, Logs and Errors, each with a live count. Counts stay visible even at zero, which is oddly satisfying.

Why does speed matter for this idea? Because anchoring and latency multiply. If the result lands next to the line right after you stop typing, you can change one character and see exactly which value moved. The feedback is local in space and in time.

Let the tool do the logging

Take the same script, with Auto Log on. Auto Log shows the value of each top-level expression beside its line, so you rarely need console.log. It skips assignments and console.* calls.

So this works with no logging at all:

const orders = [
  { id: 1, total: 40 },
  { id: 2, total: 15 },
  { id: 3, total: 0 },
];

orders.filter((o) => o.total > 0);
orders.length;

Two expressions, two values, each beside its own line.

When you want a value from the middle of something, magic comments do it. Append //? to log the value on that line:

const paid = orders.filter((o) => o.total > 0); //?

There's also /*?*/ for logging mid-expression, and a form with $ as a placeholder for the value, like //? $.length, for logging something derived from it. The editor docs list the exact syntax; I'd rather you read it there than trust my paraphrase.

Logging without editing

Sometimes you don't want to touch the code at all. Logpoints do that. Click the gutter, or press F9 on a line, and that line is logged every time it runs. Press ⇧⌘F9 to clear all logpoints in the tab.

This is the same idea again. The log is anchored to a line, and the line stays untouched.

Errors with an address

Here's the case where anchoring pays off most.

function parsePrice(raw) {
  const value = Number(raw.replace("$", ""));
  if (Number.isNaN(value)) {
    throw new Error(`Bad price: ${raw}`);
  }
  return value;
}

const prices = ["$4", "$12", "twelve"].map(parsePrice);

The third item throws. In JSLab the error row is tinted and marked in the editor margin. Its stack frames are mapped back to your source lines, so they point at the code you wrote. You click the frame, and you're on the line.

Nobody has ever said "I wish my stack trace pointed somewhere else."

Values you can poke

Anchored output is only useful if you can inspect it. Objects, arrays, Maps and Sets expand one level at a time, and ⌥→ expands everything nested. Right-click a value to copy it as plain text, as JSON, or as a path like $.users[3]["my-key"]. Copy All lives on the empty space in the panel.

What you can steal even if you never install anything

The tool is the example. The idea works anywhere:

Tag output with its source. In your own logger, include file and line. Future you will say thanks.
Prefer expressions over statements for debugging. If you can see a value without editing code, you'll look at more values.
Shorten the loop. The closer in time a result arrives, the less you have to hold in your head.
Make errors point at your code, not the runtime's. Source maps exist for this reason.

A practical note

JSLab runs your code in a separate Bun process, so an infinite loop or a crash doesn't take the editor down. It's for Apple Silicon Macs on macOS 14 or later. There's a 14-day free trial.

JSLab launches on November 15. Until then you can read the site and the docs at js-lab.app and the output docs.

If one idea stays with you, make it this: a value without a line number is a value without a story. Go give your output an address.

DEV Community: JSLab

Line-anchored output and the filter chips

Every row knows its line

The four chips

Two small things

Turning it down

Log inside a loop without touching the code

1. Log only what matters

2. Collect rows, print a table once

3. console.count for "how often?"

4. Don't edit the code: logpoints

Bonus: the loop that never ends

Which one when

Try a React component without creating a project

The hook

A component to try it in

Running it without a project

When to make it a real project

npm in a scratchpad: install without leaving JSLab

AI Chat in JSLab: ask about your tab, review the fix as a diff

Inspect any value without console.log

1. The console.log(x) || x trick

2. A tap helper

3. Split it and read the pieces

The same thing in a scratchpad

Which one when

30 seconds of JSLab: every result beside the line that made it

One editor, three runtimes: Bun, Browser, and the one in between

Three runtimes, one menu

Bun: the default

Browser: a real page, nothing else

Browser & Node APIs: the one in between

The Web View

The rule of thumb

Try it

Every value should know where it came from

The problem with a flat list

The idea: anchor output to the source

Fast loop, anchored output

Let the tool do the logging

Logging without editing

Errors with an address

Values you can poke

What you can steal even if you never install anything

A practical note

3. `console.count` for "how often?"

1. The `console.log(x) || x` trick

2. A `tap` helper