7 ms·

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 s

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 <button [style.color]="isSpecial ? 'red' : 'green'"> 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 it, syntax highlight it, format it with tools like Prettier, tree shake it... 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.

Bizarro 8y ago
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.
- rickycook 8y ago
  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
- boubiyeah 8y ago
  what if it being more productive for you has nothing to do with these magic strings? :)
- BigJono 8y ago
  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.
  - daliusd 8y ago
    What's wrong with redux-saga? What alternatives do you offer to solve problems redux-saga helps to solve?
    - korm 8y ago
      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.
      - daliusd 8y ago
        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.
m1sta_ 8y ago
JSX isn't JavaScript. It's JSX.
- phpnode 8y ago
  Why is it not JavaScript? The Ecmascript spec explicitly allows syntax extensions.
  - emn13 8y ago
    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.
    - shawn 8y ago
      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.
  - orange8 8y ago
    Is this valid Javascript: %%$$#~~~~## What if I make it my special js "syntax extension"?
- rickycook 8y ago
  no, but it BECOMES javascript after transpile time
  - m1sta_ 8y ago
    Yep. Just like C code isn't binary code.
emn13 8y ago
I came to write... this. Sure, stringly typed programming is sometimes a quick and dirty solution - and that's fine, even permanently, if you just don't want to invest much in whatever you're doing - which too, is fine. But it's not a good thing. It's cheap and easy, which is sometimes something you need to settle for.
shawn 8y ago
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.
- bryanlarsen 8y ago
  Code may be a string, but tools that treat it as such are universally abhorred, like the C preprocessor or eval in interpreted languages.
lightblade 8y ago
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.
- jaredklewis 8y ago
  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.
  - lightblade 8y ago
    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 https://youtu.be/nXCSloXZ-wc You can skip to 29:34 for the performance demo.
magicalist 8y ago
> 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" :)
- domenicd 8y ago
  +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.
  - dmitriid 8y ago
    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.
    - rickycook 8y ago
      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
    - magicalist 8y ago
      > 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`<div id="foo">hello ${you}</div>` > // output: > React.createElement("div", { id: "foo" }, "hello ", you) options https://www.npmjs.com/package/babel-plugin-htm https://www.npmjs.com/package/babel-plugin-htm
snek 8y ago
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.
- dmitriid 8y ago
  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.
  - snek 8y ago
    its actually more like tag`string ${x}` is tag(['string', ''], x)
forrest92 8y ago
Then don't do that. Write a method to get the list id. And FWIW I honestly think JSX is misstep.
boubiyeah 8y ago
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?
ttty 8y ago
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!
kgwxd 8y ago
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 \".
cztomsik 8y ago
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

Bizarro 8y ago

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.

rickycook 8y ago
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
boubiyeah 8y ago
what if it being more productive for you has nothing to do with these magic strings? :)
BigJono 8y ago
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.
- daliusd 8y ago
  What's wrong with redux-saga? What alternatives do you offer to solve problems redux-saga helps to solve?
  - korm 8y ago
    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.
    - daliusd 8y ago
      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.

m1sta_ 8y ago

JSX isn't JavaScript. It's JSX.

phpnode 8y ago
Why is it not JavaScript? The Ecmascript spec explicitly allows syntax extensions.
- emn13 8y ago
  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.
  - shawn 8y ago
    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.
- orange8 8y ago
  Is this valid Javascript: %%$$#~~~~## What if I make it my special js "syntax extension"?
rickycook 8y ago
no, but it BECOMES javascript after transpile time
- m1sta_ 8y ago
  Yep. Just like C code isn't binary code.

emn13 8y ago

I came to write... this. Sure, stringly typed programming is sometimes a quick and dirty solution - and that's fine, even permanently, if you just don't want to invest much in whatever you're doing - which too, is fine. But it's not a good thing. It's cheap and easy, which is sometimes something you need to settle for.

shawn 8y ago

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.

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

lightblade 8y ago

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.

jaredklewis 8y ago
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.
- lightblade 8y ago
  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 https://youtu.be/nXCSloXZ-wc You can skip to 29:34 for the performance demo.

magicalist 8y ago

> 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" :)

domenicd 8y ago
+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.
- dmitriid 8y ago
  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.
  - rickycook 8y ago
    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
  - magicalist 8y ago
    > 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`<div id="foo">hello ${you}</div>` > // output: > React.createElement("div", { id: "foo" }, "hello ", you) options https://www.npmjs.com/package/babel-plugin-htm https://www.npmjs.com/package/babel-plugin-htm

snek 8y ago

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.

dmitriid 8y ago
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.
- snek 8y ago
  its actually more like tag`string ${x}` is tag(['string', ''], x)

forrest92 8y ago

Then don't do that. Write a method to get the list id. And FWIW I honestly think JSX is misstep.

boubiyeah 8y ago

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?

ttty 8y ago

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!

kgwxd 8y ago

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

cztomsik 8y ago

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