Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I work on a templating library called lit-html that aims to just solve the declarative DOM w/ property & events bindings problem: https://lit-html.polymer-project.org/

It's plain JS with a very similar DX to JSX, and I think addresses that really well.

My team also works closely with Chrome, Safari, and Firefox on proposals like Template Instantiation that aim to build up more APIs that template libraries can use to be smaller, faster, and more interoperable.

I really think we will eventually get good templating in the DOM so at least the most common use-cases are taken care of.



Where is the working group at with that proposal? I've been eyeing it closely, but it hasn't seen any significant movement in over two years, last I checked. I'm excited about template instantiate, though I worry the API is going to be tied to having template element instances, instead of being part of the HTMLTemplateElement and its own thing I could take advantage of with string templates. I also haven't seen any place where I can give feedback formally on the proposal to the working group :(

HTML imports were supposed to be the holy grail to solve this, but nobody but Chrome supported it :(


It's being discussed mainly in the WICG web components GitHub repo. There are recent issues in here: https://github.com/WICG/webcomponents/issues


Every time I look at lit I get this unsettling feeling that it’s almost what I want but can’t be, because it loses the only thing I want in JSX. Lit fundamentally targets templates with HTML output. Which is great for what it is. But the thing JSX offers that nothing else does is:

- return values are a data structure, so they’re render-target/render-implementation agnostic

- it’s compile time only/effectively a macro, so the compiler can choose how to render subtrees

I love the “it’s actually part of the language not a build tool” part of lit, but it can’t satisfy those other goals without giving up its core selling points.


lit-html also returns a data structure - strings and values. You can interpret the strings however you want.

JSX actually doesn't return a data structure. It's syntax only and some transforms do things quite different from what React.createElement() does. And this is part of the problem with it and why it can't really be standardized - there's no semantics to standardize.

lit-html as an render implementation does indeed target only the DOM, it's not trying to target non-web platforms.


Sorry, I misstated my point. JSX is itself a data structure, not interpolated strings and values. That makes it closer to hyperscript. But it doesn’t necessarily return anything or have a runtime value at all.

The problems you cite are exactly what I meant to say are its strengths. Because it’s entirely undefined syntax that only corresponds to data, it can be used as a general purpose macro for anything from React.createElement to defining a web component to defining an output for a CLI to defining a test or an API endpoint or anything at all. It’s a general purpose DSL, and the fact that it looks like HTML/XML is just convenient for its most common usage.


JSX really isn't a data structure, is just syntax. Sometimes it's compiled to statements, like with some idom transforms.


JSX is an expression with structural semantics. It doesn’t have to be compiled to a data structure but at the AST level it definitely is, which is the whole point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: