Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web browser as GUI, with your preferred language in the backend

github.com

Post reply on HN
Print view View original

171–180 of 187 posts

Re: Web browser as GUI, with your preferred language in the backend

#171

Post by Xeamek »

Turing_Machine wrote: post #170
troupo wrote: post #140

Earlier quoted context omitted.

> 36 ms is a very small amount of time To render less than 10k objects on a screen given the current state of hardware? It's an eternity. The problem is, these things compound . That is why "my page doesn't have 10k elements", but for some reason Google gave up and now calls "2.4 seconds to render content is fast, actually": https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is, of course more than…

> To render less than 10k objects on a screen given the current state of hardware? It's an eternity. When it's so fast that a human being doesn't even perceive it, it's not an "eternity". In fact, it doesn't matter. At all. > I'm tired of your "fast enoughs" that cannot reliably render a static web page without consuming more time and about as many resources as a modern video game. That's nice, but I'm not sure why I…

>DOM is efficient >No it's not, here is the data >something something it doesn't matter because it's fast enough.

So you agree that the DOM is slow? Or, by this logic, can I call any terrible code 'efficient', because if I run it on modern hardware it will still be faster than 'good' code run on machines from 20 yrs ago?

But also, it's not like all this inefficiency is free; every millisecond that is spent running inefficient code requires power. Multiply that by trillions of operations computers are doing every day, multiply that by billions of computers worldwide and we end up with waste of resources that literally change the planet. Not to mention the e-waste of all the hardware we force out of the usage "because it's too slow"

Re: Web browser as GUI, with your preferred language in the backend

#172

Post by immibis »

flohofwoe wrote: post #18
lewisjoe wrote: post #9

This 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…

I thought flexbox solved this.

Re: Web browser as GUI, with your preferred language in the backend

#173

Post by switchbak »

bobthepanda wrote: post #126
flohofwoe wrote: post #18

Earlier quoted context omitted.

> 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 o…

"UI is just actually very complicated" ... yeah, it's not like we've been developing UIs for decades prior to creating them in web tech.

I think it's unfortunate that there's a generation that just takes that statement as a given, without any deeper understanding of the tech that underlies such things. UIs can be simple, they can also be complicated. Much of that depends on the sophistication and flexibility of the layout approaches you provide.

Building UIs on top of a DOM, especially with layout controlled by this CSS monster - well yes, THAT's bound to be complicated. Unfortunately it's in this awkward zone where the implementation is complex, but it doesn't provide the corresponding payoff for the developer experience.

Re: Web browser as GUI, with your preferred language in the backend

#174

Post by austin-cheney »

troupo wrote: post #137
austin-cheney wrote: post #129

Earlier quoted context omitted.

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.

String parsing is negligible compared to the speed of the DOM which is glacially slow: https://news.ycombinator.com/item?id=38835920 Come on, people, make an effort to learn how insanely fast computers are, and how insanely inefficient our software is. String parsing can be done at gigabytes per second : https://github.com/simdjson/simdjson If you think that string parsing of selectors is the slowest operation in the…

That is not at all correct. That is why we measure things.

https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

For those of us who understand how these things work the incredibly slow performance of query selections is not surprising. What is interesting, though, is comparing the numbers between difference browsers.

Re: Web browser as GUI, with your preferred language in the backend

#175

Post by mthoms »

zija wrote: post #31
twen_ty wrote: post #26

Earlier quoted context omitted.

Tauri can use a separate browser runtime if required. The use default is a space saving mechanism.

They are working on servo implementation, but it's long time to go. Tauri has problem on Linux, webkit2gtk has lower performance etc. I know I have problems with three.js, others with svg Additionaly communication speed between backend and frontend is bottleneck (serialisation to string) and you must use custom protocols to effectively communicate/send large data, zero copy binary protocol isn't possible at the momen…

I've been looking into Tauri and I'm curious if you could expand on the known problems with three.js and svg? Thanks.

Re: Web browser as GUI, with your preferred language in the backend

#176

Post by gneuromante »

p_l wrote: post #155

Reminds me of the approach of CLOG (Common Lisp Omnificent Gui[1]) and its ancestor GNOGA (The GNU Omnificent GUI for Ada[2]). They also integrate basic components and even graphical UI editor (at least for CLOG), so you can essentially develop the whole thing from inside CL or Ada [1] https://github.com/rabbibotton/clog [2] https://github.com/alire-project/gnoga

The active development of GNOGA occurs in https://github.com/Blady-Com/gnoga

Don't know the relation to the official repository, which might still be: https://sourceforge.net/projects/gnoga/ but Blady-Com is the current most active developer in both.

Re: Web browser as GUI, with your preferred language in the backend

#177

Post by thecodewindow »

hdaz0017 wrote: post #32
lloydjones wrote: post #25

FYI: The website (webui.me) has a TLS / certificate issue and can only be viewed in Chrome (iPhone) after accepting the unsafe warning.

Cert expired -- Sunday, 24 December 2023 at 23:07:23

It's working now!

Re: Web browser as GUI, with your preferred language in the backend

#178

Post by thecodewindow »

o11c wrote: post #141

"Your preferred language" except for the frontend-touching parts you have to write in JS yourself, of course. UI really can't be moved entirely to the backend.

I guess you forgot the project name, "WEB - UI", So, non-web developers (HTML/CSS/JS) should not use this library or WebView based libraries either.
Post reply on HN