What am I missing here? Web browsers are already GUIs, and any backend with an api supports it.
Web browser as GUI, with your preferred language in the backend
91–100 of 187 posts
Re: Web browser as GUI, with your preferred language in the backend
#92This seems like way too much work when people have been doing things like this in different ways for years (just look at Replit, it runs a full IDE and runs on 4gb Chromebooks).
Maybe I'm misunderstanding this project, but you don't have to reinvent the wheel.
Re: Web browser as GUI, with your preferred language in the backend
#93Earlier 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…
Fixed resolution and size? Manual layout calculations? What was the last native GUI toolkit you used, Win32?
Re: Web browser as GUI, with your preferred language in the backend
#94If I understand correctly, it's WebSocket on top of Embedded C/C++ web server (civetweb). Also, the application must find and launch the installed browser. In my opinion, this part is very fragile. On my system, this function (webui/src/webui.c) : static bool _webui_browser_exist(_webui_window_t * win, size_t browser); cannot find my browser.
Do you have "open URLs with a browswer" turned off in your OS? Because that's the universal way to open "whatever the user has set as their default browser".
> Do you have "open URLs with a browswer" turned off in your OS?
But the application works differently. It needs the browser in kiosk mode, which means it should be able to run the browser binary with specific arguments.
Re: Web browser as GUI, with your preferred language in the backend
#95Earlier 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…
It’s almost like 3d rendering is vertices and shading is an embarrassingly parallel problem which is quite trivial to make faster by throwing more hardware at it. General layouting/text rendering, etc are not like that, and there is not even a “free” improvement anymore with single-threaded CPU speeds plateauing.
Yes, modern computers are just too slow to handle layouting a facebook page, nothing can be done.
Re: Web browser as GUI, with your preferred language in the backend
#96Can't wait for someone to reinvent java applets or flash and we will have gone full circle.
Re: Web browser as GUI, with your preferred language in the backend
#97Earlier 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.
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 have no idea what they are doing.
Re: Web browser as GUI, with your preferred language in the backend
#98What am I missing here? Web browsers are already GUIs, and any backend with an api supports it.
Reading the “How Does it Work?” section of the readme, I interpret it as WebUI being a way of embedding a web view into your existing program, being a sort of proxy for the existing browser of the system.
Re: Web browser as GUI, with your preferred language in the backend
#99I wish that Apple and Microsoft would work together towards making it easier for people to make cross platform desktop applications.
It's largely uneconomical for most companies to develop and maintain separate apps using two different teams with minimally interchangeable skills.
Tools like Electron are, essentially, not a choice
I also wish that wasm would come sooner so we could have more memory and CPU efficient (threaded, statically compiled) web applications (for apps like Slack, messengers, Jira and so forth).
I know people keep saying "wasm is not a replacement for JavaScript" - but perhaps it could be an alternative. I know I'd like to write a web application in Rust but as it stands now there is little advantage to that, particularly without threads and DOM access.
Re: Web browser as GUI, with your preferred language in the backend
#100I wish that Apple and Microsoft would work together towards making it easier for people to make cross platform desktop applications. It's largely uneconomical for most companies to develop and maintain separate apps using two different teams with minimally interchangeable skills. Tools like Electron are, essentially, not a choice I also wish that wasm would come sooner so we could have more memory and CPU efficient (…
> 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", nil)
}