Closed syranide closed 10 years ago
With this release, we've gone the opposite direction. We say that the use cases are so varied that every project likely needs it's own transform. E.g. key
and ref
for example are special cased. They should probably use it's own namespace. The syntax is general but the semantics isn't.
I don't think we're ready to generalize this. Trying to make this generalized just limits us. In reality there are 6 or so larger projects that uses the JSX syntax (including internal FB projects) and they all use different transforms right now.
TBH, ultimately I hope that the XML-like syntax is just an intermediate step to find a better and more generalized object literal with balanced tags. Like a more readable JSON.
Makes sense :+1: Lets not clutter issue log indefinitely, closing.
Given recent developments it seems natural to try to separate the JSX transform from React, i.e. to rid ourselves of "React-JSX". The JSX transform could then be adopted independently for use by other frameworks as well, derivative JSX transforms for other JS-based languages could then benefit the JS ecosystem as a whole. Community exploration of alternatives to JSX could become more realistic long-term.
What would it look like? No idea...
Or perhaps it should just transform into plain objects (owner is a problem)? I have no idea, but unless there are severe practical issues then it seems to me that this is the natural next evolution for JSX (transform).
The only thing that instinctively raises red flags for me is that exploring various optimization strategies might become impossible as that would largely require mutual agreement between the transform and framework I would think. It would probably have to eventually become part of the standard (it could potentially be for the better, but much more friction).
cc @sebmarkbage