Meta: Support JSX similar to Literate CoffeeScript?

[GeoffreyBooth]

I’ve been thinking about JSX, and a way that CoffeeScript could perhaps support it. In particular, I’ve been thinking about how it’s actually somewhat similar to Literate CoffeeScript:

• Literate CoffeeScript is essentially a Markdown file that uses indentation to define CoffeeScript code blocks.
• JSX is JavaScript that uses XML open and closing tags to define HTML blocks (that themselves can contain JavaScript, within braces).

I haven’t used JSX in a project, so if I’m oversimplifying here, please correct me.

What if the CoffeeScript compiler detected XML open and closing tags and treated them the same as backticks? In other words, everything from the first < of the first opening tag through to the last > of the last closing tag would be passed through unmodified, similar to embedded JavaScript. The compiler would therefore be outputting JSX, and then the next step in the build chain would be Babel with the JSX transform.

This wouldn’t even be a breaking change. Currently <div> throws unexpected <, and </div> throws missing / (unclosed regex).

We also wouldn’t be favoring one framework over another, because we’re just outputting the straight HTML, not converting it into code like React.createElement. Vue has added support for JSX, and the Babel transform is now generic to allow future frameworks to adopt it, so it’s not a React-specific thing anymore.

How is this different from coffee-react or coffee-react-transform or CJSX, you might ask?

• That project is deprecated, for starters, and is pinned to version 1.9.1 of the compiler.
• It didn’t rely on Babel, compiling straight to the final JavaScript React.createElement output, and therefore was dependant on React; the last version supports “React >= 0.14.x”.
• It aimed to compile CoffeeScript within the XML blocks.

That last point is important. In my proposal, within an XML block you would need to use this.foo, not @foo. You couldn’t write code like coffee-react‘s example {<p key={n}>This line has been printed {n} times</p> for n in [1..5]}—you would need to write the JavaScript equivalent. But I don’t think this is so terrible. In my experience, most of the JavaScript inside a template is very minimal, generally just references to objects or basic constructs like if statements or loops. (Again, please correct me if I’m wrong.) It would be a formidable challenge to parse CoffeeScript within XML tags, which is probably why coffee-react was deprecated; but I don’t think we need to take on that task.

I can certainly see people objecting to this proposal on the grounds that people shouldn’t be forced to use JavaScript, or even snippets of it, within a CoffeeScript file. Fair enough. Another perfectly valid objection is that JSX isn’t hard to achieve right now using plain backticks:

getGreeting = (user) ->
  if user
    `<h1>Hello, {formatName(user)}!</h1>`
  else
    `<h1>Hello, Stranger.</h1>`

---

var getGreeting;

getGreeting = function(user) {
  if (user) {
    return <h1>Hello, {formatName(user)}!</h1>;
  } else {
    return <h1>Hello, Stranger.</h1>;
  }
};

See CoffeeScript and Babel conversions. If we don’t implement this proposal, at the very least we should perhaps at this example to the docs, either in the backticks section or in a new section discussing JSX.

But anyway, now that JSX is growing into a framework-independent standard, and we can support it in a minimal, framework-independent way, should we? And if we should, does this seem like the way to add support for it?

[mrmowgli]

Personally I’m not in favor of it simply from the standpoint of having to make changes to the language just to apease a small segment of the overall javascript ecosystem. It’s definitely not stage 4 ES2015+ ;) While react may be trendy now, it certainly shouldn’t have more merrit than say handlebars and Ember. Especially when it doesn’t add anything usefull to any other workflows. I could get behind a hybrid of pug and coffeescript if I could use it generically with any framework, but even then I wouldn’t want to make changes just for that particular workflow. I would think JSX specific workflows should be another project or possibly another reason to create a plugin system for coffeescript.

[GeoffreyBooth]

@mrmowgli What I’m proposing would work with Handlebars or Ember. That’s the point of passing through HTML blocks as is: it’s independent of any particular templating system.

greet = ->
  <h1>Hello, world!</h1>

would become

var greet;

greet = function() {
  return <h1>Hello, world!</h1>;
};

JSX is just a file format, that defines HTML blocks with JavaScript; similar to how Literate CoffeeScript defines CoffeeScript blocks within Markdown. We would leave it to other steps in the build chain (i.e. Babel with various transforms) to parse the HTML blocks into specific precompiled templates, whether they be React or Vue or Handlebars or something else.

[lydell]

If we're going to support JSX, we should parse it for real. No "passing strings through" hacks.

I think it would make sense to output JSX as well, and let users pass that on to other compilers.

Here's a common example of more complicated JS embedded inside JSX:

<Table>
  {items.map(item => {
    const itemId = item.is_accessory ? item.parentId : item.id;
    const hidden = !allHidden && removedItemIds.indexOf(itemId) >= 0;
    return (
      <ItemRow
        key={item.id}
        item={item}
        quantityOverride={itemQuantityOverrides[itemId] || null}
        className={hidden ? 'js-Hiding is-hidden' : undefined}
      />
    );
  })}
</Table>

[jashkenas]

This has come up before. And I think that we definitely shouldn't add halfassed JSX support to CoffeeScript. Both because if you're going to parse it you should be parsing it for real; and because JSX, as a syntax, is almost diametrically opposed to the spirit of CoffeeScript.

[GeoffreyBooth]

@jashkenas I think you’re a little too harsh. This proposal is “halfassed JSX support” in the same way that backticks are halfassed JavaScript support or that Literate CoffeeScript is halfassed Markdown support. We already have established patterns, in Literate CoffeeScript and backticks, of passing through code to be compiled by other components of a build chain. Just because XML syntax is ugly isn’t a great reason to exclude it as an option.

These XML blocks don’t necessarily have to include JavaScript. Vue uses JSX to embed Vue templates:

new Vue({
  el: '#app',
  data: {
    msg: 'Click to see the message.'
  },
  methods: {
    hello () {
      alert('This is the message.')
    }
  },
  render: function render(h) {
    return (
      <span
        class={{ 'my-class-3': true }}
        style={{ cursor: 'pointer' }}
        on-click={ this.hello }
      >
        { this.msg }
      </span>
    )
  }
});

From this precedent, I can easily see someone extending the Babel JSX transform to support Handlebars and other similar templates. JSX at this point is becoming another hybrid passthrough format like Literate CoffeeScript.

[jashkenas]

Backticks are halfassed JavaScript support, and you're not supposed to use them. They're an emergency escape hatch in times of need.

Literate CoffeeScript is on slightly firmer ground insofar as that it's not trying to mix two different programming languages, with the inter-nested back and forth that requires. It's just top-level prose and code. Let's call it 2/3 assed.

[emilebosch]

Can't we add hooks to the compilation stage to add flavors AKA babel presets?

@jashkenas isn't there some way that we can extend coffee script with JSX. It has always been we're not going to do it, but what IS possible/acceptable for you?

[GeoffreyBooth]

Another approach could be to have a preprocessor like @billymoon’s Illiterate, that detects XML blocks and just wraps them in backticks before passing that to the CoffeeScript compiler, which would then pass to Babel with a JSX transform. Such a preprocessor could even theoretically try to compile CoffeeScript to JavaScript within the XML blocks, if it were ambitious.

I don’t think the “wrap XML blocks in backticks” workaround is so bad, personally. If we’re not going to do any other alternatives I think we should at least document it.

More to the point, though, if we want people to use CoffeeScript it needs to integrate well with popular JavaScript frameworks and the JavaScript ecosystem. Say what you will about JSX, and I agree its very concept is a somewhat hideous idea, but like it or not it’s a significant part of the JavaScript ecosystem now. It’s a reasonable question for people to ask how to use JSX with CoffeeScript, especially since coffee-react has been deprecated. I’m not saying the answer needs to be this proposal, or backticks, or some as-yet-unbuilt preprocessor, but the answer shouldn’t be to just diss JSX as stupid and walk away.

[mrmowgli]

Or how about making a keyword with an external plugin like: extern jsx <input name="etc"> Anything indented under that tag will get parsed by the named external plugin :)

[xixixao]

The power of JSX is that it is a very thin layer on top JavaScript, and you can use full power JS within it and around it. This would only make sense if the JSX support in CoffeeScript was proper:

return
  <span
    class={'my-class-3': true}
    style={cursor: 'pointer'}
    onClick={@hello}>
    {@msg}
  </span>

from your example. I agree that it is very difficult to write a valid CoffeeScript expression that would include JSX, so this could be a non-breaking change. I also agree that the output should be JSX for another preprocessor.

I would also trade x = a<div being invalid CoffeeScript if it helped make the JSX support easier to implement.

I get that JSX seems against CoffeeScript philosophy. It's unnecessarily verbose. But it has evolved to more than it was a couple years ago. It's a compatible syntax which allows different compilation+execution strategy (in React it's essentially a lazy function call).

As such it doesn't really matter that it looks like XML, and I wouldn't mind dropping that (if there was a tool ala js2coffee that would allow easy migration between the two). But you still need syntax that allows "special function calls with named arguments and one unnamed children argument" to meet feature parity (dropping any of these attributes makes it such a small win that it's better to drop to normal CoffeeScript function call syntax with a special naming strategy, like _div here ).

You could try for example:

return
  <div a: 3 b: "x" d: {a: 3} e: [1 2 3]>
    "we might not need the {} around CS expressions"
    <div>
      <Component />

(note that CSX can be simpler because we can rely on indentation, which JSX cannot)

All this said, it would be awesome to have some JSX/CSX support in CoffeeScript. React is hugely influential for client-side (compare Github stars for Ember or handlerbars) and most of today's JS (ECMAScript) transpilers support JSX.

[GeoffreyBooth]

Can anyone familiar with the lexer explain why this doesn’t compile?

a ` = ` 1

---

[stdin]:1:9: error: unexpected number
a ` = ` 1
        ^

I ask because it would make possible code like this:

greet = ->
  `<h1>Hello, ` @user `!</h1>`

@lydell @xixixao

[williamstein]

At my company we write code in CJSX pretty much all day every day (in https://github.com/sagemathinc/smc). So huge +1 to this proposal. We'll surely use what you do; I'm obviously nervous about relying on the deprecated current cjsx project...

[GeoffreyBooth]

@williamstein anyone at your company willing to help code this? 😉 I have an idea for how to approach it, I’m hoping someone answers my question above . . .

[connec]

@GeoffreyBooth I don't know the particulars of why the above doesn't work, but as an interesting data point it does work if you wrap the backticks in parens, but it compiles to a( = (c)). I suspect it might not be directly related to the lexer, but rather that the grammar context for backticked expressions is restricted to places where an arbitrary expression can occur.