DEV Community: Khriztian Moreno

Hacks for effective Fullstack development with React and Node

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Today I'm going to show you an optimal workflow for effective development with Node.js and React. If you've ever worked on a project with multiple package.json files, you might know the pain of juggling multiple terminal tabs, remembering which commands start which server, or handling CORS errors.

Fortunately, there are some tools available that can alleviate some of these headaches.

Monorepo Setup for React and Node

Let's say we're working on a monorepo with two package.json files: one is in a client directory for a React front-end powered by Create React App, and one is at the root of the repository for a Node back-end that exposes an API that our React app uses. Our React app runs on localhost:3000 and our Node app runs on localhost:8080. Both apps are started with npm start

Since we have two package.json files, this means that in order to get our front-end and back-end up and running, we need to make sure we've run npm install and npm start in both the root directory and the client directory. Here's how we simplify this.

1. Running two servers at the same time

One improvement we can make to our development workflow is to add a build tool to run multiple npm commands at the same time to save us the trouble of running npm start in multiple terminal tabs. To do this, we can add an npm package called concurrently to the root of our project.

In the root of our project, we will install it as a development dependency.

npm install -D concurrently

Then, in our root package.json scripts, we will update our start script to use them simultaneously.

{
  "name": "my-app",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "start": "concurrently --kill-others-on-fail npm run server npm run client",
    "server": "node index.js",
    "client": "cd client && npm start"
  },
  "dependencies": {
    "express": "^4.17.1"
  },
  "devDependencies": {
    "concurrently": "^6.0.1"
  }
}

Now, we have three npm scripts:

npm run server starts our Node application,
npm run client runs npm start in the client directory to start our React application,
npm start runs npm run server and npm run client at the same time.

2. Installing front-end and back-end dependencies with a single command

Another aspect of our workflow that we can improve is the installation of dependencies. Currently, we need to manually run npm install for every package.json file we have when setting up the project. Instead of going through that hassle, we can add a postinstall script to our root package.json to automatically run npm install in the client directory after the installation has finished in the root directory.

{
  "name": "my-app",
  "scripts": {
    ...,
    "postinstall": "cd client && npm install"
  },
}

Now, when we install our monorepo, all we need to do to get it up and running is run npm install and then npm start at the root of the project. There is no need to enter any other directory to run other commands.

3. Proxy API requests from the backend

As I mentioned earlier, our Node backend exposes the API endpoints that our React app will use. Let's say our Node app has a /refresh_token endpoint.

Out of the box, if we tried to send a GET request to http://localhost:8080/refresh_token from our React app at http://localhost:3000, we would run into CORS issues. CORS stands for cross-origin resource sharing.

Typically when you encounter CORS errors, it's because you're trying to access resources from another domain (i.e., http://localhost:3000 and http://localhost:8080), and the domain you're requesting resources from is not allowed.

To tell the development server to proxy any unknown requests to our API server in development, we can set up a proxy in our React app's package.json file. In client/package.json, we'll add a proxy for http://localhost:8080 (where our Node app is running).

{
  "name": "client-app",
  "proxy": "http://localhost:8080",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  ...
}

Now, if we restart the server and set a request to our Node app's /refresh_token endPoint (without http://localhost:8080) using fetch(), the CORS error should be resolved.

fetch("/refresh_token")
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((err) => console.error(err));

Next time you're working on a monorepo project like this, try these three tips to streamline your development workflow.

That's all folks! I hope this helps you become a better dev!

@khriztianmoreno

Semantic markup for AI: turn your forms into WebMCP tools without JavaScript

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

In the first post in this series, every WebMCP tool was a JavaScript object: a name, a description, a hand-written inputSchema, and an execute function that called the store. It works, and for logic that lives in JavaScript it's exactly what you want. But look at your app for a second: where does most of what a user can do actually live? Search, filter, subscribe, book, pay, leave a comment. Almost all of it is a <form>.

And a form is already, to a large extent, a tool description. It has a name per field (name), types (type="date", type="email"), rules (required, pattern, min, max), closed sets of options (<select>), and a submission endpoint. The only thing it's missing for an agent to understand it is natural-language context: what the form does and what each field means.

That's what the WebMCP declarative API proposes: a handful of attributes that turn an ordinary <form> into a tool. The basic tool needs zero lines of JavaScript, and it degrades perfectly: a human still sees a normal form. JavaScript only comes back for one thing: answering the agent without navigating.

I built a demo in the same flight domain as the previous post. The code is in demos/webmcp-declarative-forms (the README explains how to run it).

How the demo works

Your browser doesn't support embedded video — clone the demo and run it locally instead.

The full run: the agent searching on its own, stopping at the booking form for you to review, and the three ways to cancel.

The app is SkyFare again, but this time there's no registerTool() anywhere. It's two plain HTML forms with declarative attributes:

search_flights has toolautosubmit: the agent fills it and the form submits itself.
book_flight doesn't: the agent fills it, the submit button gets focus, and you review and confirm.

Next to them are two panels. One is a simulated agent (no LLM, same as part 1: the plan is hard-coded) with the goal find the cheapest nonstop flight BOG → MAD for 2 passengers and book it for Ana Gómez. The other is a schema inspector that shows, live, the JSON Schema that comes out of each form.

In my runs (headless Chrome 154, using the shim):

The agent discovers 2 tools from the markup, without the page registering anything.
search_flights fills and submits itself. The agent gets 745 characters of JSON with the flights, and the URL doesn't change: zero navigations.
book_flight fills and then waits. The form gets highlighted, and the "Confirm booking" button pulses and has focus. The agent can't finish until you click. When you do, it gets 313 characters of JSON with the confirmation.

While it waits, you can cancel in three different ways: the agent cancels, you reset the form, or the page changes the toolname. All three cut off the in-flight invocation.

The problem: every tool needed JavaScript

Part 1 left us with a core idea: a tool isn't a second implementation of the feature, it's another entry point into the one you already have. But with the imperative API, you have to build that entry point by hand. This is what search_flights looked like in the first demo's tools.js:

{
  name: 'search_flights',
  title: 'Search flights',
  description:
    'Search available flights between two airports. Returns every matching flight with id, airline, times, number of stops and price in USD.',
  inputSchema: {
    type: 'object',
    properties: {
      origin: { type: 'string', description: 'IATA code of the departure airport, e.g. "BOG".' },
      destination: { type: 'string', description: 'IATA code of the arrival airport, e.g. "MAD".' },
      date: { type: 'string', format: 'date', description: 'Departure date, YYYY-MM-DD.' },
    },
    required: ['origin', 'destination'],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ origin, destination, date }) => {
    const flights = searchFlights({ origin, destination, date });
    return { count: flights.length, flights };
  },
},

Look at the inputSchema. That block repeats information your form already has: that origin is a required string, that date is a date. And because it's duplicated, it can drift: the day someone adds a pattern to the origin input, the schema never hears about it. On top of that, not everything on your site sits behind a JavaScript function. Plenty of forms just POST to the server and that's it. To expose them with the imperative API, you'd have to rewrite them first.

Building block 1: the same contract, written in HTML

This is the demo's search form, in index.html (I left out the cabin and passenger fields so it reads better):

<form
  id="search-form"
  action="submitted.html"
  method="get"
  toolname="search_flights"
  tooldescription="Search flights between two airports on a given date. Returns each flight's id, airline, times, number of stops and per-passenger price."
  toolautosubmit
  class="tool-form grid grid-cols-2 gap-3 sm:grid-cols-4"
>
  <label class="field">From
    <input name="origin" required pattern="[A-Za-z]{3}" maxlength="3" placeholder="BOG" autocomplete="off" title="3-letter airport code"
      toolparamdescription="Origin airport, as a 3-letter IATA code (e.g. BOG)" />
  </label>
  <label class="field">To
    <input name="destination" required pattern="[A-Za-z]{3}" maxlength="3" placeholder="MAD" autocomplete="off" title="3-letter airport code"
      toolparamdescription="Destination airport, as a 3-letter IATA code (e.g. MAD)" />
  </label>
  <label class="field col-span-2">Date
    <input name="date" type="date" required min="2026-10-13" max="2027-10-12"
      toolparamdescription="Departure date" />
  </label>

The pattern comes straight from the declarative API explainer, which shows the same side-by-side with a car search. There are only a few attributes:

On the <form>: toolname (the equivalent of the imperative tool's name), tooldescription (the equivalent of description), and toolautosubmit, a boolean attribute we'll get to in building block 3.
On each control: the usual name becomes the property name, and toolparamdescription provides its description.

One detail you'll see wrong in a few places: there is no toolparam attribute. The property name is the control's name, the same one that already travels with the form submission. The only new thing per control is the description.

And notice what isn't there: no execute, no registerTool(), no AbortController to unregister. According to the explainer, when a form with these attributes is inserted, removed, or has those attributes changed, the browser creates a new declarative tool. The tool's lifecycle is the element's lifecycle.

Building block 2: from form to JSON Schema (and why it's TBD)

For the agent to know how to fill the form, the browser has to "compile" it into an inputSchema. The explainer calls this input schema synthesis, and here's the part I most want to be clear about: the algorithm doesn't exist in the spec yet. The section literally says TODO: it still needs to specify how <input>, <select>, and attributes like step and min reduce to a JSON Schema with anyOf, oneOf, minimum, and maximum. Chromium is implementing "a loose version" of it to trial.

So the demo ships our own approximation, in schema-synthesis.js, and the inspector shows it with a label that says so. This table is what I'd expect to happen, not what a standard says:

In the HTML	Our approximation in JSON Schema
`required`	The property goes into `required`
`pattern="[A-Za-z]{3}"`	`"pattern": "^(?:[A-Za-z]{3})$"` (HTML anchors patterns implicitly; JSON Schema doesn't)
`minlength` / `maxlength`	`minLength` / `maxLength`
`type="email"`	`"format": "email"`
`type="date"` with `min` / `max`	`"format": "date"`; the range goes into a `$comment`, because JSON Schema has no standard keyword for date ranges
`type="number" min="0" max="3"`	`"type": "integer", "minimum": 0, "maximum": 3` (the default `step` is 1, hence integer)
`type="checkbox"`	`"type": "boolean"`
`<select>`	`"oneOf": [{ "const": "economy", "title": "Economy" }, …]`; the empty placeholder is dropped when the select is `required`
Form-associated custom element	`"type": "string"` with a `$comment`: the mapping is unspecified

Building this taught me two things. First, your HTML validation becomes documentation for the agent. That pattern you added for the user now also tells the model what format the field expects. Second, some things don't translate well: a date range has no standard keyword, and a custom control is opaque. Validation still runs when the form is submitted (it's HTML, after all), but the agent can't see it ahead of time.

The inspector updates through a MutationObserver. Tick the toolautosubmit checkbox or rename the tool, and you'll see the schema re-synthesized on the spot.

Building block 3: `toolautosubmit` or human review

This is the most important design decision in the API, and it's a single boolean attribute:

With toolautosubmit, the agent fills the form and submits it on the user's behalf. That makes sense for a search: it's read-only and has no consequences.
Without toolautosubmit, once the agent is done filling, the browser brings the submit button into focus, and the agent should tell the user to check the form and submit it manually.

In part 1, the "Approve / Deny" before booking was implemented by my simulated agent reading consequentialHint. Here, the human in the loop comes for free: it's the form itself, with the agent's data in plain view, and the same button as always. No JavaScript, no separate dialog.

To make sure the user notices a form waiting for them, the explainer proposes two CSS pseudo-classes: :tool-form-active for the <form> whose tool is "running", and :tool-submit-active for its submit button. A script can't make a real pseudo-class match, so the shim mirrors them as data-* attributes, and style.css has both versions:

form:tool-form-active {
  outline: 2px dashed var(--review);
  outline-offset: 8px;
  border-radius: 0.5rem;
}

/* ... */

form[data-tool-form-active] {
  outline: 2px dashed var(--review);
  outline-offset: 8px;
  border-radius: 0.5rem;
}

They're separate rules on purpose: a browser that doesn't know :tool-form-active drops the whole rule, so if you put both versions in a single selector list, that browser would drop the shim's version too.

The invocation can also be cut off. According to the explainer, if the form is reset or its tool declaration changes (say, its toolname), the in-flight invocation is canceled and the agent is notified. In the demo you can try it with the "Clear" and "Rename to reserve_flight" buttons while the agent is waiting.

Find, preview, commit

After part 1, a reader asked a question worth its weight in gold: if the agent no longer has to guess which button to press, how does a site express the difference between finding an option, previewing the result, and committing a change? Those are three distinct intents, and today WebMCP covers them unevenly:

Intent	Imperative API (part 1)	Declarative API (this part)
Find	`readOnlyHint` on the tool	a search form with `toolautosubmit`
Preview	not a concept: you model it as a separate read-only tool (e.g. `quote_booking`)	the agent-filled form waiting for review (`:tool-form-active`, focus on the submit button)
Commit	`consequentialHint`, plus your own approval UI	the human presses submit (no `toolautosubmit`)

The awkward part: the declarative API has no equivalent to readOnlyHint or consequentialHint. The only attributes the explainer proposes are toolname, tooldescription, toolautosubmit, and toolparamdescription. The only signal that "this has consequences" is the absence of toolautosubmit.

What follows is my own reading, not something in the explainer: the web has had this distinction for decades. In HTTP, GET is a safe method, meant for reading, and POST isn't. A well-built form already declares its intent through its method: search goes over GET, booking over POST. Note that the demo's booking form uses GET only because a static server rejects POST; a real app would use POST. If tool synthesis ended up using that signal, agents would inherit semantics the web already understands instead of inventing new ones. Solving this properly, with permissions and confirmations, is the topic of this series' human-in-the-loop post.

Building block 4: `agentInvoked` and `respondWith()`, where JavaScript comes back

So far, zero JavaScript. But there's a gap: when the agent submits the search form, what does it get back? Without JavaScript, the form navigates to its action, as always. The explainer had an idea for that case: use the first <script type="application/ld+json"> on the destination page as the response. That idea is now under debate in issue #135.

The alternative, which the demo uses, is to answer from the page. The explainer adds two members to SubmitEvent: agentInvoked, to tell whether an agent triggered the submission, and respondWith(promise), to hand the agent a response without navigating. The rule: you must call preventDefault() before respondWith(). Here's how it looks in app.js:

searchForm.addEventListener('submit', (event) => {
  // Enhanced path: answer in-page instead of navigating to the GET action.
  event.preventDefault();
  const flights = searchFlights(Object.fromEntries(new FormData(searchForm)));
  renderResults(resultsEl, flights, bookForm);

  if (event.agentInvoked) {
    // The agent gets structured data back; the page never navigates.
    event.respondWith(Promise.resolve({ flights }));
  }
});

This is what I liked most about the approach: it's the same handler for humans and agents. If you fill in the search yourself, agentInvoked is false, the results render on the page, and that's it. If the agent fills it, exactly the same thing happens, and the agent also gets { flights } as data, so it doesn't have to read the results list. The only agent-specific line is the if.

One detail the explainer doesn't settle: when the agent fills book_flight and you click "Confirm booking", is that submission agentInvoked? The shim says yes, so the agent receives the confirmation. That's my call, not something the text says.

Building block 5: Web Components that take part

The explainer talks about <form> and form-associated elements. It doesn't mention <details>, tables, or microformats. But here's an important detail: a custom element with static formAssociated = true and ElementInternals is a form-associated element per HTML. So a Web Component can take part. The demo has one, passenger-stepper.js:

class PassengerStepper extends HTMLElement {
  static formAssociated = true;

  #internals = this.attachInternals();

It shows up in form.elements, submits its value with setFormValue(), validates with setValidity(), and responds to reset with formResetCallback(). To the shim, it's just another control.

Now, what follows is my inference, not spec: the explainer doesn't say how a custom element maps to a schema. An <input type="number" min="1" max="6"> tells the agent "integer between 1 and 6". My custom element, on the other hand, is a black box: the browser has no way of knowing which values it accepts. That's why, in our approximation, it comes out as a string with a $comment, and the demo's agent sends "2". Validation still works on submit, but the agent loses the type and the range. If you can use a native control, the agent comes out ahead.

Building block 6: real progressive enhancement

Since it's all HTML, the demo works without JavaScript. Both forms GET submitted.html, a static page that shows you what arrived. The stepper has a fallback too: in the markup, it wraps a plain <input type="number" name="passengers">, and when the custom element upgrades, it copies its contract (name, min, max, and toolparamdescription) and replaces it. Without JavaScript, the element never upgrades and the form submits the plain input.

To try it without touching your browser settings, the "View without the page script" link loads the page with ?nojs, and main.js stops before doing anything:

if (new URLSearchParams(location.search).has('nojs')) {
  document.documentElement.dataset.nojs = '';
} else {
  await boot();
}

It's a simulation, and the UI says so. For the real test, disable JavaScript in DevTools. That's how I verified it with Playwright: with JavaScript off, the booking form navigates to submitted.html?flight=IB-6584&passenger=Ana+G%C3%B3mez&… like any form from the 2000s.

That's the underlying argument: declarative attributes cost nobody anything. A browser that doesn't understand them ignores them, a human sees the same form as always, and the page that already worked keeps working.

An honest caveat: this is even earlier than part 1

If the imperative API is a proposal, the declarative one is a step further back:

It only exists in an explainer. It's not in the spec, which is itself a Draft Community Group Report off the standards track.
Schema synthesis is TBD. Everything in the table is our approximation. Chromium is trialing its own loose version, and the result may differ.
How the response gets back to the agent is under debate (issue #135). respondWith() is in the explainer, but the no-JavaScript path (application/ld+json on the destination page) is still being discussed.
The event names don't match. The explainer talks about toolactivated and toolcanceled. The spec IDL, on the other hand, defines ontoolcancel. It's also still open whether they fire at Window or at the <form>. Meanwhile, the shim fires both toolcanceled and toolcancel.
Integration with getTools() / executeTool() is TBD. The explainer says declarative tools will almost certainly be invokable through them, but the details aren't there. That's why the shim exposes its own getTools() / executeTool() and leaves document.modelContext alone.
I haven't tested the native path. There's no documented way to detect support for the declarative API, so the demo doesn't invent one: the declarative behavior is always the shim. If your browser exposes the imperative document.modelContext, the badge shows it, but that tells you nothing about forms.

What I learned building this

Your forms were already a contract. name, type, required, and pattern have been describing what your app expects for years. The declarative API doesn't ask for a new contract; it asks you to add the descriptions.
Human-in-the-loop can be an attribute. Leaving out toolautosubmit is enough to make the user review a consequential action, with a UI they already know. It's the cheapest form of control I've seen so far in this series.
One handler for humans and agents. agentInvoked + respondWith() doesn't make you fork your logic: you just add a structured response at the end of the path that already existed.
Native beats custom, at least for the agent. A Web Component can take part, but a native <input> gives the model types and ranges that an opaque component hides.

In the next posts in the series, we'll look at what happens when state lives in an SPA's hooks and stores, how to design human-in-the-loop permissions beyond a form, and how to debug all of this with DevTools.

To keep exploring

The declarative API explainer: declarative-api-explainer.md, the source for everything in this post.
The issue about the agent response: webmachinelearning/webmcp#135, where the way a form's result gets back to the agent is being discussed.
The WebMCP spec: webmachinelearning.github.io/webmcp, the Draft Community Group Report (the imperative API).
Part 1 of the series: WebMCP — Why agents shouldn't have to guess how your UI works, with registerTool(), getTools(), and executeTool().
The full demo: demos/webmcp-declarative-forms — run the agent, leave it waiting on the booking form, and try all three ways to cancel.

How many of your app's forms could be tools tomorrow just by adding descriptions? I'd love to hear which one you'd expose first. Let's talk on X/Twitter or LinkedIn.

How to mock an HTTP request with Jest 💻

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Today I wanted to show you how to properly write a test.

But anyone can figure out how to run a simple test. And here, we're looking to help you find answers you won't find anywhere else.

So I thought we'd take things one step further.

Let's run a more complex test, where you'll have to mock 1 or 2 parts of the function you're testing.

[In case you're new here: mock is like using a stunt double in a movie. It's a way to replace a complicated part of your code (like calling an API) with something simpler that pretends to be real, so you can test the rest of your code easily.]

MY testing framework of choice is Jest, because it makes everything so much easier:

Zero Configuration: One of the main advantages of Jest is its zero-configuration setup. It is designed to work out of the box with minimal configuration, making it very attractive for projects that want to implement tests quickly and efficiently.
Snapshot Testing: Jest introduced the concept of Snapshot Testing, which is particularly useful for testing UI components. It takes a snapshot of a component’s rendered output and ensures that it doesn’t change unexpectedly in future tests.
Built-In Mocking and Spies: Jest comes with built-in support for mock functions, modules, and timers, making it easy to test components or functions in isolation without worrying about their dependencies.
Asynchronous Testing Support: Jest supports asynchronous testing out of the box, which is essential for testing in modern JavaScript applications that often rely on asynchronous operations like API calls or database queries.

De todos modos, entremos en las pruebas:

Step 1: Setting up your project

Create a new project directory and navigate to it
Initialize a new npm project: npm init -y
Install Jest: npm install --save-dev jest
Install axios to make HTTP requests: npm install axios

These are the basic requirements. Nothing new or fancy here. Let's get started.

Step 2: Write a function with an API call

Now, let's say you log into some kind of application. StackOverflow, for example. Most likely, at the top right you'll see information about your profile. Maybe your full name and username, for example.

In order to get these, we typically have to make an API call to get them. So, let's see how we would do that.

Create a file called user.js
Inside user.js, write a function that makes an API call. For example, using axios to retrieve user data:

// user.js
import axios from "axios";

export const getUser = async (userId) => {
  const response = await axios.get(`https://api.example.com/users/${userId}`);
  return response.data;
};

Step 3: Create the Test File

Okay, now that we have a function that brings us the user based on the ID we requested, let's see how we can test it.

Remember, we want something that works always and for all developers.

Which means we don't want to depend on whether the server is running or not (since this is not what we are testing).

And we don't want to depend on the users we have in the database.

Because in my database, ID1 could belong to my admin user, while in your database, ID1 could belong to YOUR admin user.

This means that the same function would give us different results. Which would cause the test to fail, even though the function works correctly.

Read on to see how we tackled this problem using mocks.

Create a file called user.test.js in the same directory.
Inside this file, import the function you want to test:

import axios from "axios";
jest.mock("axios");

import { getUser } from "./user";

Write your test case, mock the call, and retrieve mock data.

test("should fetch user data", async () => {
  // Mock data to be returned by the Axios request
  const mockUserData = { id: "1", name: "John Doe" };
  axios.get.mockResolvedValue({ data: mockUserData });

  // Call the function
  const result = await getUser("1");

  // Assert that the Axios get method was called correctly
  expect(axios.get).toHaveBeenCalledWith("https://api.example.com/users/1");

  // Assert that the function returned the correct data
  expect(result).toEqual(mockUserData);
});

Step 4: Run the test

Add a test script to your package.json:

"scripts": {
  "test": "jest"
}

Run your tests with npm test.

Step 5: Review the results

Jest will display the result of your test in the terminal. The test should pass, indicating that getUser is returning the mocked data as expected.

Congratulations, you now have a working test with Jest and Mocking.

I hope this was helpful and/or made you learn something new!

@khriztianmoreno

Some methods beyond console.log in Javascript

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Often, during debugging, JavaScript developers tend to use the console.log() method to print values. But there are some other console methods that make life much easier. Want to know what these methods are? Let's get to know them!

1. `console.table()`

Displaying long arrays or objects is a headache using the console.log() method, but with console.table() we have a much more elegant way to do it.

// Matrix
const matrix = [
  ["apple", "banana", "cherry"],
  ["Rs 80/kg", "Rs 100/kg", "Rs 120/kg"],
  ["5 ⭐", "4 ⭐", "4.5 ⭐"],
];
console.table(matrix);

// Maps
class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }
}

const family = {};
family.mother = new Person("Jane", "Smith");
family.father = new Person("John", "Smith");
family.daughter = new Person("Emily", "Smith");
console.table(family);

2. `console.trace()`

Having trouble debugging a function? Wondering how the execution flows? console.trace() is your friend!

function outerFunction() {
  function innerFunction() {
    console.trace();
  }
  innerFunction();
}
outerFunction();

3. `console.error()` and `console.warn()`

Tired of boring logs? Spice things up with console.error() and console.warn()

console.error("This is an error message");
console.warn("This is a warning message");
console.log("This is a log message");

4. `console.assert()`

This is another brilliant debugging tool! If the assertion fails, the console will print the trace.

function func() {
  const a = -1;
  console.assert(a === -1, "a is not equal to -1");
  console.assert(a >= 0, "a is negative");
}

func();

5. `console.time()`, `console.timeEnd()`, and `console.timeLog()`

Need to check how long something is taking? Timer methods are there to rescue you!

console.time("timeout-timer");

setTimeout(() => {
  console.timeEnd("timeout-timer");
}, 1000);

setTimeout(() => {
  console.timeLog("timeout-timer");
}, 500);

NOTE: setTimeouts are not executed immediately, which results in a slight deviation from the expected time.

That's all folks! I hope this helps you become a better dev!

@khriztianmoreno on Twitter and GitHub

Demystifying Core Web Vitals - A Developer's Guide to LCP, INP, and CLS

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Core Web Vitals are ranking signals, but most teams still optimize them like lab-only scorecards. This guide turns CWV into actionable engineering work: how to measure (field + lab), how to debug root causes in DevTools, and which fixes actually move the 75th percentile.

Core Web Vitals are engineering work, not a Lighthouse mini-game

If you work in web performance, you’ve probably seen the same pattern:

The team “optimizes Core Web Vitals” by chasing a green Lighthouse score.
The score improves.
The Search Console report doesn’t.
Real users still complain that the site “feels janky” or “lags when I tap”.

That gap exists because Core Web Vitals are field metrics. They’re evaluated on real user experiences (CrUX / RUM) at the 75th percentile, segmented by device + network. Lighthouse is still useful, but it’s not the authority.

There’s also a newer tension that many teams haven’t fully internalized:

INP quietly replaced FID on March 12, 2024.

The switch matters because it changes what “good performance” means. FID mostly rewarded “fast to start handling the first tap”. INP rewards something stricter and closer to how users judge sites: consistent responsiveness across the entire session.

If you want to build pages that rank and feel fast, you need to treat CWV as:

Instrumented production signals
Debuggable traces
Fixable bottlenecks

References:

Core Web Vitals (quick overview)

One table. No fluff.

Metric	Measures	Good (75th percentile)
LCP	Main content load	≤ 2.5s
INP	Interaction responsiveness	≤ 200ms
CLS	Visual stability	≤ 0.1

Field data vs lab data (why your “green Lighthouse” can still fail)

Field (CrUX / RUM): what Google ranks on and what users feel.
- Aggregated over real sessions.
- Evaluated at the 75th percentile.
- Sensitive to slow devices, poor networks, CPU contention, third-party scripts, and long sessions.
Lab (Lighthouse / DevTools): what you use to reproduce, regress-test, and debug.
- Controlled environment.
- Great for identifying causes.
- Not authoritative for SEO.

If you take only one rule from this post:

If it’s not measured in the field, it does not exist.

References:

CrUX Dashboard: https://developer.chrome.com/docs/crux/dashboard
PageSpeed Insights docs: https://developers.google.com/speed/docs/insights/v5/about

LCP (Largest Contentful Paint)

What actually counts as LCP

LCP is not “the time the page looks ready” and it’s not “when the hero image finishes”. Chrome continuously tracks LCP candidates as the page renders, then reports the final winner.

Common candidates include:

<img> elements (including responsive images)
<video poster> frames
Some background images (when painted as an image contentful element)
Large text blocks (big headings, hero copy)

What matters for debugging is which element won and why it was late.

In practice, LCP investigations start with:

Identify the LCP element
Break down its timeline
- TTFB
- Resource load time (image/font)
- Render delay (main thread / hydration / layout)

Reference:

https://web.dev/lcp/
DevTools LCP debugging: https://developer.chrome.com/docs/lighthouse/performance/lighthouse-largest-contentful-paint

Measure LCP (code)

Use web-vitals in production to capture field LCP and the element responsible.

import { onLCP } from "web-vitals";

onLCP((metric) => {
  console.log(metric.value, metric.element);
});

If you’re doing serious work, don’t stop at console.log. Send it to your RUM endpoint and segment it:

Device class
Effective connection type
Route/template
A/B cohort

Common real-world LCP killers

Late-loading hero images
- Hero requested after CSS/JS resolves.
- Image is discovered late because it’s in CSS or injected after hydration.
Server TTFB
- Slow origin.
- Cold starts.
- Heavy SSR compute.
- Cache misses.
Client-side rendering waterfalls
- “Blank shell” + fetch + render.
- Framework hydration blocking paint.
- Fonts delaying text paint (FOIT) or relayout (FOUT).

Fixes that actually work

1) Make the hero request early (and intentionally)

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

Guidance:

Preload vs prefetch
- preload is a strong “I need this for this navigation” signal.
- prefetch is speculative and can be ignored under pressure.
fetchpriority
- Use high for the actual LCP element.
- Don’t blanket-apply it to everything, or you’ll just reorder contention.

2) Stop hydration from blocking the first meaningful render

Frameworks differ, but the principle is the same: ship less JS before first paint.

If your stack supports it, prefer:

SSR or static rendering for the LCP region
Partial hydration / islands for below-the-fold widgets
Streaming SSR where it reduces blocking time

3) Fix TTFB before you touch images

If your LCP breakdown shows TTFB dominates, optimizing images won’t move the needle.

Typical “TTFB-first” wins:

CDN caching for HTML
Server render caching
Reduce backend fan-out
Avoid expensive personalization before first byte

Framework callout (Next.js)

The exact knob depends on version and routing (Pages vs App), but the intent is to reduce runtime JS when possible.

export const config = {
  unstable_runtimeJS: false,
};

Treat this as a reminder, not a copy/paste fix: validate what your framework version actually supports, and measure the impact on hydration + interactivity.

INP (Interaction to Next Paint)

This is the heart of CWV work in 2025.

Why FID was misleading (and why Google replaced it)

FID measured only one thing:

The delay between a user’s first interaction and when the browser could begin processing it.

It did not measure:

Event handler execution time
Rendering time after the handler
The 20th interaction on a long-lived page
Responsiveness when the app is “fully loaded” but the main thread is constantly busy

That’s why teams could “fix FID” with small tweaks (or by shifting work later) and still ship experiences that feel laggy.

INP fixes that. It tracks responsiveness across the page lifetime and is designed to align with perceived UX pain.

Reference:

https://web.dev/inp/

How INP works (the mental model)

INP is roughly:

The worst (or near-worst) interaction latency observed during the page’s lifetime
For each interaction, it measures from input to the next paint

So INP doesn’t just punish “slow click handlers”. It punishes any moment where:

The main thread is tied up (long tasks)
Rendering is expensive
Updates are synchronous and block paint

Measure INP (code)

import { onINP } from "web-vitals";

onINP((metric) => {
  console.log(metric.value, metric.attribution);
});

The attribution payload is your bridge from “INP is bad” to “this exact interaction is bad”. Fields vary by browser + library version, but you should expect to see (or derive):

eventType (e.g. click, pointerdown, keydown)
target / interaction target (which element)
interactionId (to correlate related events)

Typical INP problems (what I see most often)

1) Long JS tasks

If the main thread is blocked for 200ms+, you’re effectively rolling the dice on INP.

Usual causes:

Heavy synchronous parsing/serialization
Expensive formatting
Large list reconciliation
“One big reducer” updates

2) Overhydration / excessive client work

Hydrating everything up front often creates a permanently busy main thread:

Too many components hydrating at once
Client-side routing transitions doing expensive work
Recomputing derived state on every input

3) Third-party scripts

Third-party is a frequent INP saboteur because:

It schedules work unpredictably
It competes for CPU during user interactions
It’s often shipped without performance budgets

Debugging INP: go from metric → interaction → long task

What works consistently:

Start with field data

Confirm INP is actually a production issue.
Identify the worst templates/routes.

Reproduce in DevTools Performance

Record an interaction (click, type, open menu).
Look for long tasks around the interaction.

Use the “why is this slow?” breakdown
- Scripting vs rendering vs style/layout.
- Identify the specific function/component causing the stall.

References:

DevTools Performance panel: https://developer.chrome.com/docs/devtools/performance
Long Tasks API: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming

Fix patterns that move INP

1) Defer non-critical work off the interaction path

requestIdleCallback(() => {
  initAnalytics();
});

Rules of thumb:

Idle work must be cancelable.
Don’t schedule “idle” tasks that are actually required for UX.

2) Split long tasks (don’t just “optimize” them)

If you have 300ms of work, shaving 20ms off rarely saves INP. You need to create paint opportunities.

Options:

Break work into chunks with setTimeout(0) / queueMicrotask strategically
Use scheduler.postTask where available
Move computation to a Web Worker

3) Make UI updates interruptible (React example)

button.addEventListener("click", () => {
  startTransition(() => {
    setState(expensiveUpdate);
  });
});

The key idea is not “use transitions everywhere”. It’s:

Keep the immediate response lightweight
Let expensive work yield so the browser can paint

4) Reduce the amount of work per interaction

High-leverage wins:

Virtualize long lists
Avoid synchronous JSON.stringify on large objects during input
Memoize derived computations (but verify it actually reduces work)
Don’t re-render entire pages on keystrokes

5) Put third-party on a leash

If you can’t remove it:

Load it later
Gate it behind consent or after first interaction
Use Partytown or worker-based approaches where applicable
Apply performance budgets and enforce them

CLS (Cumulative Layout Shift)

CLS is the metric most teams think they understand… until ads, fonts, and “just one dynamic banner” wreck production.

Why CLS still fails teams

Ads and embeds that resize after load
Fonts that swap and change metrics
Dynamic components that mount above existing content
Late UI injection (cookie banners, promos, consent, tooltips)

Measure CLS (code)

import { onCLS } from "web-vitals";

onCLS((metric) => {
  console.log(metric.value);
});

For debugging, capture attribution (shift sources) when possible, and pair this with DevTools “Layout Shift Regions”.

Reference:

https://web.dev/cls/
DevTools layout shift regions: https://web.dev/articles/debug-layout-shifts

Fixes that matter

1) Reserve space for media

img {
  aspect-ratio: 16 / 9;
}

Why this works:

The browser can allocate space before the resource loads.
You avoid “downward pushes” that score as layout shifts.

If you can, also include explicit width and height attributes on images. aspect-ratio is a great complement, especially when responsive sizing makes static dimensions less obvious.

2) Don’t let fonts surprise layout

<link
  rel="preload"
  as="font"
  href="/inter.woff2"
  type="font/woff2"
  crossorigin
/>

Important nuance:

font-display alone is not enough.
- It changes swap behavior, but it doesn’t guarantee metric compatibility.
Use metric-compatible fallbacks (or size-adjust) to reduce reflow when the custom font loads.

3) Treat late UI injection like a breaking change

Cookie banners, promos, “new feature” banners: if it mounts above content after initial paint, it’s likely a CLS hit.

Patterns that avoid CLS:

Render the space from the start (even if content fills later)
Overlay instead of pushing (carefully; don’t block content)
Insert below the fold

Tooling stack (Google-first, engineer-friendly)

Use each tool for what it’s good at.

Lighthouse

Best for:

Regression detection in CI
Controlled before/after comparisons
Catching obvious LCP/CLS issues early

Not best for:

Proving SEO impact
Predicting the 75th percentile

PageSpeed Insights (PSI)

Best for:

One-page snapshot that combines CrUX field data + lab
Communicating “field vs lab” to stakeholders

Chrome DevTools (Performance panel)

Best for:

Root cause analysis
Interaction traces for INP
Identifying long tasks, layout thrash, expensive paint

CrUX Dashboard

Best for:

SEO reality
Trend analysis over time
Segmenting by device class and connection

Search Console CWV report (use carefully)

It’s useful for broad monitoring, but it has sharp edges:

Aggregation can hide the worst templates
“Needs Improvement” can hide how bad the tail is
It’s not a debugging tool

SEO impact (brief and accurate)

Core Web Vitals are ranking signals (part of page experience).
They behave like tie-breakers, not magic bullets.
Bad CWV can cap growth because:
- You lose tie-breaks on competitive queries.
- User behavior (bounce/back-to-SERP) gets worse.
- Crawl and render efficiency can suffer on heavy pages.

Reference:

https://developers.google.com/search/docs/appearance/page-experience

Conclusion: optimize how users feel, not how pages score

Core Web Vitals stop being ambiguous the moment you treat them as engineering metrics:

LCP is about delivering the main content with minimal server delay and minimal render blocking.
INP is about keeping the main thread available for humans, not just for boot-time metrics.
CLS is about honoring layout as a contract.

The biggest shift (and the reason INP matters so much) is that performance is now interaction-first. It’s no longer enough to load quickly; you have to stay responsive.

And the non-negotiable rule still stands:

If it is not measured in the field, it does not exist.

Optimizing Core Web Vitals means optimizing how users feel, not how pages load.

Checklist (high leverage)

Baseline

Verify field reality: CrUX/PSI 28-day field data for key routes/templates.
Segment: mobile vs desktop; slow network vs fast; logged-in vs logged-out.
Pick a target: move the 75th percentile, not the median.

LCP

Identify the LCP element (field + lab).
Preload the LCP resource (usually hero image) and set fetchpriority="high".
Kill render-blocking work on the LCP path (CSS/JS/hydration).
Fix TTFB if it dominates the breakdown.

INP

Record real interactions in DevTools Performance.
Find long tasks around the interaction.
Split tasks and create paint opportunities.
Defer non-critical work (requestIdleCallback, post-task scheduling).
Reduce per-interaction work (virtualize, memoize, avoid full rerenders).
Audit third-party scripts with budgets.

CLS

Reserve space for images, embeds, and ads (width/height, aspect-ratio).
Preload critical fonts and use metric-compatible fallbacks.
Eliminate late-inserted UI above existing content.

@khriztianmoreno

A senior stands out for his thinking

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

The analysis of edge cases: a key to evaluating senior developers

The world of programming is constantly changing, but many companies still use outdated evaluation methods to measure the skills of senior developers. While theoretical tests are useful for measuring basic knowledge, they do not accurately reflect a senior's ability to solve complex real-world problems.

Why are traditional technical tests not enough?

Tests based solely on theoretical concepts fail to capture the true value of a senior developer. A senior's experience is measured by their ability to anticipate problems, design scalable solutions, and optimize systems. A good senior developer not only masters the code but also knows how to handle exceptions, manage complexity, and think critically in uncertain scenarios.

The practical approach: edge case analysis

A key exercise to evaluate a senior developer is to present them with a realistic scenario and ask them to identify and solve the edge cases. Take, for example, the development of a page with search and pagination. In a technical interview, an experienced senior should be able to think of extreme scenarios that could break the functionality, such as:

Search with no results: How would you handle a search that returns no results? How would you inform the user in a friendly manner and what impact would this have on performance?
Malicious terms: What if a user enters malicious code or unexpected characters in the search field? How would you protect the application from SQL injection or XSS attacks?
Non-existent pages: If the system receives a request for a non-existent page or with incorrect parameters, how would you handle URL validation to avoid 404 errors? What alternatives would you offer the user?
Excessive results: Imagine the search returns millions of results. How would you optimize pagination to prevent the application from crashing or becoming slow? What techniques would you use to ensure efficient loading?

Why is this approach important?

Evaluating a candidate in these scenarios not only measures their technical knowledge but also their ability to think proactively, manage exceptions, and anticipate problems. A senior developer must have the ability to design robust solutions that not only work in ideal cases but also cover those exceptional cases that may arise during the daily operation of the system.

Edge case analysis is a clear way to measure a senior's mindset. It is not enough for the candidate to solve a problem in the ideal scenario. The true test is how they respond when things do not go as planned, and if they can find effective solutions to maintain the stability, security, and usability of the system.

How should a senior be evaluated?

Realistic and practical tests: Beyond theoretical concepts, interviews should focus on challenges that reflect the real problems a senior developer faces. This involves evaluating how they manage edge cases and their ability to design scalable and secure solutions.
Evaluation of architectural decision-making: Seniors must be able to make informed decisions about software architecture, scalability, performance, and security. Interviews should explore these capabilities in depth.
Evaluation of interpersonal and leadership skills: Interviews should also include dynamics that explore communication, teamwork, and leadership skills, as these are crucial aspects of a senior's role.

In conclusion:

Traditional technical tests have their place, but they are not enough to effectively evaluate a senior developer. Companies should focus on a more holistic evaluation, where edge cases and critical decisions about software architecture and design are at the center of the assessment. Only then can we ensure that the selected candidates are truly capable of bringing the expected value to a development team.

What do you think about this? Do you agree that technical interviews for seniors should focus more on edge case analysis? What other aspects do you consider important for evaluating a senior?

References

Special thanks 🙏🏻 for their example to Freddy Montes
Taking the Edge off of Edge Cases

@khriztianmoreno 🚀

Using await at the top level in ES modules

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Using await at the top level in ES modules

As I was refactoring one of my React projects last week, I realized how much JavaScript has evolved since I first started coding. Remember when we had to wrap everything in callbacks? Then came Promises, followed by async/await. And now, in 2025, I find myself regularly using a feature that quietly changed the game for JavaScript developers: top-level await in ES modules.

The Evolution of Asynchronous JavaScript

Through my journey as a developer, I've witnessed the transformation of asynchronous JavaScript. In the early days, handling async operations meant callback hell—nested functions that became increasingly difficult to read and maintain. Then Promises arrived, offering a more structured approach but still requiring .then() chains.

When async/await appeared, it was a revelation. Suddenly our asynchronous code could look synchronous! But there was still one limitation that frustrated me daily: we could only use await inside async functions. This meant wrapping our module initialization code in unnecessary boilerplate:

// The old way we had to do things
(async () => {
  const data = await fetchImportantData();
  initializeApp(data);
})();

ES2022 changed everything by introducing top-level await. After using it extensively in my projects over the past few years, I can confidently say it's one of those features that once you start using, you never want to go back.

What Exactly Is Top-Level await?

Top-level await is exactly what it sounds like—the ability to use the await keyword directly at the top level of your ES modules, outside of async functions:

// This now works in ES modules
const data = await fetchImportantData();
initializeApp(data);

No more wrapping in async IIFEs (Immediately Invoked Function Expressions). No more unnecessary nesting. Just clean, straightforward code that expresses your intent directly.

Real-World Use Cases From My Projects

Over the past year, I've found myself reaching for top-level await in several common scenarios:

1. Configuration Loading

In my latest web app, I needed to fetch configuration before initializing the application. Top-level await made this beautifully simple:

// config.js
const config = await fetch('/api/configuration').then(res => res.json());
export default config;

// Other modules can now import this config

2. Dynamic Module Loading

I recently built a dashboard where features needed to be loaded based on user permissions. Top-level await paired perfectly with dynamic imports:

let analyticsModule;

if (userPermissions.includes('analytics')) {
  analyticsModule = await import('./features/analytics.js');
}

export const enabledFeatures = {
  analytics: analyticsModule?.default,
  // other features...
};

3. Database Connection Initialization

For a Node.js backend service I worked on, establishing the database connection before exporting the module was crucial:

// db.js
const connection = await createDatabaseConnection();

export async function query(sql) {
  return connection.query(sql);
}

Gotchas I've Learned the Hard Way

After using top-level await on several projects, I've encountered some pitfalls worth sharing:

Module Execution Is Not What You Might Expect

I once spent hours debugging a mysterious load order issue before I understood a key behavior: when a module uses top-level await, any module that imports it will pause execution until those awaited promises resolve.

In one particularly painful debugging session, I discovered that having a chain of modules with top-level await created a cascading delay effect that significantly slowed my application startup.

Watch Out for Circular Dependencies

In a complex React application I was developing, I created an unintentional circular dependency between two modules that both used top-level await. The result? A runtime error that was much harder to debug than usual circular dependency issues.

// Avoid patterns like this:
// moduleA.js
export const dataA = await fetchDataA();
import { dataB } from './moduleB.js';

// moduleB.js
export const dataB = await fetchDataB();
import { dataA } from './moduleA.js';

Compatibility in 2025

The good news is that in 2025, top-level await is well-supported across the JavaScript ecosystem:

All modern browsers fully support it
Node.js v16+ has stable support
Major frameworks like React, Vue, and Angular have embraced it
Bundlers like Vite, Webpack, and Rollup handle it elegantly

Just remember that top-level await only works in ES modules (not CommonJS), so you'll need to use:

Files with the .mjs extension, or
.js files with "type": "module" in your package.json

Why You Should Embrace Top-Level await Today

As I look back at my JavaScript code from just a few years ago, I'm amazed at how much more elegant and maintainable it's become thanks to features like top-level await. It's not just syntactic sugar—it fundamentally changes how we structure our modules.

By eliminating boilerplate async wrappers, our code becomes:

More readable
More maintainable
More directly expressive of our intent

The best part? This isn't some experimental feature we need to be cautious about anymore. It's a stable part of the language that you can confidently use in production code today.

Getting Started

If you're still not using top-level await in your projects, start today! Update your Node.js version if needed, ensure you're using ES modules, and begin refactoring those async IIFEs into clean, top-level async operations.

In my experience, this small change will make a noticeable difference in your code quality and developer happiness. As we move further into 2025 and beyond, I expect top-level await to become as standard in our JavaScript modules as imports themselves.

Have you started using top-level await in your projects yet? I'd love to hear about your experiences in the comments below!

What is immutability?

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Immutability in React and Redux

Immutability can be a confusing topic, and it appears everywhere in React, Redux, and JavaScript in general.

You may have encountered errors where your React components do not re-render, even though you know you have changed the props, and someone says, "You should be making immutable state updates." Maybe you or one of your teammates regularly writes reducers in Redux that mutate the state, and we have to constantly correct them (the reducers, or our teammates 😄).

It's complicated. It can be very subtle, especially if you're not sure what to look for. And honestly, if you're not sure why it's important, it's hard to care.

What is immutability?

First of all, immutable is the opposite of mutable, and mutable means changeable, modifiable... capable of being altered.

So, something that is immutable, then, is something that cannot be changed.

Taken to the extreme, this means that instead of having traditional variables, you would constantly be creating new values and replacing the old ones. JavaScript is not that extreme, but some languages do not allow mutation (Elixir, Erlang, and ML come to mind).

While JavaScript is not a purely functional language, it can sometimes pretend to be. Certain operations with arrays in JS are immutable (meaning they return a new array, rather than modifying the original). String operations are always immutable (they create a new string with the changes). And you can also write your own functions that are immutable. You just need to know a few rules.

A code example with mutation

Let's look at an example to see how mutability works. We'll start with this person object here:

So let's say we write a function that gives a person special powers:

Ok, everyone has the same power. No matter, invisibility is cool. Let's give some special powers to super Mafe.

This function giveAwesomePowers mutates the person object that is passed into it. If you run this code, you'll see that the first time we print a person, Mafe has no specialPower property. But then, the second time, she suddenly has the specialPower of invisibility.

The object returned by giveAwesomePowers is the same object that was passed in, but it has been modified internally. Its properties have changed. It has been mutated.

I want to say this again because it's important: the internal parts of the object have changed, but the object reference has not. It's the same object on the outside (so an equality check like person === samePerson will be true).

If we want the giveAwesomePowers function not to modify the person, we'll have to make some changes.

We won't go into much detail about the following code, because it will take center stage in the next post of this series.

Object.assign()

If you haven't seen Object.assign, what it does is assign properties from one object to another. Without modifying the original object, in short, Object.assign creates a copy of the original object with a new specialPower property.

👋 In my next post, we will address what a pure function is and why it is closely related to immutability, and we will focus on understanding the concept of side effects. 🤝

I hope this was helpful and/or taught you something new!

@khriztianmoreno 🚀

Mastering Chrome DevTools for Web Performance Optimization

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Turn Chrome DevTools from a viewer into a performance debugging weapon.

Most teams open DevTools too late. Or they look at the wrong panels, drowning in noise while missing the signals that actually affect user experience.

If you are a senior frontend engineer or performance owner, you know that "it feels slow" isn't a bug report—it's a symptom. This guide is for those who need to diagnose that symptom, understand the root cause, and verify the fix.

We are focusing on Chrome DevTools features that directly map to Core Web Vitals. No fluff, just the workflows you need to fix Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS).

1. Mental model: from symptom to root cause

Before clicking anything, you need the right mental model.
Metrics tell you what is wrong. DevTools explains why.

Performance isn't about magic numbers; it's about the Main Thread.
The browser's main thread is where JavaScript runs, HTML is parsed, and styles are calculated. It is a single-lane highway. If a heavy truck (a long task) is blocking the lane, fast cars (user clicks, animations) are stuck in traffic.

Key Rule: If the main thread is blocked, UX is broken.

2. Performance panel: the center of truth

The Performance panel allows you to record exactly what the browser is doing over a period of time. It records:

Main thread activity: JS execution, parsing, GC.
Rendering pipeline: Style calc, Layout, Paint, Compositing.
Network timing: When resources are requested and received relative to execution.
User input handling: How long the browser took to respond to a click.

Recording a useful trace

Idle traces are useless. You need interaction traces.

Open DevTools (Cmd+Option+I / Ctrl+Shift+I) and go to the Performance tab.
Check Screenshots and Web Vitals in the capture settings. Memory is usually optional unless you suspect a leak.
Click the Record button (circle icon).
Interact with the page (click the button, scroll the list, open the modal).
Click Stop.

3. Reading the Performance timeline

The resulting trace can be intimidating. Ignore 90% of it initially. Focus on these sections:
FPS & CPU: High-level health check. Solid blocks of color in CPU mean the main thread is busy.

Network: Thin lines showing resource loading order.
Main: The flame chart of call stacks. This is where you spend most of your time. Frames: Screenshots of what the user saw at that millisecond.

The Experience Track

This is your best friend. It explicitly marks:

LCP: Where the Largest Contentful Paint occurred.
Layout Shifts: Red diamonds indicating CLS.
Long Tasks: Tasks taking >50ms (red triangles).

Spotting Long Tasks

A "Long Task" is any task that keeps the main thread busy for more than 50ms.
In the Main section, look for gray bars with red triangles at the top corner. These are the tasks blocking the browser from responding to user input (INP).

4. Debugging LCP with DevTools

LCP measures loading performance. To fix it, you need to know what the element is and why it was late.

Identify the LCP element: In the Timings or Experience track, find the LCP marker.
Inspect the element: Hovering over the LCP marker often highlights the actual DOM node.
Analyze the delay:
- Resource Load Delay: Was the image discovery late? (e.g., lazy-loaded hero image).
- Resource Load Duration: Was the network slow or the image too large?
- Render Delay: Was the image loaded but waiting for a main-thread task to finish before painting?

Typical LCP root causes:

Late discovery: The <img> tag is generated by JavaScript or has loading="lazy".
Render blocking: Huge CSS bundles or synchronous JS in the <head> pausing the parser.
Server TTFB: The backend took too long to send the initial HTML.

<!-- ❌ Bad: Lazy loading the LCP element (e.g. Hero image) -->
<img src="hero.jpg" loading="lazy" alt="Hero Image" />

<!-- ✅ Good: Eager loading + fetchpriority -->
<img src="hero.jpg" loading="eager" fetchpriority="high" alt="Hero Image" />

Reference: Optimize Largest Contentful Paint

5. Debugging INP with DevTools

INP is the metric that kills single-page applications (SPAs). It measures the latency of user interactions.

Use the Interactions track: Look for the specific interaction (click, keypress) you recorded.
Expand the Interaction: You will see it broken down into three phases:
- Input Delay: Time waiting for the main thread to become free.
- Processing Time: Time running your event handlers.
- Presentation Delay: Time waiting for the browser to paint the next frame.

Visually correlate with the Main Thread:
Click the interaction bar. Look directly below it in the Main track.

If you see a massive yellow block of JavaScript under the interaction, your event handler is too slow (Processing Time).
If you see a massive block of JS before the interaction starts, the main thread was busy doing something else (Input Delay).

Common offenders:

JSON parsing large payloads.
React/Vue reconciliation (rendering too many components).
Synchronous loops or expensive calculations.

// ❌ Bad: Blocking the main thread with heavy work
button.addEventListener("click", () => {
  const result = heavyCalculation(); // Blocks for 200ms
  updateUI(result);
});

// ✅ Good: Yielding to main thread
button.addEventListener("click", async () => {
  showSpinner();

  // Yield to main thread so browser can paint the spinner
  await new Promise((resolve) => setTimeout(resolve, 0));

  const result = heavyCalculation();
  updateUI(result);
});

Fix workflow:
Identify the function in the flame chart → Optimize or defer it → Record again → Verify the block is smaller.

Reference: Interaction to Next Paint (INP)

6. Debugging CLS with DevTools

Layout shifts are annoying and confusing. DevTools visualizes them clearly.

Open the Command Menu (Cmd+Shift+P / Ctrl+Shift+P) and type "Rendering".
Enable "Layout Shift Regions".
As you interact with the page, shifted elements will flash blue.

In the Performance Trace:
Look at the Experience track for red diamonds. Click one.
The Summary tab at the bottom will list exactly which nodes moved and their previous/current coordinates.

Common CLS patterns:

Font swaps (FOUT/FOIT): Text renders, then the web font loads, changing the size.
Image resize: Images without width and height attributes.
Late injected UI: Banners or ads inserting themselves at the top of the content.

/* ❌ Bad: No space reserved for image */
img.hero {
  width: 100%;
  height: auto;
}

/* ✅ Good: Reserve space with aspect-ratio */
img.hero {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

Reference: Optimize Cumulative Layout Shift

7. Live Metrics screen

The Live Metrics view (in the Performance panel sidebar or landing page) provides real-time feedback without a full trace.

Why it matters:

Instant feedback: See LCP and CLS values update as you resize the window or navigate.
Field-aligned: It uses the same implementation as the Web Vitals extension.

Use cases:

Testing hover states and small interactions.
Validating SPA route transitions.
Quick sanity checks before committing code.

Note: This is still "Lab Data" running on your machine, not real user data (CrUX).

8. Insights panel

The Performance Insights panel is an experimental but powerful automated analysis layer. It uses the trace data to highlight risks automatically.

Key features:

Layout Shift Culprits: It points directly to the animation or DOM update that caused a shift.
Render blocking requests: identifies CSS/JS that delayed the First Contentful Paint.
Long main-thread tasks: suggestions on how to break them up.

Use Insights as a hint, not a verdict. It points you to the right place in the flame chart, but you still need to interpret the code.

9. CPU and Network throttling (Mandatory)

Developing on a MacBook Pro with fiber internet is a lie. Your users are on mid-tier Android devices with spotty 4G.

CPU Throttling:

set to 4x slowdown. This roughly simulates a mid-range Android device. It exposes "death by a thousand cuts"—small scripts that feel instant on desktop but freeze a phone for 300ms.

Network Throttling:
Fast 4G or Slow 4G.
Critical for debugging LCP (image load times) and font loading behavior.

Fast Wi-Fi hides bad engineering. Always throttle when testing performance.

10. Putting it all together: a repeatable workflow

Detect: Use PageSpeed Insights or CrUX to identify which metric is failing.
Reproduce: Open DevTools, enable Throttling (CPU 4x, Network 4G).
Record: Start tracing, perform the user action, stop tracing.
Inspect: Find the red/yellow markers in the Experience/Main tracks.
Fix: Apply the code change (defer JS, optimize images, reduce DOM depth).
Verify: Re-record and compare the trace. Did the long task disappear? Did the LCP marker move left?

Conclusion

DevTools is not optional. Performance is observable. Every Core Web Vitals issue leaves a trace; you just need to know where to look.

If you cannot explain a performance problem in DevTools, you do not understand it yet.

Resources:

I hope this has been helpful and/or taught you something new!

@khriztianmoreno

Until next time.

The Web Stack You Cannot Ignore in 2026

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

After going through roadmaps, specs, Chrome Dev Summit talks, and real signals from production, my prediction is simple:

Web development in 2026 moves toward more native capabilities, less unnecessary JavaScript, and performance you can measure in the real world.

This isn’t a “cool tools” list.
These are the areas that become non-optional.

1. Performance (Core Web Vitals + Soft Navigation)

If you only fix one thing, fix this.
Performance is the priority. No debate.

Why it will be vital in 2026

Google is doubling down on real user experience, not synthetic benchmarks.
Soft Navigation also changes how modern SPAs (and “MPA-like” apps) are evaluated.

In 2026:

If you don’t improve INP and LCP, you don’t just “lose SEO” — you lose conversions.
If you don’t measure soft navigations correctly, you’ll ship “faster” routes with fake metrics.

What changes

CLS stops being “cosmetic”.
INP fully replaces the old “FID mindset”.
SPA performance gets judged like an MPA.

What you should master

web-vitals in production
Long tasks (and what creates them)
Soft navigation heuristics
RUM > Lighthouse

Resources

2. Identity: Passkeys + FedCM

Traditional login is dying.
It just doesn’t know it yet.

Why it will be vital in 2026

Passwords are both a technical and legal liability.
Passkeys reduce friction and fraud.
FedCM is the browser’s real answer to identity in a world without third‑party cookies.

In 2026:

A product without passkeys will be perceived as outdated.
“Classic OAuth” without FedCM will degrade (or break) flows users care about.

What changes

Passwordless becomes normal.
Browser-native login UI becomes the expectation.
Less JS. More platform.

What you should master

WebAuthn
Passkeys UX patterns
FedCM flows
Privacy-preserving identity

Resources

3. Fugu / PWA APIs

The web talks to hardware now.
The debate is over — what’s left is execution.

Why it will be vital in 2026

Web apps compete directly with native when the capability gap is small.
Browsers keep shipping standards-based APIs, which means fewer dependencies and less glue code.

In 2026:

WebUSB, File System Access, and Badging stop being “rare”.
PWAs feel more and more like first-class apps when the use case fits.

What changes

Real offline capabilities
Deeper OS integration
Faster UX without native wrappers

What you should master

File System Access API
Background Sync
Badging API
PWA install heuristics

Resources

4. AI for Web Developers (Built-in AI APIs)

AI stops being “just a SaaS”.
It becomes part of the browser.

Why it will be vital in 2026

Lower latency.
More privacy (because local is the new default).
And better UX without forcing every product to build an expensive AI backend.

This is not “embed ChatGPT”.
This is native AI, progressively enhanced.

In 2026:

On-device AI becomes the default when available.
AI-driven UX becomes a real differentiator.

What changes

Smaller, faster models running locally
Fewer external calls
UI patterns that adapt in context

What you should master

On-device inference constraints (and fallbacks)
AI UX patterns (assistive, not intrusive)
Privacy-first AI
Progressive enhancement with AI

Resources

AI in Chrome

5. DevTools & Browser Automation

Traditional debugging doesn’t scale.

Why it will be vital in 2026

Apps get more complex.
Performance issues get more subtle.
And manual testing simply isn’t viable if you want speed and quality.

In 2026:

Observability from DevTools becomes a daily habit.
Automation becomes part of the workflow, not a “QA phase”.

What changes

Smarter DevTools
More integrated testing
Debugging centered on real UX

What you should master

Advanced Performance panel workflows
Lighthouse CI
Puppeteer / Playwright
Tracing and deep profiling

Resources

My final prediction (no marketing)

If I had to bet on only one foundation:

Performance + Identity will be the base.
Everything else sits on top of that.

The web in 2026 will be:

More native
Faster
More private
Less dependent on “framework magic”

The rest is noise.

I hope this has been helpful and/or taught you something new!

@khriztianmoreno

Until next time.

Rust is revolutionizing JavaScript development!

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Rspack just released version 1.0 , and the dream of using Rust-based build tools to speed up the JavaScript ecosystem is more alive than ever. How did we get here? Early last year, a team of developers at ByteDance was facing performance issues maintaining the company’s “many large monolithic applications.” So they did what any good developer would do: they blamed webpack. But they didn’t stop there. In March 2023, they released Rspack v0.1, a high-performance JavaScript bundler written in Rust and designed to be fully compatible with the webpack ecosystem.

Fast forward to today, and Rspack now has 100k weekly downloads and has introduced key improvements that make it production-ready:

Better performance: New features like lazy compilation and other performance optimizations make Rspack 1.0 build times over 20x faster than webpack 5.
Increased webpack compatibility: Over 80% of the top 50 downloaded webpack plugins can now be used in Rspack, bringing it closer to becoming a true drop-in replacement for webpack.
Reduced complexity: They created a new toolchain called Rstack that includes separate projects like Rsbuild, Rspress, and Rslib, each targeting different use cases. This reduces the complexity of setting up an all-in-one tool like Rspack (or webpack), while still maintaining flexibility.

Bottom line: Rspack offers a pretty simple value proposition for developers: if you already use webpack, it will make it much easier for you to migrate to its bundler which is faster, easier to use, and still fully compatible with the webpack API. Time will tell if that will be enough to convince the masses to try it out.

Streaming AI without destroying your INP

Khriztian Moreno — Tue, 20 Oct 2026 13:00:00 +0000

Your AI feature is the new INP culprit.

For years, the usual suspects for a bad Interaction to Next Paint score were the same: bloated bundles, unthrottled scroll handlers, a chart library re-rendering on every mouse move. Now there's a new one, and it's the feature everyone is shipping right now — streaming a language model's answer straight into the DOM.

This post has a full, runnable demo behind it — demos/streaming-ai-without-destroying-your-inp, in the repo that powers this site. It needs Chrome flags most readers won't have enabled, so there's no hosted version to click into — clone it (or just read the files on GitHub) and run it locally per the README. Rather than pasting isolated snippets, I'm going to walk through the actual files: a naive implementation that wrecks your INP, and an optimized one that doesn't, both wired to a live INP readout so the difference is something you can watch happen, not just take my word for.

How the demo works

Run it locally and you'll see three things: a prompt box with a strategy switch above it, an output area, and an INP log below. The flow is:

Pick a strategy — "Naive (per-chunk, no yield)" or "Optimized (sentence batching + yield)" — with the same prompt in both.
Hit Generate. The model starts streaming into the output area using whichever strategy you picked.
While it's still generating, click "🔘 Click me while it's generating" a few times. That button does nothing on purpose — its only job is to give you something to interact with mid-stream, the same way a user would tap "stop" or scroll while your chat UI is still talking.
Watch the INP log. Every click reports its measured latency there, in real time, via web-vitals' onINP — no DevTools required, though you should open DevTools' Performance panel too for the full trace.
Hit Stop any time to see the AbortController actually cancel the in-flight generation, instead of leaving a zombie session writing to a component nobody's looking at anymore.

Run the naive strategy first, mash the probe button, and watch the log fill with high numbers. Then switch to optimized, same prompt, and watch the same clicks come back low. That side-by-side is the whole point of the demo.

Why streaming text breaks INP

On-device models like Gemini Nano expose their output through the Prompt API's promptStreaming(), which returns a ReadableStream of text chunks:

const session = await LanguageModel.create();
const stream = session.promptStreaming('Explain quantum entanglement.');

for await (const chunk of stream) {
  console.log(chunk);
}

Two things about that loop are easy to miss and both matter for performance:

Each chunk is an incremental delta, not the full text so far. You have to concatenate them yourself to reconstruct the answer.
Chunks arrive fast — often several per second — and the obvious thing to do with each one is to append it to the DOM immediately, so the text "types itself" on screen.

That second instinct is exactly what the demo's naive.js implements:

export async function naiveStreamAnswer(prompt, onChunk, signal) {
  const session = await LanguageModel.create({ signal });
  const stream = session.promptStreaming(prompt, { signal });

  for await (const delta of stream) {
    onChunk(delta);
  }

  session.destroy();
}

Every DOM write triggered by onChunk is a task on the main thread: a text node mutation, a reflow, sometimes a re-render if you're piping the chunk through a framework's state. Do that dozens of times per second and you've built a wall of small-but-frequent tasks that never lets the main thread breathe. If the user clicks "stop" or types into another field while the model is still talking, that input sits in the queue behind your DOM churn — and that queueing delay is exactly what INP measures.

The fix isn't "stream slower." It's controlling where you flush to the DOM and how often you hand control back to the browser — which is what the demo's other implementation, lib.js, does.

The building blocks

1. Batch by sentence, not by token

Painting per-token feels responsive in a demo, but it's the most expensive possible cadence — and for languages like Spanish, breaking mid-word or mid-punctuation looks broken. Intl.Segmenter (Baseline since April 2024) gives you locale-aware sentence boundaries for free:

const segmenter = new Intl.Segmenter('es', { granularity: 'sentence' });

for (const { segment } of segmenter.segment(text)) {
  console.log(segment); // one full sentence at a time
}

Segmenting by sentence means one DOM write per sentence instead of one per token — often an order of magnitude fewer updates — and it respects abbreviations and punctuation rules per locale, which a naive text.split('. ') does not.

Here's what that looks like on an actual run, prompting the demo with "Write two short sentences describing a sunrise over the mountains." Gemini Nano streamed back 37 deltas — mostly word fragments:

"Golden" " light" " kissed" " the" " jagged" " peaks" "," " slowly"
" chasing" " away" " the" " lingering" " shadows" " of" " night" "."
"  " "Warm" " hues" " painted" " the" " sky" "," " transforming"
" the" " mountains" " into" " majestic" " silhouettes" " bathed"
" in" " a" " new" " dawn" "." " " "\n\n\n\n"

The naive strategy turns every one of those into its own DOM write — 37 tasks. Run the exact same deltas through the sentence-batching logic above and you get 5 writes, 2 of which carry all the actual content:

1. "Golden light kissed the jagged peaks, slowly chasing away the lingering shadows of night.  "
2. "Warm hues painted the sky, transforming the mountains into majestic silhouettes bathed in a new dawn. \n"
3. "\n"   4. "\n"   5. "\n"

Same model output, same total text — 37 DOM writes down to 5, and the last three are trailing newlines the model tacked on at the end, not meaningful content. That's the entire optimization in one concrete before/after.

2. Give the main thread room to breathe

Even at sentence granularity, a long answer can still queue up enough DOM writes to block input. Between updates, lib.js hands control back to the browser with scheduler.yield():

export function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

scheduler.yield() isn't Baseline yet, so the fallback matters — without it, this whole strategy silently stops working on browsers that don't support it. The point of yielding isn't to slow the stream down; it's to insert a checkpoint where a pending click or keystroke can be processed before you resume writing.

3. Let people cancel it

An AbortController should exist from the moment generation starts, not as an afterthought — a model that keeps flushing sentences to a component the user has already navigated away from is its own kind of bug. In the demo, main.js creates the controller on every "Generate" click and wires the "Stop" button straight to controller.abort().

Putting it together

This is the full lib.js — sentence batching, yielding, and cancellation, in one function:

export async function streamAnswer(prompt, onSentence, signal) {
  const session = await LanguageModel.create({ signal });
  const segmenter = new Intl.Segmenter('es', { granularity: 'sentence' });

  const stream = session.promptStreaming(prompt, { signal });
  let buffer = '';
  let cursor = 0;

  for await (const delta of stream) {
    buffer += delta;

    // The last segment in a partial buffer might still be growing,
    // so only flush the ones that are already complete.
    const segments = [...segmenter.segment(buffer)];
    const complete = segments.slice(0, -1);

    for (const { segment, index } of complete) {
      if (index < cursor) continue;
      await yieldToMain();
      onSentence(segment);
      cursor = index + segment.length;
    }
  }

  const tail = buffer.slice(cursor);
  if (tail) onSentence(tail);

  session.destroy();
}

One honest caveat, straight from testing this in the demo: re-segmenting the whole buffer on every chunk means the cost grows with the length of the answer, and Intl.Segmenter can occasionally revise where a boundary falls once more text arrives (an abbreviation like "Dr." resolving differently once the next word shows up). For sentence-level batching this is rarely noticeable, but it's worth knowing before you assume the output is byte-identical to segmenting the final text in one pass.

The on-screen INP log comes from metrics.js, which is short enough to paste in full — it just wires web-vitals' onINP straight to a <ul>:

import { onINP } from 'https://unpkg.com/web-vitals@5?module';

onINP((metric) => {
  const target = metric.entries.at(-1)?.target;
  const label = target?.id || target?.tagName?.toLowerCase() || 'unknown target';
  const item = document.createElement('li');
  item.textContent = `${metric.value.toFixed(0)}ms — ${label}`;
  document.getElementById('inp-log')?.prepend(item);
});

If LanguageModel isn't defined yet in your browser when you run it, the page will tell you — the README covers the Chrome flag you need.

Measuring before and after

Don't ship this on faith — profile it. When I ran the naive strategy in this demo and let a long answer stream while clicking the probe button, DevTools' Performance panel showed a dense row of small tasks in the main thread track, back-to-back, no gaps — and the probe clicks logged high in the INP log. Switching to the optimized strategy with the same prompt, the trace shows short tasks separated by visible gaps, and the same probe clicks come back low.

metric.entries in the onINP callback points you straight at the specific interaction that was slow and which task blocked it — that's your evidence, not a guess, for whether the batching actually helped. Run it yourself with your own prompts; the numbers will vary by device and answer length, but the shape of the two traces won't.

What's next

This same shape — small, frequent updates fighting the main thread — shows up anywhere a model streams into a live page, not just chat UIs. Chrome's built-in AI stack keeps expanding (the Rewriter API for on-device rewriting, WebMCP for exposing page actions to agents, both covered at Chrome at I/O '26), and every one of them will hand you output the same way: incrementally, on your terms for when to paint it.

The API gives you the tokens. Keeping INP healthy is still your job.

I hope this has been helpful and/or taught you something new!

@khriztianmoreno 🚀

DEV Community: Khriztian Moreno

Hacks for effective Fullstack development with React and Node

Monorepo Setup for React and Node

1. Running two servers at the same time

2. Installing front-end and back-end dependencies with a single command

3. Proxy API requests from the backend

Semantic markup for AI: turn your forms into WebMCP tools without JavaScript

How the demo works

The problem: every tool needed JavaScript

Building block 1: the same contract, written in HTML

Building block 2: from form to JSON Schema (and why it's TBD)

Building block 3: toolautosubmit or human review

Find, preview, commit

Building block 4: agentInvoked and respondWith(), where JavaScript comes back

Building block 5: Web Components that take part

Building block 6: real progressive enhancement

An honest caveat: this is even earlier than part 1

What I learned building this

To keep exploring

How to mock an HTTP request with Jest 💻

Step 1: Setting up your project

Step 2: Write a function with an API call

Step 3: Create the Test File

Step 4: Run the test

Step 5: Review the results

Some methods beyond console.log in Javascript

1. console.table()

2. console.trace()

3. console.error() and console.warn()

4. console.assert()

5. console.time(), console.timeEnd(), and console.timeLog()

Demystifying Core Web Vitals - A Developer's Guide to LCP, INP, and CLS

Core Web Vitals are engineering work, not a Lighthouse mini-game

Core Web Vitals (quick overview)

Field data vs lab data (why your “green Lighthouse” can still fail)

LCP (Largest Contentful Paint)

What actually counts as LCP

Measure LCP (code)

Common real-world LCP killers

Fixes that actually work

1) Make the hero request early (and intentionally)

2) Stop hydration from blocking the first meaningful render

3) Fix TTFB before you touch images

Framework callout (Next.js)

INP (Interaction to Next Paint)

Why FID was misleading (and why Google replaced it)

How INP works (the mental model)

Measure INP (code)

Typical INP problems (what I see most often)

1) Long JS tasks

2) Overhydration / excessive client work

3) Third-party scripts

Debugging INP: go from metric → interaction → long task

Fix patterns that move INP

1) Defer non-critical work off the interaction path

2) Split long tasks (don’t just “optimize” them)

3) Make UI updates interruptible (React example)

4) Reduce the amount of work per interaction

5) Put third-party on a leash

CLS (Cumulative Layout Shift)

Why CLS still fails teams

Measure CLS (code)

Fixes that matter

1) Reserve space for media

2) Don’t let fonts surprise layout

3) Treat late UI injection like a breaking change

Tooling stack (Google-first, engineer-friendly)

Lighthouse

PageSpeed Insights (PSI)

Chrome DevTools (Performance panel)

CrUX Dashboard

Search Console CWV report (use carefully)

SEO impact (brief and accurate)

Conclusion: optimize how users feel, not how pages score

Checklist (high leverage)

Baseline

LCP

INP

CLS

A senior stands out for his thinking

Building block 3: `toolautosubmit` or human review

Building block 4: `agentInvoked` and `respondWith()`, where JavaScript comes back

1. `console.table()`

2. `console.trace()`

3. `console.error()` and `console.warn()`

4. `console.assert()`

5. `console.time()`, `console.timeEnd()`, and `console.timeLog()`