Making a Statically-Linked, Single-File Web App with React and Rust

The parent already covered your whole objection in their comment "but your backend is in Rust rather than JavaScript, and the user navigates to the app from their browser." -- and went to provide even more context and info that shows they perfectly know the distinction.

The parent's point is not that it's like Electron in that it bundles a browser, but that it's like Electron in that it allows you to bundle a web application into an executable.

The difference is that it doesn't include the rendering engine along.

Was OP's quote, but "somewhat similar" still applies. For some, the whole point of Electron is they can see web pages...meaning maybe there isn't only one "whole point" of it and therefore to some "nothing like Electron" is incorrect.

Well, Chrome doesn't really allow chrome.dll to be easily used. Electron has deep requirements on Chromium for V8, IPC, webview, customer protocol handlers, etc IIRC so it can't just easily switch browser engines. I'd say if you want this, the Chromium project would have to prioritize a stable Chrome ABI from their shared lib which I doubt they would do. And it still doesn't solve the extremely mem-bloated approach they take to serving the web stack. So for that, the Chromium project would have to prioritize better runtime feature gating for mem reduction and maybe revive first-class support for single-process mode, which I doubt they'd do. And even then, you're carrying node.

To sum up my rant, I'm afraid the fast moving web stack, coupled with the fact only a few companies can keep up, coupled with the fact that those companies are laser focused on their own browser use case and not embeddability combine to make this incredibly common desktop use case still suck. In the meantime, just hope these OS engines stay minimal and don't fall too far behind the standards you want.

Having a browser installed isn't the problem. The problem is having a specific version of a specific browser installed because that's the only thing you've tested against.

(I'm not condoning this, and haven't worked with Electron myself, but that's my understanding of the motivation.)

But what happens if your js stack requires a feature that is only in chrome 65+ and someone elses stack relies on a feature that was depricated/removed in Chrome 60? Furthermore, does that mean if a user goes to task manager and ends the task of chrome, that your app would be killed too?

We tried that. (DLLs, shared objects). Doesn't work.

Which browser? Why do I want to spend my time making my desktop app run in Chrome and Firefox and Internet Explorer and Edge... and all the old versions of these. Plus the fun of saying to my customer "oh you have to upgrade your OS before you can run our app, sorry".

That’s literally what a web view does, though.

> With all that work why not just link to gtk and build on that?

Because the packaging and distribution experience sucks. Seriously, that's all it is. Make it so that I can run one command and turn my GTK app (written in a language that has a decent package manager and library ecosystem i.e. not C or Vala) into single-file executables for all major platforms, and you'll take the marketshare back from Electron.

> With all that work why not just link to gtk and build on that?

If you're asking "why not link to gtk webkit?": because I don't want to statically compile or ship with the entire browser (not to mention Windows compat). If you're asking "why not build your app on gtk instead of web tech?": there are a million reasons and this question happens frequently, so not really sure it's worth rehashing here.

> Why should a desktop app even care about host headers?

It's one way to prevent DNS rebinding attacks. You can employ other methods to ensure the client is "authenticated" to use the server. OP's app listens on port 5000. I can have a page on example.com:5000 and set the DNS zone to a really low TTL change its A record to think it's 127.0.0.1 after first load thereby letting the browser think I'm same origin w/ just an IP change, then I can ajax call to example.com:5000 to access the local daemon. That's how DNS rebinding attacks work and host header checking is one way to for the local web server to prevent other pages from accessing it. Project Zero is finding lots of local HTTP servers that are reachable from web pages.

They are about the same in what concerns UI/UX for the end user.

Just the size of the tiny bit of C code you'd compile with. It uses shared libs already on the system (though not familiar w/ how many distros have gtk-webkit2 on Linux).

Yes, including arbitrary data in binaries is probably as old as making binaries itself.

I think what is new is that in the mid 90s you didn't have an open source, memory safe, ergonomic, strongly typed, type inferenced language that targets multiple platforms with ease, with a decent standard lib. Rust is delivering that. Golang is delivering that. I think those two are novel in that sense.

From where I'm sitting the last few decades have been ruled by VMs and the explosion of scripting languages, because no one wanted to use those Apple/Microsoft toolchains that have been around in the 90s. While those toolchains rested on their laurels (or didn't, can't tell the difference now), Java became the enterprise workhorse.

There still isn't a good built-in way to do this portably in C++.

Was the "data fork" and "resource fork" of the original Mac binaries in 1984 something different than what you're talking about?

Aren't resource scripts (.rc) even older than that?

I haven't compared them (as I haven't used go-bindata), but go.rice has a pretty ergonomic API -- I once took a look at go-bindata, but I much prefer go.rice. go.rice also seems more active in general.

I actually thought that's what Rouille (https://github.com/tomaka/rouille) was, which was mentioned in the blog post, but it looks like just uses the macro from that package (to include the strings), not the actual library even, since at the end of the day he opts for rocket (https://rocket.rs/)

[EDIT] - I didn't address your question about go.rice -- from what I know, it doesn't have this kind of thing built in, and I don't know that it even should... "flipping a production switch" is a pretty application-specific endeavor. Also this sounds like something you should be doing with your build tools..., can't include something in the binary at runtime. Maybe I misunderstood what you were asking.

To clarify, the description for go.rice is:

> go.rice is a Go package that makes working with resources such as html,js,css,images,templates, etc very easy. During development go.rice will load required files directly from disk. Upon deployment it is easy to add all resource files to a executable using the rice tool, without changing the source code for your package. go.rice provides several methods to add resources to a binary.

I’ve come halfway to building this a few times; it’d be extremely helpful for mdbook, for example.

That feature's on my (currently just mental) TODO list for my http-serve crate (https://github.com/scottlamb/http-serve). I want to use it in my moonfire-nvr app.

I'm thinking something a little fancier than include_str! because I want to include a whole subdir of resources, and I probably want to embed the gzipped version (and uncompress into RAM for when there's no "Accept-Encoding: gzip") rather than the reverse.

Assuming I understand you, it would be easy via an interface.

Build an interface for the go.rice (or go-binddata/etc) such that, depending on the environment, it either pulls the file from disk or from memory. Super easy.

I seem to recall seeing a Go library that actually has this functionality built in, but I've got no idea which it was.

Rust can create static binaries -- AFAIK there isn't even such a thing as a "statically linked" jar -- if you're relying on a VM (the JVM in this case), your program isn't statically compiled. It's not even "compiled" in the strict traditional sense, since the target isn't the machine, it's an VM (JVM).

But yes, it is just like including files in your classpath (and making sure they end up in the jar), then serving them from a Netty endpoint or something.

I actually already use the include_bytes! macro within the build.rs. Looking at the source I see that I create arrays of arrays of bytes, not just arrays of bytes as opposed to what I originally said. It was a few months since I wrote that code so I hope I would be forgiven for not remembering such details ;)

My eventual plan that I remember now was to make it so that I could reference static files (CSS, JS, icons and images, fonts) in my static HTML files and HTML templates, and build.rs would automatically include the bytes of those files.

PAR[1] is what you're looking for.

It supports loading XS modules by overriding DynaLoader bootstrapping methods; it writes shared object file to a temporary file at the time it is needed.

1: https://metacpan.org/pod/PAR

Yea I haven't used fatpacker but I've heard it is only for "pure perl" and can't be used with anything that drops down to XS or C.

You're bashing it based on some assumption that it's being heralded as an amazing piece of tech. It's just a static binary. If you want to argue the merit of static binaries then, by all means. I personally love them, it's one of the reasons why I like Go so much. I'm sure there's a ton of people who like static binaries, and who dislike them.

There's nothing else to see here, you either like dependency-less binaries or not.

Hell, if anything, I don't see the point of your point, calling static binaries "real bullshit". Depending on the scenario static binaries are either better for you, or worse for you - it's just a tool in a bag of tools. How can that possibly be bullshit? Is a wrench bullshit?

> Normally webservers serve files with the sendfile system call for zero copy IO. If the string is statically included in the binary then it first has to copy it into kernel space to send the data. So this is actually less efficient.

This doesn't sound right to me - sendfile's "zero copy" is about eliminating the extra copy when you read() a file into a userspace buffer and then write() that file into a socket. If you have a memory-mapped file (which is what your executable itself is), and you pass an address inside that mapped region to write(), I would hope that the kernel will just access the buffers of that file directly - i.e., the fact that it's memory mapped means there is no separate copy of the file, there's a virtual page that references the single kernel buffer for that file. So at that point write() should behave just like sendfile().

If you need to process the file in the kernel itself, there will still be a copy, but you'd have that in either case. If you don't, I would again hope that both write() from a memory-mapped region and sendfile() know how to DMA the file from the disk to the network card.

I am not confident about this and it seems worth benchmarking. (Also, your production server probably uses HTTPS, at which point this is all irrelevant if your TLS encryption happens in userspace. If you're using in-kernel TLS, then you're definitely not doing DMA, and I would strongly hope that sendfile() and write() from a mapped buffer involve the same number of copies - one read from disk, at which point the kernel encrypts it into a writable buffer.)

Putting the string in the binary is really only useful for trying to do ultra-portable deployments like this imo. The overhead of copying the string into memory is pretty meaningless in the use case where you only expect a single, home-desktop user.

Now if this was a production server having to service thousands of clients than the sendfile optimization becomes much more important.

> Normally webservers serve files with the sendfile system call for zero copy IO

Not if they are doing their own tls encryption which hopefully one day is the new normal.

I actually agree. I extracted this tutorial from a project I'm working on developing an RTS game for school. I'm experimenting with having the game loop run in Rust and seeing if I can send render updates fast enough to smoothly run the UI in JS. It's working pretty well so far. I'm using Protobuf 3. I'd love to get capnproto or flatbuffers working eventually, but neither of them seem to have both JS and Rust support mature yet. I think the next obvious evolution from this tutorial would be to connect a sqlite db. Not sure how easy statically linking with it is though.

I have such a thing in Haskell: https://github.com/shapr/sporkle/blob/master/app/Main.hs

It's not Rust, but it is a really crappy exercise tracking app I wrote for teaching a class.

Thing different about my code: I build the HTML in the source itself, and I don't use React

Last week I learned that if you configure your bucket name the same as your domain, then a simple CNAME record will work without Route53.

Yep, this is what I do for my site. 51 cents a month.

Thx! Nice.

Maybe json-api on a websocket on the same port as a transport would also be possible? Protobuf seems a bit overkill for something that is that tightly integrated together IMO. But if it works, it works.

If this project discussed here is using react and rust together, could I just use an react example for OAuth2 to get started with? Up to some months ago, there were no examples of using any of the Rust web frameworks with OAuth2.

With something like py2exe.