I don't think CoffeeScript would benefit much from JSX, since the sugar for function calls and object literals applies well to React. For example, one of the examples from the React page translated to plain CoffeeScript:

JSX:

    <div>
      <h3>TODO</h3>
      <TodoList items={this.state.items} />
      <form onSubmit={this.handleSubmit}>
        <input onChange={this.onChange} value={this.state.text} />
        <button>{'Add #' + (this.state.items.length + 1)}</button>
      </form>
    </div>

CS:

    R.div null,
      R.h3 null, 'TODO'
      TodoList items: @state.items
      R.form onSubmit: @handleSubmit,
        R.input onChange: @onChange, value: @state.text
        R.button null, "Add ##{@state.items.length +1}"

A hypothetical CSX would probably be more along the lines of Haml or Slim than XML syntax (closing tags would be pretty weird and out of place), and plain CS isn't that different from them already.

In CoffeeScript you can use backticks and still use JSX. Example:

    `/** @jsx React.DOM */`
    Todo = React.createClass
      render: ->
        `
        <div>
          <h3>TODO</h3>
          <TodoList items={this.state.items} />
          <form onSubmit={this.handleSubmit}>
            <input onChange={this.onChange} value={this.state.text} />
            <button>{'Add #' + (this.state.items.length + 1)}</button>
          </form>
        </div>
        `

Just remember when compiling the CoffeeScript files to pass the bare, and --no-header flags.

    coffee -bc --no-header todo.coffee

No, that is not sufficient.

The point is getting designers to shift paradigm and start writing React components. This is a major shift, because while the designers I've worked with have all done a little JavaScript here and there, it's seldom much more than copy/pasting some jQuery code from Stack Overflow.

HTML/CSS is their home turf. To you, the CoffeeScript literals might be just as good as the JSX stuff, but to someone who's already out of his comfort zone because the markup is in the middle of all kinds of weird React.createClass stuff, it's a very major difference.

JSX really strikes a sweet spot here.

Is worth notice that there is also: https://github.com/atom/react-coffee.

class Welcome extends Component

  render: ->

    @div ->

      @text "Hello"

      @span @props.name

component = new Welcome(name: "World") element = component.buildElement()</pre>

Can't help you for Typescript, but for Coffeescript I've implemented a basic rewriter for JSX-in-Coffee:

https://github.com/jsdf/coffee-jsx-transformer

Can you tell more what's your tech stack with TypeScript?

Sure. We're building a single page webapp here at http://izooble.com. Our frontend is Model-View-Nothing with React for the view and TypeScript for everything else. We build with gulp, and avoid browserify because it makes debugging more difficult. Therefore, we generate a debug and a production build: the production build simply concats all generated JS, and the debug build keeps the separate JS files with source maps back to the .ts sources. We autogenerate the index.html.

Some of us code TypeScript in Visual Studio, which is awesome. Many just use a text editor and `gulp watch`, though, which works remarkably good as well. I wish there was good TypeScript IDE support on other platforms than Windows. The entire team has previous experience that makes them think strongly in terms of classes and object. TypeScript is a very natural fit for a team like this, and made us productive very fast. Prototypal inheritance, not so sure.

On the backend, we do C#, hosted on Linux with Mono (we have devs running Linux, Mac and Windows, we're just as cross-platform as your average Python shop). We use ServiceStack v3 for the API and PostgreSQL for data. We heavily rely on stored procedures and Postgres-specific features (such as returning cursor sets instead of gigantic joins) for making the backend very lean and simple.

We use Docker for running stuff locally and in production. Our designers just run the backend docker containers locally with a single click (in Vagrant). They never installed Mono or Postgres anywhere.

Is that what you wanted to know?

WebStorm from JetBrains has good TypeScript support. You could look into that as VS alternative.

Another question: our TypeScript compile-times are approaching 5/6 seconds whenever gulp watch triggers. Imo this is too long for a workable frontend workflow. Did you guys find a way to incrementally compile TS with gulp?

No, we did not. Our stack is still on the grow but we're starting to run into the same problem.

That said, we have many small files, so I'm pretty certain that for us, setting up gulp to always only recompile whichever file changed (which we currently don't do) should be good enough. Afaik there's ways to do this with gulp but I did not investigate yet.

Do you guys manage to only recompile changed files?

Thanks for the WebStorm hint! Did not know that!

I tried using https://www.npmjs.org/package/gulp-changed, but couldn't get that to work in the timebox I allowed myself. Also, just passing the changed file to the typescript compiler would probably not work in our case (since we also need to pass in our type definitions in the same compiler pass), and recompiling a single file might lead to errors in a different file importing the changed file that you would miss with this setup...

The tsc executable does have a -watch flag itself for incremental compilation, which presumably takes into account these dependencies. So may be the solution is to use that outside of gulp (since gulp-tsc doesn't seem to be able to launch the compiler in watch mode).

What I'd really like to see is a switch to macros instead of preprocessors, so you could use (almost) arbitrary transformers together. While not always possible, it would at least let one easily mix, say, JSX and generators from different libraries.

You could take a look at https://github.com/andreypopp/sweet-jsx which fences the JSX syntax inside tagged template literal.