Why I Stopped Overcomplicating Component Events in Marko

I spent three hours last Tuesday debugging a memory leak that was entirely my fault. Actually, I should clarify — I had an unclosed subscription sitting in a destroyed component, quietly eating up RAM on our staging cluster. It’s the kind of mistake that makes you want to throw your laptop out the window.

And it got me thinking about the mental gymnastics we put ourselves through just to pass data from a child component back up to its parent. Developers will argue for days on forums about whether to use standard event emitters or heavy reactive subjects for simple component outputs. I used to care about those debates. I really did.

Then we migrated our main analytics dashboard to Marko, and I realized how much time I was wasting on boilerplate.

The Problem with Observable Soup

When you’re building complex UIs, the instinct is to reach for a heavy state management tool or an event bus the second two components need to talk. You wrap a simple click event in a stream, pipe it through three operators, and subscribe to it at the top level.

It works. But it’s exhausting to maintain.

Marko takes a completely different approach. It doesn’t ship with a massive reactive library that you have to learn. It leans on the platform. With the Tags API in Marko 6+, reactivity is handled by the compiler, and component outputs are just plain JavaScript functions passed as attributes.

Look at how stupidly simple this is. Here is a child component that just needs to tell its parent something happened.

// child-widget.marko
<attrs/{ onUpdate }/>

<div class="widget-panel">
  <button onClick() { 
    // It's just a function call. No emitters, no subjects.
    onUpdate({ timestamp: Date.now(), status: 'active' }); 
  }>
    Sync Data
  </button>
</div>

That’s it. No importing EventEmitter. No decorators. You just destructure the function from your attributes and call it.

Wiring Up Async APIs

Things usually get messy when you introduce asynchronous data fetching. You click a button, you hit an API, you update the DOM. But in Marko, handling race conditions and loading states is pretty straightforward.

Here is how I handle that exact scenario in the parent component now. I’m using standard async/await, and the compiler figures out exactly which DOM nodes need to update when the state changes.

// dashboard-view.marko
<let/metrics = null/>
<let/isFetching = false/>
<let/errorMessage = ""/>

<!-- We pass our async handler directly to the child -->
<child-widget onUpdate=async (eventData) => {
  isFetching = true;
  errorMessage = "";
  
  try {
    // Standard JS fetch API
    const response = await fetch('/api/v2/metrics', {
      method: 'POST',
      body: JSON.stringify(eventData)
    });
    
    if (!response.ok) throw new Error("API rejected the payload");
    
    metrics = await response.json();
  } catch (err) {
    errorMessage = err.message;
  } finally {
    isFetching = false;
  }
}/>

<!-- Native DOM updating based on local state -->
<section class="results">
  <if(isFetching)>
    <span class="spinner">Loading...</span>
  </if>
  <else-if(errorMessage)>
    <div class="alert">Failed: ${errorMessage}</div>
  </else-if>
  <else-if(metrics)>
    <h4>Server Response:</h4>
    <pre>${JSON.stringify(metrics, null, 2)}</pre>
  </else-if>
</section>

The beauty here is what’s missing. There are no dependency arrays to manage. I don’t have to manually trigger a change detection cycle. I just mutate the let variables, and Marko’s fine-grained reactivity surgically updates only the span or div that depends on that specific piece of state.

A Frustrating Gotcha You Should Know

I won’t pretend it’s all sunshine. I ran into a really annoying edge case last month that cost me a few hours, and the documentation wasn’t super clear about it at the time.

But if you are attaching native DOM events directly to elements (like onInput or onScroll) and you want to debounce them while interacting with Marko’s state, you have to be careful about closure staleness.

I was using a standard JS debounce utility from lodash inside a component. Because of how Marko compiles the render body, the debounced function was holding onto an old reference of my state variable. Every time it fired, it was logging the initial value instead of the current one.

The fix? You need to wrap your mutable state access inside an <effect> tag or ensure your event handler reads from a mutable reference that isn’t trapped in the initial closure. I ended up writing a custom debouncer that accepts the state by reference. Just keep an eye on your closures if you’re mixing third-party timing functions with compiler-driven reactivity.

The Real-World Impact

Switching our mindset from “everything is a stream” to “everything is just a function” had a massive impact on our codebase.

When we pushed this rewrite to our staging cluster running Node.js 22.14.0, the metrics were ridiculous. By dropping the heavy observable libraries and letting Marko handle the partial hydration, we cut our client-side JavaScript bundle from 142kb down to just 18kb. The page literally feels different when you click around. It’s instant.

The industry has spent the last five years building massive abstractions over the DOM. We invented entire new vocabularies just to pass a string from a child div to a parent container.

But I suspect we’ll see a massive pullback from this by Q3 2027. Developers are probably getting tired of shipping megabytes of runtime just to handle basic user inputs. Frameworks that compile away the complexity and let you write boring, predictable JavaScript functions are going to win out.

Sometimes the best way to handle component communication is to stop treating it like a specialized architectural pattern. Just pass a function and move on with your day.