Live data from Hacker News

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

leontrolski.github.io

81–90 of 170 posts

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

#81

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

HTML should be expressed in the data literals of your programming language, this is easier if you have a literal data type for names like Erlang and Clojure

Once you have that, you have a always "parsed" HTML that you can serialize, send over the wire to other languages, rewrite with ease and change the render target if need be

Some other commenters have shown what that looks like in practice

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

#82
post #68

Earlier quoted context omitted.

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.

I definitely had a positive experience using in on a moderate sized project last year — the biggest thing I liked was how simple it was. Everything is standard JS & browser APIs so there was zero overhead when debugging.

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

#83
HTML in JS feels so wrong, I'll never get used to React-land. Feels like the simplest 2 page, 2 action apps now need a hundred modules, all kinds of weird naming conventions and config dependency spaghetti and of course a complex build system for what would otherwise be a few lines of plain old JS.

Rails 6 now webpacks 100s of KB of js for a new blank app. wtf if going on.

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

#84
It would be interesting to see what would have happened with the internet had a few different decisions been made along the way. if a spec had been implemented differently or CSS or JS hadn't become the norm. https://eager.io/blog/the-languages-which-almost-were-css/

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

#85
post #83

HTML in JS feels so wrong, I'll never get used to React-land. Feels like the simplest 2 page, 2 action apps now need a hundred modules, all kinds of weird naming conventions and config dependency spaghetti and of course a complex build system for what would otherwise be a few lines of plain old JS. Rails 6 now webpacks 100s of KB of js for a new blank app. wtf if going on.

Yes, it's some weird cargo-culting nonsense for sure.

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

#86
They are proposing the syntax:

    button{id: 'baz' class: ['foo' 'bar'] data: '1' onclick: f
        'Hello '
        em{'there'}
    }
which is of course not possible to use at the moment, but thought I'd convert it to the closest thing that's possible right now:

    button({id: 'baz' class: ['foo' 'bar'] data: '1' onclick: f},
        'Hello ',
        em('there')
    )

Not too far!

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

#87

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

> 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 the web page 'interactive'. It was messy.

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

#89

Earlier quoted context omitted.

Cool! I was looking for something like this but couldn't find it. Oh well, building my own kept me sane during lockdown. I think combinator libraries like this and one I'm building are definitely better than templating languages, although JSX can also work really well, in particular because it retains the HTML syntax making it easy to copy from the browser into code.

You can also take a look at mithril.js implementation of hyperscript [0] [0] https://github.com/MithrilJS/mithril.js/blob/next/render/hyperscript.js

was about to mention Mithril.

solid framework, but not great for large applications.

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

#90
post #59
post #29

Earlier quoted context omitted.

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.

> PHP code which supports being interspersed with HTML You're one of a large number of people who say this, but it is false. PHP intersperses a programming language with static strings. Those static strings frequently adhere to HTML syntax, but that's aside from PHP. What is HTML? It's not random strings; it's a syntax. JSX is much closer to interspersing HTML with a Turing-complete programming language than PHP ever…

You're technically correct, but I don't think the distinction adds anything to the conversation. I don't know if PHP was the inspiration for JSX, but if the strings they were using in PHP was HTML, then it could have been.

EDIT: Sounds like JSX was inspired by XHP: https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...

Post reply on HN