Shivay Lamba: But of course now you can run very simply not just inside the browser, but even outside on server, in cloud native applications, and even in Edge applications, even in the serverless space. Paul Mikulskis: Welcome to PodRocket, the podcast for developers. I'm your host, Paul Mikulski, and today we have an exciting guest joining us. Shivay Lamba is a web developer, machine learning enthusiast, and open source developer. After having led Dark Horse as CTO in the past, he's now a developer relations engineer at Meilisearch and working with a variety of different tech stacks. We're going to be getting into WebAssembly, Wasm, TensorFlow, and all sorts of goodies that are coming out in the groundbreaking and bleeding edge space today. Welcome to the podcast, Shivay. Shivay Lamba: Thank you so much for and I'm really grateful to the entire PodRocket team for inviting me over to be part of this entire podcast. I'm really excited to be speaking about Wasm and machine learning for front-end developers and how these technologies really enable front-end developers to not just think of front-end development as the basics of HTML CMS, but how front-end development today is much more than just your simple web design. That's what I am here to demystify some of those really nice technologies that front-end developers can use. Paul Mikulskis: It's a really exciting time to be talking about this because it almost feels like front-end development is being blended with the roles and responsibilities that backend development might have provided in a traditional stack. Right now, we mentioned you're at Meilisearch. What is Meilisearch, because I feel like that is tangentially related to some of the applications we might be getting into. Shivay Lamba: Meilisearch is basically an open source, Rust-based search engine. The idea is that in case you might have, let's say an e-commerce application or you might have a documentation search, there's a lot of content, especially a lot of text-based content that might be there and you might want to integrate a search engine. Meilisearch is basically a full text search engine that allows you to have a very simple, quick type [inaudible 00:02:03] search experience that you can embed inside of your application. Paul Mikulskis: As we mentioned quickly at the beginning, this is going to be a Wasm and TensorFlow podcast. Before we get into that really quick, are you guys coming for Elasticsearch? Is that a sector of the market that Meilisearch plans to capture? Shivay Lamba: Yeah. I would say that Elasticsearch is not really a direct competitor because if you take a look at the architecture of how Elasticsearch has been positioned itself is that it's really meant for large corporations that not only require a search itself, but they also require a lot of logging, a lot of observability. Whenever you set up Elasticsearch, there are a lot of number of different things that you have to set up alongside the Elasticsearch. For example, you might use Kibana. You might use Prometheus to store the log-off whatever search that you're doing, so it's more for enterprise-grade and more of cloud-related search as compared to Meilisearch, which is more focused towards smaller sites or more smaller use cases. Yes, it is definitely in that entire space of a number of different search engines that are there, but I would say that Meilisearch is more closely competing against the likes of Algolia, which again are simpler to set up. One of the best use cases that Meilisearch has is the ease of setup. Elasticsearch, you need to set up servers. You might have a number of different containers that might be running your separate instances of your Elasticsearch, so it can be very heavy and compute intensive to actually set up such kind of search engines and that's where Meilisearch shines. Paul Mikulskis: Let's dive straight into Wasm, though. Shivay, you've worked extensively with WebAssembly. What is a WebAssembly and should we call it WebAssembly or Wasm? Shivay Lamba: I would say that, I really like to call it Wasm, but that's totally up to you because WebAssembly can be a huge word. I prefer to use Wasm, is that at least that does help to remove some of the misconceptions that people actually have with web assembly. When you use the terminology Web Assembly, there are a lot of people who might not have heard about the term that usually has certain preconceived notions about the technology itself. Again, just to put it together. Of course, web assembly is not really just related to web or it's not just related to assembly language, and that's actually the most common misconception that people usually have. In a nutshell, web assembly is this binary instruction format. It essentially allows you to take your modules and functions written in various programming languages like Rust, C++, C, Java, and compile them into this WebAssembly byte code that then can be run inside of your browser. That's how it was originally foresee, but of course now you can run WebAssembly not just inside the browser but even outside on server, in cloud-native applications, and even in edge applications. Even in the serverless space. The reason why WebAssembly was thought about in the first place was that if you take a look at how our browsers actually work, browsers natively only support JavaScript as the language. If you were to run, let's say, something like a Rust program or a C++ program, which are more performant as compared to JavaScript because despite the fact that JavaScript being one of the most popular programming languages, there are certain performance limitations that are associated with JavaScript that do not allow you to create very compute intensive or mathematically intensive applications that are much more better suited if you were to write them inside of let's say C++ or Rust, but the browser does not natively support these languages. You cannot really just take any C++ program and run it directly inside the browser. You need a way search that JavaScript itself can take that module or that function and then run that alongside your JavaScript. That's where this entire idea behind assembly language. For instance, WebAssembly started with ASM, with this Assembly [inaudible 00:06:02]. The idea was that you could take any program and then compile it into this native byte code or close to native byte code that had close to native performance and then run that alongside your JavaScript code so that you were able to basically run those functions inside of your web browser. That was the humble beginnings of WebAssembly. There are a number of different people, especially who are working at Fastly and Mozilla, who spearheaded the development of this entire WebAssembly stack. There are a number of developers who are still in Fastly and in Mozilla today who were 'the original creators' of WebAssembly. Paul Mikulskis: I think it's not only for the web is the key takeaway here. WebAssembly, Wasm, it's byte code. Shivay Lamba: Exactly. Paul Mikulskis: I'm thinking back to computer science videos where I'm learning about what happens when I call GCC or whatever on my code. It goes down to that machine level and that machine level is its assembly code at some point in down in the stack and that's what we're talking about here. Could you clarify for me, so I know a JavaScript node it would run in the V8. In the web browser, it runs its JavaScript, so this assembly runtime, it's completely different, like a whole separate sandbox so to speak has been built out. Does this have SYS call level interoperability? How low does that go onto the host machine, the host LXC or whatever it's running on? Shivay Lamba: There are two components to this. I'll also like to share how does WebAssembly run inside the browser and then also on this service side. Paul Mikulskis: We could start with the client and then go into the service side. Shivay Lamba: Absolutely. Yeah, like you mentioned, today WebAssembly is not just a browser specific technology and we'll come back to the service side a bit later, but traditionally in the browser as I mentioned, you would typically take any programming language. Let's say C++ for that matter. Today there is a very popular library called FFmpeg that does video encoding and things like video editing, you can do that. It's written in C++. Now, if you were to run this FFmpeg library inside of your browser, one of the use cases could be that, let's say if you're creating an in-browser video editor. If you were to do with that JavaScript, just forget about it. The performance would be so bad that you'll not be able to run it. The way that you basically do it is that we have this tool chain called enscripter that allows you to take a C++ model and compile it down into this WebAssembly byte code. Of course, as we mentioned that this byte code is a very low level and we can say that it's very near to your native byte code that might be running because it is not directly native but it is near to native. Let's say if you were to run some byte code that is running natively inside of your system, it could be like a Rust-native byte code. WebAssembly comes very close to that native performance, so it gives that near to native performance. The way that you run this inside of a browser is that you'll instantiate your WebAssembly module inside of your JavaScript function. The primary way in which you can instantiate your WebAssembly byte code inside of your JavaScript function is with the help of streaming. Very similar to how we have streaming functions inside of React like today in the server set render entering and SSG. How streaming works very similarly, you can actually stream your WebAssembly module inside of your JavaScript function and that allows you to basically run your WebAssembly model. There are a lot of in-built functions including instantiate WebAssembly module. There are a lot of these in-built functions that you can find on the Mozilla docs for JavaScript where you can actually use these inside of your web browser. The idea is that you would load your WebAssembly model with the help of your JavaScript function. Then you'll be able to actually run that. The idea is that using this, you can run it for any particular application for which your WebAssembly module might have been designed. This is typically the way that you run your WebAssembly models inside your browser with the help of JavaScript. Now, if we take a look at your server site, that's where actually the point that you mentioned about making SYS calls comes in the picture. There is this interface called as WebAssembly System Interface, or WASI for short. Now, if we understand that how WebAssembly actually works out the box, so there is this security sandbox model. You can think of this as a virtual machine or a VM that runs your WebAssembly model. The WebAssembly itself cannot really do anything on its own. It cannot really interact with your file systems or it does not have any network capability out of the box. The idea is that there is a security sandbox model. Your WebAssembly model itself is encapsulated inside of this WebAssembly virtual machine that provides this security. In case you want your WebAssembly model to be able to make calls to the file or make network calls, that's where this WASI comes in picture, or the WebAssembly System Interface. Paul Mikulskis: These WebAssembly system calls, are they wrappers around existing SYS calls. For example, interacting with inodes or Cgroups or whatever, or are they built up from the ground again to natively support the system in the best way possible? Shivay Lamba: Yeah. I would say that they have been built up from ground up in such a way that they do support non-native calls that you can make directly with the help of WASI. There is this entire concept of WASIX. You traditionally make WASIX calls outside of your WASI. Now, there are a lot of advancements being made inside of WASI Preview2, which is basically a new version of WASI that's coming out that will move away from the standard system calls or these WASIX space calls. Originally, I would say that when WASI was designed in the first place, it was much more closer to these system calls using LiPC or how it works internally. Now we are moving away and there is a general layer of abstraction that is being built with the help of the second Preview that's being released for WASI, too. Paul Mikulskis: Kind of like a hybrid situation now where we do have natively built things but there is wrapper-level logic being built out. Shivay Lamba: Exactly. Paul Mikulskis: We have so many things to cover in this podcast, so we might speed up a little bit as time goes on, but please humor me with one more question I have, Shivay. Do you think that building things from the ground up is risky because we've gone through years of trials and tribulations of SYS call exploits, system exploits, and here we're going, "Let's build it again." Now granted we have two, three decades of knowledge standing on the shoulders of giants, but do you have any sense of urgency of looking at security in this space? Shivay Lamba: That's where WebAssembly really shines. The entire premise of the security model for WebAssembly that your WebAssembly model cannot really do anything on its own. Now that doesn't mean that it is completely bulletproof from external security vulnerabilities. Paul Mikulskis: I would be worried if somebody told me it was bulletproof. Shivay Lamba: Yeah. Paul Mikulskis: Yeah. Shivay Lamba: It is not. That's like another key thing with security that there's nothing. Today we speak so much about the zero trust architecture in capabilities. Now we are really going out of context for front-end developers, but it's really important to note that because of the way that how the inherent architecture of our WebAssembly model has been structured, that does make it a lot more future-proof in terms of security as compared to your previous iterations and how we have seen these SYS calls being made. That is being very strongly considered when it comes even newer things that are being made into the entire WASI space. I would say that it is not actually bad to rethink and building this from ground up, especially if we are taking into consideration security because generally speaking, security is something that is always an afterthought for most of the software developers. Whether as a front-end developer you might be thinking of it as authentication, right? Paul Mikulskis: Sure. Shivay Lamba: We can correlate it with authentication. That is why we saw emergence of so many web protocols, security protocols as well, whether it's IDAC, the open identity access protocol that today we have that is being implemented by Okta by [inaudible 00:14:08] zero. Or the PKCE flow, which are really, really important and we are really taken into consideration security even for front end developers. I feel that it's totally fine to rethink it from ground up and keep security as a very important aspect when we are designing the entire specs for WASI as well, and for WebAssembly. Paul Mikulskis: I think a lot of people agree that security is a afterthought and when you hear building something from the ground up, that might be a first air of introspection. Shivay Lamba: Yeah. Paul Mikulskis: As a front-end developer, we have talked a little bit about details. We have talked about server side. We have talked about low level byte code and there are going to be a lot of front-end developers. Don't worry, we're not forgetting about you backend and server people here, but we know there's a lot of front end developers listening. They might be asking, "When do I reach for Wasm? When is Wasm appropriate for my project?" I think that bleeds really nicely into what is a Wasm-based web container? What's one example of that being used today because that sounds like voodoo magic to me of a container in the browser. Could we start with an example and then maybe lead into when should developers reach and why? Shivay Lamba: Before we speak about web containers, I'll just probably take a minute or two to really discuss about what are the best use cases for any front end developer to use WebAssembly. Going back to the first point that we raised on what exactly is WebAssembly and why was there a need? As I mentioned that JavaScript as a fundamental programming language is really great. It's by far the most popular programming language, but there are certain performance constraints that come with it. That means that if you are planning to do things like machine learning inference that is very mathematically compute intensive or things like video editing, image editing, directly inside the browser, if you were to do it natively inside of its JavaScript, it would be a nightmare to do it because of the performance issues. That's where when it comes to identifying those particular functionalities that you might want to include inside of your front-end application that runs exclusively on the browser itself. That's where you can use WebAssembly. Again, the fact being that you would have your model's functions written in more performance application programming languages like C++ compiled into the WebAssembly bye code. Then run it and that's why you see a lot of applications like Figma, which uses WebAssembly. Then you have Adobe Lightroom, then you have Microsoft Flight Simulator. These are just an very few number of applications that again are very mathematically compute intensive, certain parts of them, and they use WebAssembly under the hood to be able to run them very efficiently. That's one of the main use cases for front-end developers. If you're planning to have such kind of applications instead of your front-end app where you could actually use WebAssembly. When it comes to front-end developers, a lot of front-end developers do not really like to go into backend development. Again, it might just be part of their job role that they're primarily just working on the front-end frameworks like React, Next, and they might not really go into backend development using Node or some other programming language. That's where the web containers basically come in to picture. In a nutshell what web container is, it's essentially this technology that has been built on top of WebAssembly and web workers like service workers, [inaudible 00:17:18] service workers. The underlying technologies is that with the help of these web containers, you can actually run your entire Node.js Applications inside of your browser. It basically helps you to create this container/VM where it provides you a full-blown IDE and an entire node system. You can actually run your SGDP servers directly inside of your web browser. If you were to understand how does it work from an architect perspective is that as I mentioned that it uses your service workers and web simply to be able to first of all spin up a new container/VM that runs exclusively inside of your browser. You're not really connected to a remote server, which typically you might see with things like GitHub Codespaces or some other service that you might use. Again, because there are some issues with respect to latency, then of course security is always going to be a big issue because if you're running anything inside the browser, then you don't have to worry at all with security and that's what the biggest benefit of web containers is. Whether you are, let's say trying to build a tutorial on like let's say node-sys, which actually requires a command line tool where you might require a developer to actually type in some system level calls or make some calls. You get that full-blown web-based ID and a command prom that has node supported inside of it. You can essentially run node-sys. You don't have to set up a remote server or a backend server inside of your application to be able to do so. It's really great if you are learning things like backend development, you can use web containers for creating tutorials, even AI-based applications. There are a lot of different potential use cases where you might want to use this setup without having to set up your additional servers just to be able to make those calls. It also becomes more cost-effective as well, in case you're just trying out backend development. Paul Mikulskis: What do you think developers should tell themselves I feel comfortable with in my own personal skillset and portfolio before they try to put that ML plugin, that video editing app, that memory intensive application into that browser environment? Shivay Lamba: Before you go with any such kind of application that you might want to build, of course you would still need the basics, whether it's for front-end with JavaScript, HTML, CSS, basic stuff, how the browser technology actually works. Those should be fundamentally good, and that also actually comes with WebAssembly, because we have been speaking a lot about WebAssembly but there are certain things that you need to be aware. When it comes to understanding how basically that byte code actually works or understanding how the stack-based memory allocation basically works inside of WebAssembly. You need to be of at least aware of, on a baseline level, how does operating systems work? How do SYS calls work instead of your CPU? That is something that you should be aware of if you really want to understand that how WebAssembly works under the hood because typically people tend to ignore those, especially as front-end developers. Paul Mikulskis: Yeah, I think this comes back to the thing we hinted at the beginning, is it Wasm or WebAssembly and really having an opinion about that, whether it's one way or the other, you probably really understand where things are running. Are they on the client or under the server, and you probably are a full stack developer or you have a sense of both ends of the system. I think that's a healthy place to come to WebAssembly with. A lot of times it said, "Oh, WebAssembly can be for front end developers to get going, get that thing booted really quickly in the browser." I just want to say maybe that is a little bit dangerous because to get the benefits of WebAssembly, you need to do what you mentioned, Shivay. You need to understand the stack-based programming model. You need to understand SYS calls and there's a really interesting YouTube video I saw where this person was doing a test of the same exact sort of looping ... Shivay Lamba: Yeah. Paul Mikulskis: ... nested loops with JavaScript, C++, Go, Rust. JavaScript won so many times. It's just because you need to know how to manage your memory correctly if you want to get those performance gains. It's not like a freebie. It's not a freebie, it's just one thing to highlight. Shivay Lamba: Exactly. Paul Mikulskis: We're going to get it into TensorFlow real quick, but just to close out our ramblings on Wasm and Web Assembly, what do you think is some of the biggest market opportunities that this technology is offering creators and developers? Because it's really shaking up where you deploy, how you deploy, and what you pay for when you deploy. Shivay Lamba: Yeah. I would say that both from a front-end and even from a service perspective, because today there are so many technologies. You have database as service. You have backend as service with open source applications products like AppRight, Inhost. Why all these products are being created is to actually help assist front-end developers. That's why so many service apps are being created so that you can help assist the front-end developers and they're not reliant on having some dedicated person for a backend that they might want to manage. I think the biggest market today for WebAssembly is not really on the front-end on the browser side itself. Don't get me wrong, browser-based applications for WebAssembly are still really great, but their adoption for Wasm outside the browser has grown tremendously over the past one and a half years. Whether it's for cloud native applications or in the serverless space, things related to serverless applications, things related to deployments, that's where WebAssembly really is seeing a lot of usage. In fact, you can also actually use WebAssembly to help improve the performance of Node.js. It's being used to create user-defined functions in databases. There's this DB called HarperDB. It's a database that uses Node.js and WebAssembly, again, for being able to define your user defined functions. It's also being used in the database space. Again, a bit of out of context for or front-end developers, very likely see a lot of usage. As a front end developer today, a lot of front-end developers are getting more used to serverless functions. You might just end up using a WebAssembly based serverless function inside of your front-end app. Paul Mikulskis: Shivay, I know you're a TensorFlow fan as well. WebAssembly, it provides us opportunities to run TensorFlow. You've already touched upon this in our conversation so far, like, "We can run ML stuff in the browser." Shivay Lamba: Yeah. Paul Mikulskis: Can you tell me what you found most impactful in your life when you started using TensorFlow and why TensorFlow? There's PyTorch. There's other things out there. Why TensorFlow and what was that impactful thing that you were like, "Whoa, that's cool." Shivay Lamba: Yeah. I would say that my journey with WebAssembly actually also started when I started to contribute to the TensorFlow JS code base. Just for everyone, TensorFlow is basically an open source machine learning library that is typically used to run a lot of MLP computer-vision based stuff. It's originally created by the team at Google. Of course, there are a lot of different other open source libraries as you mentioned. There is Onyx, that is by Microsoft. There is Pytorch that is originally created by Facebook. All of them have their own benefits, but I was always a vision person and my role at Dark Horse, which is my previous company, was primarily centered around using computer vision to detect athletes. A lot of my work was primarily centered around using vision-based algorithms and I would say that the TensorFlow based models for computer vision were more efficient for our use at my role. That's why I just started out with TensorFlow and there was never looking back because I just felt that overall the developer experience that you get with using TensorFlow as compared to Pytorch, that is better with TensorFlow. That is the simple reason that I stuck with it. Paul Mikulskis: Shivay also has projects he's working on now besides just being DevRel. We should go over them really quick, Shivay, just so you can tell the public because this is bleeding edge stuff. Major League Hacking, that's one group you're working with. What are you doing with Major League Hacking? Shivay Lamba: In a nutshell, Major League Hacking is this community for hackathons. The idea is that they run a lot of student-based hackathons around the world in Asia-Pacific region and Americas and Europe, student developer hackathons. I have always been a hackathon enthusiast myself. By this time in my life, I have been to over a hundred plus hackathons as a mentor judge or even as an attendee. I am really close to building stuff. I really like to build stuff and hackathons are a really great way to do so. My association with MLH is primarily just mentor, a lot of the MLH-based hackathons helping students get started with technologies like TensorFlow JS or WebAssembly, for that matter. Really just mentoring students and helping judge some of these projects. That's primarily what I am primarily doing at MLH. For the second one is basically JSNation. JSNation is a conference that takes place annually and I'm part of the program committee. After having given a lot of talks, I wanted to be on the other side of things as well to really understand that when it comes to setting up an entire program for a conference, it can be very tough because there's so many different things. You have to take care of having enough diverse speakers. You also want to ensure that you have trending topics, but also having a good mix of topics, because JavaScript ecosystem is so large that how do you very carefully pick and choose topics and also very carefully evaluate from the abstracts that you get. It can be very stressful at times, but it's a good activity to be a part of. Paul Mikulskis: That sounds like an executive functioning nightmare to me and I'm happy people like you are there to do it. Shivay Lamba: Yeah. Definitely. Paul Mikulskis: Thank you, Shivay. You have your fingers in so many cookie jars here. You're in hackathons, you're in mentorship, you're in JSNation and on the bleeding edge WebAssembly stuff, so people are going to want to know where they can follow you if they're listening. Shivay Lamba: Most of the times I'm active on Twitter itself. Now I have also created a Mastodon account. I don't really recall it right now, so probably in the post-production we can share it. I have really started to add a lot of my thoughts on Mastodon on itself, so I'll probably share that. Paul Mikulskis: Well, Shivay, thank you for your time coming on and talking about WebAssembly. Shivay Lamba: I'll just say that the content that PodRocket comes up with, it's really great. I have been following all the different podcasts that I've come out recently, so of course, the entire team is doing really great job. Given that how quickly this entire ecosystem for WebAssembly is changing, I just expect a lot of breakthrough projects coming up, a lot of breakthrough changes coming into the entire ecosystem. There might probably just be an updated version of this podcast probably in the next few months, so I'll be definitely looking forward to that and seeing how the entire WebAssembly ecosystem expands. Paul Mikulskis: Shivay, thank you for your time and thank you for educating us today. Shivay Lamba: Thank you so much.