We use React for view components, and TypeScript for everything else. The ES6 class syntax would be great for us, because it'll allow our view code to look more like our TypeScript code, and still work in all browsers (because we already use the JSX compiler anyway).
Nevertheless, a simple way to put JSX inside TypeScript code would be even cooler (and I suspect that CoffeeScript people might have similar feelings wrt JSX).
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>
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}"
`/** @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>
`
coffee -bc --no-header todo.coffeeclass Welcome extends Component
render: ->
@div ->
@text "Hello"
@span @props.name
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.
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?
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?
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!
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).