Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

leontrolski.github.io

Post reply on HN
Print view View original

41–50 of 170 posts

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

#41

Post by jwr »

adambard wrote: post #24

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…

Thanks for mentioning this. I was about to say that those of us who write ClojureScript do not have the original problem: my functions return vectors with data, which then get turned into HTML, DOM objects, or React classes, depending on the specific use case.

In other words, there is only one language and one syntax to deal with.

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

#42

Post by Joeri »

ChrisSD wrote: post #12

Are we now reinventing PHP but coming from the opposite direction?

No, this is something different because it understands html.

Php has no understanding of html. It streams the php file as bytes, and anywhere it detects the byte sequence that corresponds to “”. You can stream anything. You can rename a png file to .php and put some php tags in there and it will work. You need something that understands html’s structure to properly escape. Php can’t do it natively, hence the many templating libraries for php.

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

#43

Post by irrational »

masswerk wrote: post #40
masswerk wrote: post #20

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

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 to the page before returning it). The only things I can recall using JS for back in the early days was displaying the date and time at the bottom of the page (why we felt like that was useful is beyond me).

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

#44

Post by TomMarius »

jannes wrote: post #29
brlewis wrote: post #11

Earlier quoted context omitted.

I'm sure it was one of the inspirations for JSX -- https://facebook.github.io/jsx/#prior-art

The creators of JSX (Facebook employees obviously) once said in a talk that their biggest inspiration for JSX was server-side PHP code which supports being interspersed with HTML.

Yes, XHP, also by Facebook

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

#45

Post by hombre_fatal »

jannes wrote: post #29
brlewis wrote: post #11

Earlier quoted context omitted.

I'm sure it was one of the inspirations for JSX -- https://facebook.github.io/jsx/#prior-art

The creators of JSX (Facebook employees obviously) once said in a talk that their biggest inspiration for JSX was server-side PHP code which supports being interspersed with HTML.

Link?

You might be misremembering Pete Hunt's talk about React's design decisions: https://www.youtube.com/watch?v=x7cQ3mrcKaY where he makes the case against the "separation of concerns" cargo cult.

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

#46

Post by freefriedrice »

I have a theory that hindsight isn't even 20/20 when it comes to the web. Hindsight is still 20/400 because we STILL do not know what is the best language & framework. Frontends evolved quarterly with new paradigms popping up at a breakneck pace.

There is a reason why we have knockout, ts, angular, react, vue, and even people touting their own NEW frameworks in this very thread: we still don't know WTF we are doing!

I don't think it is a bad thing, I think we're in the Cambrian Explosion of web development, and will be for decades until the hardware slows down its rapid evolution.

I was there when Mosaic first appeared in /usr/bin during grad school. We had no clue where things were headed then, so I find it a bit harsh to diss on the first devs.

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

#49

Post by devxpy »

I think flutter puts a nail in the coffin with its semi-declarative syntax.

While you're technically programming using an imperative language, they've somehow managed to make the syntax close enough to a declarative one that it isn't just a soup of bare object surgery (like tkinter or java swing).

They also, really went the extra mile to NOT have to do tree diffing[1], by making Widgets immutable, while still having a "detached" State associated with them.

And this is eerily close to the JSON-is-HTML syntax the author is proposing. A replication of flutter's strategy in pure JS is defininitely worth exploring.

[1] https://flutter.dev/docs/resources/inside-flutter#linear-rec...

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

#50

Post by kroltan »

This reminds me of a very cool property of the Lua language that allows for very neat "syntax extensions", and reminds of functional languages too:

If you have two expressions adjacent to eachother, it evaluates to calling the left-hand side with the right-hand side as a parameter.

At its simplest:

  function foo(text)
    print("Foo:", text)
  end

  foo "bar"
But you could implement a JSX-lite in it:

  function Div(props)
    return function(children)
      return ViewLibrary.createElement("div", props or {}, children or {})
    end
  end
Then, you use it like this:

  Div{id="outer"} {
    Div{id="innerA"} (),
    Div{id="innerB"} {
      Div()()
    }
  }
No compiler extensions needed! And with a bit of library sugar, you could do away with the empty parameter lists too (calling any unresolved functions with empty parameters), but this would lengthen the demo a bit so I omitted it.
Post reply on HN