In this talk I will show Makepad, a new UI stack that uses Rust, Wasm, and WebGL. Unlike other UI stacks, which use a hybrid approach, all rendering in Makepad takes place on the GPU. This allows for highly polished and visually impressive applications that have not been possible on the web so far. Because Makepad uses Rust, applications run both natively and on the Web via wasm. Makepad applications can be very small, on the order of just a few hundred kilobytes for wasm, to a few megabytes with native. Our goal is to develop Makepad into the UI stack of choice for lightweight and performant cross-platform applications. We intend to ship with our own design application and IDE.
Makepad - Leveraging Rust + Wasm + WebGL to Build Amazing Cross-platform Applications
AI Generated Video Summary
1. Introduction to MakePad
So, I want to start this journey long, long ago, maybe before some of you were still in primary school even. I founded cloud9 IDE, it's a company to build a web IDE. We had an HTML based code editor called Ace, it was one of the two at the time. And, so I was in the middle of the HTML world building what was considered a complex application, an IDE, right? Everyone was making web pages, some web apps, but the IDE with the code editor was considered a complex web application.
2. Challenges with Stability and CPU Power
This all runs also on an iPhone 6, I think, still, if you load it up in Safari. And at some point, I even managed to run itself in itself. And this is great. This is all fine.
But it had a big problem. It had a big problem. At the time, in Chrome, when I was working in the application for more than 30 minutes, Chrome would just crash. It would just crash, and I didn't know why. And having dealt with browser bugs before, sometimes they take years. Sometimes they never get resolved. Usually when you're like, yeah, I LiveCode in Chrome for half an hour, and I hot reload a worker, that's a bug. They go, OK, you're probably the only person in the world that does that. So good luck with that. So that was very depressing. And hold on.
4. Introduction to Rust and Reimagining Makepad
Rust is a new programming language developed out of Mozilla. It's a borrow check language that doesn't have a GC, making it fast and without hiccups. It compiles to WebAssembly and is both high and low level. The speaker joined forces with developers experienced in Rust and UI design to reimagine makepad. The new version includes a code editor and animated code folding for better code overview and spatial memory.
So yeah. And then Rust came along. Rust is a relatively new programming language developed out of Mozilla. It's a borrow check language. It doesn't have a GC. This is a very fundamental difference, which is also why it takes time to learn. You can't just randomly create objects and magically have them go away. This is also why it's fast. It doesn't have GC hiccups.
So I had a new chance at trying this out with a new technology. And I joined forces with Eddie, who is an Exmozilla developer, who was there when Rust got invented. So he knew Rust and he could teach it to me as well. And Sebastian, who is one of the most brilliant UI designers I know. And because, you know, if you're building UI, you better try to make it look good. And I just play games. So makepad Rust, this is a complete reimagining.
5. MakePad's Live Editing and CPU Performance
And it also still has the live editing. Like here's the live thing going on with changing the code. I'll tell a little bit how that works later. But it even worked in VR until the web APIs changed a bit and I just didn't feel like updating it. But I'll fix that later.
This whole UI runs in AR and VR just fine. You can position it anywhere in 3D space, it has depth in the UI, all that stuff. And I finally got it. This is my own desktop version of the build, I use it every day. It's the same code base, you just compile it as a native desktop application that runs directly on Metal on Mac, directly on DirectX on Windows, OpenGL on Linux. And yeah, no browser sandbox, no Electron bullshit. This binary is one megabyte in a zip file. We're back to 2,000 in terms of file size. So could this be it? Could this be finally what I wanted? You know, a hyper fast application stack that works on native and on web.
6. MakePad's UIStack, Design Tool, and FunAudio
I finally got to the point where I can do useful things with my UI instead of just doing the UI. So what is it that we built? It's a UIStack, so it's a widget set. It has a React-like render model. It is its own IDE and code editor built on top of that stack. And our final piece to build this into something useful that I can offer to you all is going to be a design tool. Because, you know, hand coding UI is something that I would love to delegate to the past. You want to use a proper visual designer. So this whole system is designed to support a visual designer. And that means that we have a DSL, and a DSL is a domain specific language. HTML is a DSL, CSS is a DSL. We have to have something like that as well because I don't want to do it all in Rust. If you build a visual design tool, the visual design tool manipulates the data structure that is your UI. And in this case, the data structure is something custom, that has properties of HTML, CSS, it has inheritance. It's actually my attempt to finally fix the crap. But we'll see how far that went. Here's for instance the color picker in line now. This kind of stuff, where you have a code editor that's extendable with all sorts of visual editors, is one of the reasons I want a fast render model. The code folding just folds everything with it still as well.
But why? Originally, my original motivation of getting into programming was having fun with computers. I wanted to make it draw graphics, make sounds, do fun things, and not fight with Webpack or I don't know what kind of deferred problem you have as a web developer. And that's why I want to show you our first example application because it's fun that the IDE is an example, but it's a bit of a domain-specific example. And that's why I built FunAudio. And FunAudio as opposed to LogicAudio, it's an audio application that uses our audio API on Mac. I have accessed, because in Rust you can access all native APIs, I access the audio unit API. That means that I can load native instrument...
7. MakePad's Future and Performance
I can load native instrument components into the UI. Rust allows for limited web deployment and powerful desktop performance. The future includes an open source release in three months and the upcoming release of a design tool. MakePad on the web is lightweight and loads quickly. The demo showed collaboration in WebVR, which performed well with WebAssembly. The one millisecond of CPU time shown is significant for performance on various devices.
I can load native instrument components straight into the UI. This will also build to web, but then you don't get all these nice features because this is what the web sandbox limits you to. You cannot do this. There's just no way. And with Rust, you get the power to be limited on the web, but get to deploy, and the power on desktop. And that is why I get excited by this tech stack. It's a very different approach to putting the web on desktop, it's putting the desktop on web.
Okay. About four minutes left. So what is the future? When can you guys use this? We're having an open source release to crates, which is NPM for Rust, so that you can very easily install the stack in about three months, including some documentation. And we're ramping up to release the design tool ASAP. And for that, I... You can open makepad.dev, that was the web thing that you just saw, you can open it right now on your phone. This is the GitHub repo, everything that you've seen so far is MIT in the GitHub repo. And Twitter, for myself and the product.
So yeah. So yeah, makePad on web, right? If you deploy these kind of applications to web, size matters. You don't want it to be 16 megabytes over the wire. That's why I'm very excited that this thing, as you see it here, is 500 kilobytes over the wire, including all dependencies. So I mean, that's broadly compressed. But still, 500 kilobytes to deploy this whole thing, and it loads in under a second time to interactive. So it's very, very viable to do things this way. It's not like compiling a ginormous amount of code to the web as a lot of C++ applications are doing. And similarly, if you look to the future of AR and VR, this demo had a collaborative put your quest on, open this URL and you'd be collaboratively in this IDE space whilst live editing an object in between. And I was very impressed with that as well for WebVR because I was like, ah, it's going to be janky, right? Because VR is so performance sensitive, if your garbage collector hicks up, you're going to get sick, because the frame is going to start to jutter. But if you're super disciplined about it and you use WebAssembly only, I could get it completely rock solid on WebVR. And this is also when that one millisecond of CPU time when doing stuff really starts to matter, because this is a millisecond of CPU time on an M1 Max, not on a crappy Android chip that is in a VR headset. So that one millisecond that I showed you, you should multiply by 10 to have your full application domain for other devices.
Importing 3D Models and Donating to Foundation
And this is also when that one millisecond of CPU time when doing stuff really starts to matter. So yeah, I think that is the end of my talk. Any plans to donate it to a foundation at one point? Absolutely. Is it also possible to import 3D models or textures from Blender, for instance? That's definitely like a higher-level tool. Yes, absolutely, but someone has to write the importer. It's a custom render stack with a shader model that is unified across all platforms.
And this is also when that one millisecond of CPU time when doing stuff really starts to matter, because this is a millisecond of CPU time on an M1 Max, not on a crappy Android chip that is in a VR headset. So that one millisecond that I showed you, you should multiply by 10 to have your full application domain for other devices. And so, you know, don't think that I'm over-optimizing that one millisecond. It's actually the space you have to reach your entire audience.
So yeah, I think that is the end of my talk. I think we can move to questions. Yay, questions. We have a few, so that's good. Okay. People also can still, you know, send their questions. If you have burning ones, and you were just waiting for the talk to end, to type in your questions.
I really love the question that is... Oh, did it go away now? Ah, yeah. So do you get to work on this full-time, or is there a sponsor or company behind? So for the first many years, I did consulting, and I did this as an iterative cycle every I restarted six times. More recently, when I started working with my co-founders, we have an angel-funded startup situation. But it's, yes, full-time. Full-time? Wow. Yeah. That's really cool. Any plans to donate it to a foundation at one point? Absolutely. I mean, this is an open-source stack, right? The only thing that we're going to commercialize is the design tool that sits on top of it. All of the libraries, all the dependencies, are going to be unencumbered MIT so that everything you build with this, you can pick any license you want, you know? So as this becomes popular and successful, hopefully, then we can definitely use one of those constructs that many open-source projects use. Super. Very interesting. I hope that answers the question from the person who asked. Is it also possible to import 3D models or textures from Blender, for instance? That's definitely like a higher-level tool. Yes, absolutely, but someone has to write the importer. It's a custom render stack with a shader model that is unified across all platforms. So it's not GLSL. It's something that looks like GLSL, semantically GLSL, but it cross-compiles to all the backends, Metal, HLSL, and WebGL, and in the future also WSL.
MakePad's Custom Engine and Future
So it's a custom engine. It's geared for UI, but it can technically do all the things you could do in Three.js, but we're going to need to develop the tool chains around that.
This was fingers crossed. Essentially, you know, this is not something I can benchmark dry very much. I just had to build it, and as we got further, I started getting more excited about half a millisecond of CPU time doing anything, and this means that the amount of bandwidth I have for this UI, I could render, the startup time for this IDE in terms of spawning up the UI is a millisecond. Like, I could draw tens of these things at the same time on your phone, and it wouldn't matter. So, yeah. It is definitely something I hoped, but I would say it's better than I thought.
Awesome. I see here a question whether it will only continue to run in the browser. You did show the desktop version that you used yourself. Is that going to be available too?
The idea is that we want the power of both. You want the easy deploy to web, and if you're constrained, use the desktop compile. And maybe it means mobile or they mean mobile. Mobile support will come later, because I think focusing on the web deploy target first is a good start, because it's a very big space, especially because we're bridging the APIs to Rust. That's a lot of work. But mobile will come later.
Very cool. Do you see a future for Rust-based UIs? No. I think it's absolute garbage. No. That was a very unexpected answer. All right. Thank you very much. I think that's about the time that we have, and we're going to move to lightning talks.