Live data from Hacker News

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

github.com

11–20 of 187 posts

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

#11
post #9

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…

> but comes with the most powerful layouting system and rendering engine.

It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.

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

#13
post #11
post #9

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…

> but comes with the most powerful layouting system and rendering engine. It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.

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.

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

#14
post #11

Earlier quoted context omitted.

> but comes with the most powerful layouting system and rendering engine. It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.

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.

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

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

#15
post #3

Offtopic, but: why do people insist that Edge is a meaningfully different browser from Chrome? I'm not even going to ask about the table at the end that lists that it supports exactly two different browsers while listing 10.

Mostly because what it does differently besides the rendering engine, but yeah it is still Chrome.

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

#16
post #14

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.

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

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

#17
post #11

Earlier quoted context omitted.

> but comes with the most powerful layouting system and rendering engine. It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.

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.

> 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 lengths to touch DOM as little as possible. A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s.

It's a system designed to render a page of text with a couple of images in one rendering pass at the core, and no amount of hacks on top of it will make it a high-perfromant layout and rednering engine.

> Aside from arithmetic JS is just as fast as Java now

This has nothing to do with either layout or rendering

> The two big limitations from a pure processing perspective are the garbage collector

Has nothing to do with either layout or rendering

> massive repaints of large data on large layouts.

Where "large data" is measly thousands of elements.

Massive repaints in DOM happen basiclly on any and all layouts and layout changes. And these changes are triggered by almost anything that happens in the DOM.

There's a reason why any reasonable animation you can reliably do with DOM is to literally rip the element out of the layout context and render it independently because "the most powerful layout and re-rendering engine" cannot cope with re-calculating and re-rendering the layout for the entire page when you move elements around.

Edit.

Slightly more on this:

- Rendering performance https://web.dev/articles/rendering-performance

- Linked article, Stick to Compositor-Only Properties and Manage Layer Count https://web.dev/articles/stick-to-compositor-only-properties...

From the last article: there are only two properties that can be handled by the compositor alone, all others trigger either a re-flow+re-paint or a re-paint.

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

#18
post #9

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…

> 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 sitting on top of a handful lower level rendering APIs.

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

#19
post #9

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.
Post reply on HN