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

51–60 of 187 posts

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

#51

Post by troupo »

diggan wrote: post #23
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…

> If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore). The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state. People don't chose…

Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark

Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.

And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?

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

#52

Post by Xeamek »

d3w4s9 wrote: post #42

Once your application is complex and reactive enough, has a certain amount of JavaScript code and gets used by enough people, you will inevitably run into compatibility issues. Then you realize you cannot just rely on a random browser version on any platform and think a minimum wrapper works well. That's why Electron bundles a browser and people create applications targeting specific Electron versions.

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

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

#53

Post by Xeamek »

d3w4s9 wrote: post #37
troupo wrote: post #17

Earlier quoted context omitted.

> I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great…

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 because some front dev crambed some 'cool' paralax effect onto it, or because facebook, (who literally invented react) can't handle it well enough to not make memory leaks everywhere.

Did Usability of the web moved forward since few years ago? Sure. But compared to what computers can actually do, it's insane how bad things are nowadays

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

#54

Post by ksec »

Xeamek wrote: post #20

Is this basically Tauri, but with zig instead of Rust? Or are there some bigger, inherent differences? (Besides tauri being more mature, that is). Pretty cool

>Is this basically Tauri, but with zig instead of Rust?

WebUI is language agnostic so I guess Tauri but not limited to Rust would be a better description.

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

#55

Post by diggan »

troupo wrote: post #51
diggan wrote: post #23

Earlier quoted context omitted.

> If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore). The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state. People don't chose…

Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipu…

Which popular frontend framework advertise their DOM mutation speed on their frontpage exactly? Most frontend frameworks I come across nowadays advertise their developer experience and their features, not their DOM mutation speed.

And when I say state manipulation I'm not talking about performance, I'm talking about the architecture and people working with the codebase. No one cares about state manipulation performance because as you said, it's a solved problem.

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

#56

Post by austin-cheney »

Xeamek wrote: post #53
d3w4s9 wrote: post #37

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…

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.

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

#57

Post by austin-cheney »

troupo wrote: post #49
d3w4s9 wrote: post #37

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…

> You comment shows that you have no practical knowledge of the web ecosystem You're talking to a person with 20 years of frontend development experience. But sure, do go on with your assumptions. Also, no idea what "web ecosystem" has to do with the patently false claim of " the most powerful layouting system and rendering engine.", but do go on > The reality is that web is fast enough I never claimed it wasn't. But…

I have also been writing for the web for over 20 years. This doesn't really mean anything though. That is why measures are all that matters. Bad measures are still monumentally better than no measures at all.

The sad reality is that most people writing for the web today cannot do so without a framework. They have no idea how the layers underneath actually work. If you want to understand performance you must measure for it in multiple different ways and have something meaningful to compare it to. All modern browsers provide fantastic performance measuring tools in their developer tools. Its how I got my OS GUI (in a browser) to execute as fast as within 60ms of page load.

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

#58

Post by pjmlp »

austin-cheney wrote: post #16
pjmlp wrote: post #14

Earlier quoted context omitted.

As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.

Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I only see random Java in synthetic benchmarks, without testing all variations of JIT and AOT compilers available throughout the ecosystem.

OpenJDK, GraalVM, OpenJ9, Azul, PTC, Aicas, ART, JikesRVM,....

Not to mention the optimizations that a dynamic language like JavaScript will never be able to take advantage of.

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

#59

Post by Xeamek »

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.

10 billions is a bit much, but yes

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

#60

Post by codelikeawolf »

Xeamek wrote: post #52
d3w4s9 wrote: post #42

Once your application is complex and reactive enough, has a certain amount of JavaScript code and gets used by enough people, you will inevitably run into compatibility issues. Then you realize you cannot just rely on a random browser version on any platform and think a minimum wrapper works well. That's why Electron bundles a browser and people create applications targeting specific Electron versions.

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 provides over other libs that use OS webview (e.g. Tauri) is I can use whichever newer features I want (e.g. CSS nesting) as long as they're supported by whichever version of Chrome Electron ships with.

That being said, I get why Electron gets a lot of hate. I've been developing Electron apps professionally for the last 4 years. I can't use VS Code because I'm _accutely_ aware that it's Electron. I think 80% of Electron apps in the wild should probably just run in the browser. If you don't need to do stuff like access the filesystem, spawn processes, or interact with the OS in a way that the browser doesn't provide, you should probably just stick with the web app.

Post reply on HN