Re: Emacs design and architecture

[Dmitry Gutov <dmitry@gutov.dev>]

On 16/09/2023 14:59, Sebastian Miele wrote:
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> Date: Sat, 2023-09-16 14:02 +0300
>>
>> On 16/09/2023 11:41, Gerd Möllmann wrote:
>>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>>>
>>>> Microsoft also has a project that could be tried as a base (MIT
>>>> Licensed):https://github.com/microsoft/vscode-webview-ui-toolkit. Or
>>>> one could just use its internals for inspiration, because "Visual
>>>> Studio Code design language" is probably not one of our goals.
>>> Looks like Javascript/Typescript to me?
>>
>> Yep. But any attempt to reuse an existing browser engine would likely
>> have to deal with JavaScript on some level, I think.
> 
> In the foreseeable future, probably not.  I do not know the details.
> But there is WebAssembly.  In order to access the DOM and possibly other
> browser API, at least a few months ago, it was still necessary to
> somehow go through JS.  But it is very unlikely that that will not
> change in a not too distant future.  There are many developements going
> on in that area that (will) make implementing further languages on top
> of WebAssembly easier and the languages and APIs interoperable with less
> and less overhead, and more and more common management (including GC).
> I have only a very superficial view.  But in the last months I gained
> the impression, that WebAssembly and standards and stuff around it
> probably will become a very versatile and interoperable VM
> infrastracture, including "WebAssamble-native" APIs to almost anything.

Wasm or JS, with this approach it seems like we'd need to compile Lisp 
to JS/WA, or use FFI, or (probably) both.

None of this is a deal-breaker for an experimental port/GUI, but it 
definitely doesn't make it a weekend project.

> What may be interesting in that direction, too, are experimental browser
> engines like Servo.  In the last months I read somewhere (and by people
> contributing to it) that Servo more or less explicitly has the aim to
> allow to take/use only parts of it, and to have as clear and
> approachable source code as possible.  A next generation Emacs probably
> would not need or even want all that a web browser has to support.  It
> could concentrate on a subset of web-stuff that already is known to work
> very well and efficiently.

Looking at these, it doesn't sound like it's easy to replace the current 
JS engine (Firefox's SpiderMonkey) with something else. Although to make 
it run Lisp would be pretty cool.

https://github.com/servo/servo/discussions/29100
https://github.com/servo/servo/discussions/25419

The comments in the latter led me to this, though:

https://github.com/fschutt/azul (Rust desktop GUI framework based on 
WebRender with no JavaScript involved, looks like).