// HACKER NEWS — CYBERSECURITY
Topcoat is pushing the boundary of server applications with Rust
Two months ago, we (Julien and I) announced Topcoat, a
batteries-included full-stack Rust framework. It includes views, components,
mailers, an ORM (Toasty), and more. Topcoat aims to make building web apps
with Rust as productive as any other language. We have been hard at work
shipping features, so it is a good time to talk about what is new.
I started my career as a professional software developer building web
applications with Ruby on Rails. At the time, the “build a blog in 15 minutes”
video was groundbreaking. Back then, building software was tedious: writing
boilerplate instead of shipping features. Ruby on Rails challenged that and
proved you could be productive and that building software could also be fun. I
fell in love with Ruby on Rails, worked on the core team for a few years, and am
still a top 50 all-time contributor to Ruby on Rails. Having been
through that period, it is hard to overstate how impactful the Ruby on Rails
philosophy was on software development in general.
Since then, I have spent the past 13 years or so building up Rust’s networking
ecosystem. While Rust has gained broad adoption at the infrastructure level, I
have always had higher-level application development in my sights, including the
same space Ruby on Rails occupies. I've wanted to capture some of the magic I
felt when I built Ruby on Rails applications, but with Rust (who doesn’t like
really, really fast applications that take ~20MB of RAM?).
I will be the first to say Rust isn't as elegant as some other modern languages,
but I'd definietly rather work with Rust than pour acid into my eyes. Also, most
higher-level applications can get away with minimal use of lifetimes and
generics. Rust is very expressive. Applications built with Rust and
well-designed libraries can look nice.
Rust is the best general-purpose language for the new world of AI-driven
development. That includes building web applications or any server application,
really. The role of libraries and frameworks in this new world is still up in
the air. The cost of ditching a library or framework and using a bespoke
solution has gone down, but not disappeared entirely. They will continue to play
a substantial, but slightly different role. Well-defined conventions and
abstractions will help the LLM work faster, with fewer tokens and fewer errors.
That is fundamentally why I am still pushing for a batteries-included framework
for Rust.
I partnered with Julien, who has been leading the front-end design of Topcoat
while I mostly focus on Toasty and the DB layer. We are still figuring out
exactly what this new framework should look like, but it is shaping up to be
something very nice.
When starting to build a web framework, you typically choose to either build a
browser-side renderer or a server-side renderer. If you start with browser
rendering, the challenge becomes getting data from the server to the browser and
rendering the initial page as quickly as possible. If you start on the server,
data access and initial page load become easy, but now latency and client-side
responsiveness become the bottleneck. Regardless of where you start, you
typically converge more and more towards the middle to get the best of both
worlds. We believe server-side rendering is the best default for most web apps,
but we want to make sure you can drop down to fully interactive, zero-latency
UIs when needed.
Topcoat started with signals and a special runtime expression syntax inside the
view! macro: a fully type-checked subset of Rust that can be transpiled to
JavaScript and re-run in the browser. The idea is to have as much of the
rendering and business logic on the server, and only sprinkle in runtime
expressions to bridge the latency gap, for example by revealing a loading
spinner or changing some class attributes. With a system like this, it is
possible to build basic interactivity while avoiding server roundtrips entirely:
However, by themselves, Topcoat’s runtime expressions fall short whe