HN user

nim2020

65 karma
Posts0
Comments23
View on HN
No posts found.

Hi Schickling.

Denjell here from the founding team of Tauri. Thanks for reaching out directly, and I just wanted to state for the HN record, that we are going to be having a board discussion surrounding the unpleasant event raised here, and will make a public statement very soon.

That said, on a personal note, I am quite sorry this happened. We do support and uphold our Code of Conduct, and this is not an appropriate response and the community tone we want to nurture.

I find it interesting that many people hold so tightly onto the "it is not native unless it is written entirely in %my_favorite_language%". I think a little controversy is good, but what the heck does native mean anymore? Wasn't it really invented as a kind of "shaming" because front-end developers were never considered "real programmers" and when hybrid apps came out some folks felt the need to line their pockets with this differentiation?

Don't get me wrong, I am very well acquainted with the tragedies of JS - and the propensity of amateurs to just "do it all" in a single-threaded webrenderer. In fact, I think that this is why most of the first and second generation "web-apps" built on cordova and electron were such poor performers.

But nevertheless, what we are trying to do with Tauri is to open up the boundaries between development communities and leverage the particular strengths of each of them. So if you don't feel Tauri is "native" enough, then maybe you are missing the point.

A local tauri binary that is optimally secured:

- all assets are baked into the binary, not an ASAR or some kind of sidecar

- uses minimal javascript obfuscation

- disables console availability in the webview

- detects if it has been invoked from command line and exits

- uses a minimal CSP to prevent the webview from reaching out to unknown resources

- uses an API acceptlist, to treeshake out any unneeded functionality

- injects the code directly into the webview from rust, circumventing the need for a localhost server

- communicates with the event API, which uses randomized handles for all events to prevent static attacks from knowing in advance what a function call will be

- never relies on external resources like remote servers / CDNs

- removes all println! macros from consumer side rust

- uses the forthcoming signed updater system

- has been audited with frida-trace on delegate platforms

- probably a couple more I am forgetting

Tauri builds the entire backend for you, all APIs are available out of the box without composing a single line of rust. If you do know rust, however, you can extend at your leisure.

The team is currently working on a very slim solution that will build your entire project using a deno-based binary and if you stick to the APIs and can stomach the security risk of JS sidecars, you won't even need to have rust installed. That is probably a month or two away...

Hi - core dev from Tauri here.

A new rendering engine is indeed one of the areas of the research at tauri. For now (and until 1.0 at least) we are sticking with the webview, because we want to have an alternative to electron that is safer and is well-known enough to be stable across platforms for the foreseeable future.

Regarding what an a new engine would have to provide, as a matter of fact, Tauri does offer cross-platform APIs for the filesystem, notifications, CLI, etc. These are all rust based, and available from JS.

I do have to disagree though, in one point, and that is that your single threading comment is only true in the webview. Technically, you have the entire strength of the underlying OS available to you from rust, and that is indeed where I recommend devs do all their heavy lifting. This is one of the benefits of using a polyglot system and an inherent security benefit.