I’m concerned that you’re falling into the same trap here with integrating your own variant of JSX, and mulling over adding more things like hyphens in unquoted object literal keys.

JSX is popular enough that it’s safe, ECMAScript isn’t going to break it, but your alterations to JSX are already significantly incompatible: you have <input.search /> being equivalent to JSX("input", {"class": "search"}, null), but the JSX everyone else is using has that equivalent to JSX(input.search, {}, null). I’m not certain if your JSX syntax is supposed to be able to be used with React code or anything else that uses JSX syntax, but if yes then it’ll be broken in a significant number of cases so that it’s worse than useless, and if no, well, it’s going to be misleading, and what if JSX did get merged into ECMAScript in some form? Then you’d be incompatible with ECMAScript again.

Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now, but just because it’d be a syntax error now doesn’t mean it always will be. Decorators in TypeScript are a good example of things going badly wrong even when an extremely popular project is involved.

I say: if you want to go JavaScript, go JavaScript, maaaaaybe plus standard JSX conforming with <https://facebook.github.io/jsx/>, and no further. Even if what you do is obviously superior, &c. &c. I’d apply the same reasoning on your fork of CSS: you introduced it for a good reason back then, but now it’s just friction, even if it’s a little better in a vacuum (and maybe it is in parts, maybe it isn’t in other parts).

This <input.search /> is a short form of <input class="search" />. You can use either one of those. And `JSX(input.search, {}, null)` does not make sense. But `JSX(Input.search, {}, null)` does make sense, yes. In Sciter that will be `JSX(Input-Search, {}, null)` to use Search component from Input module.

You are not obligated to use built-in JSX. TS compiler includes its own version of JSX compiler and so it will not hit built-in implementation.

"Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now"

This was used in TIScript but not in JS, unfortunately.

"standard JSX"

No such thing. Check forst paragraph of https://www.typescriptlang.org/docs/handbook/jsx.html

The semantics of the JSX transformation certainly do vary, though there’s a fairly consistent baseline which you’ve broadly matched; yet for all the variations in semantics, the JSX syntax itself is well-defined, and that’s what you’re flouting. In fact, since we’re talking of semantics, one of the ways in which the runtime (post-transformation) semantics vary is a good indication of the problem of special-casing your own syntax: your class syntax transforms into a property named class, but React uses className for the equivalent concept.

JSX(input.search, {}, null) makes perfect sense as code and as a concept, though that particular combination of names would be surprising. But suppose it’s something like props.tagName, or library.SomeComponent. As for your JSX(Input-Search, {}, null) being module lookup… I hope that wouldn’t be valid code, and that <Input-Search/> transforms into something other than that, or you’ve got grave problems. But again, this is a point where you’ve deviated from standard JSX syntax in a way that’s far too likely to cause trouble down the road. Why not rather use Module:Component or module.Component, both of which are syntactically valid JSX? (I dunno if these modules are global or have to be imported or whatever, so I don’t know what’s most appropriate.)

Concerning hyphens in keys: I’m referring to what you’re suggesting as a possible addition to your brand of JavaScript. I’m suggesting that it would be better if you resisted the temptation to alter JavaScript at all, beyond possibly standard JSX syntax.

For what it’s worth, JSX is exactly designed for this kind of usage. It’s just a syntax extension, and it only specifies the way syntax can be used in an expression position. It explicitly allows dot access (but doesn’t specify its behavior).

While it’s common to treat JSX as syntax sugar for hyperscript, even that isn’t specified. JSX is a compiler hint with expression semantics, that’s all. You can see how dramatically different it can be in plain JS by looking at compiled output from dom-expressions (most commonly used in SolidJS).