the answer could possibly anyone who cares about the footprint of their software (disk, egress, image running size...), not wanting to deal with an entire browser engine (in every aspect)
wpf is still heavily used in industry so that isnt very convincing to me
Also heavily used in the industry are toolkits like sciter, which give you HTML/CSS UIs without an entire browser engine underneath. I suspect those will be eating the remaining market share for 'traditional' toolkits, simply because it's the dominant UI paradigm.
a) being able to deploy same codebase on web and desktop
b) reusing the vast selection of libraries for web
c) tapping the large amount of trained developers.
Sciter fails on a) and b), because it doesn't support even such a basic and widely used feature as CSS flex (they have something similar, but incompatible).
I'm currently working on a Sciter-like solution that does support widely used CSS features such as Flexbox, CSS Grid, Media Queries, CSS Variables, etc. Although we're not planning to ship a JS engine: scripting will be with Rust that compiles to WASM when running on web.
Binary sizes are currently around ~12mb which isn't as good as Sciter but is quite a bit better than Electron.
> being able to deploy same codebase on web and desktop
Desktop UI and Web UI models are so different that in reality you cannot use the same codebase on 100% in both targets.
Web UI uses traditional Web's "endless tape" model where only width is known. This does not really work on desktop where width and height are finite. See this Sciter based app https://notes.sciter.com/ as an example.
> reusing the vast selection of libraries for web
If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
If you set the height of your body element to 100vh (100dvh in the case of iPhones), then the web acts like the desktop in this regard. They’re different since the tooling is different but not because they’re essentially different.
> If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
iframes are very constrained in what you can do, if you’re targeting the web from the start you get the full power of using those libraries beyond the bounds of a single frame.
> Desktop UI and Web UI models are so different that in reality you cannot use the same codebase on 100% in both targets.
I develop an Electron app and the CSS is 100% same on both web and desktop. It's not a "web page", it's an app, which doesn't use the "endless tape" model.
> If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
At that point it seems easier to just use something like Tauri which uses the system browser for all rendering.
Regarding CSS and layout in general, there is a concept of sizers and spacers in wxWidgets that makes layout far easier to grok for the average dev. That being said, it does (sadly) add to code bloat which is where CSS excels, IMO.
Thanks for that! That sounds very sane. I agree that dragging an entire browser engine just to have a desktop app is excessive -- less code is always better.
> In almost 10 years, Sciter UI engine has become the secret weapon of success for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others. The use of HTML/CSS has allowed their UI to stay in touch with modern GUI trends throughout all these years, and will continue to well into the future.
Made me laugh a bit, I usually find antivirus softwares out of touch with good design and really impractical due to that.
i actually am working on greenfield wpf currently but ill be first to admit thats an exception.
windows shop still reach for it heavily in "boring" industry in my experience.
there is a difference between performance critical and sloppy of course. most people default to heavy crap cuz its good enough, or a good fit sometimes, i get that
and this is coming from someone who had to use wpf for software where it ended up too slow in all rendering paths despite MS "trust us bro" and had to render using directx directly. not super uncommon but we were paying the price early (.net fw 3, fuzy wpf text, vibrating layouts, the good days)
No, that‘s very common. I‘m peripherally involved in such a greenfield project, too. And my employer is (very) slowly switching existing WinForms applications to WPF. It‘s the new thing.
(I know that there are a handful newer MS GUI frameworks, but for us it‘s new)
outbound bandwidth on say, "cloud" providers like aws. it can be very expensive. we have been actively reducing our installer sizes, for our costs (edge, cdn, some internal egresses), customer bandwidth, and basically giving a shit and doing a decent job. rare stuff these days
wpf is still heavily used in industry so that isnt very convincing to me