Dylan Piercey and the Marko Team
A deep dive into the Marko framework’s origins, its performance-focused design, and upcoming innovations as shared by core team members from eBay
Episode Description
Dylan Piercey and the Marko team discuss Marko's history at eBay, its compiler-driven architecture, and how Marko 6 pushes fine-grained reactivity and minimal JavaScript delivery.
Episode Summary
This JavaScript Jam Live episode features Dylan Piercey alongside Marko core team members Michael Rawlings, Luke LaValva, and Ryan Turnquist, with Solid JS creator Ryan Carniato joining as a guest. The conversation traces Marko's origins at eBay in 2012, where Patrick Steele-Idem created it to solve a specific challenge: maintaining fast server-side rendering performance while transitioning from Java to Node.js without sacrificing developer experience. Dylan explains how Marko distinguishes itself as a compiled language rather than a templating layer on top of JavaScript, enabling automatic partial hydration, streaming, and optimized server-versus-browser compilation from the very beginning — features that other frameworks are only now adopting. The team walks through Marko's unique syntax, which extends HTML with composable tags for control flow, refs, and state, arguing that this approach yields better TypeScript integration, easier refactoring, and fewer abstraction leaks than JSX. A significant portion of the discussion covers Marko 6's forthcoming compiler-driven fine-grained reactivity system, which breaks templates into independent hoisted functions, enabling dead code elimination and resumability at a granularity beyond what Qwik or Astro currently achieve. Ryan Carniato offers an outside perspective, calling Marko the most underrated JavaScript framework and emphasizing how its long design history has produced solutions the broader ecosystem is only beginning to explore.
Chapters
00:00:00 - Introductions and Show Setup
The episode opens with hosts Scott Steinlage and Anthony Campolo welcoming listeners to JavaScript Jam Live and introducing the topic of Marko. Scott encourages audience participation and mentions upcoming events like React Miami before handing off to the guests.
Dylan Piercey introduces himself, explaining how he discovered Marko while working at an agency building websites five years earlier. He describes how Marko aligned with his thinking about web performance and developer experience, which ultimately led him to join eBay. Luke LaValva and Ryan Turnquist also introduce themselves as newer members of the Marko core team, with Luke noting he came to eBay straight out of college and Ryan mentioning his background on the Solid JS router.
00:04:31 - Marko's Origin Story at eBay
Dylan traces eBay's technical history from its 1995 founding through its Perl, C, and Java eras, explaining how each migration was driven by scalability and performance needs. By 2012, eBay needed to move to Node.js for developer productivity while maintaining the rendering speed of their Java stack, which is what motivated Patrick Steele-Idem to create Marko.
Michael Rawlings adds context about eBay's Polyglot Initiative, where engineering leadership encouraged experimentation with new technologies. DustJS briefly served as a templating solution due to its streaming support, but Marko was built to go much further — compiling templates to raw string concatenation on the server, supporting streaming out of the box, and automatically determining which components needed to be sent to the browser, all concepts that predated similar features in React, Astro, and other modern frameworks by years.
00:10:15 - Marko as a Language and Compiler
Dylan explains what makes Marko fundamentally different from other frameworks: rather than layering syntax on top of HTML or embedding HTML inside JavaScript, Marko extends HTML itself into a full declarative language with built-in control flow tags, composable primitives, and JavaScript expressions as attribute values. He contrasts this with JSX and Svelte's approaches, arguing that Marko's language-level design enables better optimization and dead code elimination.
The discussion highlights how Marko's composable tag system lets developers build custom versions of built-in control flow — such as animated or paginated for-loops — using the same syntax as core tags. Dylan also explains how Marko's language semantics enable superior TypeScript support, including automatic type narrowing for conditional rendering and hoisted ref types, advantages that are difficult or impossible to achieve when the underlying representation is plain JavaScript.
00:18:16 - Developer Experience and the Tags API
Michael Rawlings introduces himself and the conversation shifts to Marko's developer experience. Luke LaValva shares that the learning curve was shallow, estimating he learned most of Marko's features within a week. Dylan explains how Marko's tags API functions as a superset of what hooks provide in React — every tag can render DOM, provide variables, or compose behaviors, without hook ordering rules or conditional rendering restrictions.
Michael makes the point that Marko allows an entire application to exist in a single file without performance penalties, echoing Dan Abramov's idea about the value of being able to create a temporary mess. Dylan argues that the only valid reasons to split components should be reducing duplication or managing cognitive load, not framework-imposed constraints. The team emphasizes that refactoring in Marko requires touching fewer places in code compared to React's hook-based patterns.
00:24:11 - Marko 6 and Fine-Grained Reactivity
Michael explains that Marko 5 uses a virtual DOM but Marko 6 is moving to a fully compiled fine-grained reactivity system. Unlike traditional signals runtimes, Marko 6's compiler analyzes the dependency graph of your code and outputs hoisted, independent functions that execute in the correct order, enabling direct DOM updates without a VDOM layer.
Dylan contrasts this with Qwik's approach, explaining that while Qwik downloads entire templates when re-rendering, Marko 6 only bundles the specific functions needed for expressions that can actually change. Luke adds that this means a component with sometimes-dynamic attributes only ships JavaScript for the instances that need it. The team shares that their Hacker News demo produced roughly one kilobyte of final JavaScript, significantly smaller than comparable implementations in other frameworks.
00:31:21 - Learning Curve, Team Structure, and Outreach
Anthony asks the newer team members about their onboarding experience and the team's organizational structure. Dylan explains that everyone is focused on engineering, with Michael primarily working on Marko 6 and Dylan having recently completed TypeScript support. The team operates within eBay's Web Foundations group, which handles broader front-end infrastructure and guidance.
Dylan acknowledges that the team lacks dedicated evangelism or design resources, with most outreach happening organically. He notes that while Marko's relative obscurity is acceptable given eBay as a guaranteed large-scale customer, the team plans to increase visibility once Marko 6 ships. Anthony and Dylan both emphasize that while Marko's internals are complex, the actual usage experience is approachable for developers familiar with HTML and JavaScript.
00:44:22 - Comparing Marko 6 with Qwik and Resumability
Dylan provides a deeper comparison between Marko 6 and Qwik, explaining that both frameworks support resumability but Marko 6's compiler achieves finer granularity in serialization. While Qwik serializes at the component level, Marko 6 only serializes data that is directly consumed by browser-side effects and event handlers, resulting in smaller payloads.
The team discusses their Hacker News benchmark results and the various technical challenges involved in shipping Marko 6, including building a sophisticated serializer, a smart enough compiler, and finalizing the language APIs. Dylan mentions a target of June for a beta release, noting that while the timeline has slipped, the parts that do work already demonstrate significant performance advantages over existing solutions.
00:48:22 - Micro Front-Ends and eBay's Architecture
Dylan explains how Marko 6's minimal JavaScript footprint is particularly important for eBay's micro front-end architecture, where individual pages and even embedded experiences within pages are maintained by separate teams with independent dependencies. These embedded components — like recommendation widgets or help dialogs — must add minimal JavaScript overhead to avoid degrading the performance of high-traffic pages.
He describes how the contract between these micro front-ends is HTML-driven rather than client-side module federation, with embedded applications delivering partial HTML that gets injected during server rendering or in the client. Dylan frames Marko's two-pronged value proposition: performance that meets eBay's demanding requirements, and a developer experience that he believes would delight developers if they gave the language a genuine try, despite the initial unfamiliarity of the syntax.
00:55:05 - Routing, Progressive Enhancement, and Marko Run
An audience member asks about routing, and Dylan explains that Marko applications traditionally relied on server-side routing through Express or Fastify since they were designed as multi-page apps. Ryan Turnquist describes Marko Run, the new meta framework that introduces file-system-based routing compiled into optimized trie structures of if-statements through a Vite plugin.
Dylan then discusses his pre-eBay work building a progressive enhancement framework similar to what Remix later became, where a lightweight client-side router intercepted link clicks and form submissions using the same API as the server. Michael notes that Marko Run is incorporating similar patterns from Remix, and the team emphasizes that Marko's HTML-first approach naturally lends itself to progressive enhancement and accessibility, including features like stable server-rendered IDs that React only recently addressed.
01:10:05 - Ryan Carniato on Marko's Significance
Ryan Carniato shares his perspective on discovering Marko, explaining that he was pulled in by Michael and Dylan while writing about signals and reactivity after React hooks launched. He describes being astonished that a JavaScript framework had been operating with server-first, streaming, and partial hydration concepts for nearly a decade before the broader ecosystem caught on.
Ryan recounts moving his family to San Jose at the start of COVID to work on Marko full-time, and reflects on how the deep design thinking behind Marko 6 traces back to around 2017. He argues that even if Marko 6 takes longer to ship, it won't feel outdated because it has leapfrogged several intermediate steps that other frameworks are still working through, making it a smart long-term bet on where front-end development is heading.
01:21:43 - The Case for a Purpose-Built UI Language
Ryan Carniato makes the argument that JavaScript has fundamentally failed as a language for representing UIs, pointing to hook rules, reactivity gotchas, and the gap between what code looks like and how it actually behaves. He notes that even Svelte's compilation approach falls back to plain JavaScript for composition patterns, limiting what the compiler can analyze and optimize.
Dylan and Michael agree, explaining that Marko's purpose-built language avoids the abstraction leaks that come from repurposing JavaScript syntax with altered semantics. Michael shouts out Dylan's work on tooling that makes the custom language feel seamless in editors, and Dylan draws a parallel to how TypeScript initially seemed like unnecessary extra work but became indispensable. The chapter closes with the team's philosophical stance that a language-level solution to UI authoring, while labor-intensive to build, represents the most promising path forward.
01:30:46 - Closing Thoughts and Future Plans
Dylan summarizes Marko's philosophy of pushing partial hydration to its logical extreme — rather than shipping islands of components, Marko 6 aims to send only the exact JavaScript functions needed for browser-side updates, approaching the theoretical ideal of a hand-written inline script. He frames this as a natural extension of server rendering that remains surprisingly underutilized across the ecosystem.
The episode wraps with Dylan encouraging developers to study web history and think about what makes the web platform unique rather than chasing surface-level trends. Anthony pins links to Marko Run and the project's Discord community, and the team invites listeners to visit markojs.com to get involved. The hosts preview upcoming JavaScript Jam episodes and sign off.
Transcript
00:00:20 - Speaker 1
Hello?
00:00:20 - Anthony Campolo
Hello, hello.
00:00:23 - Dylan Piercey
Can you hear me okay?
00:00:26 - Anthony Campolo
I can, yes. What's up, Dylan? Have you done many Twitter spaces?
00:00:29 - Dylan Piercey
I've only done one before, and I am still shocked that you can only use them, or be a speaker on them, on mobile.
00:00:40 - Anthony Campolo
Yeah, no, totally. Well, cool. We're happy to have you for your second space. So it'll be fun.
00:00:46 - Dylan Piercey
Yeah. Some of the others on the Marko team are also, in theory, going to be joining. We'll see if they chime in. They're just installing the Twitter app because normally they would use the web app, but anyway.
00:01:04 - Anthony Campolo
Point them out if they hop into the crowd and I'll add them as a speaker. What's up, Scott?
00:01:14 - Scott Steinlage
Hey, hey. What's up, everybody? Welcome to JavaScript Jam Live. Oh man, it'll be a good one today. Oh yes, Marko is what we're talking about today with our dear friend Dylan. Hello, hello, hello. Super excited. Anthony's face today is JavaScript Jam. So if you don't know who Anthony is and you're listening to this, just search the Twitter Spaces, the Twitters, for Anthony Campolo, AJCWebDev, JCWebDev. You'll find him there. Be sure to follow him, and you know, JavaScript Jam [unclear] as well. But let's give you some value first today. Let's have some fun together. Like I said, we'll be talking about Marko, as you can see from the title, with Dylan here. But I just want to say this real quick. Whether you're a beginner or you've been doing web development for a very long time, that doesn't matter. We want to hear from everybody, right? So feel free to request to come up, and you can ask questions, state facts, opinions, whatever. We love to hear everything. In fact, actually, when someone comes up, that's when we get the most value from the sessions together because people are engaged and having fun.
00:02:51 - Scott Steinlage
It creates some great conversations. So feel free to request, come up. We'd love to have you contribute and be a part of this amazing group that we have every Wednesday at 12:00pm Pacific Standard Time. And real quick here, just want to note that in the near future we are going to be going to some events. JavaScript Jam will be there. Anthony and I will be there. And one of those events is React Miami. Don't know if you're going, but it's gonna be a good time. I think there are a lot of great speakers there, and we will be there live together. So looking forward to that. We have more things coming up in the future weeks. Let's talk about that as well. But enough of that. Let's talk about today with Marko. Marko with Dylan. Marko and Dylan together.
00:03:45 - Dylan Piercey
Dylan is Marko.
00:03:49 - Anthony Campolo
Pretty dang close?
00:03:51 - Scott Steinlage
Pretty much. All right, by the way, real quick, I'll introduce myself, and then Anthony can introduce himself. And then, Dylan, you can introduce yourself. But my name is Scott Steinlage, and I am the technical community manager at Edgio.
00:04:07 - Anthony Campolo
Hello, hello. My name is Anthony Campolo. I am a developer advocate at Edgio and I am super excited for this episode. I'm a big fan of Marko. I see Michael in the audience. I know someone else will probably be pulling up here. But Dylan, why don't you go ahead and introduce yourself and tell our listeners a little bit about your background and what Marko is?
00:04:31 - Dylan Piercey
Yeah, for sure. Hello, my name is Dylan. I actually discovered Marko while I was working at an agency that essentially hammered out websites. So this was five years ago now, or actually a bit more. And so I was hammering out websites and, you know, there were various different requirements that came up, and ultimately it kind of had me thinking about what the web should look like, what its strengths are, and how I can build performant websites, ultimately. And so I built some tools around that and ultimately discovered Marko, which is super different from a lot of the other technologies at the time. And it was invented, actually, by Patrick Steele-Idem at eBay way back in 2012. And so it kind of aligned with some of the things that I was coming to believe are the essentials of the web. And so I looked at integrating it with my tools, and ultimately one thing led to another and I ended up joining eBay. So I've been at eBay for the past five years, and Marko came out of basically a need that eBay had to maintain developer productivity and maintain site performance at the same time.
00:05:53 - Dylan Piercey
So I could go into a little bit more about Marko's history, which I think is really interesting just because it is such an old framework, but has been continually evolving. And I think if you've never heard of it, it's got a lot of things that you would kind of be surprised about, considering when it was built. I've also got Michael Rawlings here in the chat. He's a part of the Marko core team. And we've got Ryan Turnquist and Luke as well, who have actually joined us in the past year. How long has it been? I'm actually not 100% sure. But anyway, they've been doing great work on Marko as well, so they'll probably chime in at some point. Maybe they should introduce themselves real quick as well.
00:06:42 - Anthony Campolo
Yeah, I said speaker invites to all three of them.
00:06:46 - Dylan Piercey
They might not have downloaded the Twitter app, so they can't speak. Okay, we've got Luke. Hey, Luke.
00:06:53 - Luke LaValva
Hi. I guess I could do introductions as well. Yeah, yeah. I'm actually a pretty recent college graduate. I kind of came straight to eBay through Marko, out of college, and I think I got really lucky because now I'm sort of obsessed with the developer experience that comes with front end, and I think Marko is a pretty great solution for that. I'm sure we'll go into that more later.
00:07:23 - Anthony Campolo
A very sweet place to be right out of college. You're getting a very thorough web education.
00:07:30 - Dylan Piercey
Yes, yes. It's definitely some fun stuff. I mean, I've been working on Marko for five years now, and it's like there's constantly new and exciting things to be looking into beyond what we're even working on right now. We have a vision way out into the future of what we think we can accomplish with it. And it's got a fair bit to it, just because Marko is a language, Marko is a compiler, Marko is a bundler in some ways. It's a whole bunch of things. It's really trying to take on the whole server-to-front-end asset orchestration pipeline and rendering and all of that. There's a whole bunch of different pieces to it, and pretty much every one of those pieces can be optimized in some way. There's lots and lots of exciting stuff there. We've got Ryan here now as well.
00:08:25 - Ryan Turnquist
Hey, I'm Ryan Turnquist. Yeah, I just joined eBay in, I guess it was August, working on Marko. I'm a member of the Solid JS core team as well, where I was mostly working on the router. That's my background.
00:08:44 - Dylan Piercey
Yeah. And Ryan's actually been working on a thing that we released just recently, which is Marko Run, which is like our meta framework built on top of Marko, which is actually kind of funny. I mean, we had a meta framework before, but it was somewhat limited. And the reality is, because of the way Marko is set up, you don't really need a meta framework to work with it. And since it's super performance-focused as well, a lot of times people just want to have their bespoke setup that's tuned exactly the way that they want. And so they're not necessarily looking for these meta framework tools. But anyway, we wanted to build a meta framework that actually met all of the needs that eBay had in terms of performance and also just have this modern DX and all that stuff. So Ryan's been doing a really good job on that specific piece. Yeah. We've got Michael here as well. If he's not able to be a speaker, I'll just... maybe he'll... I don't know. There's no chat in this, right? Like, it's just...
00:09:44 - Anthony Campolo
So you can tweet to the space. I actually just did. And then you can pin things on the Jumbotron. So right now we've got the Marko Run on top.
00:09:56 - Dylan Piercey
Yeah.
00:09:56 - Anthony Campolo
Cool.
00:09:57 - Dylan Piercey
Yeah. So Michael has also been a part of the Marko team for, I think, six years now. So he's done a lot of great stuff for Marko too. Yeah. So should I just, like, dive right in and give people a little bit about, like, what and why Marko? Obviously, I've talked a little bit about it. Yeah.
00:10:15 - Anthony Campolo
Go as deep as you want. We got plenty of time. Cool.
00:10:18 - Dylan Piercey
So, yeah, basically, if you've never heard of Marko, probably the first thing you're wondering is, like, why does this thing exist? And then you're also probably thinking, like I already said, it was created in 2012, so what was the environment like there? How did it get to that point where it seemed like a framework needed to be developed, and there were a whole bunch of frameworks being developed? So I want to dispel a little bit that it's just another framework that was tackling the exact same problems as React or Angular or Vue or anything else that was coming out around the same time. So it actually kind of starts, obviously, with eBay's history, because it was a framework that was designed to meet eBay's needs. But the specific thing with eBay is, you know, it's been around since 1995.
00:11:03 - Anthony Campolo
Right.
00:11:04 - Dylan Piercey
And obviously at that time, the experience was not built with any JavaScript in mind. And also, as an experience, it was something that scaled, or needed to scale, a lot, right? Like, it got a huge user base right away. It kind of blew up into popularity. And so essentially the very first version of eBay, called Auction Web at the time, was built with Perl. And pretty much within a couple years, they realized that it just wasn't going to scale, and so they actually switched the entire backend rendering experience to C so that it could be faster. And we're still talking hardly any JavaScript at that point. So these are just experiences where we're sending HTML to the browser, and the whole experience is driven through link clicks, navigation, form submissions, and that kind of thing. So it's pretty lightweight, and obviously back then it had to be in the '90s or the users would just never be able to load the page, because I'm pretty sure you couldn't load modern pages back in the dial-up days anyway. So eventually the C code base ended up being pretty hard to maintain, and so they switched to Java, which is like a happy medium. But it was still very much server-rendered and a focus on performance and all that sort of stuff.
00:12:21 - Dylan Piercey
But in 2012 there was a serious concern about what the developer experience was like, where you're essentially, you know, at this point there's JavaScript in the browser for sure, but just for the interactive pieces you'll bring in jQuery to enhance some portion of the experience. Then you've got the Java application doing the bulk of the rendering on the server. This ends up being relatively fast, even bringing in jQuery. But the reason it's fast is because, one, Java's rendering is fast, two, you can leverage streaming and techniques like that, but also because since you're only sending the interactive pieces of JavaScript to the browser, you essentially don't have this modern problem where, in a SPA, you end up sending the entire app to the browser. So the JavaScript scaled a lot better than many modern SPA-like setups. And so basically what happened was eBay was looking at things like, Node.js looks cool, single language across the stack makes sense for rendering, where you're going to be doing all of your template code. You don't want to duplicate that with the browser. So this is like a clear DX issue.
00:13:33 - Dylan Piercey
But at the same time it's like, we can't compromise on performance. Like, every millisecond matters and there's constant performance monitoring on all the pages, and so on. And then the other thing is that eBay, as an experience, is actually a multi-page app where any of the pages that you go to can actually be an entirely separate application, right, maintained by an entirely separate team that's probably using a similar tech stack, but not necessarily. Some of the pages could be implemented even in a different language. There's very limited restrictions on what you can do. You can do pretty much anything. But the main thing that you had to do is make sure that your experience was fast and you could deliver it quickly. So with all that in mind, essentially Patrick Steele-Idem in 2012 was looking into, okay, how can we make a JavaScript framework that has really fast server-side rendering? Because we're competing with the Java rendering. And how can we make it so that, while maintaining a good modern DX, we only send the necessary parts of JavaScript to the browser? And so those are the key fundamentals of Marko. It's performance and developer experience.
00:14:51 - Dylan Piercey
Right. And so, like I said, Marko is a language, and that language is designed to be easy to write. In terms of good DX, it actually starts as HTML but extends HTML in a way that allows you to represent pretty much anything in a very terse format if you want. But then also Marko takes that language and compiles it to completely different things depending on the environment we're deploying to. So, like, on the server side, and this is way back in 2012, we're compiling the templates to raw string output on the server, like no VDOM overhead or any weirdness like that. And there is actually a benchmark way back then as well that was showing Marko as, like, hundreds of times faster than some of the other solutions. And at that time there was also the recommendation from Angular and stuff like that to do this prerendering, which is spinning up a whole browser, and that would be even more ridiculously slow than something like a VDOM. So anyway, Marko optimized for string concatenation on the server and then eventually landed on a VDOM implementation in the browser, although it was loosely VDOM. But two different compilation targets was a necessary thing from the beginning.
00:16:12 - Dylan Piercey
So Marko was a compiler from the beginning, which meant it can do some of the fun things that you might think of when you think of Svelte. Obviously it can do tricks that don't really make sense from something as simple a language as JSX. So Marko kind of always had that. And then Marko also always had this feature of streaming templates because it's critical when you have an experience that's consuming so many different data sources and these data sources have varying amounts of latency. You don't want your application to be as slow as the lowest common denominator. Obviously, you know, React has only semi-recently come out with streaming support and other frameworks are picking that up as well. But that was a key thing in Marko as well. And then the other key thing is the opt-in to which components get sent to the browser. You can think, if you're familiar with Astro or even React Server Components to a degree, you have to essentially say these are the components that get sent to the browser. And in Marko we wanted to make it so that that wasn't something you really had to think about.
00:17:20 - Dylan Piercey
So in Marko, actually what happens is the same process under the hood is going on where it figures out what server components are, what browser components are, how do we only send necessary code to the browser, but we do it automatically. That's kind of been our ethos, like how can we make it so that it feels like you're writing in a quote-unquote modern style framework without having to make these concessions to the developer experience to achieve performance? So that's really been our goal, and that's essentially where Marko is at today. You can think of it as a competitor to Astro and Qwik to a degree. But there's a whole bunch more stuff and things that we've been working on to go well beyond this whole, like, what we call partial hydration and progressive rendering and these sorts of things. So maybe we'll talk a bit about that. Do you have any questions or anything from anyone in the audience?
00:18:16 - Anthony Campolo
Yes, that's. That's all good stuff. We have Michael up here now, so we should have him introduce himself and dive back into the framework.
00:18:25 - Michael Rawlings
Yeah, I'll just be quick. Yeah, I'm Michael Rawlings. I've been working on Marko for — I guess, six or seven years now. And yeah, I ended up at eBay working on Marko. Just found it as I was working on some projects of my own and started contributing back to the framework and then ended up working for eBay. So that's kind of my origin story. I've been around the framework for a while now.
00:19:08 - Anthony Campolo
Awesome. I guess I would be curious. My first question would be, do you know, and this may be history that kind of predates you, if eBay kind of considered other frameworks before deciding to build their own.
00:19:20 - Dylan Piercey
Yeah, yeah, Michael can speak to it. Probably better.
00:19:24 - Michael Rawlings
Well, yeah, so around 2012 there was actually an initiative that was called the Polyglot Initiative. And so it wasn't just Node that was being looked at. There was some Scala code being written. And basically the engineering leadership kind of gave free rein and encouraged people to just try out new technologies to see what the future of eBay should look like. And so what ended up winning that and kind of coming out on top was Node, and originally DustJS was kind of the only existing framework that met eBay's needs to some degree from a performance perspective. And primarily that was because it's like the only templating language for Node, prior to, like, 2020, besides Marko, that supports streaming.
00:20:22 - Anthony Campolo
That's fine. I never even heard of DustJS.
00:20:26 - Michael Rawlings
Yeah, the original author kind of disappeared
00:20:31 - Dylan Piercey
and LinkedIn and eBay sort of took
00:20:33 - Michael Rawlings
over maintaining the project for a little bit, but both of them ended up moving on from Dust as well. So it just kind of went up
00:20:41 - Scott Steinlage
in Dust or something.
00:20:44 - Dylan Piercey
Yeah, it's just a templating language, though, not a framework so much. You know, it's more like if you're familiar with Pug, or what was Jade, or EJS, or those kinds of things. It was basically just a simple server-side templating language that allowed you to do streaming, which was something that eBay realized pretty early was going to be a requirement to use Node.
00:21:11 - Anthony Campolo
What's up, Dan? Slowly turning this into a Solid team.
00:21:16 - Dylan Piercey
Yeah, I know. I've been a fan of Marko from afar. I like how it makes me feel like a space alien. Yes.
00:21:27 - Dan
Like, the templating syntax, it's very, very unique.
00:21:33 - Anthony Campolo
Yeah, well, we talk about that, actually. So, like, what is the... there's like a Marko language, right?
00:21:40 - Dylan Piercey
Yes, and I think it's honestly one of my... it's probably my favorite thing about the whole project, is this language, and it's very opinionated. And it's also something that I think takes developers off guard when they first see it. Obviously, like, space alien. But the really interesting thing about it is I feel like there's been essentially zero competition in the component-based, declarative UI framework authoring experience. Like, what does it look like to, in a nice way, author these declarative things without having to put a whole bunch of imperative glue in between? And so, you know, we've been trying to look at what that means, and also a big reason for us to do that is kind of twofold. One, we want to make sure that everything you can do in the language is composable. Like, you can take our primitive language syntaxes and build complex things on top of them. But then we also want to make sure that everything is super optimizable. And so, like, we want to be able to differentiate between, you know, this is JavaScript, where something crazy can happen in between, and this is Marko code, where we have known constraints, and so we can optimize and, you know, do dead code elimination and...
00:23:00 - Dylan Piercey
And that sort of thing. Yeah. So Marko, as a language, what does it kind of look like? You start with HTML, right? So you start with HTML. You can, in most cases, take valid HTML code, put it in a Marko document, and it just kind of works. But Marko actually extends HTML instead of just adding syntax to generate HTML. So, like, if you think of JSX or something like that, it gives you escape hatches where you can interpolate in expressions that return more JSX. All of the building up of the conceptual HTML happens in JavaScript, in this imperative world, unless you're looking at something like Solid, which takes a little bit more control over that. In Solid, you have the control flow components, but Marko's had control flow components from the beginning because we're trying to understand that entire picture, and we don't think control flow components are the only place where, you know, having it baked into the language can help us out. And actually, real quick, since we have the Solid team here, I think this is kind of an interesting one, because I know it's...
00:24:11 - Dylan Piercey
We were seeing some Twitter threads about, you know, Solid and the Show tag not narrowing the conditions, right? So in Marko, the Show tag kind of... there's a primitive for render.
00:24:29 - Anthony Campolo
Did you explain what these components are for people who've never used these things before?
00:24:34 - Dylan Piercey
Right. So basically, Marko has built-in tags for control flow, which is like if statements and looping logic. And that's similar to...
00:24:45 - Anthony Campolo
Svelte also has this.
00:24:47 - Dylan Piercey
Yeah, but so in Svelte, you know, they essentially tack on a language to HTML, right? Like, you've got the double, or you've got the curlies, and then you've got the hashtag if.
00:24:57 - Anthony Campolo
Right?
00:24:57 - Dylan Piercey
Like, it's a templating language on top of HTML, right? In Marko, there is a tag that is called if, and you can pass it a condition and it conditionally renders its body, right? But it's all a part of the Marko syntax. And you can actually go and build your own if tag that does, you know, some slightly different behavior. Maybe you wanted to have an if tag that was animated, right? You could build a tag in userland with the exact same syntax as our core if tag and have it be animated. The same applies to our for loops. That syntax, like, you can use the exact same syntax, create your animated for tag, and all the end user of your component has to do is swap out their for tags with your animated for tags. Maybe it's a paginated for tag or whatever. But all of this stuff can be composed into different things that still leverage the same Marko language, which makes refactoring a lot easier, which is actually one of my pain points with JSX in that, like, if you want to have a simple if statement, for example, in your template, like a simple conditional section that's rendered, you might throw in a conditional expression or, you know, the ampersand thing.
00:26:11 - Dylan Piercey
Whatever. Like, you're going to do a check and it's all going to be in the JavaScript. But now say you take that same requirement of conditionally showing something and add the animation requirement that I mentioned. Well, now you have to operate in components, so the person that wants to adopt that has to go in and change their code away from JavaScript syntax into the template syntax in order to abstract away that sort of behavior, if that makes sense. And Solid, you know, has the same composition model, at least in terms of the control flow. Does that answer the question of what these... yeah.
00:26:46 - Anthony Campolo
Yeah, that's good. Yeah. So what was your question for the Solid team?
00:26:50 - Dylan Piercey
Yeah, so this is more of just like a little tiny friendly jab. But so the. One of the benefits of having this be a language, and Marko's semantics being that the body content doesn't evaluate until after the child says that it wants it, is we can know that it's impossible for stuff to change out from underneath you. So in TypeScript, in Solid, if you're using a show tag and you narrow something so you're like, show this when the user is defined or something like that, well inside the body. Because Solid uses render props or not render props. I guess it's like a function body thing, which is essentially render props. TypeScript will not know if that user object has changed by the time that function runs. There's no way that TypeScript could have that guarantee.
00:27:37 - Anthony Campolo
Right.
00:27:38 - Dylan Piercey
But in the Marko language, we do have that guarantee. And so with the Marko TypeScript support that we just put out, that narrowing actually does just work. And it doesn't matter, you know, what kind of narrowing you're doing. It's just like Marko knows that the language works in a way that that narrowing is valid. And so we essentially tell TypeScript, hey, that's valid. You can output that. And so there's a few things like this. Another one is, well, like tag references. So, you know, like useRef and stuff like that. Marko has this explicit syntax for that as well. And that syntax actually allows for hoisting. And that's actually pretty powerful because often when you have something like a reference, you want to get a reference to some element and then use it somewhere else. What you would do in React or Solid or whatever is essentially put a let statement at the beginning of your component function. And that would say, okay, I've got this ref, and then you have to type what that ref is going to be, even though it's only used in one place.
00:28:43 - Dylan Piercey
In a perfect world, TypeScript could infer what the type of that ref is. But because Marko has a special syntax for that and allows hoisting all that stuff, you can basically get a ref to a div or any element or whatever, and Marko is going to know exactly what type that is, and you're going to get the right type IntelliSense for it as well, which is pretty nice. There's a few places in the language where, because we're able to represent things in a way that is within our language, that we have control over, that we can actually make the completions better, we can make the compiled output better, and in this case, you know, we can even make the DX better. It's more composable. You don't have to say, okay, I've got essentially this code for the ref in two places. It's in the top of my function and it's down in my template logic as well. Instead, you could have it in one place where you probably wanted it, right? So it makes refactoring easier. And there's a whole bunch of things that we're thinking about like that that go into the language design.
00:29:40 - Dylan Piercey
And so one thing to point out is, like, when you first see Marko syntax, again, think of it as HTML as if HTML and JavaScript were built together at the same time, with the goal being building components. What we've done is essentially added additional features to HTML that might sound limiting at first, but actually we've added pretty much every feature you could possibly need. And it's been battle-tested as well at this point. So one of the things that's actually quite nice is any attribute value is just a JavaScript expression. That's what you're passing, at the end of the day, to these tags, as JavaScript expressions. Why can't the attributes that you pass just be JavaScript expressions so you don't have to wrap everything in curlies or anything like that? We aren't worrying about weird escapes for single quotes or anything strange. It just kind of works. The attributes in Marko templates are JavaScript expressions, which is actually quite nice. And then there's also shorthands for methods. It just follows the JavaScript shorthand method syntax. There's also, like I mentioned, ways for tags to provide variables, which is very similar to hooks, ways for tags to inject variables into the body, which is similar to render props.
00:30:58 - Dylan Piercey
But like these things are a core part of the language because we know you need them and we know we can optimize them better and provide better DX around those types of patterns. So yeah, and it's, it's also designed to be like a very incremental thing as well, especially if you're coming from HTML. It's a little bit trickier if you're coming from JSX, wondering what's going on.
00:31:21 - Anthony Campolo
But yeah, this is good, actually, because Dev had a question and I wanted to ask some of the newer members of the Marko team, what's it been like getting kind of spun up with Marko? Has it been challenging, or has it made sense coming from your other JavaScript experience? Or like, what's the learning curve been like?
00:31:41 - Luke LaValva
I think the learning curve for Marko is actually really shallow. Especially, well, right now everything coming out is Marko 5. Marko 5 is pretty similar to Svelte, I would say, kind of because you have separate classes. But Marko 6, I think, is going to be huge because the developer experience has a much smaller learning curve. I think if you already know HTML and JavaScript, then knowledge of React will also be really helpful. As someone who came in as a React developer and a vanilla JavaScript developer, it was less than a week before I felt like I knew most of the features of Marko, so I think it was pretty easy to come in.
00:32:24 - Dylan Piercey
Yeah. And a lot of the power features, similar to React hooks, like, you might not necessarily understand how a hook is implemented, but you know how to go and consume a hook. That API is pretty easy. And kind of the same is true with Marko's tag variable syntax. Like, basically a tag can do anything in Marko. It can give you variables, it can provide variables to its body, it can render content, like, all of these things, but it can all be abstracted. So it's very easy, especially for new developers who are more likely to consume these complex components, to just throw them into their template. And it just kind of makes sense, right? They don't have to worry about things like hook rules or anything like that that could trip them up, which in my view is like an abstraction leak. But the other thing is, I guess specifically talking about hooks, is hooks cannot render DOM. And I think that is a pretty strange limitation. But I mean, I get, obviously, why React did it. But in Marko's case, everything is a tag. It can render DOM or it cannot render DOM, which means you can create hooks that compose different types of behavior.
00:33:32 - Dylan Piercey
Like you can create a tag that tells you without having to pass around refs or doing anything weird if a current section of the DOM is in the viewport. Like, things like that, things that are actually context, like DOM position awareness, you can do with Marko's equivalent of hooks. So there's just superpowers like that that come out as well that make it easier. That's not to say that those kind
00:33:52 - Michael Rawlings
of things can't be represented by hooks, because a hook in React could return like a JSX element that then you place in your JSX tree at a specific location. So, like, I don't know that there's anything that like, can't be represented by other frameworks, but I do think that a lot of these cases, it's just less code and I think easier to understand with the syntax that we have with Marko.
00:34:22 - Dylan Piercey
Yeah, that's definitely a good point. All of this stuff, you can build with vanilla JS as well. It's more talking about the developer experience part of it. Sure, you could have that hook that gives you a reference to something that you can put in the DOM, but wouldn't it be nicer if you just didn't have to do that at all, or think about it at all? And that is the case with Marko's tags API. And yeah, so there's just a lot of things like that where you're not having to duplicate where things are defined in multiple places whenever you're refactoring. One of the key things React hooks, when they announced them, highlighted was you want to make sure that you're touching as few places as possible. And since in Marko everything can be co-located right next to the implementation or the usage of the tag, it's very easy to do that kind of co-location. There's no arbitrary rule that says, okay, hooks have to go up here, and they potentially have to be in this order, and they can't be rendered conditionally.
00:35:21 - Dylan Piercey
And all that sort of stuff doesn't matter. You can put a hook anywhere in your Marko template. Inside a div, it doesn't matter. Inside an if statement. All that stuff is, is perfectly valid. So it's like, yeah, obviously the React solution for how do you conditionally render a hook? Well, you have to basically refactor your code and split it out into another component. In Marko, you just put another piece of state at that location. It's a one line change versus premature refactoring. And so those are the kinds of places where you really see a win. With the Marko language.
00:35:57 - Michael Rawlings
I'll chime in and say I saw a tweet from Dan, I don't know if it was Dan Abramov, earlier this week, or maybe it was last week, about the beauty in something that's able to create a temporary mess. And he was specifically talking about React and Tailwind. But I think there's an aspect of that to Marko's language in that you could write an entire application in a single Marko file. There's never a point where you're forced to split things out into components, either for performance reasons, to control what updates, or because of hook rules or anything like that. You can represent your entire application in a single Marko file. Now, should you? You know, that would be a mess. But I think there is something nice to being able to hack in a single file and then split things out according to your mental model of the application and not be constrained by what the framework model needs
00:37:09 - Anthony Campolo
to be in a single file. Yeah.
00:37:14 - Dylan Piercey
From my perspective, it's always like, well, I mean, why do you have to go into thinking about how I'm going to refactor things into multiple components when you don't even yet know how your application is going to be broken into components or what duplication exists in your application and stuff like that? So usually when I look at refactoring, in terms of evaluating how good the refactoring experience is in the Marko language, it's, am I duplicating stuff? Okay, well then, you know, that should be refactored so that the duplication doesn't happen. Or is the file just getting unusably large, right? Like, is this just too much? Is there too much cognitive load in this file? That's another valid reason to split out. But those are, like, the two main valid reasons. If you're doing something and it's a small component and your framework forces you to extract it out into another component, or forces you to move around a whole bunch of code to be able to do your next step, that's where I feel like, you know, the framework is really letting you down.
00:38:08 - Dylan Piercey
Refactoring.
00:38:10 - Anthony Campolo
So Ryan coming up here to achieve Solid-Marko parity. Also former Marko teammate, I think he gave us...
00:38:19 - Dylan Piercey
He still has Marko in his in his Twitter bio.
00:38:22 - Michael Rawlings
We still consider him core team.
00:38:25 - Anthony Campolo
Nice, nice. His connecting thing is spinning and spinning and spinning. We had another question from the audience about state, and this is probably good that Ryan's coming up as well. They said, after briefly looking at how to create state in Marko, it seems like it's very similar to React. Not sure about that. In essence, components rerender when you change state. Seeing the collab between Solid and Marko, is there a plan to make DOM updates more fine-grained? I would also add onto that: when signals? Yeah.
00:39:00 - Michael Rawlings
So Marko 5 is VDOM-driven. We do have a preview of the APIs that are coming to Marko 6 in a tags API preview package that you can install, and it basically gives you access to all these let tags, const tags, and a lot of these things that Dylan has mentioned. In some ways that's kind of like a stepping stone to where we're going. And it also looks, I think, in many ways, like what React is doing with React Forget because it puts fine-grained execution almost on top of the VDOM model. But with Marko 6 we are dropping the VDOM and going fully to... they're not signals. I mean, they conceptually are, and they're using a propagation mechanism that in some ways is similar to what MobX has, but it's almost more so just like functions calling other functions, in a sense. The Marko compiler compiles to these signal functions that basically ensure that things run in the right order so that you don't see any glitches or anything as data propagates throughout the tree. But it is fine-grained, and basically when you update a value, it calls a function which passes any computations to the next thing down the line and ultimately directly updates a DOM node.
00:40:49 - Michael Rawlings
So like that is coming soon.
00:40:52 - Dylan Piercey
Yeah, actually this is one of those things where it's almost better to be able to show the code, because this signal-like implementation is very different than anything I've ever seen in any other framework, because it's entirely compiled. So basically the Marko compiler goes and looks at your code, figures out the dependency graph of the code in terms of expression execution, and outputs a whole bunch of functions that are all at the root level, basically detangling your code so that we can call these functions in the correct order. That follows the way you typically think of signals. But one of the big reasons this is important to us, I mean, one, it's pretty fast. But the big thing is that since we've essentially untangled your code, if you have a text node that gets changed by, you know, props to the component changing, there's a fine-grained line of individual functions that get called in between. And all of those functions are hoisted. The key there: since they're hoisted and detangled, we can actually dead-code-eliminate all the ones that can never change. And so this is what...
00:42:00 - Dylan Piercey
One of the big things that differentiates Marko 6 from Qwik is that essentially there is no concept of, okay, this template is going to rerender, so we've got to download that whole template. Obviously, Qwik breaks things down at the template level. So it's not like you download one template, you don't need all of them, but it still does download the entire individual template that's rerendering. In Marko 6, that's not the case at all because Marko goes in with a compiler and detangles your entire template into a whole bunch of independent little functions that can be called in the same order they would have been executed if it was like a signals runtime. So it's a really key part of our hydration and bundling strategy as well. So instead of it being like it is now, where it's partial hydration, sort of automatic islands architecture, it's more that if you have some code that directly goes and updates, there's some state changes and that causes three expressions to run that ultimately changes, like, two DOM nodes. Marko 6 only bundles functions that basically do those things, and not the rest of your template.
00:43:12 - Dylan Piercey
It's pretty huge in terms of the savings you can get from that. And it means if you've got large static portions of your app, they're much more easily able to stay server only versus the Islands architecture, where you add state or a component at some point arbitrary height. Now, like the majority of your application is sent to the browser. So.
00:43:35 - Scott Steinlage
So I really quickly want to say Ryan has come in and out of the room like four times and tried to come up on stage like at least three times. And I don't know what the problem is.
00:43:47 - Anthony Campolo
Yeah, for some reason it's. It keeps saying connecting. It's not. I told him to, to. To just join as a listener and then I'll send him an invite. But he's having some trouble with spaces.
00:44:01 - Dylan Piercey
Yeah, I was having trouble initially because
00:44:03 - Michael Rawlings
I just downloaded the app and then was having like permission issues because I hadn't granted that permission to access.
00:44:10 - Anthony Campolo
He's been on a space with us before.
00:44:12 - Michael Rawlings
Yeah, I don't know then.
00:44:16 - Anthony Campolo
Anyway, continue on with the conversation. Yes. Something else, Dylan.
00:44:22 - Dylan Piercey
Yeah, so I mean, just going into that a little bit, I think comparing Marko 6 to Qwik is one of the more interesting comparisons, just because Qwik is doing a lot of awesome stuff in terms of resumability and the code splitting and all that sort of stuff. So I mentioned sort of what Marko 6's code-splitting model is in terms of breaking up every one of your templates into a bunch of different functions automatically. You don't have to go in and, you know, add dollar signs anywhere or anything like that. Marko just knows where all these expressions are. But the other thing that's actually, I think, quite nice is Marko 6 also knows which expressions are needed in the browser, and it's actually resumable just as Qwik is. And so essentially what happens in Marko 6 is if you have some expression that you calculate during the rendering, and then you have some effect or an event handler or something that needs to be in the browser that is going to read that expression, the Marko 6 compiler knows about that and serializes just those pieces to be sent to the browser. Whereas if you look at something like Astro or Qwik, typically the way that the serialization is going to work, and you know there are optimizations they can do and they do do, is they'll look at it from a component level.
00:45:40 - Dylan Piercey
They'll be like, this component could rerender, and so we'll need to serialize its input, right? And so Marko 6 actually takes it to the next level, and it only serializes data that is used by functions which definitely need to be in the browser, which are the effects and the event handlers. And so that's another... like, all of this fine-grained, compiler-driven signal stuff all ties into our resumability and code-splitting story as well. So I think it's quite unique in that aspect, and we've done some benchmarks. We built, like, a Hacker News demo of it and all that stuff, and it's all super promising. It's just there are so many aspects of it. Like, we have to have, you know, essentially a super-good serializer. We have to have a compiler that's smart enough to break all this stuff up. And obviously we're working on the language and the APIs and all that stuff. So there are so many pieces to it that it's obviously taken us quite a while to get it out, and we'd hoped that it would already be out at this point. And now we're looking at potentially June for a beta of it.
00:46:47 - Dylan Piercey
But it's really quite crazy what it can accomplish in the parts where it does work now compared to pretty much anything else, including something like Qwik. So, yeah, I mean, it's one of those things where it's tricky until you can see the numbers. But hopefully I've done a little bit of... hopefully that explanation makes sense. And if anyone did have specific questions on how any of it works, we'd be happy to answer that too.
00:47:12 - Luke LaValva
I think a really powerful part of this dead code elimination that Dylan touched on, but I think is worth reiterating, is that if you have a component that maybe has dynamic attributes and sometimes doesn't, then it only ships its JavaScript on the times when it has dynamic attributes. So maybe you have, like, a set of comment components and only the ones that were posted by you are editable now. All the comments by everyone else will be shipped as vanilla raw HTML, and then yours will have JavaScript embedded with them only. And that's much more performant.
00:47:58 - Dylan Piercey
Yeah, so I mean, there's a whole bunch of work going into Marko 6 and this DX effort we've had in the new Marko meta framework and all that stuff. Yeah. I'm wondering what else is worth bringing up.
00:48:22 - Anthony Campolo
We should kind of talk about Marko 6 in general, because I know that's something that's been a long time in the making. So, like, for people who've never used Marko at all, why is that something that they should care about?
00:48:35 - Dylan Piercey
Yeah. So the big thing with Marko 6 is obviously, or at least the hard part is really these optimizations that we've been talking about, like super-aggressive code splitting. Like, our Hacker News example, it was like one kilobyte for the entire final bundle for the Hacker News comment thing. And in some ways that's still a huge amount more JavaScript than is actually needed if you just inline it. So there's certainly room to improve. But compared to every other framework, as a baseline, they're like three, four, five, or more times higher, and that's the good ones, right? So for building these really small JavaScript-footprint applications, that's where Marko is going to shine, all the way down, obviously, to zero JavaScript, but really, like, incremental JavaScript. And so one of the places that actually has been causing us to put a bunch of effort into Marko 6 is this whole micro front-end setup that we have at eBay. So actually, you know, I mentioned the individual pages at eBay are in many cases developed by entirely different teams with entirely different dependencies and all that sort of stuff. But it's their responsibility to make sure that their app and the experience that they ship is as small and lightweight as possible.
00:49:55 - Dylan Piercey
So obviously it's useful for that level, and also useful in general any time you have a high amount of content versus interactivity on your site. So it's useful for that for sure. But the other thing is that it actually goes one step beyond that. There are actually embedded experiences on many pages. So, like, a recommended item experience might be brought in, or a get-help experience, like a dialog and all that stuff, might be brought in. And those are also managed by independent teams. And so it's very micro front-end in that way. But our micro front-end setup is not entirely client-based, like module federation or something like that. It's actually all driven from HTML. Basically the contract is, I'm going to include this experience. It's a lot like an iframe, sort of. You say, give me this partial HTML and I'll inject it into the page, either as I'm server-rendering or in the client, to make sure that the asset execution order makes sense and all that stuff. But you have full access to the document. So these embedded applications also impact the performance and need to be small.
00:51:08 - Dylan Piercey
And so being able to deliver one of these embedded experiences with 20 kilobytes of JavaScript is pretty important if you're trying not to impact some of the biggest pages at eBay. So from the micro front-end perspective, from this multi-page app perspective, and really from the perspective of just sending as little JavaScript as possible, and that includes the amount of serialized JavaScript, that's where Marko is really going to shine, at least in terms of performance. My view is, I wish everyone could experience the Marko tags API and the refactoring wins and the developer experience of that. I think that's huge and important as well. But certainly we're trying to meet this performance goal and then hope that once you take the step to say, I'm, you know, I need this kind of performance, you're delighted by the developer experience as well. So this is kind of a two-pronged thing. But the initial reaction people typically have to the Marko syntax is, this is not JSX, and/or this is not quite HTML. And so that learning curve, at least initially, doesn't, I think, draw people in. Although I do... I've yet to hear of someone who's used it seriously and was like, nah, this, you know, I don't like that this makes refactoring easier.
00:52:32 - Dylan Piercey
So I don't know if Michael or anyone else on the Marko team had something to add to that. Curious. I'm curious what frameworks everyone here is using, because one of the
00:52:54 - Anthony Campolo
things... only Angular devs here.
00:52:57 - Dylan Piercey
Only Angular devs. Okay, well, from an Angular dev perspective, I don't know how much you're caring about the performance of things. You also have your own, probably more...
00:53:09 - Anthony Campolo
So React devs is our audience.
00:53:12 - Dylan Piercey
I see. Okay.
00:53:13 - Anthony Campolo
Actually, we got a lot of Solid people here, but I know we actually do have a handful of Angular devs here, right? Yeah, I first came to Marko having kind of played around a little bit with all the frameworks, and I found it to be very unique and different. But I also agree that it really didn't have a super difficult learning curve. Like, I felt like I picked it up pretty quickly, and all the syntax again intuitively made a lot of sense, and the docs were pretty thorough. So yeah, I found that it's a very heady framework when you talk about how it works under the hood, but actually using it is not that overwhelming.
00:53:54 - Dylan Piercey
Right. And that's kind of our goal, like I said, with the language design and all that stuff, is to make it so that the hard parts can be abstracted from you. And also, just by its nature, the design of it is let's take HTML and JavaScript and make a declarative language that allows you to represent components, that brings them together, right? So it's like, obviously a lot of our shorthands are inspired by JavaScript, and a lot of the declarative stuff is inspired by HTML. So, like, if you're familiar with both of them, there's just a few things that you have to add. Like, oh, I can use this JavaScript-like syntax as an attribute, or JavaScript variables can come after this character after the tag. And so, you know, basically there's probably six or so different syntaxes that are unique to Marko that you need to learn. But then beyond that, it's just you have JavaScript embedded in some places and you have HTML embedded in some places. So the learning curve isn't actually too crazy from that front.
00:55:05 - Anthony Campolo
Cool. I'd actually kind of be curious to kind of take a sidestep and ask, like, we've got four people from the team up here. How is the team kind of organized? Like, what are duties and responsibilities? Are some people focused more on outreach and more on engineering, or does everyone do a little bit of everything? Like, how does that work?
00:55:26 - Dylan Piercey
I can probably speak to that. Everyone here is focused on the engineering aspect of it, but as far as who's doing what kind of engineering, Michael and I have obviously been at eBay the longest and are working on the big things. Michael's primarily working on Marko 6, and I've been working on a lot of the tooling stuff like TypeScript support. And we all are obviously chiming in and working with each other on the various different things. And so pretty soon here, since I've just wrapped up TypeScript support, we're all going to be trying to get Marko 6 across the finish line as quickly as we can, essentially. But another thing is, besides Marko, we're a part of the Web Foundations team at eBay, which is basically responsible for a whole bunch of internal guidance and infrastructure stuff around the web front end and guidance and all that sort of thing. So basically we're trying to figure out what is the best developer experience at eBay that we can achieve. Obviously Marko is a big part of that, but there are other things that we look into too, which is why you'll see different types of tooling come out in the Marko organization as well.
00:56:45 - Dylan Piercey
Yeah, so we definitely don't have anyone full-time really working on developer evangelism or anything sort of like that. We just take it up ourselves. It's something that we want to look into eventually. We don't even have a designer. A lot of that stuff has been by Michael, and so it is something that we're hoping to get more support on. So yeah, we hope that we're going to be able to do more outreach and all that soon. But the reality is, right now we're just so focused on trying to get Marko 6 out, and then once it's out and we're happy with it, you know, we're going to be sort of making the rounds and trying to make Marko a little less obscure. But at the same time, in some ways it's fine if it's obscure because, you know, we at least have one giant customer, and that is eBay, and we're trying to meet their needs as well. But this technology is so cool that we just want everyone to be able to at least play with it as well. Is there anything you'd add, Michael?
00:57:50 - Michael Rawlings
I think that's mostly it. Yeah.
00:57:55 - Speaker 1
I had a question about routing. When you have the Marko system, which is so compiler-driven, similar to Svelte, how does that affect routing compared to, let's say, like a Remix, like a file-system routing? Kind of like you have React Router, kind of, and then Remix is sort of like React Router with some server-side stuff. How would the routing system compare? I don't really know a lot about it. I'm really interested to know more about how routing works and stuff.
00:58:32 - Dylan Piercey
Yeah, that's actually a really good question. And it's one of the things that I think people first come into Marko and they're like, you know, at least up until recently there isn't an official router. Like, how do you guys not have an official router? And that's extremely confusing to people. But the reason for it is that typically Marko applications are designed to be multi-page apps that are rendered on the server. So you bring in, you know, Express, you bring in Fastify, whatever server-side rendering technology you want to use, and Marko is the one that ensures all the assets are hooked up properly. So the developer experience typically is you just import a Marko template into whatever type of backend project, like a Node server, you have, and you just render it. And Marko figures out what assets need to get sent to the browser, figures out how to serialize the components, hooks it all up. You don't have to think about any of that side of things. And so that meant, you know, normally you would just use Express's routing system or Fastify's routing system or something like that.
00:59:32 - Dylan Piercey
With the exception being the new tool we put out, and we did have a different tool before that as well, a few iterations of it. But we do have a tool now that's sort of similar to Remix's file-system-based routing, except that it does have some unique things as well. Ryan Turnquist was actually the one who is doing most of the work on that front. He could talk a little bit about it and maybe speak more to that.
01:00:00 - Ryan Turnquist
Yeah, so we were, you know, trying to make something that we can use both in eBay and for the greater open source world. And so part of that effort was this Marko Run, which is basically our meta framework, if you want to call it that. And so we're trying to reach parity, I guess, with a lot of other tools, like Remix, SolidStart, Next, that kind of stuff. So it seemed like file-system-based routing was something that people either love or hate, but it seems like it's winning out. So part of the Marko Run thing, another part of it, was kind of moving to Vite as our bundling system. And so, yeah, we basically kind of came up with our schema for how we represent our file-system routes. And through this Vite plugin, which is the majority of the Marko Run project, we're providing a routing solution for you. And it's kind of interesting because since we're a multi-page-application-first framework, and we have a compiler and all this, and we're performance-oriented, what we're doing for routing is looking at your pages and generating a compiled trie, basically.
01:01:51 - Ryan Turnquist
So all the routing is compiled into a bunch of if statements that render the correct page for you. So that's kind of an interesting thing I haven't really seen elsewhere. And I think it's going to lead to pretty good performance for Marko Run applications.
01:02:11 - Luke LaValva
That's cool.
01:02:11 - Speaker 1
I'll try to, not to take this too far off base here, off tangent, but similar to... as opposed to, you compared it to Express, specifically, for a server-based system for routing, where you hit a route and it gives you the data and you go there with the link. We were comparing runtimes the other day, me and... I was talking to Kelsey, and we were talking about Wasm, how it replaced Docker, the runtime, and it's very similar to what you're saying. It's already compiled. It's just a binary file. All the possibilities are already there. It's not like you can come up with a runtime possibility, like, oh, we have a new... look at this new runtime possibility. Nothing like that. It's not calling [unclear]. It's already compiled. You hit one of the possibilities and it's going to spit back some kind of something returned to you. So it sounds very similar. Okay, so you compile all the possibilities, precompile all the possibilities, and you get one of the options based on... based on...
01:03:17 - Dylan Piercey
Yeah, technically there is also a sister project to Marko that was developed alongside Marko, which is called Lasso. It's actually a runtime-based JavaScript bundler, so it bundles things on the fly. And that was built because, you know, when Marko came out, webpack had barely started. So we're looking at Browserify and all that stuff, and basically it didn't cut it. So a bundler had to be developed alongside this as well. But ignoring the bundler aspect of it, which is largely... at least the Marko parts of figuring out what modules to send to the browser is all in the Marko compiler. The experience of authoring a Marko app is very similar to the experience of just using Express with one of the view engines they have, like EJS or Pug or something like that, right, where you just import a view template and render it and it gives you an HTML string back. The big difference is that you can actually add interactivity in a declarative way to those templates, and Marko just figures out what assets need to go to the browser to make that happen.
01:04:18 - Speaker 1
That's cool. You lost me a little bit, but I can do some more research, maybe hit you up offline, or not offline per se, but off of this line. I was curious about how does the progressive... not to put you on the spot here, if you don't want to answer the question, it's fine, or if it's not answerable, but how does the... I'm sorry, I did too much preamble. I lost my...
01:04:42 - Dylan Piercey
No problem.
01:04:45 - Speaker 1
How does progressive enhancement fit into the picture?
01:04:47 - Dylan Piercey
Yeah, progressive enhancement. I mean, it's actually a lot easier to do progressive enhancement when your starting point is HTML. We're sending HTML over the wire. You're authoring an HTML, you're not trying to build these, you know, HTML replacement mechanisms and all that stuff. So generally we lean on HTML and recommend using the primitives and progressively enhancing stuff where possible. And plus since Marko, you know, you opt in to where the JavaScript is used. Since we opt. Oh, we got Ryan. Hey, Ryan.
01:05:18 - Anthony Campolo
It says speaker.
01:05:19 - Dylan Piercey
Can you speak?
01:05:21 - Dan
Sorry, I didn't mean to interrupt the technical answer. I've been trying to connect for like 20 minutes. Twitter didn't let me. I restarted, restarted. I just reinstalled Twitter from scratch. So here I am. Sorry, continue, Dylan.
01:05:35 - Dylan Piercey
Yeah, I was just going to say, essentially, since the model in your mind is adding JavaScript to an existing experience, it kind of lends itself well to progressive enhancement from zero JavaScript and above. And also we are thinking of accessibility patterns as we go, and how can you represent things in an accessible way? Like, one of the things that I think is kind of funny is React didn't have a stable way to get an ID that was server-rendered for, like, ever, right? Like, that was something that always had to be built into the meta framework. But Marko's always had a way to do that because getting a stable ID to be able to be used with, you know, ARIA controls and stuff like that was something that we hit right away. So it's like, you know, we are thinking about things from an accessibility standpoint as well, like from the language. But also one of the members of our team is a part of the accessibility initiative at eBay as well. So it's definitely something we have on our minds. And accessibility and progressive enhancement often go together. Not always, but yeah.
01:06:40 - Dylan Piercey
So it's definitely something I'll also say,
01:06:42 - Michael Rawlings
I mean, there's only so much that a framework can do for you on the progressive enhancement piece, though. I think Remix has done a really good job at the meta framework level. And some of those patterns we're kind of taking and pulling into Marko Run to some extent, and we're going to be doing more on that front. But I just wanted to call out that Dylan, before he joined eBay, was, like, a progressive-enhancement fanatic. So this is stuff that we are thinking about. But I don't know, Dylan, if you want to, I think it'd be cool if you just shared a little bit about what you were doing.
01:07:28 - Dylan Piercey
Sure, yeah. So, I mean, like I said sort of at the beginning of this, I was at a place where I was just hammering out tons and tons of websites and thinking about, you know, what the good parts of the web are. And that led me down progressive enhancement and streaming and, like, a whole bunch of different things. But one of the big pushes for me at that time was I need to support old browsers, I need to support IE8, and I want to write modern JavaScript. Like, that's why I have Node, right? And so there's always this tension of how could I progressively enhance the experience? And so that kind of pushed me down the model and all that stuff. But what I ended up doing was thinking, okay, the simplest way to make it so that an experience just works is to have it so that whatever HTML is rendered from the server, because I already knew I needed server-side rendering, can just work. Like, the things that you send to the browser should ultimately be a series of links and forms.
01:08:28 - Dylan Piercey
Like, what experience can you not represent with links and forms? Yes, there are some, but a lot of those even can be progressively enhanced to fall back onto links and forms. And so that was the simplest way I found to basically do progressive enhancement. And so I ended up building a router that is very similar to the current version of Koa. If you've never heard of Koa, it's kind of like Express, except a little bit more modern and promise-based and all that stuff. So I built this framework that was like Koa, except you could run it in the browser and it used the exact same APIs, and it was only like 30 KB, which is actually quite a lot. But there's a lot of polyfills you had to send for things like Promises and all that sort of stuff. But anyway, so you had this essentially mini Node server that you could send to the browser, and it would intercept link clicks and form submissions. And so what you could do is essentially a server-rendering application. And then once the browser picked up, it would intercept all of these link clicks and form submissions and pipe them through the client-side router, which is essentially the same model that Remix has today.
01:09:39 - Dylan Piercey
And actually all the similar things you could think of, like loaders and actions and all these sorts of things that you see in Remix, also exist in that framework that was built at the exact same time, or just a little bit before React Router was made. So that's kind of my foray into progressive enhancement. And then that project is ultimately what led me to Marko when I was building integrations for different frameworks.
01:10:05 - Speaker 1
I don't want to talk.
01:10:07 - Dylan Piercey
Sorry.
01:10:07 - Anthony Campolo
Yeah, I just pinned your FSJam interview where we dove into a lot of this stuff. It was actually the very first question I asked you. It was about progressive enhancement and how it related to partial hydration and all that kind of stuff. So I would point people to that interview. It's actually one of my favorite interviews I've ever done on that show, so I'm really, really proud of that one. Now we've got Ryan up here. Actually, I'd be curious for you to speak just a little bit about your history working on Marko and why you have referred to it as the most underrated JavaScript framework.
01:10:41 - Dan
Sure, yeah. I mean, it's kind of crazy to me because I like to look at lots of solutions. The whole way I approached building Solid was looking at lots of solutions in the space. So Marko was not on my radar at all. Hooks had recently come out, and I was very hyped on the fact that people were switching back to primitives. So I was just going along that thread, writing articles about signals and reactivity, when Michael and Dylan actually were like, hey, you know, we're working on something that we think signals could help with. That's how I actually got pulled in. We were thinking that Marko 6 would be based on something like signals, and it kind of is, but it's interesting. Get to that in a second. But what I did find, though, was, you know, they've been kind of suggesting, like, there are different things that Marko needed to be aware of early, like those IDs and stable IDs and a few other things. Marko has had, like, almost all the hype features of the last two years. Marko's had some version of them for about eight years, just because now everyone is, like, rediscovering the server.
01:11:54 - Dan
You know, technology changes over time and different things become available. Marko, from the start, was just, like, there. It was asking the kinds of questions we're asking right now. You know, Patrick Steele-Idem was asking those back in 2012 or 2013 or whatever, when he started working on this. So, like, I was honestly flabbergasted. Even though I've been working the web for, you know, God, like 20-some-odd years now, and I was aware of some older techniques, I didn't realize that JavaScript frameworks operated like this. It was like finding this treasure trove. It's so funny because I had some conversations with other people afterwards, even like Rich Harris from Svelte and stuff, and it was like, hey, you know, he asked me, why aren't people talking about Marko? And it was an interesting question to kind of think about. But beyond that, it was just so obvious what the value here is, both to use and for others to learn from. So, like, yeah, I was very excited, especially at the point where I was at. This was an opportunity to come actually work on a JavaScript framework full-time, work on open source full-time.
01:13:07 - Dan
And I basically jumped at the opportunity, picking up my life, my family, everything, moving down to San Jose right at the beginning of COVID. So yeah, yeah, Marko has a lot in it to be excited about, and the work that they've done since just builds upon that foundation.
01:13:29 - Michael Rawlings
Right?
01:13:29 - Dan
Like, because here's the thing. I entered the team, you know, in the first couple months, and sorry if I'm just kind of catching up here for the whole rest of the podcast, kind of giving my perspective on it. You know, Michael and Dylan were the main guys present on that. There's also the other teams around the components and stuff. And these guys had already been thinking about this specific problem, evidently, for several years. Like, Marko 6 might not have really gone into full swing until about 2020 in terms of developing for it or putting the plans together, but you could tell the roots of this go back to, like, the 2017 time period. And basically the challenge of having two developers supporting all of eBay is a lot of work, especially migrating the hundreds and hundreds of apps over to, I guess, what was it, Marko 4 at the time.
01:14:21 - Dylan Piercey
Yeah.
01:14:23 - Dan
So, yeah, there's been so much thinking and design consideration that's gone into almost every piece here that, yeah, I mean, this is why every time it comes up I'm just kind of still in awe. When I talk to people and they're like, you know, you make jokes, like, the thing is, you never say what the best JavaScript framework is. Everyone, you know, has their opinions. I always give Marko a free pass on that just because of how far, in this particular area, the thinking has gone beyond where most other frameworks are just dipping into. To be fair, this has been a known thing for a while. The work that React's doing on RSCs started really back in the 2016-17 period. The work for Qwik started in the 2019 time period. So there's a long tail to get to where we are today. But I want to say this is the think tank I go to when I really want to vet an idea of where things should be heading.
01:15:41 - Dylan Piercey
Yeah.
01:15:41 - Anthony Campolo
This is why I think it's so important for web developers to study history and to understand the historical context of these different frameworks. Because, you know, 2020 is when I really got serious about development, so all of that stuff predates me. But I found that just by digging into blog posts, like, there are all these blog posts from eBay going back to even the creation of Marko, and they reference blog posts from like 2007 or 2006 that they were taking influence from. So you can learn so much just by digging into the history of these projects and, like, take a day off of whatever the Twitter hype of the day is. Instead of arguing about Tailwind for six hours, maybe learn something useful, you know? So I really think that more people should study this framework. I think they would learn a lot doing so. We have probably about another 15 minutes left, and we can go on if we need to, but I think we should probably start closing it out fairly soon. Do people have other things they want to talk about that are relevant to Marko? Or do other people in the audience have questions? Feel free.
01:16:52 - Anthony Campolo
Dylan, Michael, Ryan, Luke, just hop in with anything on your minds.
01:16:57 - Dylan Piercey
Yeah, I mean, I definitely will echo looking at what has been done in the past, because there are so many things that, if you just take a different look at them today or think about what the implications of them were in today's context, you can do something that's a huge improvement to the current status quo. And Marko is a lot of that, right? Like you mentioned pointing to articles from 2006 where people were looking into streaming and all that stuff. And actually, you know, even earlier than that, people were using streaming. So sometimes these old technologies, with just a little bit of polish and a little bit of a modern tinge on them, can be hugely powerful.
01:17:38 - Michael Rawlings
I feel like for the last, like, several decades, there's been like, an article that gets, like, a lot of attention that's posted like every few years. Like every five, six, seven years. It's like the lost art of streaming. And it's like,
01:17:58 - Dylan Piercey
Yeah, every time we see stuff like that.
01:18:00 - Michael Rawlings
Funny how that keeps coming around. It might stick this time. It seems like it might stick this.
01:18:07 - Dylan Piercey
Yeah, I mean, I'll let Ryan go.
01:18:10 - Dan
Yeah, I was going to say, the 2005 article that I think AJC was referring to was actually called "The Lost Art of Progressive Rendering," or streaming. Like, that was actually the name of the 2005 article.
01:18:26 - Anthony Campolo
I've got all these right here. Yeah, I'm just going to pin these up.
01:18:36 - Dylan Piercey
The other thing, and like I said, I feel like it's underappreciated. I hope that eventually, especially once we get Marko 6 out, people will try just the Marko language. Like, ignore the performance aspects of it. Think about the DX, and does it make it easier to author components? And I think once you get into it, the answer will be yes. I would still like to, and I showed this off on Ryan's stream at one point, have a way for you to use Marko's language that compiles to JSX so that you can take advantage of some of the language features. I think that would be cool to be able to use in other frameworks even. Because, I mean, JSX, and this is a whole other tangent, but there is a lot to be desired in this language that, in my view, essentially just bootstrapped a bad version of XML onto JavaScript of the time, which didn't even yet have template literals and stuff. So I have a low view of JSX, and I think if people were to try the Marko language, they would come to like a lot of its features.
01:19:38 - Dylan Piercey
I'd actually be curious about Luke or Ryan's take on that particular side of things, having most recently come from, you know, React.
01:19:49 - Luke LaValva
Yeah. I think what separates the Marko language, or I think we're calling it HTML JS internally, from JSX most, is that in JSX the line between JavaScript and HTML is pretty clear. You can tell where you're writing JavaScript and where you're writing HTML. And for Marko, I wouldn't say it's a blurrier line, but it's more like you're kind of writing both at the same time, and you always know which one you're writing in, but you don't have to worry about switching from HTML mode to JavaScript mode. It kind of just happens naturally where, you know, you want to switch already. And that makes my authoring experience a lot easier because you're only keeping track of one language instead of two.
01:20:40 - Dylan Piercey
Yeah. One other thing that I point out is, you know, we're also trying to look at everything from the language perspective in terms of, like, how are people actually going to use this? How are people actually writing stuff? What is the pattern? What is the goal they're actually trying to achieve? And so that's where we get, like, the optimization side of things, but also these easier refactors. One thing that I think is probably my favorite feature of Marko 6 is this concept we have of controllable components, which we don't have time to go into right now. But all that is to say, like, there is a lot there just in the language. Don't feel like performance is the only thing we're competing on. There are definitely two paths that we're trying to fight on here, which is obviously the performance, because that's important for eBay's needs. But Marko, from its inception, the goal was how can we have a good DX and a modern development experience? And so that's definitely one of our pillars as well.
01:21:43 - Dan
The language piece is actually very interesting because part of it, I feel, is that people don't want to learn a new syntax or something, or they don't want to, like, get away from the standards. The problem is that the standards as we know them today aren't holding up, and won't hold up. There's some fear and concern around compilation and about different syntaxes and whatnot. But the problem is that JavaScript has failed us at being a good language for representing UIs. It has. We wouldn't have hooks and hook rules, we wouldn't have the don't-lose-reactivity conditions, all this, if we weren't basically trying to invent this pseudo-language on top of JavaScript. And some do better than others. But every place that we do it, we hit new challenges and problems. So because, like, Svelte's kind of brought into our common thinking that the language should look like JavaScript. But Svelte also doesn't have composition patterns as part of the compilation. If you want to use, what are they called, their directives or actions, or I can't remember what they called the use-colon thing...
01:23:10 - Dan
Well, you're writing that in plain JavaScript. You're not using Svelte. If you want to write a composable hook, you're using stores, again, JavaScript, not in Svelte-land. The thing is, the problem here is that from an analysis standpoint, JavaScript is hard. React is going to come up with this Forget compiler, but it's also going to have interesting behaviors and rules that don't actually reflect JavaScript. You might write something that looks like JavaScript, but it isn't actually JavaScript. And we're trying so hard to tie our hands, to kind of keep in this familiarity zone, that there are a whole bunch of issues and trade-offs that come down to that. Being that the language itself, the syntax, the semantics, are not the best for designing UIs. So I think what Marko is doing is interesting in that it's saying, okay, well, screw that, I'm going to make a language specially for this purpose. So where I can tell that something is a stateful reactive variable, for example, and that I can mark that and that the system knows this and that the language can basically do its job without having a mind-reader of an AI trying to figure out how to compile your...
01:24:30 - Dan
Your stuff like this. This is, this is the problem we face today with frameworks. It is a language problem. So a language solution seems like it might be the way.
01:24:43 - Dylan Piercey
Yeah, I would just add, like, a lot of other solutions will basically abuse, and I'm kind of picking on Svelte a little bit, different JavaScript language features to mean something else. But if you're going to say that a feature means something else, well, what does that mean for other tooling that's going to be working with that particular feature? Does that abstraction leak in terms of autocompletions, in terms of what variables it says are available, or what narrowing TypeScript has done, all these things? The abstraction can leak depending on how you're abusing or using JavaScript syntax. Where on the other side, like on the Solid side, if you're using regular JavaScript syntax but the semantics of how your components run is more restrictive than what the JavaScript syntax can represent, then something like TypeScript on top of it won't necessarily be able to provide you the ideal editing experience unless, you know, TypeScript goes and adds app-specific support for specific frameworks, which I guess they're all for doing.
01:25:53 - Dan
But if your framework's name starts with an R and ends with a T. Yeah, yeah.
01:25:59 - Dylan Piercey
If you're that framework, then you don't have to worry. But otherwise, if your framework is doing something where, you know, if the IntelliSense could know just this one little fact about your framework, all of a sudden the types get better and all that sort of stuff, that's really hard to do if the thing that you're augmenting or working with is JavaScript as an API for describing your UIs. But since we're building it a level on top of that, we get to decide what the meaning of a variable that's provided to you from Marko is, and what the meaning of the body content is, how things get evaluated. We have control over that, which is a lot of work, to be clear.
01:26:34 - Michael Rawlings
It's a lot of work. And I do want to shout out that Dylan has done a great job over the past several months getting our tooling into a good place, because there's a lot that has to happen in designing your own language. And I totally understand why most other frameworks have not gone down this route, because it is a lot of work. But I think Dylan's done a really good job. And the rest of the team, I mean, it has been a collaboration, but Dylan's definitely been leading it and getting the tooling into a really good place where it feels like you're not giving up anything by using this, what is essentially a custom DSL.
01:27:24 - Dylan Piercey
Yeah, and I'll just add, even though it is a lot of work, sometimes some DX wins, some new features, some APIs, like, they do require a lot of work, but that doesn't mean that they're not useful. Once you have them, it's like, wow, how did I do anything without this? Like, we lived in a world without TypeScript forever. And I'm not saying... TypeScript, I still do... but, like, yeah, you do live in a world with VS Code giving you at least JavaScript completions. So, like, back when I first started writing JavaScript, there was none of that, right? So it was very much, like, remember the application in my mind. Anyway, all that is to say is the tooling that went into even just those autocompletions and stuff like that is immense. But it's like now we can't live without it, right? And so even though we're putting in a lot of work into this language, it might be like, well, why not just use JSX? So it's like, well, you know, there are some things that JSX can't represent, and we can make better tooling if we just throw out the underlying issue, which is this sort of limited DSL that's built into JavaScript.
01:28:33 - Dylan Piercey
And so, you know, yeah, it's a lot of work, but I think it's, it's also fairly fruitful anyways, sort of
01:28:42 - Dan
Making a long-term bet here, that's the way that I look at this. Because the funny thing is, if you believe this is an inevitable conclusion, all the steps that we're doing right now are sort of intermediate steps along that path, so to speak. So the final result might end up being different if people go different paths to it. But it's interesting to me, at least, that we could talk about Marko 6 taking a while. Taking a while has so little impact on how current, how modern, how powerful it's going to feel when it comes out. Because at the point that this comes out, from at least a broad technology standpoint, other stuff will not have caught up. So even if it takes longer, which don't, but I'm just saying if it did, that part isn't a concern because it's kind of been the sort of long-shot, leap-stepping-a-couple-steps-along-the-way bet. Because it depends: if you think that is the inevitable future, then this is probably a really smart bet to make.
01:29:58 - Dylan Piercey
Yeah. And at least for the types of things that we're building at eBay, and the experiences we see, and the way that the application as a whole is architected, it seems like the safest bet for us is to account for the fact that we're going to want to send ridiculous amounts of JavaScript to the browser and make tooling that makes it hard to do that, or impossible to do that, and maintains the DX. So at least that's our bet on the performance side. And, you know, obviously there's a whole bunch of different facets of it, like the bundling, the rendering, and serialization and all that stuff. But yeah, so that's definitely sort of where we see the future going, and a lot of tooling is looking into that right now. I was super happy when Astro was released and looked at partial hydration. Pretty much no other framework picked that up or took it seriously. You know, obviously React Server Components are like semi...
01:30:46 - Anthony Campolo
Semi, that's another one.
01:30:49 - Dylan Piercey
Yeah, I mean, there are definitely some, but it was few and far between for what is a very conceptually simple optimization that I think makes sense for the vast majority of sites that people are building, right? You know, like, if you're doing server rendering at all and you're fine with your page having a multi-page app, why are you sending your entire application to the browser? You've already said the server can do some amount of the work and the browser just needs to do these little updates here and there sort of thing. So it's such a low-hanging-fruit optimization that we were only seeing somewhat recently. And then obviously we're taking that core idea to the extreme and saying, well, let's not do individual top-level islands or whatever, let's actually figure out what the real JavaScript is that needs to be sent to the browser, and only that JavaScript, so we can get closer to the actual best performance you can have on the web, which is an inline script that does exactly what you want it to do. That's what philosophically we're trying to go towards. Not to say that Marko 6 gets there, but it's definitely way closer to that than anything else that exists right now.
01:32:10 - Scott Steinlage
Yep.
01:32:11 - Anthony Campolo
Chasing that dream. Well, I hope to see Marko 6 sometime this decade. I'm still holding out hope.
01:32:17 - Dylan Piercey
Yeah, this, this decade for sure. Awesome.
01:32:22 - Anthony Campolo
Well, thank you guys so much for being here. It was a super great conversation. I really encourage everyone in the audience to follow these guys. They are super cool devs and I have pinned a whole bunch of tweets up top. One for Marko Run is up there right now. That's kind of the newest, hottest thing you got that people can try out. And then where should people go if they want to get involved with the community?
01:32:48 - Dylan Piercey
Definitely check out our Discord, or go to the markojs.com website, which has a link to our Discord. That's where all of us hang out, in the very discord.gg/marko. Oh, yeah, there you go. Michael's got it.
01:33:04 - Anthony Campolo
Awesome. Well, any other parting words for our guests or our audience?
01:33:12 - Dylan Piercey
Yeah, I mean, I think the big thing for me is look at the web as, like, what's unique about the web compared to every other platform? And to know that, you have to look at its history. You have to think about things like progressive enhancement. Try not to get a surface-level, one-frame perspective on everything. I think if you expand your horizons, you'll become a better dev and deliver more delightful user experiences.
01:33:41 - Anthony Campolo
Absolutely. All right, well, thank you everyone for joining us. And we'll be doing this same time next week, Wednesday, 12pm Pacific. And yeah, as we get closer to React Miami, we're going to be talking with some people who are speaking there. We've got one lined up with Henri in a couple weeks, so that'll be fun. But yeah, love to see you all next week, and that'll close it out for us.
01:34:08 - Dylan Piercey
Thanks for having us on.
01:34:10 - Anthony Campolo
Yeah, for sure. Thanks for being here. Bye, everyone.