Electron

Developers often fail to update the Electron base regularly enough, leaving apps vulnerable to security flaws. Electron uses Chromium which requires constant patching like any web browser, but apps ship with outdated versions.

Electron's NodeJS integration allows web pages running inside the framework to access system capabilities, creating serious security vulnerabilities if not properly configured. Context Isolation mitigates this but requires careful implementation by developers.

Electron apps don't integrate well with operating systems because they're essentially web browsers displaying local content. When Electron doesn't support specific OS features, apps using it also won't—for example, Discord lacks screen sharing on Wayland and doesn't support file portals on Flatpak.

The Remote module uses synchronous messaging between renderer and main processes, causing the renderer to block while waiting for responses. Frequent calls (e.g., in click or scroll callbacks) significantly degrade performance.

Building Electron apps for true cross-platform support means accepting compromises on native look-and-feel for all platforms. Native development requires 3x the effort (separate UI development for macOS, Windows, Linux), making Electron the only pragmatic choice for solo developers or small teams despite its limitations.

Electron apps bundle most of Chromium's codebase, making even basic Hello World applications ~100MB and real-world apps like Discord over 700MB. This excessive resource usage creates performance problems on systems with limited RAM.

Node modules loaded at startup remain in memory and cannot be easily unloaded, causing cumulative memory bloat. Libraries loaded once are permanently resident, forcing developers to implement complex hacks to remove them from memory.

Electron updates frequently, introducing breaking changes that disrupt existing functionality. Many apps bundle multiple Electron versions or fall behind on updates, forcing developers to juggle compatibility issues and regularly refactor code to maintain stability.

Native modules require rebuilding after each Electron upgrade, causing integration friction and blocking updates. Without proper rebuilding, apps fail to run or crash.

Electron apps exhibit quirky behavior and performance issues on macOS, particularly with heavy applications or when Apple changes system APIs, leading to instability and requiring additional maintenance effort.

When developers discontinue support for older Electron versions, entire user groups lose access to apps. For example, Electron dropped 32-bit system support, making all Electron apps unusable on older computers despite the web version working perfectly.

Electron makes it too easy for developers to skip optimization work. Most teams ship the default configuration without profiling memory usage or optimizing performance, leading to bloated apps. Only exceptions like VS Code invest in serious optimization.

Electron apps experience performance degradation from excessive DOM elements or animations. Overuse of animations increases CPU usage and makes apps feel sluggish, requiring developers to carefully optimize rendering strategies.

Electron applications consume significant power due to continuous background processes including the Chromium engine, leading to rapid battery depletion on laptops and mobile devices, causing user frustration and driving adoption of more efficient alternatives.

Some teams ship Electron apps as live web applications instead of self-contained binaries, resulting in slower load times, app brittleness, security risks, and poor offline functionality.

Windows Defender and third-party antivirus software frequently flag Electron apps as suspicious during development and production, requiring temporary disabling for testing or code signing certificates to avoid false positives.

Each Electron window runs as a separate process with no easy way to share data between them. IPC implementation and broadcastChannel API have limitations like non-shared memory and inability to pass non-standard data types.

Developers must bundle Chromium to control stability, security, and reliability independently from OS WebViews that are tightly coupled to the operating system. However, this creates a tension between bundling bloat and maintaining control over platform stability.

While Electron provides true cross-platform consistency by bundling Chromium, alternatives like Tauri rely on system WebViews that vary significantly across OS versions (particularly problematic on Linux), creating debugging challenges. Tauri's approach yields much smaller binaries (10-20MB vs 50-90MB).

On macOS and Windows, app store review processes can take days, preventing developers from deploying critical bug fixes and security patches immediately when they're ready, unlike on Linux platforms.

While Electron promises to use familiar web technologies, developers unfamiliar with its specific nuances face a steep learning curve, particularly in debugging and managing application environments. Mismanaged expectations and need for continuous education can extend project timelines.

Users experience noticeable input lag when typing and general sluggishness in Electron apps due to the overhead of running Chromium and multiple processes. This affects user experience even for simple interactions like text input.

Electron suffers from a persistent negative reputation for poor performance that persists even as the platform has matured. This echo-chamber effect causes community backlash whenever new Electron apps are announced, regardless of actual performance quality.