Dylan: right now, basically I think Marko is at a point where it's the best multi-page app framework that you could use in terms of performance and hopefully DX and that sort of thing. And you know, our next goal is to make it the best SPA framework that you could use in terms of the same things.
[00:00:19] Intro
Andrew: Hello, welcome to the Dev tools FM podcast. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.
Justin: Hello everyone. Uh, our guest today is Dylan Pearcy. Uh, so Dylan is on the platform engineering team at eBay and has been working on Marko Js. Uh, we're really excited to talk about your work on Marko. Uh, but before we dig into that, uh, would you like to tell our audience a little bit more about yourself?
Dylan: Yeah. Um, so yeah, my name's Dylan and I've been, uh, at eBay now for almost eight years. I've basically been working in like front end, open source tooling, whatever stuff. For quite a while, um, very into like progressive enhancement, low JavaScript, that sort of thing. Um, and that sort of brought me into the, the Marko world, which is something that, you know, a framework that a lot of people haven't heard about at all.
Um, although, you know, recently people are talking about it as far as like, oh, it's innovated in these certain ways and all that stuff, and it's actually super interesting and we're continuing to innovate with it. But yeah, so I've been at eBay mostly working on that and other like front end tooling that we have, um, at eBay.
And, uh, yeah, so I'm happy to go into like a history of Marko or like whatever you guys wanna, you know, chat about. Um, 'cause that's mostly where I'm at working on Marko.
Justin: Cool. Yeah.
[00:01:34] Platform Engineering at eBay
Justin: Before we dive into Marko, why don't we talk a little bit about like, what it's like to work in platform engineering at eBay. Uh, eBay's really fascinating company, been around for a long time. Uh, and I'm sure y'all have some really, really interesting like, platform challenges. So, so what's your experience been like on the platform engineering team at eBay?
Dylan: I mean, it's been really, um, rewarding to work on because you get to build something and then see it be, you know, roll out to so many teams and have a lot of, uh, you know, people like direct feedback from teams who either like the product or are trying to make it work for certain use cases. And so, you know, like I said, I was working on like some open source stuff before, but being able to build something that's open source and get feedback on it from people who are deploying it at scale, like right away is, um, super great.
As far as, you know, eBay goes, um, it is a very old company, um, so there's lots of tech debt that, you know, we're continually trying to address, but there's also like lots of expectations around. Performance, um, and what it actually means to, you know, for the product to be done and accessible and like all those sorts of things.
Um, and so like, you know, that is a big thing that we're constantly trying to keep in mind. Like, this experience was built in 1995 and was able to be, you know, streamed over DSL to whatever, um, computer, and it worked moderately fast. Like why is it slow now? Right. So that, it's very interesting to have that kind of perspective.
Justin: So in your work, um, are you like primarily just like focused on Marko? Is there like other sort of like tools that the platform engineering team or like you're part of the team ends up like touching? I.
Dylan: Yeah, so there's, there's a whole bunch, um, in the, in the ecosystem, like the node js ecosystem at eBay. Like, we've gotta think about like internationalization. We've gotta think about, um, like how we're I. Like setting up our servers, we've gotta think about how things are deployed. We've gotta think about the cis and like all this sort of thing.
Like everything, it's fairly holistic in terms of the front end, um, experience. And then as far as Marko goes, there's like integrations into all these different things or, oh, we want to deploy to the edge now. So it's like, well what does it look like to deploy Marko to the edge and all that stuff. Um, so there's a lot of things like that.
Plus there's just like general like guiding teams on, you know, what is the best way to architect this because Marko. You know, is you kind of have to have a different mentality is, you know, it's not a single page app. You're thinking about things more in terms of, well, what JavaScript am I actually sending to the page?
Or like, when can I flush this? And all that stuff. There's just different things that you have to think about. And so helping teams through that sort of thing. Um, yeah, but a lot of like random tooling, even like testing tooling, like. Visual regression testing or whatever. There's things like, we're not happy with a lot of solutions that are out there for that.
So we like, you know, build tools around that sort of thing and lots of different stuff, which is, you know, yeah. Fun.
Justin: Nice. Nice. Before we like one last question before we move her into Marko. So, uh. You've been at e eBay for a while, and like you mentioned, eBay's, uh, you know, for a tech company, pretty old. Um, and the web has evolved a lot over that time. So I, I'm really curious, uh, as you've watched the web evolve and, you know, things like, in some ways become simpler.
Like, you know, CSS is a lot more capable now than it was like five years ago, 10 years ago, whatever. Um, what are the like. Biggest takeaways in the evolution of the web that make your work easier or harder today? Is it like, is it substantially different? Like I, I'm sure eBay has, uh, a lot stricter, uh, browser support requirements than a lot of organizations would have.
So I, I'm just curious like where things are and like your big learnings are to this point, and like how the evolution of the web has affected your work.
Dylan: Yeah, so I mean, at least for me, the way I think about a lot of things is how we can like progressively enhance things. So I'm trying to think about what the lowest common denominator is, given what our like targets are right now. Um. And like, as long as you have that mentality, it kind of doesn't really matter what comes out because you're trying to think of how to work within those limitations.
Um, and you can still, you know, deliver really good things and enhance on top of it. But, uh, as far as like the web goes. I think the, the trickiest thing is that, you know, a lot of people are building web apps now, like full fledged applications in the browser and they're like, well, I can do anything in this application.
I can, you know, have this long live session. I can do animations across pages, and like all these sort of things. And so some of these, um, trade-offs that you might make if you're trying to serve the lowest common denominator you might not want to make for those types of experiences, or at least it's very challenging to figure out how you're gonna make that work with those experiences and enhance it.
And so a lot of developers, especially now obviously, are like, well, these, these tools can do everything I want. Right? And it, they give a good DX as well. So it's like, why don't I just go with that? And part of the answer, like from our perspective is, well, okay, well what about the users that that doesn't work for?
And also, what about performance? Like, that's basically what it comes down to, um, for us now, in terms of the, uh, like. Server-side rendering and links and forms and all that stuff. Obviously browsers have continued to g get better at that sort of thing as well with like view transitions and paint holding and the BF cache and like all these sorts of things.
There are features that are still being added for this like, you know, non single page app model that I think are making things a lot nicer. Um, but yeah, so that the, the fact that developers are kind of expecting that they can do anything on the page like that it is a full app, um, is something that is.
Uh, you know, continuing to increase. Um, and so we're trying to meet developers where they're at as well and make it so you can build these things without the compromise, which is the hard part. And, and that's kind of our goal.
[00:07:23] Ad
Justin: Thanks to work os for sponsoring today's episode of Dev Toes fm. So picture this, you're on a Zoom call with a potential customer. The demo went great, they're interested and then comes the famous ask, do you support SAML or SSO some other enterprise feature? And you pause and you say, yeah, it's on our backlog.
We can prioritize that for you and then you just have to get to work. Um, but. If you don't have time to build that, that's where Work OS comes in. Work West gives you everything you need to make your app enterprise ready. So think S-S-O-S-E-I-M. Audit logs, fine-grain roles, even domain verification and credential storage.
Everything with modern well designed APIs and SDKs that you won't hate using. They're admin portal handles, onboarding flows. They have a, their vault. Feature to help Secure secrets and the docs are really good. Uh, they're actual modern developer docs. They're clear example driven written for humans. It's delightful.
Everything is modular, so you only need to use what you need and it scales with you as customers start asking for more functionality. So the next time you're ask someone ask you, do you support SAML or some other enterprise feature, you can just say yes and mean it. Uh, and if that sounds good to you, head over to work west.com, uh, to learn more.
Andrew: Yeah. So that's a good transition into talking about Marko. Uh, Marko doesn't aim to be that like, uh, spa model with, with all those bells and whistles. It was bred from a much different set of constraints. So can you detail like what constraints led to the inception of Marko?
[00:08:57] Marko's Early Days and Innovations
Dylan: Yeah, so I mean, obviously Marko was created at and used primarily by eBay. Um, and it came about in, uh, 2012, but you know, eBay, like I said, has been around forever, like since 1995. Obviously you had like auction web and all that stuff, and it was actually written in Pearl, and then Pearl was too slow as it started to scale, so they switched to c plus plus, but that was too main unmaintainable, so they switched to Java, which was a little bit faster.
But the. The thing is obviously during that time, JavaScript is becoming more and more prolific and you can do more and more on the client side. So JavaScript starts sneaking in and enhancing certain parts of the experiences, which is good. I mean, basically you end up in 2012 with this experience, which is Java rendered drinking Cat Nation like pretty fast.
Um, and then, you know, snippets of JavaScript that enhance various parts of the page. And another thing to keep in mind with eBay is that, you know, a lot of people are coming to eBay from a link that someone shared or from a search engine or whatever. So like. This whole amortized cost savings that you get from a single page app, you don't necessarily get with eBay.
Or people might, you know, go to eBay and open up like 10 tabs and it's like, okay, well if that's 10 spas you're opening, you, you know, you're not really saving that much, you're just using more memory and like all that sort of thing. So anyways, eBay was in this place where they have this Java app, um, sprinkling of JavaScript.
But the big problem is you've essentially got two apps and if you want to do some rendering on the, you know, JavaScript client side, you've gotta implement it in a totally different way then. If you're working on the server side, two different paradigms as well. So it's just like a maintenance nightmare to, to manage this.
And at the same time, in 2012, people are like coming out with React and Angular and like all these tools are, you know, popping off. So the question obviously was like, well, can we just like use these tools? Um, and the answer was kind of no, because we could not compromise on those performance metrics. But obviously we still wanted to have this like unified developer experience.
And so basically, initially React was considered, um, as one of the things, but the things that we needed, like basically right outta the gate is streaming. And if, you know, probably most people are familiar with streaming right now, but uh, streaming is something that's been in Markos since 2012. And, um, you know, ultimately all streaming is, is sending as much HTML as you have available without waiting for whatever services you have.
That are responding with the, you know, loaded data that you had to get that's specific to the page. Um, and the nice thing about streaming is obviously you can send out stuff to the browser and have the browser start downloading assets and images and showing content to the user without having to wait for your slowest service.
And at eBay there's a lot of services. Some of them are slower than others. So it's super important that we're able to deliver that. So essentially if we were to, you know, say adopt, react or Angular or whatever, um. The fact that there wasn't streaming would essentially mean that we're just like throwing two seconds or so.
You know, like the page load time is just gonna be two seconds longer, which is just like not acceptable. Um, so we'd have to like shim that back in or something like that. And also at the time, like Angular didn't even have a server side rendering story, right? Like at the time they, they're saying just pre-render it with a web browser, right?
Which is obviously terrible for performance. So that gets to like the horizontal scaling aspect of it. Like how can you. Actually render fast. Not just get the content to the user fast, but like actually render fast so you don't have to have so many servers. 'cause eBay also owns, you know, its own server farms and stuff.
So, um, the other thing was, okay, obviously spinning up a browser is super slow, but even in React you have to like spin up a vdo, but, or not spin up a Vdo, but you know, creative Uum and then serialize that T smell versus string concatenation. So we're comparing against the Java app, right? And so the Java app is just concatenating strings.
And it's basically like two orders of magnitude faster than React and render. It's html. So it's like, okay, how are we gonna compete with that? And the fact that we don't have streaming. And then the other thing is the snippets of JavaScript, right? Like we're comparing a full page being rendered in the browser versus snippets of, you know, hand coded JavaScript basically for the interactive pieces.
So essentially there's like no way to compete on the server rendering performance. The streaming performance or the, you know, snippets of JavaScripts. And so that's where Marko kind of was like, okay, how can we answer these while still having a unified dx? So even from 2012 and Markos created, had streaming, had islands architecture, although at the time we just call it progressive or sorry, uh, yeah, we had progressive rendering and um, partial hydration is what we call islands.
Anyway, so we had all these things sort of from the beginning and that's essentially been our mental model because we wanted to have the DX. Um, where you're writing in a single paradigm, but you can have client rendering and you can have server rendering. And so Marko was the first front end framework to support streaming.
Like there was dust, but like, you know, server side rendering technologies that could do streaming, but no real front end framework supported streaming. In 2012, Marko was the first Islands architecture framework and also Marko is the first framework that actually compiled differently for the server versus the browser.
So those are places where Marko. Kind of innovated even way back in 2012, and we've just been refining that, um, sort of ever since. But we've also been looking at like what the major foot guns of this approach. And you know, like I said, it's very easy for people to det, um, especially with islands. And so comparing like, basically that's like why Marko up to today?
And I think Marko even has, you know, all these things. Whereas most framers have like two of those things. Right. Um, but yeah, so Marko six is the thing that we're, we've been working on for six years. It's actually been a very long time. And there's like a joke, like what will come first? GTA six or Marko six.
But luckily GT six was delayed, so we're, we're good. But anyways, um, yeah, so Marko six is the main thing that we've been working on, and the goal of Marko six is to make it so that you're not having to think as much about. These islands or this architecture and that you can write things like, you know, most people are familiar with writing a single page app looking thing and have it actually deliver, you know, just the amount of JavaScript that's necessary and, you know, stream things out automatically and like that sort of thing.
So that's kind of where we're at. Did you have any questions about like, history of Marko before, like, or where do you guys wanna take it?
Justin: Y. Yeah. I kind of wanna dig into this a little bit before we move on because it's like, I think it's important to set the stage for people, especially the people who are newer in the industry. So we're talking about like the time that Marko came out, there was like, there was no web pack really. There was like the world of Bundlers.
Dylan: so there's actually a bundler, like beside Marko. There was also lasso, which was eBay's Bundler. So like, yeah, there was no web hack. I mean, yeah, I think Web hack was around, but not in the way that. People would think about it today anyway.
Yeah. Yeah.
Justin: Yeah. I mean, it, it's really, it's really wild to think about like how far ahead Marko was in a lot of like the core technologies. 'cause like when, when React. Sort of first hit the public space. Yeah, you're right. It's like all like, just render to string was the big thing. And I think view, uh, like view two or something, sort of beat them to the streaming rendering, like setup and it like took a while to get streaming rendering.
And then even still like just years of churn of like, okay, well, like how do we handle like styles in the head or whatever. You know, it was like a bunch of like challenges in that space. And meanwhile, like Marko had. Out of order streaming, which is this insane feature.
Dylan: you could say React head streaming since, I wanna say it was like 13 or something like that. Like they had the render to node stream, but it's like it's still a synchronous render. They're just chunking it up because it's so slow that you might as well flush some of the HL while you're going Anyways, so view is like kind of the same thing where it's still a synchronous render.
So Marko from the beginning has had the out of order flushing where basically asynchronous content does not block the synchronous content and things shuffle into place as the browser, uh, receives it. And so yeah, that's a big thing for, for Marko for sure. But yeah, there's actually been so many I. So much tooling that we've had to consider uniquely just because of the islands architecture or the streaming or whatever, like pretty much nothing supported that.
Like streaming. What, how do you stream in storybook? How do you consume? Like, do you know what I mean? Like no tools actually support these patterns, so it's really great for us. That, you know, different frameworks are picking up these technologies and strategies just because it means we're gonna have to do less work.
Like we don't have to maintain our own bundler anymore, which is really nice. Um, and, you know, but even things like, we have our own serializer, obviously we have our own compiler, and our compiler is maybe closer to a bundler than it is like, you know, a spelt compiler or whatever, where it's looking at an individual template.
So there's, you know, just a lot of things that we've had to consider. But at the end of the day, our goal is just to make it so that you can have. A nice DX while still delivering that performance. 'cause we still to this day, can't really compromise on that performance. Like, you're not gonna go to, you know, some executive eBay and be like, okay, is it all right if we just like, you know, cut the performance in half.
Um, just that we can move a little faster. And the answer has so far has been no.
[00:18:02] Marko's Unique Language and Syntax
Andrew: I'm sure a lot of those constraints also influenced the way the syntax came about too. 'cause if you can't rely on JavaScript for things, what's, what's your next tool in the box? Well, it's HTML, right?
Dylan: Yeah. And so, I mean, it also plays a little bit into that. Marko wants you to be thinking from the HTML first, like you're writing an HML template and that template is declarative. Um, and things just like. Go through that and Marko does the right thing. Like that's the goal. Whereas JSX sort of, you know, is just an abstraction around like function calls and JavaScript objects, and obviously you can compile it to different things like solid does and whatever, but at the end of the day, it's just you put a snippet of stuff inside JavaScript.
Now the problem with that is as soon as it's inside JavaScript, you have to understand all of the JavaScript in order to do any optimization or you're gonna be breaking people's assumptions. So like if you're using something like quick. Quick has a bunch of limitations around where you can introduce state or you've gotta use the dollar in certain places and all that stuff, and you're like breaking JavaScript expectations.
So Marko's approach has been to basically start from HML, so like. When you're right in the template, you're just writing H TM L. But we want to make a language that is as if JavaScript and HML were invented together, right? So you actually have JavaScript imports in Marko, and the attributes are actually JavaScript values, so you don't have to like curies around them or anything like that.
You can just, you know, set a JavaScript expression as the value. Um, and there's a whole bunch of things like that. But the other piece is that we don't touch. Your JavaScript, right? Like any JavaScript expression you have in the Marko template will just run as JavaScript runs. But that's why we introduce language that we can optimize however we like on, on the outside of that.
Um, and the thing that's kind of cool about that. As well from a DX perspective is it means that we can enable things that you couldn't do, at least in a syntactically good way, in JavaScript. So like we don't have hook rules, for example. Um, and control flow is composable. So like in a Marko, in Marko, there's like an if tag, you can create your own if tag, like everything is composable because our primitives are our language rather than, you know, some contract with how you write JavaScript with a dollar sign or you know, whatever.
Um, so that's been one of our goals. To make it so that, you know, the DX is good, you can write this like template that looks like HML, but has, you know, all the JavaScript power that you would want. Um, but then also like, given that we've created this language and restricted it in a way that, um, can be analyzed, that's what allows us to do, um, the, the future stuff that Marko
six is all about.
Andrew: Yeah, it's, I, I find it funny how like both Marko and JSX kind of took the same prompt and went like the polar opposite direction, where it's like we, we wanted to combine HTML and J JavaScript. Uh, Marko like just leaned into the H-T-M-L-J-S-X, obviously into JJ JavaScript.
Dylan: I think a lot of people might think like, oh, but JavaScript is more powerful, so you should just like lean into the JavaScript side of things and the like. I've seen a lot of people be like, well, is this kind of like view or Angular or whatever, where you have this kind of DSL in HTML that in some ways is kind of like hobbled and you don't really know what's, um, what you can do or what the limitations are and it's like just a totally different language.
But Marko isn't so much that Marko, instead of trying to like take h, TM L and like use H tml syntax to mean different things, Marko actually extends H TM L with new syntax. So it's like very clear, oh, this is a Marko feature. Like, oh, this is how a variable's introduced. Um, whereas if you look at something like view.
It's like an if statement is V dash if, like, it just looks like an attribute and you can't tell the difference between a JavaScript expression and a string as far as like syntactically looking at the template. Um, so I like to think of Marko, um, in terms of, I. View is to JS doc as Marko is to type script like view your kind of going in and sort of annotating H ml and spelt to a certain extent is that way as well.
Whereas Marko is like, well, what would it look like if we actually added reactivity and variables and all these things to the HTML language? Right? And we add imports to the language. Like there's no, you don't have to like create a script tag, you just do a JavaScript import at the top of the file or wherever you want really.
And it just kind of works, right? Like we've extended the H TM L language with new syntax, which. You know, it's kind of nice in terms of the dx, like you're not having to like it, it looks like you're writing JavaScript. It looks like this thing that was cohesively built, um, together. But it's also nice in terms of, okay, we've defined what this syntax means, which means we can optimize it however we like, as long as we, you know, keep that contract or whatever.
Versus like, you know, if you've got a hook. The reason there's hook rules is because JavaScript executes from top to bottom, right? And that's just like you expect the JavaScript to roughly execute from top to bottom. And I'm sure you can do throws and all that stuff, but like at the end of the day, you're gonna execute that thing from top to bottom.
But with the variables that are introduced in Marko templates, because we have a different like syntax, it feels less weird that maybe these ones are reactive and fine grained and like all that sort of stuff. But your JavaScript, we still leave alone. So your JavaScript runs from top to bottom. So yeah, Marko is a probably.
The, one of the most, like how can we augment H TM L rather than like just add annotations to H tml. Right. Um, another framework that I've, uh, kind of drawn inspiration from, not that Marko has necessarily drawn inspiration from, but that I think is like in the same vein, um, if you've ever seen Amba. Um, so Amba is like. Another framework's mostly client side oriented. Like it doesn't really have, you know, any of the things that I would look for in a framework. But as far as like their language design, they're like, okay, well let's just create like a concise mode H TM L thing. That is just an entirely different language that is specific for building UIs.
See, Marko is like that, except anytime we add new syntax to the language, we want it to either look like JavaScript syntax or HTML syntax, like, or at least in like the same. Syntactic category, like it should look similar. Um, so like the imports, like why would we have custom imports? It's just JavaScript imports.
Defining HML obviously is just, you write out your HML, the attributes, like, yeah, the values are JavaScript, but you're already familiar with JavaScript. Um, like we have shorthands for methods, but they borrow from the JavaScript method. Shorthands. Like basically we're just trying to merge the two syntaxes together in a cohesive way without like abusing either of the syntaxes, if that makes sense.
So that's Marko from a language perspective, which is honestly the. Thing that I think people are least interested in because it's like, Ooh, this is a thing that I just like have to learn. And it's like different from JSX and like, what about tooling and all that stuff? I think it's super nice, obviously, in my biased opinion to, to write in and I think, you know, we've made a lot of, in hindsight, good decisions in the language.
But I think the main thing that as far as people, um, like. Looking at Marko, they would more care about what is, what is its performance characteristics and all that stuff. But I do think that like once you try the Marko language, especially around composability and all that stuff, like wow, this is, you know, actually super nice to write.
Like if you go to component party, I dunno if you guys have seen Component Party, um, it's just a site that compares like, you know, the same quote unquote code across all different frameworks or whatever. And you'll go and see that the Marko examples are basically always the shortest and not in a way that's like superficially like, oh, we cheated on some syntax here.
It's like, no, these examples are just easier to represent in Marko because there isn't the boilerplate. Um, yeah. So anyways, that's Marko as a
language,
Andrew: I was going through the docs before this, and one thing that struck out to me is you have this like ID tag thing, which is like reacts equivalent, uh, use id and adding an ID in your example was like you just added a line at the right place in the markup and you're done. Whereas in React, if you wanted to do the same thing, you basically have to pull out the, the what you're putting that state in into a component, and you end up doing all of this, as you said, boilerplate and just kind of moving the code around to get that one line of code in there.
Dylan: Yeah. And I think like if, if your audience has seen like Dan's original talk on introducing React hooks. Like the benefit of this is clear if you look at like how much code do we have to move around in order to refactor this class React component example versus this hooks react component example.
Um, and you know, hooks are really good compared to classes in terms of being able to co-locate lifecycle methods and stuff like that. But hooks don't allow you to co-locate layout or rendering functionality. Um, with the hook itself, whereas in Marko, like we just don't have that restriction. Any tag can introduce variables and render, um, content and all that stuff.
So, and it's, you know, all T tree aware. So you can have an if statement in Marko and conceptually just put a hook right in the if statement and that, you know, state is just initialized when the if statement is active and it's gone when, or cleaned up when the if statement is cleaned up. Um, and so it's very easy to write code where.
All of the, you know, templating, styling, behavioral, everything is co-located and can be very easily, like top to bottom, snipped out into another component. Um, and so refactoring in Marko is also a lot easier than in JSX and for the same reasons that like, you know, hooks make it a lot easier. We just. Lean into that even more.
Plus everything is composable. Like I said, you can build your own, if statement, you can build your own state tag, which is, you know, obviously you can build your own, like used state and react. Um, but you can, yeah, pretty much any core tag in Marko, you can build yourself, build your own for loops, like, you know, which makes it really nice to like, okay, I've got this for loop, but maybe I, maybe I wanna have like a paginated loop or something.
Um, it's like, okay, well I'll just swap out my for tag. Here with a paginated tag and we're done. Right? Like it's very easy to do those kinds of refactor and compatibility and stuff like that in the market language.
Justin: It is, it's really amazing. Uh, I don't know. It's, it's hard to express like how. Far ahead, Marko has been for how long? Uh, so speaking of, uh, sort of the, the progression of Marko, let's, let's talk a little bit about, uh, V six. 'cause, uh, that's a, a big deal. So, uh, what, what's, what's different? what's, new? what's
changed?
[00:28:22] Key Features of Marko V6
Dylan: Yeah, so I mean the, there's two big things in V six and V six has been in progress for six years. Like I said, like it's a big effort and really it's like. How can we move more really the rest of the stuff into the language. Um, and also how can we make it so that the D ops that you would traditionally see through islands architecture are just not a thing you have to think about anymore.
Those are the two real goals of Marko Six. So as far as the like language goes, I mean, you, we've been so far talking about this TAG api, which is the new thing in Marko six. In Marko five. The way that you introduce state and um, client side behavior is through like a class. So it's like similar to like the React.
Class API versus the hooks API. So basically Marko six brings this like new hooks like API, except that it's like tree aware, um, and more easy to refactor and you know, that sort of thing. So that's one piece, just like the DX around the tags. API bringing more into the language. But the other goal of that, besides just DX, is how can we optimize things further? So the main DO that you see in islands based frameworks, so like if you look at fresh or astro or whatever, it's like, well, where is the island? Like, am I creating a mega island, right? Because basically with an island, every component that is used within the island is a part of the island. Like it gets bundled, it gets sent, and you know, all that sort of stuff.
Whereas obviously the goal, um, is to send just the JavaScript that's required, right? For whatever interactivity you have. Like if it's add to guard or like whatever. Um, and so Marko, like really from Marko one up until Marko five, it has been an islands based. Um, framework, and it's very easy to opt into an island with Marko.
Like, you just go and you add some client side behavior and that becomes the island, unless it was already under an island and it's consumed into the parent island and all that stuff. But, um, you know, you look at like Astro, you've gotta have your Astro files and you've gotta have your, um, you know, your React files or your spelt files or whatever, and it's like, that's the, the boundary is basically across these frameworks.
But that's like, you know, writing two different. Two different, uh, rendering technologies. So if you wanna share things between the templates, it's like kind of weird. Like you can't really do that. Or you have something like fresh where it's like you've got the islands folder and these are the islands. So you better be thinking about what these islands are gonna be.
But now what if you wanna add some state to the top of like your page, right? Does that mean that the whole page needs to become an island? And so this is where the ops come into play. And actually Marko, it's sort of easier to make these ops 'cause it's so easy to create islands. You just like add a class and add some client side behavior and now that thing's an island.
Um, anyways, so the way that you would traditionally kind of solve that is you would move your state lower in the tree. So you would use like trans exclusion or more components or whatever to move the state lower in the tree so that your page still has more server stuff and your islands are relatively small, like, but it's something that you have to think about and anything that you have to think about.
Is something that, you know, someone could either mess up, forget about, or just like not have the time constraints to be able to do the refactor right now. And so it just ends up with, with the ops. And so that's what we've seen with Marko. And I mean obviously like it's, you can write performance apps with Marko, that's like the whole goal of it.
And you can have the Marko mindset and like do all that stuff islands and think about it, but ideally you just don't have to. And so that's what Marko six is really about. So Marko six, instead of looking at like, Hey, this template has interactivity. Right. This template is the start of the island. Instead, Marko six looks at your state and your events.
Um, and so it actually looks at like the equivalent of a use state and says, okay, how, like where does this use state propagate through the application? Let's send just the code for that. And so what Marko actually, what Marko six actually does is instead of, um, the places where the state. Uh, basically like in most frameworks you create a state and then other places reference it, right?
And that's like how you write it in Marko. But in Marko, the compilation is such that you write the state and it follows that chain through the entire component dependency graph and plumbs through that change. So like when the state updates, it's like, I know I need to go and update this class. I know, I know I need to go and update this condition.
I know I need to go and update this text, but it's fine-grained. And so what that means is you can add state at the top of your application that goes and you know that's passed through a million components and ultimately makes it to some class. And all that you're gonna get in your JavaScript bundle is code that like updates that state and directly.
Goes and updates that class. Um, so you could think of it kind of similar to like solid or something like that where you have signals, you know, obviously in solid you, you would have a state that you define potentially at the top and you can plumb that signal through a million components. And ultimately once it's, uh, registered or like consumed in a computation or whatever, it's like that's where it's gonna read it.
And any changes to the signal are gonna propagate directly through in Marko six. It's essentially the same thing except. Compile time. And the benefit of that is we have essentially code that says, okay, this state directly goes and updates these things, so we'll tree shake everything else. Right? And that's how you end up with essentially no JavaScript.
So we took like our, like I don't, you probably seen like hacker news examples and. Like all that Hacker news clones, you know, it's like a sort of defacto like how are you sending minimal JavaScript, like kind of server running benchmark, whatever. And um, so in the Marko six example, um, it is currently like 200 bytes of user code, like in the compiled template to provide the functionality that's required for the only in interactive page in that experience.
Versus like most frameworks, you at least send the whole like. Toggle component or something like that. So you're probably looking at, you know, several hundred bytes or a few KB or whatever. Or if you're like not an islands framework, then you'd be looking at the whole app, which would be, you know, much more kilobytes.
Plus you've got the framework runtime size, which in Marko six is also very small. And so that's basically been our goal. You don't have to think about like, where does my island go? You just like use your state and Marko figures out how and like what needs to be sent to the browser in order to make that work. So the other piece of that, which is like a totally separate thing, but they kind of go together is resum ability, which you've probably heard referred to by like quick and um, they, you know, were working on, it's similar. Um, but basically in Marko six it is also resumable because there's really two issues when it comes to, um, initializing or hydrating the code that makes it to the browser, right?
Like you've got. How long it takes to actually run that code and initialize it. And for most frameworks, that means rerunning everything, right? So it's, you know, everyone says hydration is just attaching event handlers and running your effects or whatever. But in practice, every, like most frameworks are gonna be doing a top down re-render, matching that up against the dom, and then running your effects and event handlers.
So. You know, in Marko five it's island, so it like leaves a lot of the stuff on the server, but the island itself is still in Marko five of vid om and it will re-render it and, you know, attach van handlers and match things up that way. And so that can be slow. Um, and so in Marko six we have it so that I.
Because of how we have this whole tree basically unwrapped and the state propagates through and all that stuff. And we know like the dependencies of everything because it's all represented in the templates. Um, Marko Six will actually serve a render and say, Hey client, here are the effects that you need to run and here's the event handlers you need to attach.
And here is the state that was referenced by those event handlers so that it can, you know, continue on from where the server left off. So basically hydration and Marko actually is just. In Marko six, it actually is just attach the event handlers and run the effects. So that like runtime piece is really small, but then with the like state-based tree shaking that I was mentioning, um, it also means that the bundles are, you know, incredibly small.
And so, yeah, and also like from just like a runtime performance piece, because we've compiled your program into essentially what it would be if you had manually wired in signals, like the state knows exactly how to go and update all of its dependents. It's also fast, like just pure client side rendering performance is fast.
So it's super fast on the server for the same reasons. You know, Marko five is fast on the server, super fast on the client, but then probably the fastest framework in terms of hydration and bundle size, um, right now. So that's what Marko six is about.~~ Yeah. ~~
Justin: That's, that's fascinating. Uh, there's a, there's a lot of, uh, it sounds like there's a lot of compilation, complexity and a lot of like, bundling complexity here. And so I, I, I think like. Marko has always had some pretty advanced capabilities. And, and we were mentioning earlier that originally y'all had built kind of your own, uh, bundler asset pipeline thing called Lasso.
Very sort of customized tool that had a lot of capabilities even way back when. And so I think as you've been expressing this, uh, I've been kind of thinking of like. There's some parallels and complexity to like react server components a little bit, uh, from just like the optimization perspective and like how do you like, prepare all these things and send them out down in the correct ways.
[00:37:33] Tooling and TypeScript Integration
Justin: So what does the tooling look like today for like Marko six? Uh, I mean, uh, do you have like v plugins? Is there a custom build pipeline? Like what does
it look like to
use.
Dylan: we have been doing this for a while longer than RSCs and whatnot. So this is something that we've had to, you know, already sort of address, which is why I say that the Marko compiler itself is closer to a Bundler than, you know, something like Spel or whatever. So we've kind of got this abstraction layer in front that is in the Marko compiler that makes it easier for us to build these integrations into different, um, bundlers, which is how we were able to move away from lasso in the first place.
'cause lasso itself was kind of like. I mean, you could use it generically for something that, you know, didn't use Marko or whatever, but it was kind of built for Marko. Um, and so, yeah, to answer your question, in terms of like Bundler integration, um, stuff, we've essentially got that covered. So we have integrations for, you know, rollup, vt, um, ES build, web hack, obviously lasso, and there's even a Browserify one.
But the main thing is that like the way that we have things set up at this point, it's relatively easy for us to go and add these, um, after the fact. We've got that part pretty down pat. The, um, other piece is like, how do you integrate with tooling like TypeScript and stuff like that. And that has been a huge, um, challenge for sure.
Like during Marko six development is when we added TypeScript and that was, you know, several months of effort. But you know, it's like, is it worth it to go and do that if you have no other reason, like build a language and then add TypeScript support and like all that stuff, it's like, no, it's not necessarily worth it.
But at the same time, when you're building something. Um, from scratch and thinking of it holistically, you can improve it more than other solutions will ever be able to improve. So with our TypeScript integration. We have like finer grained narrowing than you could get in JSX, like the control flows know how to narrow.
We have like the, the elements, they know their type already. So like, you know, if you do a diviv and you wanna get a reference to the div, you don't have to type it as HTML development. It just knows it's an h tml development. So there's things like that where we're able to like improve. Um, but yes, it is a lot of work for us to maintain these integrations and we're, you know, trying to be cognizant of that as well.
Like whenever we do something that's against the grain or specific to Marko, it's like how can we abstract that in a way that's gonna make it easier for us to integrate with other tools down the line.
Andrew: Yeah, the TypeScript integration in particular piques my interest because, uh, one thing that has always bothered me when I author content for websites is MDX is great. It ha like, I can use react components that are in TypeScript and I have no way to type check it. So like in practice, how, how does like building out a TypeScript integration for your custom language work?
'cause like, you're probably just not using TSE directly, right.
Dylan: Yeah, I know. So we have a wrapper around TST. TSC, sorry, called MTC, micro type Check. Um, and so you know, TypeScript does not really give good hooks into building custom languages. So every framework that is adding a new language to. Type script is essentially hacks on hacks on hacks. And that's the case for, you know, views felt, and also us.
Um, so like generally the way that it works is you hook into the TypeScript compiler, either the CLI or the language server that powers VS code. And you say, Hey, this thing, this file here, like, yeah, you can resolve it this way. And also it's a pretend type script file. Um, and so basically what we do is we take your Marko template, um, you know, which we have.
Pretty nice DSL that's able to be translated to a lot of different things. So we take that template and we compile it to typescripts. Not that would run, but that would be able to be type checked in the way that you want. Um, and so we basically output this like TypeScript code and then for the editor we source map it back to your original code.
So that's generally how it works and that's how most of the tools sort of integrate it. It is a huge pain. It is a, uh, um, very hacky. I'm very curious to see how. Tools react to the new go version of TypeScript and stuff as well. But you know, at least we're not alone in this now. Like we've got view and, and spelt and you know, Astro as well also have to do this kind of thing.
So before, you know, this is why I was saying frameworks, um, adopting things that we want, like islands or streaming or whatever. And also, you know, TypeScript in this particular case, um. Super beneficial for us just because it's like, oh, someone else has done this. We're not having to build it from scratch.
Um, so yeah, TypeScript is a fun one for sure.
Justin: Hm. Yeah, I'm glad you're investing that. Uh, it's, that's like one of the. Biggest challenges, I think, uh, when it comes to like template based languages is, well that, and I mean, you just end up having to build a lot of custom tooling. So, uh, I, I'd seen you, you've been doing some work on the language server for Marko, right?
Like, uh, what has that experience been
like?
Dylan: Yeah. So I mean, the language server is actually, you know, pretty nice to, to be able to work on. It's relatively simple compared to the other stuff that we're trying to do. But, um, also like Marko as a language has constrained, which makes it easier to provide certain inte sense and like all that stuff and completions like we have.
Compiler in front of it already, so it wasn't a stretch to take that compiler and its a ST and CST and like plumb that into existing tooling. Um, so we kind of have a leg up there, which is actually something that's probably a challenge for like, I know, like solid and stuff like that. Like if you wanted to change the meaning of JSX, you can't, like, you know, it's always going to work that way.
The show tag and solid is always going to have the constraints in terms of typings that it, you know, has currently, because you can't change JSX, you don't own JSX, whereas at least we like own the language. So it's like, if this. You know, we've considered this, but like, if any feature is like, well this just doesn't, it's not really possible to type this well, this pattern or whatever, it's like, okay, well then let's figure out how we can make the language actually work for that, or make the tooling, you know, appropriately work for it, which we have done.
Um, and so there's a big pro in that we're a custom language in terms of like, we want your template to be able to do. Crazy things and run in a different order than maybe you expect the JavaScript to run and all that sort of stuff. And we want the typings to reflect all of that. Um, but you know, we just own everything and then you can do whatever you want.
It just takes time to build.
[00:43:52] Development Journey of Marko V6
Andrew: S Speaking of time, it took six years for Marko. Six, uh, what was like the pr, like the majority of that time spent doing, like, was the vision at the start, what, uh, you ended up with at the end?
Dylan: No, absolutely not. So when I say that, um, Marko six started six years ago, like basically six years ago, was maybe the first line of code for what would be in like the Marko six code base or whatever. But it's more around like, okay, we know that islands based D ops are super annoying. We know that we want a more composable language in terms of hooks and all that sort of stuff.
Um. What are we gonna do to get there? So there was like a whole bunch of exploration that took place. Like we weren't necessarily gonna move away from vdo M to signals, like potentially we're thinking could we have a tree shakeable, uh, state-based vdo M thing and all that stuff. And you know, ultimately it's really hard when you don't have constraints.
Like we own the language, we own the runtime. And we can do pretty much whatever we want. So it's like, okay, our goal is to output as small a code as possible. And also our goal is to make us set the code that you author is as nice as possible. Boy, those are vague goals, so it's like a lot of exploration went into what exactly should this API look like?
What constraints do we need in order to make sure that, you know, this code isn't bundled and like all that sort of thing. Um, but also we weren't like necessarily full-time working on Marko six for the past six years, right? Like we've been building a whole bunch of other things supporting, you know, teams at eBay and, um, all that sort of stuff, building the TypeScript integration.
But it is something that has been, you know, in the back of our minds in a rough form, uh, for six years. And I would say the real development of Marko six was. As far as like, once we knew what we were gonna build and there's just less unknowns was probably like three years of development, which is still a long time.
Um, but at the end of the day, like, you know, at eBay, performance obviously matters and it's very easy to de op and it's very annoying when a de ops So if we can get out this thing that makes performance easier and you don't have to think about it, that's gonna be a huge win. But on top of that, there's also a lot of like micro front end experiences that are being.
Built, which I haven't really talked about much here, but basically, you know, with a micro front end, it's, you kinda have two options. Either you share code, you have lot, well, I guess there's three options. You do nothing and you have a bunch of duplication and it's a slow experience. Or you share code between the micro front end and the embedded application or whatever, or the host application.
Um, and if you're sharing, it's like you're somewhat defeating the purpose of the micro front end because it's like you're trying to create a decoupled experience. So you really wanna avoid sharing. But the, the real goal would just be like, can you just make two really small experiences, like then you don't have to worry about the sharing, um, the orchestration, just like they're isolated, they're resilient and all that sort of stuff.
So Marko six actually fits really well into this like, embedded experience, these micro friend end solutions because you can say, Hey, I just wanna embed, you know, like for example at eBay, our global header is what we call it. The header is like a, a micro friend in basically. It's like, okay, we don't want the header to impact the, you know, load of the view item experience or whatever.
So we wanna have that like as small as possible. And so that means having like a really small runtime, obviously. But it also means like, if. The header is using islands, like you really have to think about the islands 'cause you wanna send as minimal JavaScript as possible for that header. Whereas in Marko six it's like you just kind of write it as you normally would.
The DX is good and it's just comes out and it's like, oh, it's like three kb. Cool. Like that's small enough that it fits into our budgets. Right. Um, and yeah, the header is like kind of an interesting one too because it's like you wanna, you know, have that first flush within like maybe 20 kilobytes or whatever.
And it's like if a header eats up. You know, a big chunk of that, like the page itself has to fight for the, the rest of that. So yeah, so these micro front ends, um, setups are, are really, uh, Marko six really shines there. But also just like in general, like obviously we want to have experiences that are fast and small and that's, you know, ultimately the goal.
Justin: What does, what does operationalizing Marko look like? So if you're like trying to run it, you're building a product and Mark. Marko, um, is it like specifically you like, need a node server, um, like a very specific setup? like? What does it what does it look like? What does it
take to run a Marko app?
Dylan: Yeah, so I mean we have a new meta framework, um, which is called Marko Run. Uh, came out like last year, I think. Um, and it is, you know, similar to like spelt Kit or Next, or. Next or whatever, right? Like, and it has the concept of adapters. So you can basically create an adapter that says, this is how I wanna change the bundling and compilation, and this is how I wanna change the runtime.
Um, and so, you know, we have adapters for netlify. We have like a static adapter to build static sites, or like, the default one is a node based adapter. So it makes it easy from, from that perspective to deploy it. Um, sort of where you want. Traditionally, Marko has been like. You're building a node app, like it just works in node.
Like that's what there is also, like most of its benefits come from the server rendering aspect of it. Um, but it is also pretty good for static sites because, you know, a static site is basically just a server rendered page that you dumped to disk, right? Like after you rendered it. And so, you know, if you're using Marko with a static site, you get all the same sort of benefits in terms of violence.
Like you're only getting the JavaScript that's necessary for that static page. Um. So as far as like getting started with Marko today, I would probably start from our meta framework, Marko Run. Um, and you know, it has adapters that can get you kinda kind of going and we're doing like a documentation overhaul right now as well.
So we're gonna have, you know, a doc site for Marko run. Um, and if you go to the Marko Js website right now. It's still in the, it's still showing the Marko five docs, but we've got like a little banner at the top that says, you know, Marko six is here, come check out the Marko six website, which is still a work in progress as well.
So some bugs to, to figure out. But um, yeah, that's one of the things that we're trying to, to wrap up here. Get the documentation in a good place, get, you know, Marko runs documentation in a good place, um, and start talking about it some more. 'cause we think it's useful for people not just at eBay.
Andrew: Justin, you wanna do a future facing question now?
Justin: Um, sure. Yeah. Yeah. Uh,
[00:49:59] Future Plans for Marko
Justin: so, uh, as we're wrapping up, we always like to ask a future facing question, and, um, I think it's pretty obvious here you've. Worked a long time on getting V six out the door. Uh, and congrats on that. Uh, really excited to to mess around with it. Um, so what's next on the horizon? Are there any new, like, big challenges Marko wants to solve?
Or is it really just like stabilizing and, and making the ecosystem good
around the tool?
Dylan: So, I mean, obviously like the next few months are probably around like stabilizing and fixing any bugs and making sure that some D ops are addressed and things like that, getting the docs finished, whatever. But longer term we do have, um, a bigger vision for Marko. Um, so like obviously to date. Um, pretty much you would use Marko if you can operate in a multi-page app paradigm, right?
Like basically if you could use Astro or you could use Fresh, then you could use Marko and it would in theory be better. Um, but we obviously there are a bunch of actual applications that make sense, um, to be an actual application. Like not everything is links and forms in, in the browser, although a lot is anyway, so future facing. We have a plan, uh, that's all it is right now, but a plan to make it easier to build app-like experiences while maintaining all of these benefits of Marko six. And that is where our biggest, um, next exploration is gonna be, is like, how can we have it so that you still send minimal JavaScript, but that you can have like a single page app, like flow and build anything that a single page app could do while keeping as much on the server as possible.
So kind of similar to React server components, um, except. Without as much like overhead and, um, with some considerations that should make it, uh, you know, able to stay small and stuff like that across the, um, entire experience. So that is one of the like, next things that we're gonna work on as well as like different like lazy loading strategies for that tiny bit of JavaScript that you still have on the page.
Um. So besides that, like right now, basically I think Marko is at a point where it's the best multi-page app framework that you could use in terms of performance and hopefully DX and that sort of thing. And you know, our next goal is to make it the best SPA framework that you could use in terms of the same things.
[00:52:16] Conclusion and Final Thoughts
Andrew: Well, that wraps it up for our questions this week. Dylan, thanks for coming on. This was a super interesting episode about all the different things that go into Marko. It's like it's from the future, but also rooted in the past. So it's very interesting to see where it'll go, and thanks for coming on and talking about it.
Dylan: Yeah, thanks for chatting with me. It was fun.
Justin: Yeah, thanks Dylan. Uh, I've always been really interested in Marko and really excited to see where it goes. So, uh, keep up the good work and we're excited to, uh, follow it.