0:00 Up devs feeling the strain. Headless browsers causing you pain. Memory hogging oh so slow. Got your automation losing its flow. Scraping sites quickest headless you've ever seen. Yeah. It's the Rawkode stream. Tune right in. Got Pierre and Katie, let the show begin. Introducing LightPanda. Yeah. Built with six so keen LightPanda. Woah. The fastest on the scene. Let's ram more speed. A developer's dream. Live on Rawkode. Join the stream. Forget the bloat, the startup lag. Light pandas here, it's in the bag. 10 times faster light on the RAM, open source of power, part of the plan.

1:07 See the live demo, watch it blast, and get the quick start, make your scripts last. In the banging J and S game, it's the Rawkode stream to Riot in. Got Pierre and Katie, let the show begin. Introducing LightPanda. Hell. Built with zigs so keen. LightPanda, the fastest on the scene. Less RAM, more speed, a developer's dream. Live on Rawkode, join the stream. Plug in puppeteer, play right to. Your old code, swap the engine through. Hear the road map, what's coming next. Making machine browse less complex with Pierre and Katie right here. Light panda's future is crystal clear

2:00 on Rawkode Academy. Learn and Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, sometimes known across the Internet as Rawkode, and this is an episode of Rawkode Live where we take a look at the coolest cloud native and adjacent software projects, particularly open source, to make your life all that little bit easier. And today, we're taking a look at a new browser on the scene. This one, a headless browser to make your tests and AI workloads faster. I am joined by two members of the LightPanda team, Pierre and Katie. Hi there both.

3:03 How are you? Hey, David. Hello. Good to be here. Yeah. Yeah. Welcome. It's an absolute pleasure to sit down and have a conversation and take a look at interest in tech. It's always the absolute highlight of my day. So before we talk about LightPanda and what you're building, can you both take a minute just to say hello and introduce yourself to the audience, please? Sure. So I'm Katie. I'm the co founder and COO at LightPanda. And I've known Pierre and our other co founder, Francis, for the last eight years. We worked together before in our previous company where we

3:38 were doing a ton of web scraping. And LightPanda was born very much from that pain as we'll have time to talk about. Yeah. Hello. So I'm Pierre. Nothing more to add really. I'm the CTO. Happy to be here and happy to show you what the browser can do. Awesome. I think this will be a great episode and interest in technology. This is something that anyone who has built a website or built any kind of web screen or, you know, things that need the browser to do whatever they're doing. I felt the pain in Puppeteer and Playwright. And it's not that those are

4:17 not great tools. It's that the underlying browser technology, headless Firefox and headless Chromium. In fact, all Chromiums, headless or not. Right? They are a sucker for our CPU and their memory consumption. And I think it's nice that we get to take this opportunity to see what you've been building and hopefully make this a lot easier for everyone else. Now I know that we have some slides. Katie, if you wanna share those up and we can, you know, dive straight into it and talk about Panda in more detail. Yep. Sure. That again? Yep. I can see the LightPanda logo. It

4:53 is awesome. Please take it away. Alright. So, yeah, I'm not gonna take too much time on this part, but we just wanted to give a little bit of background on the project and how it was born, how we're thinking about the space that we're building in. So I mentioned that we all worked together in the past and we were doing a bunch of web scraping. And web scraping has been around for a really long time. So if we look back to the very first web pages, some of you may remember them. They were way more basic

5:31 HTML type web pages. Today the internet and the web is really a dramatically different place where you have full applications running within web browsers. And so the web browser itself has had to massively evolve to support that transition. Two thirds of the traffic today goes through Google Chrome and Chrome is running under the Blink rendering engine, which was developed in 2013 and is actually a fork of WebKit, which is the rendering engine behind Safari, which itself is a fork of KHTML, which is the engine behind Conqueror, which is now deprecated. So as you were saying, there's nothing fundamentally

6:22 wrong with this code. It's just not at all built for the automation use cases that it's now being used for. And there is now a need, we think, for something fundamentally different. The web browser itself, this is the kind of architecture of a standard web browser that humans would use your own or desktop or our phone. Essentially, without going into too much more detail here, a collection of different elements that enable a human to interact with a web page. There are hundreds of web APIs and more and more developed every day to support the increasing

7:05 complexity complexity of the web. And so we were talking about scraping 50% of the traffic that goes to the web today comes from machines, and that's not a new phenomenon at all. It feels like we're talking about it a lot more at the moment because of AI use cases, which are coming to the fore, but it's actually been that way for the past five plus years that it's been half the web traffic. And that's coming predominantly from things like indexing for SEO, more traditional scraping use cases, like what we were doing at our previous company, which was an e commerce

7:48 kind of intelligence platform where we were scraping retail product pages. And then obviously everything that's emerging now around AI, so extracting data to train models, chatbots that are calling the web in real time to provide information to users and agents, of course, as well. And so when we think about how we automate the web, just as the web pages themselves have changed the way that we automate it and the tools that we use to automate the web have changed as well. Back in the 2000s, you could just do a simple HTTP request or a colon, it would be enough to

8:36 get the vast majority of data within a web page. And the problem that we're faced with now is that there is JavaScript absolutely everywhere all over the web, probably somewhere around 40% plus of the content on the web lives in JavaScript, and you can't access that content unless you have a web browser to execute the JavaScript. And so that's the kind of hack, I guess, that developers are living with today, is they're using what's called a headless web browser. So essentially all the same architecture under the hood, just not the GUI, the graphical user interface

9:17 that humans see, but everything else exactly the same. And you can use these testing frameworks that you may recognise are on the side puppet of PayWrite or Selenium to programmatically control a headless web browser. For the large majority, it's headless Chrome, and that kind of does the job, quote unquote. But we think that, and having done this at scale in our previous company, we were scraping around about 20,000,000 web pages a day, and we really felt the pain firsthand of that. For about 90% of our use cases at the time, we didn't need this block of

10:00 the rendering engine on the left hand side. And so that's really what we're doing at LightPanda. Is just an interesting quote actually as we start thinking about the AI use cases that Vercel published at the end of last year saying on their network, all of these major AI crawlers, firstly, they represent about a third of Google bots volume already. So that's huge when you think that they didn't exist a couple of years ago. And also none of them are rendering JavaScript, which is we can assume because to run a real web browser at that scale is computationally just

10:40 super expensive. So yeah, this is what we're doing at LightBand and we're gonna go into it way more in-depth, so I won't spend much time here, but we've removed the rendering engine on top of the GUI. But we have, other than that, a full web browser with all the rest of the components that you see here, including JavaScript execution and a CDP server, which means you can plug it into the puppeteers and the playwrights of the world. We launched our beta at the end of last year, it is still in beta, the first results show that

11:19 it's 10 times faster and uses 10 times less resources than headless Chrome. And that is effectively a multiplication because with the same amount of resources, you're able to do 100x more with LightPanda than with Chrome. So that's us in a nutshell. I'm gonna stop sharing now, and we can dive more into it. Great. Thank you. Look. The AI traffic is obviously super pertinent right now. Now I've got a whole bunch of domains because I'm just one of those developers, and some of these domains have never had anything on them or haven't been updated in five plus years.

12:01 But my HTTP server logs show that my traffic in those last five years has increased substantially. Like, these unknown domains I don't use for literally anything are getting tens of thousands of hits every single month. And I can imagine there's not one real human there. And that's not even domains that are, like, the rock of the kind of website or maybe the news. Things are updated on a near daily basis. They're probably getting scraped much higher intervals because there's context there. That's how these AIs, whether it be AI search engines or model training, etcetera, stay relevant. It's

12:37 just that I'm in a traffic alone. I think at this time being prepared I mean, it didn't really exist beyond Googlebot, like you said, more than five years ago before this AI. Just bewilders me. I can't believe this is where we are today, but at the same time, we use AI every single day as well. It's been part of the problem, I would imagine. But it it it it helped. I'm curious about building your own engine here. And, obviously, there are a whole bunch of web engines that exist. There's there's Chromium. We know that's slow. There's Gecko from Firefox.

13:08 I think it's, you know, a lot of legacy code also quite slow. There was the server spin off project from Mozilla, which I think now lives as an open source project. I know the Ladybug browser team are building their own engine. Now, obviously, Servo and Ladybug are built with the rendering engine and the fact that there will be a UI in front of it. It's a a consumer engine. But I guess the question here is, what's different about building a browser without a rendering engine and what you know, I'm assuming there's trade offs that you're able to

13:42 what's the word? Take advantage of because you're you're cutting out this bit. It makes it I don't know if it's easier to write word or just better, but let's go into that in a bit more detail. Tell me why you build your own engine instead of using the cloth shells components and what you can do better because of these constraints. Well, obviously, it's not easy to create a browser or to write a browser from scratch. That's a lot of work. But at the beginning, we would prefer to just take, let's say, Chromium and remove the rendering parts and just

14:22 using it to, well, run what we want. So don't rewrite from scratch and remove just the rendering. But the issue was it's not really possible because the rendering elements are everywhere in the code, in fact. Everything you are doing, it's related to the rendering. So you can't just cut it simply. You have to almost change in every layer in the browser to remove the rendering things. So it wasn't really possible to do that simply to do a real headless browser. So as Katie said, by headless browser, we say that we will not render graphically the web page.

15:20 And that's something which is done by Chromium even with the headless options. So the rendering is done in memory, it just never display in the screen. So all the work is done. In fact, that's why you can do screenshots or PDF with Chrome headless. The idea for us, it was to just avoid all this work and that wasn't possible using an existing browser. It's the same. So Servo, as you said, is a rendering engine. So it was the same. Everything was merged everywhere. But also the ladybirds do the same, exactly same thing. So everywhere in the code you have rendering code to

16:10 remove if you want to change that. So that's why we started from scratch, in fact. Also, Sorry. Go ahead. Can clarify something? So I just wanna make sure I have a good understanding of this in my head. Right? When we're talking about rendering engine, I'm assuming there's still a DOM and the JavaScript is still run and the DOM is manipulated, but there's no there's just no visual representation of that. Right? That's how you're able to, you know, run Gmail or whatever. And while you click on buttons or see anything, the the DOM is being manipulated. You can

16:41 fetch data. You can run tests against assertions and all of that other really important stuff as well. Yes. Yes, that's the goal. Yeah. We want to take the difference between us and let's say, curl is that we want to fetch the HTML, the raw HTML, and then fetch all the resources, the JavaScript resources, and be able to run the JavaScript of the page. And then what we render, in fact, is the final HTML. So the HTML, the DOM, which has been modified by the JavaScript. So we want to execute XSHARE, change, update the DOM, create the new HTML tags, etcetera. So we

17:26 don't do graphical rendering, but we do actually execute the JavaScript and generate the final DOM of the web page. Okay. And are you building your own JavaScript runtime as well? Are you hooking into V eight, spider monkey? Like, what what's going on behind the the hood there? No. No. We are we are using v eight, actually. So it was well, yeah. We we want to do the minimum work we can. So reusing existing JavaScript engine was the simplest things to do. V eight is used by many user projects and well integrated. It gave us an idea on how we

18:18 can bind ourselves to this JavaScript. And in fact, it's a really important element in the browser but we are trying to stay the most decoupled from the JavaScript engine we can because we have the idea maybe in the future to be able to unplug V eight and plug another JavaScript engine. Let's say we would like to be able to plug QuickJS, for example, which is the smallest JavaScript engine, but in full C, which could allow us to maybe have a smaller binary in the future, which is something which could be interesting depending the use case we can

19:13 offer, in fact. But yeah, yeah, it is the main element. All right. We do have a question in the chat, so I'm gonna throw it up just now to tackle this one early. But PyTraderDetective, wonderful name there. Heard us mention Puppeteer, Playwright, and Selenium, and they're curious which one is most compatible with LightPanda. And I'm gonna push that a bit further and let's not I mean, like, we can talk about compatibility, but used to know this space. So let's get some opinions. Right? Which which one would you use and why? Which one? I my personally, I've I I'm more a

19:51 Go developer and I prefer to use a Chrome DP, which is a Go client for the CDP protocol and to control the browser. So I'm more But now, in fact, if I have to pick one, will take Perpetr because Well, to answer the question, we are the most compatible with Puppeter actually. We are working on the PreWrite compatibility but we have issues mainly because, well, to control the browser, Puppeter and PreWrite are using CDP protocol, which is the Chrome DevTool protocol, so specific to Chrome. And this, well, Chrome exposes a CDP server, which is a WebSocket HTTP server in the sole. And

20:58 so you can send a command on it. But the Chrome DevTools protocol allow you to achieve some actions in different ways. You can run big chunk of JavaScript doing what you want, executing in the browser in the context of your page, for example, but you have, obviously, specific commands you can run on the CDP. There are a lot of commands on it possible. So depending on the clients, can have to do the same thing. You can have many strategies. So currently we are more competitive with Preparator, but Playwrights, we have issues in fact. And Selenium,

21:47 we don't support it for now at all because it doesn't use CDP at all. It use web driver, which is another protocol. Maybe we will implement it in the future, but actually we don't. Yeah. I mean, just to I mean, I I'm not super knowledgeable on this space. But, you know, unless you're still running Jenkins, Selenium probably isn't the option you wanna be going with. I think it's very embedded in older Java systems. I can this is my perspective. Puppeteer is obviously the one that spun out of Google itself, I believe, and Playwright is what Microsoft decided to try and improve upon

22:23 it. So, you know, if you pick whatever one you like. Yeah. Puppeteer is the one I go to. I think it's when you need help, which I often do. The examples are all online for Puppeteer, and I like that. So And Puppeteer is lighter. As far as we know, Puppeteer is lighter, and PrevWrite send bigger JavaScript, more complex things. I think it's mostly because they try to be competitive with more browsers than Puppeteers because you can run, you pre write scripts on Firefox too and some of the browsers. I know. So I guess that's why

23:02 they have a different strategy using more JavaScript with big scripts executing what they want. All right. Awesome. All right. Let's change tack a little bit before we get onto the hands on demo, which I'm sure people are excited for. But, you know, you've given us a bit of history. You both worked together now for eight years. You just were doing, I think you said, 20,000,000 web page scrapes at one point. I don't know if that was daily. I think you said daily. Right? Yeah. So I'm curious, obviously you've been in this space for a while.

23:34 You've now got a new product. It's open source. Do you have a history with open source? Why did you go down this route? Especially for something that is not not not anyone could just sit down and go, hey, I'm gonna write a new headless browser. This is a very hard challenge, a large project. Why do it open source? I'd love to learn more as well. I think I'll I'll start and then, yeah, add anything you want. But I think, very simply, the the de facto solution today is Chrome and headless Chrome is open source today.

24:13 To disrupt a space that's so well established and offer something that isn't open source is making life even more difficult in an already difficult situation for one. And then I think just all the kind of classic benefits of an open source project. I mean, our target market is the developer community and we've already had some amazing contributions to the project and Zig community from, since we launched kind of properly the beta version ended last year. So I think we've seen that firsthand despite obviously knowing it in theory beforehand. Yep. And if I can add, think

25:03 the two things are as we were a potential user of LightPanda and we will never even try it if it was closed source, I think. So that's the main reason. But also because we are under development, active development right now, so the browser is not really actually or in some cases, not all, obviously. So it's maybe more understandable for users to have some things not really or not perfect to use or to try because it's open source instead of you if you get the closed source browser, you expect to have something which is just working.

25:57 And so that's another point also. Yes. Alright. Last question. I'll keep it light so we can get on to the hands on component. Give me the history of the name. What is a late panda? Well, it was mainly because it was brainstorming. We had some ideas, but LightPanda was the coolest. At the beginning, we had Had a benefit of having a lot of available domain names. Yes. Also the Not a bad way to do it, right? The Firefox, I believe is a red panda. Yes. Which is also known as a light panda. No, it's just

26:50 a red panda. Yeah. Is that right? Yeah. Yeah. It's quite fun to play around with the mascot though. This is my latest creation. I don't know if you can see. Alright. Awesome. Thank you for sharing. I think we should show people then what LightPanda is, how to get started, what it can do. So, Pierre, if you could please share your screen and we will take a look. Sure. So do you see my screen? Yeah. We do now. Thank you. Take it away. So as I said, we are under heavy, heavy development. So we don't have actually

27:41 a release tag, but we are building the browser every night. So you can get the last version on the nightly release on the GitHub repository where you can, well, just download the last version of the browser. So I will do that. Yeah. So now you just have to allow execution on it. You have two currently, you have two ways to use the browser. The first one is just a way to fetch a web page in your CLI and like you will do with but at the difference of with curl, we will fetch the HTML and execute and fetch the

28:55 resource, the script resources and then execute the whole JavaScript. So I'm using right now a local web page we are using to demonstrate the browser. So that's a fake e commerce page, a product page. So we can try it by using, like, Panda with the fetch subcommand. And then I will just add the dump option to ask LightBandA to write the final HTML in the standard output. And what I will do, I will save the results. Oh, sorry. I forgot the URL, of course. And I will save the HTML in a file. And it doesn't work.

30:07 Interesting. What I do wrong Is my ah, okay. Sorry. So let's start from the beginning. I will start my web server. It will be better. So into my demo, I have a a Go web server. Sorry. Okay. So okay. Better. I will try. Okay. Good. So here we can see in the log well, we have oh, yeah. Sure. Let me do that. No. No. How can I do that? Come on. Okay. Is that better? Okay. So here, yeah, what we can do is we have a telemetry just to, well, to have feedback from binary usage,

31:32 but you can disable it using an env variable. And then we have the log. So the first log is to fetch the first web page. And then after getting it and parse the HTML, we get the browsers fetch the external resources. So here we have a script. Js we want to execute. And the script. Js also do some XHR request, want to get reviews and want to get products details. So if I look at the results here, Yeah. So here I can see the results of what we fetched. So we didn't have the CSS display here, but we have all

32:46 the information we wanted. So here we have the the product name and etcetera, the things, the reviews also. So we get the final HTML with the the JavaScript results on it. In comparison, if I do the same with, let's say, curl. So in that case of it, curl only dumped the original HTML. So it didn't, of course, run the JavaScript. So we don't have the etcetera changes loaded. So that was the first example. So first way to use basically LightPanda. And the another, I will say, classic way to do that is to use the CDP

33:54 server. So let's try that. So if I have Here in demo, I have some preparatory scripts. One of them is CDP. Js. So this preparatory scripts will just run some load of the page to test it. So it connects to one browser URL to the CDP server. No, sorry, it's different here. So it connects to the WebSocket's CDP server on the browser and fetch the web page here, which is my local server here. And by default, it does the fetch 100 time. So nothing fancy. It's per picture. We have just a loop here. And on

35:01 each loop, we create a browser context, which is basically a tab in the browser. And then we navigate into the product web page. And we are waiting for the product price. Yeah, we are waiting for the product price and get it, if I'm not wrong. Well, yeah, we are checking it's loaded and we are checking also that the reviews are loaded. So to be sure that the page, the browser displays is the correct we want. And we are extracting some data, the name, the price description of the product, the related products also, and the reviews.

36:01 But we don't display them. We just try to We make some tests just to be sure that we get the data. And finally, we display results. Well, we store the time we used to do the loop and at the end of the process, just display the average time, the min, the max. So that's the basic script we want to execute to test. So I can run LightPanda with the serve subcommand just to start the CDP web server. I can also add the port option, sorry, to define another point. But by default, it's the 9,222. It's a classic

37:06 port number for the browser CDP. So if I run my computer script using node, so here we display a dot each time we load and we loop into the page. And here we have the average time, which is one, sorry, seventeen milliseconds. And just to compare, if you want to do the same thing using Chromium, you can run it with the headless new option, which run the browser as headless, and you will define the remote debugging port, which will enable the CDP server, the exposition of the CDP server from the Chromium browser and lets you connect

38:13 using your script. And because Chrome doesn't use just you have to give the full URL to connect directly in the webs on the web server. So I registered an example. What is it? Browser, WS. Not sure. That was wrong. Sorry. I will run LightBandA. Let me check the name. Its browser address. So here we can see visually the difference of speed with Chrome, is slower. Yes. But it makes sense because we are doing less work, obviously. We don't, of course, do any rendering, graphical rendering of page. So it takes time, but we don't also load images,

40:01 we don't decompress images, and that's a lot of work Chrome is doing and we don't. That's also explain why we could be faster than it. So I wouldn't say Chrome is slow. That's that's not true. But we can skip a lot of users' work in this case and so save a lot of time this way. I guess it comes down to your your use case, right, and what people are trying to do. Yes. There there's a large subset of acceptance test and and synthetic testing that doesn't need CSS and all of that other stuff that comes with it. And keeping those

40:44 fast is gonna save companies money, especially in their CICD pipeline or or even locally when they're running their testing, want this to be fast. Sure. We we do have a question in the from the comments in the audience here from doctor. I was curious if you could run both of those CDP scripts against LightPanda and Chromium again, but while running htop so we can see the kinda the usage of, you know, Chromium versus LightPanda, if you're happy to do that. Oh, yes. I can. Oh, sorry. I stopped the screen sharing. My bad. No. It's alright.

41:21 Yes. How can I do that? It's a good question. I'm not sure. Well, we can try it. If I run htop, but what I can do So it's F3, you can search for well, it's gonna show you your actual Chromium and not just the htop. Yes. That's a good point. But what I can do instead, maybe, I can show you a bit an idea of the memory consumption, but it's about memory, not CPU. So to just give you another idea, let's say if I use the It's time. V, I think. So oh, okay. Now you have to change that UUID

42:34 again. Yeah. Oh, come on. Okay. So I will run Chrome on it. Oh, yeah. I could reduce the number of loops, not the loop but In fact, so here we can see, okay, we use something like 200 gigabytes of memory at maximum. And if I run LightPanda Oh, sorry. I have to use the user in time today. I was, yeah, it was bigger here, so we have, okay, 60 megabytes in this case. But we have, in fact, the most of them Is that correct? No. What are We introduced a new options. I will find it exactly.

44:21 But we are reusing currently the same, well, in V eight, you can start a V eight engine and then you can create isolates to run code on isolation into the V eight engine. So currently we changed a bit our architecture recently to reuse the same V eight engine started with the browser, but using a new isolate per page we are navigating. And by default, for now, we don't run the garbage collector into the Well, by default, we don't give an option to the V eight to run the garbage collector. And by enabling GC hints, we are saying to

45:30 V eight when we change the pages, it could run Garbage Collector to save memory. And so if I will run the same tests with this option, It's a bit it could be a bit slower, but yes, you save more memory this way. So we were 200 megabytes using Chrome. And with this gcints options, you are something like 21, 20 two megabytes with LightBandA. So, yeah, But it's not CPU usage. I don't really know the difference between LightBandA and Chrome in CPU usage. Since we are doing less work, I hope or I expect we use less CPU

46:44 but I have no proof actually. Nice. Well, doctor seems happy with that at least. Glad we could help. Now, obviously, you know, you're very diplomatically said here that, you know, Chromium is different. It's doing a whole lot more. LatePanda is very opinionated on on what it's trying to do. So maybe we could help people understand the specific use cases when to reach for LatePanda over using something like Chromium. I'm assuming, you know, this is aimed at front end developers built in React applications and Vue applications. What's their use cases? There's also the data collection sites

47:23 and OpenAI and AI agents and all this. Like, When should people go for LightPanda? When it works? Well, I want to show that after I think. Yeah, I think, well, the first question is if you need visual rendering or graphical rendering, of course, you can't use LightPanda at all. So if you need to do screenshots, PDF of your page, of things like that, It will not work with LightBandA. And then, theoretically, in ideal world, everything else will be okay. Well, no, sorry. The other point is if you have issues with, let's say, fingerprinting, things like that,

48:21 I think currently LightPanda will not help you at all because we are a different browser and we are easy to fingerprint differently. So we'll be detected immediately. So if you are in this use case, you are better using right now Chrome. And for the other use case, theoretically, you could use LightPanda for everything else. But today is a bit early, I think, because our main challenge actually Well, we have many challenges, but one of the main challenge is to implement all the web APIs required to run JavaScript around the web. And currently, we don't have all the support

49:21 of all of this, of course, but we try to improve it every day. So depending of the use case, I would suggest you to give a try to LightPanda, see if it work in your case. And if it is good, you use it. But in other case, maybe you should retry later. That's the point, yeah, I think. Yeah. Does V eight support WebAssembly or is that something that you would have to build separately into your browser? You mean executing WebAssembly? Yeah. Is that a V eight concern or is that something else? Well, V eight, as far as I know, yes, we can

50:05 execute it directly into V eight, but we have to bind correctly. Let's say if currently if a web page offers a WebAssembly script, we will have to just bind the source to execute it on the VA. That's not the case actually. But I think it's not hard to do. I hope so. Alright. So before I I throw some more questions at you, was there anything else you wanted to show? Oh, yeah. Just well, an example of, well, a real world things, let's say. So what I wanted to show you. Oh, yeah. For example, if you are trying to fetch

51:05 a page, let's say, if you want if you want to use a DuckDuckGo to search something like Panda, for example. So if you're trying it with the browser right now, h t m l. So here is an example of things that could, that goes wrong. Here, for example, we have a JavaScript failing due to some reason. I don't know exactly. Here we have another one which fails because match media doesn't exist in our browser. So here is ESMOBILE. So depending on the JavaScript, at the first issue, it will stop executing with an error. So here you can see that in real

52:23 world, we are missing a lot of web APIs, in fact. But depending of data you want or what you want to do and depending of the, let's say, the final results, it could be an issue or not. In this case, I think it's an issue. Let's say the result in the browser. Let's see the result. So here we can see we have nothing at all. What we have in the Nothing? That's where? Oh no, sorry. I forgot the option to jump the page, usually. Would explain the nothing. Yeah. But oh. Oh, yeah. Okay. Okay. So it's we have not such more.

53:23 So we have only the we have only the, yeah, basic HTML, I don't know what. And something interesting could be to compare which with curl if we, let's say, if we just have the initial HTML of if we have some difference. That's that's not the point here. So we did the code. It will not work. I know that already that with Google, currently, it will not work too. But I try with Bing. And Oh, I have to use the Oh, not exactly. I didn't have to use the whole URL, Because there is some idea. I don't know

54:18 why. Never mind. So, if I try this one. So, I think on the thing. Again, we can see we still have some URLs on one JavaScript, maybe. What the results of that? Okay. In this case, I have a result. And just to compare because if results are just sent immediately, I mean, without JavaScript, this is not a real proof or not really interesting comparing this curve. I mean, there's some CSS there, right? That's Maybe there are Well, depending of how the CSS is declared in the HTML, my browser here, Chrome, can fetch it and apply it. But that's

55:28 a good point. Maybe it does the same with the JavaScript also. Let's see. Can I just disable JavaScript execution here? Where is it? Let me I know where is it in Firefox, but not in Chrome, actually. Here, I can disable JavaScript. Okay. So without JavaScript execution, I have some results. If I do the same with curl okay. Nope. It's not a good address. Oh, I have results too. So Okay, not interesting in fact. So yeah. Okay, Bing just send back the results. That's a good thing. So yeah, let's say that in real world, we still have many,

56:53 well, web APIs to implement. So you could have a lot of troubles actually using LightPanda. It's not really ready right now, at least for most use cases. But in some specifics, it could work, in fact. But we are working hard on it and we are trying to, obviously, improve that support to be able to run more JavaScript and having good results on more websites. Are currently integrating the click. And just to be clear on that also, there are both sides of implementation we have to do. On JavaScript side, we have to implement web APIs from the browser. That's one big

57:46 challenge on one side. But on the other side, we have also to implement CDP commands. We talked about PrevWrite at the beginning, and that's also where we have to improve things to be more compatible with clients, depending on how they are using CDP protocol actually. When it comes to the hold on. I'll move his back over. Yeah. So when it comes to those APIs, right? You know, let's assume I'm testing the Rawkode Academy platform, and I wanna do some sort of logins there. Do I have access to local storage, the web SQL? How much of that works right now in

58:33 the? How much, I don't know. We have some, let's say, we have basic implementation of web storage actually, but it's hard to give you a number. We are using the web platform test, which is common HTML tests to run on browsers. That's something which is standardized and we are trying to run the browser against this test. So we are tracking improvement on it, But I don't have real numbers to do that to answer in fact. Okay. I mean, think this is still a very young project. It's an exciting project. I think the value proposition is clear to the people

59:31 watching it, and it's a good way to get involved if you've never written any Zig before and you want to. Go check out the repository and look for issues and and and get committed. But as we kinda mentioned earlier, this is an an open source project. Right? And unfortunately, money doesn't grow on trees. Open source has to be sustainable. I'm assuming you just have a company that you're you're trying to make successful with this product. So maybe you can share a little bit of light into the roadmap for Light Panda as an open source project, but also where you are taking

1:00:02 this as a company in order to be a sustainable and long term business. Yeah. So as you said, it's still super young. Our big focus at the moment is getting the browser to a point where it can be used reliably in production. And we we have a couple of obvious ways that we'll build the business around that. Main one is obviously a cloud office. We want the people to be able to host it themselves if they want to. And that's why it's open source, but that's like, know, the case for every use case out there.

1:00:44 We do have a, that's in beta at the moment and it runs on Chrome and like pandas that you can sign up on our website get a test taken for that. And then we're also thinking about how we can build native AI features into the browser itself to enable, for example, but this is just more of an example to illustrate the point, but to enable LLM's, for example, to and there are there are a ton of tools doing this kind of thing already, but they're building on top of of Chrome. So, having a version of the browser, which can

1:01:29 kind of take that a step further because we control the whole code base to enable the structure of the webpage, for example, to be controlled by an LLM deeper down the stack as it were. And then that'd be like a a kind of on premise version of the browser or a premium version if you like. Okay. And the roadmap for open source, I'm assuming your heads are just down focusing on that web compatibility and those conformance tests. Right? Like Yes. That seems to be the the main objective. Right? Yeah. Yeah. Yes. It is definitively. How big is your team?

1:02:09 We are six at the moment, but Six. Growing growing pretty fast. I the good news, I guess, is that kind of conservatively, I think a lot of the hardest work is kind of behind us. So as you say, it's kind of just heads down. We know what needs doing and we're doing it. So we're pretty optimistic. And yeah, like any and all feedback from the community is super valuable as well. It's one of the huge benefits of it being open source as we get to hear from people about, you know, these random cases that are actually working in production already.

1:02:48 There may be some that there's really not that big of a lift for us at this point. Yeah. I'm I'm sure it won't be long until someone is using the CDP and, like, Panda to order their Domino's pizza. And that seems to be one of the first things that people like to hack on. Awesome. Well, thank you so much for taking time out of your day for guiding us and sharing more about LightPanda and even getting hands on and showing us how it works. Is there anything else that we haven't covered that you would like to

1:03:17 share with the audience before we wrap this up? I don't think so from my side. Thanks so much for for having us and giving us the platform. Yeah. Yeah. Thank you very much for the invitation. Alright. Well, thank you again to the people that watched us. You know, go check out the project, open issues, contribute where you can, and let us know how you get on. Feel free to drop your comments and questions into the comment section, and we'll do our best to answer them whenever we can. Have a great day. Thank you again, and

1:03:49 I'll see you all soon. Until next time. You. Bye. Bye bye. You make this happen. Fill the stream with light. We dove in deep with LightPanda speed and grace. That ZigBilled browser finding its own space. Saw how it works, how fast it really flies. Reflected in our guests' insightful eyes. They showed the way, the future looking fast. That inspiration surely gone to last. Yeah. The stream is over, but the journey's not. Subscribe and follow, give it all you've got. We'll be right back before you know it, friend. More tech adventures that will never end. So join us next time Same cool place

1:06:05 to be Right here at Rawkode Academy Yeah Thanks, Pierre Thanks, Pierre And Katie And Katie. And thank you watching. Thank you watching. And we'll see you next time. Rawkode signing off. See you soon. Keep learning. Keep coding.