# Marko 6 with Dylan Piercey > Dylan Piercey explains how Marko 6 uses compiled reactivity, resumability, and AI-guided tooling to build fast server-first web applications. - **Collection:** Video - **Published:** 2026-07-28 - **Author:** Anthony Campolo - **Canonical URL:** https://ajcwebdev.com/videos/marko-6-with-dylan-piercey/ - **Markdown URL:** https://ajcwebdev.com/videos/marko-6-with-dylan-piercey/index.md - **JSON URL:** https://ajcwebdev.com/videos/marko-6-with-dylan-piercey/index.json - **Channel:** [Anthony Campolo](https://www.youtube.com/channel/UCpdzti0GURPfMjKzYK5FVSA) - **Original URL:** https://www.youtube.com/watch?v=tLMcfuLFPm0 - **Original Label:** Watch original --- ## Episode Description Dylan Piercey explains how Marko 6 uses compiled reactivity, resumability, and AI-guided tooling to build fast server-first web applications. ## Episode Summary Dylan Piercey joins Anthony Campolo and Dev Agrawal to explain Marko 6, the latest version of eBay’s long-running frontend framework. He describes how Marko approaches web development from an MPA-first, thin-client perspective, using whole-program compiler analysis to ship only the expressions, state, and serialized data required for browser interactivity. A live code tour demonstrates expression pruning, resumability, cross-component reactivity, compact runtime output, and the differences between Marko’s declarative HTML-based language and JSX frameworks such as React and Solid. The group also discusses compiler feedback designed to correct AI-generated code, when humans should review agent output, and why AI may reduce the importance of framework ecosystem size. Piercey closes by previewing Marko Run’s experimental persisted-page architecture, which aims to provide SPA-like navigation and preserved client state through efficient server-generated patches without requiring developers to rewrite ordinary Marko applications. ## Speakers - Anthony Campolo - Dylan Piercey - Dev Agrawal ## Chapters ### 00:00:02 - Marko’s History and Dylan’s Path to eBay Anthony welcomes Dylan Piercey and revisits their 2021 conversation about the then-forthcoming Marko 6. Dylan explains that he has worked at eBay for nine years and that Marko, which dates to roughly 2012, powers a substantial share of eBay’s web experience and its highest-traffic pages. His earlier consulting work pushed him to study browser support, accessibility, progressive enhancement, and the web’s foundational strengths. That interest led him through Backbone, Angular, and React before Marko stood out through its server rendering, islands architecture, minimal client JavaScript, and early support for streaming. ### 00:04:28 - An MPA-First Framework for the Web The conversation turns to Marko’s present-day identity rather than simply the features it pioneered. Dylan positions Marko as an attempt to build a general web framework from the multi-page application side, contrasting its history with frameworks that began as client-heavy SPAs and later added server-oriented capabilities. He identifies rapid delivery as one of the web’s defining advantages: users can open an application in seconds without installing and continually updating native software. Marko’s architecture embraces that strength by letting powerful servers prepare most of an experience while thin clients receive rendered content plus only the interactivity they actually require. ### 00:08:30 - Beyond Islands with Expression Pruning Dylan compares content-oriented web experiences to video streams and highly interactive applications to game engines. Most websites, he argues, contain largely static screens with selected interactive elements, making it wasteful to send a complete rendering engine and application implementation to every browser when the server has already performed much of the work. Years of operating island-based applications at eBay also revealed their scaling problems. State placed high in a component tree can create a massive island, while increasing interactivity demands complicated hoisting and transclusion. Marko 6 instead analyzes the entire program and sends only the expressions involved in client-side updates, an approach the team calls expression pruning. ### 00:12:19 - Fine-Grained Resumability and Minimal Serialization Anthony summarizes the benefit as a simpler developer model that preserves Marko’s established performance advantages. Dylan confirms that state can live high in a tree and pass through many components without forcing the complete subtree into the browser bundle; only the state’s path and the final update logic need to be retained. Dylan then distinguishes Marko’s resumability from Qwik’s approach. Using its knowledge of the complete template graph, Marko serializes only values referenced by effects or event handlers rather than every component input. This can produce less initialization data than a conventional SPA while retaining familiar component-based authoring concepts similar to React, Solid, or Vue. ### 00:16:01 - Thin Clients and React Server Components Dev contrasts Marko’s server-first perspective with his work on Solid, where client state and SPA-shaped experiences receive more emphasis. Dylan says the desired authoring experience may be similar, but the frameworks differ in what they want to transmit over the network and how much rendering should happen on weaker client devices. That leads into React Server Components. Dylan appreciates their broad abstraction—requesting data from a server and receiving updated view information—but criticizes their wire mechanism, implementation, and developer experience. He wants server rendering to accompany data requests without increasing the cost and complexity of the initial page load. ### 00:20:00 - Compiler-Generated Patches for Navigation Dylan outlines Marko’s planned alternative to resending broad representations of rendered virtual DOM. Because the compiler knows the application’s static shell, changing holes, build identity, and relevant client state, the server should be able to return only the values needed to update a page after navigation or a form submission. An add-to-cart interaction illustrates the goal: rather than transmitting most of the page to change a cart count, Marko could send a narrowly targeted patch. Links and forms would remain the primary authoring primitives, HTML would still be available for standard requests, and enhanced clients could request compact patches while retaining ephemeral browser state. ### 00:24:10 - Reading Marko’s HTML-Based Language The discussion moves from architecture to a live tour of the Marko website and playground. Dylan begins with a counter, then explains that Marko is its own language: it extends HTML rather than embedding XML inside JavaScript, and its syntax was designed to express both initial markup and reactive updates declaratively. He introduces several unfamiliar but central features. Tags may receive parameters through pipe syntax, return reactive values, and represent either native HTML elements or discovered components. Attributes accept JavaScript expressions directly, interpolation resembles template-literal syntax, and top-level static statements such as imports coexist with the otherwise HTML-oriented template structure. ### 00:28:00 - Correcting AI Hallucinations Through the Compiler Anthony asks how language models can reliably generate Marko when React dominates their training data. Dylan intentionally writes JSX-style syntax in the playground and demonstrates a compiler error that recognizes the likely mistake, explains that the file is not JSX, and shows the appropriate Marko form. The same strategy handles className, Vue-style directives, and many other patterns borrowed from competing frameworks. When an agent is detected, the tooling can also supply a dense Marko 6 reference and current best practices. Rather than requiring every agent to install a special skill beforehand, Marko lets it attempt the task and then uses compilation feedback to guide it toward valid code. ### 00:32:00 - Training Agents with Errors and Cheat Sheets The Marko team has run thousands of inexpensive agent sessions to catalog common mistakes, hallucinations, and cross-framework idioms. Those observations become targeted diagnostics that tell both people and coding agents exactly how to correct their syntax, allowing the guidance to improve continuously as new failure patterns appear. Dylan sees this as an important advantage of owning a language and compiler. Developers arriving from React or another framework may instinctively add unnecessary braces or familiar directives, while an inexperienced model may combine several ecosystems at once. In either case, immediate contextual correction reduces the need to memorize the language before becoming productive. ### 00:36:23 - Compatibility Versus Guided, Concise Code Dev compares Marko’s approach with Octane, a newly released compiled framework that preserves React syntax and even accepts patterns such as conditionally called hooks. Dylan considers compatibility valid, especially if nobody expects to inspect the generated source, but argues that permissiveness can leave maintainers reviewing inconsistent code filled with accepted anti-patterns. Marko instead aims for a both-and result: agents receive enough compiler guidance to produce concise, idiomatic source, while the compiler independently transforms that source into efficient output. Dev notes that even imperfect authoring can still benefit from Marko’s pruning, and Dylan emphasizes that consistent, compact code remains valuable when a project must be reviewed and maintained. ### 00:41:33 - What the Counter Actually Sends The counter demonstration reveals how little JavaScript reaches the browser. Marko registers the required click handler and reactive update but omits code for recreating the button, setting its static class, or rendering surrounding markup. When Anthony asks about accessibility, Dylan clarifies that the semantic button remains fully present in the server-rendered HTML. Compact markers in that HTML identify the text node that can change and the element that needs an event listener. During resumption, the client finds those locations, restores serialized state, and attaches behavior without rendering the component again. Static markup stays in the DOM, while client execution is limited to work the server could not perform. ### 00:46:14 - From Solid’s Reactive Nodes to Marko’s Pruning Dev offers a Solid-based interpretation of the demonstration. React often reruns components after state changes, while Solid reruns only the reactive nodes affected by those changes. Marko can be viewed as another step: if an update needs five reactive nodes, only the code for those five nodes needs to exist in the client bundle. Dylan describes Marko as a compiled fine-grained reactive system, then responds to Anthony’s question about whether JSX is also compiled. JSX is transformed, but in React it largely represents a convenient syntax for function calls. Marko’s compiler understands a more constrained declarative language and can therefore reason about state, data flow, updates, and serialization across a complete template. ### 00:50:00 - Why Marko Uses a Declarative DSL Dylan explains the limitations of trying to infer application structure from arbitrary JavaScript containing JSX. JavaScript may place markup inside functions, loops, switches, or try-catch blocks, so frameworks must either support that unrestricted flexibility or impose rules that work against what developers expect JSX to permit. Marko starts with HTML and adds only the constructs needed to represent reactive web interfaces. That makes the language comparable to a specialized DSL whose focused purpose allows stronger optimization, much as a regular expression engine can optimize its dedicated syntax. State may still appear inside components or conditional tags, but it does not inherit React’s hook-order constraints. ### 00:54:52 - JSX Transformations and Compiled Dependencies Dev reinforces that a basic JSX transform normally leaves ordinary JavaScript untouched, even though different frameworks can assign different runtime meanings to the resulting calls. Dylan notes that virtual-DOM frameworks generally follow React’s established interpretation, while systems such as Solid perform more analysis to create fine-grained updates. The group then returns to Marko’s compiled reactivity. Unlike a runtime signal graph that discovers subscriptions as expressions execute, Marko can identify dependencies during compilation. If a derived value depends on a counter, the compiler can arrange for the counter’s update path to call its downstream work directly, avoiding a general-purpose subscription system and enabling bundlers to inline simple derived functions. ### 00:59:00 - Reactivity Across Component Boundaries Dylan simplifies the example to show a count passed into a separate display component. With no updates, the compiler sees that the value is static and produces an empty client bundle. Once the count becomes interactive, Marko emits only the functions needed to carry the new value into the display’s text update. The demonstration highlights a central Marko 6 claim: bundle and serialization costs scale with interactivity, not with the total number of components or the overall size of an application. The HTML-first design allows purely presentational sections to remain server output, while reactive values can cross template boundaries as direct function calls without preserving unnecessary props objects. ### 01:03:58 - Inspecting Unpruned and Production Output Dylan enables debug output to show what Marko could send if nothing were removed. The expanded representation includes template HTML, encoded instructions for locating dynamic nodes, a setup function, initial state, and event-handler registration. It resembles the broader client setup another fine-grained framework might retain. Returning to production output demonstrates what the server has already made unnecessary. Template creation, DOM walking instructions, and initialization disappear, leaving the narrowly relevant update code. Marko’s runtime is around one to two kilobytes for the simple example and grows only when additional language features are used, with the complete feature set still remaining comparatively small. ### 01:09:14 - Vanilla DOM Performance with Framework Ergonomics Dev compares Marko’s generated output to old jQuery code that attached handlers, kept a little in-memory state, selected a DOM node, and updated it directly. Dylan agrees that direct DOM manipulation is close to the smallest and fastest implementation available, but notes that writing and maintaining such imperative code produces poor developer ergonomics. Marko’s purpose is to approach that performance while retaining components, composition, asynchronous rendering, event handlers, and fine-grained reactivity. Dylan also introduces Marko’s reactive script tag: it looks like an HTML script, yet references to reactive values cause its body to execute again when those values change, serving the role other frameworks call an effect. ### 01:13:10 - Server Execution Resuming in the Browser The playground itself performs a server render and then resumes the generated result, allowing developers to inspect realistic HTML, JavaScript, and serialized state rather than a client-only approximation. Dylan uses the logging tools to show an initial value printed during server rendering and later values printed in the browser after button interactions. This makes the execution boundary visible. Initial markup and calculations can stay on the server, while the browser receives only the code needed for future interaction. If the counter stops changing, the associated client behavior is pruned. Dylan summarizes Marko 6 as a combination of agent-friendly guidance and fine-grained compilation that turns concise templates into minimal browser bundles. ### 01:17:47 - When Humans Should Review AI-Written Code Dev asks when Marko and coding agents might become reliable enough that humans can stop reviewing generated code. Dylan says the answer depends on the project, its longevity, its security and performance requirements, and how closely the requested behavior resembles material found in a model’s training data. Even perfect execution would not protect developers from flawed requirements or mistaken architecture. An agent may faithfully build a huge single-file application because that is what a vague prompt implied. Dylan recommends small, digestible change sets for important work, while accepting minimal review for throwaway prototypes. Understanding the desired system remains necessary even when an agent writes the implementation correctly. ### 01:22:51 - AI Changes the Framework Ecosystem Tradeoff Anthony observes that Marko may be easier to recommend in an AI-assisted world because developers no longer need to master an unfamiliar syntax before receiving its benefits. Dylan adds that Marko’s historically smaller ecosystem and tooling footprint may matter less when agents can rapidly produce integrations, boilerplate, and framework support. The group also recognizes the risks of dependency ecosystems, including outdated practices and compromised packages. AI makes custom tooling cheaper, but it does not eliminate the need for trusted, validated foundations. Dylan points to TypeScript support as work that could have been accelerated considerably by agents, provided a knowledgeable maintainer still reviewed the nuanced and important portions. ### 01:27:14 - Marko Run and the Persisted-Pages Direction Dev asks whether the planned server-component-style work will become part of Marko Run. Dylan explains that Marko Run is Marko’s recommended meta-framework, comparable to Next.js, SolidStart, or SvelteKit, and supplies a filesystem router and server infrastructure used by eBay applications. The new architecture adds a tiny client router capable of preloading what later navigation requires. Under an experimental concept called persisted pages, Marko can mark values and DOM holes that might change through future server updates, even when they are server-only during the initial render. Subsequent requests can then target those locations without treating the browser as a freshly loaded page. ### 01:32:35 - Combining Server Values with Client State Dylan considers control flow that depends on server-derived input, client state, or both. Static conditions need no browser representation, while a condition affected by later server data must leave enough information for the server to address the relevant hole. Conditions involving client state require coordination rather than blind replacement. The compiler can generate a gate that reacts when either side changes, and a navigation response can call the correct update function with a new server value. This extends the same dependency graph already used for client reactivity. Developers continue writing ordinary Marko conditions, while compilation determines which parts remain server-only and which intersections require resumable client code. ### 01:37:08 - Stateless Renders with Client-Aware Updates Dev restates the proposal as sending setters or targeted operations rather than serialized UI nodes, and Dylan broadly agrees. The initial Marko response already contains compact arrays of scripts, scopes, and serialized values, and the navigation format extends that machinery instead of introducing a separate component model. The server should remain largely stateless and follow the same rendering path used for a normal MPA response. A client request can compactly identify its current route and known page state, allowing the server to remove content the browser already possesses. The result preserves ephemeral browser state while retaining progressive enhancement and the operational simplicity of server-rendered navigation. ### 01:42:17 - An E-Commerce Demo of Smaller Page Patches Dylan demonstrates a prototype e-commerce application authored mainly with links and forms. Navigating to an item loads only the page-specific interaction code, the functions needed to apply server updates, and markup absent from the existing page. Marko can remember newly received server-only HTML so it does not need to be transmitted again. The measured navigation payload is smaller than requesting the complete HTML document, while still preserving browser state. A later add-to-cart form submission becomes smaller again because most markup is already known, leaving primarily the cart-related updates. Dylan argues that this offers both lower wire costs and a simpler authoring experience than manually separating React Server and Client Components. ### 01:47:15 - A Drop-In MPA Upgrade and Closing Thoughts The experimental mode aims to be a drop-in enhancement for standard Marko applications. Dylan reports roughly ten percent extra initial HTML from additional markers in current tests, followed by substantially smaller navigations and SPA-like persistence. The demo contains no persisted-page-specific application code, although the wire format and pruning strategies still require further testing before release. Dev looks forward to comparing Marko’s MPA-first solution with future fine-grained work in Solid. The guests close with Marko’s website, Discord, social channels, and recent Marko Run improvements such as validation and data-loading APIs. The recording ends at 01:53:12, giving a total duration of 01:53:12. ## Resources and Links - [markojs.com](https://markojs.com/) - [ajcwebdev.com/podcasts/marko-dylan-piercey](https://ajcwebdev.com/podcasts/marko-dylan-piercey/) - [ajcwebdev.com/podcasts/jsjam-dylan-piercey-and-the-marko-team](https://ajcwebdev.com/podcasts/jsjam-dylan-piercey-and-the-marko-team/) - [octanejs.dev](https://octanejs.dev/) - [markojs.com/docs/marko-run/getting-started](https://markojs.com/docs/marko-run/getting-started) - [markojs.com/docs/newsletter](https://markojs.com/docs/newsletter) ## Transcript [00:00:02] - Anthony Campolo And we're live. Welcome back everyone to AJC and the Web Devs, Web Devs at Night Edition, with our co-host Dev and our new very special guest, first timer on AJC and the Web Devs but longtime friend, Dylan Piercey from the Marko team. What's up, Dylan? [00:00:22] - Dylan Piercey Hello, thanks for having me on. Yeah, it's been quite a while, um, but there's lots to talk about, so I'm excited. [00:00:28] - Anthony Campolo Yeah, I first had you on FS Jam. I actually had the episode at the— it was December 2021. And I remember back then you were talking about Marko 6 and how cool it was gonna be. And now here we are almost half a decade later and it's live and available. [00:00:47] - Dylan Piercey Yeah, well, Marko itself is quite the old framework, so, you know, what's another 5, 10 years. I'm just kidding. [00:00:56] - Anthony Campolo But that's true. That's actually one of the things that first got me interested in it. And we'll get into all this, but like Marko was this framework that I didn't know about for a while. And then as I got deeper into, you know, web dev frameworks, I started hearing it come up more and more. And particularly from Ryan Carniato, who I was getting to know in 2021 as well. And that was back when he was, I think, still on the Marko team or he was still working. Um, eBay, I can't remember. [00:01:20] - Dylan Piercey Yeah, he was working at eBay for a while. Yeah, that's right. [00:01:23] - Anthony Campolo Yeah, yeah, man, a while ago. But yeah, so we would just love to hear about, you know, your background, what you do, how you got involved in Marko and all that. [00:01:34] - Dylan Piercey Yeah, yeah. So I mean, I have been working at eBay for 9 years now on Marko, which is the frontend framework that powers about half or more of the eBay web experience and is also the framework that we recommend for all of our super high traffic pages. It's optimized for performance and it's also a very old framework. So I've been working on it for 9 years, but it actually dates back to 2012, 2013 era. And basically my story before I joined eBay, I was building tons and tons of apps through a consultant agency and So it led me down the path of what is a good website? What are the fundamentals of the web? What should I be building for? Because I'm building so many of these things. And also I had a broad set of customers that wanted broad browser support and accessibility and all that sort of stuff. So I'm trying to find what the common denominator is. So I was always very interested in the web as a platform and what I thought it's like. Foundational pillars are. What's good about it? How can you build stuff with it? So I was building frameworks and tools to help my life building all these different sites. And ultimately that led me to Marko, which is a totally different framework than anything I had worked with before. I mean, I did some Backbone and then it's Angular and then React. And React's pretty cool. Everyone's super excited about it. I was still into server rendering and all that stuff with React and progressive enhancement and this sort of old way, but the tried and true way of web, but with React. So building frameworks to do that sort of thing. Anyways, that brought me into Marko, which is a framework that obviously a lot of people don't know about. Although Ryan Carniato has talked about it and some people have brought it up, especially framework authors have seen it floating around, partly because it has pioneered a lot of ideas that a lot of frameworks nowadays adopt. It's had islands, based architecture from inception, so it's optimized to not send the entire application's worth of JavaScript. From the beginning, it's like a multi-page app framework that's intended to just send minimal JavaScript to enable the functionality of the page. And from the beginning, it also had streaming, out-of-order streaming, and a whole bunch of other features that today we kind of just take for granted. So yeah, that's kind of my story and where Marko sort of started. All of that stuff was there basically when Marko came out. So the question is why, or at least my question, why does Marko still exist today? Why are we still improving it? And what has changed kind of since then? Unless you guys wanted to start down a totally different path, but that's kind of what I imagined. [00:04:28] - Anthony Campolo Yeah, well, I was going to say, Uh, it's been a while since I've talked JavaScript frameworks, obviously. And this is— [00:04:34] - Dylan Piercey yeah, I mean, it's obviously, you know, the elephant in the room is, is AI. So you can, you know, that is obviously going to be a factor in what Marko looks like in the future and how we've been improving Marko. Um, and there's also like the question of, do you even need frameworks? Are we just gonna have LLMs output like machine code or something like that? So there's like a whole bunch of questions there. But, uh, yeah, we can maybe get into some of that too. [00:04:56] - Anthony Campolo Yeah. Well, what I was gonna say though is that like, this is, this is a fun conversation for me cuz I'm kind of coming back like, reminding of like why Marko was interesting to me in the first place and how it relates to other frameworks and stuff. And like, it kind of, it takes so many things that other frameworks now are well known for and it did it first, like you said. So it had a lot of like the islands, partial hydration, MPA, SPA kind of mix that you get with something like Astro. And then it has a lot of like the reactivity you get from something like Solid. Then it has like its own templating language, like Svelte. So. It was a really hard framework for me to first wrap my mind around when I was first learning about it. So I guess today, what do you say is its claim to fame? Not based on what it did first, what does it do best now that actually makes it unique? Yeah. [00:05:46] - Dylan Piercey So I mean, like you said, obviously there's all this old stuff and that's kind of how I started is like, why does Marko exist? And obviously one of the reasons why it exists today is just because there is a whole bunch of Marko apps out there and continue to support. But what is interesting about Marko today is that we had already been building this infrastructure optimized for multi-page apps for basically 10 years before any of the other frameworks even adopted it. I had mentioned to you before off stream that we had conceptions of what Marko 6 and future versions of Marko would look like way back in 2017, 2018. That was before even React Server Components and stuff like that existed. We've been executing on the vision of how do we make Marko the optimal, not only multi-page app experience, but all app experience. It's like the ultimate web building framework, which is obviously everyone's goal, but we're tackling it from the other side. A lot of frameworks are tackling it from the SPA-first side, and obviously we're tackling it from the MPA-first side. So there's probably, maybe your viewers have heard of discussions of the app spectrum of, you've got basically static sites, and then you go to more interactive sites until you get to something that's just totally interactive and you might as well render it in the browser. So historically, Marko has obviously been kind of optimized more for this light interactivity experience. You know, I said before it's like pioneered islands architecture and all that sort of stuff. But the question is, what does it mean to actually optimize for the web? And that's what I'm always thinking of. Like, what is the fundamentals of the web? I kind of talked about it a little bit, but in my mind, the fundamentals of the web are, you know, it's open. That's like a given. You can deploy without having to go through a gatekeeper. That's great. You know, it can be accessible. All that stuff. But one of the pillars of the web that makes it unique from something like mobile, in my experience, is the delivery mechanism itself. The fact that you can load up an application in seconds instead of having to go and download an application and continually update it. So, in my mind, you know, the delivery mechanism of the web is one of its key strengths. And MPAs tie into that delivery mechanism specifically. They're optimizing for the fact that the server has this large application that a thin client can then consume and interact with, with limited interactivity added on top. The way I like to think of it, my analogy is the difference between a video stream versus a game engine. It's like a game engine, you can represent pretty much anything in the game engine. Your limitation is compute and the client devices, right? But a livestream, ultimately, you're just getting pixels on the screen, but it can obviously be sent way more efficiently from a server that's already done tons of processing. And that's kind of the difference in spectrum that I see from a content application to a super interactive application is we've got these experiences which are ultimately typically just screens that have interactive elements on it that's largely static. We're not mostly building games on the web. And so how do you optimize for that? And I see that as optimizing for that target specifically, I see as a unique advantage of the web as compared to native. So anyways, to take that all back, what has Marko done or what are we doing right now? So I said that we pioneered islands-based architecture, but since we have had islands-based applications at eBay for basically ever. Well, not forever, but we have seen the pitfalls of the islands-based architecture. And obviously now that Islands has other implementers like Deno Fresh and Astro and all that stuff, lots of people, obviously pretty quickly, as soon as you start to scale Islands, you get into issues, especially as interactivity increases. Obviously you get to a point where the optimizations that you're trying to apply on top of islands end up being more complicated than if you had just written a SPA. So what we have done on the Marko side is we've said, okay, what if instead of islands, these parts of your app, like a component, a template, what if instead of these islands that have a little bit of interactivity causing everything else under them to be sent to the browser, What if we go more fine-grained? What if we look at your whole program, we look at how data flows to the program, how state flows through the program, and determine just the expressions that need to be sent to the browser? So instead of an islands-based framework, Marko is an expression pruning framework. So now this is primarily for the MPA side of things, and I think it probably makes more sense for me to show what this sort of looks like and what it means. But at the end of the day, it means that instead of having to worry about where your islands are, to worry about how data flows through your application, to worry about where you're gonna hoist state, where you're gonna do transclusion, all these sorts of things that you have to think about when you're building with islands, you just don't have to think about those things anymore. The compiler handles it for you and sends even less code than any frontend framework that currently exists. So that's what Marko 6 is. And like I said, our long-term vision is to extend further than that. Now that we have this complex compiler that can understand essentially your entire application, what can we do with that? How can we make it so that the next navigation is more efficient? How do we go to what would traditionally be like a SPA. [00:11:59] - Dev Agrawal Okay. [00:11:59] - Anthony Campolo So, if I'm hearing you correctly, it sounds like, you know, you have a lot of the same benefits that have existed previously in Marko, but the way you do it in the framework has become simpler. The mental model has become more easy to understand for the developer, and you're trying to improve how you can actually use these higher-level primitives without shooting yourself in the foot. [00:12:19] - Dylan Piercey Exactly. Yeah. So, You know, very common in the islands-based framework to be like, well, I want some state at the top of the tree. Okay. Well, shoot. Now you've got a mega island, right? So Marko 6 doesn't have that problem. You can put state wherever you want, right at the top of the tree and plumb it all down through your entire application through 100 components. And ultimately what you get bundled is just the code for that state going through the tree and updating, you know, a text node. You don't get the rest of the application in the browser. So that's what it does. There's a whole bunch of other things that come with Marko 6. Obviously, we've been thinking about developer experience. So, there's like a whole bunch of declarative wins and nice APIs that I think you kind of have to try to appreciate. But so, it's obviously not just this MPA-style thing. Another piece of it that I haven't really mentioned, although it ties into it, is this concept of resumability. Which Qwik was the first to come out with resumability. We were working on resumability for quite a while. But our resumability is quite different from the way that it works in Qwik. And there's like— maybe it's like a confusing term. But at the end of the day, a big thing in Qwik, if you've ever worked with it, or at least from my experience, is that it ends up serializing a lot of code in the browser. Or like for components, has to serialize all of your inputs and all that stuff. Marko is also resumable. It doesn't replay anything in the browser. But because we have that whole template graph knowledge, we're able to tell exactly what needs to be serialized for the browser. Instead of thinking of what's going to get serialized as, okay, well, this thing's input might get serialized. Instead, in Marko 6, the only things that get serialized are, for the most part, things that are referenced within effects or event handlers. So, you know, if you have a button with an onClick that's like console.log input.name, right? Input being the props equivalent in Marko. The only thing that gets serialized to the browser to be able to resume that component is essentially a little ID that says, you know, it's this effect or this event handler or whatever. And that input name. Then everything else can stay on the server. It automatically prunes what gets serialized. It actually ends up serializing less than you might have even serialized just to initialize your SPA. Because even in a SPA application, you still have to initialize the state from your whatever server requests you were doing and all that stuff so that you can hydrate. In Marko 6, that is another thing you don't have to worry about. It automatically figures out what needs to be serialized. Because we have all of this compiler information, we can prune that super aggressively. So ultimately, Marko 6 is essentially the smallest multi-page app bundles that you will get with very minimal serialization. Yeah, compared to any other framework that has a normal component-based DX. Obviously you can look at something like Qwik or you can handwrite your own JavaScript or whatever, but the big thing with Marko is that it has a modern framework DX. It doesn't feel like you're writing imperative vanilla JavaScript or writing HTMX-style code or anything like that. The concepts map pretty much one-to-one to React or Solid or Vue or whatever. It's just the compiler is super smart about the Marko language and outputs a very optimal bundle. And serializes as little as possible. [00:15:58] - Anthony Campolo Awesome. Did you have a question, Dev? [00:16:01] - Dev Agrawal I mean, not really quite of a question. I think I feel like I— I mean, I love hearing the perspective on the server-first, the MPA side and the SPA side, because I get to work very closely with Ryan on Solid, especially Solid 2.0. So, I feel like I'm quite on the kind of front lines of like things should be more SPA-shaped and we should— we need more state on the client. Like that— [00:16:28] - Dylan Piercey well, I think honestly we would probably agree what the authoring experience would be like, right? It's just what the wire experience looks like. I think we'd probably disagree. [00:16:39] - Dev Agrawal Yeah. [00:16:40] - Dylan Piercey And my perspective is, you know, I look at the web from a thin client perspective. Like you want to be able to have thin clients, weak devices to be able to render your app. So that kind of means not doing heavy rendering in the browser and deferring work to the server where possible. Obviously, we don't ship our databases to the browser, but we do ship basically our whole frontend application to the browser, which can be wasteful and on some devices isn't gonna work. But anyways, so looking at it from that angle, in my mind, anytime where you'd want to say, hey server, I need some new data, why not just have the server also do some rendering for you, right? And so that's what in my mind the ideal web architecture is, is how do you make it so that anytime where you would have gone to the server anyways, you're just also getting potentially rendered view instead of, hey, here's how you build the application. Yeah, anyways, but I'm curious where you guys land on all that. [00:17:39] - Dev Agrawal No, I think what you just described is fantastic because what you just said is exactly how I would describe React Server Components to someone. And I think that recently there's been a lot of like, uh, Server Components also kind of solved this problem. But over time we realized that, oh, they don't actually fully solve it. Um, but there's also been a lot of comparisons between Marko and Server Components. Uh, I think most of them come from the fact that React kind of happened to implement out-of-order streaming around the same time. And then people started confusing that with Server Components. But yeah, I think in your opinion, how— like, what is your take on Server Components? How exactly are they similar to Marko and what makes them different? [00:18:28] - Dylan Piercey So I view Server Components basically the same way I view React's other APIs, which is that I think they have roughly the right abstraction But the wrong wire mechanism and overall implementation and developer experience. [00:18:46] - Dev Agrawal So everything. [00:18:49] - Dylan Piercey Yeah. Well, I mean, that's pretty much anything you could complain about, the superficial stuff. But at the end of the day, in terms of what I just described, hitting the server and getting new view back from it, React Server Components does that, right? The thing that is kind of important to me is making it so that that is efficient and that you're not complicating or bloating the initial load as well to facilitate that. So that is something that we're actively exploring. This is what I was alluding to earlier. But so imagine if you had something like React Server Components. But instead of authoring it like React Server Components where you have to keep track of where the client code is and where the server code is, what if the compiler just knew that for you? And what if instead of over the wire resending a whole bunch of rendered VDOM, what if the compiler knew exactly what to send? What if the compiler could tell where the holes are and what can actually change on the server and sends just a minimal just the actual change data over the wire. So that's what we are actively looking at with Marko 6, which is essentially what we've been building towards with this compiler analysis. Is, okay, we've basically set it up so that you do a server render, you get the minimal interactive JavaScript, and then the client is able to resume with a minimal serialized payload. What does it look like to do a navigation? Okay, so obviously we want to start from like the web fundamentals. So ideally it's, you know, links and forms, potentially some other progressive enhancement style APIs. But anyways, when you do a navigation, what needs to happen over the wire? So obviously like React Server Components is essentially saying like re-render the server components and send like fake VDOM-ish stuff. So one of the things I mentioned was a Ideally, the server can just know, hey, you're on the same build that I sent before, so I know I can skip this stuff. Okay, we skip the shell. You also have— there's information that the client can send, or a small amount of information the client can send, so that the server can know what state it's in to send even less. So that the wire format is closer to what you would have written if you were building something yourself, right? Because If you think of an add to cart style interaction, you add something to the cart and in the simplest case, you're just updating a number over in the top right. You know what I mean? Maybe some other stuff on the page as well. But with something like React Server Components, depending on where your Server Components are, you might be sending essentially the whole page again to facilitate that counter update. Basically, we are banking on and have banked on basically since the beginning of Marko smart compilers to eliminate that overhead. That's why we're so focused on compilers because we've used compilers to eliminate a crazy amount of the JavaScript that is necessary for the page, to eliminate a crazy amount of the serialized data that would normally be needed for a resumable type experience. And now we want to take this navigation approach. How can we apply those concepts to a navigation? And so with that, basically it would mean that you could have things like ephemeral state in the browser with the server still being the primary router. So yeah, I mean, that's ultimately our vision. It's very similar to React Server Components. Which actually when React Server Components was announced, we already had this kind of sketched out. It was just, this is what we're gonna do eventually once we have all this compiler stuff set up. So we were actually pretty excited when React Server Components came out, but ultimately I think the developer experience of it could be much better. Like I said, useClient and also a number of other footguns that you have to worry about, I think working with the web primitives is much better. So in what we have in our prototypes, it's essentially you ask for the page as HTML, you get HTML. You ask for the page as a patch, it sends you a patch. But that patch is an optimal subset of basically the holes that would be needed to update the existing page. Or, and there's a whole bunch of things to go into with that, but yeah, that's sort of our vision. We have prototypes around that. So to answer your question, basically Marko today, Marko 6, if you're building something that would work well as a multi-page app experience, like if you're building something that you would've maybe built with Astro or whatever, Marko will, in my opinion, have much better DX, but it would also definitely deliver less JavaScript and have higher performance. So that's kind of where we're at. I could show a little bit of what Marko looks like, or we could go into more questions or do some back and forth. [00:24:10] - Anthony Campolo I mean, I think getting into the code would definitely be good. This is one of those topics that is very heady, and I know people can get lost in the sauce. I know I can certainly when it comes to all these terms and things like that. [00:24:21] - Dylan Piercey Yeah, and there's so many things, like as I'm describing it, I'm like, do I go into this nuance or like this? Specific thing and then suddenly you're like 10 layers removed from the original thing. So yes, looking at code can definitely be helpful. [00:24:36] - Anthony Campolo Do you want me to add your computer to the screen? [00:24:39] - Dylan Piercey Yeah, let's do it. So yeah, I'm just gonna go through the Marko website. I'm zoomed in so it's in the mobile view. But ultimately, this is the most basic Marko example and general example of any framework that you'll see. It's just button that you click and it counts, right? The thing— [00:25:00] - Anthony Campolo weird things. [00:25:00] - Dylan Piercey It's got a couple weird things. And actually, you know what? It probably makes sense for me to start with those couple weird things so that we get it out of the way. So, Marko is a different language, right? Like, Marko is not JSX. Marko is not, you know, Svelte-like or whatever. It's a language that has been carefully thought through in terms of how we would be able to declaratively write HTML with updates also being described declaratively. And also it is an extension of HTML, not an extension of JavaScript. So the things that are added to Marko: first, start from HTML. Then you have some top-level static statements. So we have import and there's some others that I won't go into right now. But then you just have HTML. So obviously the HTML, you have a tag name. There's a little bit of magic that can happen in the tag name, but we won't go into that right now. A tag, though, is like a template or component in any other framework. It doesn't have to just be HTML. And Marko will automatically discover tags that are on disk, or you can import them and reference them that way, kind of like React. But ultimately, a tag can do 2 things beyond what you— well, maybe 3 things beyond what you would normally expect a tag to be able to do. So a tag can give you parameters. So if you think of a tag, it's like a function that you're passing a callback to, and you can receive parameters from that function and then use those parameters inside the body of the tag. So that's one thing that's different. If you see pipes, think parameters coming into the tag. Another thing is a tag can return data. So like any tag can say, I'm gonna give you— I'm gonna return some reactive value to you. So here, this myTag is giving out or returning a foo variable, and this other tag is returning a variable, but it's then being destructured. The syntax is just JavaScript in terms of the variables here. It's not like this curly brackets is anything special. It's just a regular JavaScript destructured variable, the same as if you went const this equals something. Anyways, syntax-wise, those are the main things that are gonna trip you up right away is the params. Tags can receive parameters, tags can return values. We'll talk about that obviously a little bit. But then there's some superficial differences as well, like interpolating in the body is dollar curly. It's closer to the template literal syntax. All this syntax stuff, maybe people don't care about anymore because we have agents writing our code and stuff. So I'll talk about that. But anyways, it's good to know what we're looking at as far as going into the— [00:27:38] - Anthony Campolo Yeah, I think it'll matter to the extent that You know, this is something that, you know, AIs, they'll be able to write React for days because it's in the training data. But with like Marko, you, you'll need to give them— something that I'd be actually really curious to get into. Maybe not necessarily right now, but yeah, I'm happy to get your AI to figure out how to write Marko, you know. [00:27:59] - Dylan Piercey Yeah, how do you do that? What is our answer to that? What have we been working on? Yeah, okay. Anyways, so, you know, basically superficially, we've got the params, we've got the variable, we've got some attributes, and Basically, attributes are actually more like JavaScript variables. They're not like React or other frameworks where you have to have some wrapping brackets around the value. It's just any value is a JavaScript variable. You can do template literals, you can do expressions, whatever. It just all works. You can put a function here and it just works. There's also shorthands and all that stuff. That's the superficial stuff. There's more that I won't really go into, but all that is to say is Marko is a language. You brought up a point that I actually wanted to bring up. Okay, can LLMs write this? Like, you know, it's cool way back that this is a language that is like relatively declarative and, you know, relatively concise. And, you know, if you compare it to other frameworks, it ends up usually being pretty much the least amount of code that you can write for any given example. But what does that mean for LLMs? Okay, so let's go back to the playground because I'll get into this after. So, you know, one of the things I had mentioned is that attributes are JavaScript variables. Like JavaScript properties in an object, you can also do a shorthand method. This onClick is the same syntax as a shorthand method if I was inside of a JavaScript object. I can also write it as an arrow function like this, and that's going to work identically. We just have that shorthand. Now the question is, this is Marko. What happens if I'm an LLM and I write some React in here, which would be this. Shoot, did I mess it up? Okay, hold on. I just changed the playground. Let me pull something up here real quick. This is why you don't put out releases right before showing stuff. Okay, I'll just be 2 seconds. Here it is. [00:29:59] - Dev Agrawal I'm going to guess that it's either compatibility or it's like a really helpful error message. Hey, this is not React. [00:30:06] - Dylan Piercey Yes, it is a very helpful error message. Exactly, yeah. So let me just like throw this over. This is gonna be fine now. [00:30:16] - Dev Agrawal Okay. [00:30:17] - Dylan Piercey Yeah, so like basically you get something like this. Unexpected token. And so the thing is, what I wanted to highlight is it's exactly as you expected. We give, you know, an error that's like, this isn't JSX. You probably don't want the wrapping things. But because Marko is a language and Marko is a compiler, and because we have AI, we can build tons of these, right? So we can basically think of anything that the LLM would be hallucinating and give it errors and guidance that can align it with what Marko is intended to look like. So there's basically 2 answers to your question. So one, is all throughout the language, anytime you would be writing something that would look like an idiom from another framework or tool or something that we've seen LLMs hallucinate across thousands and thousands of runs, you get error messages that not only is just like some weird abstract error, it's a message that says, this is how you fix it. Here, if I'm like className equals boo, you know, it's not just class doesn't work on native elements. It's, did you mean class? If you, if you go in here and you're, you know, like in Vue or something and you're like v-if or whatever, it's like, did you mean the if tag? Right? And so we've got these compiler errors all over the place capturing all sorts of idioms, pretty much everything we've ever seen. To guide LLMs to the right place. One thing that's not captured on the playground here is that if an agent is actually compiling the template or we detect that an agent is running, we also give the agent a super dense cheat sheet right there that shows how to use Marko 6 and what the best practices are and all that sort of stuff. Essentially a very dense cheat sheet that we constantly refine based off of what we're seeing agents mess up on. And so the nice thing about that is instead of having to install a skill or worry about teaching your thing Marko, instead it just tries to write it and it gets corrected. And it also gets essentially all the context it needs not to mess up again in the future. This is actually an area that I think LLMs have helped us out tremendously with because implementing all of these sorts of validations and stuff in the compiler, that's something that we could have done forever ago. But now that there's all of these easy wins that we can very quickly review, having a compiler gives you quite an edge, right? Like, you know, it's not going to hallucinate Svelte, um, or it's not going to hallucinate— I mean, it might hallucinate Svelte, it might hallucinate Solid, it might hallucinate React, it might hallucinate anything. [00:33:20] - Anthony Campolo It doesn't matter is what you're saying, right? [00:33:22] - Dylan Piercey It doesn't matter, it will be corrected. And so, you know, basically what we've done is, besides like seeing what people have like actually run into, we also run like thousands and thousands of dumb agents of all sorts just to see like what the lowest common denominator is doing while building with Marko. Um, so we have this like large, you know, list of common idioms that— and mistakes that the tools make. And because we have a compiler and because we're not afraid to use it, you know, we can, uh, guide agents. And it actually, you know, has been tremendously successful for the quality of the output that we get from agents, you know, as well as people. Because if I'm someone coming to Marko and I'm like, well, Shoot, this is like React. I mean, even I might— I don't usually make this mistake, but people make this mistake where they're writing the event handler with the React style or JSX style curly brackets. Now someone just has to play around with the language or have their LM play around with the language and they can learn it. [00:34:25] - Anthony Campolo Having not learned all the syntax is an advantage at this point. Someone who has too much knowledge from another framework is gonna be nerfed when they come to Marko. But if you, if you knew nothing, you could just come to it and just learn the syntax. You know, that's an interesting— that, you know, that's for all languages, right? [00:34:42] - Dylan Piercey Yeah. So I mean, it's like, obviously, you know, technically the syntax of Marko is not that complicated. I showed you that, that syntax cheat sheet reference, whatever, that shows like the syntax of Marko. It's just hard to internalize all of that stuff when— especially when you're working in other framework. So it's not hard for LLMs to get what the Markov syntax actually is and how to use it, even in concise mode, which I haven't talked about yet. But yeah, obviously the problem is a developer doesn't necessarily know what's right, and an LLM is just going to hallucinate stuff. So this kind of helps in both cases, right? Um, so that, that answers that, uh, I think. [00:35:20] - Dev Agrawal Uh, it definitely does. I think it's, it's really interesting to see here this perspective because I think So I don't know if you saw, there was another JS framework that was released basically today called Octane, which, which is by Dominic Yanovey. Actually, let me quickly put it in the chat. And I think it takes— [00:35:40] - Anthony Campolo Inferno, right? [00:35:41] - Dev Agrawal Yeah. Yes. And it, it's also like a compiled framework, but it takes the opposite approach wherein, uh, the syntax is identical to React. It's just the runtime is completely different. But to make it the most agent-friendly, it's like the most, uh, like it's all, it's even like it even removed hook rules. Like you can call it conditionally or inside loops, which is some like LLMs love to call hooks conditionally. So it's, and it added support for it. So yeah, it's like 2, uh, yeah, I feel like it's just 2 different approaches to, uh, on something similar. Like even my first, I think, idea was that you're either going to just make it compatible or provide a really helpful error message? [00:36:23] - Dylan Piercey Well, so I think the compatible approach, you know, is valid and like it can work, especially if you're operating under the assumption that you're not going to be reading any code for the rest of your life. But this guided approach, I feel, and I think it kind of proves out as you like use it, especially if you're reading the code, you end up with a cleaner code base, right? Like if you have— if you just allow LLMs to spew out anti-patterns without guidance and like that becomes the common denominator, well then the code that you're reviewing is going to have tons of these anti-patterns and horrible looking stuff to review. That's actually, I think, a strength of the Marko language is that since it is so simple, as long as you know how to write it, it's easier to review. You've probably seen, it was a while back, someone did a benchmark that was like how much tokens basically does it take to represent whatever they were building in every framework. It's like Marko's always the least. And I think if you care about reviewing the code at all, having a framework that does that for you and encourages LLMs to do that, I think is super important. Now, obviously, we can get into the conversation of whether or not you should be reviewing the code and whatever. But I think all else being equal, this approach allows you both, right? Like, you don't have to worry about the LM messing it up, and if you go to review it, you're going to have something that is relatively idiomatic. [00:37:53] - Dev Agrawal Yeah, and even beyond just like the authoring experience, I think like everything you, you've been talking about so far about like what makes Marko so special, uh, or like so performant, it's like it— you, you— Marko finds the most of efficient ways to prune away things and only keep what's relevant, which means even if the LLM kind of messes up a bunch in the codebase, Marko will somehow like sift through that and still find the most performant way to actually execute whatever the LLM wrote up. So even if you just like for a second just forget about reading the codebase, you're still going to get much better end result because the compiler, uh, even like at compile time, at runtime, it knows, uh, like even if it didn't— you did not write the most idiomatic and efficient code, the compiled output is still going to be that. [00:38:46] - Dylan Piercey Yeah, and it's a both-and thing, right? Like you can, using a compiler, encourage LLMs to write idiomatic good code, and that's what people are trying to do, right? Like they're like, okay, we need to use these like linters and we need to have our harness setups that everything is good. And yet at the same time, we're also thinking we don't need to worry about this kind of stuff or this superficial thing, and we're just going to allow our framework or tooling to absorb absolutely everything the LLM is going to output, and then we're going to be able to review it. I mean, I just don't really see that working for stuff that you actually plan to review and maintain for long periods of time. Obviously, it's a valid approach. We'll see how it works out with Octane and all that stuff. There's the 2 things that we get to do. We get to, with the compiler, encourage LLMs to write idiomatic code, consistent code to avoid hallucinating other framework patterns, and then we get to use that same compiler and everything it knows to output hopefully as optimal an experience as we can. Even here in this simple counter, Obviously, in a lot of frameworks, like you look at this JS 1.17, some frameworks that might be 117 instead of 1.17. But anyways, and what's kind of interesting, I mean, if I go here, what's actually in the client bundle? I'm zoomed in a little bit, but you can see this is ultimately what Marko sends to the browser. It's not totally minified. Obviously, you wouldn't get script here, and these are coming from the runtimes. There's the, the 1 KB is the runtime that powers this, you know, subset. But at the end of the day, it's a script that registers a click handler. There's no button, right? And like count never gets updated, so count isn't even in this bundle, right? The real example here would be, you know, count++. Okay, so now it's changed a little bit, but if you look at this, okay, so we still have our script with the click handler being registered. And then we have this count function that updates— don't worry about the internal names of things or whatever. We go debug mode, but it'll be a little noisy. Anyways, so we update count. And so what does count do? So count is this let, which is just some runtime that memoizes stuff and makes things reactive. But at the end of the day, this let is just updating some text of something in the scope at B. With the value of scope C, which is what we said over here. Which ultimately just means this template compiled to you click the button and it essentially directly goes and updates the text here. So, what's not here is, you know, the button itself, creating the button, all of the code related to that. Like if I add a class to this and I'm like class foo— [00:41:33] - Anthony Campolo Real quick, what does that mean for accessibility? Like If there's no button? [00:41:38] - Dylan Piercey Oh, so there is still a button. I'm talking about the client JavaScript. [00:41:41] - Anthony Campolo Okay. I just want to make sure I'm understanding correctly. [00:41:43] - Dylan Piercey Yeah, yeah, yeah, yeah. You said no button. [00:41:44] - Anthony Campolo I'm like, how could there be no button? [00:41:46] - Dylan Piercey Yeah, there's still a button. And so if we look at the rendered HTML, this gives you a better idea. So we've got a button. It's got the class. We've got this. Marko has these compact markers that allow us to track where the reactive things go. So this one is basically saying, we need to keep track of this text node because we're gonna update that count later. And then this one is saying we need to attach an event handler to the button later, right? So there's obviously a little bit of overhead in that, but you can think of these conceptually, especially this one, as if you were gonna write this yourself, you would just put an ID on this thing and do a query or a class and a querySelector or whatever. So this is just like Marko's kind of querySelector that is a bit more generic. But so at the end of the day, what happens is the server renders this and the server knows exactly what the client needs. So the server is gonna output these comments and then the client, when it resumes, it doesn't have to re-render the button. It doesn't have to set the class or anything like that. That's already there in the DOM. All that the client has to do is the stuff that the server couldn't, which is attach the event handlers and run effects. And so that's what this is, right? So this is just This script basically is registered and it says, whenever the server says we need to call this A0 script, we're gonna set up this event handler, which there is a part of the rendered HTML I didn't talk about. And obviously this isn't like a super critical detail, but there's this inline script, which is quite minimal, which is just to go and like find these comments and stuff. And then at the end of this inline script, there is this, which just says— well, so basically this is the C0, so this is like the server value of count because we needed to serialize count because we're referencing it in here, right? So the server figured out that we need to serialize the count. So count starts at 0, and then here it's saying execute the script with this ID with scope 1, basically. I mean, that's like implementation-y detail stuff that doesn't really matter, but the way to think about it is this script at the end basically says walk those comments and then the server says execute this effect, execute this script, execute that stuff. And so when the browser mounts, it's not doing a full re-render of the application to get the event handlers or set up the state or anything like that. The server already did all that. All that the client does is register this code essentially that says, okay, well, if the server happens to render this button, you can pass me the scope and I'll set up the event handler. And so obviously this scales a lot more when you have bigger applications and more stuff that is static. This is pretty much as dynamic as it gets. You have a button. The only thing that isn't dynamic here is the button itself. So obviously you're losing a lot or you're not gaining a ton, although it's still small because of the runtime size and all that stuff. But if I were to even wrap this with a div or wrap it with another component or have 100 components and pass input through or whatever, it's still gonna output this, right? Even if I were to just take this and whatever, throw this over here, and then on this side, just have my Counter component, So this is interesting, right? So I have this thing that's referencing the Counter component. There's no client JavaScript for this index Marko at all. It's just completely pruned. It doesn't do anything. It just sets up stuff for the Counter component. So if I go back to the Counter, this is still all we get in the bundle. So the bundle didn't even change by this little refactor that I did to abstract it into a component. And that's kind of how Marko is set up regardless of how many components you have, it is looking at all of these, what we call tag variables, variables that come from tags, how they go through the application, which ones are stateful, and what needs to be bundled and serialized to resume efficiently. So whereas if you think of Qwik or whatever, if it's resuming, it's gonna be resuming potentially at a component level, especially if you're re-rendering stuff. Marko never does that. Right? It's just going to be registering essentially these scripts and event handlers. Technically, there's, you know, more nuance to it and whatever, but that's like the conceptual way to think about it. Does that sort of make sense? [00:46:14] - Dev Agrawal It does. I think for me, like, me personally, I think because I'm so SolidJS-brained, everything— like, everything you're saying just kind of makes— like, it feels pretty aligned. I think if If anyone's familiar with Solid, it's kind of like a helpful comparison maybe. Because when you go from React to Solid, what happens is that when you click buttons and when there's any events, React re-renders your components. And when you go to Solid, you don't re-render entire components. You only run the reactive nodes that actually need to update. So, you go from rerunning entire components to only running these small bits. So, I think a way to visualize Marko would be the next step of that where imagine I click a button and only 5 reactive nodes need to rerun for my update. Well, now imagine that we only have the code for those 5 reactive nodes in the client at that time. We don't have any other code because it didn't need to be there. [00:47:15] - Dylan Piercey Yeah, and this is something I didn't really bring up at all as far as what separates Marko. So I'm guessing now, I haven't really looked at Octane's implementation. It's possible. I have no idea what it looks like. Maybe they're doing something crazy. It's too new. [00:47:30] - Anthony Campolo We don't need to worry about it yet. Yeah. [00:47:32] - Dylan Piercey But anyways, to my knowledge, as of yesterday, Marko is the only compiled reactive system. Right? So if you are familiar with Solid or any other templating language that has reactivity, in the signals-based mentality, you're thinking some piece of data changes and then that goes through a graph and updates just what's necessary, right? That's the conceptual model of it versus the React model where you update some data and everything— not everything, but you know what I mean— everything from top to bottom, which is in some ways a simpler mental model, but it obviously can be less efficient and all that stuff. So Marko is compiled fine-grained signals. [00:48:17] - Anthony Campolo Quick question. This may be splitting hairs, but I want to hear both your and Dev's take on this. Isn't JSX compiled? [00:48:26] - Dylan Piercey Yes, but we're talking about a very different compilation, right? Because obviously JSX is, you know, essentially a language that could compile to whatever you want. It's just that you have arbitrary XML in JavaScript expressions. So you have to make— your framework has to make sense of that and decide what that means. So in React, that syntax means you're gonna return some XML and every time you do an update, it's gonna re-execute that XML with a very simple, essentially function call style transformations. So what you write versus what gets executed is actually very simple. It's purely just like a DX thing. People don't wanna be writing function calls. And actually, in very early versions of React, some people just chose to write createElement and stuff manually. They didn't wanna use JSX. So the fact that you can write it— yeah, exactly. So LMs might not, who knows? Anyways, Yeah, so that's kind of the superficialness of JSX in terms of how it's used in React. And so that's all it was designed to be able to do, right, is to be able to represent these function calls. Obviously, you take something like Solid and it's a little bit more advanced and trying to look at the JSX and figure out how you can make things more fine-grained and where are the holes in the JSX so you can pipe things through. And so there's a little bit more that goes on there, but you're still thinking of things from, okay, I have these arbitrary expressions that are in JavaScript, right? And JavaScript is obviously incredibly dynamic. You can do crazy things in JavaScript. So what does it mean to have like a div in some random function and there's some try-catch around it or switch or like who knows what syntax you're using, right? What does that mean? You have to decide what all that means, but you are stuck if you're using JSX with it being arbitrary XML in JavaScript. So you have 2 options. You can lean into that and allow arbitrary XML all over your JavaScript, or you can do something like Qwik does where we, you know, you have restrictions, or even Mitosis, you have restrictions around where you can put the JSX, what can wrap the JSX, and all that stuff. But In my mind, that is hobbling what JSX was designed to do. So you run into the limitations of that quite quickly. So JSX was basically just built to represent a function call tree. So if you're using it for more than that, then you can run into language design issues. And that's where something like Solid, I think, runs into You know, like showTag and state being able to be represented wherever. So like one of the things in Marko, you know, I said it starts from HTML. And, you know, we don't have to talk too much about syntax, but this is kind of a philosophical thing of what the language can actually represent. So, so like basically starting from HTML pretty much means that everything has to be declarative. And it also means since we're extending this declarative language, we can make a lot of optimizations, right? Because if you think of something like a regex, who even knows what engines are doing behind the scenes with your regex? And that is because it is like a DSL that is meant to solve a specific problem. Now imagine that you have the same implementation of the regex, but it's represented as a JavaScript function, right? The engine is gonna do its best. It's gonna, you know, V8 can only do so much to optimize your JavaScript. So that's kind of the same thing with JSX where you have this XML representation, but it's inside JavaScript. So you can't make a lot of assumptions about how it's gonna be used, about when it's gonna run and all that stuff. Or if you do enforce those assumptions through your framework, then basically developers are gonna be like, wait, I can't reference this variable here, or I can't wrap this with an if statement, or how do I do these things. So then it's going against the grain of what that tool was kind of meant for. So anyways, Marko, very declarative first. How do we extend HTML to be able to represent just the things that we need to build a reactive frontend web application? And so it's just gradually developed to be able to represent that in a very concise way, which means we can do things like have state anywhere in the tree. I can move this let inside the div or inside a component. It can be inside an if. There's no hook rules or anything like that. And it's very easy to take this code and snip it out into another component. Composability becomes a little bit easier and stuff like that. And that's just because we're able to have all this be represented as a declarative language rather than having to be like, okay, how is this conceptually run top to bottom? In Marko, it doesn't run top to bottom, and you don't really expect it necessarily to run top to bottom because it is a totally different language, right? Whereas if it's JSX, you probably do at some level, especially people probably coming from React to Solid would expect it to run top to bottom. Which is why you need things like the function call or the show tag or whatever it is, right? And that's what trips people up. But anyways, yeah, hopefully that kind of answers your question. So I will say, I'm saying that we have this DSL that's kind of limited, or the purpose of it is to be able to make something that could be optimized more. But If you think of DSLs, it doesn't necessarily mean that the DSL is more limiting than the underlying implementation. If you think about it, every language is an abstraction on top of something else. It's just designed with different goals. So the goal of the Marko language is to be able to represent web UIs declaratively, reactively, and all that stuff. So we're able to have some pretty nice DX once you get into it. [00:54:52] - Dev Agrawal Nice. Yeah, the, the only thing I would, uh, the best way that I'd like to think about JSX compilation is that it's just a fan— like Dylan said, it's just a fancier way to make function calls. Um, I think, uh, JSX is compiled, but like JSX compiler will never touch any other of your code. It's not going to touch anything that's not JSX. It's not going to touch things inside the JSX much. It might like slightly rearrange Yeah. [00:55:19] - Dylan Piercey The thing is, the JSX is not— like, there's gonna be a preprocessing step to the JSX. It's compiled in that way and you can make it mean whatever you want. But the way that React has basically established that it should work kind of informs the language design that they built, right? So anyways, yeah. [00:55:36] - Anthony Campolo So, so am I right in saying that what you're saying is that different frameworks compile it differently? [00:55:42] - Dev Agrawal Yes. [00:55:42] - Anthony Campolo Yes. [00:55:43] - Dev Agrawal Okay. [00:55:43] - Anthony Campolo Yeah. [00:55:44] - Dylan Piercey So, most like VDOM style frameworks are gonna compile JSX basically the same way that React compiles JSX. I guess it's like technically sort of changing with the React compiler and React Forget and all that stuff. Obviously, they're making somewhat different meaning of it, but trying to make it semantically execute the same-ish way as you could have thought about executing it before. But with Marko, Obviously, we don't have that restriction, right? We designed a language that is able to represent reactivity without— while still being able to be optimized and without any of these footguns, like hook rules and all that sort of stuff. Like I said, I can wrap this in an if statement and it's just another tag. [00:56:31] - Dev Agrawal Yeah. [00:56:31] - Dylan Piercey So, does that make sense? [00:56:33] - Dev Agrawal Yeah. [00:56:34] - Dylan Piercey Awesome. [00:56:34] - Anthony Campolo Yeah, continue on. [00:56:35] - Dev Agrawal I think earlier, earlier you mentioned that Marko is also compiled reactivity. I think sometimes Solid kind of gets blamed for like being a compiled reactive framework. Yeah, this basically means that Solid is completely runtime, which means when you read a signal inside another memo, it's only going to know that at runtime. Solid has no way of knowing that at compile time. But Marko is compiled reactivity, which means at compile time, you know, uh, you know that this button depends on this count signal. And if you have a derivation in between, you know exactly which signals depend on each other at compilation. Uh, so is it complete? Like, what's the kind of balance between— like, there's still something happening at runtime, it's just like much, much, much smaller than what's, what's something like Solidity. [00:57:27] - Dylan Piercey Yeah, I think, I think this is the simplest way to kind of see it. I mean, this is just the simplest example times 2, right? So ultimately just a counter, but then there's also a double count in play. So what does Marko do here? Ultimately, we have count, but instead of double count subscribing to count or count— yeah, somehow there being a subscription, you can actually see that double count is just a plain function that sets text, right? And so all count does is it at compile time knows everything that it needs to call. So when you update count, what actually happens here is in real life, this is gonna get inlined. So that signal, this signal, this memo that you might have created is gone, right? Because the compiler starts from the sources and figures out what the dependencies are of those sources. And has it so that the source calls its downstreams directly instead of the downstream stuff saying, hey, I'm subscribing to you. Right? Does that make sense? So there's no subscription system here. I mean, it might look a little bit weird that this thing is called let. You might think of it as a signal or whatever, but it is not doing It doesn't even know its downstreams. There's no dependency array or anything like that. All that happens is you happen to reference count in this other signal. The compiler just knows that, so it folds up in. I mean, we output something that's readable so you can see that this was derived from double count, but this is mostly just to make it so that you get readable variables here. And like I said, bundlers are going to go ahead and inline this so that in the actual output, this is basically gone, right? Because it's just like an arrow function and it's only referenced in one place. If it was referenced in multiple places, then obviously it wouldn't be inline. But yeah, so does that answer your question a little bit? There's a bit more to the compiled reactivity, like what happens when things get a little bit more dynamic and whatever. But this— here, let me Let's do it this way. So we'll pass in an initial value to the counter. So we'll pass in 1. And then on this side, Marko receives its props as a variable called input that you can reference. So we can do input, and I think I called it value over here. Yeah. All right. So basically, We set count. Wait, hold on. I needed to make the other thing. OK, so let's actually— what I'm going to do is actually move this count up here and then derive it this way. I think it'll make it easier to see what's going on. And I have to do that. [01:00:31] - Anthony Campolo It's cool. [01:00:32] - Dev Agrawal Just like Marko. [01:00:34] - Anthony Campolo Yeah. [01:00:34] - Dylan Piercey I'm just trying to think of the simplest way to like show the reactivity without introducing other concepts. [01:00:41] - Anthony Campolo Yeah. I was just thinking like looking at Marko code, like it's, it's deceptively simple and complex at the same time. Like, I feel like I understand it, but then like you start explaining it and I realized there's like so much more nuance, like what actually is involved in this syntax, you know? [01:00:54] - Dylan Piercey Yeah. Yeah. I. Okay, so I'm gonna put this— okay, let's just make this as simple as I was gonna go down a path and I don't think I actually wanna go down that path. Okay, we're literally just gonna pass this through. Okay, so at the end of the day, I'm just gonna make this thing as dumb as possible so you can see sort of what's going on. So we're just literally gonna have something— this isn't even a counter anymore, so this is just like display, right? So all it's gonna do is output this input.value, but I'm just gonna show the like cross-template how things work cross-template. So we're gonna call this thing display, like it's telling me. Okay, so we're passing the count to the display and we have nothing in the bundle because there's nothing interactive yet because this count never updates. But as soon as I make it update, which I'll show a cooler way to make it update maybe, but— [01:01:45] - Anthony Campolo I mean, it's an interesting point you just made though right there that if you don't have anything interactive, then no JavaScript gets shipped. [01:01:52] - Dylan Piercey Right. So, that is the main takeaway of Marko 6 is what gets sent to the browser, like in terms of serialized data and bundle size, is based off of the amount of interactivity you have. [01:02:06] - Anthony Campolo Right? [01:02:06] - Dylan Piercey It is not based off of your overall application size. And it's not based off of how many components you have or anything like that either. So, yeah. [01:02:16] - Anthony Campolo That makes sense of what you've been saying about how it's HTML first. Because then you can write it in a way where if there's no interactivity, you wouldn't have to ship it because you're just shipping HTML. [01:02:25] - Dylan Piercey Right. [01:02:25] - Anthony Campolo Yeah. [01:02:25] - Dylan Piercey Like I said, as soon as I make this— as soon as the count interactivity aspect of it goes away, count never changes, the compiler knows count never changes, and so we get an empty bundle over here. Okay. Now this is what I was trying to show. Now ultimately all we're doing is passing this reactive value down through another component that needs to update and display. This is what the parent component looks like, which is essentially the same as what we've been seeing. But if we look at what happens when we change count, if we look at what it does, it's now calling $input_value directly. So it's calling this other function with the current count. And if we go and look at display, we can see that all display compiled to is exporting essentially— I mean, you don't see the export here, but exporting the same thing that we were doing before. So this parent knows that display receives a value that's reactive and it calls the direct updater for that value, if that makes sense. So, you know, what's not here is— I mean, we still don't have like the button in the bundle or anything, but we also don't even have this input object, right? Marko pruned away the input object. It's directly just calling this other function with the input.value. Without having to create any intermediary objects and worry about that. And so that's how things end up getting plumbed down the tree. It's just functions calling other functions that ultimately get inlined by the build tooling that you already have. [01:03:57] - Anthony Campolo Yeah. [01:03:58] - Dylan Piercey Does that kind of make sense how it works across components? So I guess I have like a— [01:04:06] - Dev Agrawal Sorry, go ahead. [01:04:08] - Dylan Piercey I think I could show the debug output because this might make it clear what we're not sending. Basically, this debug mode here shows you what happens if— well, first of all, it changes some of the identifiers to be more readable and stuff like that, but it also shows you what happens if we don't prune anything. You can get a sense of what if Marko sent this whole thing to the browser. And there's a whole bunch more here. It's still small. There's a lot of long identifier names and stuff in here that ultimately compress to basically nothing. So it might look like there's a lot of code. [01:04:45] - Dev Agrawal This is closer to what Solid would ship. If you have a similar component in Solid, this might be something like what Solid ships. [01:04:52] - Dylan Piercey Yeah. So if we look at this, this is what we're looking at, this parent component right now. So this is what it would receive if it fully went to the browser, except for the fact that there's a whole bunch of IDs that would otherwise be compressed to integers that you can't see like that. Anyway, so if we look at this, let's start from the default export. The default export is Marko's top-level API. It's like a template instance. That's what you can call render on and all that stuff from the server or the clients if you wanted to. But realistically, you're not using that. You're just using the declarative APIs. So anyways, to create a template, instance, you pass it the template HTML, this encoded information about how to walk, the template HTML, and the setup code, which would be analogous to how in Solid the component itself is kind of like a setup function. So if we go and look through, I mean, the HTML that this template has is basically inheriting from its child, and then also it has this static button text, everything except the event handler. So that is the static HTML if you were to create this thing from scratch in the browser. And then we've got this encoded walk string, which you don't really have to worry about too much, but ultimately it's just a— you can actually see what it's saying. It's saying go visit display stuff and then get the first element, then go over, and all that is just to hook up essentially Like this text node and to set up the event handler. Doesn't really matter. Obviously, it's encoded to be small and stuff. But anyways, if you look at the setup function, this is what's kind of interesting. So things that we don't send to the browser, we don't send the template, we don't send the walks, and we don't send the setup function, right? Because the setup conceptually happened on the server. So setup in this case is saying, like, initialize the counters. So call that count function that we've been seeing. With its initial value. And also set up the script, which is the one that attaches the event handler to. And since we're in debug mode, we can now see it's this button1. And then that's the script that updates the thing. And then when you turn off debug mode, you can see obviously all of that stuff that the server already did essentially gets removed. Now the server rendering actually isn't this, right? The server render is totally different. The server render is keeping track of what needs to be serialized to some degree, and it is passing an object. There's some more optimizations that we could potentially do on the server side, but at the end of the day, it's mostly just saying, hey, I'm gonna stream out this button. I'm gonna essentially mark that I need to write out that comment for that button. And I'm gonna say, hey client, you need to call this script and here's the scope that you need to do. And this is debug mode, so it has a bit more information than you would normally have here. But yeah, obviously, so what the server did is it sent a button and said to run a script, right? And then in the client bundle, whoops, in the client bundle, we just have the code that is that script. That can directly go and update the value. Now, obviously, this is about as small as you can get for the interactivity that's described here. Even we've got helpers like let and script, and a lot of frameworks are hiding a lot of their abstraction around these helpers, but these really are quite small helpers. Again, if we go to the preview page, you can see we're at 1.65 KB for Marko's runtime. And there's some stuff like we could do better than that, right? And maybe at some point we will do better than that. There's just a performance floor that we're kind of okay with right now. It's like 1 KB. But the other thing with Marko being a compiler is obviously it only pulls in features based off of the syntax and stuff that you're actually using, right? So it does grow. If you were using absolutely every feature of Marko 6, it's basically like 5 KB, 5 or 6 KB. And we might add more to that, but that is essentially just because we're doing so much in the compiler, right? Yeah. [01:09:14] - Dev Agrawal I think one helpful way to think about the compiled reactivity might be like a lot of the compiled code that you showed was reminding me of jQuery code when before framework or before I started using frameworks, I did a a decent bit of jQuery in some random projects. And the way we would write jQuery is you would attach event handlers and you would have maybe some in-memory state. And every time there's an event, you just— you made some calculations and you directly like call— use the query selector, found the DOM element, and updated its text, right? You didn't have— [01:09:47] - Dylan Piercey and I mean, the thing is, that is the underlying APIs that every framework is dealing with. That is Ignoring the fact that jQuery was like a pretty bloated module, if you were to write that in vanilla JS, that is as small as you can implement those experiences. That is basically as performant as you can make it. The problem with that is the DX is absolutely terrible, right? So that's what Marko has, you know, essentially been built to solve, is how can you have that kind of optimization without the horrible DX? Like, you have, you know, fine-grained reactivity, you have scripts, event handlers that are inlined and all look nice. You have composability, you have components, you have a whole bunch of stuff. You have async. But yeah, so Marko is really, how can we achieve what the actual possible performance of the web is while still allowing you to write in this nice, modern, very one-to-one with other frameworks DSL? Yeah, I don't know. And it's— I mean, another thing that's kind of interesting, I haven't showed, it doesn't really matter too much, we'll just get rid of this guy. But one of the things in Marko is how do you write an effect? Like I said, an effect, I'm saying that because every other framework basically calls it an effect. But in Marko, because we're starting from HTML, we call it— it's a script. So basically Marko script tags are special. And so if I wanted to write a script, I mean, obviously this looks like a regular HTML script, but the difference in Marko is that it's reactive, right? So if I go in here and I add a console.log of the count, we can see that there is a script that literally just console.logs something. Obviously, the compiler has turned it into scope B, which is actually the count in this case now. But ultimately, we have this script where every time count changes, it's going to execute. Now, this is where it kind of shows the resumability. So if I go here and we reload— did I mess up? What's going on? Wait. Oh, it's because— [01:12:07] - Anthony Campolo oh, yeah. [01:12:08] - Dylan Piercey Yes, because I didn't do that. [01:12:09] - Dev Agrawal Let's see. [01:12:13] - Anthony Campolo Yeah, really in-depth. What's the term I'm looking for? Your sandbox here. I like that it has all these different modes. It's really interesting. [01:12:21] - Dylan Piercey Yeah, we've been— I mean, the main thing is we want to know, you know, what actual templates produce in terms of HTML over the wire and JavaScript and all that stuff. And we want to have Like to be able to emulate what Marko actually does in the website. So, this website is actually doing a server render of the Marko template and resuming it, right? It's not just doing like a client render and then replacing it. It's creating like a fake server, rendering it as HTML, and then resuming that. So, you get the actual like Marko experience. But anyways, so if we— [01:12:58] - Anthony Campolo Correct me if I'm wrong. [01:13:00] - Dev Agrawal Is this also like when you change some code, And you get new code, like, is it also persisting state? Because I noticed that the initial value in the code was actually— [01:13:10] - Dylan Piercey like, is it hot reloading? Yeah, it is not hot reloading. Okay, it is not hot reloading right now. Um, yeah, so this is just like, you know, you can conceptually refresh the page or whatever and it's, you know, preserving the console or whatever. But if I like reload the page, like, ultimately what we see here is that the client side logged the count, right? And if I increment, the client side is gonna react to that and re-execute that statement just like you would have an effect. There's some other stuff I won't go into, but so one thing I wanted to show in terms of resumability is we've got all this code that's conceptually running on the server. Even this 0 was on the server. I mean, you don't think about 0 executing or whatever, but the button was on the server and none of that made it to the browser. Like I said, we've only got this code here in the browser, which is to basically do the console.log, because we don't even do anything with the count besides log it. All our script does is do the console.log. Anyways, if we go back here, another tag that's built into Marko, just because it's handy as a dev mode thing, is we have a log tag. You can just do log, and I'm just doing the shorthand with equals. Which is conceptually the same as doing value equals. We don't need to go into that right now, but ultimately this log tag allows you to print out values at render time. Render time, right? So when did this component render? It rendered on the server, right? So we see in the log here, if I get rid of this one so maybe it's less confusing. Oh, come on, go away. We logged 0, on the server. And if we look at the— well, okay, first I'll click it. We click it and then the next log is in the browser, right? Because the server serialized this count and the browser is continuing on from that point. And if we look at the bundle, we can see it's essentially the same thing except the that we have the console.log compiled in directly to the let because that's what this ultimately compiles to. [01:15:20] - Dev Agrawal Yeah. [01:15:21] - Dylan Piercey So all that is to say, we have this log that's happening on the server and then resuming in the browser whenever the interaction happens. If I were to not update the counter or whatever and clear this, obviously, that code for the log is just totally gone, right? So all we have is an empty function that gets registered in the browser. Yeah, that's Marko today. And I think between the fact that we've tuned the language to allow LLMs to produce essentially optimal-ish Marko, or at least idiomatic syntax for Marko, and the fact that we are looking at your code in such a fine-grained way to produce minimal bundles. That's the value prop right there. If an LLM is going to produce your code, why not have it produce optimal code? That's where we're at. We've got a lot more that we want to do. We talked a little bit about our RSC-style thing. I don't know if it makes sense to demo it. The demo is probably kind of hacky, but we could go into that. But that would be maybe more in the weeds. I don't know where you guys are at this time. [01:16:45] - Anthony Campolo We can keep going for a little bit. I was going to say, Dev, if you have any questions to wrap up this topic, that would be good. And then I want to talk a little bit about Marko Run and where that's at. [01:16:52] - Dylan Piercey Okay. Yeah. [01:16:54] - Dev Agrawal I think a quick question before Marko Run to kind of tie in the other topic that I wanted to talk about as well. Obviously, Marko, you mentioned that you can steer agents to write idiomatic performant Marko and then also compile it to be the most performant thing. At what point can a human stop reviewing the Marko code that my AI is writing? Can we reach a point, can you make Marko good enough? That an AI can write it and I don't have to review all of it, at least? Like, I can enforce some additional structure. Yeah. Or like, if maybe phrased in a different way, when would a user, a human developer, need to review an LLM-generated Marko code? [01:17:47] - Dylan Piercey Yeah. So I think it depends on what you're building, how much you understand what you're building, and how much what you're building is in the training data. So basically, you know, there's multiple things that can go wrong when you're building something with an LLM. It can hallucinate and it can just do something totally bizarre that you didn't expect. So obviously that's possible. So if you're not looking at the code, you don't know if it like accidentally deleted half your stuff. So there's always that, but you know, the agents are pretty good. But the other thing, even if LLMs were perfect on their execution, we don't know what we want to build all the time. We could have indirectly told an agent to build something as a single HTML file. Maybe we're not a developer, maybe we don't understand that, right? But our language, the way we were talking about it, guided an agent to do something terrible. If you're not looking at the code and if you don't understand ultimately what is done under the hood, depending on what you're building, you're gonna have a hard time. And it ultimately depends, like, is it a throwaway project? Is it something where you're just happy with it in whatever state it is? Do you care about it being performant? Do you care about it being secure? Obviously, if you don't care about any of those things, then don't look at the code. I mean, just don't waste your time, right? But if you're building something and you're trying to make it like a long-term thing, you want it to be robust, and you want to actually understand what's going on, then yeah, I think you have to read at least some of the code. What works really well for me is to have agents produce small amounts of code at a time that you can actually digest, at least for important projects. And agents are getting better and better at doing exactly that and producing code That is approximately what you would imagine in your head. So that's great. But if what you had in your head was wrong in the first place and you're not reviewing it, then that doesn't help. [01:20:00] - Anthony Campolo Yeah. [01:20:01] - Dylan Piercey Does that answer your question? Yeah, no, I'm curious where you guys are on that, like how y'all are reviewing code, how much, where you draw the line. I'm a mix of both. There's projects where I'm not reviewing the code at all. There's obviously Marko where I'm reviewing pretty much every line. I mean, obviously, like certain things in Marko, if it's adding a test and I have verified things, like maybe I'm skimming it more, right? But at the end of the day, you make the judgment call of, is this thing critical? Do I understand what it's doing? Does the shape look right? [01:20:37] - Anthony Campolo Yeah. Yeah, the way, the way I've kind of fallen into it is that I, I will ship a bunch of features and I won't look at the code too deeply. And then at a certain point, I'll kind of go back and be like, okay, what is all this crap that my AI wrote for me? And then I'll figure out like, where are there issues with it? Or issues will just kind of like arise. I'll be like, oh, there's this huge issue here because I wasn't reading the code and then I'll kind of fix it. So. I feel like it, it really comes down to like, what is the stakes of your application? You know, if you're just building your own kind of, you know, toys for whatever, it's not as big of a deal. But if you are working on this framework that's supporting, you know, a giant e-commerce site, you know, it's a whole different sort of situation. [01:21:24] - Dylan Piercey Yeah. And if you're prototyping something, like don't review the code until the prototype looks like it's working in the shape that you expected. Right? Like, yeah, try not to waste time. Like, we want to be able to get done as much as possible. If an LLM can shoot out something that you could then go and review and learn, you know, that even for projects like Marko, that can be helpful. Having it just prototype some idea, and I can see what the statistical average approximate of what I described would look like, you know, that can be helpful in and of itself. Yeah, but no, I still read a lot of code. I read more code actually. I don't know if I'm sleeping enough to do that. There's a lot more code to be read. Yeah, yeah, there's a lot more code to read. There's too much code. So yeah, I mean, honestly though, if you're going to maintain quality, like I said, trying to have minimal PRs and small change sets and all that stuff, I think is hugely important. And to plug Marko, it simply is the most concise way to represent a lot of what you would build in web applications. Go to Component Party and compare the Marko examples to anything else, and that amount of code and the amount that you'd have to review scales. So anyways. [01:22:51] - Anthony Campolo Yeah, I think in an AI world, You can actually, it's easier to make the pitch for Marko than it would have been, you know, 5 years ago when you were first telling me about this, because you would have had to learn a new syntax or a new mental model. And like now you just put your agent at it and be like, write this Marko thing and you'll get all the benefits. So I think you actually, I think you can make a much better case for it now in an LLM world. [01:23:12] - Dylan Piercey Yeah. And honestly, from my perspective, one of the biggest downsides outside of eBay for Marko was the lack of ecosystem and tooling and all that sort of stuff, right? [01:23:23] - Anthony Campolo Yeah, that doesn't matter anymore. Like. At the ecosystem, at the ecosystem is gonna steal my credentials, you know, like I'm trying to get away from the ecosystem at this point. [01:23:32] - Dylan Piercey Yeah, yeah. Well, so, and I mean, it's like easier than ever to roll your own things too, which, you know, has pros and cons. You want to have like vetted solutions, right? Like, yeah, you don't want stuff stealing your credentials. So like at the end of the day, someone's name has to be behind something and you got to trust what you're— whatever. And, you know, maybe you ran Fable for one iteration and maybe someone ran Sol times 10 and Fable times 10 on the same thing and like, so pick that one, right? Like, why waste the— like, you want to pick something that has already been verified at the end of the day. So anyways, that's kind of where I see Marko at right now. I mean, it's pretty easy for LMs to write, especially with the guidance that we give them, and it's easier than ever for us to build and copy tooling that has already been done. It took me a very long time to write the TypeScript implementation or support for Marko. There's a lot of nuance that has to go on there, and there still would have been even if I was using Fable or something like that. I still would have had to understand the code and know what it's doing and all that stuff, but it could have saved me so much time copying things that were just boilerplate. Building tooling for a framework has never been easier, which is why I think stuff like Octane exists. I don't think you would just go and build another framework and knowing everything that you have to build if you didn't have an LLM that could just rapid-fire that stuff out, especially for low-risk tooling. If you're going to build a linter that maybe it has a false positive or something like that or whatever. It's not the end of the world and you can relatively easily fix it with another prompt. But yeah, so I think ecosystem has become a much less important aspect of picking a framework. But at the same time, there's the whole, well, why don't I just build my own and like have to see what the agent puts out, right? So there's always going to be that kind of hurdle. But like I was saying before, if you did that, maybe the agent decided that the best thing was to have a single HTML file with like, you know, 100,000 lines of who knows what in there. [01:25:55] - Anthony Campolo I mean, that's, that's how Levels— Peter builds all his— he has a single one PHP file. Every app he builds is a single PHP file, you know. [01:26:06] - Dylan Piercey Yeah, yeah. I mean, you know, it can be fine depending on how you're trying to scale it and what you're trying to do. If you're happy with it, you're happy with it. So, but I mean, obviously if you hit a performance issue and the solution to solve the performance issue is to boil the ocean, then that's not great. So usually it's better to start from a very more stable foundation than just let it rip. But prototyping has never been easier. [01:26:39] - Dev Agrawal Yeah, for sure. And yeah, I do agree that I think ecosystem becomes less of an argument or less of a benefit for bigger frameworks. Sometimes it might even become more of a liability because the AI has just been trained on outdated patterns. But I think, yeah, I think I definitely want to use the rest of our time here to talk about the server component variation of Marko that you're working on. Which I'm gonna take another guess and that's just the next Marko Run. It's gonna be a part of the next Marko Run? [01:27:14] - Dylan Piercey Yeah, it's gonna be integrated into Marko Run. But I mean, basically all that's gonna be in Marko Run is the router aspect of it. The client-side router. Because Basically, Marko Run, if you're not familiar, is the meta framework that we use at eBay and generally recommend people use. It's like SolidStart and Next.js, that kind of thing, but for Marko. So, it has a file system-based router that's kind of similar to SvelteKit. But at the end of the day, it compiles your app into a router that serves Marko files. And so, with our server component solution, which is very promising. Prototypey. I mean, we've had a lot of prototypes and it's been a vision for a long time, but it's definitely not ready yet. But anyways, the Marko Run is a router on the server, but it also now sends a micro router to the browser to be able to preload stuff that you might need as you navigate across the app. So I'm trying to think if it makes sense to show a demo. I'm kind of thinking maybe we stay here and I can show conceptually what happens. But yeah, so basically, if I just go back here and we put this back to the simplest possible template and Let's see. So we've got this button. OK, so at the end of the day, I had already shown what Marko renders on the server for this button. It's essentially sending these markers for stuff that it's going to need to be able to update in the browser. If this count never updated, then we lose the marker for the count. Makes sense. It doesn't need to ever update in the browser, so we lose that count. So what our Server Components solution does is enables comments for anything that could have been updated on the server following the same reactive graph. So ultimately, a Marko template on the server receives the top-level input, which is you can pass to the application. It also receives this basically context that's usually where you store all of your promises for pending data that you fetched for whatever you're building, like your actual API data. So you pass that through the application. Marko can track that too. So essentially in this new mode, anywhere where you have one of those values, it also sends a comment even though normally it it would be server-only, right? So there is an overhead to it, but what it enables is any of these values that would have been server-only but could update now have a marker in the DOM that on a subsequent navigation, the server can say, go update that specific hole in the same way that here, If we look at the client compiled, it's saying when we update the let, go update scopeB's text, which scopeB is our button text, right? Go update scopeB's text to bc, which is the count. So in the same way, the server can actually send basically a JavaScript payload that says, go update that marker. To this value. But there's a whole bunch more to it than that. But one of the things is, well, what if you have some server-only control flow? So if I have something like if— I mean, we can even do like this. [01:31:20] - Dev Agrawal If— [01:31:22] - Dylan Piercey okay, well, that— [01:31:23] - Dev Agrawal okay. [01:31:23] - Dylan Piercey So if I have like if true, hi, that's not a part of the bundle. It's gonna be output in the HTML or whatever. So this is a server-only control flow. This could have anything in it. This could have a div or whatever. So the browser literally does not know about this at all. It's not a part of the bundle. So what we do in this new mode is we say, okay, is this control flow triggered or updatable through one of these server expressions, like an expression that can change on the server. So if it's if true, obviously the answer is no. If it's something that's static, like from module code, the answer would be no. But if it's something that can be derived from the server, then the answer would be yes. And so what our mechanism does in that case is it Checks— well, basically on the first render, it sends the markup inline in this streaming script that has the holes, is what we call— I mean, you know what I'm saying when I say holes, right? [01:32:34] - Anthony Campolo Yeah. [01:32:34] - Dylan Piercey So it's got— [01:32:35] - Dev Agrawal Can we try if count greater than 0? Would that show it? Yes. If you have it working, that is. [01:32:43] - Dylan Piercey Yeah. So this actually doesn't have the the prototype in here. [01:32:48] - Dev Agrawal Okay. [01:32:49] - Dylan Piercey I'd have to like— no, that's fine. Maybe we could, I don't know. [01:32:54] - Anthony Campolo Yeah. [01:32:56] - Dylan Piercey So, if you had something like this, the compiler knows that this is a client-driven state. So, the server never sends anything about that state, right? Because we're only sending stuff for what is conceptually server Updateable holes. So now what's interesting is, well, what if instead of this being like count greater than 0, count is a client state, what if this is like count greater than, like, let's just say input.target or something, I don't know, something. And we'll say that this input, I mean, in this case it's not because this is like a top-level template that doesn't receive anything, but let's say that this input.target was from the server and we knew that. So what would actually happen is you get this code. So do I want to have an if? I mean, there's like a whole bunch of things to explain here, but at the end of the day, we get this gate that says, if either of these 2 things change, execute this code. So in this case, it's update the if's condition, which does a whole bunch of other stuff. But anyways, let's update the if's condition. But we have this intermediate signal that's like, okay, if we update count or if we update target, do this stuff. So what happens here is in our mode, which we call persisted pages, it's like a working term, basically the bundler knows, okay, this is a server-driven value. The server-driven value is not a whole by itself. It's not something we can just update directly. It interacts with client state, and so it will actually call this function directly with the new scope value. So what would happen here is if there was something that caused a client-side navigation that ultimately caused input.target to change, the server would send code to update input.target and call this intersection of input.target and count directly. Does that make sense? Which is ultimately the same code. I'm not running it in the new special mode or whatever. It just shakes out of the compilation strategy that we— ultimately, the client would just register this or in a way that the server can call it, just like it registered the script in a way that the server can call it. And the server knows, hey, this is something that I can update. So I'm gonna say, hey client, here's the new value for that. And there's also automatic memoization and stuff like that in these APIs. That's really what these wrappers are kind of for. So if the server sent the same value again, it's not gonna throw everything away and reinsert it and stuff. But that's the core idea. And hopefully, you can see, just given the compiled output that we have, how this is enabling that ultimate mechanism, because this was really designed with that as the ultimate goal. So I have a fairly vibe-coded e-commerce demo that I'm comparing to RSSs and stuff. I mean, it's probably totally broken right now, maybe. Okay, I'm gonna pull it up real quick. It's probably totally broken. [01:36:18] - Dev Agrawal While you do that, I think I'm going to try to explain, uh, the mechanism that you just explained about Marko, but in more like React or Solid terms, and you can kind of double-check my understanding. Um, like the React Server Component solution today gives you like the serialized JSX of the UI as it was rendered on the server. But what you were saying is that when the UI renders on the server, like, uh, first of all, when the client sends a request to the server, the client sends some sort of a checkpoint of like where the client is at right now. So, the server, once it renders the like conceptually JSX, the UI on the server, it compares it with what the client checkpoint. And instead of sending the JSX, it sends it a bunch of setters. Like set value. [01:37:08] - Dylan Piercey More or less. It's actually in a very similar format to the— I mean, we didn't go into it that much, but what was sent in that initial HTML where it's like a script that is ultimately an array of things that the client needs to apply. So, there are like scripts to execute and scopes that got serialized. And our serializer is obviously, you know, pretty crazy. It can serialize any type of data that you can think of, really. Like promises and like all this sort of stuff. Similar to Seroval in Solid. And so, I mean, we can look at it here real quick. I'll open up the dev tools and we can kind of see what's going on. Now, I think— [01:37:46] - Dev Agrawal conceptually, you're not sending the nodes themselves. You're sending a bunch of functions that will be called that are basically like setters that will change the value in those nodes rather than something that client will then just look and compare every single node. [01:38:00] - Dylan Piercey More or less, yeah. Yeah. I mean, another big part of it though is that at least the core we're designing to be stateless. So the way to think about what we're building is a pure upgrade to an existing multi-page app experience. So right now in a multi-page app with Marko, we send minimal JavaScript and we send the HTML fast, but then you do a navigation and you get more HTML and more minimal JavaScript for that other separate page. And that can be fine, but obviously you lose ephemeral state and all that stuff, which is what we're trying to answer. So the question is, how can the server say, hey, you're already on this page, let's navigate and go through the exact same ideally stateless flow where you're saying, okay, here's the whole page again. I don't know anything about you, but here's the whole page again. [01:38:58] - Anthony Campolo Ideally. [01:38:58] - Dylan Piercey But the thing is, we do know about the client. We know what route they were on and what they're going to and all that stuff. So we essentially can encode some of that information very compactly, send that to the server and say, hey, just send me updates. It goes down the same render path basically, but it just sends updates. So if we look at this e-commerce, very basic Vibe-coded, essentially, demo, and I refresh here, and I'm probably gonna need to make this bigger. This is in production mode and things are cached, whatever. Okay, let's see. So the initial load isn't super interesting, and there's some dev mode stuff in here that doesn't really matter. I don't know if I'm gonna be able to find the chunk here in the production preview. But so basically what this has is a little bit of functionality for this search experience to optimistically add to cart, to optimistically watch, and a few other things. But for the most part, it's authored like an MPA. So these are links and forms all over the place. And we've got some JavaScript here for the initial load, which is essentially the exact same JavaScript you would get for a normal Marko app, except you get this router that can lazy load these partial update appliers that give you the code to get the extra things that the initial page didn't need. Anyways, so if we follow through and we go and click on this, we get— oh man, I might have messed up the caching or something like that, so it's very hard to see what's going on today. I have cache enabled. Okay, well, we'll just look at this right now. I think caching is disabled on the server, so a lot of these assets would've been cached, but they've been re-requested. But ultimately, you're gonna get some extra code specific to the other page that we went to that is its client interactivity. So we navigated to an item page. That item page has client interactivity. We send that. And then you get another chunk that has, how do we apply the updates from the server to that client interactivity. And then, so those 2 are both cached and they're both also very minimal. And then this is the main response that is worth talking about. So this is actually what if we sent the page like an MPA, like all the HTML, but we stripped out everything that we know the client has. Obviously, we did a full-page transition, right? There's a lot that the client doesn't have here. We're going to a totally different experience, but we're actually able to send even what the client doesn't have in a slightly more efficient way because we have our own wire format. This code here, and it's a little bit dev-mode-y, is essentially filling in this top bar here. This is the top bar encoded in a way that can fill in the holes with HTML down below, which we'll see. And then basically different parts of the app. I guess we're eventually gonna get to the items. [01:42:17] - Anthony Campolo Let's see. [01:42:17] - Dylan Piercey So that's— oh, these are like the— what's it called? Is it the recommended products? Anyway, so this is basically the same code that would exist in the HTML response, just with a whole bunch of stuff pruned. Then anyways, Marko applies it, but here's the interesting thing. Down here, you can see it's got the HTML parts that it knows the client didn't have. What it's able to do is actually take that HTML and remember that the client had it. When we do another interaction on the same page, the browser doesn't have to re-request the HTML parts that it didn't even know about. So this would be like server-only HTML, right? So this would be like the if case where, you know, in this case it's a big if. We're going from one route to another route, so we've gotta load, you know, a decent amount of HTML. But what's interesting is if we look at this, this response was 2.1 KB of, you know, the, the polls and a little bit of HTML. And like ultimately Marko applied that without losing the browser state. Now, if I load the page from scratch, it's 3.2 KB. So even this full replacement mechanism still yielded less data over the wire than a full page, just the HTML. So it's purely better than an HTML navigation in terms of bytes over the wire, and you get the persistence. Then the other thing that's nice is, okay, so if I— we'll go back here and we'll navigate to an item and I'm going to clear that. Then say we do add to cart. It updated this here. I did a 3rd interaction. There's 3 levels. I navigated to the item, which gave me a smaller payload to navigate to the item and I got to keep all my state and whatever. Then I added to cart. Add to cart, this is a form. It's reloading the page conceptually and the cart updated at the top. But what we got from the payload— why is it? I don't know why this is not showing. Ultimately, 0.7 KB. This is because it was able to prune all of that HTML that it knows the client has at this point. Basically, What's in here is code to update things related to the cart. And that ultimately is what separates it from React in that you're authoring this thing like a normal MPA. You authored it the exact same way you would write normal Marko code. But then just like how the Marko examples are— if I were to make this in React, it would be 10 times larger at least. In terms of the initial load JavaScript. It's also probably like 10 times less over the wire here than what the RSC equivalent would do. Maybe more. Right? So that's— [01:45:24] - Dev Agrawal it must be a lot more than 10 times because you'd also be bringing in Next.js. [01:45:29] - Dylan Piercey Yeah. Yeah. [01:45:30] - Dev Agrawal That's— [01:45:30] - Anthony Campolo yeah. [01:45:31] - Dylan Piercey Then it gets even worse. But yeah. So I mean, that's basically— [01:45:36] - Anthony Campolo SDK. [01:45:38] - Dylan Piercey What's that? Oh yeah. [01:45:40] - Anthony Campolo The only other RSC framework I know of. [01:45:45] - Dylan Piercey So, I mean, like, at the end of the day, it's performance. You know, it's nice for things to be performant when you need performance. You wish you had it, and sometimes it's impossible to achieve it given what tools you've chosen to use. So that's one aspect of it. But I mean, one of the most important aspects of Marko is that the DX behind building this is actually in a lot of ways better than what you would get with RSC. So specifically with RSC is a lot better because like I said, you're not having to think about where am I use clienting and a whole bunch of other stuff. You're basically just writing your Marko app, you enable this flag, and essentially what the flag does, you know, it does have a little bit of overhead in that it's adding these markers to more places. So in what— in the experience experiments we've done, it's like a 10% initial HTML overhead. But then you get substantially less navigation overhead. And you get the ephemeral client-side, like, feels like a SPA sort of experience. So, it's like a strict MPA upgrade on our existing super fine-grained remove everything architecture. [01:47:00] - Dev Agrawal Yeah, which is amazing because I think outside of like all the DX issues of React Server Components, I think the absolute biggest complaint of the community was that it was not a drop-in upgrade. You had to rewrite your app to actually take benefit of Server Components. [01:47:15] - Dylan Piercey There is not a single line of persisted pages specific code in this particular app. I have a few other apps, like demo apps that are, you know, just to play around with and make sure that we're actually pruning things properly and all that stuff. But right now, the wire format isn't 100% settled, and there's maybe more pruning that we can do in some experiences than others. And parts of it being a prototype are Vive-coded, so it needs a lot more vetting and all that stuff. But that's basically where we're at. And it's able to leverage the vast majority of machinery that we've already built and the compiler analysis that we've already built because we've essentially been planning this from day one. So, and, you know, the nicest thing about this is that it opens up a different category of experience that you could build with Marko while still maintaining essentially all of its advantages. Um, yeah, so that's, that's where we're going, and I don't think it's going to be very long before we get there. Nice. [01:48:14] - Dev Agrawal Have you talked— like, does Ryan know about this? I'm, I'm guessing you, you guys have like shared notes, or— [01:48:20] - Dylan Piercey yeah, he is He knew that this is what we're eventually getting to. Yeah. But there's a whole bunch of technical details of how you prune things. How much data do you send to the server? How are you encoding what the client already has? And there's a whole bunch of things there. And I have a whole bunch of strategies, which is why this is in a very prototypey phase because I'm just trying so many different things. But at the end of the day, you just write normal Marko. Like, that's the goal, right? We've designed the language so you write normal Marko and you get this crazy optimized output that you're not even having to think about. [01:49:00] - Dev Agrawal Yeah. This is especially exciting for me because the reason I got— the biggest reason why I got involved with Solid and SolidStart was because at that time Ryan was very aggressively looking at server component solutions for for Solid. He eventually dropped it. But that was the thing that got me interested in Solid and SolidStart in the first place. Just imagining the possibility of the server component-like solution but in a more fine-grained way. And right now all the focus is on Solid 2.0. But once that gets out of the door, I know server components is gonna be top of mind for Ryan and Solid team as well. I'm probably going to be playing a lot with, with what you guys are building and trying to figure out how. [01:49:48] - Dylan Piercey Yeah. And I think it'll be super cool. And now we have the power of AI, we can finally bridge the gap. You guys do it from the spa side, we do it from the MPA side. We'll see what turns out to be more efficient. [01:49:59] - Anthony Campolo Yeah. [01:50:00] - Dev Agrawal Or we'll all evolve into crabs. [01:50:02] - Dylan Piercey Yeah. Yeah. Who knows? [01:50:04] - Dev Agrawal Yeah. [01:50:04] - Dylan Piercey We'll all have to switch to Rust. I don't know. I mean, it's, it's crazy times. Um, you know, maybe that's the next thing is rewriting Marko in Rust. We'll see. [01:50:16] - Anthony Campolo Yeah. Amazing. Uh, Dylan, I gotta say, I've interviewed a lot of people in the web dev world. You're consistently one of my absolute favorite people to interview because when we have these conversations, I am reminded of how much more I still have to learn. [01:50:31] - Dylan Piercey So there is— it's so hard to get it all out and to convey sometimes the complexity that's here. But I think the results can speak for themselves if you try it out. [01:50:45] - Anthony Campolo I know, it's amazing. And you've reminded me that Qwik is still a thing, which is nice. I want to hit up Misko and get him on to talk about Qwik. And then I want to do an episode where we get both of you on to talk about all sorts of stuff because that's always really fun. I had a good Convo a couple years ago where I had Mishko and Dan, Dan Shapiro, on an episode together. That was super duper interesting. So yeah, I want to try, I want to try and get, uh, yeah, that'd be awesome, of people to talk on stream. So we'd love to have you back again. [01:51:16] - Dylan Piercey Um, you want to just share a while? I talked to Mishko, yeah, well, quite a while, but yeah, yeah. [01:51:22] - Anthony Campolo And yeah, it sounds like resumability is, is a big thing for, for Marko, so that would be a very interesting conversation to have. Do you want to just hit people with your socials where they can find you and where they can find Marko? [01:51:33] - Dev Agrawal Yeah. [01:51:34] - Dylan Piercey So, markojas.com. I had it up. That's like the main place where you can find stuff. We have a Discord that's linked on there. So, you know, hop in if you want to chat. That's probably the best way to reach me. And then I'm on Twitter as my name, Dylan Piercey. And on GitHub as— I missed it. [01:51:48] - Anthony Campolo Dylan Piercey was in the chat. He— had him on the stream a long time ago to talk about Marko Run. [01:51:55] - Dylan Piercey Yeah, and I guess we didn't talk about Marko Run, but really quick, Marko Run has also seen a lot of improvements. There's now first-class validation support and data loading APIs and a whole bunch of things that are somewhat table stakes and whatnot. Marko Run itself has improved a lot, but it also has a lot of the agentic support that I talked about. Marko Run itself is in a way a compiler. And so, it uses a lot of the same techniques to be like, oh, this looks like you probably meant for this to be a route. Did you mean that? And here's the cheat sheet. And, you know, similar kind of mechanisms there. So, there's been a lot of work on Marko Run as well. Ryan's been doing a lot of work there. [01:52:38] - Anthony Campolo Yeah. Yeah. We can talk about that more next time we get you on. But yeah. No, this has been amazing. Super, super great convo. Yeah. I think that probably about wraps it up for us. Thank you so much, Dylan, for being here. And hopefully, have you back on again soon. [01:52:53] - Dylan Piercey Yeah, that'd be awesome. Thank you guys. [01:52:56] - Anthony Campolo All right, and thank you everyone for watching. We're gonna be back next week with Glauber talking about Turso. That'll be a really great conversation. Um, I love Turso and I'm all about SQLite, so that'll be a good one. And yeah, that, uh, that wraps up for us today. [01:53:12] - Dylan Piercey Thank you.