Musings of Programming Future Blazor or Rust

March 12, 2020 | Reading time: 4 minutes

I’m a programming professional. I’m not the greatest developer by any stretch, but I’m competent and responsible. Even nearing 50 years old, I’m keeping my eyes to the future. Right now I feel that future is WebAssembly. I’ve been keeping my ear to the ground and the two major players aiming for developers in this technology is Rust and Blazor.

As this technology matures I tend to start weighing my options on “which to choose.” However, this is more of a “which would I like to focus on for now,” since my interests in this part of science is always in flux. I’ve got a small list of pros and cons which appeal to me.

These are far from a comprehensive list, for I’ve already chosen Rust as my next focus. I’ll explain below.

Rust and wasm_bindgen


Pros for Rust

  • Rust compiles down to (nearly) the smallest static executable.
  • Rust doesn’t have an extensive runtime. Everything has a runtime - even handwritten code on an Arduino. Rust has a very minimal runtime and no garbage collector so performance is always stable and predictable.
  • Fast, Fast, Fast. Because it’s compiled as if it were written in C/C++ it’s just as fast as those compiled languages on bare metal or in a VM. This is why they call Rust a “Systems Programming Language.”

Cons for Rust

  • Moderate learning curve because the language doesn’t let you shoot yourself in the foot with data races and memory allocation and management. The compiler, although friendly, can be frustrating to new folks.
  • No good GUI development kits. Although this is only slightly true. I’ve been able to write, compile, and run quite native GTK3 apps in rust, but I’ve not had time to test this on any larger apps.
  • The language is still in flux. The language, although breaking changes are rare these days, is in flux and sometimes breaking changes to existing code happen. This also can happen with C# and DotNet, but not nearly as much due to the age of that language and platform.
  • No Easy Single Project for Client and WebServer This is something which is better described below.

Blazor and DotNet Core


Blazor is Microsoft’s team’s amazing effort to put DotNet into browsers. They’ve succeeded by using a subset of the mono runtime. It’s (relatively) small, fast and works quite well. The memory and download runtime footprint vs rust compiled .wasm files is higher, but Microsoft devs promise they’re working on that.

Amazingly enough they’ve got an already working all-in-one solution for both client-server rendering and interaction.

Pros for Blazor

  • Integrated Client/Server API. Using the same language on both the front end and the backend, a development team can (with just a few keystrokes) use GRPC, REST, or GraphQL for the WebAssembly client to
  • Razor Components. Simple and approachable html templating make it simple to add pages and functions to a Single Page Application (SPA) on the Blazor front end. This is something Rust can do (through the yew framework), but isn’t nearly as slick.
  • Open Source. Not only can one create apps in Windows and Visual Studio, a developer can use the command line tools in DotNet Core to create projects and edit the source files in whatever editor they choose. It’s slicker and more integrated in Visual Studio, but it’s no longer required to be a Windows-Only development platform (nor has it been in years).
  • Blazingly fast development. The work that Microsoft’s team is putting into this platform really shows. It’s gone from “zero to hero” in less than a year and, although they don’t recommend it, is easily ready for smaller production projects.

Cons for Blazor

  • Runtime. Blazor is still dotnet, and as of the time of this writing (and last I checked), there’s no compile-ahead for the Blazor app, so it’s compiled on load (but once it’s JIT’ed it’s not so slow on subsequent loads unless there’s a change to the program). This could potentially be slow on low-power devices or enormous applications. This could potentially slow some processing down in comparison to Rust and straight WebAssembly in contrast to a runtime running on top of WebAssembly.

Why I Chose Rust and wasm_bindgen today

I’ve chosen Rust partially because I’m an old C grognard and I miss that level of programming. Sure, I could just compile WebAssembly from C++ or C, but Rust gives so much to an out of practice developer for that level of programming. It may be a bit more work to get a client/server solution working for me, but I think in the long run it’ll be a better laid out system.

Most importantly I’m a Linux user. I’m a proponent for freedom to install my choice OS on whatever device I want with no “spyware” or limitations (although I am an Ubuntu user, and lots of die-hard Linux folks think that’s spyware).

I’ve already got some WebAssembly projects for my personal project Savaged.us, which is an app written in Node/React/Typescript. I’m planning on starting to replace some components bit by bit with WebAssembly modules. This is a little easier using Rust.

To be honest, if I were to start Savaged.us new, I believe it would be a Blazor project using C#. There’s a ton of potential in that platform, and it’ll only get better.

Comments

comments powered by Disqus