How we chose the tools: Tauri, Electron, then Wails and Go

On 1 November 2025, Tziyun B’Rega was set up on a tool we had chosen because it looked exciting. Less than two weeks later, most of the code written on it was deleted.

Choosing tools is a product decision: which ones will actually get a working product into a school’s hands? Tziyun B’Rega used three different foundations before it settled. This is why, in the order the project history records it.

Key points

• On 1 November 2025 we set the project up on Tauri and Rust because the tool looked exciting. Nobody had asked for Rust.
• Less than two weeks later, most of the code written on it was deleted.
• We went back to Electron, built on tools we knew, and later arrived at Go and Wails, which we had not planned.
• The lesson: pick tools you can deliver with.

First choice: Tauri and Rust

The project was created on 31 October 2025, and on 1 November it was set up with Tauri (opens in a new tab). Tauri builds desktop programs with the back end written in Rust (opens in a new tab), a modern language known for being fast and careful. As developers, our first reaction was the usual one: this is a cool tool, and it should be quick.

That choice was a matter of taste. Nobody had asked for Rust. The history shows a lot of code for a first fortnight: a first link to AMC (opens in a new tab), an existing exam tool, a program that wrote exam files for a document-layout program called LaTeX, Hebrew fonts, a local database, a user system and a log of what the program did.

Where Rust stopped

On 13 November the project was cleaned out. A cleanup guide written that day lists what to remove from the Rust side: the AMC code, the typesetting generator, the user system, the database. Its reasons are plain: the old approach is “not needed”, one part is “over-engineered”, and a simpler way is chosen. Most of the Rust code went in a handful of saved steps in the project history (commits) that day.

Rust was not simple for us. Our experience is in Node.js, not Rust. The next day, 14 November, came a new set of Rust files for making exam PDFs and a bundled third-party PDF program for each of three operating systems.

The notes beside them explain the wall. In the web view that Tauri uses (the browser part that the operating system already has, explained below), the browser’s print function needs a person to click, and the program could not save a PDF by itself. The notes list several options, a Tauri print plugin among them, and none is marked as working.

Second choice: go back to what we know

So we stopped trying to be clever. On 19 November the first Electron (opens in a new tab) code appears, with the commit message “working pdf generation tested” (spelling fixed here). Electron is built on JavaScript and Node, the tools we already knew how to deliver with, and it can print a page to PDF by itself. Tauri was fully removed a week later, on 26 November.

The decision was simple: a tool you know well and can finish a product with is worth more than a more exciting one.

Electron did the job for several months. It also brought the printing problem described in “Why we left Electron”: pages that drifted when printed in batches, and a long search for something else.

Why Electron is heavy, in plain words

A desktop program that shows its screens like web pages needs something that can draw web pages. Electron brings its own: a complete copy of a browser inside every program. Install three Electron programs and you have three browsers on the computer, each one a version the makers chose and control. That is the price of knowing it will look the same everywhere, and it is why such programs tend to be heavy.

Tauri and Wails (opens in a new tab) take the other road. They use the browser engine that the operating system already has, called a web view. On Windows that is the engine behind Microsoft Edge, which is built on Chromium (opens in a new tab). On a Mac it is Apple’s own engine, WebKit, and on Linux it is a version of WebKit too. The program stays smaller because the browser is not inside it. The trade is that the engine is no longer ours. It is whatever the computer provides, and a mouse pointer that looked wrong shows what that can mean.

Third choice: Go and Wails, which we had not planned

The search led to Folio (opens in a new tab), a library written in Go (opens in a new tab) that makes PDFs directly, and to scanner and image libraries that were also stronger in Go. The question became what to wrap around a Go back end.

The decision record for Wails (a short note we wrote when we chose between options), dated 14 May 2026, lists what it considered:

• Electron next to a Go helper: two runtimes and a full copy of Chrome in every install.
• Everything in the browser: rejected, because a browser cannot freely read scanner output or write to the user’s folders.
• Tauri again: rejected for a plain reason. The back end would have to be rewritten in Rust, and the libraries we needed were in Go.
• A native Go interface toolkit (one built from the operating system’s own screen parts): rejected because it could not carry the Hebrew right-to-left screens we had built.

Wails was the one that fit. It builds the program in Go and shows the screen using the web view that Windows and macOS already have. The screens we had built in React moved over almost unchanged. The plan was committed on 2 May 2026, and on 7 May the first commit removing Electron’s files from the app followed. The Electron folder itself was deleted on 9 July.

The surprise

Here is the part we find funny. What drew us to Tauri was a small, quick program that uses the system’s own web view instead of carrying a browser. We did not get that from Tauri. We got the same kind of result from Wails, a tool we had not planned to use.

We are not claiming a speed number. The decision record gives reasons, such as no bundled Chromium and one program file. What matters here is the order: the result we wanted came from a different tool than the one we chose for it.

We did not know Go before this. We learned it as we went, leaning heavily on AI coding assistants, and learned to give them written rules and reusable skills so the code stayed tidy. We took that risk on purpose, because by then the libraries we needed were in Go and the other options were worse.

What we learned

Pick tools you can deliver with. Exciting tools are fine for experiments. For a product meant for schools, the first question is whether you can finish it, support it and fix it at night. We built Tziyun B’Rega lean and carefully, without cutting corners, and that starts with tools you can stand behind. Our first choice failed that test, our second passed it for a while, and the third arrived because the problem pushed us there.

One more fact about how it was built: the design, the architecture and all of the engineering of Tziyun B’Rega were done by one person.