Live data from Hacker News

Tauri – Electron alternative written in Rust

tauri.studio

331–340 of 435 posts

Re: Tauri – Electron alternative written in Rust

#331
post #65

Earlier quoted context omitted.

> I really don’t care if my hello world UI is 60MB to download lot of people cares, they may have a slow connection, must pay per MB and so on. There is no reason why hello world UI should be 60MB.

Arguably both Slack and Spotify (and Visual Studio?) have reached significant scale with Electron apps - so at the end of the day it seems to be less of an issue for end consumers.

Lots of things are popular, but that doesn't imply quality. McDonald's does not make the best hamburger in the world.

Re: Tauri – Electron alternative written in Rust

#332
post #286

Earlier quoted context omitted.

There's a proxy polyfill. And if you really wanted there's at least one pcre2 wasm build you could wrap to make a polyfill, lol. Barely anyone uses lookahead/lookbehind even in pcre, though.

Proxy polyfill: assuming you are referring to this [0], since I haven't seen anything else like this, then I'll paste here what the readme says: > The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time. i.e. that's not a polyfill for Proxy. It's a polyfill for a subset of…

>Shipping an entire regex engine with your app: right, that's the only way to do something like that.

You mean like shipping an entire 100+ MB browser and rendering engine with your app?

Re: Tauri – Electron alternative written in Rust

#333

Earlier quoted context omitted.

I wasn't even talking about the penalty of writing a Qt application in C++. That's a different penalty. Qt doesn't really compare with what can be done with a good UX/UI dev on the team, and in much less time. And there are far more front-end devs than Qt experts.

> Qt doesn't really compare with what can be done with a good UX/UI dev on the team Those are orthogonal. UI/UX is platform-agnostic - if you're only developing Electron UIs, you're not actually good at UI/UX. > in much less time Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer? > there are far more front-end devs than Qt ex…

> Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer?

Yes. Hands down.

I'm actually saying two things: there are far fewer Qt developers, and the learning curve is much steeper. This has huge impact on maintaining and improving the code. We started with Qt and abandoned it because it is way easier to bring someone new in and get them started than having someone climb the curve to learn Qt and C++. Plus spinning up new features in Qt is laughably slow compared to how quickly a frontend dev can do the same in Electron: the former takes days, the latter is practically interactive.

It was such a clear choice to abandon Qt.

I was primarily worried Electron wouldn't last long, but we wrote our first app with it 6 years ago and it has remained completely stable. The biggest dev hits have been in Node peripheral support as they get better, like BLE and serial port interfaces.

Re: Tauri – Electron alternative written in Rust

#334

Is "written in Rust" a registered trademark already?

they promote "written in Rust" more than the product

that is the only thing i remember of the countless of projects advertised on hackernews, "written in Rust", they still haven't got it, the language is the least important piece of a product

Re: Tauri – Electron alternative written in Rust

#335

If anyone wants to know how it works: > [leverages] WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux. So cross-platform compatibility isn't guaranteed, unlike Electron. https://github.com/tauri-apps/tauri

This is a feature. It means every process doesn't have its own copy of Chrome.

It might mean more testing for developers, but it's a benefit for users.

Re: Tauri – Electron alternative written in Rust

#337
post #65

Earlier quoted context omitted.

> I really don’t care if my hello world UI is 60MB to download lot of people cares, they may have a slow connection, must pay per MB and so on. There is no reason why hello world UI should be 60MB.

I can remember using 56k dialup and downloading ISOs around 650MB. A 60MB download would have been fine. Indeed, with the annoying habit of proprietary software to install "Download managers" that download the actual software, I would be happy for just a 60MB runtime for the actual program itself.

I also remember using 56k dialup, and we paid per minute. A 60 Mb download would take several hours.

Re: Tauri – Electron alternative written in Rust

#338

Earlier quoted context omitted.

Proxy polyfill: assuming you are referring to this [0], since I haven't seen anything else like this, then I'll paste here what the readme says: > The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time. i.e. that's not a polyfill for Proxy. It's a polyfill for a subset of…

> Shipping an entire regex engine with your app: right, that's the only way to do something like that. You mean like shipping an entire 100+ MB browser and rendering engine with your app?

Electron does not weigh 300+ MB for starter, and one means basically statically linking your app so that it ships with its own dependencies and works more consistently, while the other means shipping a language because the one you have to use is not implemented properly by the platform, pretty different things when you look at them. I'll give you though that in both cases you are shipping a big engine with your app, so it kinda sounds like the same thing.

Re: Tauri – Electron alternative written in Rust

#339

Earlier quoted context omitted.

Here's your citation: https://insights.stackoverflow.com/survey/2020#most-loved-dr... Rust is #1 loved language, almost 20 points above the second one.

I can't imagine a better definition of trendy and hyped up than "loved on stack overflow".

I don't do anything because it's trendy and I don't use Stack Overflow, but I have used Rust in a project. Its popularity with me is 100% merit-based. In fact, the project failed only because of management not understanding its value and me being unable to communicate to them why Rust is superior.

The language ultimately chosen for the project ended up being 100% a political contest, and that language was not Rust.

Re: Tauri – Electron alternative written in Rust

#340
post #171

Earlier quoted context omitted.

JS DX always seemed really quite bad whenever I looked. A constantly shifting landscape of frameworks and packages where nothing will stand for long before being eroded away.

let's see - language: ES / Typescript are quite established - CSS: also quite established - Frameworks: there is still a lot of innovation here, but also React / Vue / Angular are quite established. on that latter part I prefer the innovation. Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++)

> Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++)

I can easily imagine that, because that's more or less what we had before Electron. And it was much better, because apps (mostly) looked consistent across the OS, rather than each and every one coming up with its own custom UI theme.

Post reply on HN