This is a rewrite of the app in Typescript using vanilla Svelte and Electron.

The following is simply some notes about the reasoning behind the rewrite and honestly can be safely ignored.

Preamble

This isn't a "don't use this!" or "use this instead!" list, this is me pointing out some reasons why I decided to make this switch for a personal project.

I am documenting this mostly because the project got a mention in a Svelte blogpost (!!!). Even though it was a passing mention in the middle of other cool projects, it makes me happy and some people that might have found the project through the post and might wanna know why this sudden change.

Programming languages

For any project, I try to use the best tool for the job even if I don't like it (+80mb installers, the entirety of the Javascript/Typescript ecosystem), if it does the work well enough, improves productivity and the end product, I will most likely use it, specially when talking about a personal project that maybe only I use.

Now, "the best tool" to you can mean the objectively best tool for the job or just what you like/are familiar with, to me, its a mixture of both, I will always try to use safe, fast and strongly typed languages, but God forbid I am not using Rust for web frontend dev.

Ok, maybe with a template engine if I am feeling a bit silly, perhaps goofy even.

So with any project, I try to find a good middle ground where what is being used helps the development of the project but also results in a better product (lightweight, easy to install, fast). My answer most of the time is to just use Go, though garbage collected, its very fast, easy to learn, and overall, a good middle ground.

But I decided I wanted this app to be cross platform as any app should strive to be, so choices like Tauri, Electron and Wails popped up.

Why I used Tauri?

Its wasn't Electron.

Why this chan- wait what

On a real note, it was simple as that. You are telling me I can use a safe language for the logic and also use whatever framework or even none for the frontend without having to bundle chromium? Sign me up!

Even without focusing on performance and just making code that works, the end result was always a small executable that I only needed a command to build an installer/.exe, I could and even did cross compile to Windows in Linux in the old workflow, pretty neat! Also, there was a library for interacting with YouTube's internal API called RustyPipe, which helped a lot when working on the YouTube frontend.

I am not very familiar with cross platform desktop development libraries like Qt, wxWidgets or hell even raylib, so just this one time, I decided to stick with things that are easier for me so I can make the app I want.

Yes, I realize there was most likely a way to get the app in its current state working just fine with one of those libraries, maybe even linking with VLC/mpv for the player which would be pretty cool, but I will be saving that for the next rewrite.

Why this change?

Development

Working on the project is a simple flow:

• Run tauri dev.
• Make change on the backend.
• Wait for it to compile.
• Change some backend comments.
• Wait for it to compile..
• Noticed a bug in a feature, put some println! to check the flow of the code.
• Wait for it to compile...
• Might just have found the issue! Make change.
• Wait for it to compile....
• Not it! Oh wow, I missed this one thing, let me fix it.
• Wait for it to compile.....
• Fixed!

Rust compile time, never seen anyone complaining about it!

In order to reduce the compilation time, I've resorted to reducing the level of debug information in a dev build. This just feels wrong and it of course didn't completely solve the issue.

After "dealing" with that, the thing about not bundling chromium hit, because now I need to make sure the frontend works for the browsers Tauri is going to be using, this can be a pain, but I jumped ship before discovering anything other than Twitch emotes not working.

The Tauri end result

The biggest upside from all the time wasted compiling was the final executable, the bundle could be as little as ~6mb and the actual executable ~25mb, with some changes to the release profile this could even drop to ~10mb.

And thats all I can really think about.

Wails

I didn't experiment with Wails enough, as it uses Go for the backend, my issues with compilation time would certainly improve as much as using Electron did. The only "issue" there would be is with supporting different browsers like with Tauri as Wails also uses the systems browser.

How are things now?

Better, thanks for asking.

Using scientific methods like trying to remember, the Electron version is using if not the same, possibly even less memory than the Tauri one on Windows.

It starts up faster for me, is a lot better to tinker with, takes less space on my dying SSD and is pretty fast to build installers for Windows, Linux and macOs.

The end

The alternatives to Electron are pretty interesting and in the future, if I decide to use javascript for the frontend, I might just use one of them again depending on the project.

Now, please look forward to the next rewrite in C++.

Changes

• The app now uses Electron and is built using electron-vite and electron-builder.
• Following the above, the 'backend' is now written in Typescript.
• The app for now builds for Windows, macOS and Linux. For now, Linux is only built using deb packages, I am thinking of offering just flatpak.
• Using vanilla Svelte instead of SvelteKit. This might change in the future if SvelteKit offers something for this project that vanilla Svelte doesn't.
• better-sqlite3 is now being used instead of sqlx.
• Youtube.js is now being used instead of RustyPipe.
• A Settings page has been added with options like disabling ad blocking, autoplay, using the embedded player for YouTube, etc.
• Changes to the UI to keep it more consistent.
• For now, videos will by default use the embedded player.
• The new database tables are incompatible with the old ones, you will need to delete the app data folder before starting if you used a version prior to the port.
• Opening a stream using rt:// no longer adds the user.