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