Programmer here, was working on self-redistributing OS and encountered a similar problem to yours on verification. You can't provide a guaranteed 100% non-comped program, all you can do is make it so it's extremely unlikely (don't let perfect be the enemy of good).
MD5 hash has been broken for years and data can be manipulated in transit or in standing. JavaScript payload is sent plaintext and can be intercepted (see 'problems with encryption in JavaScript' - you can't send a reliable JavaScript program without the reliable program having a reliable means of transport).
Electron is a Chrome spin-off and I'd advise away from 'Bridge' technologies.
It's unclear if you're after a standalone app or a webhosted app, so I'll attempt to bridge both. Webhosted is nearly impossible to give any real assurances of non-comped status (you or host can be compromised, can be hijacked on site, etc).
Standalone requires a webhost, so it hits the same issue.
So, tips:
1) Keep the app small. Smaller it is, the easier it is to do a byte-by-byte comparison. A 20MB app would be mere seconds, 800mb is going to be a pain.
2) Use anything stronger than MD5 for a hash. Avoid anything with the NSA's rubberstamp of approval (that means no SHA256 etc).
3) Supply more than one type of hash of the software.
4) Make sure you have an alternative source that keeps a copy of the current hash(es) [EG an archive page] so even if main website is comped, archive isn't.
5) Utilise multiple webhosts for hosting the main package itself (why? To compromise the software all hosts have to be hijacked). You can include free software hosts etc into this mix. Don't touch Mega because Kim Dotcom no longer owns it (NZ government gave it to a Chinese investor).
6) Include a copy of the hashes in a text file which is shared with the software package.
7) Use a 'read only' storage format (EG squashfs or an encrypted archive). In order to tamper with it, you'd need to replace the entire file.
8) Supply the individual with the means to build their own from scratch. So if the binaries are comped, it's possible to recreate a non-comped binary from source.
9) Archive copies of the source code.
10) Only push out major releases (so you're not overwhelmed with the archiving/hashes/mirroring).
Essentially to avoid software compromise, you need many alternative copies and many checks/balances. As for yourself being compromised, you need someone who acts as your watch guardian (they don't have control over the project, but they do have the power to say if you're compromised).
Having warrant canaries and a specific coded signal that you can mention that the community will know to mean you're compromised will also help.
If you sell out and none of the checks succeed, then the open source code or binaries would be analysed or decompiled by a white hat eventually and you'd become exposed anyway if that was the case.
But the most compromised product of all is the one you don't even produce. ; )