It's not text-to-speech, it's the video (and voice) of a Youtuber (Fireship) that makes a lot of "in 100 Seconds" videos about all kinds of frameworks/programming languages/etc.
Like a lot of newer video content creators, this author has perfected their ability to speak exactly like a speech to text synth does: The same inflection over sentences, no human variability between lines, a lot of post-processing.
I am the same way, but I've noticed folks 10-15 years younger than me don't mind it at all. Perhaps it's just some weird internet culture thing that I'm too crusty to understand :)
Maybe tiktok TTS is now the standard for vocal communication :( . If I ever hear "the young people" talking like this to each other when I'm out shopping I think I will retire and just move off the grid.
I find it surprisingly hard to judge, because the edit style is so obnoxious and poorly executed. I think it’s done by a human, but the speech and editing are both sufficiently lousy that I’m not confident from this video alone—though another couple of videos I tried were definitely somewhat better. The aggressive cutting style is just bad editing, and the speaker has spoken each phrase independently with no attempt to bridge them (which a competent speaker would do). The first ten seconds are particularly grating, with thoroughly unnatural emphasis on the start of most syllables, almost as though each word or even syllable had been spoken independently and then glued together (e.g. And, A, Light, Weight, Rust, Back, End). The prosody is also regularly quite a bit off, and it’s hard to determine if that’s related to the bad editing and speech segmentation, or an independent issue. There’s enough that feels natural in things like intonation that I don’t think it’s TTS, but it’s also making a lot of the sorts of errors that even the best TTS engines habitually make.
I get the impression that it’s a human who doesn’t know how to speak or edit particularly well but normally gets away with it not being too bad (as I say, other videos seem to be better, though they still suffer from the aggressive cut style), but compromised harshly on quality in this case in order to squish more into the hundred seconds… and still ended up 50% over time.
I guess that happens when you try to fit everything in 100 seconds.
Also, it will become almost literally impossible to hear the difference in the near future, so I personally wouldn't keep assuming it's one or the other.
> I guess that happens when you try to fit everything in 100 seconds.
What, you overshoot by 50%? :-) But more seriously, the job that has been done is simply low-quality, even disregarding the choppy edit style—probably a mixture of shoddy work (from comparing it with some of the others), and the creator not being capable of better as regards the speech—most aren’t particularly aware of how to improve. Much better is readily possible.
> Also, it will become almost literally impossible to hear the difference in the near future
I am an excellent reader, highly regarded for my diction and prosody and for conveying the sense of a matter. So far, I haven’t heard a TTS demo, hand-picked or otherwise, that would stand a chance against a skilled reader: the veriest dunce would savvy which was which within a couple of sentences. (And at least a couple of the demos were deliberately trying to address these sorts of shortcomings in inflection and such.) Certainly they’ve reached the stage where you often can’t reliably identify the computer versus the mediocre reader (and there are an awful lot of them), but I don’t think we’ll see computers beating skilled readers and speakers any time soon, when I consider how poor a job AI is still doing on coherent longform writing, and then add the degrees of nuance and information conveyed in speech. (Supplant them? Sure. But you don’t have to be better than something to supplant it, just cheaper, or some such thing. My favourite example of this is book binding where hot melt glue is vastly inferior to cold glue, but it’s much faster and thus cheaper to produce with, and it’s good enough that you’ll struggle to find cold glue ever used in production now.)
Tauri is such a breath of fresh air for a web developer like me! I picked up Rust because of it, and was easier than I thought (I've read lots of "Rust is hard" articles).
The application I wrote is a Hacker News client with focus on offline reading and listing comments in threads sorted by time and flat, instead of trees sorted by score (which incidentally, also works as a web application which is deployed here: https://ditzes.com/).
I found it helpful when I'm traveling but still want to read discussions, useful for following along threads that are actively being discussed (this submission can be seen at https://ditzes.com/item/31764015 for example) and also useful when using HN comments as reference to something I'm building. Guess I'm also pretty proud that the client is VERY fast, loading 1000 comments in something like 1s (because of the caching). Like this thread for the Coinbase layoffs: https://ditzes.com/item/31742590 (1001 comments)
The Tauri application currently works with 99% of the features of Ditzes, but the mouse "back" button doesn't actually navigate the internal browser back in history with Tauri yet, so I haven't done a "Show HN" yet as I consider that a essential feature of Ditzes (for following along threads via the "View" link) before "launching" it.
Overall, besides the extremely long compile times, Tauri has a been a pleasure to develop with, and I'd definitively use it over Electron in the future. Really looking forward to mobile support as well, as then I'll finally have a comfortable and offline-capable HN client for my cellphone.
Both :) But what bothers me most, is the slow incremental debug builds. But that's a general Rust problem, although seems extra bad with Tauri.
My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies and changing one line in main.rs takes about ~20 seconds for the debug compile to finish (on a 5950X CPU). Fresh build takes about 1m30s but that only happens on CI, so not really a problem day-to-day for me. Full CI build on Codeberg/Woodpecker takes around 5 minutes from push to release created, but that's including other things too.
I wonder if there are any plans to buttress this issue with Rust. Last time I checked the issue was that there is/was no ABI stability which meant you couldn't have precompiled libraries to build against. The only way around it at the time was to expose C compatible APIs, but that means of course giving up much of Rust's strengths.
> [...] My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies [...]
I have no experience with Rust. Having 0.4 dependencies per line (so every 3 lines you are dependent on a 3rd-party) sounds very extreme. Can you elaborate a bit what those dependencies are (like many std libs?)?
That will be including transitive dependencies. Consider how many dependencies making a HTTP request will pull in. Ones for network IO, ones for parsing HTTP request. Possibly separate ones for HTTP1, HTTP2, HTTP3. Ones for type definitions of HTTP requests. Rust convention is to publish these bits as separate crates even if they are published by the same maintainer(s) so as to improve compile times (separate crates can be compiled in parallel) and modularity (if you're writing a competing library then you can share the internals of the existing implementation when possible).
This isn't like C++ where a single dependency is a huge project. Some crates are literally just trait (interface) definitions.
Thanks a lot for taking a look at the dependencies! I'm gonna be honest and say that I haven't spent much time "optimizing" anything, I haven't even arrived at a "first" version yet with Ditzes. But with that said, you have some good points :)
> How come you pull in both isahc and reqwest? On the surface, don't they fill the same role? Similar for rustls and openssl.
Yes indeed. I started with using reqwest, but it's no longer used and only isahc is used, so reqwest can be removed from the list.
Same with openssl/rustls. Started with rustls, but not longer used, so can also be removed.
Simply forgot to remove them at one point I guess.
> If you upgrade your readability dependency, you will only pull in reqwest once instead of twice. Might be useful to run `cargo tree -d`.
Ah, that's good to know. I'll do that once I put in some other changes, thanks!
> I'm not familiar with savefile? What does that get you over serde_json which you also pull in?
Rust savefile persists structs as binary data on disk, and also have versioning. Started out persisting everything as JSON, but loading thousands of posts (or even hundreds) from disk and deserializing them from JSON turned out to be quite slow. So using savefile mainly for performance, but I like the versioning/migration aspect of it as well, although I haven't used it yet with Ditzes.
serde_json is mainly used to parse responses from the HN API and to output JSON from the HTTP API, if I recall correctly.
Indeed. Here I took a random sample from https://github.com/topics/rust and listed the amount of dependencies from running `cargo tree` (full command: `cargo tree | awk 'NF' | wc -l`)
- denoland/deno (nodejs-like runtime) - 1550
- alacritty/alacritty (Terminal) - 303
- sharkdp/bat (`cat` clone) - 249
- meilisearch/meilisearch (search engine) - 1128
- starship/starship (command line prompt) - 427
- swc-project/swc (JS/TS compiler) - 1869
- AppFlowy-IO/AppFlowy (Notion clone) - 1146
- yewstack/yew (Rust/WASM web framework) - 942
- rustdesk/rustdesk (remote desktop) - 648
- nushell/nushell (shell) - 858
- ogham/exa (`ls` alternative) - 61
So yeah, seems even things as basic as a `cat` replacement ends up with 249 dependencies. Lowest amount of dependencies is a `ls` alternative, which ends up with 62 dependencies.
cargo tree | wc -l tends to over-count dependencies a lot because there are many very common crates.
Use grep package -F '[['package Cargo.lock | wc -l instead. This is doubly true if you pull in multiple crates using the same framework behind it, e.g. in async projects. E.g. for exa this is 45 instead of 61. For deno this turns into a 3x difference (515 vs. 1571).
Other reasons, besides what has been mentioned (vendoring being very uncommon, crates existing for common type and trait definitions, crates being generally scoped more narrowly resulting in more smaller crates), a lot of crates have additional crates for macros. Bindings often end up being a whole bunch of crates for this reason (i.e. one xyz-sys crate for the FFI bindings, plus one or more crates for a rusty wrapper and perhaps one or more crates for convenience crates). Case in point from deno's dependency tree:
Deps are a transitive tree. The number of deps for enduser code for a framework like this will always be high. That is kinda the point. A small amount of end user code uses the work of thousands.
I recently developed a similarly sized APP with tauri + rust (3kLOC+~250 deps) and found that using mold[0] as a linker helped quite a bit for incremental builds. There were also a few other bits, like decoupling the build step in tauri from the frontend build, that helped.
Yeah, separating things is what I ended up doing as well. Ditzes is currently four parts: API, CLI, frontend (CLJS though) and desktop application. Most of the time when developing, only the API/CLI/frontend changes, while I just do desktop builds to check it from time to time.
What do people compare with when they complain about 20 second build times? That doesn't seem like anything for a thing that one doesn't need to do very often. You can still do cargo check without taking so much time, right?
`cargo check` is what my editor runs automatically to find type errors, that runs automatically on every save. It doesn't allow me to actually "check" that the application does what I want it to. I run `cargo run/build` when I need to "humanly" test the application, and waiting 20 seconds for it is pretty bad.
But then I come from a dynamic application development background (mostly Clojure), so maybe I do have a pretty unfair view on how fast I should be able to make a change and see the effects (sub second is the usual wait time in Clojure land).
Incremental builds are unlikely to benefit from multiple cores. I have a 5900x Desktop and recently bought a Laptop with 12700H. For some incremental builds, I'm getting the same performance. The Desktop Ryzen shines with full multiple builds (where the laptop gets hot and has to sabotage itself); or with running multiple programs without noticeable performance impact.
I haven't tried mold. I already face lots of difficulties with the current linker since I need to deploy to multiple architectures, so I can't imagine how that would be with Mold (but then maybe that's why I should try it!)
Sure thing. Compiled mold from source and got the following numbers when compiling Ditzes:
- Debug build from scratch: ~1m 20s
- Incremental debug build: ~3s
- Release build from scratch: ~3m 40s
So, seems that helped quite a bit, thanks for the tip :)
As someone who is generally unaware of things as I'm new to Rust, is there any drawbacks to using a non-default linker? Everything seems to work fine as far as I can tell, but no drawbacks mentioned in the repository of Meld makes me slightly skeptical.
- It's still somewhat experimental. It may not be able to link everything. There may be bugs.
Having said that, it's written by someone with a lot of experience writing linkers (they previously worked on lld), can link codebases as complex as chromium, and generally seems to work well for most use cases.
A common pattern would be to use mold for development, and then the regular linker (varies by platform) for release builds.
If it's for the future, why not use something even newer than Deno, because clearly newer === better?
But on a more serious note, what could they possibly stand to gain to use Deno instead of NodeJS at this point? The languages are mostly the same, the tooling slightly different. Sounds like it'd add a lot of changes just for the sake of changing things. Not to mention newer stuff usually are less tested and higher chance of not working.
Speaking about newer, has Deno received any sort of security audits? Tauri is pretty focused on security, so one could assume that'd be a requirement before even considering Deno.
Which you don't even have to use. I don't. I just use `cargo build` and `cargo build --release` which works exactly the same way as the CLI. Add `entr` and you get the "live-reload" feature for free too.
My guess is that there's only so much change you can foist on people at once. If the point of Tauri is that JavaScript devs can leverage their existing knowledge and skills then meeting them where they (or most of them) are seems like a reasonable strategy.
Not sure. To me, they seem to nail all three of them.
- The desktop application I build end up being 16M which seems small enough to me.
- The performance is generally good enough, even though I haven't spent any time optimizing things (here is loading 1000 comments from a HN thread https://ditzes.com/item/31742590, even faster if you use the local version [obviously])
Just as a reference, the application I'm building features a lot things inside the final binary, that might affect ram usage, so this is not a "hello-world" example but a real application, with a SPA built-into the binary and loaded into RAM, together with a HTTP API and more (fuller list here: https://news.ycombinator.com/item?id=31765186).
With that said, `ps_mem` (https://github.com/pixelb/ps_mem) reports that the memory usage is 58.7 MiB after starting the Tauri application. If I run just the HTTP API, memory usage ends up being 19.4 MiB. So I guess in that sense, the overhead of Tauri is about ~39.3 MiB.
For my use case, that's pretty acceptable.
Edit: full data in case it interests people:
Desktop application:
Private + Shared = RAM used Program
47.0 MiB + 11.7 MiB = 58.7 MiB ditzes
Just the API:
Private + Shared = RAM used Program
19.0 MiB + 345.5 KiB = 19.4 MiB api
Per their introduction video they advertise it as lightweight as the runtime "only" uses 180MB of memory at startup.
This makes GTK and QT look lightweight in comparison, not to mention FLTK, a 3D enabled, platform independent toolkit, which fits in a statically linkable 300kB library.
Of course, these require C++, and the point of those frameworks is to enable web developers to become application developers. One can't expect resource efficiency when everything has to run on top of a web browser.
Like Tauri, this is only lightweight in terms of download size as it doesn't download chrome. The 'bloat' of electron is really at runtime due to loading a full browser engine. Both neutralino and Tauri will use roughly as much ram as an electron app, give or take. You're only saving on download size.
This is only the case for Tauri on Windows because the native website is just Chromium. On MacOS it’s much leaner. I can’t find the thread where the Tauri devs mentioned a plan to fix this, but iirc they do have one.
I personally liked that I could use whatever I wanted for the backend, but I’m kind of inclined to switch to Tauri anyway since the build story seems a bit better (ultimately I want native desktop builds for every platform).
Been using tauri since it was in alpha for hobby project. Experience overall is pretty good. You really can call backend rust from js, in a lightweight browser window.
It is probably the most approachable technology for me for making desktop apps these days. Much leaner than electron, like it says on the tin.
- What's the point of mentioning Rust when the heavylifting is done by the system's webview widget, and applications are written in HTML/CSS/JS, just as in Electron?
- Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime? Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
I think it depends on your use case. Yes, a huge selling point Electron is being able to control the Chromium version. But, I can imagine a lot of less complicated apps don't need this.
Also, the Chromium renderer is only half of an Electron app. There is also a background thread running in node, which can pass messages to the renderer.
So, I can imagine that for apps that are more background thread heavy, swapping out node for rust could work quite well.
> What's the point of mentioning Rust when the heavylifting is done by the system's webview widget, and applications are written in HTML/CSS/JS, just as in Electron?
You're assuming the 'heavylifting' part of the application is in the UI itself. Imagine some data processing app where the heavylifting part would benefit from a backend running in Rust. Say, an image enhancer of some kind.
> Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
Electron also made the packaging of such an app dramatically easier when building on macos/linux/windows.
But if you write your "backend" in rust, then with tauri you don't need a separate process, which may or may not be important depending on how your application works, and your tolerance for additional overhead.
> What's the point of mentioning Rust when the heavylifting is done by the system's webview widget, and applications are written in HTML/CSS/JS, just as in Electron?
That is true. It's basically exposing a Rust API and using FFI to the Desktop APIs. Nothing special going on apart from hype and marketing and possible over-promising on features.
> Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime?
Yes. The selling point here is that there are no fundamental rewrites needed for using Electron but only small Javascript / Typescript tweaks to get it up and running. This is why unfortunately Electron is used all the time despite the giant negatives. As with Tauri, it is basically a wrapper around the system Webview and using Rust FFI to the Desktop APIs.
I'd rather bet on Flutter Desktop as a possible long term Electron competitor.
"To compile a desktop application, you must build it on the targeted platform: build a Windows application on Windows, a macOS application on macOS, and a Linux application on Linux."
So, I essentially do need to own a mac if I want to target macs along with other platforms.
> So, I essentially do need to own a mac if I want to target macs along with other platforms.
If you want to target other platforms than the one you are currently running, then you need to compile and run on that target machine as well. It is not a hard requirement that you need a Mac to develop Flutter applications. The Flutter SDK is also on Windows and Linux machines as well.
It is exactly the same thing for Tauri. [0] This is why they tell developers to use GitHub Actions or CIs to do it for them. Again, the same can be done for Flutter.
Electron on the other hand, does not need any of that.
It's an application framework, with UI being only one part of it. It has a native Rust API for writing non-UI parts of the apps in Rust. Plus there's a lot of Tauri's own code for window management, clipboard, networking, auto update, bundling, etc.
Another difference is that it doesn't need to bundle a Node.js or another language runtime.
This is what I thought at first until I dove in more. AFAIK, Tauri makes it possible to write your ENTIRE app in Rust _EXCEPT_ the view. This means you can take events and send them directly to Rust for processing and vice versa. While porting an existing web app might not use any Rust, someone using this to specifically create a Rust GUI app can use the HTML/CSS/JS portion as just a view for their Rust app for the most part.
Hmm, I was thinking about writing a nodejs native module with rust to access some system library in an electron app for one of my side project, but using this might be easier instead. I guess I should check it out.
As a tauri user, I can highly recommend it. If you can write the backend code in Rust only it's very simple and you have a much smaller footprint than electron.
I wonder if they've gotten around the horror of Windows distribution for native webview based apps?
The usual problem is that you have to either use an antiquated IE based webview on Windows or install the Microsoft Edge runtime. The latter is painful to bundle and some people don't like it, especially enterprisey IT departments who consider it "another thing" they have to approve instead of just a part of the app since it's a separate OS component.
> The usual problem is that you have to either use an antiquated IE based webview on Windows or install the Microsoft Edge runtime.
Windows 10/11 both ship with Edge by default, so however big of a problem that is _now_ (probably depends a lot on your target market), it certainly will progressively be a smaller problem over time. Windows 10 was released almost 7 years ago, so while there are undoubtably some corps stuck with windows 8 as their standard, most of the world should've moved on at this point I'd think.
It depends on your target market then. If it's for business/enterprise use you have to ship the entire universe and try to support Windows as far back as possible because companies don't upgrade.
It is these types of platform questions that make Electron so powerful from the developer perspective. In building Beekeeper Studio I already have a lot of OS-specific problems to debug, having to also debug the webview just makes it 100x harder.
Electron is one of those things that's both terrible and awesome at the same time. It's great for developers but it's a RAM hog, a CPU hog, a bandwidth hog (in downloads), and a disk hog.
But don't blame Electron. Blame OS vendors and their refusal to standardize anything when it comes to app distribution.
This seems a very interesting addition to the Rust ecosystem. I wonder how much traction it will get, though.
Some days ago there was an HN thread about Rust, conversing about the steep learning curve of Rust. The conclusion frequently is that maybe Rust is great for financial systems, kernels, rendering engines, media processors, etc... but just not necessarily the best tool for the job when there is no pressing need to avoid GC, and/or to squeeze the maximum performance while at the same time maintaining memory correctness. Which, on the other hand, tends to be the immense majority of application development out there...
So Tauri seems to me has a similar issue than the Qt Framework (built on and for C++): its adoption as an Electron alternative might not be as much as it deserves, because of the difficult to learn programming language that is behind it.
Thoughts?
EDIT: I know Tauri is just a WebView component, but programming in Rust still seems to be an important part of developing apps with it (it is even prominently featured in the 100 seconds video of the entry)
Tauri is "just" a system webview wrapper. It's an interesting alternative to Electron for some applications because the installer is much smaller, but it also has downsides compared to Electron (the system web view will be updated independently and may unexpectedly break the application).
As far as I understand, applications are not written in Rust but in HTML/CSS/JS.
There's a communication channel between the Rust code and the JS running in the browser. It's possible to move as much functionality to Rust as you want... It's even possible to compile Rust to WASM to use that in the "frontend" though that from my experience is very cumbersome due to the Rust bindings for the Web API being pretty terrible.
For electron based apps, most part of the codebase runs on the chrominum front-end - written in JavaScript / HTML. Usually only some critical code runs on the node backend.
As such then, the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem, while the critical parts can be offloaded to Rust. Even the filesystem access is possible in JavaScript side itself.
Well I agree that it is already a good tradeoff, being able to offload the most intensive tasks to Rust, which is really performant. However my perspective is that of a C++ developer already, so I like Rust as a "better C++"... it's just that I'm not sure others will see it with such kind eyes :-)
On a tangent, I've been forced to learn and use Swift the last couple weeks, and to my surprise it has been a delight! If it had a more cross-platform spirit, I think I might have found a new favorite of mine for general application development.
> the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem
That's a decision the developer has to take, but I'd rather see it as the opposite: the sensible approach is to run just the UI related things in Javascript, and run almost all of your business logic in Rust.
That's how I use it too, mostly because I personally find JavaScript and typescript frameworks harder to use than rust. Managing data in js is hard for me without static typing. Everyone will have different comfort levels but I agree, business logic in rust, front end in js is a great separation.
You can use tauri without concerning yourself with rust at all. You can use typescript or JavaScript. Optionally if you want too you can write backend stuff that needs to go fast in safe or unsafe rust. It's kinda dreamy if you need to access drivers, or other things that are very uncomfortable to do in js.
When you get comfortable with rust it's just like any other language you might use. Yea it has safety benefits but it's just a nice language.
People talk about rust like it's impossible to learn, or not worth it, I think it's a language every programmer should learn at some point to fact check their understanding of memory management. It does take a few weeks to figure out for some people, but writing basic/easy/sane rust isn't a challenge at all.
This is a known downside: rust forces you to write correct code, and will refuse to compile until you prove to it that you don’t have data races, all errors are handled, etc.
If it’s a one time script, I still whip out the trusty Perl one-liner, because correctness doesn’t matter.
I would argue, however, that the vast majority of software would benefit from the rust compiler. The type system is very powerful and modelling your problem in it lets you think about the problem explicitly and guarantees safety around its usage. You can refactor without worrying about the entire codebase breaking, and the doc and testing system is some of the best I’ve seen.
Rust lends itself naturally to writing large maintainable codebases, and I think that this is a much more important aspect that how quickly can you get the initial build out the door. Reliability is not just for the kernel and rendering engine.
And to that extent, due to the lack of GC, you need to provide it (and keep in your head) with lots of extra information that wouldn't be needed with other languages.
I find that Rust is too strict because it assumes concurrent multithreaded code by default. Which wouldn't be needed for most desktop apps. Why no circular refs or having a mut ref and a ref at the same time, in my simple single-threaded To-Do list Tauri app?
I disagree, and I'd be fascinated to hear more of your perspective here.
I love Rust precisely because I can keep extra information out of my head. When I express something with the type system, I can stop tracking it mentally, and just rely on the compiler to keep track of it for me. With dynamic languages, I have to track far more mental state.
If this were permitted, then this example would have use-after-free whenever myvec reallocates its storage. No concurrency needed.
I'm not sure what you have in mind for circular references, but I don't know of any complications with circular references that have anything to do with concurrency.
Excuse me? If you're unable to clarify your thoughts enough so others can understand what you mean and why you say what you say, you need to take a step back.
I do really want to understand the "why", I'm not being sarcastic or anything.
It's faster to start, faster to build, but not faster for pure web, most of time is slower than electron except for windows, because webview2 and electron using the same core. But if you replace some of your app function by bridging to rust, it's blazing fast.
I looked at it, but there is very little ecosystem support for other UIs beyond Material. There are partial Macos/Windows (fluent) libs but everything still seems quite immature. I do think it gets better rapidly though.
Here is another one https://github.com/wailsapp/wails powered by Golang, but both of tauri and wails do not support BrowserView like feature in Electron, which means you can not build a brave browser on top of them.
Depends on your skill set, wails maybe better, think building a UI based tailscale app, just make the embed web part display directly instead behind a http.Server with extra 3-5 MB
If I'm trying to bring app to mobile, ionic is my first choose. Like fluter is not the first choice to build a web app. For tauri case, most tauri app shared part is web based, you can just put it into ionic, and deploy for mobile now.
What you mean tab-strips ? There are toooooooo many good HTML ui components, good I mean beauty, good code quality, maintained by a team, but maybe not good enough for your use case. UI is verrrrrry subjective.
There is no such thing like desktop native components, you have to choose the desktop first, every desktop is different, but there are always someone simulate the ui.
All these components/frameworks are build for websites, but a desktop application looks different. I haven‘t seen a maintained desktop application ui framework in years.
I have been unable to find any "desktop-like" components.
There are many many things that just use some CSS styling on native radio buttons or whatever, but very few that offer higher-level functionality like tab-strips where I can pull of a tab and reorder it etc. I.e. more than just styling some divs.
Yes, there is no fully desktop like components, looks like desktop but no desktop. Just like recently the app is not that native look, only flutter give you almost pixel perfect native looking, native is hard, build for the base os needs, not for every one to use.
The good side of using native is less learning more intuitive, but everyone doing there own design system now, users already trained to use newer design pattern.
Quite enjoying https://daisyui.com/ at the moment, and in general any framework built with tailwind CSS that allows styling with tailwind utility classes.
In my curious search for lighter Electron alternatives to implement Zoho Writer's (https://writer.zoho.com) desktop app: I found Sciter[1]
It supports multiplatform app development with HTML/JS/CSS and the entire engine's runtime is just about 5MB which is unbelievably small!
I further analysed how this was possible, what I found was beyond fascinating.
1. The author has wrote a compiler that supports JS with useful extensions like classes and fancy stuff, even before ES6 came into existence.
2. He had built his own layouting engine that understands HTML and CSS 3.0
Basically he's built a custom browser engine, but custom tailored for writing multi-platform apps. So it's super-fast without as much memory taxes. It's not backed by a BigCo or a huge community (I guess) and I'm not sure whether I'll pick it for a business critical app. But the way it's architected seems far superior than the shortcut approaches that Electron or most other alternatives take.
The project is not even new. It's more than a decade old which itself is amazing.
sciter looks good, but just don't think about the recent modern web feature, current web feature is impossible to make it right/full by a small team, even ms can not catch up, so they just choose the chromium.
sciter is good if you are looking for make an app based biz which not depends too much on web spec.
> sciter looks good, but just don't think about the recent modern web feature, current web feature is impossible to make it right/full by a small team, even ms can not catch up, so they just choose the chromium.
Not every feature needs to be supported, which feature are you referring to?
Also, given the use case: what is required in your opinion?
How does the shift in microsofts scope translate to the efforts to sciter?
What did the shift imply?
> sciter is good if you looking for make a small app which not depends too much on web spec.
Since when is it a feature to comply to "web spec"?
Why should anyone continue to comply with all new requirements?
And why do you feel it is required for portable desktop applications?
Why not settle on some proven essentials?
And why I am talking about browser now?
Hopefully you elaborate your thoughts: I am sincerly curious about your opinion.
First of all, I do like sciter, it's fresh air in wails,webview,electron & tauri.
There are several cases why I prefer an electron: BrowserView, FileSystem api, newer css feature(Interop 2022 are greate), and all the newer js feature I use but I don't know it.
I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
> I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
Okay, now I see: As a web dev you are able to make use of all these new features. I do not know about current conveniences.
FWIW is that CSS should be portable across any browser/web view. And given that browsers nowadays occupy tons of memory (even though they are written in highly performant languages) I am still impressed by sciters small shipping size.
> If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
Thank you for the recommendation!! It appears to me that his previous attempts to market his product have left a serious impression. I do remember stumbling about sciter a while ago, neglecting it as well. But I can't recall my reasoning.
> BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
> CSS should be portable across any browser/web view. And given that browsers nowadays occupy tons of memory (even though they are written in highly performant languages) I am still impressed by sciters small shipping size.
Chrome is new IE since June 15 2022, and happy about it. Interop 2022 is about make safari and chrome get on the same page about new css feature.
Memory, portable CSS and browser compat is about cost, if I can make whole company install chrome, that can save a ton of money investing on support unexpected browser, one time install is way cheaper than continue support. If the company is big enough, there will be no problem, like google can rewrite whole Google Doc to canvas to support cross browser.
If building a sciter based app biz, that's all your investing goes, that make sense.
The problem is, you can forget about the entire web and node ecosystems of libraries, because it's just not compatible with any of the standard stuff. You'll probably end up having to write almost everything from scratch.
Also, whatever you write won't then be usable in normal browsers. So it's essentially just another cross-platform UI library, with a DSL for the UI parts - of course that's still good enough for many people.
...but if your business need/use case is to port with your existing web app to the desktop with minimal fuss (and you're willing to sacrifice UX), this in no way helps (unlike Electron). If you're going to have to manually rewrite everything for the desktop anyway, why would you want to do it in the DOM, using an older HTML version, a CSS subset, and a somewhat-compatible JS-lookalike? Why wouldn't you just write it in a desktop-native UI kit?
Nothing wrong with jQuery if it suits your use case! Sometimes mutating the DOM directly is simpler and more maintainable.
IMO React is a response to a problem that not all websites have (complex state-dependent nested UIs). At a certain level of complexity it's worth it, at another level it's necessary, beyond that it's insufficient... but below that it can totally be unnecessary and more pain than it's worth :)
> ...but if your business need/use case is to port with your existing web app to the desktop with minimal fuss...
I pretty much understand this point and see that Electron help.
I would definitely write desktop-native UI, maybe just because I prefer it.
And in large programs it might be somewhat expensive. But on the other hand, I found writing QT programs to be much easier than messing with web stacks.
I agree that Sciter is pretty exciting. It's tiny and very resource friendly, and the language extensions are quite nice. It also is much better at behaving like a desktop application than Electron. Oh, and did I mention there are Rust bindings?
The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.
> The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs
Even bigger drawback is that it ain't Free, honestly.
Sure, the licence allows you to use it if the users install the sciter runtime separately, but that ain't really am option beyond development imo.
Dynamic linking is allowed and you are allowed to ship those, so on Windows it's very painless. You just ship your Go/C#/Python/Rust binary with a sciter.dll that sits in the same folder. On Linux it's not quite as nice since you have to move the libsciter.so to the appropriate folder.
Of course static linking would be nicer, but I think it's fair to charge money for that (as well as for source code access). The project has to finance itself somehow.
> On Linux it's not quite as nice since you have to move the libsciter.so to the appropriate folder.
Incorrect. Linux doesn't care where you load a .so from. You could load it by using a path, or you could add a path to your LD_LIBRARY_PATH env var. You could even add it to your compiled binary's RPATH. All methods support relative paths. The latter requires a binary, but the first two work with nearly all scripting languages.
They are easier for the end user in certain cases. Putting the library in the system library search path requires elevated privileges (usually). Having your application run from a self-contained directory does not.
I don't think I agree. You don't need root and you don't need to "install" anything with these other options; it allows the user to extract and run rather than extract, elevate, install, run. It clearly shifts some of the pain from the user back to the developer. It's particularly clearly a win if you're distributing your app on your website instead of via distro package managers.
A shell script provided by the app author can automate setting LD_LIBRARY_PATH and running the binary. It's very convenient for the end user. Lots of programs are shipped to Linux this way.
I think there is an oversized focus on everything being free. It started with Google being free but it really isn't since you have to view adds and get distracted.
Also think about a software tool that costs say $100. It ain't free but that's your hourly salary Mr. Professional Developer. Using only free tools is penny-wise and pound foolish.
Agreed; don't pick the free-as-in-beer tool solely because of that. However, some of the free-as-in-beer tools are the best. And those you should donate to (if they accept it). :)
Sciter isn't exactly a custom browser engine, because it lacks many, many APIs that browsers would use. It just happens to also use HTML & CSS, but it's not Servo-lite or Chromium-lite with V8 slapped on.
That sounds like the worst of both worlds, actually. A web-LIKE language that only supports some, not all, of real browser features? Sounds like Internet Explorer all over again.
If you can't reuse the same code between web and the desktop, you might as well use a better desktop framework. This just creates a false positive lookalike that is surface-level compatible but really not reusable and maintainable, and trying to figure out which APIs are shared and which aren't would be more work than just working in a different language & environment altogether.
Which better desktop framework for cross-platform with some of the productivity available for web apps? Curious on your experiences because it's hard to avoid a lot of sprawl and inconsistencies over time.
That's a good question, and I don't know the answer :) I wasn't thinking about it that way, like as an alternative to QT or the Java stuff, you mean? That might make sense if your users don't really care about native look & feel.
Was more considering it from the perspective of web-native companies wanting some offline/desktop experience too
You write your own JS/HTML/CSS to style it, however you want. I'm currently using ClojureScript to write my Tauri applications, but that has less to do with styling.
247 comments
[ 5.5 ms ] story [ 273 ms ] threadTauri seems like a step in the right direction so will be giving it a go.
The AGIs should be concerned about us, not the other way around.
I get the impression that it’s a human who doesn’t know how to speak or edit particularly well but normally gets away with it not being too bad (as I say, other videos seem to be better, though they still suffer from the aggressive cut style), but compromised harshly on quality in this case in order to squish more into the hundred seconds… and still ended up 50% over time.
I very strongly dislike the general style.
Also, it will become almost literally impossible to hear the difference in the near future, so I personally wouldn't keep assuming it's one or the other.
Also also, did you give this feedback to Jeff?
What, you overshoot by 50%? :-) But more seriously, the job that has been done is simply low-quality, even disregarding the choppy edit style—probably a mixture of shoddy work (from comparing it with some of the others), and the creator not being capable of better as regards the speech—most aren’t particularly aware of how to improve. Much better is readily possible.
> Also, it will become almost literally impossible to hear the difference in the near future
I am an excellent reader, highly regarded for my diction and prosody and for conveying the sense of a matter. So far, I haven’t heard a TTS demo, hand-picked or otherwise, that would stand a chance against a skilled reader: the veriest dunce would savvy which was which within a couple of sentences. (And at least a couple of the demos were deliberately trying to address these sorts of shortcomings in inflection and such.) Certainly they’ve reached the stage where you often can’t reliably identify the computer versus the mediocre reader (and there are an awful lot of them), but I don’t think we’ll see computers beating skilled readers and speakers any time soon, when I consider how poor a job AI is still doing on coherent longform writing, and then add the degrees of nuance and information conveyed in speech. (Supplant them? Sure. But you don’t have to be better than something to supplant it, just cheaper, or some such thing. My favourite example of this is book binding where hot melt glue is vastly inferior to cold glue, but it’s much faster and thus cheaper to produce with, and it’s good enough that you’ll struggle to find cold glue ever used in production now.)
The application I wrote is a Hacker News client with focus on offline reading and listing comments in threads sorted by time and flat, instead of trees sorted by score (which incidentally, also works as a web application which is deployed here: https://ditzes.com/).
I found it helpful when I'm traveling but still want to read discussions, useful for following along threads that are actively being discussed (this submission can be seen at https://ditzes.com/item/31764015 for example) and also useful when using HN comments as reference to something I'm building. Guess I'm also pretty proud that the client is VERY fast, loading 1000 comments in something like 1s (because of the caching). Like this thread for the Coinbase layoffs: https://ditzes.com/item/31742590 (1001 comments)
The Tauri application currently works with 99% of the features of Ditzes, but the mouse "back" button doesn't actually navigate the internal browser back in history with Tauri yet, so I haven't done a "Show HN" yet as I consider that a essential feature of Ditzes (for following along threads via the "View" link) before "launching" it.
The Tauri-part of the source can be found here: https://codeberg.org/ditzes/ditzes/src/branch/master/src-tau...
Overall, besides the extremely long compile times, Tauri has a been a pleasure to develop with, and I'd definitively use it over Electron in the future. Really looking forward to mobile support as well, as then I'll finally have a comfortable and offline-capable HN client for my cellphone.
Out of curiosity: fresh builds or also incremental builds? If the latter, how much of it is linking?
My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies and changing one line in main.rs takes about ~20 seconds for the debug compile to finish (on a 5950X CPU). Fresh build takes about 1m30s but that only happens on CI, so not really a problem day-to-day for me. Full CI build on Codeberg/Woodpecker takes around 5 minutes from push to release created, but that's including other things too.
I have no experience with Rust. Having 0.4 dependencies per line (so every 3 lines you are dependent on a 3rd-party) sounds very extreme. Can you elaborate a bit what those dependencies are (like many std libs?)?
This isn't like C++ where a single dependency is a huge project. Some crates are literally just trait (interface) definitions.
My project have ~30 dependencies defined for various features in the client. The rest are transitive.
Here is the output of cargo tree for your leisure: https://pastebin.com/aep1bX4v
A quick scan of cargo tree seems to indicate most of them comes from tauri and actix projects.
Edit: oh, and also tantivy (a search engine) ends up pulling in ~300 dependencies which is a pretty big chunk of the total
- An electron-like framework
- A web framework
- Multiple HTTP clients
- An HTML parser
- An image editor
- A search engine
Some potential dependency savings I noticed:
How come you pull in both isahc and reqwest? On the surface, don't they fill the same role? Similar for rustls and openssl.
If you upgrade your readability dependency, you will only pull in reqwest once instead of twice. Might be useful to run `cargo tree -d`.
I'm not familiar with savefile? What does that get you over serde_json which you also pull in?
> How come you pull in both isahc and reqwest? On the surface, don't they fill the same role? Similar for rustls and openssl.
Yes indeed. I started with using reqwest, but it's no longer used and only isahc is used, so reqwest can be removed from the list.
Same with openssl/rustls. Started with rustls, but not longer used, so can also be removed.
Simply forgot to remove them at one point I guess.
> If you upgrade your readability dependency, you will only pull in reqwest once instead of twice. Might be useful to run `cargo tree -d`.
Ah, that's good to know. I'll do that once I put in some other changes, thanks!
> I'm not familiar with savefile? What does that get you over serde_json which you also pull in?
Rust savefile persists structs as binary data on disk, and also have versioning. Started out persisting everything as JSON, but loading thousands of posts (or even hundreds) from disk and deserializing them from JSON turned out to be quite slow. So using savefile mainly for performance, but I like the versioning/migration aspect of it as well, although I haven't used it yet with Ditzes.
serde_json is mainly used to parse responses from the HN API and to output JSON from the HTTP API, if I recall correctly.
- denoland/deno (nodejs-like runtime) - 1550
- alacritty/alacritty (Terminal) - 303
- sharkdp/bat (`cat` clone) - 249
- meilisearch/meilisearch (search engine) - 1128
- starship/starship (command line prompt) - 427
- swc-project/swc (JS/TS compiler) - 1869
- AppFlowy-IO/AppFlowy (Notion clone) - 1146
- yewstack/yew (Rust/WASM web framework) - 942
- rustdesk/rustdesk (remote desktop) - 648
- nushell/nushell (shell) - 858
- ogham/exa (`ls` alternative) - 61
So yeah, seems even things as basic as a `cat` replacement ends up with 249 dependencies. Lowest amount of dependencies is a `ls` alternative, which ends up with 62 dependencies.
Use grep package -F '[['package Cargo.lock | wc -l instead. This is doubly true if you pull in multiple crates using the same framework behind it, e.g. in async projects. E.g. for exa this is 45 instead of 61. For deno this turns into a 3x difference (515 vs. 1571).
Other reasons, besides what has been mentioned (vendoring being very uncommon, crates existing for common type and trait definitions, crates being generally scoped more narrowly resulting in more smaller crates), a lot of crates have additional crates for macros. Bindings often end up being a whole bunch of crates for this reason (i.e. one xyz-sys crate for the FFI bindings, plus one or more crates for a rusty wrapper and perhaps one or more crates for convenience crates). Case in point from deno's dependency tree:
[0]: https://github.com/rui314/mold
But then I come from a dynamic application development background (mostly Clojure), so maybe I do have a pretty unfair view on how fast I should be able to make a change and see the effects (sub second is the usual wait time in Clojure land).
Incremental builds are unlikely to benefit from multiple cores. I have a 5900x Desktop and recently bought a Laptop with 12700H. For some incremental builds, I'm getting the same performance. The Desktop Ryzen shines with full multiple builds (where the laptop gets hot and has to sabotage itself); or with running multiple programs without noticeable performance impact.
If not, can you try using it and let us know whether it improves your compile times or not?
Here's the instructions for using it with Rust: https://github.com/rui314/mold#how-to-use=
- Debug build from scratch: ~1m 20s
- Incremental debug build: ~3s
- Release build from scratch: ~3m 40s
So, seems that helped quite a bit, thanks for the tip :)
As someone who is generally unaware of things as I'm new to Rust, is there any drawbacks to using a non-default linker? Everything seems to work fine as far as I can tell, but no drawbacks mentioned in the repository of Meld makes me slightly skeptical.
- It's linux only (macOS support WIP)
- It's still somewhat experimental. It may not be able to link everything. There may be bugs.
Having said that, it's written by someone with a lot of experience writing linkers (they previously worked on lld), can link codebases as complex as chromium, and generally seems to work well for most use cases.
A common pattern would be to use mold for development, and then the regular linker (varies by platform) for release builds.
That makes a lot of sense. Thanks for sharing the potential drawbacks and possible solutions to those :)
But on a more serious note, what could they possibly stand to gain to use Deno instead of NodeJS at this point? The languages are mostly the same, the tooling slightly different. Sounds like it'd add a lot of changes just for the sake of changing things. Not to mention newer stuff usually are less tested and higher chance of not working.
Speaking about newer, has Deno received any sort of security audits? Tauri is pretty focused on security, so one could assume that'd be a requirement before even considering Deno.
My guess is that there's only so much change you can foist on people at once. If the point of Tauri is that JavaScript devs can leverage their existing knowledge and skills then meeting them where they (or most of them) are seems like a reasonable strategy.
- The desktop application I build end up being 16M which seems small enough to me.
- The performance is generally good enough, even though I haven't spent any time optimizing things (here is loading 1000 comments from a HN thread https://ditzes.com/item/31742590, even faster if you use the local version [obviously])
With that said, `ps_mem` (https://github.com/pixelb/ps_mem) reports that the memory usage is 58.7 MiB after starting the Tauri application. If I run just the HTTP API, memory usage ends up being 19.4 MiB. So I guess in that sense, the overhead of Tauri is about ~39.3 MiB.
For my use case, that's pretty acceptable.
Edit: full data in case it interests people:
Desktop application:
Just the API:This makes GTK and QT look lightweight in comparison, not to mention FLTK, a 3D enabled, platform independent toolkit, which fits in a statically linkable 300kB library.
Of course, these require C++, and the point of those frameworks is to enable web developers to become application developers. One can't expect resource efficiency when everything has to run on top of a web browser.
https://neutralino.js.org/
With neutralino you're using the system main process, so you're only spawning a new browser thread.
https://github.com/styfle/awesome-desktop-js
It is probably the most approachable technology for me for making desktop apps these days. Much leaner than electron, like it says on the tin.
- What's the point of mentioning Rust when the heavylifting is done by the system's webview widget, and applications are written in HTML/CSS/JS, just as in Electron?
- Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime? Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
Also, the Chromium renderer is only half of an Electron app. There is also a background thread running in node, which can pass messages to the renderer.
So, I can imagine that for apps that are more background thread heavy, swapping out node for rust could work quite well.
Also, more complicated apps don't need this, the ones that want to control every aspect of the render, with SVG or Canvas.
You're assuming the 'heavylifting' part of the application is in the UI itself. Imagine some data processing app where the heavylifting part would benefit from a backend running in Rust. Say, an image enhancer of some kind.
> Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
Electron also made the packaging of such an app dramatically easier when building on macos/linux/windows.
That is true. It's basically exposing a Rust API and using FFI to the Desktop APIs. Nothing special going on apart from hype and marketing and possible over-promising on features.
> Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime?
Yes. The selling point here is that there are no fundamental rewrites needed for using Electron but only small Javascript / Typescript tweaks to get it up and running. This is why unfortunately Electron is used all the time despite the giant negatives. As with Tauri, it is basically a wrapper around the system Webview and using Rust FFI to the Desktop APIs.
I'd rather bet on Flutter Desktop as a possible long term Electron competitor.
No. [0]
[0] https://docs.flutter.dev/development/platform-integration/de...
"To compile a desktop application, you must build it on the targeted platform: build a Windows application on Windows, a macOS application on macOS, and a Linux application on Linux."
So, I essentially do need to own a mac if I want to target macs along with other platforms.
If you want to target other platforms than the one you are currently running, then you need to compile and run on that target machine as well. It is not a hard requirement that you need a Mac to develop Flutter applications. The Flutter SDK is also on Windows and Linux machines as well.
It is exactly the same thing for Tauri. [0] This is why they tell developers to use GitHub Actions or CIs to do it for them. Again, the same can be done for Flutter.
Electron on the other hand, does not need any of that.
[0] https://tauri.studio/v1/guides/building/cross-platform
- Cross-platform auto-updating
- Desktop tray features
- System notifications
- Menu stuff
These are some of the "extra" things that also made Electron nice.
You have a point about browser API compatibility, though. That's the big downside to using the system-provided webview widget.
Another difference is that it doesn't need to bundle a Node.js or another language runtime.
marketing
The usual problem is that you have to either use an antiquated IE based webview on Windows or install the Microsoft Edge runtime. The latter is painful to bundle and some people don't like it, especially enterprisey IT departments who consider it "another thing" they have to approve instead of just a part of the app since it's a separate OS component.
Windows 10/11 both ship with Edge by default, so however big of a problem that is _now_ (probably depends a lot on your target market), it certainly will progressively be a smaller problem over time. Windows 10 was released almost 7 years ago, so while there are undoubtably some corps stuck with windows 8 as their standard, most of the world should've moved on at this point I'd think.
But don't blame Electron. Blame OS vendors and their refusal to standardize anything when it comes to app distribution.
Some days ago there was an HN thread about Rust, conversing about the steep learning curve of Rust. The conclusion frequently is that maybe Rust is great for financial systems, kernels, rendering engines, media processors, etc... but just not necessarily the best tool for the job when there is no pressing need to avoid GC, and/or to squeeze the maximum performance while at the same time maintaining memory correctness. Which, on the other hand, tends to be the immense majority of application development out there...
So Tauri seems to me has a similar issue than the Qt Framework (built on and for C++): its adoption as an Electron alternative might not be as much as it deserves, because of the difficult to learn programming language that is behind it.
Thoughts?
EDIT: I know Tauri is just a WebView component, but programming in Rust still seems to be an important part of developing apps with it (it is even prominently featured in the 100 seconds video of the entry)
As far as I understand, applications are not written in Rust but in HTML/CSS/JS.
Frontend UI yes. But enables you to use rust for your background worker (Electron apps use node for the background worker)
As such then, the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem, while the critical parts can be offloaded to Rust. Even the filesystem access is possible in JavaScript side itself.
From that sense I feel this is a good tradeoff.
On a tangent, I've been forced to learn and use Swift the last couple weeks, and to my surprise it has been a delight! If it had a more cross-platform spirit, I think I might have found a new favorite of mine for general application development.
That's a decision the developer has to take, but I'd rather see it as the opposite: the sensible approach is to run just the UI related things in Javascript, and run almost all of your business logic in Rust.
When you get comfortable with rust it's just like any other language you might use. Yea it has safety benefits but it's just a nice language.
People talk about rust like it's impossible to learn, or not worth it, I think it's a language every programmer should learn at some point to fact check their understanding of memory management. It does take a few weeks to figure out for some people, but writing basic/easy/sane rust isn't a challenge at all.
I would argue, however, that the vast majority of software would benefit from the rust compiler. The type system is very powerful and modelling your problem in it lets you think about the problem explicitly and guarantees safety around its usage. You can refactor without worrying about the entire codebase breaking, and the doc and testing system is some of the best I’ve seen.
Rust lends itself naturally to writing large maintainable codebases, and I think that this is a much more important aspect that how quickly can you get the initial build out the door. Reliability is not just for the kernel and rendering engine.
And to that extent, due to the lack of GC, you need to provide it (and keep in your head) with lots of extra information that wouldn't be needed with other languages.
I find that Rust is too strict because it assumes concurrent multithreaded code by default. Which wouldn't be needed for most desktop apps. Why no circular refs or having a mut ref and a ref at the same time, in my simple single-threaded To-Do list Tauri app?
I love Rust precisely because I can keep extra information out of my head. When I express something with the type system, I can stop tracking it mentally, and just rely on the compiler to keep track of it for me. With dynamic languages, I have to track far more mental state.
"Mutable xor shared" does not have anything to do with concurrency or threads. Here's one example in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&editio...
If this were permitted, then this example would have use-after-free whenever myvec reallocates its storage. No concurrency needed.
I'm not sure what you have in mind for circular references, but I don't know of any complications with circular references that have anything to do with concurrency.
I do really want to understand the "why", I'm not being sarcastic or anything.
i think thats where claim comes from.
edit: embedded lib-chromium thing
Depends on your skill set, wails maybe better, think building a UI based tailscale app, just make the embed web part display directly instead behind a http.Server with extra 3-5 MB
Not just styling buttons with CSS, but actual components like e.g. tab-strips?
Some link to share
- MacOS & Windows https://github.com/gabrielbull/react-desktop - Ubuntu https://github.com/vivek9patel/vivek9patel.github.io - XP https://botoxparty.github.io/XP.css/
There is no such thing like desktop native components, you have to choose the desktop first, every desktop is different, but there are always someone simulate the ui.
I have been unable to find any "desktop-like" components.
There are many many things that just use some CSS styling on native radio buttons or whatever, but very few that offer higher-level functionality like tab-strips where I can pull of a tab and reorder it etc. I.e. more than just styling some divs.
The good side of using native is less learning more intuitive, but everyone doing there own design system now, users already trained to use newer design pattern.
It supports multiplatform app development with HTML/JS/CSS and the entire engine's runtime is just about 5MB which is unbelievably small!
I further analysed how this was possible, what I found was beyond fascinating.
1. The author has wrote a compiler that supports JS with useful extensions like classes and fancy stuff, even before ES6 came into existence.
2. He had built his own layouting engine that understands HTML and CSS 3.0
Basically he's built a custom browser engine, but custom tailored for writing multi-platform apps. So it's super-fast without as much memory taxes. It's not backed by a BigCo or a huge community (I guess) and I'm not sure whether I'll pick it for a business critical app. But the way it's architected seems far superior than the shortcut approaches that Electron or most other alternatives take.
The project is not even new. It's more than a decade old which itself is amazing.
[1] https://sciter.com
sciter is good if you are looking for make an app based biz which not depends too much on web spec.
EDIT: small app -> app biz
Not every feature needs to be supported, which feature are you referring to? Also, given the use case: what is required in your opinion? How does the shift in microsofts scope translate to the efforts to sciter? What did the shift imply?
> sciter is good if you looking for make a small app which not depends too much on web spec.
Since when is it a feature to comply to "web spec"? Why should anyone continue to comply with all new requirements? And why do you feel it is required for portable desktop applications? Why not settle on some proven essentials? And why I am talking about browser now?
Hopefully you elaborate your thoughts: I am sincerly curious about your opinion.
There are several cases why I prefer an electron: BrowserView, FileSystem api, newer css feature(Interop 2022 are greate), and all the newer js feature I use but I don't know it.
I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
> I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
Okay, now I see: As a web dev you are able to make use of all these new features. I do not know about current conveniences. FWIW is that CSS should be portable across any browser/web view. And given that browsers nowadays occupy tons of memory (even though they are written in highly performant languages) I am still impressed by sciters small shipping size.
> If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
Thank you for the recommendation!! It appears to me that his previous attempts to market his product have left a serious impression. I do remember stumbling about sciter a while ago, neglecting it as well. But I can't recall my reasoning.
> BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
No worries, thanks for your input!!
Chrome is new IE since June 15 2022, and happy about it. Interop 2022 is about make safari and chrome get on the same page about new css feature.
Memory, portable CSS and browser compat is about cost, if I can make whole company install chrome, that can save a ton of money investing on support unexpected browser, one time install is way cheaper than continue support. If the company is big enough, there will be no problem, like google can rewrite whole Google Doc to canvas to support cross browser. If building a sciter based app biz, that's all your investing goes, that make sense.
[Interop 2022]: Blog https://web.dev/interop-2022 Current status https://wpt.fyi/interop-2022
Also, whatever you write won't then be usable in normal browsers. So it's essentially just another cross-platform UI library, with a DSL for the UI parts - of course that's still good enough for many people.
As a web dev, I agree 100%. It's a mess.
> That's not a problem, but a very big plus.
...but if your business need/use case is to port with your existing web app to the desktop with minimal fuss (and you're willing to sacrifice UX), this in no way helps (unlike Electron). If you're going to have to manually rewrite everything for the desktop anyway, why would you want to do it in the DOM, using an older HTML version, a CSS subset, and a somewhat-compatible JS-lookalike? Why wouldn't you just write it in a desktop-native UI kit?
IMO React is a response to a problem that not all websites have (complex state-dependent nested UIs). At a certain level of complexity it's worth it, at another level it's necessary, beyond that it's insufficient... but below that it can totally be unnecessary and more pain than it's worth :)
Go with what works for you and your team!
I pretty much understand this point and see that Electron help. I would definitely write desktop-native UI, maybe just because I prefer it. And in large programs it might be somewhat expensive. But on the other hand, I found writing QT programs to be much easier than messing with web stacks.
The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.
Even bigger drawback is that it ain't Free, honestly. Sure, the licence allows you to use it if the users install the sciter runtime separately, but that ain't really am option beyond development imo.
Of course static linking would be nicer, but I think it's fair to charge money for that (as well as for source code access). The project has to finance itself somehow.
Incorrect. Linux doesn't care where you load a .so from. You could load it by using a path, or you could add a path to your LD_LIBRARY_PATH env var. You could even add it to your compiled binary's RPATH. All methods support relative paths. The latter requires a binary, but the first two work with nearly all scripting languages.
Also think about a software tool that costs say $100. It ain't free but that's your hourly salary Mr. Professional Developer. Using only free tools is penny-wise and pound foolish.
The trouble is that everyone wants to be a landlord these days by charging rent instead of allowing you to buy a copy of the software.
Every new feature also adds complexity and size, so it goes exactly against one of the main advantages of the project
Sciter isn't exactly a custom browser engine, because it lacks many, many APIs that browsers would use. It just happens to also use HTML & CSS, but it's not Servo-lite or Chromium-lite with V8 slapped on.
(he also hangs out on HN)
If you can't reuse the same code between web and the desktop, you might as well use a better desktop framework. This just creates a false positive lookalike that is surface-level compatible but really not reusable and maintainable, and trying to figure out which APIs are shared and which aren't would be more work than just working in a different language & environment altogether.
Was more considering it from the perspective of web-native companies wanting some offline/desktop experience too
It would be good to see what it actually looks like before investing in time to build something.
The project encouraged me to better my own workflows too, as even the awesome-tauri repo requires signed commits in the PR template :) ( https://github.com/tauri-apps/awesome-tauri/blob/dev/.github... )