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

131–140 of 170 posts

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

#131

Post by krebs_liebhaber »

toohotatopic wrote: post #103

>What if we'd always had something like this in js? What if html would use round brackets and just use the closing bracket instead of the closing tag? e.g. foo could be: (html (body (div 'foo'))) Something similar could be done for javascript. Instead of writing html in javascript we could write javascript in html. Just imagine if we could represent the code as html or in that round bracket form: function inc (x){ re…

Congratulations - you've invented S-Expressions! Fortunately for you, there's a whole family of programming languages[0] that are based solely on this syntax!

If you want to see a mature library that uses this syntax to represent both DOM elements and code, I'd suggest checking out Reagent[1].

[0] https://en.wikipedia.org/wiki/Lisp_(programming_language)

[1] https://reagent-project.github.io/

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

#132

Post by kazinator »

kroltan wrote: post #122
goatlover wrote: post #104

Earlier quoted context omitted.

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.

The duo of Lisp and Smalltalk basically define what OO means.

Javascript simulates some of the aspects of OOP in an ad hoc way by turning every object into a hash table so that properties can be tacked onto it.

It's what you implement if it's Wednesday, and the boss asks for a some sort of working OOP system by Friday.

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

#133

Post by ahupp »

db48x wrote: post #119
ahupp wrote: post #75

Earlier quoted context omitted.

The problem with E4X is that it's only data; you can't define a new tag that reduces to new primitives. This kind of composability is why XHP (in PHP) and JSX are so useful.

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.

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

#134

Post by Seb-C »

I actually wish we had more advanced features in HTML itself. There are still many cases today where you only need JS to load something on click or for a simple datepicker.

If some basic things like and the tag (and associated css) were actually standard, reliable and working, we would not need JS at all most of the time.

I also wonder after 20 years why we still don't have something like or to dynamically load content rather than billions of specific ajax query scripts everywhere.

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

#135

Post by anonytrary »

> I think it's a fine enough solution, but the fact that it's a different syntax from your standard js objects encourages people to consider the VDOM objects as "not normal data", but they are. Notation as a tool of thought innit.

This is the author's only commentary on JSX and IMO it's not enough of a reason to completely ditch JSX. Most people who work with JSX in any reasonable capacity understand that they get transpiled to hyperscript-flavor calls (and ultimately POJOs). I'm not sure why we need to reinvent this wheel in TypeScript as hyperscript already addresses this problem in native JS.

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

#136

Post by anonytrary »

glutamate wrote: post #8

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

How is this different from just using a hyperscript library directly and bypassing JSX-like transpilation?

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

#137

Post by kalleboo »

irrational wrote: post #43
masswerk wrote: post #40

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…

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

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

#138

Post by Waterluvian »

> the fact that it's a different syntax from your standard js objects encourages people to consider the VDOM objects as "not normal data", but they are.

Can someone help me understand what the author means by this? What are people doing where the author sees them as considering vdom objects as not normal data?

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

#139

Post by dmitriid »

thayne wrote: post #128
fragmede wrote: post #121

Earlier quoted context omitted.

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.

They can't and they won't. Because they rely on DOM APIs to do anything useful. Which brings us back to the article.

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

#140

Post by dmitriid »

flowerlad wrote: post #96
FlorianRappl wrote: post #93

Earlier quoted context omitted.

Besides the poor browser support (supporting IE11 is still quite a pain) the API is just so bad that you'll need another abstraction on top anyway. The main use right now is as target for framework independent design systems / component libraries.

Here's an example of a Web Component: https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Looks pretty straightforward, and there isn't much of an API to begin with. It's just plain HTML, CSS, JavaScript and DOM APIs.

> It's just plain HTML, CSS, JavaScript and DOM APIs.

Exactly. The entire history of web development has been about finding good abstractions around the horrendous DOM APIs.

And that's before you start talking about the need to roll out your own solutions like state management for WebComponents.

Post reply on HN