Web browser as GUI, with your preferred language in the backend • Hacker News Board

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

#161

Post by hellsten » Tue, Jan 02, 2024, 10:26 AM UTC

petabyt wrote: post #121

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.

The fact that the only thing WebUI needs is a web browser is a bit of a problem for me, so I decided to go with Tauri, which uses the system's webview, for my HTML-based application: https://github.com/christianhellsten/ollama-html-ui/

The biggest problem with HTML/CSS apps is that their look and feel are different from native GUIs. This is less of a problem for chat and document-based applications (Slack, Word, etc.), IMO. With Tauri, I can also customize the window and integrate native features to mitigate this. I'm not sure WebUI can do this.

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

#162

Post by austin-cheney » Tue, Jan 02, 2024, 11:42 AM UTC

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…

Sure. Check out my personal website. https://prettydiff.com/

Just open a bunch of windows and you will get to 10k page elements. The primary window shows the page load time in bold red font. The page load time includes all network calls, all initial script execution, state restoration, and graphical rendering. Total load time should always be around 1 second of which most is visual render. The script execution typically takes about 60ms or so but you can see the complete breakdown in the browser performance tab. The CSS could use a lot of clean up. I pulled all of this code from a browser based OS highly distributed OS I am working on.

Also, on that site you can easily check element count in the console using the following custom DOM methods:

    document.getNodesByType(0).length; // all nodes
    document.getNodesByType(1).length; // all elements

EDIT

I just got to 10000 visible elements on the site and everything still loads in about 850ms, give or take 50ms, on my 7 year old desktop. Base load time for a new user on the same machine is about 550ms, so difference in load time is not significant. The real significance is page repaint on a fully loaded page. Drag and drop of any one window is noticeably slower.

To reset state execute the following and refresh the page:

    delete localStorage["gui-state];

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

#163

Post by 59nadir » Tue, Jan 02, 2024, 1:08 PM UTC

codelikeawolf wrote: post #131

StevePerkins wrote: post #88

Earlier quoted context omitted.

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

> We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks.

Is this actually the case? MacOS is in a distinct minority position in desktop/laptop usage as well as areas where people (erroneously) assume it has a significant market share, such as for developers.

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

#164

Post by croes » Tue, Jan 02, 2024, 1:19 PM UTC

h4x0rr wrote: post #156

croes wrote: post #146

Earlier quoted context omitted.

Better user experience and many styling options are counterproductive for the UX.

Better user experience (UX) is counterproductive for the UX... wut

>Worse developer experience and worse style options though reply But better user experience. Also many styling options are counterproductive for the UX.

Now it's more understandable what I tried to say.

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

#165

Post by thisislife2 » Tue, Jan 02, 2024, 1:38 PM UTC

lucasyvas wrote: post #151

I don't understand how this is materially better than Tauri (more generally, frameworks that bind to the platform webview). At least with the platform webview, you can: 1. Have some knowledge about what engine versions were available on what OS versions and make compatibility decisions accordingly. 2. Know that the browser engine is always there. When it comes to trade-offs between "static linking" (Electron) and "dy…

Since I had a similar idea to build something like this, here's my opinion of the pros of this concept:

1. We web developers should always be building to a common specification, and not to the quirks of a particular web engine (which now includes webview quirks too).

2. Javascript is a shitty language. There are other better languages for application development, which allow you harness the full power of the OS platform.

3. It's more in line with unix philosophy - Write programs that do one thing and do it well, write programs to work together and write programs to handle text streams, because that is a universal interface.

4. If an application is built with point 3 in mind, a lot of old codes can be reused and / or given a new UI with this concept.

5. Really tiny as it doesn't increase the size of the application code base by much.

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

#166

Post by T3RMINATED » Tue, Jan 02, 2024, 2:18 PM UTC

[dead]

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

#167

Post by c-hendricks » Tue, Jan 02, 2024, 2:26 PM UTC

croes wrote: post #106

zamadatix wrote: post #90

Earlier quoted context omitted.

Browsers have extremely good backwards compatibility, five or ten years should really not net you any problems. They do carry quite a bit of bloat however, though so do most native toolkits these days.

For old features yes, for new ones it depends. https://github.com/philipwalton/flexbugs And there could be changes because of security concerns like with alert (), prompt() and confirm().

Just FYI, most (all?) of those are in years-old versions of evergreen browsers, no affected versions listed are supported I don't think.

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

#168

Post by 38 » Tue, Jan 02, 2024, 2:36 PM UTC

mgerullis wrote: post #160

38 wrote: post #100

Earlier quoted context omitted.

> Tools like Electron are, essentially, not a choice yeah, they really are. people seem to forget that you can simply start a local web server, and direct the user to visit http://localhost:8080 . here is one in Go, literally 8 lines of code: package main import "net/http" func main() { http.HandleFunc("/", func(w http.ResponseWriter, _ *http.Request) { w.Write([]byte("hello world")) }) http.ListenAndServe(":8080", n…

Wow thanks, I really needed to see a hello world server example

you're welcome

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

#169

Post by codelikeawolf » Tue, Jan 02, 2024, 3:41 PM UTC

59nadir wrote: post #163

codelikeawolf wrote: post #131

Earlier quoted context omitted.

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

> We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks. Is this actually the case? MacOS is in a distinct minority position in desktop/laptop usage as well as areas where people (erroneously) assume it has a significant market share, such as for developers.

I know macOS doesn't have nearly as much market share as Windows, but we've been getting requests for a macOS version for a long time. Considering the current Windows-only version of the software has been around for 20 years, that's a lot of requests.

Our software is very specialized and very expensive. We don't need to sell thousands (or even hundreds) of licenses to justify the effort.

Maybe the aerospace grads wasn't the best example, mainly because I didn't go to school for aerospace. The private sector is full of space startups that need mission planning software. I don't know about you, but every dev job I've had in the past 7 years is full of people using MacBooks or laptops running Linux.

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

#170

Post by Turing_Machine » Tue, Jan 02, 2024, 4:51 PM UTC

troupo wrote: post #140

Turing_Machine wrote: post #136

Earlier quoted context omitted.

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

> 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 should care what you're "tired of".

I'm old enough to remember rants virtually identical to yours when people first started using C rather than hand-tuned assembly language.