Rust on the web is starting to look quite good.

本站添加: 2026-05-05

[00:00:00]As someone who loves to develop software, building web applications has always been a bit of a mixed bag. On the one hand, the web itself is probably the best platform when it comes to distribution. There's no easier way to ship your applications in 2026. However, when it comes to actually building for the web, well, for myself, this isn't as enjoyable as an experience, mostly because of the main programming language that's actually used, JavaScript, and its derivatives such as TypeScript. Now, to be fair, these languages aren't exactly terrible. In fact, I'd argue that they've helped to usher in an era of fantastic developer experience.

[00:00:36]Whether it's through frameworks such as React, Vue, or SolidJS, or through fantastic tooling such as VIT. However, as somebody who learned code in C++ and who very much likes working with more systems level languages, then building for the web and subsequently writing JavaScript/TypeScript has always been something I just haven't really enjoyed.

[00:00:56]Fortunately, I'm not the only one, and there's been a number of attempts to abstract the need to build web applications using either of these languages. These include frameworks or libraries such as HTMX, Alpine.js, Data Star, and even Hyperscript. All of which bring a unique perspective into building web applications without the need to write JavaScript or TypeScript. Whilst each of these have their own strengths and weaknesses and are definitely worth learning in my opinion when it came to my own experience of using these to build more than a non-trivial project, I still ended up needing to write JavaScript, but in a less maintainable way than had I done so using something like React. Now, this could very much have been a skill issue on my own behalf. But ultimately, I decided that these solutions just weren't for me.

[00:01:39]Fortunately, there is another solution out there that can allow one to build modern web applications without the need to write either JavaScript or TypeScript or any of its other derivatives. That solution is web assembly or WOM, which allows you to write code in other programming languages that can then be compiled for use in the web. One such language is Rust, which also happens to be the language that I'm exclusively using in 2026 for things such as my agentic AI video editor, but also when it comes to writing code for the web, of which, in my opinion, Rust is actually quite good. So, what makes this the case? Well, beyond the fantastic ergonomics of the language itself, there's a good few reasons as to what makes Rust on the web not only viable, but also an enjoyable experience for building web applications. For starters, there's actually rather decent tooling, allowing you to develop, iterate, and deploy your applications in a way that feels similar to using something like Vit. Although, I will say it's nowhere near as mature, but it's definitely starting to get there. In addition to tooling, the actual ecosystem behind Rust on the web is looking pretty good as well. Whether it's through native crates, those that allow you to interrupt with JavaScript, or even desktop frameworks that allow you to publish straight to web assembly. For example, here I have a game of snake that I wrote entirely using Rust using the iced desktop framework that has been published to the web. However, perhaps the biggest reason as to why Rust on the web is starting to look so good is because there are now multiple viable frameworks for building either front end, backend, or even full stack web applications. All of which provide a developer experience that's reminiscent of some of the more popular JavaScript front-end frameworks. Therefore, to give a highle look at what Rust on the web looks like, let's begin by taking a look at some of the popular web frameworks for the language. Beginning with one that I've been playing around with recently called U, spelled YW. U is a front-end framework for building interactive single page web applications that are client side rendered by default. The framework itself is heavily inspired by React, both when it comes to developer experience, but also the underlying architecture. This is because under the hood, U uses a virtual DOM when it comes to rendering and also employs a component-based model both for defining view logic and also when it comes to managing state. To show what I mean, here I have an example web application that I've built with you which defines a single label representing a counter and a couple of buttons to modify the value either by incrementing or decrementing which as you can see works. If we take a look at the actual code, you can see it's very similar to how one would create the same application in React uh but just written using Rust. To start here, we're defining a function called app, which we're specifying as a component by using the following macro. Inside of this component is both where our counter state and view logic lives. We're creating this state using the use state hook, passing in a closure that returns the value of zero. Then when it comes to both our increment and decrement actions, we're defining a closure for each that modifies the counter state internally. As for the components HTML view, here we're using the HTML macro, which allows us to define both our HTML tags as well as any interpolation of the counters value. Additionally, we're also passing in the callbacks that we defined for the onclick handlers. Very cool. As for how to actually run this code, well, this is where some really nice Rust tooling comes into play. The first thing we need to do is add the WAM 32 unknown unknown target to Rust up which is achieved using the following command.

[00:05:05]Once the target is added, we're then able to compile our Rust code to web assembly. However, rather than doing this using cargo build, let's instead make use of another approach, one that will allow us to serve our code locally.

[00:05:17]This is through a tool called trunk which is a bundler/build tool for womant based applications of which u is basically you can think of trunk as playing a similar role to what vit does when it comes to javascript and typescript frameworks. To install trunk you can do so using the following cargo install command which just to be warned does take quite a bit of time. In my case on the new M5 Max MacBook Pro this took about 2 and 1/2 minutes.

[00:05:44]Fortunately, Trunk does provide binaries that you can instead install using either the cargo bin install command or by using something like Nyx, which is the approach I personally like to take through the use of Nyx Darwin. Once installed, in order to run this code, you can then use the trunk serve command, which will compile the application into WOM and then serve an index.html with the web assembly injected in at localhost at80. If I head on over to this address, you can see our code is now running. Very cool. As well as supporting application development and serving our code, Trunk is also able to build and bundle our application for deployment, which is something we'll take a look at shortly when we look at how to deploy a Rust web application to a server. Speaking of servers, as I mentioned before, U by default is client side rendered, which is defined by the CSR feature inside of my cargo.l.

[00:06:31]However, in addition to being client side rendered, you also provide support for serverside rendering, aka SSR, which can be enabled using the following feature. By doing so, it allows you to create an application that supports SEO, but still operates as if it was a single page web application. This is again very similar to what you can achieve when using React with React serverside rendering. To use serverside rendering with U, you need to pair the application with a backend server. In my case, I'm doing this with Axom. Once you have a server set up, you can enable both SSR and the hydrate features inside of the cargo.ls.

[00:07:06]This will provide you with a server renderer type that can be then used inside of an API route to render a U component as HTML which you can then send over the wire inside of an endpoint request. Now if I go ahead and run this code, the serverside rendered version of my application will be available at localhost 3000 which if I go ahead and do a curl request, you can see is returning the actual HTML which is great when it comes to SEO. As with all things in software development, serverside rendering in U does come with a few trade-offs with the most major one being that client state isn't available when on the server rendered path.

[00:07:40]Fortunately, this can be managed through the use effect hook, similar to how one would handle this when using something like React server components. Other React-l like features that U provides include U router which is used for routing, suspense which allows you to display a placeholder UI whilst an asynchronous task is loading and agents which allow you to offload tasks to web workers. As you can see, U is very capable when it comes to developing Rust single page web applications. Of course, building a web application locally is only half the battle and in order for anybody to be able to use your application, then it needs to be deployed. Fortunately, when it comes to you, deployment isn't that difficult.

[00:08:20]Although, if you're coming from the world of say NextJS and Versell, then there are a couple more steps one needs to take. So, let's quickly take a look at how to actually deploy a Rust web application. First things first, we need to build our bundle, which is done using the trunk build-release command. This command will cause trunk to compile the application into WOM and then produce a directory called dist which contains the application bundle including the compiled web assembly, a JavaScript loader, our applications CSS, and the configured index.html.

[00:08:51]With our bundle created, we're now able to deploy it behind a reverse proxy such as caddy onto a VPS. Therefore, in order to do so, we're going to need a VPS instance to deploy on. Fortunately, I have one already provided by the sponsor of today's video, Hostinger. The VPS instance that I'm going to use is the KVM2, which comes with two vCPUs, 8 gigs of RAM, 100 GB of SSD storage, and a cool 8 TB of bandwidth. This is more than enough to not only host one web application, especially one written in Rust, but in fact, multiple applications, which is what we're going to deploy throughout this video. In my case, I have the KVM2 running with YUbuntu 2404, which is the latest LTS at the time of recording, although there's going to be another one dropping very soon. In order to deploy this application, the first thing I need to do is to SSH in and install a reverse proxy on this machine. Uh, in my case, I'm going to go ahead and install Caddy, which is currently one of my favorite reverse proxies out there, as it provides and provisions HTTPS certificates out of the box. To install Caddy, I can just copy the install command from the Caddy website and then paste them into my VPS as follows. After a short while, we should then see the Caddy service is up and running, which I can check using the following system control command. Once installed, I can then configure it to serve my U application using the following configuration inside of the Caddy file.

[00:10:11]In my case, I already have this DNS record pointing to the machine, so it should just work once Caddy is reloaded.

[00:10:17]Now all that remains is to copy over our applications distribution bundle to the location that Caddy expects. First creating this directory and then using SCP. Now if I open up my browser and head on over to my configured domain name, we can see that the U application is available which you should also be able to access as well. As I mentioned before, the VPS instance that I'm using is the KVM2 provided by Hostinger and comes with 8 gigs of memory which is a good amount for running multiple applications. Of course, we all know that the price of RAM has gone up recently. Fortunately, however, when it comes to Hostinger, 8 GB won't cost you your firstborn child, as the KVM2 comes in at only $8.99 a month when you purchase a 24-month term. The benefit of doing this is that it locks in the price for two whole years, which means you'll be protected from any future price changes during that time. If this price of $8.99 a month wasn't good enough, then by using my coupon code dreams a code when you check out, you can save an additional 10% off, making the VPS instance an even more affordable option.

[00:11:16]So, to get your own long-term VPS instance at an incredibly affordable price, then make sure to visit hostinger.com/dreamscode and use my coupon code dreams of code when checking out to save an additional 10% off. A big thank you to Hostinger for sponsoring this video. As you can see, deploying a U application is incredibly simple, especially when it comes to client side rendering. For serverside rendering, however, it's a slightly different process and involves deploying the application binary for the server that you compiled. However, the benefit of doing so is that it also makes it easier to deploy a back-end web API alongside your project, which most modern web applications typically require. However, if you do want a more full stack solution, then there are a couple of better options when it comes to Rust. The first of these options is Lepttos which is a dedicated full stack web framework focused on fine grain reactivity similar to solid JS. This means that unlike React and U, it doesn't use a virtual DOM and instead relies on signals and dependency tracking in order to perform DOM updates. This makes Leptos extremely well suited to more complex user interfaces. But it does come at the cost of being a slightly different mental model and in my opinion isn't as ergonomic to use when it comes to developer experience. In any case, if we take a look at some example code when it comes to Leptos, you can see it's very similar to the U component that we looked at before, but with a couple of key differences. For starters, we're managing state using a signal instead of the use state hook, which then returns two values, a getter and a setter.

[00:12:47]Another difference is the macro name that we're using, in this case called view. whereas with U it was called HTML.

[00:12:54]Other than that though the interface for defining HTML elements and defining our view looks pretty much the same. As you can see both Leptos and U are incredibly similar to one another. And this isn't really a coincidence as most of the Rust web frameworks have converged around this similar style. This is also true when it comes to serving leptose code as just like you it also makes use of trunk when it comes to client side rendering.

[00:13:18]Oh, that reminds me. One thing I forgot to show when it came to trunk serve is that it also provides hot reloading out of the box. Here you can see it in action when I change the title of my Leptose counter and head back on over to the web page where you can see the change has been applied without me needing to rebuild or reload the application. Whilst you can use trunk with Leptos, it's only really viable to do so when it's client side rendered.

[00:13:40]And whilst there's nothing wrong with this, Lepttos does support the ability to be used as a full stack framework, which does provide a number of useful features that aren't available when client side rendered. So how does one use Leptose in full stack mode? Well, in order to do so, the first thing one should do is to create a new project using the cargo leptos plugin, which can be installed using the following cargo install command. Again, this command takes a little bit of time to install and in my case, it actually took longer than trunk. Fortunately, there are some binaries again you can download and install. Or if you're like me and use either Nyx OS or Nyx Darwin, then you can just go ahead and add it into your configuration. In any case, once installed, we can then create a new full stack leptose project using the cargo leptose new command followed by the name of the application and the git URL of the template we want to create from. In this case, I'm using the Axom template, although Leptos does provide support for actics as well. Now with our full stack application created, we can then run it using the cargo leptos serve command as follows which will build and serve our application for us. Once complete, I can then access it over localhost 3000 uh which you can see is working. The benefit of using Leptos as a full stack application is that it provides a number of features out of the box. These include serverside rendering, multi-page applications, progressive enhancement with the hydration SEO and Tailwind support by default. Perhaps the biggest benefit of using full stack mode, however, is that you get server functions through the integrated backend, allowing you to call and run code on the server without needing to define a dedicated API service. To show how this works, here I have the following code, which defines two server functions. One to add an item to a to-do list, which is stored in memory, and one to return this list called get to-dos.

[00:15:23]If we scroll down to the to-do page component, you can see that both of these actions are referenced, which allows us to either add a to-do item to the list or to obtain them when the page reloads. If I go ahead and now run this code using cargo leptus serve command, I can then access this web app on my browser at localhost 3000. If I go ahead and add a couple of items into this to-do list, they'll be stored in a vector on the server, meaning that when I go to refresh the page, the state is persisted and my to-do list remains. By the way, in addition to cargo leptose serve, you can also use the cargo leptose watch command, which will perform hot reloading and rebuild/reload the application whenever the code changes, similar to what we saw with trunk. As you can see, by using leptos in full stack mode, it's incredibly simple to add serverside functionality.

[00:16:11]But that does beg the question of how does one go about deploying leptos as a full stack application. Well, the most robust solution in my opinion is to make use of either a Docker file or container file to create a container of your instance of which there's an example in the Leptos documentation. This allows you to then deploy the application to any container platform such as Docky K3s or just run it directly inside of a Docker installation uh such as the Docker Manager feature provided by this video sponsor, Hostinger. For this video, however, I'm instead going to show how to run this directly on the VPS instance itself, of which the Leptose documentation provides some instructions on how to do this. The first thing to do is to actually build the application, which in my case, I'm going to go ahead and do on the VPS using the following cargo leptos build command. Once this completes, the next thing to do is move both the application binary and the site resources into a dedicated directory.

[00:17:02]Then we can go ahead and run the application using the following command before adding in an entry into the caddy file to proxy to the address of this running instance. Lastly, all that remains is to reload caddy using the following system control command. Now, if I tab back to my browser and head on over to the domain name that I configured, which is leptos.zen.cloud, you can see my Leptos website is now being served both the front-end application and the server side functionality. Very cool. In addition to both containerization and direct deployment, Leptos also supports the ability to be deployed serverlessly through AWS Lambda and the fantastic Cargo Lambda plug-in, which I'm probably going to do a dedicated video on at some point in the future. In any case, as you can see, Leptos makes it incredibly easy to build and ship a full stack web application, which is my personal preference when it comes to web development over using something like a clientsideonly framework. However, Leptos isn't the only full stack web framework when it comes to Rust. And in fact, there's another that I actually prefer just a little more. Dioxysus.

[00:18:04]Dioxysus, in my opinion, is a kind of special framework and one that I believe is going to be incredibly impactful in the near future. This is due to the fact that you can write code once and run it in multiple places, be it on the web, desktop applications, and even when it comes to mobile. I have a dedicated video planned to talk more about Dioxysus and why I believe it's going to be so impactful in the future. For this video, however, let's focus on Dioxys's core offering, which is as a fullstack web framework. Similar to both U and Lepttos, Diosis takes a component-based approach to rendering. However, the main difference is that rather than defining HTML as its view logic, Dioxysus instead uses its own DSL called RSX, which is basically a onetoone representation of HTML, but just emits some of the syntax around tags. Other than that, however, Dioxis is very similar to Leptose, making use of signals in order to manage state, providing Tailwind CSS support out of the box, and also the ability to operate as a full stack framework. This means you can again use server functions which are powered by Axom under the hood and you get all of the benefits that serverside rendering provides.

[00:19:11]Additionally, just like Leptos, Diosis also provides its own CLI tool for serving hot reloading and bundling which is called the Dioxis CLI. This is again installed using cargo and upon doing so provides the DX command which you can use to perform many different tasks related to Dioxis. One benefit that Dioxys has over Leptose is that they also provide their own component library which is a SHAD CN inspired set of components built on top of Dioxys primitives cutting down the time it takes to get started building web applications. All of this for me makes Diosis my favorite framework when it comes to web development using Rust. So much so that it's going to be the main framework that I use for web development in the future. Of course, Dioxis can also do native rendering and mobile applications as well, which is a rather big benefit. However, it's yet to become my go-to framework for building desktop applications, although at the rate it's improving, it might one day be. Speaking of Rust on the desktop, many of these popular frameworks can also publish to the web as well. For example, here I have a demo desktop application I've built using, which is a desktop framework entirely written using Rust.

[00:20:19]Whilst this application runs on the desktop by default, it can also be compiled to web assembly and then by using trunk can be served on the web. In addition to iced, other rust desktop frameworks that support compiling to WOM include egeuey, which is a really simple yet powerful immediate mode framework, and GPUi, which is the framework behind the Z text editor. GPUi, in fact, only added support about a month or so ago, which speaks to how fast things are improving when it comes to the Rust ecosystem. Whilst it is really impressive that these frameworks can publish to the web through Wom, I personally wouldn't use these when it comes to developing a production web application. This is because rather than modifying the DOM, these instead draw to an HTML canvas, which does come with a few drawbacks, especially related to accessibility. Although perhaps the new HTML and canvas API will help to solve some of these issues. Even so, it's still really amazing that we can publish desktop applications to the web. And in some cases, such as if you're building a multimedia application like a game, then this can be quite useful. By the way, if you want to play around with any of these examples, I have published all of them onto the VPS instance with their framework name as a subdomain on the zenful.cloud host. This includes the three desktop frameworks I just mentioned, as well as U, Leptos, and Dioxys. Okay, so now that we've taken a look at some of the popular frameworks for building Rust web applications, there's a couple of other crates worth going over that help to make Rust on the web incredibly viable. Typically, when it comes to building modern web apps, at some point there's going to be a need to interact with the browser's APIs. Uh whether it's playing a video, interacting with local storage, or just simply opening up a file. These APIs unfortunately require the use of JavaScript, which presents a bit of a problem when developing a web application using Rust. Fortunately, there is a solution through a crate called Web CIS. This crate allows you to interop with browser APIs from within WOM, meaning you can do pretty much anything that's possible inside of a JavaScript context. This pairs with another framework called JSIS, which allows you to interface with JavaScript primitives and data types from within Rust, uh, making it a sort of foundation crate when it comes to working with JavaScript. To show how this works, here I've got an example project in Dioxysus where I'm using the web cys crate to load data in from a file using the show open file picker API that I'm then passing to a video component for it to render. If I go ahead and fire up Chrome because Firefox doesn't yet support this API, then you can see it works no issue as if it was any JavaScript-based web application. Very cool. Of course, another feature of web development or bug depending on who you ask is the extensive ecosystem that helps you to implement features without needing to reinvent the wheel. Unfortunately, again, the overwhelming majority of these are distributed as JavaScript packages. And whilst the ecosystem for Rust and WM is starting to grow, it's still orders of magnitude less compared to what's available in the JavaScript land. Fortunately, however, we can still tap into this ecosystem as there's a way to work with these packages from within Rust. To show this in action, here I have a simple Dioxis application with a button, which if I go ahead and press, you can see produces a bunch of confetti. This application is interacting with confetti.js, which is probably the leading confetti package when it comes to the web. And yes, it's written in JavaScript. The way I'm able to do this is thanks to the WOM bind genen crate which allows Wom code to call JavaScript functions basically using FFI which is incredibly cool. As you may be able to tell from looking at the code, the biggest issue that I've typically had when using these crates is that they're not exactly the easiest to work with. And the subsequent code that comes out of doing so is just bloody awful. Historically, this has been my main issue when it comes to Rust on the web, as the cognitive load in order to work with browser APIs or other JavaScript packages has been typically quite high. Fortunately, we're now in the era of agentic engineering, and thanks to tools such as clawed code and codecs, I'm yet to have encountered any issues working with these crates on recent projects. For myself, this is what makes Rust on the web so appealing in 2026. Because in the past where I would have struggled to obtain par with a TypeScript implementation in a decent amount of time, now it's easier than ever to do so because of how easy it is to generate code thanks to these tools.

[00:24:34]In fact, it's so easy now that the main challenge is ensuring code correctness and stability, which fortunately happens to be Rust's bread and butter.

[00:24:42]Therefore, because of this, I'm planning on building more web applications in the future. However, rather than doing so using either JavaScript or TypeScript, I'm instead going to do so using a language I really like, which if you hadn't guessed by now, is going to be Rust.