I think my favorite thing about JSX specifically - is that the {} breakouts used in it, get all the same treatment from the JS/TS compiler as your Javascript/Typescript does. And all without changing HTML into a JSON or Yaml representation. It just works in VSCode. The number of years of HTML being an relative of the SGML/XML family (pedants calm here, you know what I mean) shouldn't be thrown away just because it's…
What I would love to see is something like jsx supported directly by the browser. Although, I'm not sure what that would do in non-browser EcmaScript environments. Perhaps something like lit-html's html string tag is more likely to be standardized.
What if we'd had better HTML-in-JS syntax all along?
161–170 of 170 posts
Re: What if we'd had better HTML-in-JS syntax all along?
#162Earlier quoted context omitted.
> There are so many things you need to do in HTML to make a modern web page that this suggestion conveniently ignores. Any examples of things that aren't handled by the suggested syntax?
Comment nodes, multiple text nodes in one element node, CDATA section.
None of those seem to be necessary to create a modern web application.
I'm not arguing, just trying to understand.
Re: What if we'd had better HTML-in-JS syntax all along?
#163Earlier quoted context omitted.
Comment nodes, multiple text nodes in one element node, CDATA section.
Are there any examples of where you'd need that in a web application that's just being used to update the DOM? None of those seem to be necessary to create a modern web application. I'm not arguing, just trying to understand.
Re: What if we'd had better HTML-in-JS syntax all along?
#164Earlier quoted context omitted.
Are there any examples of where you'd need that in a web application that's just being used to update the DOM? None of those seem to be necessary to create a modern web application. I'm not arguing, just trying to understand.
If you have a rich text editor or inline SVG there, you're bound to have to deal with them eventually.
Re: What if we'd had better HTML-in-JS syntax all along?
#165An early alternative would've been to use an integrated language for both HTML and JS features, like Curl, published in 1997: https://en.wikipedia.org/wiki/Curl_(programming_language) https://dl.acm.org/doi/10.1504/IJWET.2003.003259 https://groups.csail.mit.edu/cag/curl/wwwpaper.html (Disclosure: I worked at the Curl commercial spinoff.) Or, many Lisp people just used s-expression data for HTML, and Lisp for everythi…
Clojure has literal lists using parens and vectors using square brackets. By using both you can mix code and markup in a readable way. It's great!
Re: What if we'd had better HTML-in-JS syntax all along?
#166Earlier quoted context omitted.
They can't and they won't. Because they rely on DOM APIs to do anything useful. Which brings us back to the article.
What does that have to do with having composable components?
The only way the vanilla webcomponents are "composable" is through tons of boilerplate code using DOM APIs. You can't even re-create the example with list elements without tearing your hair out when using webcomponents.
It's so bad that any examples showing "composability" immediately give up and use .innerHtml everywhere, and even then it's pretty bad.
It's so bad, in fact, that people do anything to avoid writing vanilla and use lit-html (yay, programming with strings), Stencil, or even Preact (AMP switched to Preact to author components).
Re: What if we'd had better HTML-in-JS syntax all along?
#167Earlier quoted context omitted.
> It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). I think people also forget how slow a lot of JS was really until V8. I remember having server code generate JS arrays (creating them from an xhr request was too slow), that in turn would document.write (manipulating the DOM was also super slow) data on the client to make…
> creating them from an xhr request was too slow You had XHR? Luxury! We had to embed a 1x1 px Java applet to communicate with the server without reloading the page! ;)
Re: What if we'd had better HTML-in-JS syntax all along?
#168Something 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…
Solenya does pretty much exactly what you've described: https://github.com/solenya-group/solenya Interestingly, in a very early version classes were allowed to be expressed as arrays of strings just like you had, but in the vast majority of cases a space delimited string worked fine, so this feature was dropped for simplicity/uniformity.
condition && "conditional-class"
At the end of the class list.)Re: What if we'd had better HTML-in-JS syntax all along?
#169Earlier quoted context omitted.
What I would love to see is something like jsx supported directly by the browser. Although, I'm not sure what that would do in non-browser EcmaScript environments. Perhaps something like lit-html's html string tag is more likely to be standardized.
I was going to bring up Polymer's lit-element / html`` syntax but decided it was a dead horse - but in any case, hopefully that isn't the way things go. Even though the breakouts ${} are JS and the compiler can help with those, it doesn't do much for repetition. I really think that's one area that angularjs -> angular X really struggled was templates that repeat things... React pulled that off so f...ing fabulously.…
html`
${items.map((i) => html`${i}`)}
`
...so I don't understand the critique.Re: What if we'd had better HTML-in-JS syntax all along?
#170https://github.com/enjikaka/webact/blob/master/src/helpers.j... https://github.com/enjikaka/webact/blob/master/src/helpers.j...
html`Hello world`
returns a document fragment that you can just appendChild with. Super simple.