TypeScript and JSX | Hacker News Reader

TypeScript and JSX

jbrantly.com

137 pointsdkarapetyan47 comments

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/

I really like the simplicity of mithril with regards to expressing the view. It's less verbose than jsx, and even less verbose than html. You cant think of it as a tree of minimalistic functions organized in a JSON structure. Also, you can use regular javascript control flow in the view, that's awesome.

You can also use regular JS control flow within JSX. That's the point.

`m()` actually outputs plain JS objects.

    m(".hello", 'world')

outputs

    {"tag":"div","attrs":{"className":"hello"},"children":["world"]}

The security test on that page isn't correct for Backbone. Underscore's templating (what is used) has two modes, `<%- %>` will output escaped (what should be used in that demo) and `<%= %>` will output raw

Is the only difference really that Mithril has replaced "React.createComponent" with "m"?

The limitations of creating the view in JS seem invisible, yet visceral to us. I think the reason it is jarring is a fundamental expressivity problem of JS not being able to match templating logic of Handlebars like for-loops and conditionals, despite JS having these statement constructs.

An elegant templating solution is a result of Lisp's mixing of data and logic, something called Hiccup in the ClojureScript community, which I've written about here [1].

[1]: https://github.com/shaunlebron/jumping-from-html-to-clojures...

JS is not a templating language and I'm pretty sure you know this already. PHP on the other hand started as a templating language for the web and then grew from there.

Handlebars is an application of JS (Node) for templating engines and so is Jade. Even though I still prefer Jade over Handlebars for mostly static/frontend oriented web apps.

For people big on JSX, can they tell us please what do they like most about this framework that they don't find equivalents for in Jade or Handlebars for example?

I'd be interested in hearing what you think about the article I linked then. Jade is so close to Hiccup, except you can use it alongside your code.

Jade/Handlebars don't map to React components.

Jade can be used along with code too. I think that you mean view logic by code here as mixing business logic with your view is a big no no.

I took a look at Hiccup. It looks interesting and promising but I'm an indentation oriented developer and that's why I favor Jade and Sass and the likes.

Also, I like the design philosophy that they chose with Jade by absorbing JS in HTML and not the other way around like in JSX where HTML & CSS being subordinates to JS thus making the process a whole lot more tedious and time-consuming.

to Notnow:

> Jade can be used along with code too. I think that you mean view logic by code here as mixing business logic with your view is a big no no.

Code is data. Separating concerns by using different technologies to solve the same problem is not simplification. You can separate views from logic as you would separate different functions in code. We can organize that.

> I took a look at Hiccup. It looks interesting and promising but I'm an indentation oriented developer and that's why I favor Jade and Sass and the likes.

Not liking Hiccup because you prefer indentation doesn't make sense. Hiccup is indented by convention. If you're speaking about the delimiters, those are what keeps it from slipping into limitations shared by JS, Jade, etc.

> Also, I like the design philosophy that they chose with Jade by absorbing JS in HTML and not the other way around like in JSX where HTML & CSS being subordinates to JS thus making the process a whole lot more tedious and time-consuming.

You don't need to choose an absorption direction between JS and HTML if you treat HTML as what it is, a nested data tree, and realize that templating is the mixing of logic into this data tree. S-expressions in Lisp were designed exactly for this.

One big feature in my mind — and I've used both Handlebars, Mustache, and HTMLbars a lot — is the fact that it compiles straight down to a JS data structure.

Especially with Handlebars it's always kind of tricky to debug, because there are all sorts of strange conventions going on, and it ends up being very hard to mentally parse.

With JSX (of course the same with Mithril) you get a data structure that is very easy to reason about.

> Is the only difference really that Mithril has replaced "React.createComponent" with "m"?

The Mithril `m()` was designed to be used as is rather than as a serialization format.

It also understands `m("input.bar[type=date]")` which is handy, and the array for children elements is optional (`m(...)` is variadic) which makes it nicer in CoffeeScript-like languages.

"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?"

Because the template is already so coupled with the view logic that you might as well put them in the same place.

And when we've reached that point, it make sense to make the template as legible as possible. Hence JSX.

Also, no one is forcing you to have the JSX and views in the same file. You could have them be separate, with a different file prefix (.jsx) for the template and not break any existing tooling.

And lastly, https://github.com/insin/msx (Mithril + JSX) is also a thing.

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?

That is because you're used to JSX. They are equivalent to me, and — disregarding the fact that you used arrow functions in one and not the other — equally easy to read.

What would make it "hard" to read? The fact that the third argument is the text?

That's just a tiny convention.

Or use a language that makes it trivial to mix data with logic, so you end up with something like Jade/Haml but with the power of macros.

   [:div
     (for [p ctrl.pages]
       [:a {:href p.url} p.title])
     [:button {:onclick ctrl.rotate} "Rotate links"]]

> Or use a language

You mean use clojure(script) , don't be shy ...

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.

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.

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.

It really depends on what you're used to.

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.

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.

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.

Indeed there is: http://facebook.github.io/react/blog/2015/09/02/new-react-de...

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

The rudimentary formatting keeps away the high-noise/low-signal folks who need shiny bells and whistles with their tech discussions.

It might seem trivial but there are a lot of people who don't like HTML templates where HTML tags don't look like HTML tags. That's why nearly all templating languages represent HTML tags as themselves if they have a choice. People won't use something like Mithril which might as well be Lisp.

I'm quite able to adjust, personally, and I've often represented HTML tags using method calls in a tasteful API, but I get complaints about why I'm not using a template language.

XML becoming first class citizens of code is huge. The tooling has already evolved for Javascript - Babel compiles it and JetBrains has excellent IDE support.

If you haven't written significant front-end code using JSX and React yet, give it a try. I make a case for JSX here: http://www.jasimabasheer.com/posts/evolution-of-view-templat.... There are also a few Medium posts with perspectives on JSX: https://medium.com/search?q=jsx.

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.

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.

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 2 : https://github.com/borisyankov/DefinitelyTyped/issues/2150 3 : https://github.com/borisyankov/DefinitelyTyped/issues/4513

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

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

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.

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.

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.

It's a matter of preference. I'd rather shoot myself than write HTML as JS objects like that. I've written countless lines of HTML in my life and don't see any reason to start thinking or writing HTML in the form of JS.

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.

> which has the most expressive type system.

Elm?

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

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

ES6 doesn't have static typing, so...

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.

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.

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

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

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).

Reply on news.ycombinator.com