What if we'd had better HTML-in-JS syntax all along? • Hacker News Board

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

#141

Post by Mikhail_Edoshin » Tue, May 12, 2020, 5:35 AM UTC

JS is a procedural language. The somewhat forgotten procedural pattern for constructing these things in procedural languages is to use a canvas::

    xmlCtx = MkXmlCtx()
    SetNsPfx(xmlCtx, "foo", "http://foo.com/ns")
    OpenTag(xmlCtx, "foo:bar")
    SetAttr(xmlCtx, "name", "value")
    Write(xmlCtx, "string")
    CloseTag(xmlCtx)
    xml = GetXml(xmlCtx)

It may look boring but it's exactly the right thing. Syntactic sugar is deceptive. A declarative approach is not the right pattern in JS. (It's essential to XML, but XML is a very different thing.)

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

#142

Post by pjmlp » Tue, May 12, 2020, 5:36 AM UTC

masswerk wrote: post #106

matwood wrote: post #87

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

It wasn't just JS, you could actually watch JPEG images becoming decoded, esp. on a computer which wasn't exactly new. Layout of complex markup could take seconds, reflowing and repainting was out of question. JS as an interpreteded language was accordingly much slower than native code. There was no way to do fast, declarative HTML in JS – and not much of a use case for this. (For much the same reasons, there was no…

Ah, the render one scanline at a time effect in analog modems.

I even used to disable images and just selectively download them.

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

#143

Post by pjmlp » Tue, May 12, 2020, 5:37 AM UTC

TedDoesntTalk wrote: post #57

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…

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!

Well, with a bit of luck you just need to ship a TypeScript compiler/AOT/JIT shipped as WebAssembly module. :)

The best way to take advantage of WebAssembly, since it is here anyway, is to abuse it to recover all plugins that were taken away.

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

#144

Post by pjmlp » Tue, May 12, 2020, 5:39 AM UTC

TedDoesntTalk wrote: post #57

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…

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!

ActiveState had browser plugins for Perl, Python and Tcl. I think they were IE only via COM extensions.

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

#145

Post by irrational » Tue, May 12, 2020, 7:02 AM UTC

kalleboo wrote: post #137

irrational wrote: post #43

Earlier quoted context omitted.

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…

The other major uses of JavaScript were hover-over-button effects, and scrolling text in the status bar

Oh my. I'd forgotten about scrolling text. Why did we do that? LOL

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

#146

Post by jcelerier » Tue, May 12, 2020, 7:29 AM UTC

discreteevent wrote: post #71

QML is this and more.

While being so much simpler at the same time

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

#147

Post by underwater » Tue, May 12, 2020, 8:03 AM UTC

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…

Strings are so tempting because they are there and everyone knows how to use them.

But they are the wrong abstraction for building DOM nodes. They're error prone (no guarantees of correctness) , encoding woes) and are write only (how do you modify a node that is encoded in a string). And what do expressions like html.substr(0, 7) even mean?

First class HTML composition in JS is pretty dang important.

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

#148

Post by rimliu » Tue, May 12, 2020, 8:48 AM UTC

jdmichal wrote: post #60

I have a hypothesis about a different way to organize responsibilities within webpages. I think the split of "content" to HTML and "presentation" to CSS was a mistake. To me, those are both describing content. That is, the author's intent to emphasize a particular part of text, whether via tags or CSS, is part of the content. I think there was a missed opportunity to instead split page layout into its own technology.…

It was not a mistake. The theory being that HTML describes the structure, and CSS describes the presentation. Do not forget, that there are other ways for the page to be rendered: e.g. in screen reader or for print. We had "HTML and CSS living together" with FONT and BGCOLOR and friends. It was not nice. Sad to see people wanting to get it back. We are finally comming to realize that maybe rendering HTML on the server is not so bad after all, when will we realize, that maybe the idea of separating concerns was not so bad after all. And most importantly, when we finally start to learn the technology before trying to "improve" it. It looks like HTML and CSS is somehow considered not worthy learning and understanding, something do be disgusted about. Hating CSS for me sound like the lame bragging "I do not read book" or as the as lame jokes about PHP.

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

#149

Post by jannes » Tue, May 12, 2020, 9:01 AM UTC

hombre_fatal wrote: post #45

jannes wrote: 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.

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.

Sorry, I don't remember the link. It may have been this talk from 2013, but I haven't rewatched it: https://www.youtube.com/watch?v=XxVg_s8xAms

However, if you check out the History section [0] on Wikipedia you will see this confirmed:

> React was created by Jordan Walke, a software engineer at Facebook, who released an early prototype of React called "FaxJS". He was influenced by XHP, an HTML component library for PHP.

[0]: https://en.wikipedia.org/wiki/React_(web_framework)#History

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

#150

Post by db48x » Tue, May 12, 2020, 9:22 AM UTC

ahupp wrote: post #133

db48x wrote: post #119

Earlier quoted context omitted.

Javascript already has the ability to define new abstractions. They're called functions. Imagine you want a new "tag" for defining a Widget. Make yourself a Widget function which takes some arguments, maybe the name of the widget, the mass, and the price. Those arguments can themselves be HTML, created either using E4X or any other means you like. This lets you compose things together. For example, perhaps the price…

Sure, but the why are we talking about special syntax in the first place? In any non-trivial projects you're rarely going to be working with primitive tags, it's always higher level components.

Because all higher-level components must be created out of primitive html tags with a sprinkling of attributes, and it's nice to have a convenient way to create those. This is the same reason why modern languages include some kind of object-literal syntax rather than relying purely on constructor functions. Even C has a comprehensive syntax for initializing objects now. E4X was just that for HTML and XML.