Earlier quoted context omitted.
As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.
Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Web browser as GUI, with your preferred language in the backend
21–30 of 187 posts
Re: Web browser as GUI, with your preferred language in the backend
#22Is this basically Tauri, but with zig instead of Rust? Or are there some bigger, inherent differences? (Besides tauri being more mature, that is). Pretty cool
Re: Web browser as GUI, with your preferred language in the backend
#23This 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…
jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore).
The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state.
People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases.
Well, except when it's chosen by cargocult, which is probably most of the cases.
Re: Web browser as GUI, with your preferred language in the backend
#24Earlier quoted context omitted.
As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.
Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re: Web browser as GUI, with your preferred language in the backend
#25Re: Web browser as GUI, with your preferred language in the backend
#26Is this basically Tauri, but with zig instead of Rust? Or are there some bigger, inherent differences? (Besides tauri being more mature, that is). Pretty cool
Kind of but also not. Tauri uses the default on the platform it runs on, this zig-webui project seems to be able to use every major browser and every major platform. For example, Firefox, Chrome and Edge all seem to be available for Windows, Linux and macOS in zig-webui, while Tauri would use a specific engine for a specific platform (by default at least).
Re: Web browser as GUI, with your preferred language in the backend
#27Earlier quoted context omitted.
I am not sure how you come to this conclusion. JS and the DOM are fast. Aside from arithmetic JS is just as fast as Java now and only 2-4x slower than C++. The two big limitations from a pure processing perspective are the garbage collector and massive repaints of large data on large layouts.
> I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great…
My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders.
The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test:
Re: Web browser as GUI, with your preferred language in the backend
#28Earlier quoted context omitted.
Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Synthetic benchmarks for some algorithms have little to do with actual performance of real life applications
Re: Web browser as GUI, with your preferred language in the backend
#29Earlier quoted context omitted.
Kind of but also not. Tauri uses the default on the platform it runs on, this zig-webui project seems to be able to use every major browser and every major platform. For example, Firefox, Chrome and Edge all seem to be available for Windows, Linux and macOS in zig-webui, while Tauri would use a specific engine for a specific platform (by default at least).
Tauri can use a separate browser runtime if required. The use default is a space saving mechanism.
Unless you're referring to using tao and wry as libraries in your own application, but I guess that would be kind of cheating as it's not really a part of Tauri per-se in that case.
Re: Web browser as GUI, with your preferred language in the backend
#30Is it just me or does their logo look very similar to the Waterfox logo?
https://commons.wikimedia.org/wiki/File:Waterfox_logo_2019.p...