Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
mockoon
Mockoon is the easiest and quickest way to run mock APIs locally. No remote deployment, no account required, open source.
-
wee-slack
A WeeChat script for Slack.com. Supports threads and reactions, synchronizes read markers, provides typing notification, etc..
-
-
-
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.
-
The code is here: https://github.com/linen-dev/linen.dev It is actually kind of tricky to self host since there are quite a few services that needs set up and we could use quite a bit of work in our documentation.
I maintain an open-source app built with Electron. It serves tens of thousands of users every months and nobody complained in 5 years that it is being built with Electron. Not saying that Electron is perfect, and that it couldn't be a bit more performant, but as a solo maintainer (and entrepreneur) it helps me ship something that save people time. The burden of maintaining an application is already huge. Having to juggle with multiple environments would be a hassle and I definitely wouldn't do it.
That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet.
The app, if you are interested: https://mockoon.com
Fwiw, last time I looked, wee-slack was a decent improvement for slack text chat. These days maybe a matrix bridge?
https://github.com/wee-slack/wee-slack
Haha, it's amusing that the history essays are one of the things you remember :)
Yes you can compile Scala and ScalaFX apps down to native binaries this way. Look at Gluon Substrate:
https://github.com/gluonhq/substrate
One of our customers is experimenting with shipping such apps with Conveyor. There's a discussion ongoing here:
https://github.com/hydraulic-software/conveyor/discussions/6...
We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way.
If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:
https://hydraulic.dev/blog/13-deploying-apps-with-jcef.html
I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.
Haha, it's amusing that the history essays are one of the things you remember :)
Yes you can compile Scala and ScalaFX apps down to native binaries this way. Look at Gluon Substrate:
https://github.com/gluonhq/substrate
One of our customers is experimenting with shipping such apps with Conveyor. There's a discussion ongoing here:
https://github.com/hydraulic-software/conveyor/discussions/6...
We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way.
If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:
https://hydraulic.dev/blog/13-deploying-apps-with-jcef.html
I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.
I tried this same approach (embedded webview instead of e.g. electron -- https://github.com/rdaum/vstwebview) for something last year and I agree the biggest problem is Linux support, specifically WebKit GTK.
On Windows, and to a lesser degree on the Mac, this approach actually went pretty smoothly. But WebKit GTK introduces all sorts of problems -- having to tie into GTK's event loop even though you don't want it, dealing with distribution variances, event binding issues, etc.
I suspect the answer here for Tauri is that someone needs to expend the effort to come up with a good Rust crate bundling of Chromium or Gecko or etc that isn't tied into GTK. Yes, it would defeat the "just use the platform's webview instead of bundling" line, but really it would only be a concern for Linux.
Tauri uses WebkitGTK, which has pretty bad performance compared to other browsers on the same hardware.
https://github.com/tauri-apps/wry/issues/890#issuecomment-14...