DEV Community: defunkt-dev

This Framework Was Streaming HTML Before It Was Cool. Learn It in 135 interactive in-Browser Lessons 🚀

defunkt-dev — Mon, 03 Aug 2026 16:07:16 +0000

defunkt-dev

Aug 1

This Framework Was Streaming HTML Before It Was Cool. Learn It in 135 Browser Lessons

#webdev #javascript #tutorial #frontend

7 min read

This Framework Was Streaming HTML Before It Was Cool. Learn It in 135 Browser Lessons

defunkt-dev — Sat, 01 Aug 2026 02:35:20 +0000

What this about?

A free interactive tutorial for Marko 6. Real dev server in a WebContainer, covering 0 kB pages, resumability, out-of-order streaming, SSE, and app federated microfrontends.

When React 18 shipped Suspense-aware incremental streaming SSR in 2022, it felt like a breakthrough.Marko has been streaming HTML since 2014 😏. It powered eBay's product pages back when server rendering was considered a legacy technique. It ships zero JavaScript for static pages. Not a small runtime. Zero. It had a compiler before frontend frameworks had a compiler!

The framework was never the problem. The problem was that trying it meant a lot of setup time.

So I built a tutorial that removes the setup. 135 lessons across 12 parts, running in your browser:

markojs-tutorial.netlify.app

No install, no signup. A real @marko/run app boots inside a StackBlitz WebContainer in your tab. Lesson text on the left, a live editor with a terminal and preview on the right. Edits hot-reload. Every exercise has a Solve button, and every lesson can be downloaded as a runnable project.

It's built with TutorialKit, plus a custom CodeMirror package that runs Marko's actual VS Code TextMate grammar through shiki's WASM engine, so highlighting in the lesson editor matches your IDE exactly.

Here are the patterns the tutorial teaches, and why they're worth your time.

1. Your page is HTML, your interactivity is surgical

A .marko file is HTML with a few additions:

<let/count=0/>

<button onClick() { count++ }>
  Clicked ${count} times
</button>

That's a complete reactive component. No imports, no useState, no export. <let> declares state, and assigning to it is what triggers the update.

The interesting part is what the compiler does next. Marko splits every template into two programs, one for the server and one for the client (Btw, marko had multiple compilation outputs before Svelte), and the client program contains only what the browser actually needs. One lesson has you build a page, run node inspect.mjs, and read the resulting bundle yourself:

Static markup becomes plain HTML and ships no JS
Server-only computation (a formatPrice helper) stays on the server and never appears in the bundle
The one interactive widget is the only thing that ships
And an interesting thing to note, Marko does sub-component hydration. This goes beyond islands.

A fully static Marko page ships 0 kB of client JavaScript. Not hydrated cheaply. Not shipped at all.

2. Resumability: the client doesn't re-run your code

Traditional hydration re-executes the client-side component logic for each hydrated boundary so the framework can reconstruct its runtime and wire up interactivity.

Marko 6 resumes instead. The tutorial demonstrates it with a component that has a render-time console.log and a button. The log shows up once, in the server terminal. The browser console stays silent. The button still works. The client never re-ran the render logic; it picked up serialized markers from the HTML and continued from there.

Your render code runs once. You watch it happen live.

3. Streaming: three tags cover everything

The tutorial dedicates whole parts to this (3, 10 and 11), including recreations of Marko's classic streaming demos.

Streaming means sending HTML chunk by chunk as each piece is ready, instead of buffering the whole page. The browser starts parsing, and starts fetching your CSS, fonts and JS, while your slow database query is still running.

`<await>` for in-order streaming

<h1>Dashboard</h1>

<await|signups|=loadSignups()>   <!-- 1s -->
  ${signups.total} new signups
</await>

<await|traffic|=loadTraffic()>   <!-- 3s -->
  ${traffic.views} views
</await>

The stream holds at each <await> and releases in document order. Simple, no client JS, but the slow section blocks everything below it.

`<try>` with `<@placeholder>` for out-of-order streaming

Wrap the slow section:

<try>
  <await|traffic|=loadTraffic()>
    ${traffic.views} views
  </await>

  <@placeholder>
    Crunching traffic numbers…
  </@placeholder>
</try>

Now the server doesn't hold. It streams the placeholder immediately, keeps going with the rest of the page, and when the promise settles it streams the real content, which replaces the placeholder in place. Content below the fold can arrive before content above it. Out of order, on purpose. Note, that while it streams out-of-order, the order is proper at paint.

`<@catch>` for errors

Same <try> block, rejection path. In the progressive-rendering lesson, the main section races a 5-second timeout with Promise.race, and <@catch> renders the fallback if it loses.

One more thing the tutorial makes a point of: <await> is the same tag on the client. When a browser interaction swaps the promise you're awaiting, the same <await> re-renders the result client-side. One mental model for both runtimes.

The streaming-search lesson recreates Marko's old v3 demo: a single Express handler, template.render({}).pipe(res), and 30 search results arriving in batches down one held-open HTTP response. Pure HTML, no client JavaScript. You can watch the raw HTTP body arrive in chunks.

4. Rendering a live stream with recursion

<for> can't iterate an async stream, so how do you render "one item per event until the stream ends"? You recurse.

<define/Wait>
  <try>
    <await|messages|=Promise.any([
      once(messageStream, "done"),
      once(messageStream, "data"),
    ])>
      <if=messages && messages.length>
        <Notice message=messages[0].message/>
        <Wait/>                     <!-- render the next one -->
      </if>
    </await>
    <@placeholder>Waiting for the stream…</@placeholder>
  </try>
</>

<Wait/>

<define> creates a reusable snippet named Wait. It awaits the next stream event, renders one <Notice>, then invokes itself, so each notice nests inside the last as its own branch of the render tree. When the stream signals done, the <if> fails and the recursion stops.

The payoff: every notice hydrates independently and stays interactive (each has its own dismiss button), even though they arrived one at a time over a live stream. I haven't seen this pattern documented anywhere else.

5. SSE and EventSource

Part 9 covers the browser's native EventSource API, the simplest real-time primitive on the web:

const source = new EventSource("/api/ticker");
source.onmessage = (ev) => { /* a new event arrived */ };

One long-lived HTTP response. The server writes data: frames whenever it wants, the browser fires events. No WebSocket handshake, no library, and reconnection is built in.

Part 10 then combines SSE with the next pattern.

6. App federation: micro-frontends without the iframe tax and the hassle of module federation

Module federation shares code between apps. App federation shares rendered apps. Part 10 teaches it with @micro-frame/marko, running a host app and a remote app at the same time in the same browser tab. Two dev servers, one WebContainer.

The host embeds the remote with one tag:

<micro-frame src="http://localhost:3001/fragment" client-reorder timeout=0>
  <@loading>Loading the remote notice…</@loading>
  <@catch|err|>The remote is unavailable: ${err.message}</@catch>
</micro-frame>

<micro-frame> fetches the remote's fully rendered HTML and transcludes it in place. You get iframe-style ownership isolation with none of the iframe box. The remote team deploys independently, and the host only knows a URL. Loading and error states are just attribute tags.

The SSE chapter pushes this further with a faucet-and-slot pair:

<!-- the faucet: opens ONE SSE stream, renders nothing -->
<micro-frame-sse timeout=0 name="notices"
  src=`http://localhost:3001/sse-notices?slotName=main`
  read(ev) { return [ev.lastEventId, JSON.parse(ev.data), false]; }
/>

<!-- the slot: streamed chunks land here -->
<micro-frame-slot from="notices" slot="main" timeout=0 client-reorder>
  <@loading>Waiting for notices…</@loading>
</micro-frame-slot>

The remote pushes rendered HTML fragments as SSE frames, each tagged with a slot id, and the host drops each chunk into the matching slot. The multi-slot lesson streams different fragments to different regions of the host page over a single connection. Every arriving fragment hydrates and stays interactive.

A live-updating, independently deployed micro-frontend, with loading and error states, in roughly ten lines of template.

7. The Hacker News app

Part 12 tours the official Marko Hacker News reader, adapted to Marko 6, running live in your browser:

File-based routing (+page, story.$id+page, +layout)
server import keeping the API client server-side
Story lists streaming in through <await>
A self-recursive comment.marko rendering nested threads to any depth
Collapse toggles with <let>

And the bundling payoff, measured: the list and user pages ship 0 kB of client JS. Only the story page ships anything, and that's just the bytes for its collapse toggle.

Why the format matters

Everything actually runs in your browser, in an interactive manner. The dev server, the terminal, hot reload, even two federated apps at once, all inside a WebContainer in your tab.

Every exercise ships its starting files and its solution. Stuck? Solve shows the finished state. Want to keep going? Download the lesson as a complete runnable project.

And the scope goes well past the basics: fundamentals, reactivity, async and error boundaries, components in depth, @marko/run full-stack routing, streaming, progressive rendering, SSE, micro-frontends, GraphQL, SPA routing, CSP nonces, deployment adapters for Node, static and Netlify Edge, and using Marko without its meta-framework at all.

Try it

Open markojs-tutorial.netlify.app
Jump to Part 11 (Streaming) for the fireworks, or Part 1 if you're new
Break something, hit Solve, download the lesson

The repo is open source at github.com/defunkt-dev/markojs-tutorial. Stars ⭐️ and issues welcome.

The ecosystem spent a decade arriving at streaming HTML, islands, and shipping less JavaScript. Marko had the answers the whole time. Now there's a place to learn them 🚀, in your browser, for free & we are taking it to the world for everyone to see.

auto-animate now speaks marko

defunkt-dev — Wed, 15 Jul 2026 08:50:08 +0000

As of @formkit/auto-animate@0.10.0, the library ships an official Marko adapter (PR #239).

If you write Marko 6, you can now get animated list additions, removals, and reorders with one tag and no per-item work:

npm install @formkit/auto-animate

import AutoAnimate from "@formkit/auto-animate/marko"

<let/items = [
  { id: 1, text: "Mango" },
  { id: 2, text: "Papaya" },
]>

<ul/listRef>
  <for|item| of=items by="id">
    <li>${item.text}</li>
  </for>
</ul>
<AutoAnimate parent=listRef/>

That's the whole integration. Mutate items however you like (push, filter, reverse, shuffle) and the DOM changes animate. There's a live demo covering the full API, server-rendered with @marko/run: demo · source.

The rest of this post is the part that's actually interesting: what shape an auto-animate adapter should take in a framework that has no directives, no hooks, does not perform a hydration re-render during initialization/resume (it resumes the server-rendered DOM in place) and what we learned when the published package met the newest Vite.

Marko in sixty seconds

If you haven't met Marko: it's an HTML-based language for building reactive UIs, born at eBay (it powers eBay.com) and now under the OpenJS Foundation. Nearly any valid HTML is valid Marko; you add reactivity with tags instead of a component API:

<let/count=0>
<button onClick() { count++ }>
  Clicked ${count} times
</button>

Three properties matter for this article:

Fine-grained by compilation. The compiler analyzes which parts of a template are actually interactive and ships JavaScript only for those, at sub-template granularity. Static content ships zero JS. This goes further than islands: you don't declare server versus client components, the compiler works it out from the state tree.
Resumable, not hydrated. The server's HTML is the app. The client picks it up where the server left off, with no re-render pass to rebuild a component tree. (This is the property the SSR section below hinges on.)
Tiny output. In an independent comparison that built the same kanban app in ten frameworks, Marko shipped the smallest bundles of all: 6.8 kB compressed for the homepage and 28.8 kB for the full interactive board, versus 176.1 kB for Next.js. Our own numbers agree: every fully interactive route in the demo linked above ships about 10 kB of gzipped JavaScript in total, framework runtime and animation library included. Marko's runtime is estimated to be 7KB Gzipped.

Marko also streams HTML (in-order and out-of-order) as it's ready and has built-in TypeScript support. @marko/run is its file-based SSR meta-framework, which the demo uses.

What auto-animate is (and isn't)

auto-animate does exactly one thing: when the direct children of an element are added, removed, or moved, it FLIP-animates the change. No springs, no gestures, no orchestration, no timelines. Its about 14K stars are for the effort-to-payoff ratio, not for depth. It's the animation you were never going to hand-write for every CRUD list in your app, delivered in one line.

That small surface matters for this story. It's why a complete Marko adapter fits in a ~45-line tag, and why the demo linked above covers the complete Marko-adapter surface in five routes.

The adapter's shape: why a tag

Every framework adapter in this library mirrors its host framework's idiom. React and Preact get a hook that returns a ref. Vue and Angular get a directive you sprinkle on the parent element. Solid gets a directive too. Svelte uses actions.

Marko has none of those primitives, and it turns out not to need them. The adapter is a tag with three attributes:

<AutoAnimate
  parent=listRef      // a native element tag-variable
  options={ duration: 300, easing: "ease-in-out" }  // or a plugin function
  enabled=showMotion  // reactive boolean
/>

parent is a Marko tag-variable: write <ul/listRef> and pass listRef. The target is explicit and typed, with no wrapper element and no DOM query.
options takes the same object as the core (duration, easing) or a plugin function. It's read once when the tag mounts, matching the core's behavior (there is no setOptions).
enabled is reactive. Flip it and the adapter calls the underlying controller's enable()/disable() for you.

The honest trade-off versus a directive: two touch points instead of one. You name the parent and place a tag, where Vue users write a single v-auto-animate. What you get back is more than the ceremony costs:

Reactive enable/disable as a plain attribute. In hook-based adapters, runtime toggling means capturing a second return value and calling methods on it. In directive-based ones it's awkward or impossible. In Marko it's an attribute bound to any reactive value. The demo drives it with a two-way-bound checkbox (checked:=enabled) and nothing else:

<let/enabled = true>
<input type="checkbox" checked:=enabled/>

<ul/listRef> ... </ul>
<AutoAnimate parent=listRef enabled=enabled/>

Auto-discovery. The package ships a marko.json, so Marko's taglib discovery exposes <auto-animate> in your templates without an import statement. The explicit import AutoAnimate from "@formkit/auto-animate/marko" form works too, and is what the demo uses.

Lifecycle correctness for free. The tag's <lifecycle> owns setup, the reactive enabled diff, and teardown (controller.destroy() when the tag unmounts). Unmount the tag, or the branch containing it, and cleanup happens. There's no effect-ordering to reason about.

And if you don't want the tag at all, the core function is one import away:

client import autoAnimate from "@formkit/auto-animate"

<div/panelRef> ... </div>
<lifecycle onMount() { autoAnimate(panelRef()); }/>

Same escape hatch every other framework's docs show; now Marko has it too.

Does it survive resume? (And why that question is different here)

Let's be precise about what's special and what isn't. Server-rendering auto-animate is not a Marko-only trick. React under Next and Vue under Nuxt server-render lists fine, and after hydration a useEffect/onMounted attaches the animation. Same outcome. Qwik, which also resumes rather than hydrates, has an adapter too.

What's different in Marko is the mechanism, and it changes how the adapter must be built. Marko never re-renders on the client. There is no hydration pass that reconstructs the component tree and hands you a fresh ref. The HTML the server printed is the app, and Marko resumes it in place. So the adapter can't hang off "the render that happens on the client," because there isn't one. Instead:

The <ul> and its rows arrive as real server HTML.
On resume, the tag's onMount runs (a client-only lifecycle phase).
input.parent() dereferences the tag-variable, which points at the server-printed DOM node.
autoAnimate() attaches its MutationObserver to that node.

The subtle failure mode this design avoids: the adapter never depends on a sibling effect having run first, because the parent is a real DOM node reachable through the ref the moment resume reaches the tag. Marko's leaf-first resume ordering, a genuine trap for other integration shapes, simply doesn't apply here.

You can verify the whole story in ten seconds: open the demo, view source, and find the <li> rows sitting in the server HTML. No client render produced them; the adapter attached to them anyway. There's a passing SSR test suite upstream asserting exactly this, including plain object options after resume and an inline-template plugin case. Runtime plugin functions passed through server input are a different case and should be treated as client-only.

The full API in five routes

The demo is structured so each route teaches one thing, and the five together are the complete surface:

/ covers add / remove / shuffle / reverse with the tag, plus the view-source SSR check.
/options covers duration and easing, shown as a side-by-side race: two identical lists mutated by the same click, one at 150ms, one at 1500ms.
/plugin covers a custom plugin returning KeyframeEffects per action (add / remove / remain) for a bounce-in, shrink-out, springy-slide feel.
/enabled covers the reactive enabled attribute on a checkbox.
/dropdown covers the raw-core escape hatch, no tag involved.

One perceptual finding from building /options is worth passing on, because you'll hit it too: at the same duration, removals look slow and additions look instant. That's not a bug and not the adapter. It's the library's default keyframes. A removed row is kept in the DOM as an absolutely-positioned ghost and fades out visibly for the full duration while its siblings slide up. An entering row never moves: it's held completely invisible for the first half of its animation, then fades in (at 1.5x your configured duration, per the core source). A delayed fade with no motion reads as a pop, however long it runs. If you want loud entrances, that's what the plugin API is for. The /plugin route's bounce-in is the proof.

What we learned shipping it: a Vite 8 gotcha

The adapter merged, 0.10.0 published, the ./marko export went live. Then the first fresh npm install into a new @marko/run app crashed the dev server:

[UNRESOLVED_IMPORT] Could not resolve '../index' in
node_modules/@formkit/auto-animate/tags/auto-animate.marko

The cause is a packaging subtlety. In the source repo, the tag imports the core as "../index", extensionless, which resolves to src/index.ts and passes every test. The release build copies the tag into the tarball next to the compiled index.mjs, keeping the import as-is. Older tooling would guess the extension. Vite 8's rolldown-based dependency optimizer applies strict ESM resolution inside a type: module package and refuses to guess. Boom.

No spelling of that import works in both places. Using ../index.mjs would break the repo's tests, and ../index.ts would break consumers. So the package-side fix needs to make the published .marko file resolvable under Vite 8’s dependency optimizer. Rewriting the import during the release copy step is one possible fix; excluding the package from optimizeDeps is the current consumer workaround.

Until that lands upstream, the workaround is one config entry, which also reflects a general truth about .marko taglib packages (they should be compiled by the Marko plugin, not prebundled):

// vite.config.ts
export default defineConfig({
  plugins: [marko()],
  optimizeDeps: {
    exclude: ["@formkit/auto-animate"],
  },
});

The demo ships with this and documents it. It's also a neat illustration of why "the tests pass" and "the published package works" are different claims: the upstream test suites import the tag from source, so no CI run ever exercises the installed tarball under a consumer's bundler. The only way to catch this class of bug is to do what you'd tell a user to do. Install the real release into a fresh app.

Try it

Install: npm install @formkit/auto-animate (0.10.0+)
Import: @formkit/auto-animate/marko, or use <auto-animate> via taglib auto-discovery
Demo: https://codesandbox.io/p/github/defunkt-dev/auto-animate-marko-demo/main · source: https://github.com/defunkt-dev/auto-animate-marko-demo
The adapter PR: formkit/auto-animate#239

If you ship something with it, or hit an edge the five routes don't cover, I'd like to hear about it.

by defunkt-dev

DEV Community: defunkt-dev

This Framework Was Streaming HTML Before It Was Cool. Learn It in 135 interactive in-Browser Lessons 🚀

This Framework Was Streaming HTML Before It Was Cool. Learn It in 135 Browser Lessons

This Framework Was Streaming HTML Before It Was Cool. Learn It in 135 Browser Lessons

What this about?

1. Your page is HTML, your interactivity is surgical

2. Resumability: the client doesn't re-run your code

3. Streaming: three tags cover everything

<await> for in-order streaming

<try> with <@placeholder> for out-of-order streaming

<@catch> for errors

4. Rendering a live stream with recursion

5. SSE and EventSource

6. App federation: micro-frontends without the iframe tax and the hassle of module federation

7. The Hacker News app

Why the format matters

Try it

auto-animate now speaks marko

Marko in sixty seconds

What auto-animate is (and isn't)

The adapter's shape: why a tag

Does it survive resume? (And why that question is different here)

The full API in five routes

What we learned shipping it: a Vite 8 gotcha

Try it

`<await>` for in-order streaming

`<try>` with `<@placeholder>` for out-of-order streaming

`<@catch>` for errors