Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
awesome-desktop-js
🖥️ A list of awesome packages and frameworks for implementing javascript applications on the desktop
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
I find it fresh and positive that Tauri developers take security very seriously. Before this 1.0 release they ordered a full security audit for the codebase and published the report ( https://github.com/tauri-apps/tauri/blob/next/audits/Radical... ).
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... )
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!!
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.
[0]: https://github.com/rui314/mold
If you want to see even more alternatives, checkout this list
https://github.com/styfle/awesome-desktop-js
I find it fresh and positive that Tauri developers take security very seriously. Before this 1.0 release they ordered a full security audit for the codebase and published the report ( https://github.com/tauri-apps/tauri/blob/next/audits/Radical... ).
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... )
Quite enioying https://daisyui.com/ at the moment, and in general any framework built with tailwind CSS that allows styling with tailwind utility classes.
i think the author swapped his custom scripting engine to https://bellard.org/quickjs/ a year or two back.
For anyone coming from the rust side and just looking for a cross-platform rust frontend framework: although not covered in any details by the docs, you can cut out all the web stuff and run everything from cargo.
I have a small `hello-world` example of a rust-only Tauri application at https://github.com/Japanuspus/tauri-from-rust
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.
https://github.com/vercel/pkg .
You write a server in Node.js, compile it to an exe with Vercel Pkg and users run the exe on their local machine and use it with their browser.
Instead of running an app "in the cloud" they run it on the server on their machine. But the server could easily also be moved to the cloud as well.
Using a browser to connect to an app running on your local machine has the nice feature that you can open any number of browser-views on it, looking at the app and your data and tools from multiple viewpoints. Since it is local they are the only user and don't need to login or "keep a session" and can thus interact with the app in multiple ways in parallel.
I don't need to design in a feature that allows users to "open a new window". That is handled by the browser. Open a new tab to the same or different (bookmarked) url.