
TypeScript and JSX - dkarapetyan
http://www.jbrantly.com/typescript-and-jsx/
======
beefsack
I'm still yet to be convinced that JSX is a good idea, why break existing
tooling and significantly complicate parsers for what appears to only be a
minor convenience at the surface level?

Mithril manages similar functionality without any modifications to syntax.

[https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/)

~~~
Offler
Mithril appears harder to read than equivalent JSX.

const links = ctrl.pages().map(page => <a href={page.url}>{page.title}</a>);

return <div> {links} <button onClick={ctrl.rotate}> Rotate Links </button>
</div>;

Compared to

    
    
    		m("div", [
    			ctrl.pages().map(function(page) {
    				return m("a", {href: page.url}, page.title);
    			}),
    			m("button", {onclick: ctrl.rotate}, "Rotate links")
    		]);
    

I can see what the UI will be with JSX at a glance with Mithril I have to
parse the code.

edit: Mind you both look awful due to HNs poor formatting ability. Honestly
how did this website become so popular with tech people?

~~~
pygy_
With proper indenting and similar formatting:

React:

    
    
        const links = ctrl.pages().map(page => <a href={page.url}>{page.title}</a>);
    
        return <div> {links} <button onClick={ctrl.rotate}> Rotate Links </button> </div>;
    

Mithril:

    
    
        const links = ctrl.pages().map(page => m("a", {href: page.url}, page.title));
    
        return m("div", [links, m("button", {onclick: ctrl.rotate}, "Rotate links")]);
    

There are JSX equivalents for Mithril too (for both Babel and standalone JSX).

Mithril templates look also very good in CoffeeScript and similar languages.

~~~
rch
I don't use either framework, but for whatever reason I find the Mithril
example markedly easier to read. This is simply a matter of taste.

~~~
jhall1468
It's only easier to read because it meets your expectations since it looks
"javascripty", but absolutely not as easy to reason about.

Both of those snippets are intended to generate HTML. In that sense there's no
question which one is easier to reason about/read.

~~~
Nemcue
Not easier to reason about?

I would argue the opposite — it is _immediately_ easier to reason about, since
I see what functions are called, and I can go look up the documentations for
those functions without having to go through a precompile-step.

~~~
omphalos
Yes and additionally (with Chrome's DevTools) you get out-of-the-box
functionality like the ability to set a break point, live edit your code right
at the breakpoint, and save your change right back to the filesystem. With
transpiled languages this kind of workflow is generally less streamlined -- I
don't know why more people don't complain about it. The best alternatives I've
seen are when people completely reengineer the workflow - I'm thinking about
the Elm debugger as an example.

~~~
rch
Thanks - I hadn't even thought about that aspect, but it's definitely a
problem I would run into. As popular as React is though, I'd assume there is a
browser extension or something to support the workflow.

~~~
mmebane
Indeed there is: [http://facebook.github.io/react/blog/2015/09/02/new-react-
de...](http://facebook.github.io/react/blog/2015/09/02/new-react-developer-
tools.html)

------
drinchev
That's cool. I'm trying to use it right now. What I don't like so far is :

1\. Lack of definition files for some isomorphic flux implementations ( like
yahoo/fluxible ) ;

2\. Lack of big projects written with TSX to learn from ;

3\. No support in WebStorm ( even 11 EAP, dated 09.09.2015 ) for TSX files ;

With No. 1. as most annoying I would recommend for anyone trying to do
isomorphic NodeJS + TypeScript app to be really patient and to expect writing
commits to DefinitelyType repo.

Kudos for TypeScript team for implementing TSX it would be great when it's out
of beta.

~~~
wereHamster
Note that you don't _need_ the declaration files. They are entirely optional.
You can get started right now and add them gradually as they get written by
the community.

~~~
drinchev
I usually write the declaration files that I need and submit to the repo. It's
not that hard :) and your app feels kinda 'complete'.

I would take the opportunity to address the DefinitelyType repository issues.

Actually if anyone from TypeScript team reads this, they should know people
there are struggling with that.

There are multiple flaws in gathering so much development code under one roof
and a lot of discussion that goes nowhere [1][2][3]. What would be great if
there is some sort of "native" support / recommendation of definition files.

1 :
[https://github.com/borisyankov/DefinitelyTyped/issues/5040](https://github.com/borisyankov/DefinitelyTyped/issues/5040)
2 :
[https://github.com/borisyankov/DefinitelyTyped/issues/2150](https://github.com/borisyankov/DefinitelyTyped/issues/2150)
3 :
[https://github.com/borisyankov/DefinitelyTyped/issues/4513](https://github.com/borisyankov/DefinitelyTyped/issues/4513)

~~~
jbrantly
FWIW, there is better support[1] in 1.6 for definition files for node modules.
TypeScript can now read definitions directly out of node_modules. As library
authors include those in the package there will be less of a dependency on
getting definitions from DefinitelyTyped. This obviously doesn't solve all
problems but I think the point is the TS team is aware of some of the issues
and is taking steps to address.

1\.
[https://github.com/Microsoft/TypeScript/pull/4352](https://github.com/Microsoft/TypeScript/pull/4352)

~~~
drinchev
Thanks for that, I didn't notice this is coming :)

------
serichsen
I see two problems with the basic idea of JSX:

\- Parsing is a mess, it is not even obviously unambiguous.

\- HTML syntax is horrible, and all templating language attempts building on
it are verbose and clumsy.

That is the negative argument (“That is crap”), but there is also a positive
argument (“Here is a much better alternative”):

You can express HTML structure in a concise and relatively readable manner in
plain JavaScript, and you do not need a 400 kb interpreter nor a separate
compilation step for it!

    
    
        ['div', {'class': 'foo'},
          'some text',
          ['span', {}, 'yay']]
    

You also can embed "directives" or "components" in a rather obvious and
unambiguous way:

    
    
        ['div', {'class': 'container'},
          [MyConstructor, {'arg': foo()}]]
    

Implementing a robust interpreter for this is a matter of perhaps 50 to 100
lines of plain JavaScript.

~~~
feedjoelpie
The big advantage of JSX to my company is that our design team, which does
design in the browser, has a much shorter leap to understanding it than plain
JavaScript. These suggestions of "JSX sucks, you can express this in plain JS"
always leave people with those skill sets behind. Sure it would be really
awesome if the designers were also serious JS programmers, but that's not why
we hired them, and with JSX they don't need to be.

~~~
nine_k
I honestly do not see how much effort would it take to get from <foo
bar="baz">Quux</foo> syntax to ["foo", {bar: "baz"}, "Quux"] syntax. I believe
someone already working with code (HTML, CSS) should be perfectly capable to
learn this transformation in well under 15 minutes.

------
hokkos
I would be interested to know about the difference with TypeScript and Flow,
which can do the most ES6/7 things, which has the most expressive type system.

~~~
dominotw
> which has the most expressive type system.

Elm?

------
sparaker
This is great news without a doubt, Does anyone know what is the direction
Typescript is headed now that ES6 is becoming increasingly supported?

~~~
ane
It's just going to keep getting more features from ES6 and ES7. Some of the
features in ES6/7 were taken from TypeScript, I reckon.

[https://github.com/Microsoft/TypeScript/wiki/Roadmap](https://github.com/Microsoft/TypeScript/wiki/Roadmap)

------
Renaud
wow, that, plus the VS2015 support for JSX syntax amount to great tooling.

Being able to use JSX in Typescript is a big deal, if only for the compile-
time checking you get for free.

------
toxicFork
I may just use it for compile time prop validation! Amazing. I was looking for
that feature alone using eslint and so on but couldn't find anything like
that. Since the compile speed improvements I'm running out of excuses not to
use TypeScript in my projects now.

------
arm55
This is pretty awesome. React and typescript have independently improved my
opinion of javascript - now we get to use them together.

------
danjc
This is awesome! TypeScript has been tremendously useful to us and it's great
to finally be able to use React properly.

------
guscost
Great news. I've been avoiding JSX at work in order to get TypeScript support,
and it will be a nice option to have in the future. Now we just need to
upgrade from VS2012 (that version is still on TypeScript 1.0, so a lot of the
DefinitelyTyped definitions don't work out of the box).

