The Changelog: Software Development, Open Source - Build tiny multi-platform apps with Tauri and web tech (Interview)

Episode Date: July 15, 2022

This week we're talking with Daniel Thompson about Tauri and their journey to their recent 1.0 release. Tauri is often compared to Electron - it's a toolkit that lets you build software for all major desktop operating systems using web technologies. It was built for the security-focused, privacy-respecting, and environmentally-conscious software engineering community. The core libraries are written in Rust and the UI layer can be written using virtually any frontend framework. We get into all the details, why Rust, how the project was formed, their resistance (thus far) to venture capital, their full commitment to the freedom virtues of open source, and all the technical bits you need to know to consider it for your next multi-platform project.

This week on The Change Law, we're talking with Daniel Thompson about Towery and their journey to the recent 1.0 release. Towery is often compared to Electron. It is a toolkit that lets you build software for all major desktop operating systems using web technologies. It was built for the security-focused, privacy-respecting, and environmentally conscious software engineering community. That's a lot to build for. The core libraries are written in Rust, and the UI layer can be written using virtually any front-end framework. On today's show, we get into all the details, why Rust, how the project was formed, their resistance thus far to venture capital, their full commitment to the freedom virtues of open source,

and all the technical bits you need to know to consider for your next multi-platform project. For our little listeners out there who want to skip the ads and get a little closer to the metal, check out Changelog++. That's our membership, changelog.com slash plus plus. Sadly, there is no bonus content for Plus Plus subscribers today, but we have started to ship a special Monday news edition of the pod for everyone.

If you're a subscriber, all you have to do is sit back and enjoy those extras. And if you're not subscribed, hit the changelog.fm for all the ways. A massive thanks to our friends and partners at Fastly.

Bandwidth for Changelog is provided by Fastly. Check them out at fastly.com. This episode is brought to you by Honeycomb. Find your most perplexing application issues. Honeycomb is a fast analysis tool that reveals the truth about every aspect of your application in production. Find out how users experience your code in complex and unpredictable environments. Find patterns and outliers across billions of rows of data, and definitively solve your problems. And we use Honeycomb here at

Change. That's why we welcome the opportunity to add them as one of our infrastructure partners. In particular, we use Honeycomb to track down CDN issues recently, which we talked about at length on the Kaizen edition of the Ship It podcast. So check that out. Here's the thing. Teams who don't use Honeycomb are forced to find the needle in the haystack. They scroll through endless dashboards playing whack-a-mole. They deal with alert floods, trying to guess which one matters, and they go from tool to tool to tool playing sleuth, trying to figure out how all the puzzle pieces fit together.

It's this context switching and tool sprawl that are slowly killing teams' effectiveness and ultimately hindering their business. With Honeycomb, you get a fast, unified, and clear understanding of the one thing driving your business. Production. With Honeycomb, you guess less and you know more. Join the swarm and try Honeycomb free today at honeycomb.io slash changelog. Again, honeycomb.io slash changelog. Again, honeycomb.io slash changelog. So we have Daniel here from Tari.

Or is it Tari or Tori? Help us out, Daniel. How do you say it? Well, you know, it's all up to you. I think that in our community, there's a lot of people who have different opinions about how to say it. And we always kind of just go with whatever people want to say. Personally, when I'm using it in a sentence, I would say Tauri is this, that, or the other thing. So for me, it's Tauri.

For Lucas, I think he says more Tauri with a little bit of an O. For Yue, it's maybe Tauri with a longer O. But I mean, it's maybe tauri with a longer o but i mean it's just a name if you put me in a vacuum and said pronounce this i would probably pronounce it like atari without the a tari that's probably less accurate than the way either of you are doing it but i'm happy to call it tauri what about the star centauri alpha centauri how would you say that centauri yeah same thing tarry that's actually where we took the name from it's from these binary stars yeah it's the binary stars so you know you've got this core or back end and you've got the front end and that's kind of the design impulse behind it and we just kind of

went with it and if you look at our logo you'll actually see that the uh the blue part and the orangey yellow part are very close to a very certain star. Okay. I'll leave it to you to find out. Very cool. I thought it was like a cell dividing. That was my interpretation. It was like cell division.

It's also two people hugging. Lots of interpretations here. Adam, how do you say centaur? Centaur. I would say like a centaur would be like centaur. And I would say alpha centauri like alpha centauri like atari yeah so we're together of course we're both midwesterners here yeah danielle's over there in malta but also originally from the states yeah i uh i grew up there went to

college there and then left in uh 2000 so a long time expat now living in malta i like the the logo being after the the two stars because i'm i'm a a known person to know about space and stars and astronomy and whatnot but i hadn't looked at alpha centauri in a while and it's two stars well played guys well played you know that that whole three body problem thing is also kind of cool if you think about it like you know the the all of these possibilities of the user and the app and the front end and the back end and how it's just uh recombinatorial in so many different ways that i don't know it just seemed like that kind of fixed tidal gravitation was a nice visual acoustic uh ideac metaphor for it yeah if you look at the at the blank space the non-space it's actually also an infinity sign right

kind of pretty close it's either sideways eight or the number eight leaning over that's right a lot of depth to this i think you guys have thought it through as the point that we're getting to where you got very lucky with a very cool logo. And a name that's unique but hard to say for people around the world depending on your dialect. I like that, though. I mean, the name, it makes it challenging in some cases, I guess, if you're trying to say, hey, go check out Tari.

Well, you got a Tari app. Well, how do you spell Tari? Well, you may spell it differently because you may be thinking of Atari, A-T-A-R-R-I, I believe is how you spell Tari. So you may go just to T-A-R-R-I as an example versus T-A-U-R-I.app. So it does make directing people to the brand somewhat challenging whenever you have a challenging name to pronounce. Tough question. What's the best circle constant? Tough question. Yeah, that's a tough question.

What do you think? I would say Tao. I'm a Tao club fanboy. Okay. Just less division, right? Sure. How much division, right? Sure. How much division is involved? Well, I mean, 2 pi r.

Isn't that how you calculate the area of a circle? But if you know Tao, you don't need to do 2 times something. You just have it. I like how he drops that and then he just takes a long pause and takes a drink of his drink while we just sit here and think about it. Okay. Very nice. Well, very nice. Well, you're a deep thinker, Daniel.

Maybe go deep with us on the origin of Towery because you've been working on it a while. It's 1.0 now, but that was even after a very long nine-month beta. So I'm assuming it took more than nine months to get to here since you had a nine-month beta. Give us the backstory, why you created this project, who's involved, et cetera. Oh, gosh. Well, we've been working on it for just over three years now, since May. And it goes back to a different open-source project

that I was involved in. My friends and I, we were working on a project called Quasar, which is a Vue.js system for building websites and spas and SSR apps and Electron apps and Cordova apps. And I was always kind of interested in outreach and getting into other ecosystems. And I reached out to the wonderful people over at Purism. They make this PureOS open source conform system. I mean, the company is following these ideas of open source and the products are following these ideas. And I thought, well, hey, maybe I can stop over there and ask if it's possible for us to figure out a way to work together. And we start putting some of these Quasar apps on their app store.

And they're like, oh, cool. That's awesome. So how are they made? And I was like, well, you know, we use Vue.js and Electron. And they're like, whoa, we can't. Here's a long thread over at the FSF and read through about ungoogled Chromium and why some header files aren't appropriate. that what I thought open source was wasn't always what open source really was. And just saying that something is open source and putting it on GitHub

doesn't mean it really fulfills the needs of the Floss community, right? I guess the difference between free Libra open source software and open source software and open core software is that core softwares that everyone kind of has these different feelings about how, how you enable other people to use your code. And at any rate, and as fate would have it kind of dejected a couple of days later, a really good

friend said, Hey, did you check out the WebView library? And I was like, okay, well, fine. I'll go look at it. And this was like a combination of projects. There was a developer named Zserge who wrote a bunch of C and Objective-C bindings for the platform-specific WebViews on Windows, Mac, and Linux. And then we found a rust port and so we did a first uh practice lucas and i with go and then i think i think i did the first c example and then lucas did go and we're both like this isn't really nice and then we found the rust library um the rust library kind of helped us and allowed us to get to a kind of proof of concept

really quickly and you know what we were seeing was kind of this like daniel lucas said is this right like the app's only two megabytes and and you know we've been using electron apps and are used to things weighing 600 700 megabytes in the download. And, okay, it was just a dot app. You know, it wasn't like all of the crazy MSI installers and DMGs and don't get me started on the Linuxes. But it was kind of tangible and real. And we were both really new to Rust, like totally unaware of the complexities of the stuff we were getting ourselves into.

And we had these proof of concepts. We got it working on Mac and we got it working on Linux and we got it working on Windows. And that's kind of the time when I think we got slash dotted. No, we got hacker news first. And it was kind of this almost raging, how dare you not ship Chromium. And it was interesting because it kind of gave us an uptake and it gave us some visibility to the larger community. And then just one after the other, these amazing people joined us who really believed in, yeah, we can make it more energy efficient, we can make it more secure, and we can really follow in these open source ideals and do our best and stay transparent and accountable. And, you know, things went, went pretty well. We got further and further and then boom, COVID

happened. And I think, you know, for, for those of us who were around and active in software and especially open source, it kind of got to be, I don't know. I mean, I know personally, I had a, just this like crazy experience of not knowing when to stop. And that kind of led to this weird COVID burnout. And we're all just like, oh my gosh. All right. So the world's ending, let's go have a barbecue. And, and, you know, things kind of got back on track. And then, you know, the investors started like ringing the doorbell and, you know, the venture capitalists who will remain unnamed. Like, I don't think there's anything wrong with open source software becoming commercialized. But it scared me because I've been working in open source projects for like almost two decades and I didn't want this project to become corrupted by some kind of capital that starts dictating the direction it

has to take. And, you know, we kind of ghosted the first VCs to call us and went into overdrive and registered Tauri as a program within the commons conservancy, which is a Dutch organization around an L net that really exists to support open source projects and protect them, and especially to protect the code and to protect the community. I mean, we've all heard of bus factor, but, you know, I think that the ability for money to corrupt ideas such that the original vision gets lost. I mean, I'm not saying that's the kind of militarization of open source that I'm most worried about, but for our project, we really wanted to keep it in the hands of the community. And I think that that was really the right decision at the time because, you know, as time went on, we got really close.

You know, we built our betas and then we decided to get audited, right? Which is a little silly. I mean, who are we? It's just some friends and an open source project. And then, you know, we got some grant funding and we took our donations together and we had an external horizontal audit of all of the libraries and a vertical audit of an example app. And I have to tell you, if you've never had your code audited, it can be scary. But I think what we all learned from the experience is that it's really exciting when your presumptions are challenged and you get to a point where you realize through the help of the external pen testers or auditors or code reviewers or whatever it is you want to call them, that you can actually continue to make your thing better. And, you know, we obviously published the finding after we did six months of work rebuilding the parts that were problematic. And yeah, and now here we are a couple weeks post 1.0 launch. And it's so exciting to see the gravitas of the future in the team because, you know, up till now, we do have a change log that we, you know, implemented in probably the first six months so that we can maintain the history of what we've built. But now you have

other concerns like what parts do we have to audit next? And what is our release strategy going to be? How are we going to branch this? And it's really exciting to see the working group come together. And... Well, it's a journey for sure into your story. I think what stands out to me really

is your desire to be true to what you consider open source roots to be. And we've covered all the aspects. And you're right. Money can corrupt things. It can also inject a lot of capital for the good. So there's both sides. It's interesting to see how you were, I can't recall the word you used, like afraid or you got fear from the VCs coming.

What was the word you had said there about your your feelings but just how it can corrupt things and that's one thing i'm taking away from this intro really is just how you how this journey has been and how the possibility of venture capital being able to corrupt that because that you also have a governance model in place you have not only do you have that you have like a what's it called a social contract so like you've done some things to like put faith into the community and your trust in the community so that's definitely evident what's your personal end goal with this project you personally that's a longer story give us a tldr so i mean i'm a short filmmaker that's where i

come from you know i graduated in the fine arts from Bauhaus University, and my thesis project was a real-time analog holographic projection system that I built from scratch, including five video projectors back in 2004. And I've always been a filmmaker. It's how I started my I liked the ideas behind it. But as I got deeper into it, I realized it needs a testing framework. And so I built that. And it's kind of like the deeper I go down this rabbit hole of having the perfect tech, the deeper I have to continue going. And, you know, I think that for me, finding that Zen is when there's no more tools left to make, when I'm unable to, you know, find a better way to do something when my friends and my community and my partners and the businesses I'm involved

in all say, well, guys, we did it. Then, you know, you'll find me in my studio making films because I, you know, I kind of, I tried to follow my principles and did my best to make the world a better place. But ultimately, honestly, I've been scratching my own itch. You know, if something isn't working, why isn't it working? Can I fix it? If I can't fix it, can I build something better? Is it really truly better?

I don't know. Can I build something better than the other thing that we built? And, you know, that's, for me, the end goal is as a tool maker as an artist as a communicator i think that the path is the goal but i don't know end game gosh it's hard to say could you do both i mean it was gonna be an and or or can you make films in pursue this pursuit absolutely Absolutely. That's actually what I'm doing next week in Malta. I'm shooting a series of short films. Nice. Nice.

The reason I asked that question is because it helps me understand why the fear of VC was there. And why, because the question is like, well, where are you trying to take this thing? And your answers are all beauty, art, perfection, curiosity, community, relationships, perfection. I already said that one. But they're very much, these are intangible artistic things that aren't like, well, I want to have everybody using this to build their desktop applications. I'm sure that's probably maybe a piece of one aspect of it, but it's just I'm trying to understand. I agree there's the balance of the needs of the humans working on the project and the goals of the project and are working on retrofitting Servo to become a web view provider for Tauri. And where we think this could go might be a truly secure and

privacy respecting browser. Maybe that's as far as I can think. It's a massive undertaking. It will require enormous amounts of capital that will probably have to come from VCs and the European commission and places like that. You know, I would like to backtrack a little bit to this point in time where the VCs started contacting us. We weren't ready as an organization. We weren't mature enough as a group to even consider those things as possible. We didn't want to take capital until we knew we had a product like a 1.0. And we might be taking capital in the near future and we might be starting a company. It's a group decision and there are some possibilities out there that are really exciting. And I'm just so glad we didn't go down that path too early

because I think from what I've seen in the investment world and in venture capital world, when you go in too early, I think what you sacrifice is a little bit of backbone and knowing where you come from, what it is you're doing, where you're going. And I think that taking a massive amount of cash for a young group can also poison relationships and make things challenging. And I think after three years, it's something we're going to be looking at. I think that's fair and wise, especially when you're trying to figure out who you are as a group. Money makes things more complicated. Now, a lack of money can also make things very complicated.

Like, hey, I can't work on Towery today because i have to go do a day job or whatever it is do my thing yeah you know so these are different trade-offs that people make you want to give the quick nutshell of what towery is as it exists today because we're assuming the listener has some context which i hope they have but't have. So just lay it on the table, what Tauri is as a 1.0. Sure. Today, Tauri is a framework that lets you create desktop applications for the major OSs. And I'm counting Linux under the major OSs because there's about a dozen there. And it does so by leveraging kind of the best of both worlds of software engineering. So people who are familiar with building front ends and GUIs with web tools like, I don't know, Vue and React and Angular and Vite and all of these great, crazy tool chains that allow you to compose JavaScript in a higher level language like.svelte or TypeScript and render out basically HTML,

JS, and CSS, which gives you as a visual designer, a user experience designer, builder, the opportunity to, you know, leverage the best parts of the browser, which, you know, are styling and theming and in some cases performance. While on the backend, what you have is a highly tuned core, like an engine, if you will, that is built on Rust and only ever ships the pieces of the project that you really need. And I guess as opposed to shipping an entire Node.js runtime, one of the ways we get smaller is we only ship those code points that you actually need for your app. And, you know, it's not necessary for you to even know Rust. You can just consume the APIs. You do a little configuration file that's all documented, and you can consume those APIs for Tauri in JavaScript.

And the API I call passes a string message to the Rust core, and the Rust core then responds depending on what you want to do. You may want to open a new window or visit a website or send a notification. putting this core system interface behind the confines of relatively safe Rust, what ends up happening is that this kind of barrier between the two systems provides a greater degree of operational security. And in a nutshell, Tauri provides a bundler that allows you to create versions of your app that are then compatible for the platform upon which it was built. You can also use our open source GitHub action to compile for all of your platforms. And we also provide a updater system so that you can basically publish an update to your update service and all of the apps that are online and listening will download an update. Sounds trivial, but it's along with

package management, maybe one of the more important parts of modern software. Tauri also offers a plugin system so that you can enhance the features and functionality of your app above and beyond what it is the core offers, such as a YubiKey integration. So there's a Rust library that integrates with the YubiKey, and you can send a message from the user interface to the Rust core to say, hey, authenticate me, please. And then the Rust core negotiates all of that then with the YubiKey. And that's just one example. I mean, there's lots of other things that people have been building and that we also manage for the plugin ecosystem.

And maybe the coolest innovation that we have is an isolation pattern. of the audit findings, which more or less showed that our bridge between the front end and the back end can be corrupted in the case of illicit code running in the browser. And so what this isolation service does is it only allows API commands that are authentic to run through the bridge. There's a wonderful write-up by the author, Chip, a member of the core team, who it goes into great length to explain the backdrop of it. But the important thing is it is now possible to secure the front-end and back-end communication against illicit injection or XSS or CSS attacks or SVG attacks or whatever. Nice. So you have these three aspects of your philosophy. I think you're speaking to the security aspect through that cool innovation. Yes. You also focus on privacy. This

is from the 1.0 blog post. You have the security, privacy, and then the environmental impact, which is an interesting way to think about what most of us developers tend to think about first and have the environment as an afterthought is performance. You put the environment first and have the performance be kind of the afterthought. I kind of like that casting. But here you're speaking to the app size.

I assume the CPU cycles required, etc. is your other third aspect. Well, the interesting part about shipping less code is there's less possibilities for gadget attacks to be introduced. So by shipping less code, you kind of fulfill the environmental aspect as well as the security aspect. Now, with regard to the privacy aspect, this has a lot to do with the fact that we are working on helping younger engineers learn how to do things. And what I've noticed in my, I don't know how many years on help desks is that the tooling has gotten amazing. The developer experience is so great that you don't even have to know what you're doing anymore and you can make and ship an app.

And where we're trying to, it sounds terrible, we're not trying to educate people about doing things the right way, but we're more interested in fostering an environment for engineers to reconsider their perceived ideas about how software has to be developed. It's not free real estate. I mean, just the number of applications running massive bloated binaries and consuming transit resources is mind-boggling. And by developing from a secure perspective where the things you build are always secure, it's not, oh, I'm building a developer app and it's only going to be for insiders in my company. We try to take the other approach and say, yeah, you may take shortcuts, but you're making yourself vulnerable. And so by kind of cementing

these principles into what it is we do and how we talk about it, it's really our hope that we're able to present not only a framework for making better apps, but ultimately a community that's more aware of the fact that the planet is burning, that every single thing that you can do to help that is so important. Even if you don't think it's much, every little act helps. And I'm really not greenwashing here. I mean, I live in Malta. It's 42 degrees. We have floods everywhere on the planet, except where there's no floods and there's no water and there's no basins. And I'm not saying that smarter software is going to solve these problems. Smarter engineers will.

And that's the next generation. And, you know, to come back to your question, maybe that is the end game. Because literally the week before we released the 1.0 of Tauri, Explorer got retired and so did Atom Shell. And software projects like Tauri, like Atom, like Explorer, they have a shelf life. At a certain point, the next thing comes along and hey, maybe Tauri is able to continue evolving. Maybe not. But what we can help people do is think about what it is they're doing, why they're doing it, and offer them a framework for thinking about better ways of doing things. Hmm.

That reminds me of our conversation we had with Jessica Lord last fall about Electron and her work on Electron and how it changed the game and allowed so many more people to develop cross-platform apps that otherwise wouldn't have been able to because so much investment, both in education and just time, in building the same app for these different platforms. I'm sure you know that quite well at this point, building an application like Towery that people build upon. And she said, I was asking her about how she feels when people hate on Electron on the internet, which is something that we do on the internet,

is we hate on Electron. And she said the haters have a good reason to say the stuff they're saying because it's got a lot of warts. It has a lot of problems. And one of the haters have a good reason to say the stuff that they're saying because it's got a lot of warts. It has a lot of problems. And one of the problems that it has are these large hundreds of megabyte application bundles that are produced with Electron apps. And she said at that time, like, somebody, maybe it's the Electron team, but somebody needs to come out and innovate and change, and the next thing at some point will take over or will augment or challenge Electron to change the way they do things. Now, if it's completely built around Chromium versus not,

that's the foundational aspect of a technology, it seems. And so maybe a difficult pivot for Electron at this point. But Tauri definitely, I think, is well-positioned because of these very small app sizes that you all produce to change the game once again and allow better cross-platform apps to be built.

The smallest app size that I know of was 450 kilobytes for a functional Hello World macOS app. Granted, the ICNS, the icon file for Mac, if you

play it right, the icon is generally the largest piece of your code base. I was going to say, they like to have nice, big icon files. Yeah, there's your 700, 800 kilobytes right there. And the code that we need to build the app is 300 kilobytes. If you write solid, tight, minified JavaScript and you use SVGs, you know, and you do like the awesome parts of Rust compression, then you can absolutely get down to two, three megabytes for a small app. For massive apps, okay, sure, there's maybe a bit more JavaScript

and then it's eight or nine megabytes. But even then, one of the nice features that I really wish Electron would figure out that we offer is that we don't ship the blank JavaScript because the ASAR file that is shipped with Electron is basically the entire code to build the app. And because of the way that Tauri, it doesn't use a web server.

We use a custom protocol, so there's no extra ports flying around and because of the way that the entire bundle is crafted you can i suppose you can you can introspect some strings in a hex editor but recompiling it is a master class in uh in reversing it's not like um you know somebody posting on reddit oh i copied all your code and I made a fake app. And I think for the security conscious out there, we understand that nothing is perfect, but every opportunity that you have to slow down an attacker and make it hard for them, the less interest they are going to have in breaking into your app and, you know, hacking around.

Obviously, everything is hackable. I mean, I'm on a computer right now and it's hackable. I use a phone. It's software with hardware and, you know, storage devices. It's hackable. But doing our best is better than making excuses, I think. And we try to really not just say that we're secure or more secure, depending on who you talk to, but we back it up with the audit.

And I guess that's the big thing from the 1.0 is that the 1.0 was audited and we resolved all of the issues that were found. This episode is brought to you by Influx Data, the makers of InfluxDB. Increasingly, time-series data is all around us. It's in the cloud as applications and services scale out. It's in IoT as more and more devices come online. Sensor data is time-series data, and that's exactly where InfluxDB comes into play. InfluxDB is the open-source time-series data platform that allows developers to build and to integrate applications with time as a foundational component. InfluxDB is made for developers to build real-time applications quickly and at scale, and they keep improving their platform to build those applications with less time and less code. Recently, they launched their Edge data replication feature.

This new capability is built into the 2.2 open source version. It allows developers to replicate data from local instances into InfluxDB Cloud, enables users to aggregate and store data for long-term management and analysis and to satisfy regulations. It brings the horsepower closer to the sensor and gives developers and solution builders the ability to leverage their own elastic compute resources deployed at the edge. Edge data replication lets you decide strategically what data moves from edge to cloud, how the data should be enriched and formatted. Add to this, InfluxDB has ongoing efforts to unify APIs across all its database offerings. They now provide a path to build once and deploy time-series applications anywhere. Learn more about InfluxDB and this new feature at influxdata.com slash changelog.

Again, influxdata.com slash changelog again influxdata.com slash changelog so we've talked about these three pillars of i guess your you know your philosophy the tower philosophy security privacy and environment just to remind the listeners. But performance isn't in there. Although it's kind of like part of the future of the web or any sort of application like this to be performant. But imagine that smaller file sizes lean towards performance for obvious reasons, like it downloads faster, it installs faster, it probably runs faster, less to load into memory.

But yet the word performance didn't make it into your philosophy. Is it just baked into all three or is this the grand vision or is it just missing? Sometimes we do call the apps high performance and there are bottlenecks. And in my experience with projects using Tauri, it really comes down to who is doing the architecture, what kind of architectural paradigms are they familiar with and comfortable with. you know, the crypto library from JavaScript to create a random number. And it'll take a couple cycles. It's JavaScript. It's still pretty fast. You can do the same calculation in Rust. And it might be slower because you have to pass a message to have that performed and then return the result across the bridge. But for me, the performance, that's not the big issue. I think a lot of people on the Twitterverse and in Reddit and Hacker News and wherever are always looking at memory consumption and how much memory is being used. And we do track and compare between like a hello world with Electron and a hello world with Tauri.

And, you know, we find that the memory consumption is similar. Your boot time is similar. And a lot of that has to do with just the way that web views have been built and managed as adopted stray cats for the browser ecosystem. And the standards bodies are run by a lot of super intelligent people with vested interests. But there's no web view standard. You know, the way that, that Mac OS serves out their versions of the web view, as opposed to how windows is now doing it, as opposed to the way that a WebKit GTK tries to do it across Linux platforms shows that everybody's just kind of trying to figure it out while they go. And because of this, we see Tauri core at the moment kind of as a collection of ugly hacks and workarounds so we can get it to work.

And we manage that and it is working. But in the long run, it's not really tenable. The big performance issue that we have is the bridge. It's serialization. It's about passing data from one side to the other. There's no real shared memory between a front-end and a back-end in a web view. And where we're excited about working on Servo is rescuing this grand project that had such lofty ideals and repurposing it such that we can get the performance back from the WebView bridge by using shared memory. And it'll be marginal. It might be a little bit better than we're at right now, maybe twice as fast, maybe 10 times as fast in some cases.

But for me, and I think for the team, the most important features are the fact that it's secure and robust. And I mean, we still need benchmarks for the GL windowing that we're bringing out. I do expect that to be several orders of magnitude faster than a web view because it's just shader response. And yeah, I mean, why not performance? Well, you talk about the environment too, right? Like in terms of, you have in this 1.0 blog post, you have a full-on table of how app size impacts the environment. is planning to be or attempting to be what Electron could not get right because of Chromium and other, I guess, hurdles in its way to get to perfection

is performance. And every developer's issue with Electron when they cry on Hacker News, Lobsters, wherever they go, is usually app size, which you've already talked about, but then also performance. It's like, well, I've got this application, but it runs slow. It loads slow. It's not a native app, and I want native, et cetera, et cetera. So performance seems to be the key thing.

Well, see, that's exactly the thing. No, native apps. I believe that that was an attempt to throw mud in the face of Cordova electron capacitor engineers, which is, yeah, your app runs so slow, you don't even get 60 frames per second if you're running a list with a thousand elements. And that kind of performance, well, maybe we're sidestepping that because when you use the UI, the user interface, just to do user interface stuff, you've got lots of overhead. But if you're using it to do fetch and web sockets and, you know, keep your interface GUI and also do some kind of random intervals and you're all, you're stuck on

this thread, maybe you've got a web worker. So if you're lucky, you've got two threads intervals and you're all, you're stuck on this thread. Maybe you've got a web worker. So if you're lucky, you've got two threads, but you're still sandboxed by the operating system. So at best, you're going to have two node JS might have one or two, but with Tauri in the Rust core, just take all the threads you need. If you need to do thousands of computations to the nth position of tau or pi, I wonder which app would be faster. We might make that challenge on Twitter

when this changelog podcast comes out. That'd be a good one. Let's do a battle. Tau battle. So a lot of people would want to use Tauri at this point simply because they're going to get that two megabyte to five megabyte binary, right? I mean, I would.

And a lot of Electron apps are like very little Electron. It's just like the corners, the edges that you need. Maybe you have like a menu bar app. I mean, a lot of, especially dev tools, right? Like we're scratching our own itch. I would love this to be a menu bar app. Especially dev tools. We're scratching our own itch. I would love this to be a menu bar cross-platform. Maybe I have a little bit of code that runs and I throw in Electron and it's a menu bar app now.

And that's great, except for it's like a 500 megabytes. Menu bar app, there's a lot of bloat there that could be avoided. Are people porting to Tauri? What does it look like to port, et cetera? Well, it really depends on how dependent you are on an electron. Well, let's just take that simple case of like I'm using it to help shim into the menu bar. My otherwise CLI kind of style tool that's like, you know, shelling out and stuff.

I mean, how much is there? Jumping into a menu bar is probably going to require you to write a little bit of Rust. Okay. Menuing and that kind of task bar interaction is still a little complicated, but absolutely doable. The interesting thing that we've heard from a couple of projects is they've been using rust to write their node.js libraries you know so they use the napi and they render their rust out and then they consume the napi in their javascript in their electron app and they were like oh this is great i can just skip this compilation step and instantly consume my rust that i've already written and know very well, and I have one less breakpoint.

And it absolutely does work that way. And for trivial apps like a Word a Day app that is literally just some HTML, CSS, and JS, you can take that entire rendered dist folder or whatever and point the tower rebuild command at it. And if you're not doing anything funky you're done and you didn't even have to really touch a line of rust nice maybe a different word a different version of jerry's question might be where is the sweet spot if someone is porting what kind of app could be ported or greenfield that's like sweet spot for Tauri right now? We're seeing a couple different groups of projects come together. Developer tooling is great,

especially if you're consuming something remote over a web socket or something. People can do that. You can use the web sockets in the front end or the back end of Tauri. It just depends on your side. Security focused things like password managers are interested and actually using Tauri right now. Not sure if I'm allowed to mention them. They're a sponsor

on your website. Maybe we can mention them and you can neither confirm nor deny. You don't have to say anything if that's not the one with the trouble. I will say one of our

most popular episodes was a rebroadcast of a show about them being all in on their web stacks. I mean, what they're doing around the web stack is very interesting to many. Well, I'm hesitant to name any kind of names, but things that are developer tools, that are utility tools. We saw somebody make a Twitch stream subtitle plugin system for OBS, for example. So I think the sweet spot are apps where you might have to do something like cryptography, or you might have to do something with general low level access or where you really want to have granular file permissions. Cause I think we do that pretty well. Like the easiest way to get started. If you're a node JS developer is really

literally just to NPX create Tauri app. And it'll tell you that you still have to install rust if you haven't installed rust yet and then it'll compile away after you you know set up the npm run dev command or whatever and you'll have it up and running so i think the neat part about it is just the diversity i it's hard to say we have started our awesome Towery repo on GitHub, and every couple of days a new project floats on in, and it's just like, oh. What about if the app wants to be your digital HQ and maybe transform the way you work with one place for everyone

and everything you need to get stuff done like maybe slack.com oh wow slack um as an experiment at one time we did embed slack.com into a towery app and it worked but i also know that that slack is a deep believer in Electron. And for good reason, because it's a wonderful user experience. I think amongst the 10 chat applications that I have, it's kind of the most well thought out. I do appreciate their user experience. They have a lot of deep integration.

So you have a lot of file access stuff. You have a lot of notifications, operating system level notifications. The kind of places where I think that cross-platform apps usually fall down is in the tighter way. There's two ways that we think about native apps, perhaps. One of them is performance. Like, oh, that's native, it's fast.

You were talking about the scrolling, right? But the other one is how much does it feel like the other apps on your system? And how much does it have those native dialogues or those native file pickers or et cetera? And I'm wondering where Towery is with those kinds of features, those kind of integrations into the platforms. For Mac and Windows, it's native windowing.

So you can also modify it. On macOS, you've got this little stoplight at the top and then the title of the app, and that's just kind of the generic app Chrome. But you can remove that. You can make the entire window transparent if you want. You can make it always on top. You can, which actually isn't something that Mac does that much,

but the file picker, the directory picker, that's just native NS elements. Tabs, native tabbing, native preferences. Yeah, we are integrating with the system light and dark mode. So you're able to do that kind of deep insight into or not deep insight but you know this kind of expected user experience where right if they're on a dark mode then the app registers that it's in a dark mode and can pass that down to the user interface this this native talk really reminds me of applications or maybe even

particular developers, individual or conglomerate, whether it's a small team or not. They choose, let's say, for example things. They're pretty much Mac OS only. And I wonder sometimes if it's just because it's been super difficult to multi-platform. And so it's easier in some cases just to be, I care so much, or we care so much about native look and native speed and native whatever, all these native things that make it feel like this is Mac only. And some of that might be it's just hard to multi-platform

or they're just so focused on macOS for whatever the reasons are. History question. Does Windows 7 have native notifications i wouldn't know it does not no it does not okay and i think you know if we look back to the past 10 years of operating system evolution on the one hand you have like this mass exodus from a style in the Linux community where not only do you have a driver for your screen, X11 was very popular for a while, but I heard it's being dropped. Okay. So you've got the driver. Then you have the user interface. You know, maybe it's GNOME, maybe it's KDE, maybe it's something else. Now, each of these apps have different understandings of what the desktop does.

Or not apps, but, you know, these kind of GUIs and different ways of registering them. And then in some of them, they don't even like you to have a taskbar anymore. And what we've discovered along the way working inside of the Linux ecosystem is that the matrix of things that you have to understand about that entire ecosystem in order to make a multi-platform Linux app is mind-boggling. Even are you going to use AppImage or ShipDev? What about Arch users? How do you get it to them? And it becomes this practice of finding the least worst compromise, I guess. And Windows, thankfully, they've, believe it or not, built WebView2 on top of chromium yay but what windows finally did i think what they do better than all of the others you know webkit wk webkit from mac and webkit gtk from the linux community is they have a rolling evergreen release so that you can constantly just subscribe to that and your system will keep the web view to up to date.

And you can, as a developer say, nope, it's this version and I'm shipping this version with you eat the 30 megabytes, but you have those options as, as a developer. And to come back to your question about why is multi-platform so hard? It's because it's just different user experience dialects and different source, different ecosystem requirements. I mean, on Mac, we can't go back in time before 10.13. I don't know how long it's going to be until Mac just says, all right, you guys, anyone who's still using Intel is out of the game. And at that point, we definitely have a fractured ecosystem. So how do we even notarize Mac apps if they just deprecate the whole architecture?

I don't know. I'd be sad because I do have some Intel machines lying around that I keep using that are still useful to me. I mean, it's got to be five, ten years away because there's a lot of machines that are out there right now. The reason why I brought up things in particular in this idea of the difficulty to multi-platform is, does Towery, and Electron has promised us, but some just don't go down that road, but does Towery enable teams like Things, for example, to go beyond Mac? Because there is obviously a market share of people who want to do to-do lists. I mean, I love Things. I'm a user of them. That's why I'm mentioning them, because it's just got a phenomenal user experience on

mobile and on the desktop. And I don't use other well-known to-do apps because their experience from one version to the next doesn't match. Things has been focused on that. And I'm just wondering, does Towery enable a team like that to more easily, in quotes, more easily, multi-platform? I would like to think so, but I don't know things tech stack. Right, specific things, yeah.

Did they use Cocoa? Yeah, Sync and stuff like that. Yeah. It's been around a long time. They've put a lot of engineering effort into focusing on this platform, getting it right. And they've probably gone through iterations where they're like, oh, no, what do you mean WebKit? Whatever is gone now. And I mean, maybe they're not even using the WebKit.

Maybe they're just like 100% metal these days. Maybe they don't use Objective-C. Maybe they do. Maybe they're writing in Swift. I think once you start down a path, that's kind of what we mean with Brownfield. Once you start down a path, you kind of set your limits. And what I think Adam Shell and Electron and Node WebKit have done is they've allowed engineers to kind of hedge their bets because now you can, for the most of your code, take it from Electron and move it to Tauri or move it to somebody else

who does something similar. Neutralino, for example, it's the HTML, JS and CSS that you care about. And then you just have to glue it together with a backend. And what that does is it allows your architectural debt to sort of resolve itself

as a new technology comes along. You can take the stuff that you've been building and port it over. And yeah, I think that it has a lot to do with the team. I mean, I don't know what else to say. What about other platforms? There are other platforms. I notice you don't call yourself a desktop solution anywhere

that I can see on the main website because, well, I wonder if that's because there's other platforms that you have planned such as these mobile devices that we all know and love so well yes we actually have prototypes of ios and android working already nice uh we we've been waiting until the 1.0 landed in order to bring them kind of more to the forefront. The place where they exist is in one of those three libraries that we talked about in Tau and Rai. So we can do windowing, we can communicate with them. And now we have to raise them up to the Tauri layer where they then interact with the apis that you need like the file system the camera the bluetooth and then also create the final apk or apple blob and get those on the

app stores so it's very early days for that we're also interested in getting the apps on other devices. I remember when, gosh, when was it? This was a year or two ago when one of SpaceX's rockets went up and somebody mentioned, that window, isn't that Electron? And it turns out they were using Electron on the rocket ship. And I think that, you know, okay, it's a nice dream to have, but as, and if our civilization keeps on progressing, I do expect us to start being able to ship apps to other devices like augmented reality and to watches and to your smart TV and even to embedded systems. I mean, one of the neat parts about Tauri is that you can use it as a CLI. You can interact with it from the perspective of a CLI. You can hook apps up together so that they're communicating in a distributed way. And I think as people start to realize, okay,

we can think about these applications, these devices that we're using as, we can still think of them as thick clients, right? It's not like it's just a dumb screen and a keyboard. These things have amazing processing power and we can reduce these requirements of putting our data into corporate silos. And that's where the privacy comes back in, right? By allowing people to own their own data, to own their own identities, to manage their own things because their devices are capable of it.

Maybe that destroys some business models, but I think that for a growing type of engineer, it just makes more sense. Like, why would you pay for a cluster of highly available database servers and some API endpoints behind a CDN? Or when you can just have the apps talk to each other. You just have to negotiate a point where they can meet and they can send all their data. Why bother having databases when you can trust your users? And that might be the final paradigm shift that we're after. This episode is brought to you by Sourcegraph. With the launch of their Code Insights product,

teams can now track what really matters in their code base. Code Insights instantly transforms your code base into a queryable database to create visual dashboards in seconds. And I'm here with Joel Kortler, the product manager of Code Insights for Sourcegraph. Joel, the way teams can use Code Insights seems to pretty much be limitless, but a particular problem every engineering team has is tracking versions of languages or packages. How big of a deal is it actually to track versions for teams? packages. How big of a deal is it actually to track versions for teams? Yeah, it's a big deal for a couple of reasons. The first is, of course, just compatibility. You don't want things to break when you're testing locally or

to break on your CI systems or test systems. You need to have some sort of level of like version unification and minimum version support and all of that needs to be, you know, compatible forward. But the other thing we learned was that for a lot of customers, especially, you know, engineering organizations that are pretty established, they have older versions of things, or even older versions of like SaaS tools they don't use anymore that they haven't fully removed, because they're like, not sure if it's still in use, or they, you know, lost focus on that. And they're spinning up old virtual machines that they're still paying for, they're using, you know, old SaaS subscriptions, they're afraid to cancel, because they're not sure if anyone's actually using it. And so getting off of those versions,

not just like saves you the headaches and the risks and the vulnerabilities of being on old versions, but also literally the money of, you know, older systems running more slowly or the build times or, you know, virtual machines and SaaS tools that you're no longer using. Before you had this ability, we talked to teams, there were basically three ways you could do this. You could slack a million people and ask for just like an update point in time. You could have sort of one human and one spreadsheet where like it's somebody's job every Friday or every two weeks to just like search all the code and find all the versions and write it down in a Google sheet. Or there were a couple of companies that I came across

with in-house systems that were sort of complicated. You had to know, you know, maybe Kotlin, but you didn't know Kotlin. But if you want to use this system, you had to learn Kotlin and you'd have to sort of build the whole world from scratch and run basically a tool like this with a pretty steep learning curve. And now for all three of those, you can replace it with a single line source graph search, which is basically just the name of the thing you're trying to track and the version string in the right format. And then we have templates that will help you get started if you're not sure what that format is, and then it'll automatically track all the different versions for you, both historically. So even if you start using it

today, you can see your historical patterns. And then of course automatically track all the different versions for you, both historically. So even if you start using it today, you can see your historical patterns. And then, of course, going forward. Very cool. Thank you, Joel. So right now there is a treasure trove of insights just waiting for you. Living inside your code base right now. Teams are tracking migrations, adoption, deprecations. They're detecting and tracking versions of languages and packages. They're removing or ensuring the removal of security vulnerabilities.

They understand their code by team. They can track their code smells and health. And they can visualize configurations and services and so much more with Code Insights. A good next step is to go to about.sourcegraph.com slash code dash insights. See how other teams are using this awesome feature. Again, about.sourcegraph.com slash code dash insights. See how other teams are using this awesome feature. Again, about.sourcegraph.com, slash code dash insights. This link is in the show notes.

And by our friends at Retool. Retool helps teams focus on product development and customer value, not building and maintaining internal tools. It's a low-code platform built specifically for developers. No more UI libraries, no more hacking together data sources, Thank you. Out there, trust Retool, Brex, Coinbase, Plaid, DoorDash, LegalGenius, Amazon, Allbirds, Peloton, and so many more. The developers at these teams trust Retool as their platform to build their internal tools, and that means you can too. It's free to try, so head to retool.com slash changelog.

Again, retool.com slash changelog. So, Daniel, there's, I'm sure, a mounting amount of people listening to the show now. 20, 30, 40, 50,000 people. Who knows? Curious about the future of multi-platform native application development. And with Tara, what's the first step? You got some prerequisites. Rust is a prerequisite. Pretty easy from there, right?

But then you've got... Actually, that's the only prereq. You can do your entire app in rust if you want to run all of the towery commands you can use the the rust version of npm yarn pmem it's called cargo generally speaking the majority of people will need node.js if they're doing something like a front-end language like Svelte or Vue or whatever. And depending on your development platform, you're probably going to need some other tooling. Chances are good that you already have it installed, but if you don't, we walk you through the couple things that you might need. Basically, at the end of the day, you need a C compiler because we still use Rust.

There's a couple ways to do it, but GCC, for example, is pretty common. And yeah, then you're good to go. You need a computer. We did have somebody trying to develop Tauri apps on Android and kind of didn't work that well. You can develop headless. There's ways to test with XVFB on Linux. So you can kind of emulate a screen. But generally speaking, a keyboard, an IDE, like a development environment, a lot of people use VS Code, VS Codium, you know, take your pick.

As long as you can edit some code, you might want to have Git installed. It's not a requirement, but modern engineering is kind of moving toward that distributed collaboration. It's what we use, but not a requirement. So, I mean, the easiest way to get started is probably for a lot of people, I would say the majority is going to be in the Node.js ecosystem. So pick your favorite framework and we probably have a starter kit for you so you can run the create towery app which is a library that we built in node.js that scaffolds up your entire folder structure so you get your you know if you're using react or spelled or whatever you get all of those node modules that you need to set it up and you

get a dev server that you then use to get your hot module reloading while you're developing the app. And yeah, it's pretty straightforward. We've tried pretty hard to get it to work for almost everybody. I think we're at parity now between the three majors, you know, macOS, Linux, and Windows. And then, you know, you're going to want to build your app. And what we've found is bundling for all the platforms is complicated. And that has a lot to do with the way the compiler expects the architecture to work. And, you know, Rust, you can compile Rust for a number of different platforms, but where it always, always, always gets sticky is compiling for macOS. So some people run a couple virtual machines.

They maybe have a macOS as a main driver, and then they run a Linux and a Windows virtual machine, or they have a Linux as their main, and then they run a suite of virtual machines. And as a matter of fact, that's kind of how the CI works. So the TOW reaction on GitHub that you can really easily hook into your GitHub workflow basically takes your towery configuration file, which tells it, you know, what kind of app you want to build for Mac, for Windows, for Linux. So, you know, what kind of API features you want to embed into the system because you're using them or you don't want to embed the kind of CSP security policy that you want. You know, there's a lot of granular functionality

inside of that configuration file. And it's actually all the CI really needs at the end of the day to build out for those other platforms. And, you know, I think that's kind of the skinny, the lowdown on what you need to consider when you want to build for multiple platforms. How do you test those integrations?

How do you test? Sorry. No, the age old question that sucks to answer. It is, it is a sucky question. But no, it's, it's, it's really, really, really important that, you know, you unit test the code that you've written, but how do you integrate? And what we've built is an early version via normal WebDriver.io stuff. And because it's WebDriver.io, you get all of the other goodies that the ecosystem offers.

You know, visual regression testing, if that's your jam, or I've seen even AB stuff work where we do need help. And if you're listening, dear listenership, help with the Mac OS integration of that. Cause we just, we just couldn't get that to work with GUI apps. I know that, you know, for example, Cypress does an amazing job of the way you set up your Cypress tests and the way that it runs through them and it clicks through your user interface. It's really great for websites, for web apps, and you can actually leverage a lot of that thinking in Tauri apps. So you can also run tests on your browser code. Certain things that have to hook into Tauri APIs, well, you got to mock them. That's how that game works.

And we do provide a plugin that helps you mock. And at the end of the day, if you're serious about it, you have a QA team. And they're on each of the platforms that are important to you. I don't think the reality on the ground ever says that it's just okay to do automated testing. I think without users giving you feedback on what you thought was a thing that was working is really important, especially because the guys and girls and folks and people writing the code, sure, they can write the tests, but

they can't quality assure. You just always have these blind spots. I know I'm kind of going off on a tangent and I'm not trying to avoid the question. The answer is... Well, you answered the question, I think, as well as you can. You test in Rust, just like you test in JavaScript. You write your units and you mock what you have to and you build integration tests and you do

QA. Normal software engineering, I guess. Is there any Tauri-specific debugging stuff? Or is it just, again, the same answer as like, well, how do you debug in Rust? How do you debug in JavaScript? You know, there's a really amazing learning tool

for Rust called Rustlings. If you haven't heard of it, go to GitHub, track it down, clone it, run it in your IDE. And the way Rustlings works is it gives you chapters of broken code. And the Rust compiler, say what you will about Rust mutability, about borrowing, about streams, about the complexity of the deep magic involved in unsafe code. What it does have that I wished I'd discovered somewhere a decade ago is a compiler that really tries really hard to help you. If it finds a mistake, it'll be like, well, you know, you've got a mistake here. You can't cast this to that. And it shows you like with a explainer text that you can call up and read about. So the compiler helps you. And

what I find or found hard at the beginning of Rust was, you know, overcoming my deep of how mutability worked. And I didn't have it at the time. And now what I really enjoy is finding out new parts of Rust that I didn't know existed before. So the compiler is your friend. That's what people do for debugging. In the near future, soon, trademark, whatever, we are building static analysis tools to help users, developers for applications, discover where they can improve. We have this notion of an accept list, and the accept list basically in the configuration file tells the Tauri bundler which parts of the Rust API it should embed in the application. And if you don't know what you're doing, it's easy to just accept list the entire API, which makes your app about 1.5 megabytes bigger because it's just extra stuff that you don't know you need because it's very granular. And what we're looking forward to doing is introspecting in the code to find ways for you to improve your security, but also your footprint.

And I know it's not exactly the same as debugging, but from the perspective of wanting to help people ship better software these assumptions of it's free real estate are things that i think are bug so the sense that i'm getting and i want you to like true or false this or tell me if my sense is off it sounds like at this point the promise is somewhat like you don't have to write any Rust, but the reality is kind of like, yeah, you're probably going to be writing a lot of Rust. Is that wrong? Or is that on? Just for expectation setting. You do not have to write any

Rust code. Absolutely. If you don't, if everything is web-driven, web interface driven, and you're comfortable with the APIs that we offer you, you don't have to write any Rust. If you want to integrate a shiny library from the Rust ecosystem or write your own for perfect random number generation or something, then you have to learn a little bit of Rust.

And I think, and this is something we were actually talking about in the working group today, it's not just me. We think that because you don't need to write Rust from the beginning, you can make your entire app this way just by using the APIs that you consume and writing a configuration file in JSON. It lowers the barrier to entry because you can say you have now built a Rust-based application. And just being able to say this is kind of one of those visualization techniques of getting better at things is understanding that, yes, you are capable of doing it. And the fact is people get interested by it. Like over the three years we've been working on this project, a couple people have very visibly improved in their rust. At the beginning, they're like, this is hard. Everything is hard if you've never done it before.

And having Tauri as a gateway to understanding, well, okay, I need a compiler. Why do I need a compiler? Well, having a compiler is good because it makes my app small. Great. So you get that out of the way. And then you discover that, oh, maybe there's this special custom feature that you want to make. And you follow the instructions and you write a couple lines of rust and the compiler's like, oh, you did it wrong. And you're like, oh, okay, what did I do? Oh, that's what I did wrong. And you figure it out and suddenly you've written a couple lines of Rust. So I see Tauri and projects like Tauri that offer an easy access to a complicated language paradigm as a definite win, not only for people who want to learn Rust, but also for those advanced projects that absolutely need Rust engineers. Suddenly we're able to provide a marketplace

for Rust engineers to go out and get jobs. Okay. Maybe not suddenly. It might take a few months. We just got the 1.0, but I think that it's definitely a way forward. It's a way to grow as an engineer. You mentioned before, teased, I should say, other platforms. What's the state of Wasm as it is to Atari? What's the future? Yeah yeah coming soon on the home page so wasm and wazzy are ultra exciting the concern i generally have with wasm in the browser has to do with the linear memory space of wasm and the fact that up until now as as far as I know, it still exists in the global scope. So any kind of security isolation that you thought you had, you don't really have. Where we're going to be going with Wasm first and foremost is providing a Wasm-ish interface for Wasm projects to interact with.

One of them that's kind of common or might have heard of is called U-Y-E-W. Another one is Dominator. And these are basically projects that are Rust native, which means you write your entire user interface in Rust, and that gets rendered out to Wasm. And the problem that those projects have right now is that it's very difficult for them to interact with the JavaScript API from Wasm. So that's actually the very first step down that road. And we have always wanted to branch out into other languages. And what I mean by that is, yes, the core is written in Rust. We plan and want to continue offering further interfaces to Tauri. In one of our examples on the main repo, we have a

a, I don't know how to say this, DY lib that allows you to harness Tauri core from C. And where I think that's going to be able to go in the not so distant future is offering the same type of interface to a WASI environment. So I guess the thing to think about is what is the target of the WASI blob, right? If it's going to be targeting the browser, the browser has a much different permission scope than a Tauri app does by nature. So rendering a Tauri app as Wasm might make sense in some circumstances, such as you maybe want to make a spa or a website from the same app. But at that point, I think we're still in the discussion phase about how much sense that makes. I mean, if you think about it,

you're building a web app using web tech, such as Vue or Svelte. And then you're putting that into a Tauri app that you want to then turn into Wasm so you can put back in the browser. Why not just cut Tauri out entirely? So for us, the interesting sides of Wasm are the use cases for the pure Wasm community and also looking forward to the WASI approaches that allow you to just run anywhere in any context what's the best place or

way to become part of the towery community is there a place y'all hang is there a forum or a discord or a slack hq there is a electron app known as Discord that you can download. You can also put it on your phone. I think that's a capacitor app. There's no Tauri app for this? And that's where you can come and get involved in the research behind Tauri core and plugins and get involved that way. You can also come and ask questions in one of the other channels about problems you might have. And if you like it and you stick around and maybe you file some pull requests and file some issues and start getting involved in the actual making of Tauri, chances are good that one of the people in the working group might reach out to you and be like, hey, you're pretty awesome. Do you want to get

more involved? And that's our flat hierarchy. Basically, the way that works is we have a core team of a number of people who are the wardens, the gardeners of the project. Make sure that when we cut a release, it has to be done by one of them. But by joining the working group, you would then get GitHub repo access to all the public repos. And you can work on a branch instead of a fork, which, believe it or not, improves security. And you can participate in the strategic discussions and the WTF channels and hang out and work together. And we're super open. If you get involved, you're part of the working group and we want to know about it and bring you on board. And I think

that that low barrier to access is also a reason why we have such an amazing group of dedicated people who spend weekends and afternoons telling people how to do things and at the same time building great stuff. So if our listeners are listening and are getting excited about the future of where this is going, what can you share about the organization? You mentioned before venture capital, maybe there's a company, Maybe there's some things happening. And if they're going to invest in their time in building something, they want to build it on a strong foundation. So describe the direction of what you're doing and how the organization is forming. Not so much if there's venture capital or not, but what's happening company-wise to keep the core team involved, keep people around,

keep the project and the idea sustainable. So we have a board of directors that get together to make strategic decisions about things like, do we get a trademark? How do we deal with managing the community? What about the book? How is that deal going to work? Who gets how much finance? Then we have the core team, which is, like I said, a number of people who have massively contributed to the project and are involved in the day-to-day decision making. And then we have another volunteer group called the working group. And basically the way that our organization makes decisions is by consensus. So if there's a veto, then we talk it out. If there's not a veto, then we discuss the best way forward. For example, right now we're having a multi-day discussion about our future release strategy. Now

that we've gotten 1.0 behind us, how do we deal with new features? How are we going to integrate the auditors? Do we call something a beta or an RC? And how often are we going to release a major? The reason why we even got audited in the first place is because we're going to continuously be audited. And I think that if someone is getting interested in Tauri right now, it's a great time to find out what we've built and know that the stuff that we've built up until now has been proven to be as secure as possible and is backed by a team of people who really deeply care about the project. We have been accepting donations from over at Open Collective, excuse me. And some organizations find the project useful and make regular donations.

Others are personal donors. And we use this money for things that are project relevant, like paying for the audit or the trademark or for deciding on, no, we didn't ever do travel costs. We've kept it lean, but that budget has also been really small. And so in the discussions around forming a company, what we've realized is that, sure, up until now, for the past three years, it's been working really, really well on the backs of volunteers, which is almost the same as the instrumentalization of the precariat, where people have time on weekends and evenings and sacrifice social time in the real world. And then maybe they get new jobs or they have to move and they just don't focus anymore. And our documentation needs lots and lots of attention. And how do you manage a documentation project of that scope just with volunteers?

So we've really come to the conclusion that in order for us to continue sustaining the community, we need to find a means by which we can employ members of the core team. We can employ members from the community and people who are interested in getting involved in Tauri. And, you know, that's the delicate balance of how do you create a common good while still participating in a capital market? It's a really intriguing concept to even think about because when you say the value of our company isn't in what we're doing, it's in what other people are doing with us. Like it's hard for financial people to, to really wrap their head around and grok and be like, yeah, that makes sense, man. And at the same time, if, you know, if, if we don't continue getting donations for, you know, paying for one or two full-time roles, you know,

if that money were to dry up, people would have to start looking for other jobs and the evolution of the project would stall. So, you know, in order to continue providing that common good and doing it in the right way is going to be a very delicate dance. But if you've been listening, you'll remember that not even the core team can change the license of the code. There's no rug pull possible here because we put the code at such a privileged central point of the project that, you know, the only things that we could even really consider offering are things that are built around Tauri. There's no way for us to open core it. There's no way for us to even legally gut it. It's owned by a foundation in Holland

called the Commons Conservancy. And so, I mean, it's challenging to talk about. And I know that there are amazing open source projects out there that have succeeded and we're taking inspiration from them. But at the same time, the promise that we made to ourselves when we made an open source project is that it stays open source. We're not going to weaponize it because we don't believe in your war.

We're not going to, you know, delete the code from NPM because we don't believe in your police. I think that the greatest satisfaction that you can have as an open source software engineer is that somebody is using your code and enjoying it and contributing back. And that contribution back can simply be by building an app using it. Filing issues, filing pull requests, making donations, that's all really great. But the mere fact that it's being used is why open source exists. Now, we can get into the morality of what it means to be an honorable human being and a gentle person who cares for their environment and their fellow beings. We can talk about that, but that's why you have other instruments. That's why you have a community. You can take people out of your community if you don't like them, but open source is, it's become more than a license, but at the end of the day, that's what it really is. And so we have an agreement with the community and with each other

that this project is open source and it's staying open source. And I mean, those are the arguments that I would bring to the table, that it's a stable core, it's been audited, and it is and always will be open source. And we're working really hard on finding an honorable way to support the engineers involved in building it. Well, you've really thought through a lot of stuff here. You've got a great community behind you.

You've got great ideals in place in terms of how you're running the project. So this is all good things to build a foundation for this project on. So I appreciate you sharing your time here today, and it's been awesome. That's it. The show's done. What appreciate you sharing your time here today. And it's been awesome. That's it. The show's done. What do you think about this big next step in web tech, in multi-platform, in tiny? Tauri is doing some cool stuff.

Check it out if you haven't already. And let us know in the comments. We want to hear from you. Links are in the show notes. If you dig what we're doing with this show, I think you might because you're listening to it. Thank you, by the way. You might enjoy other pods we have in the ChangeLog podcast universe. For fans of my show, Fighters Talk, I recently talked to Jack Dorsey.

Yes, CEO of Square, former CEO of Twitter. And Jack shared with me what it means to be a hacker. Take a listen. One of the interesting things around punk rock is like, you know, someone gets up there first time with a band and they're absolutely terrible. Take a listen. I saw the same sort of attitude and approach on the internet and open source software where you're not, you're a terrible programmer and you put something out there and you get feedback and it's usually super negative feedback and, you know, angry people behind keyboards, but it gets you into a better state. It helps you learn and you learn from others just by watching their work and watching what they're doing and what mistakes they're making. The other thing of hacker to me means like you do whatever it takes to make it work. I was not an engineer. Never an engineer.

I just don't have the skill for that. Engineer being someone who actually can make something work, but also it be stable and scalable and be fail-safe. I learned enough to make the thing work, barely work, and then it would probably fall down at some point. So I wrote all the original code for Square back then, and it was quickly replaced by people who could actually make it scale. Although i thought mine was pretty good in this case all right continue listening to that pod at founders talk.fm slash 91 that's episode 91 big thanks once again to our friends and partners at fastly they provide our super fast global cdn check them out at fastly.com and of, of course, big thanks to Breakmaster Cylinder. Our beats are banging. BMC makes banging beats, and we love them.

Hope you love them, too. All right, the show's done. Thanks again for tuning in. We'll see you next week. Thank you. Game on.