search

facebook / jsx

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

Please consider users' proposals/ideas or move the JSX spec to an independent organization #119

Open jhpratt opened 5 years ago

jhpratt commented 5 years ago

There are a number of proposals that have been open for years. After quickly going through the list of open issues, here's a few that don't seem too controversial that have been open for multiple years.

A number of these proposals were put forth together in October 2016 in JSX 2.0 (203 👍, 3 👎). It was locked in December 2016 after minimal input/feedback from maintainers.

What I am asking is simple: consider these suggestions and proposals. All of the issues I've linked have widespread support and would allow the use of JSX by wider audiences.

The lack of responsiveness, even after pinging users who are otherwise active on GitHub, is unacceptable. If there is a lack of activity on these or other issues in the coming days and weeks, I intend to create a competing specification in the newly created @jsx-spec organization. I expect the JavaScript community to understand that specifications need updating, and the failure to do so under Facebook's control is holding a number of projects back.

sebmarkbage commented 5 years ago

JSX's success as a non-standard syntax extension has been largely due to its stability which has let a wide variety of tooling develop in compatible way. Often with even better cross-compatibility that standard language features.

Particularly parsing is something that is difficult to fork which is why syntax stability is particularly important. Where as transforms can be pluggable syntax can't as easily be pluggable.

Syntax also conflicts with extensions that TC39, Flow and TypeScript wants to do. So it's important to the whole ecosystem that not too many permutations become popular.

JSX 2.0 was an attempt to unify a lot of different changes into one cohesive one so there would at least only be two versions to support instead of many. Unfortunately, while it had a lot of upvotes here, it also had a lot of concerns elsewhere and didn't provide enough value. There were also other ideas popping up that wouldn't necessarily neatly fit into this. So to avoid having to also do a JSX 3.0, it kind of fizzled out.

So the lack of activity here is very intentional.

In terms of stewarding going forward. I believe that the next step for JSX is to make it into a TC39 proposal where it can reach further stability. That's the natural ownership org for this extension to the language since it's highly integrated with other possible language features and risks conflicting with other syntax.

Perhaps not in its current form though. Perhaps even as a macro.

jhpratt commented 5 years ago

JSX's success as a non-standard syntax extension has been largely due to its stability which has let a wide variety of tooling develop in compatible way. Often with even better cross-compatibility that standard language features.

I'm not disputing this at all, it's quite true. However, updating JSX's syntax to implement some new features from ES6+ should (IMO) absolutely be performed. I'd absolutely like to preserve backwards-compatibility as much as feasible in order to avoid breaking existing plugins.

Particularly parsing is something that is difficult to fork which is why syntax stability is particularly important. Where as transforms can be pluggable syntax can't as easily be pluggable.

Agreed. At least with Babel, some of the issues mentioned in the original comment should be relatively simple to implement. do expressions are already parsable (albeit explicit, not implicit), custom namespaces would likely just need an expansion of the allowable tokens to begin a namespace.

Syntax also conflicts with extensions that TC39, Flow and TypeScript wants to do. So it's important to the whole ecosystem that not too many permutations become popular.

See below for a possible solution.

JSX 2.0 was an attempt to unify a lot of different changes into one cohesive one so there would at least only be two versions to support instead of many. Unfortunately, while it had a lot of upvotes here, it also had a lot of concerns elsewhere and didn't provide enough value. There were also other ideas popping up that wouldn't necessarily neatly fit into this. So to avoid having to also do a JSX 3.0, it kind of fizzled out.

This pretty much sums up why I listed the "uncontroversial" proposals, based on things that had a significant number of upvotes and minimal downvotes.

In terms of stewarding going forward. I believe that the next step for JSX is to make it into a TC39 proposal where it can reach further stability. That's the natural ownership org for this extension to the language since it's highly integrated with other possible language features and risks conflicting with other syntax.

I agree this would be the best way forward, but I follow TC39 proposals quite closely, and personally don't think this would be feasible. Do you think TC39 would consider a JSX-style syntax? We're both well aware of the fact that JSX by itself doesn't actually do anything, it necessitates a transform to do anything useful. Given the wide variety of things JSX can transform into, what would this even do? DOM is not ECMAScript, so TC39 wouldn't spec that, and WHATWG certainly wouldn't expand syntax singlehandedly. Perhaps TC39 could create reserved syntax, in the same way it was reserved the type annotation syntax TypeScript uses.

Perhaps not in its current form though. Perhaps even as a macro.

Not entirely sure what you mean by this.

If TC39 could get onboard with an expansion of reserved syntax to include JSX, that would obviously be ideal. Then all future changes could be done annually as with other syntax changes. In the meantime, I personally believe some updating should take place independently.

sebmarkbage commented 5 years ago

I went through the list of issues that you posted and all of them have a number of outstanding unanswered questions in them.

jhpratt commented 5 years ago

Extend JSXText with comments: This will be a very large burden on syntax highlighters and parsers since it needs to define how valid JS code inside the comment is either ignored or parsed and how comments can possibly interleave. We need buy-in from a wide variety of implementors that they're willing to do this at that it's worth it. We also need a spec. There's also the outstanding controversy whether this should be treated as semantics, i.e. they generator comment nodes, or if these are truly comments. Does this influence?

I can't speak as to the difficulty of syntax highlighters, as I've never created one. Parsers should be able to handle it if comments are sufficiently restricted (such as within another JSX node).

As to semantics, that's not a JSX problem, it's React's (for you, at least). At last with how Babel works, the parser would create a comment node in the AST, and it would be up to the transformer to determine what happens.

Support object literal property value shorthand: I followed up in #118. I'm not convinced this is actually a good idea but the least controversial one probably.

I don't necessarily agree with this one either, but it does have 100 upvotes.

Allow template strings in JSXAttributeValue: This hasn't settled what encoding should be allowed in template literals and if syntax highlighters can deal with that. React JSX uses HTML encoding in strings. Someone has to write a spec for how the more complex template literals syntax plays together with HTML encoding.

As with above, this would be up to the transformers, no? In Babel, a quick test shows that HTML entities are decoded, but there's still node.extra.raw that allows you to get the string with the encoded entities.

Implicitly use do-expression for any JSX expr container: This shouldn't be done until the upstream do-expression is further along. There are some problems with it and it might not make it upstream. We also noticed that this likely isn't that useful for a lot of cases, at least in React. We dropped our original proposal and favored something like do-generators.

Waiting for further development with do expressions seems reasonable. It is only stage 1, after all.

Remove JSXElement from JSXAttributeValue production: This is about removing a feature. I guess we could remove it but then we'd just open another issue to read it.

For this, at least, it seems like it should be removed if for no other reason than nothing supports it.

Support numeric attribute values: This one is tied to the other forms we might want to allow here. There needs to be a story about how all these values tie together, not just added one-by-one. One possible solution is to allow a limited set of all expressions. If we can't do all expressions, what's the rule for what is included and what isn't? That's discussed in other issues.

Not sure where exactly was discussed, but if there's other things that can it can be expanded to, even better. Numeric literals are just an obvious starting point.

Custom attribute namespace: Adding all possible syntax options here would severely limit how we can utilize that syntax in the future. E.g. for immutability, decorators, private fields. So care needs to be taken which one is allowed so we don't shoot ourselves in the foot. Feel free to make a specific proposal. The obvious and least controversial one is the XML-namespace style and that's already allowed by the spec.

Of course it's best to avoid future syntax conflicts, but given that JSX controls its own portion, it could disallow decorators, private fields, etc. inside the opening element declaration (some options wouldn't make much sense, anyways). Lit HTML currently uses a prefixed ? to indicate a boolean attribute, . for bound properties, and @ for event listeners. Though Lit HTML uses template literals, the ability to use other namespaces (notably symbols) would be useful if we wanted to write JSX to transpile. Of course, other transformers may want to use other symbols, but it's certainly somewhere to start. ? and . certainly won't have syntax conflicts in the future due to ternaries and property accesses respectively.

RyanCavanaugh commented 5 years ago

So the lack of activity here is very intentional.

@sebmarkbage Which interpretation do you mean here?

  1. We intentionally don't interact with developers on the issue tracker
  2. We intentionally choose not to add new things to the spec

If it's the first, just turn off the Issues tab in this repo, or add a template indicating that users should expect to be largely ignored. If it's the second, be proactive and tell people that the spec is closed, and close issues proposing to add new features.

sebmarkbage commented 5 years ago

Lack of activity, meaning that we don’t just add something because it seems like a good idea at the time. It needs to be well motivated and needed.

We tend to answer and follow up on issues when there are new points or someone actively driving a proposal.

My frustration has been that there are a lot of drive-by comments on these issues that just ignore the unanswered questions above and rehash previous points. It gets tiring. I admit I’ve been bad at answering those threads. Especially since it’s usually new people you have to rehash it with every time. Feels a bit like es-discuss.

It might be helpful to have a small working group for that purpose.

sebmarkbage commented 5 years ago

@jhpratt Do you mind if we follow up on each one at their specific issue so we can keep the thread going there?

jhpratt commented 5 years ago

I'd very much like a working group; it certainly doesn't need to be anything like TC39, but an independent group that's able to determine if something is worthwhile would be great.

Feel free to follow up in individual issues if you'd prefer.

nojvek commented 4 years ago

@sebmarkbage have you given much thought about a jsx working group? A couple of community folks, some from react, some from babel, some from typescript. The lack of progress in the spec is very disheartening.