Show HN: Sauron – A web framework in Rust that adheres to the Elm architecture

Large bundle sizes are not a consequence of creating UIs on the frontend, they are a consequence of bad practice. I have created plenty of purely frontend apps that don't even approach 1 MB let alone 6 MB. In fact, most languages that can target WASM seem to produce enormous modules compared to a reasonable frontend JavaScript app. Rust is an outlier in my experience because of its minimal runtime.

It's also worth noting for example that only 1/5th of the data transferred when I load medium.com cold is their JavaScript, so WASM can't really help them either way.

Another lightweight contender, not WASM though, is Phoenix Live View[1]

[1] https://github.com/phoenixframework/phoenix_live_view

Where are you seeing 6MB on Medium? It looks everything aside from images is <1MB compressed.

https://www.webpagetest.org/result/190426_YD_9088b86bbe21e61...

If I get this correctly, both this and Blazor are handling most of the UI logic in front-end, despite they are WASM.

So WASM is just another bytecode encoding that relatively smaller than JavaScript, without solving the problem from the root.

In contrast, a server-side heavy solution like Phoenix LiveView that has been heavily mentioned in this thread would do hold the logic on the server side, so in the client, there's only very few generic logic handling the DOM patching.

iirc WASM will tend to be larger than minified javascript.

Blazor's bundle size (assuming client/wasm rendering) is pretty damned big. Also, JS is a pretty cool language imho.

"Lord of the Crates" doesn't quite have the same ring to it

You need to use the script for release mode.

$> wasm-pack build --target no-modules --release -- --features "wee_alloc"

It will shrink it down to 165KB

> Elm gets plundered repeatedly before it ever reaches version 1.0.

I concur. Ever since Elm 0.17 [1], when Evan removed event streams and standardized on The Elm Architecture, Elm seems to have lost its way. Just saying as an interested outsider.

[1] https://elm-lang.org/blog/farewell-to-frp

I presume it is a matter of perception: Elm is now perceived as a GUI toolkit rather than a language in its own right. Elm achieved simplicity and, ironically because of that, it is now plain easy to port its main ideas to other languages.

Because elm is elegant. I have written web-app with elm on the client side and rust in the backend. It was great, except for duplication of code when serializing/deserializing json data when making API calls. With sauron, I save up a lot of duplicated codes, and gotta squeeze that webassembly performance as well.

The main issue with Elm is the glacial development pace. I understand why it is the way it is (it shows in how well designed what is there is), but it really does hurt as someone who wants to adopt it.

Yep! I'm writing this from Elm in the Spring, the 2nd of 4 dedicated Elm conferences in 2019.

JS/TS continue to dwarf everything else, but it's possible that Elm is the most widely used JS alternative at this point. (Hard to know definitely though!)

I like to think Elm is the most influential web framework that no-one uses.

We're using Elm for our front-end UI. With Erlang in the backend (not Elixir). It's very reliable and predictable. I hope it succeeds.

Would it be fair to expect the performance to get better once the Web IDL Bindings Proposal for WebAssembly is done?

1.) The syntax in creating the view: is just plain function calls which the rust compiler can accurately tell you about errors in your code, ie: typo, unclosed brackets/braces/parenthesis mismatch.

2.) Concise code, there is not too much ceremonial/boilerplate code to get started.

3.) Less code in the library maintain, there is no parser(which are mostly complex).

4.) Sauron is using wasm-bindgen, yew is using stdweb.

5.) It's in the early phase, so the performance is not yet optimized. https://github.com/ivanceras/todomvc-perf-comparison/

Nothing compares. Nothing compares to Yew.

It's based on Yew itself and since Yew is React/Elm like, but this is more Elm inspired I assume it compares like Elm vs React.

The usual mentality is "Use us 'cause we're faster than all those SLOW frameworks!" and then they show you a graph of a benchmark was in a specific instance they're X faster than the common options.

It's fun to see some people being honest about it. "It's good enough" is pretty honest here.

I traded a bit of performance for aesthetics by cloning the children of a node. I tried the todomvc benchmark and saw it wasn't so bad without employing optimizations in placed. It's still in it's early stage though.

The Rust community has high standards for perf!

The main issue is that jsx can contain both mutable references to a variable and immutable references. For example <div onClick={() => count = count + 1}>{count}</div> contains both a mutable reference to count and an immutable reference. Thus, the naive way of storing this in a single struct will fail. The use of the elm architecture (where the onClick handler returns a message, instead of directly updating count) side steps the complicated borrow-checker issues.

It is certainly possible to get around this with the proper procedural macro, but it is not easy, and will never be as "magic-free" as people want.

Look into the framework Yew. It sits somewhere between elm and react in how it's designed, and makes use of an html macro that allows for jsx-like markup.

Since Rust supports macros, I think you can actually implement most of JSX's syntax in it directly without needing an additional compiler.

I can see this going in two ways: either we'll have WASM "shared libraries" that can be cached, or every website will go the way of apps and contain duplicate WASM modules in it.

Not convinced that's the case, with a bit of code splitting the view may end looking more like (pseudo-code):

    fn view(&self) -> Node<Msg> {
        div(self.attributes(), self.content())
    }
    
    fn content(&self) -> Node<Msg> {
        input([
            class("client"), r#type("button"), value("Click me!"),
            onclick(|_| {sauron::log("Button is clicked"); Msg::Click})
        ],[],)
    }

As long as all event callbacks are delegated into the update function and unified in an Msg enum, the code will have the same pattern regardless of how big the project is.

Thanks. I think I'm pretty good at naming. I have a few repo with good names as well.

rustorm - an orm in rust

diwata - a database UI in rust.

Probably not, technically, but it's sort of in that (Gandalf The) Grey area where nobody really gives a shit so you'll get away with it. This is just a random project on GitHub, it's not like a major corporation is putting this out. If they did, they could just remove the copyright images and possibly rename it if they felt it was really necessary.

I’m not an expert, but that seems like an example of fair use to me.

In Europe probably not. In the US it falls under first as fair use.

What specifically are you waiting for? You can already run rust in the browser, by compiling it to wasm and talking to the DOM using wasm-bindgen (like this Sauron library is doing).

You ever tried Clojurescript?

Does Sauron evoke some sort of primal disgust in you like cockroaches do?

There was a time when people named stuff after positive things. If you asked my psychologist ex about people who name things after Saurons and Cockroaches, she'll jump to some 'priliminary conclusions'. This country needs frequent mental checkups like we have frequent dental checkups