Kate:
Hello, and welcome to PodRocket. I'm Kate, the producer of PodRocket. And with us today is Dylan Piercey, the platform engineer at eBay and a core team member of Marko. Hi Dylan. How are you doing?

Dylan Piercey:
I'm doing really good. Thanks for having me on.

Kate:
Yeah, thanks for being here. So yeah, if you could just tell us a little about Marko and what it is.

Dylan Piercey:
Great. Awesome. So, I mean, Marko is another one of these reactive front-end frameworks. There's obviously a ton of them going around, but I think Marko is interesting in a lot of ways and underrated in a lot of other ways. And I think the main reason for that is Marko's designed for a different type of application than a lot of modern frameworks have been built to address.

Dylan Piercey:
Most modern frameworks are built around the SPA architecture, single-page applications. Whereas Marko has kind of been built looking at things from a multi-page app architecture where you're trying to essentially do as much as you can on the server and have it pick up in the browser with as minimal JavaScript as possible, which coming from eCommerce probably makes a lot of sense, but that's really what separates it.

Dylan Piercey:
From the beginning we've been trying to optimize for that use case and although it kind of gives, in a lot of ways, the DX of a single-page app framework, it does have the performance of sending a sprinkling of JavaScript to the browser. I can go into a little bit about how that works and like the techniques that we use and sort of why that's been set up that way. Where do you guys want to take it?

Noel Minchow:
Yeah, I guess I'm kind of curious, like when we're talking about companies that are looking at single-page apps versus like multi-page traditional apps, would you ever say that an organization should maybe consider not doing a single-page app for any reason?

Dylan Piercey:
Yeah. And I think this is actually really interesting point. A lot of people look at MPAs and think, "Yeah, that's a traditional app, the traditional way that you do things." But I mean, if you think back to these semi-traditional sites where you're just sending it a script, grabs some elements on the page and add some interactivity and stuff like that, you're not really working with these declarative frameworks. You're having to go in and write a whole bunch of imperative code, and soft, and quite a mess to maintain.

Dylan Piercey:
So Marko is really set up to make it so that you can write things in a declarative way while still giving you as close us as we can, the ability to send just the minimal amount of JavaScript. And so where this really makes a lot of sense is for really content-driven sites. And eCommerce is a big part of that, is ... Essentially the question is, do you want to get some content to your user as quickly as possible? And then if you step back from that, I think it's becoming increasingly more obvious that one of the ways to do that is to do server-side rendering and send the HTML to the browser in a way that the browser can just receive that HTML and show content immediately to the user without having to wait for all these assets to download in JavaScript, to hydrate the page and all that stuff.

Dylan Piercey:
And another core principle of Marko is to take advantage of streaming. So like if you imagine an eCommerce setup, you've got presumably like some static content on the page that you want to show like the eBay header, for example. Then you've got all of this dynamic stuff that's going to be coming from some service to load the item data and stuff like that. Now, contacting that service is obviously going to take some time, but we want to send content to the user as quickly as possible. So Marko takes advantage of streaming so that we can flush out things like the header, the footer, and all that stuff immediately. And that gives the user the advantage of being able to download a few images, they can download the scripts and everything actually starts earlier.

Dylan Piercey:
And then once the content comes in, we can flush it out as it's available. So streaming is really huge for that use case as well. And then another thing, like I kind of mentioned at the beginning is if you're having the server essentially do some amount of the work, presumably the browser doesn't need to redo all of that work. Essentially, the server rendered the page and now we want to say, "When you click this button, add something to the cart or something like that, show some animation and so on."

Dylan Piercey:
But what most frameworks do is they say, "Okay, the server did this rendering of the code, and now the browser's going to do the exact same rendering from top to bottom and hydrate the page." And that takes time as well. And not only does it take time to actually execute that, it takes time to download all of the code to effectively re-render the whole application again. So Marko does not do that. Marko looks at your application, determines where the top-level interactive components are and just sends those to the browser.

Noel Minchow:
Got you. Got you. So if you're in a traditional organization, I guess just to kind of help us frame where Marko fits in, into the stack. Is Marko really just like another framework that devs would reach for akin to like angular react view or does it try to take a little bit broader of a slice because there's like a server component happening as well?

Dylan Piercey:
Right. Yeah. So Marko necessarily needs to take more control over your application than a lot of these other frameworks, because from the server to the browser, we want to have full control over that experience and be able to determine what assets get sent to the browser. So Marko actually has to have deep integrations with bundlers and stuff like that, so that we can know like, "Okay, we've analyzed that we only need these components in the browser. Let's tell the bundler to bundle just these components," and stuff like that.

Dylan Piercey:
So from the beginning, Marko has had a high focus on optimizing across the stack, which means that we need to touch more of your tools. And eBay actually has another tool that we've produced, but we're not pushing as heavily anymore, which is Lasso, which is kind of like a competitor to Webpac, Vite, and so on. That was also kind of built with this mentality, but it hasn't really been kept up in terms of features and stuff like that.

Dylan Piercey:
But yeah. So if you're choosing Marko, really you're looking to optimize a server rendered or a static-site generated page, which is like across the stack, Marko is going to determine what needs to be sent to the browser versus a traditional ... I say traditional, but a modern framework. They're going to be typically relying on some form of client rendering. And they're usually optimized for that specific piece. Some will compile to different code in the browser to at least be optimized on the rendering side of things. But I don't think ... There are very few that are actually set up to optimize for the whole experience, but there are new tools that are coming out that are doing that.

Dylan Piercey:
So yeah, that's really cool to see new tools, like, you've probably seen Astro gaining popularity as well. And so Astro basically sets you up such that you can build a static-site or a statically-generated site that is optimized similar to Marko. You essentially say, "I've got these components on the page. This one is interactive when we scroll to it," and so on. And there's also [Aisles 00:07:19], which is kind of similar and slinky. And these tools are really built for static-sites. Because if you think of a static-site, it's a lot like server rendering, except that it's cashed.

Dylan Piercey:
Essentially, you build some HTML, that HTML is already there, stuff's already been rendered. How do we make that already rendered HTML interactive? And hopefully that doesn't mean we're going to have to do everything again in the browser, which is what most frameworks do. Another one that's cool is obviously Quick, which is kind of a totally different approach and their strategy is to essentially lazy load everything. So whenever you do an interaction, like click a button, they're going to load whatever JavaScript's required to facilitate that interaction, which is a totally different way of looking at it as well. So there's lots of cool stuff happening in this space now, but Marko's niche is really server rendered applications that send as little JavaScript and as performative as possible.

Noel Minchow:
Got you. Yeah. No, thank you for that breakdown again, because I feel like it quickly gets confusing because there's like so many tools in this space that are trying to kind of slice that stack differently. I think a big delineation right now that I'm not even clear on is in Marko's ... So say I've got a traditional app like a store, like I'm doing an eCommerce site. I've got like my static files, I'm serving them either server-side rendered or like just as like static assets. And then I'm requesting all of the actual store data via an API, like asynchronously after that initial page load. Does Marko have an interest in doing that kind of data fetching on the server-side and then sending that down as well? Or is that not really in the broader view?

Dylan Piercey:
That is actually really interesting question. So I think our focus is really, like while you're rendering the HTML, that's probably when you want to be thinking about fetching the data. And you probably want that to happen on the server-side, especially depending on how your stack is set up. Because if you're imagining that you're contacting several services and they're responding with maybe an excess amount of data, usually the HTML that you send down, the final form of it contains like a subset of the data that would otherwise have had to been downloaded to the browser.

Dylan Piercey:
So we try and push that kind of stuff a to the server. Whereas if you think about doing like an Ajax request to say, "Give me the new items," and stuff like that, that kind of necessitates that you're doing all of this client-side rendering in the browser, which means you did have to send all the JavaScript to that. It is something that we are going to be focusing on, is how we can kind of keep stuff on the server while still allowing these kind of full-page transitions going into sort of the new transitional app world. But that isn't our focus right now, right now it's multi-page apps, you load stuff as it's rendering and then you add a sprinkling of interactivity sort of where it makes sense.

Noel Minchow:
Got you. Got it. Okay. Yeah. That makes sense to me. Yeah. Because I feel like that other problem, the problem of like, "I've got a bunch of data I'm pulling from an API or whatever," is the kind of space that tools like Gatsby, like even getting into that space a little bit more. Yeah. So I was curious, so when devs are looking at those tools, should they be thinking about Marko in the same way? Or is it more just like we can really do good server-side rendering of those first initial request load?

Dylan Piercey:
So it's mostly the first initial load of the page.

Noel Minchow:
Got you. Got you.

Dylan Piercey:
Yes.

Noel Minchow:
Cool. Cool. That makes sense. Yeah, I got them. I'm just trying to get the groundwork laid out a little bit here. Yeah. So what was the ... I guess, maybe for people that even have kind of less context here, can we go a little bit into, like, when we're talking about hydration, partial hydration, the traditional frameworks needing to do that top-down to get the whole trunk loaded, what that means and why that might matter?

Dylan Piercey:
Yeah. So, I mean, if you think about it from the perspective of server-side rendering or static-site generation, like I said, you have some amount of HTML that was rendered at some point, be it build time or on the fly. And so you've got this HTML that was rendered by a server, but it's not interactive at all. You need to go and attach event handlers and all the stuff that you can only really do in the browser.

Dylan Piercey:
And that's what hydration is typically referred to as. But the problem is that most frameworks are set up such that essentially to render anything or get these event handlers and all that stuff, get the effects and whatnot, you have to render the whole application. And then basically, if it's [Vdom 00:11:57], it's going to do a dev to attach those event handlers lazily, and stuff like that. But I mean, like I said at the beginning, if you think about it, the server has already done so much work, and presumably there aren't event handlers throughout your entire page. Like there's a lot of static content. And so happens is when you're hydrating in the browser, essentially this framework is rendering a whole bunch of static stuff that was already done by the server, which is harmful in kind of two ways. One, it's just wasted CPU cycles. So depending on the devices performance, I've heard of stories where hydration itself, just the actual CPU, intensive part of it can take like five seconds.

Dylan Piercey:
That's five seconds where the user can't do anything on the page. Like they're clicking buttons and nothing's happening. So that's pretty bad. The other side of it is obviously, all of this stuff has been done by the server and we're redoing and the browser, which means we need all of the code to redo it in the browser. If you are using, for example, like Moment.js, or something that's a larger library. And in Marko, if you only use that on the server-side components, we just don't send Moment to the browser.

Dylan Piercey:
So that's like a huge savings that you get. Whereas if it's a single-page app framework, especially if they're doing top-down rendering, you're getting everything. And that's one of the main downsides to it. That's why, especially looking at eCommerce, it's like not even actionable. You've increased the amount of JavaScript that you're sending exponentially, and you increase the amount of time that it takes to initialize that JavaScript.

Noel Minchow:
Right. Yeah. Got you. Yeah. That makes sense. So when we're talking about like JavaScript bites being expensive on the wired, do you guys ... I guess, when you were thinking about this and Marko was being rolled out, you were considering what mattered. Was there data gathering happening that was kind of driving the frameworks architecture itself?

Dylan Piercey:
Absolutely. Because I mean, for eBay, essentially before 2013, it was primarily a Java shop. So they were using JSPs and then they had, essentially adding sprinkling of interactivity through jQuery and stuff like that. Now, jQuery is a little bit large, but it's not like you're sending the entire application to the browser, essentially like some of these frameworks do.

Dylan Piercey:
So in early benchmarks, it was immediately obvious that this whole page hydration strategy was going to be sending too much, and obviously for a company like eBay, a hundred milliseconds has a huge impact on our GMV. Like it's basically a nonstarter. So it's like, "Okay, well, we want to switch to no-js because there's obvious benefits to no-js. What options do we have to still continue to send interactivity to the browser?" And so obviously, the simplest one is just, "Continue to use jQuery," and stuff like that.

Dylan Piercey:
But I've talked, at the beginning, that that's an awful developer experience. You're having to write all this imperative glue code and it's just hard to manage. And so from the beginning, it was like, "How can we make, optimize server rendering that only sends a subset of the application?" And that's really what Marko is.

Noel Minchow:
Got you. Got you. Was there kind of other frameworks at the time that were able to model things after? Or when was this conversation happening?

Dylan Piercey:
Yeah, so I mean, a lot of Marko's inspiration comes from React, because in a lot of ways, React did bring this much better developer experience to the user. So it's like, "How can we deliver that developer experience while also maintaining the benefits of being able to send minimal JavaScript? Why is this page so much larger? Why are we sending so much more stuff?"

Dylan Piercey:
And then the other inspiration for Marko is just these server-side rendering template languages in Node, like Dust, and Jade, and now Pug. And obviously, from the streaming side of things, we were looking heavily at Dust. Essentially when eBay was starting to go into no-js world, and we're like, "Okay, streaming is super critical, we already know that. And we know that we need to have a sprinkling of interactivity. What is a framework that supports streaming and Node that we can at least use Node?"

Dylan Piercey:
And at that time it was like, "Well, Dust is an option, but I mean, it's not the nicest language to write in. There's no easy way in Dust to add this sprinkling of interactivity." And so that's why at that time it was like, "Okay, we need to make it easier to build an application that works with the performance characteristic that we need."

Noel Minchow:
Got you. Yeah, totally. So, I mean, with eBay, it seems like the story is pretty clear because you have this giant existing web app that's has all this traffic and you've got to maintain the performance that you had while also migrating to something that has a nicer developer experience. I guess, for those devs out there, they're at smaller shops, they started with already act app or whatever. They've noticed some performance degradation over time. When do you think is a good time for them to start evaluating, "Do we need to start or look at other options that might be more performant?"

Dylan Piercey:
Yeah. I mean, it's tricky because it's going to depend on the type of app, right? Like if you've got ... Some apps just don't work in a multi-age app world. And I think Rich Harris recently had a talk where he is like, "If you want to have a video player or an audio player that's consistent across page navigations, you can't do that with an MPA." And that's true. So you kind of have to look at the experience that you're building and see if that experience is sort of set up to be able to be, in a lot of ways, progressively-enhanced or a sprinkling interactivity, that kind of thing.

Dylan Piercey:
If that model already makes sense for the type of thing that you're building, then you're just leaving performance on the table. So if you already know that's what you're going to build, then going down the path of Marko or some of these other tools can make a lot of sense. So it's really, right now, and this is the hard part, it's tied to what kind of app you're building. Everyone wants a one size fits all. Right now the race is to the middle. How do we get these transitional apps where you get the performance benefits of MPAs and the developer experience of SPAs?

Dylan Piercey:
And that's really been Marko's focus from the beginning to an extent. Obviously we're hyper trying to optimize MPAs, but we're trying to give the SPA like developer experience, and that's something we're pushing into even more. And I could talk a little bit about it, it's like semi-far future. We're talking like a year away. But I do think, one of the most interesting things that's going to happen in the next like couple years is this push to the middle transitional apps that actually maintain good performance in both scenarios. I do think there will be frameworks that's like, "Yeah, you can just pick this and it's going to be good for both types of applications." That is what excites me most about the current era of web development, is we might finally get there.

Noel Minchow:
Thanks. Yeah. Yeah. I think we can dig it a little bit. So currently, like say, we're building an app ahead of persistent audio player, I think was your example just now. It's like a sound cloud, like or something. I go click ... Would it be possible to build something like that with Marko currently? Or is it like it doesn't really fit the paradigm at all?

Dylan Piercey:
It is totally possible. So Marko does full client-side rendering. You can essentially say, "Okay, at the root, I'm going to set up a client-side router and you can do all of that stuff. And it would work very similar, like top-down hydration, similar to other for framework."

Dylan Piercey:
So it's definitely possible. It's just, that's not leveraging Marko's strengths. And really, Marko's strengths, like I said, come from knowing that, the server did some work, how do we continue from it? And so that's what we want to continue to be able to optimize in. And we're kind of doing it in two ways, in the next version of Marko. One way that I'll like to get into a little bit is we're, instead of looking at things from like a component by component basis, this concept of partial hydration, like only sending the components that have interactivity to the browser, we want to do things in a much more fine grained way.

Dylan Piercey:
Because what we've seen at eBay, and like in general, people using Marko, is you've got this component that has little bit of interactivity in it, but still the vast majority of the component is unnecessary to send to the browser. It might have like a huge SVG in there. It might have a static button in there. All this stuff that's still static, that is still ... So it's not the perfect world of we're just doing what is necessary in the browser. So one of the things that we're doing in Marko 6 is essentially breaking things up in a super fine grained way so that we can load just the stuff that is reliant on reactive data.

Dylan Piercey:
So it's kind of like, you can think of it like hooks, like essentially Marko is looking at, where is your use states and how is that use state propagated through the program? And the place where the use state exists is where we know there's an interactive parts. And so we'll just send those and then everything else can be split. So that's one thing. We want to optimize that, basically that's taking MPAs to the fullest performance potential. That's what we're trying to do.

Dylan Piercey:
And then, so another thing that's a little bit further future is since we have this analysis to basically say like, "These are the interactive parts," we actually want to do essentially the same thing on the server-side. And this is what I think our answer is for the transitional apps. So essentially, what we want to do is the server, when you're rendering a top-level component, you're passing in some input or props to that component. And those props define, what is dynamic on the server? If you have these partially hydrated points, the part that needs to change whenever you would traditionally do a navigation, is that top-level input to the server.

Dylan Piercey:
And so they basically what our plan is, is to create a router that works somewhat similar to React server components, where essentially whenever you do a navigation, it will ask the server, "Hey, send me just the expressions that depend on the top-level input that also weren't sent to the browser." And so conceptually the way that it would work is like, if you had a ... Imagine the user's name is printed in some header, but we only know the user's name on the server side. We don't want to bother fetching it in the client and all that stuff. And you do a navigation, and maybe during that navigation, we want to validate that the user is still the same user.

Dylan Piercey:
So what would happen is we'd do the navigation, we'd hit the server and say, "Hey, we want partial content, only the things that could change." And the server would be like, "Okay, is this the same page? All right, it's the same page. And so I know these are the dynamic things for this page that only the server handles, and so I'll send you just the username and maybe just a few other things." So that's what we see as the full sort of picture for transitional apps. And one thing that's kind of interesting about it is, essentially, if you have nested routing as well, it makes it super easy to be like, "Okay, well, what is consistent between the pages?"

Dylan Piercey:
So we know that the top-level is always going to be consistent, but then these nested routers can also be independently consistent. And so the end game is Marko will tell the server, "Hey, I'm rendering this route, this portion of the document, is it the same as what you gave to me last time? If so, send me an update. If not send me the HTML and I'll stream it in." So that's kind of where we see it going.

Dylan Piercey:
And then in that case, like there is still going to be overhead for MPAs, because essentially we have to send some markers to the browser to say, "Hey, these are the parts that the server can update that you can't update." But we're not sending all of the JavaScript to rebuild the whole application in the browser. And whenever you do a navigation, we just say, "Hey, server, what's the new dynamic stuff that you had sent to me?" Whereas, React server components right now basically says, "Hey, server, give me all of the data, all of the J[inaudible 00:23:28], all of the Vdom again, so that I can dev it." So it's like sending a whole bunch of stuff, whereas, we wanted to have it be more fine grain and send just the minimum amount of content to the browser.

Noel Minchow:
Nice. Nice. Yeah, that sounds super cool. And again, to bring it back to the example of like a persistent audio player, then it's very easy. Like, well, everything else is like a sub route that audio player sits there like in the outer rapper components.

Dylan Piercey:
Exactly. Which is exactly how you build it in a SPA, right? You need to make sure that when that page is rerendered in a SPA, that the route is still there, right?

Noel Minchow:
Exactly.

Dylan Piercey:
Because otherwise, it would be [deved 00:23:59], and removed, and so on. So you would essentially, and this is our goal. We want to make it so that you get this SPA like DX while maintaining the benefits of offloading as much as you can to the server. Because offloading things to the server has huge benefits. And by server, I mean, it could be a server, it could be statically generated, so on.

Noel Minchow:
Yeah. Got you. Got you. So yeah. So like this paradigm of returning things to the server, do you think that in general, say ... Again, we're talking about apps for where like somebody's built something out. They have literally just like static files that they're serving and then fetching all the data from the API. Is there a [swath 00:24:40] of developers that don't even think about rendering the web via servers in the old school style?

Dylan Piercey:
Yeah. Yeah. And it's tricky. In some cases, those kind of experiences are going to make sense. I'm not going to say that the ultimate transitional app is going to be the best for each case, but we want to have it be like pretty, pretty good for all cases. Yeah. Client-side rendering is always going to have of its place. And one of the things that's interesting, I think, about our approach is since we know, and we're tracking the things that are derived from state and this like top-level input and all that stuff, you can do client-side rendering.

Dylan Piercey:
Like if you wanted to fetch some data based off of some client-side state, you can do that, and Marko would basically be like, "Oh yeah, that's derived from client-side state? Okay. Well, we'll do client-side rendering for that." And so that's where I see it as the true transitional app in that you can kind of opt in, "This is client-side rendering, but by defaulted it's server-side rendering."

Noel Minchow:
Got you. Got you. When you're interacting with the community and the user base, is the API that kind of makes that delineation pretty clear? Is that easy for users to work with an intuitive or do people often get kind of confused about the [crosstalk 00:25:53]?

Dylan Piercey:
As it stands right now is, it is something that confuses people, especially when they're first getting into Marko. So right now the heuristic in Marko 5 is essentially you write this single file component and you can put a class body on there that gives you life cycles that you can work with in the browser. And so having that class there is what says, "This is a component that should be sent to the browser."

Dylan Piercey:
And so the thing is, a lot of people come at Marko and they're thinking of it from the SPA like mentality. So they put the class right at the top and try and do all this stuff at the top. And then you send the whole application down and it's like, "Well, why isn't Marko doing what it said?" And that's why we think that this whole sub template hydration and stuff is really important, because essentially, instead of just putting this class at the top, you just put your state where it makes sense, and Marko's like, "Oh, this is the part that should render in the browser." So the developer doesn't really have to think about it. If they write something using state, that is going to cause client-side updates in a fine grained reactive way and only send the code to do those specific updates.

Noel Minchow:
Got you. Yeah. Very cool. Very cool. I guess, that kind of leads me to this other question. And this thing I've been thinking about abstractly recently is like, I feel like a simple React app is very conceptually easy to grasp for a new dev. I feel like having to think about like server-side rendering or doing pre-rendering or pre-compilation, and having to bring all that into the purview of a new web developer, seems like a large ask, right?

Dylan Piercey:
I agree.

Noel Minchow:
Do you think that that's a fair thing to be kind of asking new web dev? Would you point, someone you're mentoring be like, "Hey, figure out Marko as your first kind of front-end framework"? Or do you think that that is maybe not the best?

Dylan Piercey:
Well, I think the heuristics in Marko right now, like I said, they can't trip people up, but it is like a fairly simple heuristic. And once you get the mental model down, I bet it is different, you can do pretty well there. But having said that, yeah, it isn't something that we want people to think about. That's the whole point, right? We want this to look like you're writing a declarative front-end framework where things can just update whenever you want and all that stuff.

Dylan Piercey:
And that's really our goal. Right now it's not as fine grained as we would like, but next version of Marko, we think it's going to be a lot better and you're going to notice it a lot less. You're just going to be like, "Oh, wow. In this Marko app, it sent zero KB of JavaScript, or like six KB of JavaScript," versus the 200 or 300 that is the baseline for some setups.

Noel Minchow:
Yeah. For sure. When we were talking about the performance, or I guess even the size of the files you're loading. I feel like a lot of devs also don't even have visibility to that. Like when they do create React app and do their thing and don't even think about the size of their-

Dylan Piercey:
Yes.

Noel Minchow:
Is there a way that you guys, in your development cycle, internally or just when you're talking about Marko, or doing performance checks. Is there something you do as part of that dev cycle to kind of keep an eye on that?

Dylan Piercey:
Yeah, so, I mean, obviously we're looking at bundle sizes and we've got performance monitoring all the time. But like during development, really, if you're building a Marko app, what you're trying to do is move essentially the stateful logic, the interactivity as low in the tree as possible, because you want to let the server do as much of the work as you can.

Dylan Piercey:
And so that is definitely something you have to have in the back of your mind while you're building a current Marko application. But like I said, that's why when you're evaluating, should you use Marko? You should look at it from the perspective of, "Is this a site where I know I'm going to be adding sprinklings of interactivity?" When I say sprinkling of interactivity, you can still have, "This section is purely client rendered and is shuffling things around, is doing ..." You can do quite a lot, but if the majority of your application is going to be set up that way, that you're adding things and you're fine with the page level navigations for everything else, then Marko is a great fit.

Dylan Piercey:
But currently if you need something where you're going to be doing transitions across pages, and you want that to animator, you want to persist things, Marko does not currently do that.

Noel Minchow:
Cool. Cool. Yeah. Yeah. And again, I'm not trying to ring these things up as like, "Oh, this is a big scary reason." But I do feel like this is a hard problem. And especially when I'm talking to people who aren't familiar with web dev or they are kind of on the fringes. It's just like, "Oh, there's this whole other space that we're like spending a bunch of energy on."

Dylan Piercey:
I agree. And this is why I think Marko, in many ways, is really underrated. Because it is super optimized for this specific case, and this case is a valid case in web development. There is a lot of content-driven sites out there that you want to add interactivity to. But the thing is, most of the focus right now has been like, "How can we build apps in the browser?"

Dylan Piercey:
And so since that's been the huge focus, the ecosystem around Marko and this kind of architecture is kind of sparse, and that's part of the reason why we believe that Markos adoption hasn't been as much as other frameworks. Having said that, I do think that we are rounding the corner in terms of creating a transitional app where someone could be like, "I'm using Marko, it's an SPA, but it's taking full advantage of doing the work somewhere else and the dead code elimination, and all of that stuff."

Dylan Piercey:
So that's where we want to be. We want to be at a point, like you said, where you're not thinking about this stuff. Right now you do have to think about it a little bit, and especially when you're deciding what architecture makes sense for the type of application that you're building. But yeah, we hope to alleviate that moving forward.

Noel Minchow:
Got you. Yeah. It makes sense that you guys are thinking about it and yeah, I'm glad to hear you're approaching it with that same empathy, I guess.

Dylan Piercey:
Yeah. I will say ... So I've said this before. One of the things is I feel Marko is kind of uniquely positioned to tackle this transitional app setup, because one of the things you need to have a performant transitional app is to be able to continue from where the server left off. And that's been our focus sort of from the beginning. And so the question for us is, how do we take this thing that's already split up in a million different ways to send only what's necessary to the browser, and then pick up off of that in a way that doesn't require sending everything to the browser? Which I think, as I described before, we can also analyze our way out of and build a performance solution that continues to work even with a SPA like mentality.

Noel Minchow:
Got you. Yeah. I guess on that front is like, have you seen instances or are there people that are, they have a traditional React app right now and they want to transition to Marko? Can they do those at the same time? Can you have React running inside of a Marko app?

Dylan Piercey:
Yeah. I mean, you definitely can. It's not the easiest thing ever, but you can use Reacts client-side rendering APIs or service-side rendering APIs and swap it out. The thing that you typically lose when you're trying to merge frameworks together is the transfusions of content. So like if you've got body content that you're trying to pass through, like, "This is Marko content, it's not going to make sense in React world."

Dylan Piercey:
So there is some stuff there, but if you design your APIs in certain ways, you can get around those kinds of things. I will say that by its nature, React isn't really a good setup for the niche that Marko has put itself in, because you're bringing a huge amount of JavaScript unnecessarily and the service-side rendering isn't quite where we'd like to see it and all that stuff. So maybe picking something like Preact or something like that, if you wanted to migrate and use Marko would be better. But yeah, there's nothing technically stopping you from doing that.

Noel Minchow:
I guess I was more like, again, say you have a React app, you realize the shape of your app is a better one for something with more like server-side rendering. Like, "Oh, we should switch to Marko or something."

Dylan Piercey:
Yeah. You can definitely do it in a piecemeal kind of way.

Noel Minchow:
Yeah. Got you. Cool. Cool. Yeah. Let me think here, I guess I'm kind of curious on your personal history and how you found yourself in this space, like working on the framework at eBay. Can you tell a little bit of that story?

Dylan Piercey:
Yeah. So, I mean, I've been programming for quite a while, since I was like 12 years old, building like little websites for various games I was playing and so on, but basically my second job out of college, I was just hammering out websites. Like it was an agency that just made websites for other various different customers.

Dylan Piercey:
And those websites varied from heavy content sites to actual spotlight applications with lots of rich interactivity and stuff like that. But at the time when I was doing it React router didn't even exist at that point, but I was using React and the DX was great. And so I wanted to go down that path, but I knew that service-side rendering was going to be really important for some of the experiences, that I was building SEO, it's going to be important and so on. So I wanted to make sure that that was thought of.

Dylan Piercey:
So I went and built essentially this framework that was a router, but it allowed you to do service-side routing and client-side routing. And it also handled form submissions and stuff like that. So you could do progressive enhancement really easily with it. So that got me down that path, but I was using React. I mean, it was sending all of the JavaScript for like the whole application. And since I was doing progressive enhancement, it was still pretty good. Like you could interact with the page before the JavaScript loaded and all that stuff, but it was pretty clear that for some of these experiences I was sending way too much JavaScript.

Dylan Piercey:
And so that's kind of what brought me down the path of looking into Marko and realizing that it really was just like a different conceptual way of building websites, but it still had that good DX. And so my work on the router ultimately got me in contact with some of the other Marko core team members. And that's what got me on the team.

Noel Minchow:
Oh, nice. Very cool. So were you like contributing and figuring it out and stuff, and then they were eventually like, "Hey, we're all embedded here. You should come join us"

Dylan Piercey:
Yeah, pretty much. I mean, the sad thing of it is like I realized my router because it was conceptually a top-down, send everything to the browser model. It is never going to make sense for Marko, anyways. But I'm excited for where we're going in terms of routing and all this stuff, like I talked about earlier, I do think that is like the ultimate solution. I mean, nothing's ever the ultimate solution, but it's a good step in the direction of having these transitional apps and I wish I had it back then.

Noel Minchow:
Nice, nice. So was eBay already basically using Marko for everything at the point when you came aboard? Is that-

Dylan Piercey:
That is correct, yes.

Noel Minchow:
Got you. Got you. So are you guys fielding questions for the dev teams and stuff internally, like the in-house?

Dylan Piercey:
Yeah. A big part of our job is continuing to work on Marko. We're actually a part of the web foundation's team at eBay, so we maintain Marko and a whole bunch of internal and external modules, and then we also do support for these teams as well that are using our products. Which is really good, because we get really tight feedback. Like if someone doesn't like something about Marko, we hear it pretty quick. We're getting bugs fixed super fast, the turnaround ... Because we've got direct lines of communication with all these people. It's nice to be able to work on this framework in open source, but then have these people picking it up right away.

Noel Minchow:
Got you. Yeah. Yeah. Totally. Is that communication typically like bubbling out through the open source channels or is there kind of [crosstalk 00:36:56]?

Dylan Piercey:
Sadly, no. And that's probably something that could improve, because a lot of the communication around Marko happens internally and Marko was kind of super integrated with a lot of internal tools. And so we didn't have necessarily those same tools available in the open source community, which is kind of unfortunate. So we want to better embrace these new technologies that are coming out. We've got integrations with Vit and we got a prettier plugin and we're trying to actually integrate with tools that eBay isn't necessarily using right away and then trying to push adoption in eBay as well, versus just building a framework for eBay.

Noel Minchow:
Right. Yeah. Is prioritization ever tricky? Because resources are limited. How do you guys decide like, "Oh we'll build some integration that we really have no internal use for, but will be good for the health of the framework?"

Dylan Piercey:
Yeah. It is tricky. And I think the reality is like if there is outside interest in some integration, why isn't there inside interest as well? Like maybe we haven't done enough education internally or maybe it just doesn't fit with Marko. And that's a fair thing. Like some integrations just aren't going to work with Marko, and so we consider that. But in a lot of cases it's like, "Yeah, there's cool stuff out there. Why isn't eBay using it?" So our team is also trying to push eBay to use more modern and open source technologies and expand in that way.

Noel Minchow:
Nice, nice. Very cool. Did you ever see yourself in a position like this, like working on an open source project inside of a large company? Was that a weird place to find yourself?

Dylan Piercey:
A little bit. I mean, like I said, I'm mostly just like, what am I trying to build? How can I make this as performant as possible? And "Oh, okay. It turns out that you can't do this in a way that's nice, so I'm going to build tools until I can make it an approximation of nice." So that's what I've kind of always been doing since I started development. So to be able to work on a framework, especially one that is like, in many ways, fundamentally different than others, and has unique problems that it's trying to solve, I think is super interesting. And yeah, so I'm definitely happy to be working on what I'm working on.

Noel Minchow:
Nice. Nice. Very cool. I guess with that, is there anything in particular kind of coming up with Marko or just like related tools that you're excited about that we haven't already covered, that you want to plug chat about a little bit?

Dylan Piercey:
Yeah. I mean, so we've sort of recently put out a Vit and CloudFlare example for Marko. We think deploying Marko to the edge is super awesome. To be able to have this streaming service-side rendering happen at the edge is great. So that's something we've recently done. Obviously, we've got coming Marko 6 and these things that I talked about.

Dylan Piercey:
Another thing that we want to sort of explore more and add support for is the ability to say like, "Okay, I've got this section of code that I want to hydrate in a fine grained way." But right now we don't give you the ability to say when that is. It's just like as soon as it loads. And so we want to sort of like Astro, be able to say like, "Yeah, this section's going to be chunked up in a fine grained way, but we want to load it when the user scrolls to it," and stuff like that. So that's another thing that's coming.

Dylan Piercey:
And actually, a thing that we want to get done this year that, in many ways, is one of the major complaints against Marko, is since Marko is a language we have to do integrations with various different tools, like TypeScript, [ESLint 00:40:25], and so on. And we don't currently have TypeScript or ESLint support in the actual templates. You can write Marko in a multi-file format. So you can write your TypeScript over in a different component JS, but your template logic wouldn't have the types of completions and stuff like that. So that is another thing that we want to address here fairly soon.

Noel Minchow:
Got you. Nice. Nice. So you can't write your Marko files with TypeScript, but you're saying you don't have support through the framework for that. Is that what I hear?

Dylan Piercey:
Well, so Marko is actually a language which actually comes a little bit back to the developer experience side of it. Like we make it really easy to ... It's HTML first and then essentially, we have a custom parser and we sort of enhance HTML to be able to represent a whole bunch of things, like render props and passing complex data, and all that stuff. And yeah. So in a lot of ways, Markos, I would say has a really good DX in terms of its language, but because it is a language, it requires us to do all this additional effort to actually support integrating with other tools, which is something we're doing better. Like I said, we came out with a prettier plugin semi recently and stuff like that. So that's something we're focusing on.

Noel Minchow:
Got you. Yeah, yeah. Again, I set up a hell of world in prep, but I hadn't thought of the extra load for you guys and like, "Oh yeah, this is like a separate extension." Like there's no-

Dylan Piercey:
Right. Yeah.

Noel Minchow:
Yeah. Right, right.

Dylan Piercey:
Yeah. Compared to other frameworks, I would say Marko has probably one of the most complex languages. Like there's a lot that's supported in Marko and there's a lot of nice things too. Marko, the tags, you don't have to actually be like import whatever it automatically finds the tags. It's been like that from the beginning. With the attributes, you don't have to actually quote your attributes. Like basically the Marko syntaxes. You have attribute equals and then JavaScript expressions.

Dylan Piercey:
So it's not just HTML, it's JavaScript expressions where it makes sense. And then you've also got the ability to represent a whole bunch of other things. So we've been trying to, and we've got an article out that's our Tags API Preview, that puts more into the language so that you can represent pretty much everything in the language, which I think is really cool. And language design is a big part of what makes Marko, Marko. It's just not, it's like main selling feature. But again, DX is always in the back of our mind. And having control over that template experience is important to us too.

Noel Minchow:
Nice. Nice. Yeah. Very cool. Yeah, man, I feel like we've covered a lot. Kate, is there anything else you wanted to jump in with here?

Kate:
Yeah. Thanks for joining us. And I mean, where do you want to point our listeners? Where can they find you? That sort of stuff.

Dylan Piercey:
Yeah. Definitely, if anyone wants to check out the Marko Discord, we're always hanging out there. Most of us on the Marko team are also active in the Solid Discord, so you could jump over there too. And then obviously, on Twitter, we've got the @Markodevteam handle, and I'm @Dylan_Piercey there. So if you could check out what we're posting there. Yeah.

Kate:
Awesome. And yeah, we'll include those links in the show notes and yeah, thanks for joining us.

Dylan Piercey:
Thanks for having me.

Brian:
Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me, even though that's not a popular option, it's brian@logrocket.