Live data from Hacker News

Hyperscript Tagged Markup: JSX alternative using standard tagged templates

github.com

71–80 of 93 posts

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

#71

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…

Then don't do that.

Write a method to get the list id.

And FWIW I honestly think JSX is misstep.

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

#72
I remember when everyone suggested their own way of s-expressions (basically) to avoid having to write superfluous end-tags and other XML/HTML tchotchkes, now we're getting multiple ways to get all the markup boilerplate into our programming language.

Sometimes it's weird how tastes change. Same thing happened with the nigh universal hacker-ish dislike of "bondage and discipline" languages, now it's enforced formatting wherever you look.

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

#73

Earlier quoted context omitted.

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

Yes, the runtime needs to be JavaScript.

It’s not obviously faster, but it’s been benchmarked to be faster. https://youtu.be/nXCSloXZ-wc

You can skip to 29:34 for the performance demo.

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

#74
post #27

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. You can type check code. You can lint it. You can optimize it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it... Both intellij and emacs do all of these things for Vue code. That seems to cover >90% of developers' tooling needs. Also, code itself is a string. Code is data.

Code may be a string, but tools that treat it as such are universally abhorred, like the C preprocessor or eval in interpreted languages.

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

#75
post #59

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.

what if it being more productive for you has nothing to do with these magic strings? :)

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

#76

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 agree with the general sentiment.

The difference is even more pronounced once you start typing your code.

TS/TSX = 100% typed

arbitrary template DSL = 0% typed

and now these string template based on interpolation = 5% typed: Only the dynamic values inside ${} expressions are "typed", but there are no coherence checks. DOM attribute names and values remain untyped

In the absence of any real advantage for string templates, why even bother?

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

#77

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…

Thanks, I was coming here to say how a bad idea is this thing. Totally agree with you, I can't understand why people still like write magic. I like your comparison strings Vs code. I'll steal that!

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

#78

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…

If I find myself doing something like that in Vue, I immediately make it a computed property. Granted, v-bind:id="something" is still markup that has little chance of being well understood by the IDE, but at least there isn't much to get wrong, and I don't have to remember if I need ', ", \', or \".

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

#79
post #59

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.

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.

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

#80
post #72

I remember when everyone suggested their own way of s-expressions (basically) to avoid having to write superfluous end-tags and other XML/HTML tchotchkes, now we're getting multiple ways to get all the markup boilerplate into our programming language. Sometimes it's weird how tastes change. Same thing happened with the nigh universal hacker-ish dislike of "bondage and discipline" languages, now it's enforced formatti…

There's so much money in web apps now that your average team is flooded with mediocre devs. These joints need "bondage and discipline" languages and frameworks to be productive. It's better business value to have your 50 work-a-day devs productive than your 2 rockstars.
Post reply on HN