The problem with supply chain attacks is specifically related to npm, and not related to JS. npm as an organization needs to be taking more responsibility for the recent attacks and essentially forcing everyone to use more strict security controls when publishing their dependencies.
It runs on a majority of computers and basically all phones. There will be many security issues that get discovered b y virtue of these facts.
What makes you think that "native" apps are any more secure?
It’s maybe a nit-pick, since most JS is run sandboxed, so it’s sort of equivalent. But it was explicitly what GP asked for. Would it be more accurate to say Electron is secure, not JS?
I’d love to try it, but speaking of security, this was the first thing I saw:
sh <(curl https://create.tauri.app/sh)
It's not a problem on pc, but an obsidian vault with thousands of notes can have a laggy startup on mobile, even if you disable plugins.
Users sidestep this issue with quick capture plugins and apps, but I wish there was a native stripped-down version of obsidian.
I'd also be forced to ask... what exactly are you doing with a markdown note-taking application such that performance is a legitimate concern?
But, I mean, maybe you're reading this in a Lynx session on your ThinkPad 701C.
Any two Turing-complete programming languages are equally secure, no?
Surely the security can only ever come from whatever compiles/interprets it? You can run JavaScript on a piece of paper.
Conversely, barring a bug in the runtime or compiler, higher level languages don't enable those kinds of shenanigans.
See for example the heart bleed bug, where openssl would read memory it didn't own when given a properly malformed request.
Language design actually has a lot of impact on security, because it defines what primitives you have available for interacting with the system. Do you have an arbitrary syscall primitive? Then the language is not going to help you write secure software. Is your only ability to interact with the system via capability objects that must be provided externally to authorize your access? Then you're probably using a language that put a lot of thought into security and will help out quite a lot.
Tauri is trustable (for some loose definition) and the pipe to shell is just a well known happy-path.
All that to say it's a low value smell test.
Also, I'm in the camp that would rather git clone and then docker up. My understanding is it gives me a littl more sandbox.
Let's fix private key leakage and supply chain issues before worrying about C++ haxxors p0wning your machines.
To be fair, a plugin system built on JS with all plugins interacting in the same JS context as the main app has some big risks. Anything plugin can change definitions and variable in the global scope with some restrictions. But any language where you execute untrusted code in the same context/memory/etc as trusted code has risks. the only solution is sandboxing plugins