cppwinrt VS tauri

Cppwinrt is in maintenance mode[1]. Cppwin32 is abandoned (with windows.h as the official alternative). It is now possible to deploy WinUI 3 apps as single files in C#[2] but not in C++. From experience, the entire C++ side of WinUI 3 documentation is underbaked to the extent that the easiest road is to read the C# documentation and attempt to guess the cppwinrt equivalent (as docs for cppwinrt are not really... there).

I don’t know if they’ve really abandoned C++ entirely—the compiler team certainly hasn’t, that’s true. But the above doesn’t feel like first-class support.

[1] https://github.com/microsoft/cppwinrt/issues/1289#issuecomme...

[2] https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

https://github.com/microsoft/cppwinrt/

And then compare with Project Reunion vision from 2021, and where we are three years later

https://blogs.windows.com/windowsdeveloper/2021/03/29/announ...

Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.

This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.

[0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/

Windows Runtime (WinRT) seems to be something they are working on. From what I could read are there a bunch of stuff needed apart from just a development library. I guess you meant this: https://github.com/microsoft/cppwinrt

Yeah, I closed it because it didn't seem to be taken into consideration, as later proven by https://github.com/microsoft/cppwinrt/issues/1123

Using bleeding-edge or hipster tech has always been risky. Now it can also prevent agents from being able to code effectively. If something is too new or too unusual to have much written about it around the internet, LLMs are likely to hallucinate. I found this to be true when trying to write a Tauri app, and eventually stopped trying to get my agent to write Tauri code. (At the start of the project, I knew zero Rust and zero Tauri. By the time I dropped the agent, I had learned enough to fly solo. The mediocre agent code got me far enough to start learning organically—I never read a tutorial.)

Early in the development journey, the decision came to use either Tauri or Electron to build the app. Using one of these frameworks offered a promising way to avoid writing native code for each platform (Windows, macOS, Linux). This meant a crucial choice needed consideration.

Tauri is a desktop application framework that serves as an alternative to Electron. (From Tauri v2, it also supports mobile apps.)

Tauri is a Rust-based library that enables you to build lightweight desktop applications by leveraging web technologies like HTML, CSS, and JavaScript for the UI. You can use any frontend framework of your choice that compiles to HTML, CSS, and JavaScript. Unlike Electron (a JavaScript desktop app development framework), which relies on Chromium and Node.js, Tauri uses the system's native web view.

Then I learned Tauri and used my favourite frontend framework SolidJS with TailwindCSS and DaisyUI to build the UI with MotionOne to add animations and Tauri to build the desktop/web/android/ios app.

tauri dev is incredibly slow

Are the memory benchmarks measured correctly?

This tauri issue suggests the common measurement approach might be wrong

https://github.com/tauri-apps/tauri/issues/5889

Also would be better to have specific startup time instead of "fast" (which is strange since electron is not known for fast startup)

Here is a whole story: https://github.com/tauri-apps/tauri/discussions/4089

tl;dr - Tauri uses platform's default implementation of a webview. On Windows it's WebView2 which reports back to MS.