What Framework Should You Use?

Taylor Hunt, Manu Martínez-Almeida, Rory Madden at UXDX EMEA. Video: https://www.youtube.com/watch?v=CHWDFGsbMls

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Standardizing on a framework, and introductions

[00:00:01] Rory: Today, what we want to talk about, and this was really interesting because I was just chatting at a forum there in the break, and it came up that a lot of people had been standardizing. It was a big process, and people were saying they were standardizing on React because they didn't want one team using Vue and another using React and another using something else. So they were limiting and standardizing on React to make it consistent. But obviously one of the challenges that presents is that technologies evolve. Everything moves on. People had standardized on Angular, people had standardized on jQuery.

[00:00:34] That's the purpose of this conversation today: what are the new ones, and how do you know that this is actually something new, versus something that might not take off? And should you jump in and start adopting it? That's what we're going to talk about today. First, I'd like you to introduce yourselves so the audience can get an understanding. I'll start with you, Taylor.

[00:01:00] Taylor: Totally. I'm Taylor Hunt. I work for eBay on the Marko framework development team.

[00:01:07] Manu: My name is Manu. I'm from Spain. I recently moved from Lisbon to Budapest; before that I was in Berlin for a little bit. It's never a stable place. I work in the open source team at Builder. It's a drag-and-drop tool for e-commerce sites, but I work in the open source team, so we build a new framework called Qwik. We are three people: myself, and also Miško Hevery, the creator of Angular, is part of the team, and also ex-employees from the Ionic framework. I don't know if anyone here uses it. We are the three of them building that.

What is unique about Marko

[00:01:48] Rory: Excellent, so a high-pedigree team. I mentioned at the start that React is the elephant in the room, the big framework at the moment. It feels like there's a new framework every week. So I'll start with you, Taylor. What's unique about Marko? Why should people pay attention?

[00:02:10] Taylor: Because it is not new as of this week. It is new as of eight years ago.

[00:02:12] Rory: Okay. I always think of Marko 6, because that's where there's a lot of new reworking. So maybe give me a bit of the history of Marko, and then where you're taking it with Marko 6.

[00:02:27] Taylor: Certainly. A long time ago, ebay.com rendered everything on the server, because you had to. When Node.js started gaining a lot of traction among developers, and developers at eBay wanted to use it, it was agreed that you may, as long as you don't regress any performance metrics on the main site. That's a very unusual thing for JavaScript frameworks nowadays to have as a requirement, and we are seeing some of the emissions from it. So Marko started as "don't be any worse than the old thing, but make it nicer in a way that we want our developers to work on."

[00:03:07] As the ecosystem has evolved: first Marko was just fancy templates that streamed from the server, just like the old-fashioned ones did. Then it had asynchronous fragments, much like Facebook's BigPipe back in 2007. Then we added a terse mode, almost like Pug or Haml or the other HTML templating languages. Then when components won the hearts and minds of developers, we added a component model to more easily put the small bits of interactivity that actually need to be on the client into the same code base, in the same exact components, as opposed to writing everything one and a half times.

[00:03:51] Marko 6 is hopefully skating to where the puck is going, because there's a lot of fire in motion in the React community, in terms of a bunch of new APIs. Maybe some of them will be the important ones, but all of them are distracting ones. Hopefully we are taking what is still good about our performance, which we are heavily incentivized to keep, while also shrinking the client-side footprint even further, and even shrinking the server-side footprint in some places.

[00:04:31] Rory: Great. If I distill this down, and correct me, its origin was as a performance framework. That was your key thing, and you've maintained that throughout. So what is the key selling point, if somebody's using React, or they've got Angular or some other framework? What would be the best benefit you could tell them to start using Marko?

[00:05:02] Taylor: It has the component model of React today, but it actually renders on the server in less than a second, which a lot of React users' sites cannot. Well, in theory it can. I'm not allowed to say React is slow. I have to say React is statistically slow.

What is unique about Qwik

[00:05:21] Rory: Okay, great. I'll pass the same question over to you, Manu. And this one I know for sure: Qwik definitely is new, and it's not just Qwik version six. So can you tell me what's unique about Qwik, and why somebody should listen to this framework over something that they already have?

[00:05:40] Manu: The way I like to see it is that when you make any kind of technical decision in your company, you choose a specific framework, you choose specific providers, you value a set of trade-offs, and you make these trade-offs based on the current context and the current options available. What Qwik fundamentally does differently, completely new, is that it really changes some of the trade-offs that you have to make. If it was another framework, say, "I know it's very fast, it's a very nice developer API, but if you have a lot of interactivity, maybe it's not something you should even consider, because for your use case it doesn't really apply."

[00:06:28] So probably the decision you already made was the right decision. You chose React because it really solved your problem. What Qwik fundamentally does is that it doesn't have the same trade-offs, so it's really a new option on the table for pretty much all the use cases. That's what I would say. We target e-commerce sites, so especially very complicated applications with a lot of interactivity that have to be extremely fast. And it has to fit the current developer experience of developers, like the React model, even taking React components and using them in Qwik. I think Qwik is fundamentally new in that it brings something completely new to the table, and it would be good for a lot of engineering teams and leads to re-evaluate their decisions, because this is a new player in town.

[00:07:21] Rory: Can you just dig in there slightly? You say that you're making trade-offs with React and you're not making trade-offs with Qwik. So how exactly does Qwik get around the trade-offs?

[00:07:30] Manu: It's not that there are no trade-offs. You usually make a decision, you write down why you made the decision, and then nothing really changes unless you need to do something else or the context changes. This would be a context change. With Qwik, fundamentally, you get a fast website. I feel like right now there are two kinds of companies: the ones that prioritize performance at all costs, and the ones with bad performance. I think Qwik in that sense just works, because it builds a fundamentally different model of how the JavaScript is delivered.

[00:08:13] By default, you will have a Qwik application and no JavaScript runs. That's one of the first things. It doesn't matter the complexity. Actually, when you compare different frameworks with Qwik and you start to add more and more components, you will see there's a linear trend going up, and in Qwik it doesn't: it's flat, O(1). And it does that while keeping everything interactive. With another framework it's, "Yeah, HTML only, there's no interactivity." With us you will still have the same interactivity, SPA navigation, but with the performance of an MPA. It seems like a big claim, but it's because of resumability, which, if you check my talk, I explain in detail. Marko 6 is also working on the same concept, and it's a fundamentally better approach to building applications.

How hard is Qwik to learn?

[00:09:07] Rory: Great, and I'll stay with you, Manu, for this one. So we've got the pitch there. It's that scalability of performance. A lot of websites do have that payload challenge, with the size, and it gets slower over time. So let's say I'm bought in and I want to go for it. How hard is it to learn Qwik? Is it completely new concepts that are going to take a long time to learn?

[00:09:34] Manu: No, not at all. The concept by which we achieve this, we call it resumability, and it's not something new. Google has this internal framework called Wiz that actually powers their more complex products that have more users: Google Search, Google Photos, Gmail. They have Angular and they use other frameworks for other things, but for the things where performance is very important and that are extremely complex, they use Wiz. The problem with it is that it's a pain to build anything with it. They can only do it for these big, big projects.

[00:10:11] One of the focuses in Qwik was to make it simple. Making a Qwik application is, in that sense, exactly the same as making a React application, even though under the hood we're completely different. The authoring of components is the same. I would say it's 95%. You might have to learn about some new concepts, but I think they are delivered progressively. You don't have to know all these things up front to start to use Qwik. And you can even use React components in the Qwik component layer. We have demos using Material UI, and even complex things like three.js [?]. So if you really have that use case, you can have this big thing right there.

[00:10:59] Rory: I know it's in the early stages, but do you have any real-life stats? Because it's one thing to say it's easy to learn, but do you have any examples of teams and how quickly they've picked this up?

[00:11:10] Manu: Actually, yes. On the docs site we wanted to add search. I don't know if people here know a company called Algolia, but they have a super nice search product that you can integrate. For the UI, Algolia has a React library. At the beginning we just put it there, and of course it's a React application, so you don't get all the benefits. So one member of the community took all the React components and made them Qwik. If you look at the diff, it's ridiculous. It's adding very few things, and you can start to see that there is a one-to-one mapping. It's not like you can automate it, but pretty much. I think that says something.

How hard is Marko to learn?

[00:12:01] Rory: Excellent. And the same kind of question: let's make the assumption I'm coming from React, or maybe Angular. I'm coming from that world. What does it take to learn Marko?

[00:12:12] Taylor: Specifically from those worlds, we find most people start by looking at the client-side component layer and interactivity, because that's what they're familiar with, and then hopefully our docs lead them over halfway to how good server rendering could be if you actually liked it. Similarly, we also have a lot of people coming from the more classic server-rendered frameworks, like Ruby on Rails or JavaServer Pages or even PHP especially, where they like what they're seeing in terms of the server output. Then they get to learn, "Oh, it comes with its own client-side enhancement layer that uses the same syntax and the same concepts, and I don't have to learn jQuery and PHP at the same time."

[00:13:00] The nice thing we found out is that most people in the industry of making websites already know how to make websites, so we just have to meet them halfway. They are going to be forced to learn new concepts, but if you are picking a new framework and you're not expecting to learn something new, I think you should not be shopping for a new framework in the first place.

[00:13:24] Rory: Just on that, because you mentioned two different audience segments: do you have a preference? Do you market or pitch more to those Ruby on Rails and PHP people, or would it be more the React people, or both?

[00:13:39] Taylor: Professionally, we take anyone we can get. Personally, I prefer the third segment that I didn't even talk about, which is the classic front-end developer who knows HTML and CSS really well, knows how to put together a form submission, and by volume is the most common kind of web developer in the world. But there are a lot of increasing barriers, and the bro-ification of Node.js, and, you know, JSX is HTML for men. So I would love to make Marko as easy to enhance from the lingua franca of the web, to have minor interactivity, much like all you have to do to upgrade to PHP is change the file extension and then put a dynamic year in the footer.

[00:14:29] Rory: Is it that level of upgradeability, where you can go quickly from something like PHP to Marko? Or, as you were saying, do you need to learn a bit of new concepts, similar to what Manu was saying?

[00:14:40] Taylor: You can certainly start. On syntax: the first day, the syntax differences will bother you, and the second day you will forget about them. And then 17 days later you will make one mistake, but then the linter catches it.

Support: getting unstuck with Marko

[00:14:55] Rory: Awesome. I'm going to move on from the learning, because learning isn't always the biggest concern that people have. Often it would be the lack of support. If I go on Stack Overflow and look for a React problem, there are a hundred questions, all with answers, so I know that there's going to be support there should I run into any issues. With Marko, do I have that level of support from a community?

[00:15:24] Taylor: The hard part is that when people are anxious about support, they can be anxious about many separate things. As you said, there's one where it's just, "If I'm stuck, can I get unstuck?" And then there are other things, such as, "Will this be abandoned next year, and then we have to rewrite for nebulous reasons?" That sort of thing. In terms of "can I get unstuck," we do monitor the Marko tag on Stack Overflow. I should probably make it a personal OKR to do that. We also have a helpful Discord and that sort of thing. Because it's a small community, everyone is a little invested in helping newcomers, because it's a sense of identity.

[00:16:06] But at the same time, part of the problem with looking up React's extraordinarily broad Stack Overflow support base, as you put it, is that there are going to be seven answers, and the right one is at the bottom, and all the other ones are vaguely illegal, or they should be.

[00:16:27] Rory: And I guess also, because React has gone through different versions, you're getting the answer for a different version.

[00:16:33] Taylor: Yes. And in many ways, the upcoming capabilities that new versions of React are promising, like streaming or different mental models, might require just as much work and as many changes as picking an entirely new framework, at least especially in terms of data loading, as I think the folks at Qwik found out.

Support: getting unstuck with Qwik

[00:16:57] Rory: We'll jump on to Qwik, then, before we jump into the data loading issue. Actually, we'll take both of those, because I like that distinction you made between "can I get unstuck" and "is this going to stick around." I'll put the unstuck question over to Manu. It's the same question: inevitably I'm going to get stuck. Something's not going to work and I don't know what's wrong. How can I get unstuck?

[00:17:29] Manu: First of all, I agree with Taylor that quantitatively speaking, React will always have more content. Qualitatively, not necessarily. I think Marko has a very strong culture of doing things right from the beginning, and in React that isn't necessarily so. As Taylor was saying before, React is not necessarily slow; it's that the system leads to that. It leads to these kinds of broken abstractions, and that's also the good thing about React. So there's a lot of content, but not all of it is that good.

[00:18:10] Especially talking about Qwik, I think we've already passed an inflection point. The community is booming right now. It's going by itself, and I think that's beautiful when it happens in open source, when the core team doesn't have to respond to every single question, and you just see that happening naturally. It's just beautiful.

[00:18:32] One of the decisions was to match some of the semantics of React in terms of how to author components. Not necessarily data fetching, because that's what most of the questions are about in React, and we have a better solution for that. But the idea is that a lot of the questions can be solved with React knowledge. It's not for everything, but for a big part of it, I think, the things that can get you unstuck, the things that should work in a React component, should work in a Qwik component, even though under the hood it's completely different.

[00:19:13] To give an example, Solid also has JSX, but it has very, very different semantics in terms of the JSX, and that confuses people: it looks like React, but it actually behaves very differently. We don't have that in Qwik. It's not that it's totally the React way, but we can make it look like that for React developers, and that's a trade-off we took. I feel like there is a difference between a beautiful model and something that really makes sense for people.

[00:19:45] When you build a framework, you have to choose one battle. If you want to innovate in one thing, you can't innovate at the same time in all of them. We want to innovate in how to fundamentally deliver JavaScript better, so we don't want to create a new syntax or make everything different. Solid, for example, was about how we get something that looks like React and make it super efficient, and Svelte [?] was about how we make reactivity, so they apply reactivity to everything. It's this purity of different frameworks. In Qwik, I think we took good trade-offs, or of course that's what I think. We really think of real businesses using Qwik, not just an experiment. That's what we have in mind.

[00:20:37] Rory: I love that answer from a product perspective, because you're trying to make changes, but you recognize that if you try to change absolutely everything, it becomes a much harder proposition for people. So just change what you can innovate on.

Will it be abandoned?

[00:20:49] Rory: Just that last one: will it be abandoned? I'll start with Manu and then come to Taylor. How can people be confident that if I invest in it, I get Qwik up and running, and then a year down the line updates stop and the project teeters off?

[00:21:08] Manu: It's a risk you always take. There's this book, Crossing the Chasm. That's why, for example, in our marketing right now, our messaging is not trying to convert older companies, or to get people to move everything. But a lot of companies, even big companies, are coming to us because they understand their problem totally, and they can put something to run, a proof of concept, do some stuff, and see if it really delivers. And it does, because it actually is a problem for them. We're solving a real problem for them. But you have to be on the side of the early adopters, that's for sure. It will only take time to get to the next step, but we need people. We need companies, and especially big companies, using it.

[00:22:02] That doesn't mean that they're going to migrate the whole thing, but a lot of them are saying, "We are trying to migrate lower-traffic pages," or doing experiments, these kinds of things. It's about trust. For us in the company it's a core thing, and Builder, the company that is building this, is going really well. So in that sense, I would not expect that we won't get the resources from there.

[00:22:30] And then it's open source. For example, four years ago I created another open source project called Gin. Gin is a web framework in Go, the Go language. Right now it has 70,000 stars, and it's used at Dropbox, Facebook, it's used everywhere. It's actually the recommendation in the Go language itself, to use Gin. And the open source community is taking care of it. It doesn't really need a company behind it. If the community grows, open source can make that magic happen too. I'm not even working on it, and it's perfectly maintained and things are working. That's also the magic of open source.

[00:23:19] Rory: And from your perspective, is it that open source approach that's how you're trying to guarantee Marko? How do people make sure that if they invest, it's not just going to disappear next year?

[00:23:30] Taylor: Certainly. There are three questions again when people ask that. The first one: we did register under the OpenJS Foundation, for people legally being able to depend on it. But no one here actually cares about that, because I don't think you have a whole lot of lawyers at UXDX. What you actually might be caring about is, how do I know that eBay won't move on, if we are the primary mover behind it? Even if Facebook dumped React tomorrow, people would not be that concerned, because there's a critical mass of the industry.

[00:24:07] One nice thing about that is you probably would not ask me if I thought mice would be around in the future. Similarly, Marko has withstood a number of attempts to replace it, and it's been doing so for a long time. In terms of making sure that there's ambient community support: we could use your help.

[00:24:30] Manu: I want to amplify that. I think it's interesting. I think it's a non-existent risk, to be honest. I think it's more risky that you make the wrong decision at the beginning and then you have to migrate. That's a much more likely outcome. I'm more interested in how mice have withstood a number of attempts to make them disappear.

Why would you not use the other framework?

[00:24:49] Rory: Okay, I'm going to get a little controversial now, because you've both put up good arguments for why to use Marko or Qwik. I'll start with you, Taylor. Why would you not use Qwik? What would hold you back from using Qwik?

[00:25:05] Taylor: I would have to read their docs first, and then I might start building something in Qwik. If you want controversy, my answer is: the people behind Qwik are the people behind Angular, and I don't know about you, but I would not trust a tobacco company to sell me quit-smoking supplements. They have recanted at the altar of performance. That was my joke.

[00:25:28] I would actually prefer that people investigate and use Qwik and see if its strengths meet their needs, and if its weaknesses are not what they care about, because every technology's greatest weakness is its greatest strength pushed too far. There could be an open question in terms of: is Qwik too granular, or does it let you, the developer, do too many things? Because developers want infinite control, and then we're really bad at using it. It's also brand new, so I don't know yet. But I would much rather anyone investigate and kick the tires and choose Qwik or Marko than the current status quo, both for the short-term mental health of our users and the long-term health of the web.

[00:26:18] Rory: Excellent. Quite an altruistic answer there, the mental health of everybody. I don't know if you have the background on who the people behind it are and what their past sins have been, but what would you say to that? Why would you be worried about using Marko, or what would stop you from using it?

[00:26:41] Manu: First thing, I think Marko, or Marko 6 in that case, and Qwik are part of the new generation of really doing something new. I know that for a lot of people it's, "Oh, a new framework, it's the same." Of course you will have to trust my words, but there is something really different here, so definitely check out some of the concepts behind it.

[00:27:08] I would not use Marko because I can't: Marko 6 isn't published, so I can't even check the docs. But I would say that I would not use Marko because I don't want to learn yet another templating syntax and all this stuff. I think it's very, very custom. And I think in the last six years the whole front end has evolved and tested all sorts of different ideas. The current generation of frameworks all tried, "Let's try this syntax, let's try this, and something else." And React is the big thing that actually allowed us to test meta-frameworks, how to do routing, how to do data things. So a lot of things have been figured out, and I think the next obvious step is to iterate on the things that we learned. I think Marko has a lot of legacy that prevents them from looking forward in terms of how things can be different.

[00:28:19] In terms of what you said about Angular: two-thirds of the company is not really Angular. Actually, at Ionic we started using Angular and we had to move out of it big time [?], so we really created a framework so as not to use Angular. We experienced that pain there as well. Not a lot of Angular love.

[00:28:38] Rory: That was interesting, because for one it's the newness, and it's hard to dig in and know exactly where the flaws lie, and then you're saying it's the opposite: it's the oldness, or the legacy that's coming along with it. So they're opposing sides of the same argument.

[00:28:55] Taylor: Right. We're trying to paint the other one's strengths as flaws right now.

Resumability explained

[00:29:01] Rory: Excellent. I'd love to open it up to the audience if anybody has any questions they'd like to ask. Or I have a question: has everybody heard of resumability as a concept? Put up your hands if you've actually heard of resumability as a new concept. I'm seeing a very small handful of hands, so I think there's a bit more of a job to be done on explaining it. The concept is: with the current JavaScript app, you send all of the JavaScript to the client and then you send all of the data over, and it has to read all the JavaScript and then read the data, and then it loads the page. Whereas these new frameworks send the HTML over, and it's only when the user wants to interact with something that it has some smarts to get just that JavaScript to the user, just in time. Would that be it?

[00:29:54] Manu: For me, resumability is not about downloading, it's about the execution. It doesn't execute the code that already ran on the server. It's not really about downloading the code; you download it when it's needed. It's about this: when you do SSR, you render the website on your server. The server has to do a lot of work. It has to run your components, fetch data, whatever, and then it serializes HTML and sends the HTML to the client.

[00:30:27] That's like the server making a cake, but then instead of delivering the cake, it actually takes a picture of the cake and sends the instructions on how to make a cake. Then when it gets to the user, the user tries to eat the cake, but it's really not possible because it's a picture. To actually eat the cake, the client needs to get the instructions first, and the ingredients, make the cake again, compare it and say, "Okay, now for real you can use it."

[00:30:55] Resumability is about how to not have that nonsense. It's really that all the work that was done on the server is reused on the client, without having to rerun it again. I think the concept does make sense regardless of the framework. It's just, "Yeah, that's what it should be," otherwise it's just waste. There are different ways to implement this. Marko and Qwik do this in different ways, but fundamentally that's it.

Big bang rewrite or incremental adoption?

[00:31:28] Rory: Excellent. Does anybody have a final question? I can't see any hands. We have one very last minute, so I'm going to ask a quick one. If I was to do Marko, should I do a big bang rewrite of everything, or should I start on something small? A 30-second answer, if you can.

[00:31:50] Taylor: In this hypothetical question, are you a CEO or are you a developer?

[00:31:52] Rory: Let's go with the developer.

[00:31:55] Taylor: Okay. No, that would be foolish. You would die. Instead, you should do it incrementally. The way I would recommend doing it is you try streaming the outer shell of the page, so at the very least you get the assets in the head to the client ASAP while they're working on it. Then your body can still be a React layer of interactivity, because Marko is zero JavaScript by default. Then you can slowly eat from the outside in, and hopefully it pays for itself the whole way.

[00:32:30] Manu: The benefits come when the framework owns the route for that particular page. In Qwik it's also possible to have React components and stuff, but I would really try to find a way to route different paths and say, "These ones can run under Qwik." Then you run your tests, and if it makes sense, then yes, let's keep investing and making the changes. It's never a good idea to refactor everything.

[00:32:53] Rory: Excellent. Well, I really enjoyed the talk, so thanks very much. If anybody is interested in diving a bit deeper, we have a forum later on front-end frameworks where both Taylor and Manu will be, so if you want to interrogate them or ask questions, I'm sure they're more than happy to oblige.

[00:33:11] Taylor: I have some stickers too.

[00:33:14] Rory: And stickers. Thank you very much, and thank you for joining us.

[00:33:17] Taylor: Thank you for having us.