Our great sponsors
-
webview
Tiny cross-platform webview library for C/C++. Uses WebKit (GTK/Cocoa) and Edge WebView2 (Windows).
-
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.
-
-
-
-
Quark
Create Applications with browser technologies using the native engine in your OS. (by jscherer92)
-
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.
-
-
-
Vrmac
Vrmac Graphics, a cross-platform graphics library for .NET. Supports 3D, 2D, and accelerated video playback. Works on Windows 10 and Raspberry Pi4.
-
-
-
clipper
📋 Cross Platform Desktop App to Save history of all information you copy and use them whenever with a solitary snap (by AkashRajpurohit)
-
remarkable
Markdown parser, done right. Commonmark support, extensions, syntax plugins, high speed - all in one. Gulp and metalsmith plugins available. Used by Facebook, Docusaurus and many others! Use https://github.com/breakdance/breakdance for HTML-to-markdown conversion. Use https://github.com/jonschlinkert/markdown-toc to generate a table of contents.
-
graderjs
💦 Turn your full-stack NodeJS application into a downloadable cross-platform binary. Also works for SPAs, or regular web-sites.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
It depends on what application you have in mind.
React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers.
For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ;
MithrilJS ( https://mithril.js.org/ ) works as it is also.
SvelteJS works as it is with Sciter.JS too.
Also Sciter.JS has it own native implementation of JSX ( it's built-in ) on JS core of Sciter.JS and also DOM extended by native element.patch(vdom) that makes "reactivity" to work in Sciter.JS with native speed.
Yet quite a lot of UI components are natively built-in. For example:
https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/
It's not a new idea, for instance
https://github.com/webview/webview
...has a fairly long history. It's great for extremely small application packages (when I tinkered around with it on macOS a few years ago I brought it down to 26 kilobytes).
The usual argument against the idea is that Electron gives you a fixed Chromium version to work against, while the system webviews are a moving target with different underlying browser engines.
I started to build some internal tools that interface with hardware using Tauri last year. That effort ended after trying to cross-compile to aarch64 and hitting a ton of roadblocks. It looks like it is still an open issue. So, Raspberry Pi, for example, is not supported.
https://github.com/tauri-apps/tauri/issues/941
Revery is another similar project that is trying to be a lightweight alternative to Electron https://github.com/revery-ui/revery
> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface.
Like other replies have mentioned, it's not a new idea
DeskGap uses the native OS Webviews. https://github.com/patr0nus/DeskGap/
Electrino (4 years old) was an experiment where they forked Electron and removed Chromium to replace it with the native OS Web views. https://github.com/pojala/electrino
Quark is a fork of Electrino: https://github.com/jscherer92/Quark
There's also a way of building desktop GUIs using Deno, which uses Deno Webview, which is a binding for the same webview library that Tauri uses.
https://denotutorials.net/making-desktop-gui-applications-us...
On the go side, there is Wails (https://wails.app/) which is pretty popular
People have been trying the WebView approach for years. Historically, it worked terribly on Windows.
https://github.com/jscherer92/Quark
https://github.com/neutralinojs/neutralinojs
On Windows, if you used the OS WebView, your Windows 7 users would be forced to use IE11 to run your app, even if they had a newer/better browser installed locally. On Windows 10, you'd get whatever random version of Edge was installed, or the new Chromium-based Edge.
In 2021, we're in a new era for Windows WebViews, thanks to Microsoft shipping WebView2 at the end of 2020, which ensures that the OS-provided WebView will be a modern version of Chromium. https://docs.microsoft.com/en-us/microsoft-edge/webview2/ Tauri supports WebView2 and I bet it will work a lot better than historical approaches.
Support is still pretty dicey on other platforms, though. macOS doesn't have anything like WebView2, so if you want to support a five-year-old version of macOS (which isn't that old in desktop terms), you'll be forced to support and test your app on a five-year-old version of Safari. (The user might have upgraded to a two-year-old version of Safari, but they might not, if they prefer Firefox or Chrome, and that's now your problem.)
The easiest and best way to improve the user's experience on old OS versions is to provide your own copy of Chromium, like Electron does.
At that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day?
Having said that, if you can keep your OS-version support matrix tight, Tauri might work OK for you.
Do you have more specifics, and/or have you advised them of the difficulties? It seems to use the same "mach" build process as does firefox, and I build FF developer edition regularly (not every day, but damn near): https://github.com/servo/servo#normal-build
While investigating this, I have deep sympathies for whoever has to work with that taskcluster silliness because yikes that is some A++ grade obfuscation as compared to a .gitlab-ci.yml or .circleci or even the .travis.yml they migrated off of
If someone paid me to do something similar, I would probably be building on top of this: https://github.com/Const-me/Vrmac
There’re two hard problems there.
One is how to render vector graphics and fonts. So far, only web browsers do that in a cross-platform way. Windows has it’s Direct2D and DirectWrite, while Linux has nothing comparable, unfortunately.
Another higher level one is how to build easy to use GUI library on top of that. Have not approached that one. I have a few ideas but did nothing so far to address them, lately I’m too busy with other projects.
We didn't take over control, rather we helped setup an independent org around webview and other related repos. At the time, the original author of webview expressed plans to work on it a lot. However, this didn't really happen. Webview is stuck with some nasty bugs and missing features, and none of the members of the Tauri team had enough C experience to fix it efficiently. Instead, we created our own pure Rust solution (https://github.com/tauri-apps/wry). We've already given it way more features than the original webview project, and it doesn't carry the bugs that plagued webview either. The next release of Tauri (about a month or so out) will use Wry, and will have features such as multi-window and fancy window styling (frameless, fullscreen, custom controls, etc...).
"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
I've performed a couple experiments remaking Electron apps using Sciter.
My first target was https://github.com/AkashRajpurohit/clipper, a neat little clipboard manager. The owner was gratious enough to officially list my project under the "Clones" section of his readme =D The result was a 6mb file, compared to the original 165mb Electron app.
The second attempt was https://github.com/girkovarpa/temps-lite, an aesthetically-pleasing weather app which was motivated largely by the fact that the original was broken and abandoned yet still had people who wanted to use it. According to the open issues and forks trying to resurrect it, anyway. The file size savings were similar to the former, and they start virtually instantly. The Electron apps have a bit of delay and then a blank window before they finish starting up.
will give you split-view out-of-the-box. But web dev's will start looking for frameworks in order to achieve this simple task that browser have internally already.
TL;DR: Web and desktop UIs use inherently different models. You can share parts between these two different platforms but only parts, really.
[1] Remarkable JS: https://github.com/jonschlinkert/remarkable
It is a good idea but it is not a new idea
the interesting history of these sorts of frameworks is that Google actually created a framework that did this and stopped development on it. the code is still on GitHub. And there's a bunch of other frameworks that use a variety of different languages not just rust as the application language that also have this idea of not bundling chromium but instead using the system webview for rendering HTML and JavaScript.
You can find a bunch of different approaches in lists like "alternatives to electron." There's some on GitHub.
I took a slightly different approach where instead of using the system web view which I thought you know is going to be inconsistent across systems and it's not going to support the latest HTML JavaScript and security features I used the assumption that the user already has chrome installed which works in a high number of cases or can download and install it if that's not the case. predictably I suppose some people express to satisfaction that it was not using Firefox. using Firefox becomes more possible and more likely I suppose as firefox's support for the dev tools protocol achieves parity with chrome support for that.
https://github.com/c9fe/graderjs
Wouldn't a better solution to be use something like https://github.com/microsoft/react-native-macos ?
Yes, Telegram Desktop is a normal C++ app: https://github.com/telegramdesktop/tdesktop
So a cross-platform is quite easy, Electron one would need to be tested for different webviews on each system.