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

131–140 of 187 posts

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

#131

Post by codelikeawolf »

StevePerkins wrote: post #88
codelikeawolf wrote: post #60

Earlier quoted context omitted.

I can provide an example. I work on spaceflight mission planning software that runs in Electron. We're using a lot of cutting edge Web APIs like WebGPU, SharedWorker, OffscreenCanvas, and Atomics. There's no way we would be able to ship something that would reliably work cross-platform if we used the OS's webview or whichever browser they prefer. There's other considerations as well. The biggest advantage Electron pr…

> I work on spaceflight mission planning software... Yeahhhhhh. The thing is, though, I see two classes of desktop GUI applications: 1. The kind that are simple and casual enough to build around a web-based framework. In which case, I'd rather rely on the system native browser rather than ship my own entire browser in my distributable. Because I'm not doing anything complex enough to worry about cross-compatibility i…

> The kind which don't fit the criteria above, and therefore really just ought to be honest-to-God native desktop GUI applications. I'm rather astounded that spaceflight mission planning software doesn't fall under this category.

Our team is very small, so we don't have the budget or resources to make a native version for each platform. I think this is why most companies go with Electron. The browser/Web APIs abstract a lot of the platform-specific stuff away (at the cost of missing some functionality), which means you can run pretty lean.

> Do you REALLY care about supporting Windows, Mac, and Linux targets? If so, then... why?

Yes, we really do care. The current version of our software only runs on Windows, just like our main competitor. We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks. We really only have one competitor and are pretty close to having feature parity with their product, so the ability to run our software on 3 platforms is going to be a pretty big feather in our cap.

> I would assume that spaceflight would be dramatically more locked-down and spec-targeted

To some extent, yes, but probably not as much as you might think.

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

#132

Post by troupo »

TuringTest wrote: post #85
croes wrote: post #77

Earlier quoted context omitted.

Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.

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…

Qt had what is essentially flexbox in early 2000s.

Native apps have had to deal with dynamic sizes and layouts since the idea of resizing windows to arbitrary sizes became a thing. So, since 1980s?

> on-the-fly resizing

Which web tech famously cannot do with any efficiency

> and layout of multiple complex screen sections

What complex screen sections? This is a complex screen section: https://x.com/dmitriid/status/1424052288205856773

The web does not (and cannot) have "complex screen sections". It doesn't have the capacity for it.

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

#133

Post by c-hendricks »

I'm seeing lots of comparisons to Tauri, which is exciting because while I am using Tauri to build an app, I'm not actually that enthusiastic about Rust.

But I'm feeling a lot of comparisons are really just comparing the most straight forward, load HTML + JS in a webview, without comparing other things like:

- (Auto) Updating.

- Embedding other files (and actually distribute them).

- Plugins (I guess plugins can be made for the various language bindings and implemented via event handlers).

- Disabling Edge's annoyances (IE it looks like Edge's menu that shows up when selecting text is happening, I guess its image hover thing is there, and maybe more annoyances).

- The menu on macOS is the menu of the launched browser.

This does definitely seem to have its uses and I'll keep an eye on it.

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

#134

Post by ale42 »

austin-cheney wrote: post #97
croes wrote: post #77

Earlier quoted context omitted.

Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.

Yeah... JS and the DOM are incredibly fast, but that does not applications written for that platform are fast. Many JS developers have absolutely no idea how these technologies work and are reliant upon several layers of abstractions that are each progressively slower than the next. As an analogy crypto coin in theory is a good idea, but its rife with fraud because most people playing with crypto are speculators that…

You're totally right about the layers of abstraction... still, JS and DOM could be incredibly fast (and in some way, they are, sa there are huge optimizations behind for that to work as well), but they remain slower and more energy hungry than (almost) any native interface, even if you leave away all the layers of abstractions.

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

#135

Post by ale42 »

austin-cheney wrote: post #56
Xeamek wrote: post #53

Earlier quoted context omitted.

>The reality is that web is fast enough No its fuckin not. We have devices running literally billions operations per second, orders of magnitude faster then what we had just few years ago, yet they struggle with rendering websites which comes down to presenting some good looking text. It's insane how my pc can compute entire 3d world with millions of triangles, 120 times a second, but it lags when I open few websites…

With a modern CPU and DDR5 memory you should be capable of running no slower than 10 billion DOM operations per second in Firefox. Usability is not performance.

How much electricity is getting wasted into this, worldwide?

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

#136

Post by Turing_Machine »

troupo wrote: post #123
Turing_Machine wrote: post #108

Earlier quoted context omitted.

> 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 So, less than a 10k elements in total. The fastest of the fastest attempts to do this takes 36 milliseconds to render. For what is essentially static markup with zero co…

> 36 milliseconds to render.

36 ms is a very small amount of time (faster than the rod flicker fusion frequency, though not the cones), and 10K elements is far more elements than even a complex web page is likely to have.

Can you give me some examples of real-world web pages that have 10K DOM elements on them, or anything like it? Running document.querySelectorAll('*').length on my personal amazon.com home page gives 3163 (obviously this is going to vary somewhat for different people), and amazon.com's front page is pretty damned complex.

> I'm not saying everything should be Unreal Engine.

I'm saying that almost nothing needs to be Unreal Engine. You are confusing "fast" with "fast enough".

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

#137

Post by troupo »

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

Earlier quoted context omitted.

> 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.

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 browser, please find some resources that talk about what is actually happening in the browser?

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

#138

Post by Turing_Machine »

troupo wrote: post #124
Turing_Machine wrote: post #73

Earlier 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.

If people could actually write code, it also wouldn't be a problem.

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

#139

Post by codelikeawolf »

Xeamek wrote: post #65
codelikeawolf wrote: post #60

Earlier quoted context omitted.

I can provide an example. I work on spaceflight mission planning software that runs in Electron. We're using a lot of cutting edge Web APIs like WebGPU, SharedWorker, OffscreenCanvas, and Atomics. There's no way we would be able to ship something that would reliably work cross-platform if we used the OS's webview or whichever browser they prefer. There's other considerations as well. The biggest advantage Electron pr…

Fair example, although from what You are saying it looks more like its about using features that might not yet be available in os webview. But the parent post, as well as 'other stories' I see sometimes talk about using certain, 'frozen', older version to ensure compatibility, essentially stating that new releases break some stuff. So i was more asking about such cases

> Fair example, although from what You are saying it looks more like its about using features that might not yet be available in os webview.

Right, which is what the parent comment explicitly stated about compatibility issues. The issues are with trying to use newer browser features that might not be available in the OS webview.

> But the parent post, as well as 'other stories' I see sometimes talk about using certain, 'frozen', older version to ensure compatibility, essentially stating that new releases break some stuff.

I'm a little confused here. Are you talking about an older version of the browser or an older version of your application? TC39 and browser vendors go to great lengths to ensure backwards compatibility. I've never had a web app break on a new version of a browser.

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

#140

Post by troupo »

Turing_Machine wrote: post #136
troupo wrote: post #123

Earlier quoted context omitted.

> 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 So, less than a 10k elements in total. The fastest of the fastest attempts to do this takes 36 milliseconds to render. For what is essentially static markup with zero co…

> 36 milliseconds to render. 36 ms is a very small amount of time (faster than the rod flicker fusion frequency, though not the cones), and 10K elements is far more elements than even a complex web page is likely to have. Can you give me some examples of real-world web pages that have 10K DOM elements on them, or anything like it? Running document.querySelectorAll('*').length on my personal amazon.com home page gives…

> 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 just DOM being slow).

Gven that it takes that much time to render a static page with a number of elements that shouldn't even register by a clock, you run into hundreds of other problems: layout shifts in DOM are extremelyexpensive, avoid them; animations in the DOM are extremely expensive, avoid them; we can't re-render fast enough when the winow is dynamically resized, so there's tearing; we can't update the DOM fast enough because updates are extremely slow, so we fight the DOM and come up with crazier and crazier solutions to touch it as little as possible; and so on and so forth.

On the same machine a game engine re-renders the entire world with thousands or millions of objects with complex computations and interactions from scratch in under 10ms.

> You are confusing "fast" with "fast enough".

I'm not. 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.

And then hear the idiocy of "it's the most advanced rendering and layout engine" or "string parsing is so much slower than DOM operations" and other claims by people who have no idea what they are talking about.

Edit: your amazing "fast enough" is known to consume 20% of CPU just to display an animated emoji: https://twitter.com/dmitriid/status/1486364312910368769

Post reply on HN