electron-egg: a JavaScript desktop framework built on Electron, with its own CLI and build pipeline

What electron-egg adds on top of plain Electron

Electron gives you a Chromium renderer and a Node.js main process. It does not give you a directory convention, a packaging script set, or a way to split business logic across processes. electron-egg fills that gap. The repository is organised into build/, cmd/, electron/, frontend/ and public/ directories, with package.json declaring main as ./public/electron/main.js. That layout is the product: a place for the frontend, a place for the Electron side, and a place for build configuration.

The README describes the framework as supporting JS, TS, CJS and ESM, and as frontend-independent, so Vue, React or plain HTML can sit in frontend/. The stated audience is broad: the project claims community groups covering frontend, Java, Go, Python and PHP developers. That is a marketing claim about reach, not a technical property, and the README does not quantify it.

The version in package.json is 5.0.0, matching the v5.0.0 release dated 2026-06-21. The last push to the repository was on 2026-09-17, which is recent enough that the project is not dormant.

The ee-bin CLI and the build pipeline

The mechanism is a command-line tool, ee-bin, declared as a devDependency at ^5.0.0, plus a runtime package, ee-core, declared as a dependency at ^5.0.1. Almost every script in package.json shells out to one of them.

Development runs through ee-bin dev. The script list splits it into dev-frontend and dev-electron, each passing --serve=frontend or --serve=electron, so the two halves of the application can be started independently. Production builds chain three steps: build-frontend runs ee-bin build --cmds=frontend and then ee-bin move --flag=frontend_dist, build-electron runs ee-bin build --cmds=electron, and the top-level build script finishes with ee-bin encrypt.

That encrypt step is the interesting one. The README lists bytecode encryption and compression/obfuscation encryption under security. It does not explain the format, the key handling, or what happens to source maps. Treat encryption as a packaging step whose details you will need to confirm from the external documentation site rather than from the repository.

Platform targets are named scripts: build-w for win64, build-we for win_e, build-m for mac_arm64, build-m-x86 for mac, build-m-arm64 for mac_arm64, and build-l for linux. The README also names national UOS, Deepin and Kylin as supported Linux targets. Note that build-m and build-m-arm64 both pass --cmds=mac_arm64, which looks like a duplication worth checking before you rely on build-m for an Intel Mac.

Installing electron-egg and running a first build

The README does not contain installation commands. It links to an external Installation Guide at kaka996.com under Getting Started, and the homepage is the same site. So the steps below come from package.json scripts, not from a documented quick start.

Start by installing dependencies with the package manager of your choice, then run the development task. The dev script is defined as ee-bin dev.

npm install
npm run dev

According to package.json, this invokes ee-bin dev, which should start the Electron application defined by main, ./public/electron/main.js. If you want to run only one side, the split scripts are dev-frontend and dev-electron, which pass --serve=frontend and --serve=electron respectively.

npm run dev-frontend
npm run dev-electron

To produce a Windows 64-bit build, the repository defines build-w as ee-bin build --cmds=win64. The full build script first builds the frontend, moves the distribution, builds the Electron side, and then encrypts.

npm run build-w

If you use better-sqlite3, package.json includes a re-sqlite script that runs electron-rebuild against it, because native modules must be rebuilt against Electron's Node version.

npm run re-sqlite

The README gives no expected console output for any of these commands, so what you see on a successful run is not documented in the repository.

Where the repository is silent

The README is a feature list, not a manual. Several things an adopter needs are simply absent from it.

First, there is no documented rollback or downgrade path. If v5.0.0 breaks your build, the repository does not describe how to return to v4.2.0 or v4.1.0, both of which exist as releases. You would be pinning versions in package.json on your own.

Second, the encryption feature has no threat model in the README. Bytecode encryption and obfuscation are listed as security capabilities, but obfuscation is not the same as protection, and the repository does not say what the encrypted output defends against.

Third, the README claims use in accounting, government, healthcare, education and stock trading, and shows screenshots of named applications. Screenshots are not evidence of correctness or of regulatory suitability, and the README makes no compliance claims either way.

Fourth, the project points to an external site for installation and discussion. That means the repository alone is not a complete source of truth, and the documentation's version could drift from the code you have checked out.

When Electron itself is the better choice

The real alternative is Electron without a framework, and the difference is structural rather than cosmetic.

Plain Electron gives you an application skeleton and nothing else. You choose your own directory layout, write your own build scripts, and decide how the main process and renderer communicate. electron-egg makes those decisions for you: cmd/ and electron/ exist, ee-bin drives the build, and ee-core provides the runtime side. If your application is small, say a single window loading one page, that convention is overhead you will spend time working around rather than benefiting from.

The other comparison the search data suggests is Tauri, which takes a different route: it pairs a system webview with a Rust backend instead of bundling Chromium and Node. That produces smaller binaries and a different security model, at the cost of writing backend logic in Rust. electron-egg keeps everything in JavaScript. If your team already writes JavaScript and you want to reuse that skill, the electron-egg path is shorter; if binary size or memory footprint is your main constraint, the Tauri approach addresses it directly and electron-egg does not.

A third option is a frontend build tool such as electron-vite, which handles bundling and hot reload for Electron but does not prescribe a business-logic layout or ship packaging and encryption scripts.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-17. Releases are spaced: v4.1.0 on 2025-03-05, v4.2.0 on 2025-12-08, and v5.0.0 on 2026-06-21. That is roughly two releases a year, with a major version bump in the most recent one.

The upgrade cost is concentrated in two dependencies: ee-core and ee-bin, both pinned to 5.x in package.json. A major version of the framework likely moves both. Because the README does not document migration between major versions, budget time to read the external documentation before moving a production application from v4 to v5.

On licensing: package.json declares "license": "Apache" and the repository contains a LICENSE file, which the README badge identifies as Apache. Apache-2.0 is a permissive licence that includes an explicit patent grant and requires you to preserve notices. The framework bundles Electron and electron-builder, which carry their own licences, and your packaged application will include Chromium. That combination is what you need to review for your distribution, particularly for the government and healthcare deployments the README mentions. This is a description of the licence files present, not legal advice.

Who electron-egg is actually for

The framework suits a team that already writes JavaScript and has been asked to ship a desktop client. The appeal is concrete: one codebase, named build targets for Windows, macOS and Linux, a documented path to UOS, Deepin and Kylin, and a frontend directory that accepts whatever UI stack you already use.

It suits less well a team that needs to audit every layer. The encryption, the packaging internals and the runtime module system live in ee-bin and ee-core, and the README describes them in one-line bullet points. If your review process requires understanding what a build step does before you ship it, the repository will not answer that on its own.

It also suits less well anyone whose application is essentially a web page in a window. At that size, the framework's conventions cost more than they return, and plain Electron or a bundler plugin is the shorter route.

The honest summary is that electron-egg is a convention layer with a build toolchain, not a runtime you cannot replace. Its value scales with project size.

Editorial conclusion

Adopt electron-egg if you are building a cross platform desktop client in JavaScript and want a packaged project layout with build scripts for Windows, macOS and Linux already wired up. Do not adopt it if your application is a thin wrapper around a single web page, or if you need documentation that covers failure modes in detail; the README points to an external site for installation and does not document rollback anywhere in the repository. Before committing, verify the ee-bin dev command starts on your target platform, confirm the electron-rebuild step works if you plan to use better-sqlite3, and check the Apache-2.0 LICENSE file against your distribution requirements.

Frequently asked questions

Official sources

1. dromara/electron-egg on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases