Ikryanov

I don't think that it's a common thing. There are many alternatives like MoBrowser, Electrobun, Wails. The choice depends on the project requirements.

ClipBook

I've been working with Electron for a while, and one thing that keeps bothering me is how IPC is designed. I mean, it's pretty good if you write a simple "Hello, world!" app, but when you write something more complex with hundreds of IPC calls, it becomes... a real pain.

The problems I bumped into:

1. No single source of truth for the API between renderer and main.

2. Channel names are just strings (easy to break, hard to refactor).

3. No real type safety across process boundaries.

4. I have to manually keep main, preload, and renderer in sync.

5. The errors I can see only at runtime.

I tried to think about a better approach. Something on top of a contract-based model with a single source of truth and code generation.

I wrote my thoughts about how the current design can be improved/fixed (with code examples) here:

https://teamdev.com/mobrowser/blog/what-is-wrong-with-electr...

How do you deal with this in your project?

Do you just live with it or maybe you built something better on top of existing Electron IPC implementation?

The uncompressed macOS app bundle size for Electrobun's `react-tailwind-vite.app` is ~63MB.

The business logic of your app is running in the Main process using Bun runtime. The website you load or the app's frontend is running in a separate sandboxed Renderer process. When I run Electrobun app on macOS, I see that it launches the following processes with the following RAM usage:

- views://mainview (33.7MB) <- your frontend is running here

- react-tailwind-vite-dev Networking (5.4MB)

- react-tail wind-vite-dev Graphics and Media (16.7MB)

- react-tailwind-vite-dev (60.7MB)

A regular Electron app for macOS (DMG) is ~80MB. Electrobun's DMG is ~16MB.

A Tauri app built on CEF (Chromium) is very similar to Electron (which also uses Chromium). The key difference is that Tauri uses Rust for the application’s business logic, whereas Electron uses JavaScript.

In this case I don't know why I should use Tauri instead of Electron.

You could have just write the performance critical part of your Electron app using C++ and native node module and achieve the same performance improvements. You actually did it, but using Rust instead of C++.

Wow… that’s nice to see my customer here. Thanks for your support!

Thank you!

Thank you for the feedback. I hope ClipBook will be useful for you.

Thank you for your feedback. Appreciate that.

Thanks for your feedback. I love the dark mode too.

ClipBook is written using Molybden SDK. It allows building UI using modern web frontend frameworks like React, Vue, Angular and write business logic using C++. In case of ClipBook: UI — React + shadcn/ui, business logic — C++ + Cocoa. I wouldn't say it's a native macOS app. I would call it a hybrid app that combines web and desktop technologies to build cross-platform desktop apps quickly.

This size comes from the SDK I use to build the app — Molybden SDK. It's like Electron, but for C++ developers. This SDK allows me to create UI using React and the business logic using C++.

As for access to the source code — I see that it's very important for lots of people, so I will open the source code on GitHub. It's not a problem at all.

Just checked this scenario on macOS 14.4.1 M3 Max. Works well and copy everything.

Thank you so much!

Maybe I wasn't clear. I was talking about the preview panel. Sometimes I copy content of a source code (*.cpp) file, and I need to quickly look at what I have copied in the preview panel. I have to scroll a lot to look at the source code. In ClipBook I just resize the clipboard history window to see more in the preview panel without scrolling.

It doesn't support images yet. I work mostly with text, so in the first versions I added support of the text content only, but support of images and files on the product roadmap. Will add it later. Thanks for your note. Appreciate that.

I didn't enable support for images. It's on the product roadmap. I would like to add support for files too.

As for quick edits — I do the same trick too. I will add the quick edit functionality. I miss it too.

I'm not planning to add snippets. Alfred and Raycast are really good at this.

Thank you for your feedback. If you have any questions, please let me know.

You can resize the window using mouse. Like any other regular window. I didn't implement the resizing feature using keyboard shortcuts yet.

As for repositioning window, you can drag the window by dragging the panel with the keyboard shortcuts on the left-bottom side of the window.

I think I can add this feature, so you can open the clipboard window on the screen with the currently focused window. I think a screen with the currently focused window should be treated as active. It's because I can keep my mouse cursor on secondary screen and work (type something) inside a window on the primary screen. Or just add both preferences, so you can decide yourself which screen should be treated as active.

I will make it open source. It's not a problem at all. Thank you for your comment.

Last year I answered on SO about the difference between Electron and CEF and which one to chose: https://stackoverflow.com/questions/70620182/whats-the-diffr...

I actually use an Electron-like framework to make ClipBook, but it's not Electron and not CEF. It's Electron for C++ developers. It's called Molybden SDK. I'm one of the creators of this SDK. I decided to use it, because I know it really well and it allows me to write using C++ and closely work with the operating system. It's very important when you build a software like ClipBook.

There are three downloads: for Mac Apple Silicon, Intel, and Universal.

You see the 600MB binary, because it's probably Universal (Apple Silicon + Intel) DMG. To have a smaller size it's better to download DMG for your Mac CPU architecture. You can find all three versions at https://clipbook.app/download/

I should say that even Apple Silicon or Intel app will still be ~330MB. It's because of the SDK I use to build this app.