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

Hyperscript Tagged Markup: JSX alternative using standard tagged templates

github.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#31

Post by spankalee »

bcherny wrote: post #3

This is a neat syntax, but it doesn’t seem at all typesafe (typesafety was the main benefit of JSX over the various string templates that came before it).

JSX is only type-checked because someone wrote a type-checker for it.

It's completely possible to write a type-checker for HTML templates like lit-html. In TypeScript we even have access to third-party extensible interfaces for all the elements with the HTMLElementTagNameMap, so we can check buildings to properties.

We'll be working on a lit-html type-checker for TypeScript early next year.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#33

Post by shawn »

emn13 wrote: post #29
phpnode wrote: post #24

Earlier quoted context omitted.

Why is it not JavaScript? The Ecmascript spec explicitly allows syntax extensions.

I'm not javascript syntax, especially if you're being pedantic, but focusing on that is kind of missing the point, which is that it's tool friendly in the way string interpolation is not.

Intellij automatically highlights HTML syntax inside grave quotes, so this argument doesn't seem to apply here. Emacs likely has a similar feature. I don't know about Atom or Sublime, but HTML entity interpolation within grave quotes is an extremely common tooling feature.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#34

Post by magicalist »

stevebmark wrote: post #20

The nice thing about React, vs others like Vue and Angular, is that we've learned not to write code in strings. You'd think this would be a fundamental law of software engineering, but we keep seeing things like v-bind:id="'list-' + id" or or this. Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimize it, compile it, validate i…

> Writing code, not strings, means you can do everything to it that you can do to code.

These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc. This is JS all the way down. And spankalee mentioned below they're adding typescript support to type check the very similar lit-html, so that's coming too.

> That's why I like JSX, it's Javascript all the way down. Everything is code. It's a very well designed and thought out DSL.

It's also kind of a weird to highlight all this for a DSL that actually has to be parsed from a string to get it to be Javascript. Everything else you're talking about is tooling that had to be built special for it, not the language itself.

Why not just say "I like the style of jsx embedding and existing tools better" :)

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#35

Post by reificator »

simlevesque wrote: post #26
dixie_land wrote: post #15

TIL https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I'm not a JavaScript developer so this is news to me, very neat feature!

Here's a list of tagged template literals: https://github.com/declandewet/common-tags

Which brings up a question: Is it possible to have multiple tags on a given string? Composing smaller helpers would be nice, but I don't see how the syntax would work.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#36

Post by simlevesque »

reificator wrote: post #35
simlevesque wrote: post #26

Earlier quoted context omitted.

Here's a list of tagged template literals: https://github.com/declandewet/common-tags

Which brings up a question: Is it possible to have multiple tags on a given string? Composing smaller helpers would be nice, but I don't see how the syntax would work.

You'd just need to create a meta tagged litteral function. tagged litteral can accept parameters.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#37

Post by mattbierner »

I’ve written tooling to support lit-html and styled-components in editors. Template strings are sort of nice to write but complete pain to support in editors. They are just like a macro language, so you end up with stuff like: `...` which is not possible in jsx. Even just detecting syntax errors is a pain

Obviously if deciding between making life easy for editor implementers or making life easier for coders, the coders win, but if something is unnecessarily difficult to build good tooling for, that’s a sign of poor design in my book. And coders will ultimately suffer too because their tooling will suck and because their code will make use of all the crazy flexibility the library allows.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#38

Post by mrweasel »

leowoo91 wrote: post #13

Can we go back to Jinja now?

Maybe it's just me being an old man at this point but I still dislike doing templating in JavaScript. It's not natural. I want Jinja2 and server side rendering. If you absolutely must do JavaScript you should keep it separate of your HTML and other stuff... again maybe I'm just getting old.

Honestly I don't find neither JSX, or this new alternative particularly readable.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#39

Post by domenicd »

magicalist wrote: post #34
stevebmark wrote: post #20

The nice thing about React, vs others like Vue and Angular, is that we've learned not to write code in strings. You'd think this would be a fundamental law of software engineering, but we keep seeing things like v-bind:id="'list-' + id" or or this. Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimize it, compile it, validate i…

> Writing code, not strings, means you can do everything to it that you can do to code. These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc. This is JS all the way down. And spankalee mentioned below they're adding typescript support to type check the very similar lit-html, so that's coming too. > That's why I like JSX, it's Javascript all…

+1. It's all strings (of source code) in the end. It's just a matter of how well the tools support those strings.

There exists a medium-sized ecosystem of tools which supports static checks on strings inside angle brackets, a la JSX. There is a smaller-but-growing ecosystem of tools that supports static checks on strings inside backticks, a la HTM/lit-html/etc. There's no fundamental difference here.

Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates

#40

Post by jaredklewis »

lightblade wrote: post #30
stevebmark wrote: post #20

The nice thing about React, vs others like Vue and Angular, is that we've learned not to write code in strings. You'd think this would be a fundamental law of software engineering, but we keep seeing things like v-bind:id="'list-' + id" or or this. Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimize it, compile it, validate i…

When you write JavaScript, you can only optimize it..as JavaScript. It still needs to be parsed, compiled, and optimized as JavaScript. When you write templates, you get more room for optimization. Glimmer engine compiles templates to binary bytecodes to bypass JavaScript parsing. Vue3 inlines component fragments as part of the compilation step.

Not sure I follow.

Glimmer compiles to bytecode, but I am not sure how that “bypass[es] JavaScript parsing” as the bytecode is evaluated by a runtime written in JS (which is obviously parsed) and that translates the bytecode into JS calls. Basically one type of parsing has been replaced with another, which is fine though not obviously faster.

Likewise, I don’t see the point with Vue since again vue templates are translated into JS calls.

Or you could just make JS calls, like React does, no runtime translation required.

Post reply on HN