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

61–70 of 93 posts

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

#61

Post by bcherny »

spankalee wrote: post #48
dmitriid wrote: post #43

Earlier quoted context omitted.

Well, you can skip JSX, and write functions only, and you'll have full support. https://reactjs.org/docs/react-without-jsx.html It's functions all the way down, after all. How do you write a type checker for something that is a string (HTM, lit-html)?

You parse the string literal, just like you parse the string that is the contents of a JavaScript file.

You could definitely do that (Angular recently started doing this too!). I think once there is a way to enforce compile time safety for HTM, it’ll be a lot more appealing for TypeScript/Flow folks.

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

#62

Post by rickycook »

Bizarro wrote: post #59
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…

I wrote React for a couple years and was pretty dogmatic against the whole "stringy code" thing. Obviously and generally, we'd rather write code not in strings. But guess what? Moving to Vue from React was a major productivity boost for us - "stringy code" and all.

that as the case may be, id say that was in spite of the “stringy code”. the point (i think) is that this, and JSX are functionally the same thing, but there are some very large issues with doing this in a string.

*edit: clarity

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

#63

Post by rickycook »

dmitriid wrote: post #49
domenicd wrote: post #39

Earlier quoted context omitted.

+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.

The fundamental difference is what you have in the end. With JSX you have function calls (JSX is a very thin DSL after all). With tagged literals you end up with runtime string parsing and concatenation.

and i think this is the point; runtime vs compile time! similar reasons that people love the popular new type systems... if it compiles, it probably works or you get an error rather than pushing that later and possibly not catching it

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

#64

Post by rickycook »

m1sta_ wrote: post #22
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…

JSX isn't JavaScript. It's JSX.

no, but it BECOMES javascript after transpile time

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

#65

Post by leowoo91 »

mrweasel wrote: post #38
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.

Young is just learning it hardway, we all have been there. Creating walls of abstractions as well as enduser's greed for edgy feel that is turning into easy profit.

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

#66

Post by magicalist »

dmitriid wrote: post #49
domenicd wrote: post #39

Earlier quoted context omitted.

+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.

The fundamental difference is what you have in the end. With JSX you have function calls (JSX is a very thin DSL after all). With tagged literals you end up with runtime string parsing and concatenation.

> The fundamental difference is what you have in the end. With JSX you have function calls

Check out the output of the Babel plugin mentioned in the readme

> // input:

> html`hello ${you}`

> // output:

> React.createElement("div", { id: "foo" }, "hello ", you) options

https://www.npmjs.com/package/babel-plugin-htm

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

#67

Post by rickycook »

spankalee wrote: post #31
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.

well no... it’s type checked because it’s transpiled to a function

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

#68

Post by bcherny »

ricardobeat wrote: post #52
bcherny wrote: post #10

Earlier quoted context omitted.

My opinion, not a fact. Before JSX came out, there were tons of templating systems that let you embed HTMLish things in JS: Handlebars, Mustache, EJS, Pug, Angular templates. JSX’s big innovation was taking the way XHP promoted HTML to first class syntax and applying it to JS. The big difference between that and the template systems that came before it is JSX is statically analyzable (by your type checker, or by othe…

What I was thinking is that you're backdating your impressions. JSX came out in 2013, when TypeScript was at it's infancy, and also predates flow; support for JSX in the TS compiler was only added in late 2015. You're right that when it came out it's main innovation was separation of concerns and composability, but types or static analysis were not part of the value proposition at the time.

You know, I think that’s a really fair way to look at it. I would be surprised, though, if down the line type safety wasn’t a design goal. It did come from the same company that built XHP around 2010, and the same dude that built the first React prototypes in OCaml. I can ask around after the holidays and see if anyone remembers :)

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

#69

Post by allover »

mrweasel wrote: post #38
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.

You can use Jinja-style templates client-side too if you want (see nunchucks).

But client-side rendering and server-side rendering have different use-cases. It doesn't come down to just which is 'particularly readable'.

> If you absolutely must do JavaScript you should keep it separate of your HTML and other stuff

Why? This argument has been lost. If you're writing a rich client-side UI that makes sense to be "component-oriented", there is literally zero value in splitting each component into HTML and JS, it is a completely arbitrary 'separation by technology'.

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

#70

Post by madeofpalk »

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…

> These are tagged templates, not strings

Tagged templates are strings.

Post reply on HN