Earlier quoted context omitted.
JSX isn't JavaScript. It's JSX.
Why is it not JavaScript? The Ecmascript spec explicitly allows syntax extensions.
Is this valid Javascript: %%$$#~~~~##
What if I make it my special js "syntax extension"?
Hyperscript Tagged Markup: JSX alternative using standard tagged templates
51–60 of 93 posts
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#52Earlier quoted context omitted.
> typesafety was the main benefit of JSX Do you have a source for that?
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.
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#53The 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…
to give a clear answer here, tagged templates don't actually perform string concat. the function being used as the tag receives an array of the string literals, and the rest of the arguments as the values passed in templates, and can perform any processing it wishes at that point. I've seen some js sql libraries actually using this to prevent people from having the exact problem you're complaining about.
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#54Earlier quoted context omitted.
You parse the string literal, just like you parse the string that is the contents of a JavaScript file.
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.
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#55Earlier 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. 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...
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#56Nice try, Angular.
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#57The 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…
to give a clear answer here, tagged templates don't actually perform string concat. the function being used as the tag receives an array of the string literals, and the rest of the arguments as the values passed in templates, and can perform any processing it wishes at that point. I've seen some js sql libraries actually using this to prevent people from having the exact problem you're complaining about.
However, the main darling of tagged templates, lit-html does exactly that: parsing, concatenating, then doing an element.innerHtml
So does HTM we discuss here.
I quickly googled. sql-tag and node-sql-template-strings do a lot of string concatenation (well, of course, they have to create a SQL statement out of values passed in). sql-template parses and concatenates.
Because it's really basically all you can do, be cause tag`string` is just a function call tag("string"). There's no magic.
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#58Earlier quoted context omitted.
to give a clear answer here, tagged templates don't actually perform string concat. the function being used as the tag receives an array of the string literals, and the rest of the arguments as the values passed in templates, and can perform any processing it wishes at that point. I've seen some js sql libraries actually using this to prevent people from having the exact problem you're complaining about.
However, the main darling of tagged templates, lit-html does exactly that: parsing, concatenating, then doing an element.innerHtml So does HTM we discuss here. I quickly googled. sql-tag and node-sql-template-strings do a lot of string concatenation (well, of course, they have to create a SQL statement out of values passed in). sql-template parses and concatenates. Because it's really basically all you can do, be cau…
its actually more like tag`string ${x}` is tag(['string', ''], x)
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#59The 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.
Re: Hyperscript Tagged Markup: JSX alternative using standard tagged templates
#60This 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.
I think type safety was a core design constraint for JSX (since XHP — where JSX came from — is typechecked, after all). It’s also nice to be able to do this checking with the type system you already have (TS, Flow, Reason), rather than having to install extra tooling that has to then interoperable with each of these type systems.