[blacktriangle]

Clojurescript is at least available at dev time thanks to figwheel.

Vue and React do bring along the whole runtime and allow introspection, but have abstracted away the browser to a great degree.

The problems really break down like this:

Clojurescript: Doesn't run natively in the browser, requires too much tooling, interactive development during development but doesn't make it into production.

React/Vue: layer of abstraction over native browser APIs, also unacceptably large

Svelte: Not available at runtime

Flippantly, the audience is me, but I'm trying to better put into words why I want this. The idea is to get closer to the experience of developing CL with SLIME/Emacs, where you really are poking around on an active living system. I find that form of development to be the most productive, and it seems like the browser + inspector console is a great potential place for such development with the right set of libs. I want a library that is fully available at run time yet small enough that you can send it into production. And I want to to fully embrace web standards for good or ill rather than try and fix the web via layers of abstraction. Last, I want it to have a very minimal surface area so the whole thing fits in your head, think something like Backbone.js where you could read the whole things annotated code in a day and wrap your head around it.

I appreciate your replies, you've helped me at least try and better refine what I'm thinking of.

[ducharmdev]

No problem, glad I could help - that does clarify where you're coming from. Interestingly, when Brendan Eich was creating JavaScript, he actually intended to make it more like Scheme before his supervisors pushed him to make the syntax more like Java. So I think your thought process is inline with his original intentions.

When you say minimal surface area and "whole thing fits in your head," I can't help but think of the Alpine.js API. Although I'm still mixed on how I feel about Alpine, I can't deny how beautifully simple the API & docs are for it.

I also wonder whether web assembly could play a part in what you're suggesting. It's a part of the web platform, would potentially help with providing robust in-browser tooling... even the S-expressions of human-readable .wat files look rather Lisp-like, albeit too low-level for most frontend work. But I don't know wasm that well, just thinking out loud.

[blacktriangle]

Alpine does look neat, but it feels like its coming at the problem from a different direction than I'm thinking. Alpine looks like it wants to expose you to JS functionality via HTML attributes. My issue with this approach is that every time I've tried it, one eventually hits the limits of what the tool anticipated. Also Alpine looks like it leans on putting literal JS into HTML tags for execution which I don't like since this code is often difficult to debug, lint, reuse, etc.

I prefer the alternative approach where you move as much of the system as you can into JS, since JS is a fully functional language that will adapt to any issue you might run into. Your static HTML would really just be a static skeleton focusing on layout leaving your dynamic content to be dynamically created by JS. Your JS could keep references to those elements in code and then not rely on selectors to find what you need.

With web assembly I'd be really shocked if it was able to provide the same kind of dynamic interactive environment as the Javascript console, but I'm not that well versed in webasm so who knows?

[ducharmdev]

Definitely feel the same way about Alpine. Philosophically I get it, but I agree about how using attributes obfuscates too much. The idea of debugging js in attributes sounds horrible.

Not sure if you've used the multiline console that Firefox has, but I could easily see some repl-driven development with that; I just wish the other browsers had it too.