I added a new debug tool which shows how my system is traversing the entities in search of a “focusable” entity that will properly handle the “Arrow Down” exit event. The first video is with broken behavior, where it can’t find an entity that can handle “focus” and the second video shows correct behavior.

I realize this may be passé, and folks love to kick JS, but have you considered plain JS, with no build system, targeting the browser?

It’s pretty easy to target oooooold apis and get cross platform support. Everything I make in my hobby programming is this, pretty much.

Like, all of these experiments, toys, tools, and games are plain Jane JS, written in a text editor and sourced from a static file server. I have no external deps outside of the browser itself.

Yeah, JS has definitely been on my radar in the latter half of 2024 in a way it wasn't back in 2023.

What would be the best place to start for learning how to write cross-browser, cross-device, dependency-free Javascript?

I should try recreating lines.love or something in html+javascript. Just create a new canvas when I want to draw. No need to invent line-wrapping, so it'll hopefully be quick.

Let me noodle for a bit about some learning resources. Cross browser is essentially something you get for free these days as long as you don’t reach for cutting edge APIs. I try to keep my code as boring as possible to achieve this.

Yeah, I fear I just lack the instinct for what is cutting-edge that I have developed on other stacks.

Thinking about it some more, stuff like my doodle experiment may not be a good fit for html+js, not without reinventing textareas in Javascript (something I don't want to ever go near, CodeMirror included). Any sort of syntax highlighting is also excluded because of that, I think. Historically I've done a certain amount of stuff with text, and it feels awkward to slice it between html or canvas.. but maybe it's for the best to move on to new kinds of projects.

What I’d suggest is looking at what you get from the browser, like the canvas, and textareas, and then see how you can work within those bounds.

Also, happy to help if you’ve got questions!

For staying compatible between browsers: I use dev docs.io and install both JavaScript as well as WebAPI docs (for offline usage). Then you have access to MDN docs for the browser stuff. At the bottom of each page you have a table with compatibility info.

@Eli Mellen I'd be interested in learning resources as well for working in plain JS. Although I suspect that there is no solution for what is a fundamental issue for me: nearly all code I want to write needs read and write access to my computer's file system.

Konrad Hinsen aside: I am trying to understand the issue mentioned of writing to local disk. On the surface, it sounds like the phrase "plain JS" - in this case - is a code-phrase for "app running in the browser". Apps running in the browser can't write to disk. Apps running locally can (i.e. on the command line, etc.). JS, HTML, CSS are the "assembly language" for making and operating GUIs in browsers. It sounds like all that's wanted is to create local apps that scribble on the disk, while creating GUIs in browsers. Common Lisp (etc.) gives you all of the local-ness needed and allows programs to write to disk. CLOG takes the approach of running a tiny JS evaluator in a browser taking GUI "assembly" commands through a websocket. CLOG is - in essence - a transformer between CL and GUIs-in-browsers. CLOG lets you use CL to do whatever you want locally, while providing a transpiler from CLOG's class hierarchy into commands that form actions on the browser's window (is this like a modernized version of X11?). I haven't tried yet, but, I think that CLOG's tiny in-browser evaluator could be used by apps written in any machine-local programming language. CLOG's class hierarchy shields one from having to learn the niggly details of operating browser-based GUIs. Likewise, DSLs created for this purpose might do the same. [advertisement for t2t and OhmJS omitted].

CLOG looks great, but I believe anything that transpiles to something that runs on a browser will inherit the browser's sandboxing restrictions against file system operations.

I've not been keeping up, though. Perhaps there are new APIs now for file:// URLs. I've never understood the threat model that leaves browsers insisting on sandboxing those.

I see now that @Eli Mellen's pico-cam project demonstrates downloading local files. It downloads images, but it should be possible to use the same techniques to download itself.

I can also open html files to my Android phone, though the flow is a little weird. It can't use Firefox for some reason, forces me to use one of the (many!) other browsers installed on my device. Hopefully this also works in some form on iOS.

The omnipresent danger with mobile devices is that you end up with a minority workflow that is at the mercy of the OS company. This is true of both offline web-browser flows as well as side-loading native apps. Static js hosted remotely -- as demonstrated by pico-cam -- may well be the sweet spot of durability here.

The importance of this - to me - is the idea of thinking of a GUI as an attached device, like a postscript printer. The GUI engine has its own scripting language (like PS, or HP's PCL). Programmers can still write in their language-of-choice, but, need to send commands with appropriate syntax (aka "API") to the attached device. Local commands still work, but anything sent to the GUI engine must follow browser sand-boxing rules (i.e. don't send requests for file access to the browser).

That approach certainly buys you the "G", but feels like a substantial restriction on the "UI"? Any interaction you provide needs to be on the paper emitted by the PostScript printer, in this analogy. But the printer can't send anything back to the computer.

@Erik Stel docs.io redirects to Microsoft now 😕

sliding in to mention that there is a filesystem API, but it comes with a few caveats, but it is 100% there

Rich communication flows in both directions. You get "G" and "UI". I don't actually use CLOG, I just troll things like this to see what ideas can be stolen. Somewhere, I saw a full-blown IDE written in CLOG. The GUI portion ran in a browser, the rest of the IDE stuff ran locally on the server in the language-of-choice. The first time I saw this idea was several years ago. Someone at a Torlisp meeting demo'd turning a phone into an I/O device. The app stayed on the server, just enough code was sent to the phone to display a keypad and to tell it "when someone pushes a key, send me a message and tell me which key was pressed". That demo was abandoned because CLOG already does all of that.

Konrad Hinsen and Kartik Agaram I pulled together a teeny tiny demo that uses the filesystem API -- defo a lot of caveats (namely that it doesn't seem to be available outside of Chromium browsers right now...) but I included a fall back in the demo so it'll work anywhere.

Also, if you wanna test it on a real PNG here is one of those, 😄

Paul Tarvydas Kartik Agaram I use CLOG every day, it's my main GUI provider for Common Lisp. At its core, it provides local proxy objects for the browser's DOM, maintaining a Websocket connection to keep both sides synchronized. On top of that core, CLOG provides a nice GUI construction toolkit. There are IDEs and even a full desktop environment implemented via CLOG.

Treating a browser as an external device with CLOG as the API is indeed a good mental model.

The reason I am interested in something browser-only (that's indeed what I meant implicitly with "plain JS", as I wouldn't bother with JS at all except for the browser) is deployment simplicity, especially for friends and family. I routinely hack personal tools in Lisp with CLOG, and for me that's fine. But I am not going to explain to my wife how to set up a Common Lisp environment, just to use one of my personal tools. And yet, there are personal tools I'd like to share with her, such us analysis/visualization for our bank accounts.

@Eli Mellen Thanks a lot! I'll see if I can figure out how it works. Right now I am on a machine with only one graphical browser (i.e. not counting eww in Emacs): Librewolf, a fork of Firefox. With that browser, I can load a PNG and save the edited version, but it can't do in-place modifications. But I have something Chromium-based (Brave) elsewhere for testing.

Paul Tarvydas My goals (stated before but not in this thread) are 1) cross-platform apps that are 2) easy to maintain and 3) can be operated offline. Depending on a server can never satisfy all 3, I think, no matter how you arrange things.

Kartik Agaram Eli has already shown how to do this with JS in a browser, but, to help further my own understanding: would not a Python app, running a localhost:XXXX do the job? Run Python program, open browser and point it at localhost:XXXX.

You can't do that on Android or iOS.

Going back to the start of this thread, the reason I am looking at Decker is it gives you a single html file you can modify and save on any device. Though I haven't actually tested the save-load flow on Android, now that I think about it.

Kartik Agaram I wonder if I could modify my playground (which is a little buggy and in need of some love) to play nicer on mobile?

The program is kind of a quine, you can download the file, including the contents of the text area as a new file

Oh this is cool!

And.. I'm fucking pissed off. I could open local html files on my phone 30 minutes ago, and I can't anymore.[1]

One interesting design choice Decker makes is in creating its own file format. So it's not quite one html file. It's one html file for the platform and then a .deck file for your data. It still needs the html file somehow, though, but maybe it reduces its exposure to shit experience like this.

[1] I was trying different browsers, being careful to not set any default, always choosing "just this once," and then I had the grave misfortune to tap on the Samsung Browser (that manufacturer-installed piece of malware that you can't uninstall). First it asks me to accept ToS. I'm like, oh never mind not worth the fucking trouble so I hit cancel. And now I can't open local html files anymore. At first it would always pop up that (Samsung!) (ToS!) window for any local html file, no matter what file it was or what app I was opening it from. So I finally accepted ToS because what else. And it still doesn't work. Ironically I can't even find Samsung's browser anymore 😂 😭 Gonna reboot now, see how things look then.

This is a good reminder, everyone: never depend on people who don't give a fuck. And phones are always fucking contingent. Never rely on them for anything.

So yeah, @Eli Mellen maybe mobile is a tire fire and I should just rip out all the mobile stuff from Lua Carousel.

Kartik Agaram it should be devdocs.io

Kartik Agaram Your Samsung experience is exactly why I adopted /e/OS. No regrets.

BTW, you can run client-server assemblies in Android, by running the server part from Termux. I run CLOG apps this way on my e-ink reader, just to be able to work on an e-Ink screen. But it's a bit of a pain to work with, and probably not good for battery life if you have a long-running server,

@Eli Mellen Thanks for the playground link!

I have been wondering for a while if something like that could be integrated with TiddlyWiki as a UI toolkit to make a personal coding platform inside the browser. But I didn't find anything similar in spite of the huge TiddlyWiki community, so perhaps there are technical obstacles that I am not aware of.

Another reason to build on TiddlyWiki is that they have a large collection of workarounds for the file saving issue. Quines are cool, of course, but if manual downloading is the only way to save your code, you end up saving it much less than you should.

UPDATE: I just did another quick search on this and found this recent project: github.com/tiddly-gittly/zx-script

Second UPDATE: "This plugin requires TidGi Desktop App...", so it's actually not for TiddlyWiki in general, and in particular requires Node.js

I am making tomlarkworthy.moldable.app/index.html for this kind of usecase. I am very interested in what kind of minimal app you would want, as the webpage version is probably too engineered to be a good starting point. IMHO you don't need FileSystemAccess API to upload and download a file from the web to a browser, especially if the page itself is single statically executable webpage from the filesystem, you can just replicate the entire webpage.

Tom Larkworthy I tried it with great interest! Keep it in a single (unminified) html file and get to a workflow that works on Android and iOS, and I won't care too much about anything else.