Live data from Hacker News

What if we'd had better HTML-in-JS syntax all along?

leontrolski.github.io

121–130 of 170 posts

Re: What if we'd had better HTML-in-JS syntax all along?

#121

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…

Yeah, agreed. React and JSX really shines with a good component library, and the key word with react is composable. I don't know that, by itself, better syntax for HTML-in-JS would advance the state of the art. Instead of having divs and spans everywhere, they're an implementation detail of components.

I can change

    
        
    
    
        
    
to

    
        
    
    
        
    
Without having to know what html+css tricks topBar is doing under the hood.

Inside of medicationsPanel, there's which is the `ul`.

    
        {medications.map(m => {
            
        })}
    
medicationListItem has the ``, with the styling living somewhere inside. Templates, especially in separate files, don't really manage to be composable with the same ease. Leaving the divs and spans and CSS to the lowest levels of the component library does wonders for making the code easier to reason about, and maintain. React code from a few years ago still has some warts, but it's still way less painful to try and pick up than code that was written with traditional templating. (Specifically, the templated project was using `.erb` files.)

React threw out MVC and templates (though some say it's just the V instead), and is worth learning just to feel like it's possible to implement UIs cleanly.

Re: What if we'd had better HTML-in-JS syntax all along?

#122
post #58

Earlier quoted context omitted.

In fact, since objects and arrays are one and the same in Lua, one can even do away with the nested calls, which also simplifies things visually: Div { id = "outer", Div {id = "innerA"}, Div { id = "innerB", Div {} } } This works because when you omit the key (id=) of a table item in Lua, it is assumed to have a incrementing numeric key.

That's very neat. In the pure prototyping language IO, since the syntax was defined as messages to objects, you could define your own syntax to support xml or html directly in IO. I wonder if Netscape hadn't collaborated with Sun if JS would have had a more pure implementation of prototypes, and how those might have been leveraged more minus all the confusion from mixing in Java-like syntax on top of JS's object mode…

I don't have the sources right now, but I once watched (not attended!) a presentation that talked about how JS was initially intended to be a language more like Lisp or Smalltalk, but was changed into an OO language to appease the heavy marketing at the time.

Re: What if we'd had better HTML-in-JS syntax all along?

#123

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…

Stencil uses JSX.

Re: What if we'd had better HTML-in-JS syntax all along?

#124

The "object" syntax reminds me a lot of Clojure/script's Hiccup ( https://github.com/weavejester/hiccup ) style, which has become a de-facto standard across many popular libraries. In hiccup, this example: { tag: "button", attributes: { "id": "baz", "class": "foo bar", "data": "1", "onclick": f, }, children: [ "Hello", { tag: "em", attributes: {}, children: ["there"], } ] } Would be represented as: [:button#baz.foo.b…

That looks identical to WC3 XML Schema language using JSON syntax instead of XML syntax.

I think you've missed that the hiccup example is the code on the final line.

Re: What if we'd had better HTML-in-JS syntax all along?

#125

> 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!

>Think native TypeScript parsing in a browser today!

If only...

Or better yet, a bytecode format that is easy to target for scripting languages like typescript, clojurescript, scalajs, coffeescript, dart, and even plain JavaScript. Webasm is too low level (at least currently) since it doesn't have a GC, direct DOM access, etc. Most js engines have an intermediate bytecode representation anyway, it would be cool if you could target that instead of textual js.

Re: What if we'd had better HTML-in-JS syntax all along?

#126

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.

Re: What if we'd had better HTML-in-JS syntax all along?

#127
post #62

The solution is not another templating language. Html is complex and many templating languages exist because it’s hard to compress and everything thinks it’s not that hard. There are so many things you need to do in HTML to make a modern web page that this suggestion conveniently ignores. The web is complex because it has replaced native programs and it’s perfectly backwards compatible. Stop trying to make it look ea…

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

Re: What if we'd had better HTML-in-JS syntax all along?

#128

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…

Yeah, agreed. React and JSX really shines with a good component library, and the key word with react is composable . I don't know that, by itself, better syntax for HTML-in-JS would advance the state of the art. Instead of having divs and spans everywhere, they're an implementation detail of components. I can change to Without having to know what html+css tricks topBar is doing under the hood. Inside of medicationsPa…

Webcomponents should help with this. Although the current API is not as pleasant to use as react.

Re: What if we'd had better HTML-in-JS syntax all along?

#129
I have had this in my toolkit

https://gitlab.com/teknopaul/xgenjs

Gives me neat html in jQuery syntax.

$(...).create("div.foo#my-id/input{type=radio}");

Results in code that is just js, no template needed and no data binding.

$(...).create(...).text(quxx).data("foo", baa);

N.b. create() and most Jquery methods return a nodelist so chaining is easy.

I can work on sets as easily as nodes.

create("input[5]").addClass("btn btn-primary").click(...)

Wrote it years before the framework wars and never got sold on any of them.

I prefer code you can see, but I imagine thats not to everone's taste.

Re: What if we'd had better HTML-in-JS syntax all along?

#130

Earlier quoted context omitted.

So, if initially there were no Array nor Object constructors (there were arrays and objects, but only prepopulated ones, representing anchors, forms, etc, found in the document), how were arrays done in a script? function MyArray() { this.length = 0; } function arrayPush( value ) { return this[this.length++] = value; } function arrayPop() { return this[--this.length]; } MyArray.prototype.push = arrayPush; MyArray.pro…

I have been using JS since the mid 90s, but I don't recall needing arrays or objects back then. Frankly we weren't trying to build applications and any real programming work was done on the back end (remember that xmlHttpRequest wouldn't exist for years to come, so any changes to the page were made by going to a new page which would require a round trip to the server, so the server could do anything it needed to do t…

what a trip, I forgot about displaying the current time and date haha. The other major usage I had for JS back in the day was to focus the cursor on the login box on page load.
Post reply on HN