from Hacker News

Ask HN: Can small teams maintain Electron apps?

by diamondap on 8/15/22, 4:38 PM with 15 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?

  • by yrgulation on 8/15/22, 7:31 PM

    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.

  • by lightwin on 8/15/22, 6:42 PM

    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.

  • by 999900000999 on 8/15/22, 4:47 PM

    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.

  • by atwood22 on 8/15/22, 5:00 PM

    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?

  • by tabtab on 8/15/22, 11:37 PM

    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.

  • by mikece on 8/15/22, 5:08 PM

    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).