Is Tauri the Electron Killer?

Welcome to Syntax. On today's supper club, we have a really good one for you. Daniel Thompson is here to talk all about Tori, and Tori's just hitting their version 2. It's in release Node now. We're gonna be talking all about what is Tori, you know, what are the motivations behind it, what can it be used for, and just all about the nitty gritty there. So my name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey. Excited to talk to Daniel about

Torrey. I know you just got Deno a whole week working with it, and we've been talking about it for seems like over a year Node. So stoked to have him on. Yeah. I've done a lot of Torrey projects, so I got a lot of, lot of questions, a lot of thoughts here, and I'm a big fan of the project. So welcome to the show, Daniel. How are you doing? Great. Thanks. You know, it's, I'm in the hot seat, but that's because I'm in Malta. Oh, wow. It's about 30 degrees here. However, it's a kind of tempered basement. I've heard from friends of mine across the Atlantic that it looks like the walls are made of blocks of butter. They're not. They're limestone.

Oh, wow. No. But I'm I'm doing great, and I'm happy to be here and talk to you all about that fantastic Tauri stuff. Yeah. Do you you live in Malta, or are you just vacationing? I live here. I actually moved here a few years ago, fell in love with the climate. I have no allergies here whatsoever, which I can't say for the other 45 years of my life, and actually started a company here and run a company out of Malta with a whole bunch of amazing people around the world. Wow. So

do you wanna let's kick this off with a little bit about and you say Tori or Tori. How do you say it? Let's say that. Wow. You know, my friends at Snyk also say Snyk

on what part of the world you're from, whether it's Israel or California. And I probably even said Israel wrong. So, you know, I think the the important thing for me is that people understand what it's all about. You Node? Names and ways we pronounce them. I say tauri, you say tauri. Tomato, tomato. Right?

Awesome. Says tomato, though. Yeah. No. Yeah. You gotta say tomato. You're right, Wes.

So, do you wanna give the audience maybe somebody's never heard of it before? They haven't heard us talking about it or just never seen this project? What's the deal with it? What's it doing?

Sure. That that happens a lot. And I think the the 3 sentence pitch is that Tal Ray helps you make really small performant and secure applications using a system web view. If I already said too many words that people don't understand, I'll start from the very top. You need a user interface, and Talry helps you make that, using the skills that you might know as a web developer on the front end and provides you with an application protocol interface, an API that lets you then communicate with the core of the Tori app, which JS, traditionally written in Rust, although there are projects that let you do it in Python. And if you're adventurous, heck, why not even write it in c? So, basically, what, you're making apps with Tori. Right? You're making desktop apps, and and now with version 2, you're making

mobile apps as well.

Right? That's the that's the big version 2. Is is that what version 2 is all about, or is there more there?

There is a lot of work under the hood to make Towery even more performant and smaller.

In the course of our design decisions leading up to the 2 point o release candidate, we felt that it was important to include the mobile ecosystem.

Some people have accused me personally of you know, in a way, of course, of doing it for the upvotes on Hacker News or GitHub, but actually, it's a it's a really interesting architectural strategy because once you think you know a system really well and you provide one way for people to interact with it and use it, you think that is the way. And in the course of integrating Towery into Android and Bos, we discovered that the way that we built for desktop just didn't work.

We actually had to fundamentally rethink a lot of the things that we were doing, and what that led to was an even more secure system for users because now they actually have to opt into and grant permissions on a very granular level to the various subsystems that they need, whether that's the camera or the file storage. Right? The move to mobile actually brought with it a lot of other benefits to the ecosystem. I think another one that that people were concerned about with Node point o was this method by which you send messages from the user interface to the core. It's like the interprocess communication, you call it. The way that we've been doing it in the beginning Wes, let's just say, left left room for be desired, especially when you wanted to do things like stream data from the back end because every blob has to be serialized, and then it has to go across the border transferred over to the front end, and then it has to be deserialized, and then it has to be integrated into whatever thing is reading, whether it's a video player or an audio stream. And so we put a lot of work into verifying that we are now I think it's something, like, 10 times faster with 2.0 versus 10 versus 1 ESLint o. I remember way back when we were writing up the list of things that we thought were important to qualify Telry 1 ESLint o as being stable was having an updater that lets people update their apps because I think especially for beginners, you think, oh, I've made an app. I'm done, and and actually it's, it's an infinite game in the context of, you know, after the releases before the release, and you have to figure out a way to get that updated code to the users and do it in a secure way. And that was actually one of the first occasions where we felt that we found a better solution than what Electron was doing because our friends in the security community found a vulnerability that we were then able to sidestep because we are now forcing people who make updates to provide a TOWERY signing key to sign the actual binary

so that when an update comes, it can prove that it's coming from the same authorial provenance. Right? Oh, yeah. Those are all sounds like tough problems. So I'll be on, like, websites. Right? We got websites, so just push new update. We don't have to worry about signing and deploying and having the user update. It's a yeah. It's a whole another world. I think

with the web, we've come to realize that things like integrity checksums are important when you're pulling source from remote.

And with the whole module federation blowing up everywhere being really important in this opportunity to, you know, hot push to running apps, I think that the the security model can always be improved, and maybe there's ways for people using module federation and Tauri together to get the best of all those worlds. Right? So talking about

Electron, because people listening right now are probably going, okay. That seems cool. Maybe I've built an Electron app in the past. And the real benefit to using Tori versus Electron is that it's not huge. Like, the the joke with Electron is that you download an entire thing, and we're running these massive Chrome apps on absolutely every single desktop. Right?

And before you know it, you have, like, 8 instances of Chrome running. Probably, I'm running them right now. Is is that fair to say? Obviously, one of the benefits of shipping the Telry app is that your binaries are 3 to 9 megabytes in size. Yeah. Until you start adding LLM models or something like that or shipping lots of images.

But, you know, the smallest app we ever built was 500 some kilobytes.

Right? So you can go and golf really small.

And I think for people who are doing hobby projects or, you know, using GitHub at the weekend for their free time, they don't expect to get a 100,000 downloads a month or a1000000 or more.

And what happens at that point is that you realize GitHub isn't actually a CDN, and there's problems once you start to put those those binaries in an AWS bucket because somebody's paying that bill for that transit, and it's gonna be you. Oh, yeah. Yeah. And, Aaron, how about that

updating a an I always think about that. Like, Discord? Discord updates, like, every time I open it, and it downloads, like, 300 megs or something like that. I'm like, that's that's expensive.

I don't know about you, but I do travel quite a bit because I live in Malta. I have to leave the island somehow, and usually it's with a plane. And I always forget to turn off data because I'm traveling. I use I live on my phone when I'm traveling. I sometimes don't even bring a laptop. I can get everything done. And then I'm in the airport in Zurich, and LinkedIn says download.

It's, I don't know, a 150 megabytes. Yeah. And Yeah. I mean, I'm not gonna complain about the LinkedIn app. I think LinkedIn is a wonderful service, but in Switzerland, I'm paying roaming. So I would ultimately pay €15 to download the update of LinkedIn right there. I guess the the problem gets compounded when you start thinking about the accessibility of software engineering to regions like Kenya and India. I mean, Kenya in particular is notorious for not even having 4 g, and people are oftentimes paying for traffic directly.

And so especially in regions where there was a skip, there was never a laptop generation, everybody's on their phone, finding and and providing a methodology by which people can create cost effective, energy efficient, resource preserving applications can, in some cases, even turn into life saving events. I think that the claim that, okay, electron is just free real estate has kind of been debunked, but there's a there's a couple more nuances there. You mentioned that it ships a a Chromium instance.

Which Chromium instance does it ship? Well, I can tell you it's not the latest Chromium. It's always behind, and when you produce a Electron app and you ship it to your customers, chances are good by the time it's shipped, there are already end days exploits out there for that version of Chromium that your users are running, And what that turns into is a security whack a mole where actually, if you are shipping an electron app and you have some kind of CSO in your team, then they're probably justified in requiring that you have a milestone of shipping an updated Electron app probably that same day.

Given given the fact that that Europe and and the US and Japan and everybody actually is starting to get really concerned about the security of our software, having a framework like Towery that is regularly audited for minor releases and externally audited for major releases is a real positive way to gain that confidence in the framework itself.

So those are two reasons, I think. Yeah. I don't think I ever thought about that. Yeah.

And I'm curious about like, one of the huge benefits to something like Electron is that the back end is in Node, and I I feel like that makes it very accessible to just a lot of regular developers. Whereas on Tori, you wanna write back end. It's it's in Rust. Right? And most people are, oh, I have to learn a little bit of Rust. Like, I built a I built an app in it about a year ago, and I had to learn a little bit of Rust. It's kinda fun. Is there ever a time you said, oh, you can there's a back end in Python, but is there ever a time where we could also have a Node back end as well? I'm I'm gonna tear apart your your points here for a second. Yes.

So Node? Probably not. Deno is something that's in research right now. Really? Yeah. Okay. I'm trying to remember the name of that graphics modification library that everyone's using in Node. Js. There's this one very popular one. Sharp.

Yeah. Sharp. Doesn't sharp require some kind of post install compilation phase inside of the runtime because it's not written in JavaScript?

Yes. We just had Ryan on, and he's like, that's the stupidest thing we coulda ever done is post install, automatically run code.

Well, I mean, ignoring for the absolute security horrors of having your developer machines compromised, my point is that a lot of modules are actually node modules themselves.

The really powerful ones are written in something like C or C plus plus And I guess my argument goes that while you can use Rust, we've tried to take every single pain point out of the Rust equation.

You can write your menus in JavaScript. You can trigger all of the low level systems, like send a notification to the user, use the the Towerys HTTP service so you can Node step Mhmm. Course, for example. And you can you can control all of this from JavaScript land and and the dash client. Right? From the client, from the web worker.

Right. And and I think the paradigm shift that's important for me to make people recognize is that there's always a better programmer than you out there, and it's really easy for great programmers to very rapidly build plug ins that have not only ways to consume them from Rust but also from JavaScript.

And, technically, we won't accept anything into the official library of plug ins unless it offers both opportunities.

Oh, so you're saying, like, we could build a good chunk of our apps entirely in JavaScript? Like, it's not like, even the file system has a has a JavaScript client side API.

Right. So you can call the file picker for the operating system that you're on, and then you choose something, and that value then gets returned through Rust and bubbles back up to the JavaScript side.

Yep. Node. Yeah. When we were working on our Tori app for Hack Week, we did a, like, a syntax production assistant. And one of those things it does is it runs like FFmpeg to generate Npm threes and stuff. So that was being done through Rust, but it Wes it wasn't super tough being just done through invoking a message, hitting a file, and running that sidecar, and it it compiled it. So the Wes stuff isn't that scary if you can get into it a little bit. And we didn't have to do everything in Rust either. I I'm curious because so Tori works and is able to ship to Mac, Linux, Windows, iOS, and Android. Right? And each of those have their own web view, right, with Safari. It's w k WebKit. W k WebKit. Yeah. And in addition to that, there's all these APIs that exist in the different systems. How is it possible that you're able to test the surface of all of those different things, whether that is all of the APIs? Do do you have, like, a Mac, Linux, and a Windows computer set up to hash everything out on? Like, what what JS the actual process for something like that look like?

Lots of VMs.

Physical hardware Mhmm. Of course. I think there's a lot of automated test suites that we have used to prove that up to a certain version of a system web view, a certain API is or is not available.

I think the lonely child of the how do you call 5 twins? Anyway, the the the lonely child out of the 5 quintuplets of the 5 quintuplets is obviously Linux. Linux itself is a vast ecosystem of people who do things different ways. And we found a library written by our friends over at Agalia called WebKit GTK. One of the large problems for that WebKit distribution itself is that we do not have proper WebRTC.

We we would just say WebRTC is a way to communicate between

clients. Right? Most likely used for video audio streaming. Right. Exactly. There are people who have built it themselves, and that was never something that we JS a team were able to support. Another example on on Safari is that, actually, the version of the Wes you have is locked to the Safari version that is installed and running right now. There used to be crazy hacks to get around it, but they just weren't sustainable. In a weird twist of fate, the people behind the WebView project team over at Edge, I think they came really close to doing a perfect job, and that has to do with how they distribute the updates of WebView.

Basically, our applications check the system to see if there's a WebView 2 installed. If not, it phones home. It says, hey, Microsoft. Give me the WebView 2 that's going to run here on this machine, and then it will get installed and it's enrolled in something, like a a rolling release. Every time they make a new release, the device will download it and use that then. You can also install a pinned version as well. None of this is really great from the nuanced perspective of connoisseurs.

We knew this back in 2019. And in fact, back when we were just a core team of, like, 4 people, we even tried to compile Servo. We tried to get Servo to run. Can you explain what Servo is? Yeah. So Servo JS a project kicked off by the, Mozilla research team. The idea behind Servo was to investigate the utility of leveraging the Rust programming language to build a whole browser. As fate would have it, the search bar barons decided to switch funding.

And for a while, that department didn't have any funding, so the team got let go. Also, as fate would have its, Firefox was already using some of those libraries, and they needed somebody to maintain it. And, you know, as time went on at Tauri, at the organization, the project, we've adopted a few of those server libraries that we're using and help maintain them for the rest of the community. But we always felt like there was a better opportunity out there. And we actually received some funding from a Dutch nonprofit and the European Commission's NGI, Next Generation Internet Fund. The nonprofit is called NL Net, and they supported us in doing initial research into testing out if we could use a servo type window together with TOWERY, which we proved. Then we went on and continued the development work, And today, that project is a standalone open source community. It's called Verso, v e r s o, and it uses the servo engine in order to produce a binary that is a browser.

However, because we kind of overlap with that team, we're working on building a custom purpose built web view, obviously, for everybody, following spec as close as possible, but even providing shared memory, which basically means the user interface and the back end JS long as they're sharing the same exact types. I'm not talking about big in tier, but mostly, you know, the same types, they can just share that memory instead of having to message across, which makes it extraordinarily

performant. Node So you're what you're saying is, like, you literally built a web renderer, like a browser in Rust, and you could have code that runs on the back end. I'm using air quotes here.

That then shares memory.

Like, you send a a massive array from your back end to the browser.

1000000000 lines. Yeah. And that would that would take up a ton of memory because you have it in 2 spots. Right? Right. It would be able to share that. Right?

Correct. That's cool.

So what's the likelihood that that ever makes it into Tari as the the Wes view?

It's going to stay as as an experimental web view at least for the next 6, 12, 18 months. I think that the risk of making something that experimental, the approach, is kind of unfair to the tens of thousands of people building with Telry today. But for greenfield projects Wes a unified user interface that works across all 5 platforms that is not Chromium, that leverages the learnings from the delivery mechanism that the WebView 2 team from Edge are using that solves the problem of, oh, we don't have WebRTC. I guess that's okay. It's absolutely not okay to be missing web critical interfaces and calling yourself a webview. I think that it's not criminal because there's not really even a great standard for web views. Web views have always kind of been that little extra thing.

You know? It's been like, yeah. Okay. We'll do you a service. And, you know, Microsoft rightly, in my opinion, discovered that, well, actually, Electron much and, well, we need a WebView.

And I believe Teams even made the switch to to WebView 2. I don't think they're using Telry directly, but the the learnings are shared across the community, and I feel that that's the important part of of all of this, of all the stuff that we're doing. Hey. You know, I even have personal experience here with issues caused by the Safari approach, which is

the Safari is tied directly to your your Mac version. Right? And in my instance, with the Safari web view, the w k web view, they hadn't implemented the share screen dialogue. That was only part of Safari proper, but not part of the web view. Is that correct? And so what it would do when you prompt it, it would automatically fail any request for get display media, I believe. And that wasn't an older version as far. I wouldn't say that was about a year and a half ago. And I just had to sit on my hands and wait for Safari to push an update and for my computer to get an update before I could even think about implementing that with Safari, which I feel like that's the kind of thing that, you know, it the weird thing about the Apple approach is that the some of the apps are just tied so directly to the OS. You just have to wait. And then you're not sure if your users are updating and all sorts of stuff there. I mean, it's, yeah, that's a tough world compared to being able to choose the version of the the Wes view. Yeah. The other

problem of Tauri on the Safari based web view on on macOS is that somebody just decided not to make the testing harness that is available to Safari available to the web view. So Wes driver interfaces don't exist for the web view, which is just, I mean, a little baffling to me. And, hey, guys. If you're listening out there, I'd love to talk to you about this. It's not that hard.

You Node, ring me up. You'll find me anywhere you look. We built Tauri from these first principles of giving people the power, and then, yes, the operating system is the best we have for secure updates. Like, I think that Safari is going to do a better job, generally speaking, of shipping secure updates, and people are probably generally better about updating their operating system in Safari than they might be about Firefox.

That said, these these nuances are turning into pain points for people, and that's the point, you know, where we decided as a team that it's important to go deeper and solve that layer because no one's gonna do it for us. Apparently, we gave them 5 Yarn, and the situation hasn't gotten better. And then you might ask yourself, Daniel, well, if you give a mouse a cookie, he's probably gonna ask for a glass of milk, and you better believe it. There Yarn Telry OS, but a bootable microcontroller that instantly goes into kiosk mode running a Verso based Wes view that is harnessed and controlled by Telry.

Wow. Wow. How big how big would that would be? Could you run that on some pretty small hardware?

Yeah. We're targeting the s t 32.

The s t 32. Hold on. Let me Google what that is.

It's tiny.

It's damn cool. That's that's a ARM chip. Correct? That's a like a chip that would go in a low power cell phone?

Chip for application. They're gonna be making them for decades.

The IP is very clear. Everyone knows exactly how it works, so it's very well known.

It's easy to acquire.

It's easy to to manufacture.

And, you know, in some cases, if you have a giant part order, you can basically print your own ASIC on the expanded version of the 32 series and put all of your logic onto silicon.

I mean, I'm not suggesting we're gonna go down that road. I'm just talking about research that we're doing. And, again,

STM, if you're listening, love to talk to you guys. Good stuff then. With all this research and all these these projects and and the Torrey project has been so, it feels like vibrant for a long time. There's always movement. You know, I've been following since early on. And it feels like you're always working hard on something on this project. And that's it. There's nothing about a paid product or anything on the website that I can see. How does this project make money and sustain itself?

The project is a purely open source project that is hosted by a Dutch foundation. No one who works inside of the organization receives any money for it. It is all based on volunteering.

Are a couple companies, mine included, that pay the salaries of senior engineers in the project, but we made the decision very early that this was not IP that would ever get snagged. And I'm not gonna name names. I don't wanna shame any of any of our listeners out there, but it's literally legally impossible for any individual in the community to change the license.

Like, if the board of directors decided, oh, no. You know what? We're gonna take this private.

The working group would revolt pretty instantly, cause a a vote of no confidence, remove the board of directors from their seats, and then vote in a new board and revert whatever commits those people thought they were entitled to make made.

So that is the most ideal version of a community driven project that you could think of.

But, of course, you know, people have jobs and in open source, they likely have a job and a hobby, and the hobby is open source, but then people get families and kids and other hobbies. And we actually raised money from an incredible VC, Joseph Jacks, from OSS Capital and a cohort of amazing angels gave us money to finish off Talry two point o. We dedicated a lot of time and effort and money into that and build products that serve the Talry ecosystem. I mean, you've probably worked with the auto updater, Scott. One of the the key things that we knew people were always going to face was setting up an auto updater service that hosts the latest versions, hosts the old versions, hosts release notes, host it for all of the operating systems that are out there, and then provides updates and and manages that all in a such a painless way that you probably only have to visit the website twice and set up the CI once and check your credit card invoice Wes the end of the month. It's just that bulletproof and and that simple because it's important to get that right. It's like that that last part of running a marathon or or building a a a desk. If you forget to hydrate, you're not gonna finish the marathon. If you've if you don't treat the woods, you're gonna get termites. Those are things that you learn from experience, but if you've never done this before, you're going to go your own way and it's going to cost you a lot of time. And for our friends in Scott ups, they don't have time. They're burning candles at both ends.

And if you can get this entire thing set up in 5 minutes, 10 minutes of your time with the support of the team if you need it, then it's actually a very net positive win for the broader community.

And, yeah, that's the main service that the Crab Nebula provides is this cloud where you can store your assets, ship your assets, update your assets, and coming soon, proof compliance with these amazing new European regulations.

Wow. So, yeah, so to make that clear, it is Crab Nebula Crab Nebula Scott dev, and that is I had a peek at some of these things. And, obviously, I don't want this to sound like an ad. But, like, the thing I love about it is that it's taking the things you're gonna have to do and making it much easier on you because, yeah, you can do it without Crab Nebula. But, you know, that doesn't sound like a ton of fun to me. So, yeah. I think that's a a good way to to approach because it's not necessarily funding Torrey dev in the way that you're thinking. Or

would you consider Crab Nebula I know we we kinda went over how you got funding. But would you consider Crab Nebula funding the development of Torrey long term? I think we're always going to be involved. The the risk of just 1 company doing it is that Wes were talking about before Mhmm. About testing your your theories JS that it it can kind of run into the the the risk of appearing like it's all being pushed up by 1 company, and it's really not. I mean, yes, we are heavily involved, but without the amazing contributions and participation of the open source community in the working group, Crab Nebula couldn't have even done it alone.

Right? And to recognize that, the Tauri community represented by the working group has approved actually, it took a year of doing this, but they ultimately approved Crab Nebula as the official partner of Tauri, which is beneficial to us. I mean, we've we've placed information together with the working group in the Tauri documentation that says, hey. You don't want to roll your own update? Go check out this Crab Nebula service. Or you're having trouble debugging the IPC call, check out Crab Nebula's dev tools. In in a similar way to, how React Native shares the services offered by Expo. Right? So there there is

prior art that we sort of modeled that approach on. And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.ioforward/ syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to sentry.ioforward/ syntax. Again, we've been using this tool for a long time, and it totally rolls. Alright.

I'm curious about the Bos part. When you need to go native, meaning that, okay, I need to interface with some sort of native API that Tori does not give me, you know, like calendar or native maps or or Bluetooth.

You tap something. Is the idea there that they're similar to React Native Wes there's just a large community of people that will build bridges for that type of thing? I mean, writing Swift is just another programming language, right, just like Kotlin? How would you access, like, the Swift from your JavaScript

that's running in your Tori app? With a bridge, and we write the bridge in Rust. Right? So that the bridge is then available to Rust, but through the JavaScript API that the commands functionality via invoke and respond provides, we're able to then communicate directly with the app itself. I mean, recently, for a client, we built a mapping app that leveraged geolocation and haptics. So, you know, when when the ride arrives, you get a buzz. And that was all custom TOWRI plugins that we wrote that are open source to everybody.

There's so much prior work and good stuff out there, and thanks to the open source community, we're able to to find out where people went right or where they went wrong. I mean, NativeScript, Capacitor, React Native have all had to deal with these problems in one way or the other. And at the end of the day, it's just engineering.

So what was what is the hardest part of putting mobile into Tori? I mean, it had been around with desktop for a little while, like and, you know, I know you had to rewrite a considerable amount of things. But getting mobile applications to work well with Tori, like, what overall, what was the the hardest part of that whole process?

Of everything that happens after it's compiled. Interacting with the entire developer ecosystem provided by, Apple and and Google is it Alphabet and Play Store? Anyway, yeah, interacting with those services is tricky because, first of all, you wanna automate everything you can, and second of all, you also need to have a human in the loop in certain places. Right? You can't just, like, wildly release an accidental update to every device in in your fleet. There has to be a human involved, and I think that we've worked hard to keep it not absolutely necessary to use the tools provided by the respective ecosystems.

But, you know, sometimes you just have to, and sometimes it's just more efficient. And I think the interesting comment that I've heard people say about TowerE is, yeah, you can write code in one way for all the platforms.

If you don't know Rust, for example, you get this amazing feature called conditional compilation, which means it detects the target operating system and and hardware that it's building for and gets rid of everything else. Like, if you're building for Bos Yarn, for example, or just macOS, let's call it that, the easy way, you're not gonna build all the stuff that you might need that's slightly different for Windows.

And I think that the the trickiest part that we faced, Scott, to come back to your question directly, was that in order to run a Talry app in those contexts on mobile, we had to change to a library approach inside of Rust, which, like, means you have a different way of compiling it and then interacting with it and rigging it. And, ultimately, we don't own everything anymore, and for people who are Rust nerds, it's a hard pill to swallow.

To to finally come to the the situation where you are not the absolute owner of every piece of memory out there, It's a caveat that I think is is, acceptable in these cases where we have to interface with low level subsystems. We have to interface with the system WebView, and those are the methodologies that are available.

If something changes and it becomes suddenly easier through work being done by people in the in the Rust or or Android or iOS ecosystems,

we'd absolutely consider, you know, revisiting that, making alternative approaches available to to people. Yeah. I'm just looking at the haptic plug in here, and it's it's really not that much. It it makes sense where there's a sources haptics plug in Node swift and 100 lines of swift in there and then maybe another 20 lines to register the plug in via Rust, and then you can call that thing from JavaScript. That's pretty neat. I'll link up the example in the the show notes.

I also have to say the the mobile ecosystem has a couple decades head start on Telry, and we are not a company with a a 1000 employees, and we don't have 1,000,000,000 of of dollars of funding, and and the community is based on people that wanna help each other. We knew that we would never be able to hit the full surface area of every single type of plug in that everybody wants out of the gate.

And so the approach we took, which was approved by our auditors Radically Open Security from the Netherlands, who audited our Yarn two point o via funding from the the European Commission again, they agreed to review several types of plug ins for veracity, for simplicity, for readability, and for security because giving an auditing firm a 150 different plugins to audit is something that's going to take a lot of linear time.

Even if they put 4 or 5 people on it, there's just not that many experts in the security venue working in the same place. Right? So you'd have to shop around nightmare. The approach that we took is we tried to make it so simple that gosh. I don't know. I mean, somebody in the community said they were looking for a plug in, and they went over they went over to capacitor, found a plug in there, and looked at it and figured out how to write it for Talry because they were they were good solid Rust engineers. You know? Like, you take that. You understand how plug ins work.

That is of benefit. You know? When you are a a solid engineer and you're capable of making these kinds of things, then it also opens up a market for other companies to get involved and decide, yeah. We're gonna make this plug in for our customers. And, hey, maybe 1 out of 10 get contributed back upstream to the open source community. Right? Yeah. And I found the Tori ecosystem to be in terms of, like, or just community in general, whether it's the Discord or the GitHub.

Anytime I'm looking for help, there's always somebody who's been ready to help me. Or even, like, just in general, there's a lot going on. There's people in there talking. There's, in general, a lot of support amongst community members. And I found that to be really just a positive aspect about you know, when you pick a platform, you don't wanna pick something that's a ghost town or that everybody's I don't know. I I've been in some grumpy web communities before, and Tory certainly isn't that. So I've always really appreciated, that aspect of how everybody seems to work together.

I I'm curious about, like, what are what are some of the larger apps that have been shipped with Tori? Are you aware of most of the apps that have shipped with Tori, or just things popping up left and right? I mean, I have 2 2 direct comments to that. I wish, but we do not run telemetry. That was a choice.

Maybe we could add something optional in the future, but, I mean, what I what I do know is, for example, from Sourcegraph, Node is written in Tauri.

Oh, cool.

I know that Git Butler has chosen Tauri for their platform. If you watch Scott Chasson, pretty much every talk, he'll he'll drop a slide where you see that it's Tauri, and I actually sat next to him at a conference as he was hammering in some Rust code and fighting with the compiler, but he won. Yeah. Yeah. Oh. And I think that the apps you can find, there's 2 places to look in the community. We have an awesome Taeri repo where people place and should place their private projects, their their proprietary projects, use it as a platform to to to spread the word.

And if you're looking for more interaction or feedback, a lot of people use the Towery Discord because we have a showcase, and you can just come and and showcase your app. And if you have an update, you give an update to the people that are using it or they give you some feedback, and that'll bubble up to the top of the showcase so you can also start to engage with the Towery community. And I guess if I was to try to place Towery apps into genres, I think the the people who are not afraid of an early adopter tax are dev tools, people who are building things for, you know, making their dev life easier.

I mean, I've seen a lot of those.

I've seen teamwork apps being built with it, and, again, you know, this this whole productivity market is where a lot of young startups are, you know, sharpening their swords and getting into the the the fray.

Another weird one is add ons for Twitch streamers.

Like, I've seen a lot of people build these. Like, there was one from a long time ago that's recently been updated where it takes voice to text and places the text onto the screen. Cool. Games are popular, but not in the sense that you think.

Actually, it's the launchers that people come to Towery to to build. So they'll build a launcher for the game in Towery and use the launcher to do amazing things, like manage the assets, manage the versions, use it to do the download because you got this massive binary that you just spit out of your game engine of choice, and it runs great on the platform you built it. And and having a launcher is, you know, kind of a a semi common thing, especially for game studios.

Right? So if you have 3 or 4 different games, that way you can keep people engaged and tell them when there's a new game or a new update because you've got their eyes.

Man, this awesome Tori list is absolutely massive. Yeah. And, like, there's hundreds of apps on here. It's really cool. There's EPUB readers, screen recorders on there, visualizers, keyboard driven database management.

There's so many cool things on here. It's fun to just click through.

Especially, they mark which ones are, like, paid, like, closed closed source paid apps, which is kinda interesting because if people are running businesses on us, you have an idea? You wanna build a a little app and charge $6 for it? You can do that with this. Yeah. And you know what? I will say from somebody who doesn't write Rust, it's a good introduction

to writing Rust because, like we've talked about, you don't have to get crazy into it. But, you know, I'm not a Rust engineer, and and we were able to to ship some pretty serious stuff just getting into it.

It's just so it's a heck of a lot of fun to build an app. I it's just cool. My partner's

daughter is 24. She just graduated from college.

Hi, Cheyenne. And she asked me to teach her Rust. She's never programmed before, and I put her through the course. She's doing the Rustlings course. Check it out, Rustlings. It's a great way to learn the basics.

She's watched the video solutions to Rustlings.

And believe it or not, I don't know if you follow Cassidy Yeah. Williams, Cassidy, she publishes a challenge, and I've been having Cheyenne run the challenges, but write them in Rust. Cool. And we got into this really interesting challenge that was all about time, right, and understanding, like I this Wes a a challenge from cast a couple ago, and it was all about log lines. Basically, you get a log line and how much time elapsed between them, between jobs. And, you know, for for Cheyenne, this was a big thing because, you know, she's never been exposed to a production environment. I mean, let alone GitHub. Actually, she does sign her commits now. You know? She's taking the right the right teacher at this time. But, I guess, the the ESLint I wanted to make is that when we decided that we were gonna have to show this somehow to Cassadot, we put it through Wasmtime and built WASM from the Rust and then and executed the WASM blob in the browser via a GitHub page.

And because we were talking about I was like, you know, Rust is a lot faster than JavaScript, and she's like, Node. It isn't. And I was like, okay.

Go over to chat GPT, copy paste your Rust function that you wrote, ask it to change it to JavaScript. We took that. We put it into the index HTML and or not milliseconds faster was Rust every time until Scott, are you gonna guess what happened? She used an I thirty two. She used a type a type of integer that just doesn't go very big, which meant that suddenly we were confronted with big int and the this whole notion of numbers. And I guess the reason why I'm bringing this up is if somebody who's never studied computer science before is able to start completing Cassadeus challenges in 3 weeks and learn about JavaScript at the same time, there's really no excuse other than being unwilling or lazy or you've got other things to do. It's not hard if you put the time in, and, honestly, we the 3 of us wouldn't be sitting here if we had decided at some point to be lazy and not put the time in. Yeah. And I found, you know, writing Rust even made me a better TypeScript developer. There are so many things that are

similar in ways, you know, especially if you're not coming from type languages primarily.

What JS the future of Tori look like? I know we're in our c phase for version 2.

Is is that going, full release anytime soon? And after that, what's next?

So Tori two point o is scheduled for in about 2 weeks, the stable release. What the versions mean to us in the Tori ecosystem is an alpha means we're just trying stuff out. We're trying to see, like, what's good enough what's good enough for everybody. A beta means the architecture has been decided. It's been designed, and we hand it off to the auditors. And as the auditors have findings, we revise the structure, the architecture. When we get to RC, the API is locked, and we're just bug fixing. It's open to the community. It's technically, it's battle ready, but it hasn't been battle tested. You can't expect there will be any changes because all of the critical stuff has been found, and then it's a documentation sprint. The RC phase is always a documentation sprint because we just found out that all of our assumptions have been proven or fixed by the auditors.

Yeah. So very near future.

We're recording this on the 27th August.

So our plan and expectation is in the month of September to celebrate the stable launch.

Awesome.

Yeah.

So the future, Tauri, Tauri 3 ESLint o. I actually saw somebody in our Discord talk about that, and that's actually when you have these super highly motivated engineers and they're just kind of, like, stuck fooling their thumbs, like, I can't write docs all day. I have to do something, and we're, like, don't touch that again.

Just leave it be, and they're, like, okay.

I can't push to the dev branch, though, because dev promotes to some other like, our release structures is kind of interesting, but you have to fork, and then you have to track. And so we've started putting together a list of things that we want to really button down for 3 ESLint o. Node of those, if you ask me, is going to be having at least pnpm experimental web view of our own available on all 3 browsers. I mean, our release cadence is about once every 2 years. It's about how we Wes get to a major release. We're we're methodical in the approach that we take to releasing software, and, you know, that gives us enough time to collaborate with the other teams because that's a that's a pretty big project.

I think what we'll really see is a lot of engagement in the mobile ecosystem.

People like Cheyenne, people who have an idea but don't know how to bring that all the way to the end are increasingly turning to AI tooling.

That's unstoppable.

That train is traveling.

I think the important part for us to realize is that, you know, as engineers, a lot of the code that's going to be executed inside of the context of a tower app is going to be written by LLMs or LLMs trained by humans or maybe slightly modified Mhmm. Which takes the I'm not judging here, but there there is a trade craft to understanding the possibilities of things like side effects and code smell that if you don't know what tabs and spaces are, you're not gonna care, and who cares about linting as long as it runs on on my machine? And so I think that tooling for absolute beginners who, like the Sorcerer's Apprentice, are confronted with a tool they don't understand, is not an excuse big enough to prevent us from finding concrete ways to help them.

And so I would see the the the transition to Telry 3 ESLint o as being one of those experiences where we fix things that have been us along the way. We see it as a maintenance release, but we work really hard on improving the developer experience for everybody no matter who they are, where they're coming from, what programming language they're using, and just turn it into this very utilitarian agnostic framework that is good. I guess, yeah, it it sounds trite, but I really believe that software engineering has a way of changing people, and it can change them for the better if they understand what it is that they're doing. And I'm not gonna go on a philosophical rant right now, but there's something that feels good at the end of the day when your Rust code compiles.

You commit your code to to your your, you know, your your version control system, and you come back the next day and it's still working.

And I I guess the risk for a project like Tauri is something that was made really clear to me back in the days right before we launched 1 point o stable, and that was the week that Explorer was deprecated. I mean, Wes the deprecation was announced of Explorer and Adam Shell the week before Teleri Node point o stable came out. And I think I talk about this almost at every every major release because it still sits with me.

If you do not continue to innovate, your project will, at some point, disappear in relevance, and that is tempered with the desire of a Rust engineer. I count myself amongst them to have something finished. I think the notion of being done is something that you can achieve with a compiled language that's hard to do with JavaScript. I'll give you an example. Try catch. Right? Like, you just don't Node. Yeah. And why is that? And and Rust Rust is really like, to to get to that kind of behavior, you you gotta work really hard.

And and I think that the question we're gonna ask ourselves as we get to 3 point o JS, what does done look like for Tauri? Mhmm.

And how can we keep on innovating? I think JS I mentioned earlier, the momentum to build a Wes view good enough for everybody, but designed for Tauri is a huge lift. I think that's something that's gonna carry on for a decade probably. And then I sort of hinted at it, but I I think that the interop with other programming languages like Python, like PHP, like script based languages, whether it's TypeScript or, you know, script or whatever TypeScript y languages you're using, opens up the venue for everybody. Right? You don't have to be a Wes station to even touch it at at that point. That that's about as far out the window of this train that I can that I can lean. That's a you know what? I love what you said about

even the concept of done is something that ESLint the JavaScript world, we don't have that that concept. If we see a package that hasn't seen an update in 6 months, we're like, is this abandoned? You Node? Where in in Tori or even in Rust in general, I can't tell you the amount of times I've seen people ask about abandoned packages. And, like, what do you mean abandoned? It's done. It's like, oh, we don't you know, I've never even thought about that in the web world. So it's an interesting concept that it's it's so far removed from the web world. You know?

Let's move into the last section here. We have a sick pick, and shameless plug, did you bring a sick pick for us? So my my sick pick would be, 5 Second Films. It's a it's a troupe

of comedians who've made short films

forever. I think almost 20 years they've been doing them. Yeah. And I have one in my watch view from 13 years ago. It said I watched this at some point in the past 13 years. So Yeah. And

what I love about these short films is that they force you as a viewer to come to terms with a situation you weren't prepared for really quickly, find humor in it, and move on. I think that in in the the world I live in of software engineering, we kind of end up getting stuck with these ideas in our head, and it's hard to to to flush them. And then I think that this group does a does a really great job. I'm not an affiliate, but, support them on Patreon. It's a good thing. What about a shameless plug? I'm actually writing a book at the weekends. I got involved in the discussion around the Cyber Resilience Act in Europe last year when everybody was going crazy that open source was gonna have to turn into a product.

And as time went on and I've had more conversations and I've been on panels and I've held talks and I've got notes put together, I decided that it's an important opportunity in the weeks before this act gets published in Europe to make a guide for people just building software because the Cyber Resilience Act is all about the notion that products with digital elements are now going to be regulated in Europe.

And, sure, there's gonna be a few years that you have to get into compliance, but what it does to Node of product, which I love, and engineering, which I need, and these crazy interrelated documents that go back 15 Yarn. And in Node document, they'll say, 1 word, and they know everybody knows exactly what that word means, who's been around since 2012 and has been reading all these things. And it's it's such a behemoth of a topic that I thought I would take some mystery out of it and polish up my LaTex. I already got the ISBN numbers. I'm just waiting to to to publish it. What's it gonna be called? Manufacturing European software.

Awesome. And can people find that anywhere?

It's going to be on Amazon. It's going to be on my corporate website. I'm going to be shilling it on LinkedIn and at conferences because I have 4 ISBNs. I'm also printing the physical copy. So if you see me somewhere, I will always have a couple copies there. So, hit me up, and it's it's been a really exciting journey, especially because the the topic is so underserved, and there's so much FUD out there. The act has changed over the past 3 years, almost

3 years. Things that people wrote about it 2 years ago are just wrong, like, literally wrong because this thing has been evolving. And yeah. So that's that's my my shameless plug. Sweet. I'm writing a book. Cool. Well, thank you so much. This has been incredible. It's been great to hear about Tori, but not only that, just all your amazing thoughts and everything. So thank you so much. This has just been really enlightening. If you haven't checked out Tori, we'll post all the links of everything that we talked about in these show notes. I highly recommend to give it a try. It's a incredible piece of software in general to work in a great platform. So thank you so much, Daniel, for coming on. Thanks for having me. It was a pleasure.