For me, native means "I can integrate a platform widget in the middle of it". For instance, with Qt, GTK or wxwidgets it's entirely possible to integrate a Win32 / Cocoa / X11 component right in the middle of your app (and it's super important for instance for things such as integrating audio plugins, where the plugin only gives you a HWND or NSView and you have to draw your application Chrome around it, have it follow resizes, etc.)
It's pretty much impossible to embed properly without edge cases in GPU-based renderers as far as I know, if you want layering of widgets (for instance a platform widget in-between two flutter widgets in z-order)
Most toolkits, including WebUI 3.0, render widgets on their own, so you can't distinguish just on that. I'd say anything written in an interpreted language is not native, and Javascript falls into that category. Dart at least is possible to compile ahead of time, and so is C#.
WebViews aren't written or rendered with interpreted languages either. It is also usually not Javascript that makes browser based apps so heavy. It is almost always the whole browser stack that is making them large and memory hungry, which is mostly written in C++.
You can also hook a WebView up directly to a low-level language and skip Javascript entirely, so does that mean Rust + WebView = Native?
A big complaint in TFA is that Win32 is much much easier to use than Wayland is:
>Getting any example application to work is so incredibly ridiculous, that every second I program on Wayland, I yarn for the times I did Win32 programming.
And that comes from the core of how Wayland is designed.
In Win32, the stable interface / ABI is the set of C functions provided by the operating system through DLLs. These are always dynamically loaded, so Microsoft is free to change the internal interface used for controlling windows at any time. Because of this, decades-old .exes still run fine on Windows 11.
In Wayland, the stable interface is the binary protocol to the compositor, in addition to the libwayland-client library plus extensions. Instead of that socket being an "implementation detail", it's now something that all programs that just want to make a window have to deal with. You also can't just use the socket and ignore the libwayland libraries, because mesa uses libwayland-client and you probably want hardware acceleration.
The other big issue is the core Wayland protocol is useless; you have to use a bunch of protocol extensions to do anything, and different compositors may implement different versions of them. On Win32, Microsoft can just add another C function to user32.dll and you don't have to think about protocol how that gets transformed into messages on the socket layer, or compatibility issues with different sets of extensions being supported by different compositors.
I was going to point out that wayland is a protocol & surely there must be other ways to do this. But your point about mesa expecting wayland-client is a very tight binding here.
Anyone know of exceptions? People who get mesa working anyhow, some way?
It also doesn't preclude people from making nicer experiences on top of libwayland. Again I'd be curious to see what material is out there. It feels like a library that materializes the current state of things into a local view would go a long way to dispel the rage of people such as the author here, who seem to detest callbacks with firey rage.
The idea of the wayland registry seem unifying & grand to me. Ok yes it's async & doesn't hide it? Lot of ink spilled to be upset about that, and doesn't feel like an immutable fact that must govern life, if that for some reason makes you as mad as this dude.
> But your point about mesa expecting wayland-client is a very tight binding here.
You don't have to use Mesa's wayland-egl to make EGL work with Wayland, you can easily pass dmabufs by yourself - though this will theoretically be less portable as dmabufs are Linux specific (but practically they're also implemented by various BSDs).
I don't have a program that uses it, so it's not my place to watch mailing lists for it getting deprecated. Basic searching of Github however (what I'd have expected them to do before removing it) reveals 20k files that contain IPPROTO_UDPLITE, and many projects that use it directly. Probably the most renowned is FFmpeg (!!!).
C11 atomics, C11 threads, variable length arrays, safely reading from an inactive union member, designated array initializers, compound struct literals, implicitly converting a void pointer to a typed one, and the list goes on.
reply