Ask HN: Can small teams maintain Electron apps? | Hacker News Reader

Ask HN: Can small teams maintain Electron apps?

9 pointsdiamondap15 comments

We're a small dev team maintaining a niche Electron app that has about three dozen direct dependencies and hundreds of indirect dependencies. Dependabot warns us weekly about vulnerable Node modules, while Electron has frequent major releases, sometimes with breaking changes that have a major impact.

We have to update dependencies in this codebase much more frequently than in our Ruby and Go codebases. The result is a huge time suck, especially when we run into breaking changes and poor documentation (which is often).

Do other small teams feel this pain? Do large teams have staff dedicated to keeping Node/Electron dependencies up to date?

View on HN

Yes. I do it for a client. The app is used on a daily basis by a small number of users, but for a somewhat high volume of data and generates them quite a bit of revenue. To me it sounds like your issues are related to libraries. I aimed for the most stable and where that wasn't an option i wrote alternatives - i actually understand js and i am comfortable replacing most libs with my own code. Obviously it depends on context but generally speaking electron devs, as js devs, have the habit of bringing in thousands of dependencies for every little thing and then wonder why things are slow, un maintainable and full of security issues. If all you need from a lib is a function then implement it yourself. Also dont cargo cult chrome updates - some may be totally irrelevant to your specific use case.

Yes, the Electron app has a huge number of dependencies, many more than our Go apps, which actually implement more features. On subsequent JS projects (after this Electron experience), I've become extremely strict about dependencies. Like you, I tend to write the functions I need rather than importing packages that bloat the codebase and make the app hard to debug.

As other comments also mentioned, maintaining an Electron app is not much different than any other JavaScript application.

My team used to work on large electron & non-electron apps. We used to have a tech-debt ticket every couple of sprints to review and update various packages in order to take care of any potential vulnerabilities.

Most of time updating packages is as simple as running "npm audit fix" command. But sometime we had to manually update major versions of some of the packages and while doing so, we had to take care of any potential breaking changes.

Having a good set of automated regression tests really helps with the process.

> We used to have a tech-debt ticket every couple of sprints to review and update various packages in order to take care of any potential vulnerabilities.

We should probably start doing that.

We have a pretty thorough set of tests, so we do catch breaking changes from Dependabot in the CI pipeline.

i.e Javascript applications in general have poor maintainability.

That is simply the price of Electron. You trade API stability and application maintainability for cross platform and cheaper developers/web tech.

No one makes you do that, you can build it from scratch natively for each platform.

It's been well known for a long time that anything with JavaScript will be quicker to create right now, but there are significant downsides later on.

I'm actually weighing the cost of doing just that. For our particular use case, it may be the better option.

Do you have an examples of things you've felt compelled to update? Electron does have a lot of reported vulnerabilities, but are you sure those vulnerabilities actually impact your product? Usually properly sandboxing and isolating main / render contexts goes a long way in preventing those vulnerabilities from being exploited. One approach may be to attempt to triage the vulnerable dependencies rather than update them immediately?

Yes, we switched to triaging after a while. Still, there are times when we're forced to update, such as when Electron stopped accepting Let's Encrypt SSL certs, breaking a key feature.

I do think I'm going to move on to another technology with lower maintenance costs.

What's really needed is an open state-ful GUI markup standard so we don't have to reinvent GUI OS's using JavaScript + DOM. It's bad industry-wide tool factoring. Focus on making the GUI browser (pluggin?) do just ONE thing and do it well: GUI's. Don't try to be a full virtual OS like Java applets and Flash tried; they bit off more than they could chew.

It would be nice if Microsoft would enable a type of language server scheme, like they use for VS Code, to allow Electron apps to use any backside language rather than depending on Node. Would be handy to have a cross-platform app where the UI is HTML/CSS/JS but the core logic was in Go or Ruby or C# or (insert language here).

There are alternatives that might work to such an effect.

Tauri comes to mind: frontend using html/css/js but backend is in Rust.

Then there is Blazor: C# in the browser. With Blazorserver, you could actually do both core logic and ui with Dotnet. Stick a webview or minimal electron app in front of it (something like Tauri backend might work too now that I think about it) and you could theoretically fake a native experience while in truth you are actually calling an url: just like electron kinda does. Early cross platform phone app frameworks (Ionic) did this exact thing.

If most the common GUI idioms are built into a good GUI standard (see below), then it wouldn't need tons of client-side coding, and thus JS would probably suffice for lite-duty stuff.

There are some technologies like this. I'm going to look into Wails: https://github.com/wailsapp/wails

Electron.net gives you just that. All the backend logic is in C#.

It's not the most well maintained project, but once you have it up and running for a new project it's stable.

Reply on news.ycombinator.com