suggestion: major version switchover for jsx cli to always assume .jsx, with .js needing -x

[Pomax]

Since JSX code is now advocated as needing a .jsx extension, it would make sense to do a major version release that breaks backward compat by switching to "always assume code is in .jsx, unless otherwise specified using the -x flag".

The major semver bump would ensure existing projects are not affected by that realignment with current advocacy and practice.

[zpao]

I think at this point we're not likely to do this. The current plan is to sunset react-tools and make jstransform the standalone way to transform your code (or babel or whatever tool you want that supports JSX). See facebookarchive/jstransform#81

Given that jstransform does more than the JSX transform, it doesn't really make sense to default to .jsx files there.

FWIW, we've never really advocated using .jsx files. We use .js and most (all?) of our open source projects follow this convention. What people are actually doing… that's may not match. But I think as transpiling JS becomes more and more common-place, it makes sense to just use .js.

[Pomax]

For JSX source code, calling the files **.js doesn't make a lot of sense. Once transpiled to JavaScript, storing the result in files ending in .js certainly makes sense, but saving JSX with a .js extension makes about as much sense as saving Coffeescript or Java source code as ".js" because it *can transpile to JavaScript, rather than actually being JavaScript.

But that's neither here nor there - if jsx, the cli utility, is getting sunsetted, then this issue can be closed as soon to be irrelevant =)

[sebmarkbage]

Basically we think of these as potential or experimental extensions to JavaScript, not a new language. FlowType is another one. Each experimental syntax extension doesn't need a whole new language to support it. You could argue that it should be annotated as an extension but it doesn't make sense that I combine a long list of file extensions for every new experimental version of the language.

.jsx.flow.es6.es7experimental.sweetjs.js

They're all designed to coexist as extensions to the existing language in a compatible way. In fact they might maybe one day be part of what we call JavaScript. In fact E4X once was. This is what differentiates it from Java or CoffeeScript. None of these features are a new language (unlike TypeScript which is a subset+superset of JavaScript and really a new language).

[Pomax]

Annotation would indeed be quite silly, but at this point it seems weird to not acknowledge that JSX is, in fact, a new language. It's mostly JavaScript, but then Processing is "mostly Java", too. The important part is that it has things that JS can't (ever) do, and no spec published or even in draft even intends to add the XML syntax for rich object notation. So making sure people understand that a file is not going to be runnable in a JS engine without a conversion step, by seeing the extension indicate its content type, seems pretty much common sense =)

[sebmarkbage]

making sure people understand that a file is not going to be runnable in a JS engine without a conversion step

The same argument currently applies to many ES6 features. Early adopter code might not even work in future engines. Flow types is another example of a syntax extension that doesn't have an active proposal but is in talks to be potentially standardized in some form. JSX is not actively pursued right now but I can definitely see some form JSX being standardized in the future since it solves a real use case that template literals doesn't. Perhaps not in its current form, but in some form. Also, E4X code used the .js extension for years.

More over, JS is becoming a source and target language where they're not necessarily the same. The future of JS is that it is always expected that a majority of code will in the future be compiled/transpiled before executed in the engine. It is a moving target.

[Pomax]

yeah but ES6 is very much in draft. There is, to my knowledge, not even a pre-draft working group for the subspec that JSX relies on in additional to base JS. If there is, though, let me know where because I'd love to read about that and possibly contribute!

[xml]

This simply raises the very valid point that files containing ES6, which aren't valid javascript runtime files on many platforms unless they're first transpiled, should possibly be named .es6, rather than .js. (That, however, is a debatable point, because some platforms can and will run ES6 syntax without needing transpilation, and more will do so in-future. But unless you're actually using those files in runtime, people should consider naming them for what they are: ES6 source files, not runtime Javascript.)

What's not debatable at all is that a file containing JSX will not work as intended until it's first transformed/transpiled: it's not fit-for-purpose if you interpret it as standard JS, under any spec, in any runtime. It might Lint, but it does not become a usable React component and perform as intended until you convert it. At no point in the future will that situation change.

Don't let the complexities of ES6/7 transpilation distract from that reality. JSX cannot be run until transpiled, and will not ever run until transpiled, and deserves some kind of clear and unmistakeable convention indicating such. While there are options available other than the file-extension (an interpreter flag like "use strict";, in or out of comments, might be another approach), it's illogical and unhelpful to pretend that JSX == JS, and to force tooling (and engineers) to make inferences about something that need not be the least bit ambiguous. We very much need some convention to make this distinction explicit, and I'd love to see this community make a recommendation on that.

[ehartford]

jsx isn't valid JavaScript, so it should not have a .js extension.

[oiwn]

Indeed, i have different setups and modes in emacs for JavaScript and reactJSX.

[gaearon]

This simply raises the very valid point that files containing ES6, which aren't valid javascript runtime files on many platforms unless they're first transpiled, should possibly be named .es6, rather than .js. (That, however, is a debatable point, because some platforms can and will run ES6 syntax without needing transpilation, and more will do so in-future. But unless you're actually using those files in runtime, people should consider naming them for what they are: ES6 source files, not runtime Javascript.)

But ES6 is JavaScript. It’s literally the current version of JavaScript. By this logic, you should rename the ES5 source files to .es5. 😉 Whether browsers support it or not has no bearing on whether the file is written in JavaScript or not.

jsx isn't valid JavaScript, so it should not have a .js extension.
Indeed, i have different setups and modes in emacs for JavaScript and reactJSX.

Then use .jsx extension. It is up to you. React has no opinion on it. Opinions on this will differ so there is no need to bump this thread with arguments 😄 . Use what you like.

[chicoxyzzy]

It’s literally the current version of JavaScript.

In fact current version is 7th edition / ES2016 =)

[maratbn]

Dear Facebook JSX Developers,

What goes into ECMAScript is decided by a consensus process inside Ecma International, and you guys are not part of that discussion regarding inclusion of the JSX syntax. You're partially acting like a parallel standards body, with your own definition of what ECMAScript either is or should or might kinda be (see next paragraph). If everybody starts doing that then we will have 100+ different "JavaScripts", each one incompatible with the other. That's just not cool.

And in your own self-contradiction, according to the current Facebook JSX specification website, archived at https://web.archive.org/web/20160914010022/https://facebook.github.io/jsx/ , JSX "[is] NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript."

If it is not intended to be used in exactly the same way, then it should not have the same file extension.

[maratbn]

Basically we think of these as potential or experimental extensions to JavaScript, not a new language. FlowType is another one. Each experimental syntax extension doesn't need a whole new language to support it. You could argue that it should be annotated as an extension but it doesn't make sense that I combine a long list of file extensions for every new experimental version of the language.

.jsx.flow.es6.es7experimental.sweetjs.js

They're all designed to coexist as extensions to the existing language in a compatible way. In fact they might maybe one day be part of what we call JavaScript. In fact E4X once was. This is what differentiates it from Java or CoffeeScript. None of these features are a new language (unlike TypeScript which is a subset+superset of JavaScript and really a new language).

That's like C++ developers saying that C++ is just an extension of C, and therefore it's OK for C++ files to have a .C extension.

[sebmarkbage]

@maratbn I am on the TC39 committee and Facebook is an associate member of Ecma International, involved with the ECMAScript process.

The process involves a multi-stage process which starts out with lots of exploration in user space by various contributors and by champions that aim to propose a concrete proposals. As you can see with ECMAScript 2015 this can take many years and needs a lot of evidence of the worth of inclusion and early experiments.

JSX may very well be adopted as a standard just like E4X was at one point. It is not clear in what form though. Would it be semanticless syntax? If it had defined runtime semantics, what would those be? That's a field that is still evolving. Another plausible route would be to include a macro system into the language. It is still unclear what features that would require.

We're not at a stage where we're ready for a formal proposal yet, but that's not to say we'll never be.

Similarly, Flow and TypeScript types are not ready to become a formal proposal yet, but they're evolving within the same space.

The .js extension has long been overloaded with various extensions, early proposals implemented in Babel, Flow types etc. There's also the whole thing about Node.js potentially requiring the .mjs file extension because ECMAScript itself has multiple ambiguous parsing interpretations of the same file.

[maratbn]

@sebmarkbage

JSX may very well be adopted as a standard just like E4X was at one point.
...
We're not at a stage where we're ready for a formal proposal yet, but that's not to say we'll never be.

If / when it DOES get adopted, then by all means, it will rightfully deserve the .js extension, just not at the present time.

The TypeScript people are also on Ecma International committees, but up to now they're happy using a separate extension.

[Pomax]

Given that this issue was resolved to a close in April of 2015, let's not keep beating a dead horse and instead focus our efforts on making cool stuff on the web with React, JSX, and ES6+ instead =).

React is agnostic about the extension, and there has been plenty of tooling available since I filed this issue to make the extension choice purely an aesthetics issue these days: use .js if you like
because babel", or use .jsx if you feel that'll help your team "because it's not JS". And if it's something anyone still feel strongly enough about to want to debate its place in JS as a spec, there are more appropriate places to discuss what is and isn't JavaScript (As a repo for React, not JavaScript, this is not the place for that discussion).

[maratbn]

@Pomax

Given that this issue was resolved to a close in April of 2015, let's not keep beating a dead horse and instead focus our efforts on making cool stuff on the web with React, JSX, and ES6+ instead =).
...
As a repo for React, not JavaScript, this is not the place for that discussion

There are a number of newer discussions / pull requests / bug reports related to this issue referencing the arguments made here, and using those to base supporting arguments, so this issue is not a "dead horse".

Since React and javaScript are closely related, this is an appropriate place for the discussion conducted above, as long as it stays on the topic of the React-JavaScript relationship, and does not stray into pure JavaScript topics completely unrelated to React.

The purpose of a public forum is to facilitate an open sharing of opinions and analysis, which is exactly what's happening here.

[Pomax]

Closed issues are not the right place for discussions. If you want to use this thread as reference: great, but don't keep adding comments to it. This issue has been resolved, so if you have thoughts based on the other, still open issues you refer to, that's where you comments should be directed.

[maratbn]

@Pomax

Closed issues are not the right place for discussions...

Open public forums are not the right place for closed discussions.

[gaearon]

You may keep discussing it if you'd like for sure. This discussion will not affect anything because React has not been including or maintaining "jsx" compiler for a while now. This compiler's behavior is what this issue was about.

If you'd like to change some behavior in Babel (which we recommend instead), you can file an issue with it. Realistically discussion here will not change anything because the whole issue is not actionable for the React team.

Cheers!

[maratbn]

@gaearon
OK Dan, good insight.