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.