Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we move JSX to be an extension of ES Spec that evolves forward like EcmaScript + TC39 ? #123

Open
nojvek opened this issue Jun 18, 2020 · 3 comments
Labels

Comments

@nojvek
Copy link

nojvek commented Jun 18, 2020

This repository has a ton of issues and discussion, although effectively things are dead. There is no movement as of 2 years ago. That being said, I value the ability to keep things stable.

However what is the plan to actually evolve JSX ? There are a lot of good ideas that will be stuck in eternity unless folks who can do something about it, make things happen.

AFAIK There are two main transpilers for JSX, Typescript and Babel.

Should we get a team of folks from JSX / Facebook, Typescript, & Babel to get together like TC39 in a semi regular fashion and move things forward like TC39 process ?

Have there been thoughts on having JSX be an extension to EcmaScript and do the discussions as part of TC39 itself?

fyi @sebmarkbage / @RyanCavanaugh / @nicolo-ribaudo ^

@sebmarkbage
Copy link
Contributor

I'm all for JSX being an extension of ECMAScript like E4X was. Probably as a separate spec and technical group. Same as ECMA-402. It likely would be considered optional and not part of the browser. We would be supportive of anyone within TC39 to drive a concrete proposal for that. It might be somewhat controversial to lift it up even to that level because people like to pretend that it's fringe and hope that it will go away as E4X.

I think the main thing to keep in mind is that a lot of the proposals that are the most interesting ones are breaking changes. One decision that will have to be made is whether this new organization will allow for versioning breaking changes which ECMA-262 and ECMA-402 does not, and doesn't have a process for dealing with breaking changes.

I was originally hoping that we'd be able to make a bulk of breaking changes such as JSX 2.0 before standardizing so that the next one could be more stable after that. There wasn't a clear winning set of changes and enough want to warrant it.

We'd probably be against any standardization of runtime semantics since that is something that is very use case specific and has changed a number of times already. I think it would be difficult to get consensus on that but maybe there's some clever extension mechanism that could allow for some subset to be specified.

@nojvek
Copy link
Author

nojvek commented Jun 18, 2020

I was originally hoping that we'd be able to make a bulk of breaking changes such as JSX 2.0

Yeah the JSX 2.0 proposal is great.

The gist I see from a whole bunch of issues in this repo is most folks are asking for JSX to be closer to JS in semantics and have less overhead of extra {} characters. i.e more javascript expressions and less html quirks. Reasonml's jsx flavor that favors expression is a great inspiration https://reasonml.github.io/docs/en/jsx.

By just making the syntax more close to javascript, I think many long-standing problems would be more easily fixed:
#23 - support object literal property value shorthand
#25, #51, #64 - Drop the need for curlies around attribute values if they're a single literal, or parenthesis.
#35 - Drop implicit text content and curlies as children.
#7 - Extend JSXText with Comment?

I guess what I meant by having a process of moving forward is a way to adopt breaking changes too. As long as the tooling ecosystem i.e acorn, babel, typescript, eslint e.t.c is in agreement with the changes, we can add new things, deprecate old things and after many years remove them. Big breaking changes can be adopted via compiler/plugin flags. Jsx gets transpiled into js functions any way so browser vendors don't really need to be involved like ES does.

We'd probably be against any standardization of runtime semantics - That makes total sense.

I feel the core problem here is to get the list of core JSX people from different OS projects to get together and accept a proposal that we are in agreement with. Something that cleans up the rough edges of JSX and is future proof enough for the next 5-10 years.

In a way JSX has become the defacto templating language for javascript because of the great tooling around it. JSX is a thin transformation to hyperscript like calls and that's awesome, the rest is all javascript. I really do appreciate the mental simplicity of JSX.

Do you have any idea who we should reach out, to get something like this going ?

@QbDesu
Copy link

QbDesu commented Oct 16, 2021

I would be all for expanding on the jsx spec. We could reach out to facebook alternatively we could reach out to ecma and tc39 on whether this could be turned into a syntactic spec that is managed by them.
And if all else fails reach out to the major projects using this spec. Of the top of my head there is quite a few other than React itself. Like React Native, Preact, Next, and of course not forget about the projects that actually implement the transpilation like Typescript and Babel.
Hope there is still interest from a couple of people. Alternatively it could just be an Github organization created by a couple of people interested in it.

@Huxpro Huxpro added the Meta label Feb 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants