Tauri: An Electron alternative written in Rust • Hacker News Board

Re: Tauri: An Electron alternative written in Rust

#301

Post by Tijdreiziger » Fri, Feb 19, 2021, 11:57 PM UTC

brundolf wrote: post #44

the_duke wrote: post #29

Earlier quoted context omitted.

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…

> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web stand…

Anecdotally I wrote some JavaScript just today (I'm not a frontend dev but I write some simple stuff for fun sometimes). It seemed to me that every modern feature you'd care about is now widely supported. I used the JS fetch API and template strings and these things just work in modern browsers. I even encoded my web fonts in WOFF2 only, because it's so widely supported that I didn't see the point in bothering with WOFF1 too.

Re: Tauri: An Electron alternative written in Rust

#302

Post by elonvolo » Fri, Feb 19, 2021, 11:58 PM UTC

themihai wrote: post #208

brundolf wrote: post #12

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…

>> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. I believe there are dozens of projects using Webview and market themselves as a lightweight "Electron". The development for these apps takes longer (as you need to test for different webview versions/vendors) and the end product is worse as some features are shimmed or you just choose to no…

The dirty little secret is that a software project with two different native codebases is often cheaper, with a faster time-to-market, than a cross platform browser-tech based solution that had just one codebase.

The BS of the browser tech world compounded over time and a million edge cases eventually eats up all the one-codebase, cross-platform savings.

Re: Tauri: An Electron alternative written in Rust

#303

Post by c-smile » Sat, Feb 20, 2021, 12:00 AM UTC

gigel82 wrote: post #296

c-smile wrote: post #283

Earlier quoted context omitted.

"is this impossible?" Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk 10 times more compact than Tauri, 20 times less than Electron.JS Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter ), that if someone need "Made with Rust" label :) And it works even on Windows 2000, do you remember that thing? See: https://sciter.com/necromancing-sciter-on-windows-2000/

I like Sciter for the possibilities, but it needs better compatibility with web standards. Being able to port an existing application that uses React -for example- and have it just run would be the cat's meow. Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.

It depends on what application you have in mind.

React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers.

For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ;

MithrilJS ( https://mithril.js.org/ ) works as it is also.

SvelteJS works as it is with Sciter.JS too.

Also Sciter.JS has its own native implementation of JSX ( it's built in JS core of Sciter.JS) and also DOM extended by native element.patch(vdom) that makes "reactivity" to work in Sciter.JS with native speed.

Yet quite a lot of UI components are natively built-in. For example:

https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/

Re: Tauri: An Electron alternative written in Rust

#304

Post by pitay » Sat, Feb 20, 2021, 12:01 AM UTC

babypuncher wrote: post #113

ASalazarMX wrote: post #98

Earlier quoted context omitted.

> A major benefit of Electron is that you can develop against a single browser version and don't have to deal with all the small but time consuming compatibility quirks. Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.

I think they're overstating the browser compatibility problem too. It was really bad 15 years ago, but today it is almost a non-issue. Between significantly improved standardization of web technologies, and new tricks like polyfills, I think it has become pretty uncommon for apps to not just work on multiple browsers without any tinkering.

At least with writing uncomplicated web applications it was still quite easy to have it compatible with the major browsers, you just had to test the web application with them as you wrote it to make sure. Compatibility problems didn't even come up very much while building it if you stayed reasonably within the boundaries of standards that were well entrenched. The biggest issue was how little CSS IE6 supported, if you did anything fancy with CSS and it didn't work with IE6 you had to include an IE6 specific hack, fortunately that was easy and worked completely fine with other browsers.

There were problems with internal off the shelf applications whose user interface was built for IE6 only. The funny thing is those applications still worked well with the Firefox of the time, but IE9 broke compatibility with them and the applications didn't work on IE9, but IE10 got released and was compatible with them again.

Re: Tauri: An Electron alternative written in Rust

#305

Post by Xevi » Sat, Feb 20, 2021, 12:02 AM UTC

brundolf wrote: post #44

the_duke wrote: post #29

Earlier quoted context omitted.

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…

> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web stand…

Tauri also uses MSHTML (Internet Explorer) on Windows. And there's no way I'm going back to developing for that.

Re: Tauri: An Electron alternative written in Rust

#306

Post by jlokier » Sat, Feb 20, 2021, 12:02 AM UTC

hctaw wrote: post #212

jlokier wrote: post #190

Earlier quoted context omitted.

My Mac isn't an M1, but it does only have 16GB of RAM. Yes, it goes into swap when Safari grows like that. It's mostly ok even with several GB of swap used, but can slow down. My solution is to restart Safari when it gets too bad, as it's obviously leaky. For a long time I used Firefox, was annoyed at how slow it would get on a busy browsing day, and didn't realise the memory consumption of Safari (also open) was ove…

I was going to comment this elsewhere, but workstation class problems require workstation class solutions. If 16GB isn't sufficient for your work you should upgrade. Unfortunately Apple has stopped making competitive workstation laptops. As an example, the new MacBooks are not very competitive (for performance) with the latest XPS series from Dell.

Unfortunately, The XPS would be useless for that part of my workstation class problems that target the Apple ecosystem.

Like almost everyone, I'm financially constrained as well as space constrained. so buying multiple expensive machines, or a high end Mac Pro or something is not on the table as an option.

So it's a compromise.

My compromise at the moment is to use a MBP for Apple things, do smaller Linux and Windows things in a VM on it, and do big Linux and Windows things on cost-optimised rented servers much more powerful than the XPS from Dell. That seems to be a better use of the resources I have for the workstation class problems I'm choosing to solve.

An additional target of my interests is the M1-class processor with it's ARM plus extensions architecture.

So I will wait and see what the next high end, ARM-based MBP from Apple is like. By all accounts the M1 is an excellent and powerful processor, competitive with other Intel-based laptops, so its successor may be a good match for my needs. It might not be, in which case I will need to revisit my strategy, but until it's announced we don't know, and it doesn't make sense to buy an XPS at the moment for what might be just a few months of only marginal discomfort. I have my servers after all.

Re: Tauri: An Electron alternative written in Rust

#307

Post by ianlevesque » Sat, Feb 20, 2021, 12:03 AM UTC

calibas wrote: post #233

yannoninator wrote: post #196

I think the desktop seriously needs a production, RAM and developer friendly breakthrough that isn't Electron. Tauri may be it, but the desktop SO needs this moment, I don't want to see 50 years on and Electron is still being used.

There's React Native for Windows/macOS, though if you don't like Electron I doubt that's very appealing either. I've had some nice experiences using PyInstaller to create desktop apps.

React Native is fantastic as a user on macOS and Windows. Personally I think if there’s any hope of winning the Electron crowd over that’s it. I like to develop with stronger typed languages than JS, but there's clearly demand given electron’s popularity.

Re: Tauri: An Electron alternative written in Rust

#308

Post by sodality2 » Sat, Feb 20, 2021, 12:10 AM UTC

efwfwef wrote: post #184

Klonoar wrote: post #149

Earlier quoted context omitted.

This sounds like you didn't look up and read the comment in question. Problems with cross-platform webviews stopped being the HTML/CSS/JS layer long ago; it's integration, availability, and rate-of-updates that are common blockers. Call me when Microsoft actually ships WebView2 with the OS.

if you would link to that comment it would be helpful

https://news.ycombinator.com/item?id=18763449

"This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.

* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.

* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."

* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host. "

Re: Tauri: An Electron alternative written in Rust

#309

Post by jlokier » Sat, Feb 20, 2021, 12:12 AM UTC

dcow wrote: post #289

jlokier wrote: post #109

Earlier quoted context omitted.

I run three browsers on my desktop, because the number of things that don't work properly in anything except recent Chrome is enough that I keep encountering issues, I don't want to use Chrome for my regular browsing, and both Safari and Firefox have issues on some sites. On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome.…

Running tabs in a separate process has been a boon IMO. It’s better security and a crashed tab doesn't bring the browser down and an unresponsive tab can be killed independently.

I agree, however that is part of the argument for why Electron RAM usage should be compared against browser tabs, instead of assuming that Electron must be using a lot more ust on principle because it's separate.

Re: Tauri: An Electron alternative written in Rust

#310

Post by gigel82 » Sat, Feb 20, 2021, 12:15 AM UTC

c-smile wrote: post #303

gigel82 wrote: post #296

Earlier quoted context omitted.

I like Sciter for the possibilities, but it needs better compatibility with web standards. Being able to port an existing application that uses React -for example- and have it just run would be the cat's meow. Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.

It depends on what application you have in mind. React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers. For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ; MithrilJS ( https://mithril.js.org/ ) works as it is also. SvelteJS works as it is with Sciter.JS too. Also S…

I think the project is great and I admire your work, but I'm confused about how you position it.

Being "almost" web compatible is not a recipe for success, as it's bound to cause confusion and frustration among folks that want it to be an Electron alternative.

Either embrace Web APIs entirely (perhaps a smaller compatible subset), or just position it as something else entirely, like Flutter.