Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website).
In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron, I guess
I'm hacking on a Tauri web app that needs to bridge to talking UDP protocols literally as we speak.
While Tauri seems better than ever for cross platform native apps, it's still a huge step to take to allow my web app access to lower level. Rust toolchain, Tauri plugins, sidecar processes, code gen, JSON RPC, all to let my web app talk to my network.
Seems great that Chrome continues to bundle these pieces into the browser engine itself.
Direct sockets plus WASM could eat a lot of software...
What's your recommendation? I've tried so many multiplatform toolkits (including GTK, Qt, wxWidgets, Iced, egui, imgui, and investigated slint and sciter) and nothing has come close to the speed of dev and small final app size of something like Tauri+Svelte.
of course dev speed will be better with tauri plus the literal ton of JavaScript transpilers we use today.
but for us an inhouse egui pile of helpers allow for fast applications that are closer to native speeds. and flutter for mobile (using neither Cupertino or material)
Glad to hear that egui is working for you, but in my experience it's not accessible, difficult to render accurate text (including emoji and colours), very frustrating to extend inbuilt widgets, and quite verbose.
One of my most recent experiences was making a fairly complex app at work in egui, then migrating to tauri because it was such a slog.
The web stack is now the desktop UI stack. I think the horse has left the barn.
It’s not great but there’s just no momentum or resources anywhere to work on native anymore outside platform specific libraries. Few people want to build an app that can only ever run on Mac or Windows.
I've built my app[1] using Qt (C++ and QML), and I think the UI looks decent. There's still a long way for it to feel truly native, but I've got some cool ideas.
You are probably not solving the same problems many other people are facing.
Many such applications are accessible on the web, often with the exact UI. They may even have a mobile/iPad version. They may be big enough that they have a design system that needs to be applied to in every UI (including company website). Building C++ code on all platforms and running all the tests may be too expensive. The list goes on.
I just started prototyping a mobile version of my app (which shares the code as my desktop app) and the result looks promising (still work-in-progress tho).
Offering a web app is indeed not trivial. Maybe Qt WebAssembly will be a viable option if I can optimize the binary and users wouldn't mind first long load time (and then the app should be cached for instant load). Or maybe I could build a read-only web app using web technology.
Currently, my focus is building a good native application, and I think most of my users care about that. But in the future, I can see how a web app could be useful for more users. One thing I would like to built is a web browser that could load both QML and HTML files (using regular web engine), so I could simply deploy my app by serving my QML files without the binary over the internet.
Thank you! I think Qt is absolutely great. One need to put a little effort to make it look and behave nicely. I wrote a blog post about it[1], if you're interested.
- It is possible, if not likely, that an attacker will control name resolution for a chosen name. This allows them to provide an IP address (or a redirect that uses CNAME or similar) that could enable request forgery.
This is quite trival, not even possible though. DNS server is quite a simple protocol. Writing a dns that reflect every request from aaa-bbb-ccc-ddd.domain.test to ip aaa.bbb.ccc.ddd won't take you even for a day. And in fact this already existed in the wild.
In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron, I guess