search

facebook / jsx

The JSX specification is a XML-like syntax extension to ECMAScript.
http://facebook.github.io/jsx/
1.96k stars 133 forks source link

Explain why to use JSX over ES6 template literals #1

Closed sophiebits closed 10 years ago

sophiebits commented 10 years ago

Adapted from https://twitter.com/sebmarkbage/status/475827159571787776.

sebmarkbage commented 10 years ago

I'm going to drop the performance paragraph. The output of a template literal can be inlined by a compiler. All you need to do is assume that the module or identifier you're using is statically known (just like require expressions).

sophiebits commented 10 years ago

My point was that you need a smart compiler anyway so you may as well use the custom syntax as well.

sebmarkbage commented 10 years ago

Hm. Interesting point. You don't need it during development though so it's not quite true that you always need a compiler. However, compiler vs. no-compiler is not the main argument that I'm trying address.

I think there are two arguments against JSX:

1) Practical constraints. I.e. using a compiler is hard. 2) Don't extend syntax because it'll conflict and cause compatibility problems.

For example, you have ambiguity with other language extensions, we claim real estate that others can't use. Not all tooling works. E.g. type inference and minifier tools can't work on JSX without additional knowledge about the semantics.

I'm not sure we need to address the practicality concerns in this spec (1). This isn't really a tutorial for why you should use JSX in your projects. Besides, a sufficiently optimized VM wouldn't suffer from the string manipulation slow-down anyway. That's usually not a good reason for introducing new syntax.

I think we just need to address the legitimacy of the syntax itself. I'm writing up some details about what I mean.

The key to my argument is that templates include semantic meaning. Meaning that generic tools will make assumptions about those semantics. That means that you only have two options. 1) Comply with the semantics and get really messy syntax. 2) Break the semantics of the syntax and just use it as a syntactic placeholder. But then you don't get the benefit of the tooling support/compliance anyway.