Marko in July 2026

Marko Run

Request validation, data loading, and URL construction became first-class in @marko/run, with type inference flowing from the handler through to pages and layouts (run#198).

In a +handler file, the verb helpers accept validation options for path parameters, the query string, and the request body. A validator is either a function or a Standard Schema, and validators are lazy, so a request that never reads ctx.search never pays to validate it.

export const GET = Run.GET(
  {
    params(value) {
      return { clientId: Number(value.clientId) };
    },
    search: InvoiceFilters,
  },
  (ctx, next) => next({ invoices: loadInvoices(ctx.params.clientId, ctx.search) }),
);

Handlers pass data downstream by calling next with an object, which templates read as $global.data. Passing the promise rather than awaiting it lets the response begin streaming while the data is still in flight, covered in Data Loading.

Run.href builds URLs against the routes the application actually serves, with the path, params, search, and hash all type checked. Renaming or moving a route turns stale links into compile-time errors instead of broken anchors, and client builds rewrite statically analyzable calls at compile time so most cost nothing at runtime (Typed URLs).

<await|invoices|=$global.data.invoices>
  <for|invoice| of=invoices>
    <a href=Run.href("/invoices/$clientId/$invoiceId", {
      params: {
        clientId: invoice.clientId,
        invoiceId: invoice.id
      }
    })>
      ${invoice.number}
    </a>
  </for>
</await>

<await|invoices|=$global.data.invoices>
  <for|invoice| of=invoices>
    <a href=Run.href("/invoices/$clientId/$invoiceId", {
      params: { clientId: invoice.clientId, invoiceId: invoice.id },
    })>
      ${invoice.number}
    </a>
  </for>
</await>

await|invoices|=$global.data.invoices
  for|invoice| of=invoices
    a href=Run.href("/invoices/$clientId/$invoiceId", {
      params: {
        clientId: invoice.clientId,
        invoiceId: invoice.id
      }
    }) --
      ${invoice.number}

await|invoices|=$global.data.invoices
  for|invoice| of=invoices
    a href=Run.href("/invoices/$clientId/$invoiceId", {
      params: { clientId: invoice.clientId, invoiceId: invoice.id },
    }) --
      ${invoice.number}

A POST handler calling next now renders the page instead of falling through to the GET handler. The documentation grew alongside the feature, with new guides covering routing, validation, data loading, and the runtime (website#183).

Performance

The optimization work this month split between the code pages ship and the compiler developers install.

Pages stopped carrying runtime they cannot use. A spread onto any native tag used to pull in every controlled-element handler, so a page that only spread onto a <div> still shipped the machinery for <select>, <input>, and <textarea>. Such a page now ships roughly 37% less JavaScript, dropping from 2,614 to 1,641 bytes after brotli, and one spreading onto a <textarea> drops from 1,981 to 1,529. Pages that genuinely use every control kind are unchanged (marko#3622).

Selecting a row in a keyed <for> became an O(1) update. When a value outside the loop is read inside it only as an equality against the loop's key, a change can flip at most two rows, so the compiler updates just those two instead of walking the list. The update measures flat from 1,000 to 20,000 rows, and loops that do not match the pattern are unaffected (marko#3314).

Server rendering got faster and its output got smaller. Rendering a page spends less time producing the same bytes (marko#3411), and every <if> and <for> branch on the page now sends less data to the browser to resume from (marko#3320). Serving those renders got faster too: a Marko Run application on Node measured about 6% higher requests per second on a 16 KB page and about 3% on a 455-byte page in a local benchmark (run#214).

The compiler itself got smaller as well, dropping from 2,084 KB to 1,626 KB on Node (about 22%) and from 1,966 KB to 1,509 KB in the browser (about 23%). It compiles to byte-identical output, so the saving is purely in what gets installed and loaded (marko#3688).

Application-level techniques are collected in Optimizing Performance.

Dynamic Styles

The <style> core tag accepts ${...} interpolations. The stylesheet itself stays static and is still extracted into the bundle, with the changing values delivered through CSS custom properties. Every instance gets its own values, they update independently in the browser, and they work under a CSP nonce.

<style>
  
  .status-pill {
    background: ${input.tint};
    padding-inline: calc(${input.pad} * 1px);
  }

</style>
<span class="status-pill">${input.label}</span>

<style>
  .status-pill {
    background: ${input.tint};
    padding-inline: calc(${input.pad} * 1px);
  }
</style>

<span class="status-pill">${input.label}</span>

style
  --


    .status-pill {
      background: ${input.tint};
      padding-inline: calc(${input.pad} * 1px);
    }


  --
span class="status-pill" -- ${input.label}

style
  --

    .status-pill {
      background: ${input.tint};
      padding-inline: calc(${input.pad} * 1px);
    }

  --

span class="status-pill" -- ${input.label}

Interpolated values are escaped, so user input cannot break out of the stylesheet. Interpolations belong in property values rather than in selectors, property names, or quoted strings, and a unit belongs inside the value or a calc() rather than written against the interpolation. A dynamic <style> applies to the elements after it, so it goes above the content it styles (marko#3309).

Agent Guidance

A run of work aimed the compiler's diagnostics and the published packages at coding agents as well as the developers supervising them.

The compiler's diagnostics now suggest the Marko form to write when a template reaches for a habit carried over from another dialect, whether in control flow, tag variables, or attribute values. Each suggestion states the correct general form only, never task-specific content (marko#3388). A template's errors are also reported together rather than one at a time, so a single compile surfaces everything to fix (marko#3390).

The marko package now ships a dense syntax reference at cheatsheet.md, covering the Tags API rules, control flow, async rendering, components, and client effects. Publishing it inside the package gives tooling a stable path to point agents at, and @marko/vite and @marko/run ship the same reference and route agents to it (marko#3392, vite#283, run#212).

Improvements

The rest of the month's feature and tooling work centered on pnpm support, serialization, and the playground.

Fixes

Correctness work concentrated on controlled elements, resuming, and asynchronous rendering. Server and browser rendering came into agreement across <select>, <textarea>, and radio groups, covering form reset, value coercion, and multiple selections in any order, so a controllable element ends up in the same state either way. Roughly two dozen resume fixes followed, including one where a single unserializable value could take down a page's whole resume rather than just reporting itself. Placeholder and error-boundary behavior improved across <await> and <try>, lazy loading triggers and fallbacks were hardened, and module resolution no longer loops forever at a Windows drive root.

Full details for every change are in the release notes of each package on GitHub.

Community

Further Reading

• June 2026

Contributors

Helpful? You can thank these awesome people! You can also edit this doc if you see any issues or want to improve it.

• DylanPiercey
• You?