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

81–90 of 93 posts

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

#81

Post by [deleted] »

madeofpalk wrote: post #70
magicalist wrote: post #34

Earlier quoted context omitted.

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

[deleted]

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

#82

Post by daliusd »

BigJono wrote: post #79
Bizarro wrote: post #59

Earlier quoted context omitted.

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.

I'm calling bullshit on all these claims of "massive productivity boosts" when switching to Vue. What on earth were you doing in React that was so unproductive? Maybe if you're bogging yourself down with a bunch of absolute garbage like immutable and redux-saga, but you can hardly blame React then.

What's wrong with redux-saga? What alternatives do you offer to solve problems redux-saga helps to solve?

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

#83

Post by korm »

daliusd wrote: post #82
BigJono wrote: post #79

Earlier quoted context omitted.

I'm calling bullshit on all these claims of "massive productivity boosts" when switching to Vue. What on earth were you doing in React that was so unproductive? Maybe if you're bogging yourself down with a bunch of absolute garbage like immutable and redux-saga, but you can hardly blame React then.

What's wrong with redux-saga? What alternatives do you offer to solve problems redux-saga helps to solve?

I assume the point is that some people bog themselves down with tools that make them less productive just because they read that it's best practice, without deeper understanding.

For example, in most threads about Vue on Reddit, the fact that you can just add Vue as a script tag and start working with it is it's most frequently cited advantage.

A small app, especially for most newbies just starting out, doesn't need webpack. But obviously they didn't read the docs and didn't even try the same with React. They just went straight for webpack, even though they shouldn't have. Not to mention CRA exists.

Same with immutable and saga. Their benefits are apparent in much bigger applications, and even then there are arguably simpler and better tools like Immer, update-immutable, redux-thunk, redux-promise-middleware or even rolling out your own middleware.

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

#84

Post by daliusd »

korm wrote: post #83
daliusd wrote: post #82

Earlier quoted context omitted.

What's wrong with redux-saga? What alternatives do you offer to solve problems redux-saga helps to solve?

I assume the point is that some people bog themselves down with tools that make them less productive just because they read that it's best practice, without deeper understanding. For example, in most threads about Vue on Reddit, the fact that you can just add Vue as a script tag and start working with it is it's most frequently cited advantage. A small app, especially for most newbies just starting out, doesn't need…

Why beginner would try that with React? Official documentation does not even offer this approach. Meanwhile Vue.js official documentation gives basics first with this approach.

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

#85

Post by dmitriid »

atombender wrote: post #55
dmitriid wrote: post #42

Earlier quoted context omitted.

> These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc. Optimize, compile etc. what ? f`string` is literally a function call f("string"). What exactly are you "compiling and optimizing"?

No, that's incorrect. Interpolations (${}) are preserved. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Let's return to the original statement, shall we?

> These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc.

So. How exactly do they "work as code" and "have support to optimize it, compile it, etc."?

Here's HTM's main function https://github.com/developit/htm/blob/master/src/index.mjs#L...

It: concatenates strings, parses (via regexes), then concatenates again. Can someone enlighten me as to why this is awesome, is code, is optimized and compiled?

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

#86

Post by dmitriid »

spankalee wrote: post #54
dmitriid wrote: post #50

Earlier quoted context omitted.

Yeah, I'll let Javascript engines parse and convert my Javascript to bytecode for me. It's definitely not the same as manually parsing strings at runtime. And equating the two is disingenuous at best

Type-checking happens at compile time, and even the JS is parsed by a user-land library and not the JS engine. At runtime these templates are parsed by the browser's built-in HTML parser.

> Type-checking happens at compile time, and even the JS is parsed by a user-land library and not the JS engine.

True. Still, it's functions and regular JS, not strings manually processed at runtime

> At runtime these templates are parsed by the browser's built-in HTML parser.

It's not the first time I've seen this ... bullshit (no other word for it). Where does it come from?

The only time it's parsed by browser's built-in HTML parser is when you manually call something like `element.innerHtml = "you string that you manually assembled in your function at runtime"`.

The browser has no idea what is contained in your tagged string. Which is painfully obvious when you actually look at the implementations of HTM: https://github.com/developit/htm/blob/master/src/index.mjs#L... or lit-html: https://github.com/Polymer/lit-html/blob/master/src/lib/temp...

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

#87

Post by dmitriid »

magicalist wrote: post #66
dmitriid wrote: post #49

Earlier quoted context omitted.

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

It's (marginally) better than having it at runtime. Poor man's macros. Much like JSX in a sense, though JSX is a much thinner abstraction IMO.

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

#88

Post by cztomsik »

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 is not Javascript, you need to transpile, and not everybody wants to mess with webpack+babel or create-react-app, or anything other what involves downloading 1000+ packages from npm just to do some quick PoC. Sometimes you want to stay light (and fast), and incrementally build your stack, just you like can do with vue.

So I actaully like this project, thanks for this :-)

BTW: it's similar to lit-html, t7 and hyperx

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

#89

Post by wild_preference »

dmitriid wrote: post #85
atombender wrote: post #55

Earlier quoted context omitted.

No, that's incorrect. Interpolations (${}) are preserved. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Let's return to the original statement, shall we? > These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc. So. How exactly do they "work as code" and "have support to optimize it, compile it, etc."? Here's HTM's main function https://github.com/developit/htm/blob/master/src/index.mjs#L... It: concatenates strings, parses (via regexes), then c…

They're just talking about https://www.npmjs.com/package/babel-plugin-htm.

> A Babel plugin that compiles htm syntax to hyperscript, React.createElement, or just plain objects.

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

#90

Post by lucideer »

> Improvements over JSX

With the exception of html comments, these are invariably antifeatures. Optional quotes/closing tags save zero to negligible typing time in exchange for added complexity for tooling and reduced readibility in many circumstances.

I can understand why these features were added to HTML5 (backward compatibility is of more benefit than prescriptivism) but I would never have thought anyone would argue that having these features in HTML1 was a good idea in retrospect!?

Adding them to a new syntax that isn't burdened with backward compat requirements seems daft.

Post reply on HN