MIME-Version: 1.0
Date: Wed, 24 Feb 2021 12:30:29 +0100
From: Amirouche <amirouche@hyper.dev>
To: Timmy Douglas <mail@timmydouglas.com>
Cc: ~sircmpwn/public-inbox@lists.sr.ht
Subject: Re: electron alternatives: wayland-like widget toolkits/GUI
 frameworks
In-Reply-To: <87r1l6i0f2.fsf@timmydouglas.com>
References: <871rd7icvp.fsf@timmydouglas.com>
 <7f1dd619d56936818a7e466da3409b72@hyper.dev>
 <87r1l6i0f2.fsf@timmydouglas.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <8009f053958f9907cb9eacc63073d54d@hyper.dev>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2021-02-24 04:56, Timmy Douglas wrote:
> Amirouche <amirouche@hyper.dev> writes:
> 
>> On 2021-02-23 06:14, Timmy Douglas wrote:
>>> 1. Has anyone created a realistic alternative to HTML/CSS--maybe a
>>> binary DOM that has a reasonable API for manipulation? I supposed 
>>> it'd
>>> also need some sort of rendering engine
>>> 
>> 
>> By DOM, you mean the HTML serialization or the tree-like structure 
>> that
>> is in memory?
> 
> well it'd probably be both--you'd need some sort of serialization 
> format
> (HTML today) to materialize the one you actually operate on.

HTML in the case of webdev is useful to exchange the information about 
the DOM between the frontend
and backend. Where the DOM represent the information required to do the 
rendering.
In fact, that HTML serialzation is not necessary in Single Page 
Application that
exchange JSON with the backend, and build the DOM fully browser side. 
Even more so
HTML is useless for rendering purpose in a desktop application (except 
for debugging).

> But if you were going to create a GUI toolkit around it, you probably 
> wouldn't want
> to spend time parsing HTML unless you made that choice to reuse other 
> code.

Yes. Qt or GTK can re-use existing components / widgets without a text 
or binary serialization.

> 
>> I think HTML/CSS even DOM API are nice, but it is a long way to get
>> there.
>> And not a lot of people have the time or energy to dive into
>> alternatives approaches.
>> 
>> GUI without HTML/CSS is more powerful than what the browser can do. I
>> figured that while trying to build a text editor.
> 
> If I was going to build a simple text editor, I think rendering the 
> view
> with HTML/a couple of absolute-positioned preformatted divs would be
> easier than writing my own renderer on a canvas-like object, if that
> makes sense.


I was not sure it was the case on your side, but basically me and
most web developers have a skewed vision of what GUI dev really is.

At the bottom of the GUI stack there is a bytes array, such as 'x'
times 'y' times 24 bits for 8 bits per RGB components.

At the top level there is some kind of representation such as the DOM.
In between there is a mess... What the representation is and how to 
translate
that into bytes or bits (what I call the 'mess') is up for engineering.

Maybe the case of a text editor is very peculiar, but I think similar
problems arise with diagramming tools, visual programming, and prolly 
others.

In the case of the text editor, there is a very specific datastructure
to represent the text that is edited (immutable array of array, rope,
balanced binary tree, fingertree..). When one thinks in term of browser 
GUI
and putting aside the canvas, one necessarily need to serialize that 
datastructure
not into HTML text, but into DOM text nodes, and that is very costly,
because of back and forth conversion when you consider key events, 
selections etc...

DOM does not accept arbitrary data nodes or even custom text node 
following a specific
interface or protocol. Similarly, in the case of diagramming tool, one 
need
to convert back and forth (hence copy much data) between the best 
diagram data structure
and the "render nodes" that are svg. Whereas in a desktop GUI, you can 
use
the same data structure for doing updates on events and rendering.

I did not check, but last time I read about it Atom editor use HTML 
canvas.

tl;dr: browsers are a framework that need to do trade-offs,
        and force you to think in a very specific narrow way.

-- 
Amirouche ~ https://hyper.dev