81–90 of 187 posts
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…
SABnzbd agrees since 2016.
[flagged]
Is it just me or does their logo look very similar to the Waterfox logo?
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…
Earlier 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.
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 on a fixed size, sure, go native GUI. But if you need to support multiple devices and resolutions, on-the-fly resizing, and layout of multiple complex screen sections, the browser is an unbeatable platform.
If 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".
Earlier quoted context omitted.
I've never worked on big enough project to hit such issues. Could you provide some examples? Not that I doubt your claims, just curious
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…
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 issues, and I'm not concerned about people running my executable 10 years in the future with zero updates.
2. 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. Do you REALLY care about supporting Windows, Mac, and Linux targets? If so, then... why? I would assume that spaceflight would be dramatically more locked-down and spec-targeted. If you do not care about cross-plat, then what's the point of eschewing native frameworks since that's the main reason people go with web-based?
Earlier quoted context omitted.
You comment shows that you have no practical knowledge of the web ecosystem, and everything you know about it comes from all the blog articles that contributes nothing that's useful in real world use. The reality is that web is fast enough (even with all the tweaks and different approaches of frameworks, libraries etc), and it is the first choice for building a new cross-platform product and for migrating legacy proj…
>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…
General layouting/text rendering, etc are not like that, and there is not even a “free” improvement anymore with single-threaded CPU speeds plateauing.
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…
Good luck running you GUI from know in a browser in ten years or maybe even five. Not to mention that WebGUIs are slow compared to native ones. https://news.ycombinator.com/item?id=36446933