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

Re: Tauri: An Electron alternative written in Rust

#311

Post by bscphil » Sat, Feb 20, 2021, 12:16 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.

Is the M1 really not competitive with the latest XPS?

Re: Tauri: An Electron alternative written in Rust

#312

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

Xevi wrote: post #305

brundolf wrote: post #44

Earlier quoted context omitted.

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

Isn't IE just using Chrome now? Or do you mean support for old IE?

Re: Tauri: An Electron alternative written in Rust

#313

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

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.

I feel like this is a monkey's paw wish. I've wanted to see QT and GTK replaced with something better for a long time.

We got Electron, and other browser based toolkits.

Re: Tauri: An Electron alternative written in Rust

#314

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

qbasic_forever wrote: post #139

gameswithgo wrote: post #17

Earlier quoted context omitted.

It isn't your fault that you have to do this, it is that our industry hasn't created enough quality, easy to use, cross platform gui libraries for popular languages, such that the only viable place to turn is to use a whole web browser.

We've had about 60 years and multiple huge attempts at it, and IMHO HTML & CSS _are_ the easy to use cross-platform GUI platform. Nothing else stuck--flash, java swing, qt, etc. were all super capable and promising but failed to gain mass usage. HTML & CSS is the way. Nothing in existence has as much capability, developer usage and talent pool, accessibility and internationalization features, etc. A good GUI system i…

I suppose this depends on your point of view. QT has achieved broad acceptance as "the" cross platform solution among open source Linux-first applications, as well as much of the open source ecosystem more generally. (Open source being what it is means that there are many exceptions, obviously.)

For example, on my computer right now I have 55 applications that depend directly on qt5-base, not including libraries and parts of QT. This is also not including a ton of applications that depend indirectly on QT, including most every KDE desktop application, which depends through KDE's frameworks.

So while QT may not have caught on in commercial software development, I'd say calling it a failure depends very much on what software ecosystem you're in. You might argue that HTML has achieved "universal usage" for desktop apps in a way that QT has not, but I would have to disagree. I don't have a single HTML UI or Electron app on my computer, and I don't feel as though I've given anything up. In fact I simply haven't come across any of these apps that I felt like I needed.

So I might say that HTML has failed to gain mass usage on the platforms that matter to me. :-)

Re: Tauri: An Electron alternative written in Rust

#315

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

gigel82 wrote: post #310

c-smile wrote: post #303

Earlier quoted context omitted.

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.

"how you position it"

Hmm... and how do I do that? What's your impression?

Sciter.JS is "an embeddable HTML/CSS/JS UI engine" and that's it.

Yes, it is possible to use it without touching native side like ElectronJS, see: https://quark.sciter.com/ , but that's not the primary use case. So far it has around 400 mln installations in embedded form as part of other products, see: https://sciter.com/#customers

If you want you can treat it as Flutter that uses time proven and familiar HTML/CSS/JS resource definitions instead of Dart. Dart is close to JS but not JS, Flutter has some DOM but not HTML DOM, it has some style system but quite rudimental one.

Re: Tauri: An Electron alternative written in Rust

#316

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

ianlevesque wrote: post #307

calibas wrote: post #233

Earlier quoted context omitted.

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.

I started getting in the habit of using Typescript with JS. It's annoying at first, but worth it for any decent sized codebase. All the bugs from JavaScript's unexpected type conversions just disappear.

Re: Tauri: An Electron alternative written in Rust

#317

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

mattmanser wrote: post #297

oxymoron wrote: post #292

Earlier quoted context omitted.

In 2008, when IE7 came out, I cried of joy. I turned 22 that year, so the 7 years with only IE6 and Firefox was a significant chunk of my life. Firefox showed us that the web wasn't finished and could still be improved, and then came Firebug which made Firefox first web dev the obvious choice. But the vast majority still used IE6, so there was always a miserable step in the project of fixing all the IE bugs. After do…

I've had to say this a fair few times here, but I'll keep saying it. IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember. So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.

I was young and dogmatic, so I did admittedly despise Microsoft back then. I can't recall I ever heard of IEDevToolbar, though. Did it really feature the DOM tree view where you could do CSS manipulation? I always had the impression that it was a Firebug invention, but I could be wrong about that.

Re: Tauri: An Electron alternative written in Rust

#318

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

Neputys wrote: post #286

eivarv wrote: post #279

Earlier quoted context omitted.

That's not my experience, at least. I haven't had any major issues I wasn't able to solve with either. Even if I were more comfortable with web tech when I first started experimenting with this stuff (some time around 2012-2015) I still found the end result much better.

If you don't go beyond standard interactions and look it's probably fine but let's say I want system chrome to look like the one in photoshop and some custom dropdowns for starters...

Why would your desktop users want your weird drop downs? UI consistency used to be a thing.

Re: Tauri: An Electron alternative written in Rust

#319

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

themihai wrote: post #222

I think a better electron would be an Electron that you can build only with the features you use(i.e I don't use websql, I don't need CORS, web notifications, nfc, bluetooth, hundreds of legacy js and css features, no pdf/print support etc). I'm pretty sure that if you can drop all the stuff you don't use you get better performance/efficiency.

It goes deeper than that. Frickin’ Spotify has a manual toggle for whether or not I want Hardware Acceleration turned on or not. It’s not the only one. I don’t have any way to know which setting doesn’t spin up my laptop fans and burn me. How about just building your app in such a way that I don’t have to manually configure that. We’ve had music players since the 90’s, I don’t see why this is so hard.

Re: Tauri: An Electron alternative written in Rust

#320

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

908B64B197 wrote: post #110

mumblemumble wrote: post #92

Earlier quoted context omitted.

Some corporations did that. Most didn't. The main reason IE dominated was that most people didn't care, and stuck with the default. The main reason old versions of browsers were more common than new ones was that self-updating browsers hadn't become a thing yet, and most people didn't care, and just stuck with the default. The reason most browsers stay up-to-date now is that modern browsers are all configured to self…

> I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default I'm not aware of any Windows machines shipping with Chrome pre-installed. But as soon as you use any website that's owned by Google you get spammed with install links for Chrome.

An entire generation is being raised on Chromebooks. I wish Boot2Gecko and Firefox OS weren’t a bit ahead of themselves and had better ugh marketing.