For example, with Paredit, you can create an element and then move it prev/next/up/down a tree with muscle memory you're already using for the rest of your code.
When I re-entered the Javascript world, I tried arrays-for-html but realized it's unbearable without manipulation tooling. I think something like JSX makes more sense at that point since I find you're more likely to already be using an HTML manipulation tool like Emmet which is more pleasant than hand-editing array structures.
I've never used paredit in emacs, but I suspect that it might be amiable to working on Javascript as well.
More annoying to me would be all of the extra quotes and commas I need compared to Hiccup implementations in Clojure.
Even with decades of knowledge, I think you'll find that devs can transition to the non-html model really, really quickly, and then it's nice because everything is a single uniform language.
Well... there is the OP...
At least JS is really just JS, and developers have been reading, mentally modeling and reasoning about JS -> execution translation for decades.
It lets you write HTML templates as JS template literals:
let post = (title, body) => html`
<h1>${title}</h1>
<div>${body></div>`;
Lots of editors have automatic support for inline HTML tagged with a tag named "html", so you'll get syntax highlighting in say, Atom. And VS Code has a plugin that adds intellisense.
https://github.com/cwells/breve
I don't see a huge advantage over hyperscript (hyperapp and mithril both use it), but that is a ridiculously small codebase.
The JS hate is kind of funny around here, because when you dig into stuff like this, you realize that JS is very lispy in ways (it's easy to build up trees of HTML dynamically). In the mid aughts on r/programming people would rant and rave about the kind of stuff Smalltalk's Seaside could do. Now that's possible, most of the disadvantages have been worked out, and people hate it.
Can't win, can you?
This then led to the myriad toolchains/PMs/bundlers/language processors that added a huge amount of grit to what should have been a blindly simple development process. Some shoddy implementations have been allowed to mature far longer than they should have, and we're still trying to recover.
But the base language is fine IMHO.
Thanks, I hadn't seen Breve! I was looking for exactly this a while ago.
I have been thinking of adding shorthand for id/classes in the tag name like hyperscript or JSnoX.
That would mean you could write `['input#search.large']`
"JSON" originally stood for "JavaScript Object Notation" - the restrictions on double-quotes and unquoted keys are arbitrary extras on top of that concept, but otherwise JSONML is, technically, another JavaScript Object Notatation for Javascript that is also a Markup Language.
Admittedly, the use of the term JSON these days implies that your syntax will be parsable by a JSON parser, which JSONML might not be.
body
h1 Hello World
input(type='range')
input(onclick='console.log') Log event
ul
li 1
li 2
li 3
unless false
span Hidden
At that point, I hadn't really done much react-style apps - will have to see how well that works with React!
which is even more terse
You refer to h but what is it? I searched around but obviously something called h is hard to find.
Practical Common Lisp demonstrates a spiritual predecessor that works on data from 2003[0]. I'm sure there are much older implementations floating around for CL and Scheme but I don't care to look for them. This is a common idiom in lisps.
[0] http://www.gigamonkeys.com/book/practical-an-html-generation...
https://makandracards.com/makandra/44070-javascript-hash-obj...
Well, explicit-dependency-free, but there's still an implicit dependency on the tag names. Granted, those are just standard HTML, but something is lost by not checking them at compile time. OTOH, you could write a linter for that...
That's high-value in a language like Elm because you can refine element-generating functions (e.g. not allow children elements for empty elements), it's not really useful in a dynamically typed language.