QML is this and more.
What if we'd had better HTML-in-JS syntax all along?
71–80 of 170 posts
Re: What if we'd had better HTML-in-JS syntax all along?
#72> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascript. It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). The genuine way of generating HTML in JS were various methods of `String.prototype` for generating HTML form…
There was also the the idea that JavaScript was just one way of scripting the page. VisualBasic Script (VBScript) had momentum in IE releases. The general idea was that the user-agent was going to be able to parse multiple scripting languages, the list of which would probably grow as time went on. Think native TypeScript parsing in a browser today!
Tcl added sandboxed subinterpreters in a bid to become a safe web scripting language. The plan didn't work out but it is a killer feature for untrusted input.
Re: What if we'd had better HTML-in-JS syntax all along?
#73I've thought that Ruby's syntax would map nicely to HTML elements:
div class: "language-javascript" do
a href: "index.html" { img style: "height:2em", src: "pic.png"; "⇦"}
h1 {"What if we'd had better " + code{"html"} + "-in-" code{"js"} syntax all along?"}
p{"I have a theory that a grave mistake was made in 1995 ..."}
endRe: What if we'd had better HTML-in-JS syntax all along?
#74Ctrl-F `E4X` .... nope.
https://developer.mozilla.org/en-US/docs/Archive/Web/E4X
(Not quite "all along"/1995, but available by the early 2000s...)
Re: What if we'd had better HTML-in-JS syntax all along?
#75Don't forget E4X: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tut... It never really caught on.
The problem with E4X is that it's only data; you can't define a new tag that reduces to new primitives. This kind of composability is why XHP (in PHP) and JSX are so useful.
Re: What if we'd had better HTML-in-JS syntax all along?
#76Earlier quoted context omitted.
Wow. I'd never heard of this. And now instead we have virtually the same thing via JSX except we now require a compilation stage to achieve essentially the same thing...
I'm sure it was one of the inspirations for JSX -- https://facebook.github.io/jsx/#prior-art
JSX was a direct port of XHP to Javascript.
Re: What if we'd had better HTML-in-JS syntax all along?
#77Personally I find the syntax of SwiftUI to be most sensible.
Re: What if we'd had better HTML-in-JS syntax all along?
#78Interesting note is that Perl's CGI module used to have functions like this and they were removed a few years ago because it was considered bad form to mix document and code.
Re: What if we'd had better HTML-in-JS syntax all along?
#79Suspiciously absent, but right up this alley is hyperscript: h('div', {id: 'foo', onclick: f}, 'Hello') The benefits of hyperscript over `div()` is that in JS, variable names must be imported by name (so `import {div, ul, li, ...}` gets annoying fast). Also, React is super popular, and hyperscript interoperates nicely with JSX.
FYI in typescript with VS you just hit TAB to auto-complete an import.
Re: What if we'd had better HTML-in-JS syntax all along?
#80Something close to this is possible already in JS, I'm working on a library for generating HTML in node, heavily inspired by Haskell's blaze and lucid. Example code: div( { class: "table-responsive" }, table( { class: ["table table-sm", opts.onRowSelect && "table-hover"] }, thead(tr(hdrs.map(hdr => headerCell(hdr)))), tbody( vs.map(v => tr( mkClickHandler(opts, v), hdrs.map(hdr => td(typeof hdr.key === "string" ? tex…
The Re:DOM library might be of interest — it's very similar to your syntax above and it also comes with a robust toolkit for handling updates without the overhead of a virtual DOM: https://redom.js.org/#elements
Neat! I made this exact same thing, but a bit more robust a while ago. It's amazing to see how similar it is. The implication is that it's likely logical.