I've been trying some new stuff lately: • Decker. I'd for some reason assumed it was some npm and/or wasm monstrosity (perhaps because it's so dang inefficient), but it turns out it's nice zero-dependency Javascript in a single html file! And that's in addition to the native version that uses SDL just like LÖVE. So in some ways it has a better cross-platform story than LÖVE, which is non-trivial to run on iOS. • Rust. I spent some time playing around with a LÖVE-inspired game engine called ggez, and the much more basic wgpu crate. The promise here: Rust seems to be evolving some pretty nice cross-platform tooling, so in time we may end up with a world where it's easy to cross-compile to any platform. Of course, the compile step is not ideal, but it promises to yield much more efficient binaries that might run on lower-end devices like old phones. The eco-system is not quite there, and the npm-like dependency explosions are rough. But I want to try to look outside my comfort zone. It's possible the way forward isn't unique-snowflake minority platforms like LÖVE or Decker, but just to use a majority platform with better taste, taking the time to understand and curate the landscape of dependencies.

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.

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.

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.

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.

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

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

@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?

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,

I am making https://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.

@Konrad Hinsen About TiddlyWiki, I'm planning to build out a much more "robust" saving path there, hopefully in the next few months. For example, I'd like TW to use browser local storage (for user prefs) and have the option of a (in-browser!) Git repo as durable storage. Hopefully that would be useful to others as well. 🙂

@J. Ryan Stinnett Looking forward to it! I have absolutely no idea how one can have in-browser Git repos, but if that's possible and if they can actually connect to on-line repos, that sounds like a minor revolution in linking in-browser and out-of-browser data storage.

yeah they can https://isomorphic-git.org/docs/en/authentication

Oh sure. Just rewrite Git. I tend to forget the immense resources poured into the Web ecosystem.

we waste so many resources reinventing the wheel across all the ecosystems. Its not just JS, I feel like there is a python binding to a Rust port of X, as well as the pure Python implementation of X, plus the bindings to the original X. • https://github.com/jelmer/dulwich • https://github.com/GitoxideLabs/gitoxide • https://github.com/gitpython-developers/GitPython I do feel LLMs could do this, they have a reference implementation.

Having an LLM translate a real-life project such as Git would be an excellent test for the capabilities of LLM coders. That said, even if LLMs routinely did such jobs, there would still be people motivated to rewrite stuff themselves for ideological reasons. In particular in crusade-driven communities such as Rust.

Going back to @Eli Mellen's idea of locally running JavaScript, I focused earlier on phones because I implicitly assumed browsers on computers would be able to handle it, but support is irregular on the weird browsers I'm trying to use: • Zen Browser has some sort of restrictive Content Security Policy that blocks all Javascript on file:// pages • SeaMonkey is definitely missing features. I can't download edits to Cristóbal Sciutto's quine document or your Javascript Playground above. I can't save the canvas in inknswitch. Yon seems to mostly work except alt-meta-click which it uses to open links in other "windows". There might be some other nooks and crannies like that. So even seemingly simple stuff in the Javascript world currently feels locked behind the Firefox-Chrome duopoly 😕 But there are probably lessons to be learned from m15o's work.

not all browsers work the same, thats a feature not a bug. If you want to target reach then you stick to the Chrome-Edge-Safari, if you want to support an ideology you have to decide what that ideology is and target that, and not all browsers will be coherent with that ideology. I actually consider Firefox in the ideology camp and definitely not part of any dystopian duopoloy. The shit samsung browser has more users than Firefox.

My "ideology" is to build things others can use without having to think about fine distinctions in the software their computer has. So not all browsers working the same, I don't understand in what world that's a feature. Chrome-Firefox is a duopoly in the sense of browser engines. Edge/Safari/Samsung are under Chrome the way I think of it. Any other rendering engine has really tiny market share. > even seemingly simple stuff in the Javascript world currently feels locked behind the Firefox-Chrome duopoly 😕 Another way to say this is, browsers keep adding features that require using their latest and greatest version, which also mixes in a bunch of user-hostile stuff. Minority forks of those browsers avoid the user-hostile stuff but also lag behind on useful (and not particularly advanced) features.

I’m gonna be a little pedantic and point out that Edge, Samsung, Chrome, Brave, etc. are all the same engine Firefox and Safari are each different. Safari is WebKit, which a handful of Linux browsers use, too. A lot of the differences come from the different sandboxing models adopted by the various engines.

no I target safari as well (iphone users). Any random program can call itself a browser is a feature of an open platform. But its not sane to say I will support every random program that calls itself a web browser. Its literally impossible to do a local first browser if the browser consciously shuts down javascript or indexdb. Some people want utmost privacy and will see javascript and indexdb as a dangerous fingerprinting vector. I am glad they get to choose not to use indexdb, but saying that because there exists browsers that don't have indexdb that this is a problem for the web has got their priorities wrong IMHO, its good people can choose not to have specific web APIs working and that they can continue to surf with some gracefull degradation is good.

@Eli Mellen Oh I thought Webkit folded up with Chrome at some point? Was I completely imagining that?! Will go check.. @Tom Larkworthy That makes sense from the perspective of a creator but not as a user for features that seem simple but turn out not to be. Perhaps this is my fundamental dissatisfaction with the web as platform. It's metastasized under commercial pressures until there's no meaningful distinction between engine and UI, protocol and user agent. That and not prioritizing offline single-html-file use cases. Zen is a direct fork of Firefox, and SeaMonkey has been a funded project for longer than Firefox. These aren't exactly randos!

@Kartik Agaram Chrome's Blink engine started as a fork of WebKit in 2013. WebKit has remained its own separate thing since, powering Safari and other smaller browsers (plus all iOS browsers, at least outside the EU...).

Ah, thanks. Common heritage so I was collapsing them in my mind.

I tried desktop Zen, this is literally the first clicks I made in this application and it worked. I also jsut tried opera on my mobile and the full download, open from filesystem worked local-first too (and I already tested web chrome local first works on android). Some web projects don't work across the full ecosystem, as it does require a bit of extra work to test. Safari in particular has a few JS divergences but generally they are easy to fix once you spot them.

Oh interesting. 🤔

What I worry most about with browsers is the combination of (1) their complexity and (2) their central place in cybersecurity. Together, they mean that whatever works today in some browser may be broken tomorrow, "for security reasons", and there isn't much an ordinary mortal can do about that. It's the worst kind of dependency.

@Konrad Hinsen do you have any specific examples of this biting you or others in the past?

together, they mean that whatever works today in some browser may be broken tomorrow, “for security reasons”, and there isn’t much an ordinary mortal can do about that. It’s the worst kind of dependency.

I know my question likely comes off as sort of a snide reply-guy, and I promise up and down on Ivan’s powerful 🍰 emoji use that it isn’t, I’m genuinely curious because I’ve worked in web dev for 10+ years, and maintained a lot of gov and industry web tools that required STRONG and LONG backwards compatibility. Working in JS, at least, it has been my experience that, with very little exception, once a feature is introduced it will be there pretty much forever. There was a time where some browsers, namely IE, had bespoke, or weirdo implementations, but these days, browsers have pretty much converged on all but the cutting edge, where Chrome is typically happy to adopt anything and everything they invent and then try to push the others to adopt it by baking it into a core experience of YouTube 🫠 I don’t think browsers are perfect, by any means, but I think that they generally offer a much more stable, well defined, and wide-spread target than most operating systems do. I’ve also been an iOS and Android dev for years, and those platforms burn old APIs every single point update.

@Eli Mellen The best-known story is probably TiddlyWiki. It used to be a straightforward document in local storage for which the document editor happened to be the Web browser. Sweet and simple. Today, you can't use TiddlyWiki without a careful study of various storage solutions and their trade-offs. I no longer recommend TiddlyWiki to non-techies for this reason. But even leaving aside issues related to local storage, I have plenty of memories of sites (usually sites run by my employer, or by some other mid-size institution with little technical competence) that work only in some range of version numbers for some browsers, which is tiring in the long run. Right now, I have one of my employer's sites that I can't get to work in Firefox, so I need Chrome on all of my machines as well. Another weird story is FUN, which works for me with Firefox but not Chrome, whereas for a colleague, it's just the other way around. FUN officially recommends Chrome, so it's me who has the weird variant of the problem.