Hi Felix,
Maybe this is vaguely related, but now that you are exploring
alternative paths to HTML+web you could consider Hypermedia Systems[1]
like HTMX[2] or Data-star[3].
[1] https://hypermedia.systems/
[2] https://htmx.org/
[3] https://data-star.dev/
Of course you're a pretty fluent programmer of JS and TS, and while none
of those frameworks are anti-JS, for me at least has been a breath of
fresh air to see alternatives to develop web interactive interfaces
without all the incidental complexity of the JS framework of the week
and JS in general (I "just" needed to wait a couple of decades to have a
sensible alternative ;-) ).
Now that you're in your exploring phase, it maybe worth to take a look
at these alternative approaches that do not virtualize the DOM or use
JSON as a primary format and instead do things in the server with the
"old and good" hypermedia approach.
Cheers,
Offray
On 9/13/25 23:23, Félix wrote:
After doing a few experiments with HTML+web based Leo outline viewers
(and realizing that for a relatively large tree, the rendering needs
virtualization of a subset of the visible nodes only, and that having
DOM elements for ALL nodes of the outline destroys performance!)
I've decided to put docutils-ts on the side for the next few days:
I'll be working on another javascript version of Leo that will be web
based, but opposite to LeoJS it is NOT embedded in vscode, nor will it
edit files directly on github.
It will instead allow for usage with local files on a computer or even
even imported directly from a github repo or anywhere else, but will
save/write files to local files on the computer.
But since being web based (i.e. in the browser) it needs permission
for individual file access.
This implies that after opening a Leo file, to then import or write
external files it will be required to 'right-click' on a node and
choose 'write external file' / 'Refresh-from-disk' on any @<file> node
you want refreshed / written. (it would not be automatic upon
save/load of an outline)
(maybe I can get the permission per folder instead - we'll see)
For now It's at the tech demo stage: I've not yet reused LeoJS
implementations of the proper classes (vnodes, positions, commander,
etc.) It' just a dummy/dumbed-down acyclic graph engine under the hood
while I finalyse the GUI implementation, keyboard+mouse interactions.
(It will of course use the same LeoJS classes sources after that's done)
What's the main benefit ? -> That GUI is quick and responsive like the
original Leo!
... and it's a cool weekend project! /(link and github repo coming soon)/
Félix
--
You received this message because you are subscribed to the Google
Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/leo-editor/4db4cc9b-19c8-41be-a43d-0e9b1a5746f6n%40googlegroups.com
<https://groups.google.com/d/msgid/leo-editor/4db4cc9b-19c8-41be-a43d-0e9b1a5746f6n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/leo-editor/659ccacf-b1c8-41f7-ab58-08fd713430a2%40riseup.net.
