Paul: Hi there and welcome to Pod Rocket, a podcast brought to you by LogRocket. LogRocket combines session replay ever-tracking and product analytics to help software teams solve user reported issues, find those issues faster, and improve conversion and adoption. Get a free trial at logrocket.com today. We're joined with Yoav Ganbar, who, besides being a speaker, head of developer experience at Builder.io, and the host of his own FEDBytes podcast, Yoav have recently had a blog post title, "Resumeable React," how to ese React inside of Qwik, which framework inside of another framework sounds a little wonky, but we're going to be delving into why is this so powerful and why is this going to be a window of opportunity for a lot developers trying to improve their quality of builds. So, welcome to the podcast Yoav, really excited to have you today. Yoav Ganbar: Happy to be here. Thank you for having me. Paul: What inspired you to delve into this blog post? Because, if people want to go check it out, it's detailed, it really walks you through tutorial about how to set up React inside of Qwik, what urged you to try to get deep into Qwik in particular, because your website's built in Astro, right? Yoav Ganbar: My website is built in Astro, and that is because... It took me a while to get to it, to just build it, and it's a project that I've been procrastinating on for such a long time. And when Astro 1.0 dropped, I started building it and it became a thing, right? Paul: You get into it for you for a few days, it becomes a thing. Yoav Ganbar: Yeah, exactly. So, my website is built with Astro just because that was the hot thing at the time, and this was before I got deep into Qwik and a little bit before I joined Builder. I don't know, it just ended up like that, but I might just rewrite it in Qwik soon enough. Paul: Rewrite your blog post in Qwik, which is... I'm already wanting- Yoav Ganbar: No. I mean my blog itself, the blog site. Paul: Rewrite the blog site. Yoav Ganbar: Yeah. Paul: So, that begs a question for me right away Yoav, because for me, Qwik is not my go-to static site solution. Qwik offers a lot of possibilities of how I could use interactive components, server side rendered components, and stuff like this. Before we maybe get into the React side of things, why at a very fundamental level are you reaching for potentially Qwik to rebuild your blog website? And maybe we can also define what is Qwik for people listening who have not heard of it before. Yoav Ganbar: Okay. Maybe we should start with the basics, right? Let's define what Qwik is. And I'm going to be... Not step on my toes here and just go straight to the documentation site right now. And the way we describe it right now, and at this point in time before we do do an overhaul on our messaging and website, it is a framework that is reimagined for the edge. The idea of Qwik is that you can have instantly loadable applications that have almost zero JavaScript on them. And that is achievable by a pattern that Qwik is kind of introducing, which is the pattern of resumeability. And to understand resumeability one must kind of think... There are two metaphors that work I think best to describe this. So, one is VMs. So, a VM for those who don't know, virtual machine, is a basic way to containerize an operating system with programs and whatnot within it. And on a virtual machine you could start up an application, for example, I don't know, something like Word or Word processor. You could start writing that document and then you could shut down the virtual machine, take that file of the virtual machine, pass it to a different machine, start it up, and it will start from that exact point in time, right at that document without the whole boot up process and everything. And Qwik kind of takes the same approach, but for HTML and JavaScript. It does the work on the server, it serializes all the things it needs, pauses it in time, and then when it goes to browser, you basically start it up from that point in time. So, that is one way to think about it. The second way, which might resonate even better, is to think about it like downloading a video versus streaming a video. So, back in the elder days, this is before Netflix and whatnot, to play a video file, you'd have to go download the file, get the whole file on new computer, and then start it up with whatever media software you're using, and only then you can watch it when you finish downloading. But, nowadays with things like YouTube and whatnot, you have streaming, you can start watching a video, stop it at some point in time, and then in a different machine or a different device, just go and start it from that exact point in time. And what happens there is that you don't have the whole video and then you're starting from that particular time, but you're actually getting chunks of video that are streaming in. So, then you can watch. So, with Qwik, when you think about the JavaScript load, the way it works is you get the HTML, and the JavaScript just streams in when you need it. As soon as you kind of hover over a button for example, that has an "Onclick" function method, then that's particular chunk will be loaded at the time it's needed. However, it's worth pointing out that we already download that chunk beforehand using something that's called "Speculative Model Fetching." So, there is a service worker in Qwik that is in charge of actually knowing what to download ahead of time. And there's a lot of heuristics to it. This is a little bit more of a deep dive later on maybe that we can go into. But that's the basic idea. Paul: Because, at a very high level, Qwik's got to have at least some knowledge of what JavaScript exists at the omniscient high level, so it can figure out... I would assume so it needs to figure out, it needs to generate some interfaces, some types, I don't know what the Qwik version of this would be, but it needs to have some holistic view of what you're trying to present so it can then figure out how to incrementally stream it. When you rebuilt your blog website, when you chose Astro, did you choose Astro... You said it was just like the new shiny thing, you reach for it was really fast. Do you expect to have the same sort of benefits if you were to rewrite it in Qwik? Would you be reaching for the same advantages? Yoav Ganbar: There would be the same advantage because [inaudible 00:06:47] of Qwik is it doesn't... It blurs the barrier between SBA, MPA, and static generation. You can do all of those with Qwik, and you wouldn't have to think about it too much. That is one of the beauties that I see in Qwik right. The X is just there. So, it does support the same kind of things that Astro does. So if you write a markdown file, MD file, or MDX file, it'll just write right out in the route according to how it works. And again, it's worth mentioning that along with Qwik, there's Qwik City, which is the meta framework that holds all the stuff that are in charge of routing, bundling, and splitting into the chunks themselves. So, with Astro, what I was going for was having the ability to use different types of frameworks within my little blog application. So, just to be able to play with it, that was the general plan. Paul: Because, in Astro you could do that, you could use Vue, React, and whatever. So, you were really wanting to try that features. Yoav Ganbar: Yep. That is what I tried. But, the difference between Astro and Qwik on that hand, which is it's that Astro in the end, what it does, it's in charge of just a server phase, right? It renders HTML from React, or from Vue, or from Angular. But, as soon as you want interactivity, then the framework itself needs to go and hydrate itself on a client. So, there is no escape from that in Astro. Paul: You're still beholden to the framework core code loading and being sent over you're saying? Yoav Ganbar: Exactly. Unlike in Qwik, which is in charge of the whole rendering on the server and on the client. So, when you use React Qwik, which is what I wrote the blog post about, it does not necessarily have to let React load on the client in order to work. It'll render the HTML, but then you could wire it up to either use Qwiks fine grained Reactivity, which is signals, or you could let React hydrate according to different directives, similar to Astro. And similarly to Astro, when you do that, that is actually an island like Astro has when you have each little piece from different framework is an island by itself. Paul: So, it is the same idea. We still have the same mental abstraction of islands with Qwik, but the paramount distinction here is the heavy lifting of React can be done on the server, and as a result, ideally, you're not going to need to send over the entire React framework code over to the client. Yoav Ganbar: You don't have to. It's your choice. That is a little kind of thing about it. You have control over it. You can either say, "I want to hydrate this and let React internals take over," or, "I'll just use Qwiks methods to actually gain Reactivity and change detection through signals. But, I don't need the React internals." So, I dive into this a little bit in the post itself when I have a Material-UI component that is from React, which has a ripple effect that is through JavaScript. For those who don't know, Material-UI is built with a motion, if I remember correctly. So, that's a CSS and JS solution. And for it to run, it needs React to run. So, the ripple effect is something that only happens when you have an "Onclick" event on a button. But, in order to kind of activate that, it needs the actual React code and the hydration process to get there. In my blog post, I have a demo in between having only Qwik be in charge of rendering that same exact button but not hydrate React, and another one that does hydrate React. So, the one that doesn't hydrate React will not have that ripple effect, but it will have the functionality of adding an "Onclick." Paul: I was just going to ask, so there's a bunch of different directives that you went over in your blog post too, which to me felt slightly more powerful when I look at Astro's directives. I'm a very basic web developer personally. So, for me, what Astro gives me is more than enough to do everything I might need to do. But, in your blog post you went over, I could load on hover, I could load on if something's in view... Something in view, I think Astro has added as well. But, there's two different types of directives. There's the client directive, and then what was the other one that had to do with the hybrid rendering life cycle? Yoav Ganbar: So, there are a few strategies, like we said, in Qwik React, you could either load it once the document loads, or you can do it while it's visible, or while the browser main process is idle, or on hover. But, there are also three other strategies, which is you could render only when a signal in Qwik is actually a boolean is triggered to be true. Or you could trigger it through some sort of custom event. Or you can just say, "I want this always to be rendered on the client and hydrate on client." And to my recollection, in Astro, they have also kind of client load- Paul: Is visible is another one. So, when we're installing React into Qwik, it's also similar to Astro. And I'm always just comparing this to Astro, because I think they're two very compelling cousins even though they tackle a different use case sort of. So we'll do Astro Ad, and it's the same thing in Qwik. In your blog post you sort of walk through it's one command, you can add the React. Yoav Ganbar: Yeah. So, integrations in Qwik are inspired by Astro in that kind of manners, that you could just, if you want to add React, you just go, "Qwik, add React," or if you want to add Tailwind, it's, "Qwik add Tailwind." And also for our deployment integrations, for example, with Vercel and Netlify, and all the rest of the adapters, we also have for CloudFlare, we have one working for Azure soon, and coming up with GCP and the rest. So, you just go and just say, "Qwik add Vercel," and you get whole thing ready up and set up for you and wired up. So yeah, there's a big emphasis on developer experience, and why not stand on the shoulders of giants and learn from the best. Paul: Yeah. Who's the best Yoav? That's like your Meta Framework podcast over at FEDBytes. People want to listen about who's winning. Yoav Ganbar: Yeah. Paul: I love that question about who won. I don't even know. That's a very obscure- Yoav Ganbar: It's an obscure question, and I don't think the answer is definitive. And I think the web developer community is winning generally, right? Because, we have great options nowadays. You have so many great options, so many great meta frameworks out there, different flavors and ways of in and building web applications. And like anything in software development, there are trade offs, and there are pros and cons to every choice you make. But most of the choices nowadays are not choices that are going to get you fired as a Dan Shapira said on our podcast. So, winning, again it depends on how you define it. That is kind of what we got to the conclusion, is what is it a winner right now? Is it whoever has most market share, is it the number of websites that have... The framework that has the most website built with it now nowadays? So, if that were the case, then WordPress is winning, right? Because, still more than 50% is using WordPress. Paul: On your podcast you say like, oh well a lot of people have been doing WordPress sites for a while and it's been around for years. So, naturally there's a lot of WordPress sites. On the flip side of that argument though, there's still tons of people making WordPress sites. It's just never going to go away. It's ever popular. And I think that I love that you highlight, we have options as developers, it's the community that's winning. It's empowering to think about us having a choice and that choice being okay and not black and white. Yoav Ganbar: No, it's never been better to be a web developer nowadays. I am thinking going back eight, 10 years, it was much more... I feel, again, there's some people that say that today web development is more complex than it was. But, I don't know if you remember JavaScript fatigue in 2017 and all that fun stuff, and every framework coming around, and taking a different take, and then it looked like it was too much. But nowadays, people look at... Again, this is my experience. Now when I look at it, I said, "No, this is great. We got a lot of options and a lot of different ways of doing it, which is fantastic." So I don't know, Svelte is awesome, React has always been a shift forward compared to what Angular was. But now we have signals coming back that were cool back at Knockout days and Backbone and whatnot. Paul: Backbone, I haven't heard that one in a while. Yoav Ganbar: Yeah. I didn't get a chance to work with Backbone. But yeah, just yesterday, Misko Hevery, who was the CTO with Builder, and the brains behind Qwik, just put out a post of his kind of journey in the history of Reactivity. So, he went down the line in all the different kind of frameworks that he went through while building Angular until he got to Qwik. So, he did the Touch upon Backbone, and there's some code there that are written, and it doesn't look that much different than what we have today for reactive languages or libraries, right? It's just interesting. Paul: We actually have an episode with Misko where we step into the basics of Qwik, if anybody wants a longer Qwik centric episode, like go check that one out. I'm just going to take a quick pause here to remind listeners that Pod Rocket, our podcast is brought to you by LogRocket. And LogRocket, it can really help you be a better web developer, because it can help you understand exactly how your users are experiencing your digital product, your website, your complicated DOM tree, no matter what it is. There's session replay, error tracking, product analytics, frustration indicators. And we have algorithms in AI that surface the most impactful issues affecting your users. And you can spend more time building, experimenting, checking out libraries, rather than hunting through tools. So, solve user reported issues, find those issues faster, and improve conversion in adoption today with LogRocket. All right, so moving back on to what we were talking about, Yoav, you are right now developer experience at Builder.io. Misko, he's heading Builder.io as well. What does Builder.io do? Yoav Ganbar: Builders product is a drag and drop editor, which can connect to any front end stack. And that is cool if you ask me. And the way that I- Paul: Yeah, so it can connect to any of them? Yoav Ganbar: Any of them. And this is done by the help of another open source project that we maintained called Mitosis. And Mitosis is what helps us build our SDKs. And shout to Sammy Jabber, who is the one maintaining most of our SDKs and maintaining Mitosis. The general idea of Mitosis is you write JSX and it compiles to every kind of framework. So, it spits out Angular components, React, all of them, Stencil even, web components, you name it, it does it almost. And another cool feature of Mitosis is it has two different kinds of syntax. You could write JSX or you can write its Sveltosis style, which is the spelt kind of syntax, which is a community contribution that was made not recently ago Paul: Because, Svelte has a whole other rhythm to the way you go about and write your code. So, I guess, it- Yoav Ganbar: Yes and no. I don't know. When I tried, it's similar to the old days of just having HTML, CSS, and JavaScript in the script tag. But, you could put it in one file, or you put it in one file in a more cohesive way maybe. That's from my experience again. Paul: So over at Builder, I feel like you're solving a developer efficiency and organization problem, because we have Mitosis, we have this way to create framework agnostic components that can be compiled down to React, Vue whatever. And now, we're coming out with your blog post where it's, "Okay now that you have your React components, here's how we can use them in the fastest way possible using Qwik on the web." And there's this whole end-to-end solution here for running a development team that you guys are coming up. Is that sort of the direction that Builder is moving in where it's marking your space in the developer community? Yoav Ganbar: Builder.io, it's trying to solve the problems for developers and which are are users of it. So, we have Qwik for handling first party code to make the best, fastest kind of website or app that you want to build. We have Partytown that is another open source library we maintained that was built by Adam Bradley, one of our heads of engineering, who's also behind Stencil Anionic. And he built Partytown, which is a tool to tame your third party scripts by moving them onto a web worker, and then by that freeing the main thread, and helping you perform better. So, seeing those lighthouse scores shoot up by just putting Partytown is quite an experience I got to say. And then we have Mitosis, which is to generate all the code you need for different frameworks. And you have Builder, the product itself, which is for handling first party content, but not only that, it also take off some of the overhead that developers have from their marketing team or product managers that might come to you every Monday and Thursday saying, "I want to change that homepage text from 'Buy Now' to 'Order Now.'" And then that goes in, and there's a ticket, then you need to push code to get it to run. Then with Builder, you don't have to do it. You can kind of say, "Okay, this section inside our app is going to be controlled by our content team, or by our marketing team, or product manager, whoever, even a developer," and what you put in this content section can be just components that you drag and drop. And we have built-in components and Builder that you can drag and drop for images, a text, and whatnot, all the regular stuff. But, the coolest part is you can actually register components from your own code regardless of the framework you're using, and register them to the Builder UI, and then give control to someone to drag and drop your components that you built as a developer inside that section. So, in that section can be as small as you want or big as you want. And on top of that, we are also a CMS. So, you could also manage your data there. And it's kind of the trifecta of it all. I don't know about you, but I've worked on a lot of content heavy sites in my day, and I've always... And any developer that has worked in this space I think has thought at some point, "How about I just build my own CMS?" Paul: Yeah. Yoav Ganbar: And- Paul: It's always an easy thought at first. Yeah. Yoav Ganbar: Exactly. But, it's much more complicated than you think. But for me, when I first started using Builder, and this was before I worked at Builder, so before Builder I worked at Fiverr and was building a product and- Paul: Fiverr, the e-commerce place? Yoav Ganbar: A marketplace for freelancers, yes. Paul: Right. Yoav Ganbar: And when I hooked up Builder, I was amazed by how easy it was to hook it up. Second of all, how easy it was to give control over to someone else, how much headache it took away from me. And it had all the features I wanted as a CMS. And that really made me kind of fall in love. And then later on that kind of led to me in joining Builder. Paul: Do you feel like there's a generally optimal setup of how we can develop a content rich website that for 80% of cases is carried between teams? And I'm thinking, you have an external CMS that is hosted by a service somewhere, and it's good to have that, it'll never go down, you know, don't have to think about it. So, you have some CMS, you have some WYSIWYG, or visual editor for your non-developers to work on customer facing material. Then you have some trans-file compilation process, and then you have some sort of meta framework and framework hosting your site. I feel like that's a very common setup that we're starting to see across a variety of sites. You like using these paramount features. Do you think we're going to start to see that having a more and more congruent setup between teams? Because, even if I go from one startup to another big company, there's still differences. And I almost feel like we're starting to develop this sense about like, "Here's the best way to do it." Here's always differences between teams or differences between marketing teams, but in general, "Oh yeah, we will use a hosted CMS. We're done trying to mess with building our own." Are we getting to that stage at all? Or are the teams always going to be pushing the boundary thinking, trying to rebuild the CMS problem? Yoav Ganbar: I think that developers are always going to try and figure out and solve problems, even solved problems, just because developers are opinionated people, and there's always someone that thinks he might do a better job than someone else. And, I think, also that is a core to technology innovation, is always even trying to solve something that's already solved, but maybe you're tweaking it a little bit more and making it a little bit better. I don't think as a community, we'll come to a point that we're going to agree on something completely, because otherwise we'd be still just writing jQuery all day, or whatever, or still using building sites, using WordPress. Because, if you think about it, WordPress is a great solution. It gives you most of the things you need to build a website. It gives you also tools for non-developers to kind of work behind the scenes and enter content. It gives you a UI, you can host it anywhere. It works. So, why isn't everybody using WordPress? Because, people expect a little bit more, because WordPress has its problems. There's no such thing as something without downfalls or trade-offs like we've mentioned before. But nowadays, I think what developers are looking for is much more having a good experience building something and being able to iterate and build faster in order to get better UX for their users. But, there has always been this kind of tug of war between DX and UX. Every time there was an improvement in DX, that made developers maybe build some more things or add more into activity, and that kind of hurt the user experience. And then another framework came and maybe kind of fix that little problem and made rendering a little bit faster or added server side rendering, and that made perceived performance look a little bit better. And it's always this tug of war, but it's an upward trajectory. That's how I see it. And with Qwik, for example, I see that we're converging and something that is great DX on one hand because the way you work with Qwik is you don't have to think about things like performance, because it's performant by default. That is what we were going for. That is what Manu, and Adam, and Misko have been tirelessly working on is making it like something you don't have to think about. It's really hard, if not almost impossible to write bad performance code with Qwik. And just because of the way it works and the foundations it lays on, right? Because, other frameworks at this point, it doesn't matter. The more you add features, the more code you generate, the more JavaScript you're shipping down the wire, it exponentially grows. With Qwik because you have resumeability and you serialize everything into HTML, and you only load the chunks you need, you can kind of achieve an, "0 of 1" framework, which only loads when it needs. So, it doesn't matter how many features you add, you're always going to have a performed app. Paul: Because, we're streaming it, essentially. That's how I always get brought back to that mental model of I'm streaming my app over as needed. And I think another cool thing, just to bring us back to the blog post Yoav, is you even point out the power that V gives your render to React. And I think the blog post is a really great place if people want to start taking that next step into using a meta framework or if they want to start figuring out what is the newest and greatest in developer experience, this is it. Like, "Go run that one command, put React into a Qwik app, follow Yoav's blog post." And I thought it's really cool at the end it's kind of like... Oh yeah, because you point out, you can load it this way, you can load it that way. And at the end, all of this still works under V. We still have a small single file bundle at the end. And yeah, it's just exciting. We're opening up the opportunity for somebody like myself who might not be a web only developer to make a fast website without shooting myself on the foot and not having to think a lot. Yoav Ganbar: Exactly. So, if someone is not an experienced developer, and then he picks up React. So for example, someone that's a fullstack and does mostly backend stuff, he picks up React, and then he learns about hooks. So, I can write something. And then he writes this very complicated component or application, and then rendering starts to lag and all that. And then he shows it to someone that knows React. And he is, "Oh, you didn't use Memo, and you didn't do use "Callback," and you forgot to Memo-ize your functions." And then he's like, "All I did was write some code in the click of a button." What I envision is a good future for the web is reducing the number of foot guts that we can have. Because, there is so many things that can go array when writing applications and websites. And if frameworks, and libraries, and the tools we're having are creating maybe new problems, maybe it's not such a good way. And again, I have to say I love React. I've been a React developer for many years. And it has been a paradigm shift in the industry. And it has done amazing things. However, nowadays I sometimes really have this point where I get frustrated so much with all those things you need to remember when you're writing React that I say, "Maybe I don't want to write React anymore." Paul: Yeah. Or, "Give me some help to write it." Yoav Ganbar: Yes. Paul: Yeah. Yoav Ganbar: Give me some help. Give me better lenders, give me better tools that'll actually already do this. But yeah, it is how it is. Paul: Yoav, thank you for your time coming on, and putting out this blog post, because like I said, for anybody trying to step into Qwik for your first time you're in React and you want to figure out, "I don't want to have to remember Memo... Or I don't want to go crazy on making the website super performant." Go check it out. Resumable React using React inside of Qwik. And Yoav, if people wanted to follow you and learn about more blog posts coming out, more tutorials, you do have your personal site, which we mentioned at the beginning, which is currently written in Astro, you might rewrite in Qwik later. What about on Twitter? What's your handle if people wanted to follow you? Yoav Ganbar: So my website and my Twitter handle is Hamatoyogi, spelled like it sound like, but H-A-M-A-T-O-Y-O-G-I. And my website is hamatoyogi.dev, and that's my Twitter handle. There is a story behind the nickname, so if you want to ask, just ask. I've tweeted about it once. Expect much more things coming out in the Builder blog, which is my main focus. I have not put out stuff on my personal blog enough lately. I'm hoping also to make a lot more cool demos with the Qwik React, and show you that you could also use Framemotion within there, and other cool React libraries. Yeah. That is my plan. But again, not enough hours in the day. Paul: Never. But we're going to expect some more potentially React centric, Qwik centric, post coming up from you in the near future. Yoav Ganbar: Yeah. I think that something I'd want to focus on is a scene, how maybe we could show a migration pass from React to Qwik. So, having either a way to quickly start a Qwik app and have maybe a map of how you'd transfer a whole React application into a Qwik application. Then slowly chip away and take certain pieces you want, or certain pages you want of React application and just move them to Qwik, all by being very incremental and you could just use React Qwikify for certain things, when you're ready you could move them to Qwik. So, that's something I'm thinking about. Paul: Thanks again, Yoav. Yoav Ganbar: Thank you for having me Paul.