I did a basic C demo where I compared this to Tauri/webview:
https://github.com/petabyt/webui-demo
I'm not planning to make any apps in HTML/CSS, but if I had to, WebUI would be my choice.
Web browser as GUI, with your preferred language in the backend
121–130 of 187 posts
Re: Web browser as GUI, with your preferred language in the backend
#122Once your application is complex and reactive enough, has a certain amount of JavaScript code and gets used by enough people, you will inevitably run into compatibility issues. Then you realize you cannot just rely on a random browser version on any platform and think a minimum wrapper works well. That's why Electron bundles a browser and people create applications targeting specific Electron versions.
Most of electron apps have compatible website version.
A website has the same problem as non electron: the browser is always different, so this doesn't seem that dramatic as a downside
Re: Web browser as GUI, with your preferred language in the backend
#123Earlier quoted context omitted.
You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Would you apply the same logic to game optimization? That's it's not the responsibility of game devs, and instead we can shift all the blame to the gpu sdk team?
> You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Not at all. Quite the opposite, in fact. My position is that the browser is fast enough, and that any slowness is exactly the fault of the site devs. You said the browser wasn't fast enough. Previous poster: The reality is that web is fast enough You: No its fuckin not.
> You said the browser wasn't fast enough.
It isn't. Not for what people are trying to make with it.
Case in point: https://krausest.github.io/js-framework-benchmark/2023/table...
The benchmark creates 1000 rows that look like this:
random short text
The fastest of the fastest attempts to do this takes 36 milliseconds to render. For what is essentially static markup with zero complex logic or complex interactions.
In comparison: 1000 actors with complex interaction and behaviour, complex animations and lighting takes 4 milliseconds to render (in total, significanly more than the measley 5-6k static elements on the page): https://youtu.be/kXd0VDZDSks?si=SswSZLNFlRd7adsM&t=586 (at 9:46)
I'm not saying everything should be Unreal Engine. But the web is on the lowest of the lowest end of the spectrum when it comes to performance.
Re: Web browser as GUI, with your preferred language in the backend
#124Earlier quoted context omitted.
You comment shows that you have no practical knowledge of the web ecosystem, and everything you know about it comes from all the blog articles that contributes nothing that's useful in real world use. The reality is that web is fast enough (even with all the tweaks and different approaches of frameworks, libraries etc), and it is the first choice for building a new cross-platform product and for migrating legacy proj…
> The reality is that web is fast enough This. So much this. Yes, there are contrived examples where DOM rendering speed makes a difference, and also a fair amount of real-world crapware (much of it written by companies that should know better) where shitty code continues to hit the DOM unnecessarily hundreds or thousands of times even after the page is allegedly "loaded", but that is not the fault of the DOM.
> hit the DOM unnecessarily hundreds or thousands of times even after the page is allegedly "loaded", but that is not the fault of the DOM.
If DOM was actually performant, this wouldn't be a problem.
Re: Web browser as GUI, with your preferred language in the backend
#125Earlier quoted context omitted.
Native GUIs are fast, but they are not powerful. You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. The web browser gives you a full package with standardized commands to control all those aspects, which is also portable between different implementations. If your rendering needs are limited to a few buttons and a canvas…
> You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. Even Java UIs supported dynamic layouts 20 years ago. C# had a flex box based layout (called flow layout) since 2006.
Worse developer experience and worse style options though
Re: Web browser as GUI, with your preferred language in the backend
#126This is definitely the way to go! The browser is not only good at network requests and sandboxing but comes with the most powerful layouting system and rendering engine. So yes, leveraging browsers just for the front-end of a local-first app is such a good direction to go. Generally apps tend to bundle their own browser runtime to leverage this component. Even the lighter weight electron alternatives tend to either i…
> but comes with the most powerful layouting system and rendering engine If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM. The DOM was originally created to render static text-heavy documents, baking such a limited document-layout system into browsers was a mistake in hindsight. These days, the DOM should be "just another" on-demand loaded Javascript UI framework sitt…
The issue most javascript frameworks try to fix with the DOM is the fact that it is not a language and does not have very good templating support. (Even web components in their plain form are pretty bad; no one wants to write document.appendChild everywhere)
But no one has dethroned HTML and CSS as a fully baked cross platform engine, because it has been battle tested and optimized to death. And not really for lack of trying; UI is just actually very complicated.
Re: Web browser as GUI, with your preferred language in the backend
#127This is definitely the way to go! The browser is not only good at network requests and sandboxing but comes with the most powerful layouting system and rendering engine. So yes, leveraging browsers just for the front-end of a local-first app is such a good direction to go. Generally apps tend to bundle their own browser runtime to leverage this component. Even the lighter weight electron alternatives tend to either i…
Good luck running you GUI from know in a browser in ten years or maybe even five. Not to mention that WebGUIs are slow compared to native ones. https://news.ycombinator.com/item?id=36446933
The problem with native has always been that
* Users expect consistency within their apps, and will complain loudly if platform A has something that platform B has not
* the native platforms’ rendering technologies are so different that you basically need a developer or team dedicated to each platform, with their own test infrastructure, etc.
* even if you can afford to do the above, herding four teams using different technologies to do a coordinated feature release schedule is like herding cats
In any case the native platforms hardly do much better. There are plenty of Windows, Mac, Android, iOS applications from ten years ago that don’t work well today, for instance.
Re: Web browser as GUI, with your preferred language in the backend
#128Earlier quoted context omitted.
> You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. Even Java UIs supported dynamic layouts 20 years ago. C# had a flex box based layout (called flow layout) since 2006.
Worse developer experience and worse style options though
I strongly disagree with that. WinForms is imho very easy to use.
Re: Web browser as GUI, with your preferred language in the backend
#129Earlier quoted context omitted.
> The reality is that web is fast enough This. So much this. Yes, there are contrived examples where DOM rendering speed makes a difference, and also a fair amount of real-world crapware (much of it written by companies that should know better) where shitty code continues to hit the DOM unnecessarily hundreds or thousands of times even after the page is allegedly "loaded", but that is not the fault of the DOM.
> hit the DOM unnecessarily hundreds or thousands of times even after the page is allegedly "loaded", but that is not the fault of the DOM. If DOM was actually performant, this wouldn't be a problem.
I think the misunderstanding is how to hit the DOM. If using static methods the performance cost is a memory cycle, so there can be many wasted steps and it’s still negligible. If access is via query selector then there is a string parse operation which is a few orders of magnitude slower. That does not mean the DOM is slow. Even Lamborghinis are incredibly slow if you never move out of first gear.
Re: Web browser as GUI, with your preferred language in the backend
#130Is there a document describing the architecture and security model?
Edit: There's an image that mentions WebSockets. Is it using the same one-time token approach to security as NeutralinoJS[1]?