Sultan

@Olivia-SY129 can you add a test case, i'm assuming we can replace `replaceAll` with just `replace` safe assumption?

Naming suggestion: `@@style` in a similar vein to `@@iterator` instead of `css` so `{'@@style': string}` or `{'@@style': function}`

@kof If it should be unique i think it should only be "pseudo" unique and not "react" unique i.e `Symbol.for('@@style')`, so other react-like libraries can support it. the underlining abstractuib...

Thanks.

>Change JSX transpilers to use a new element creation method. Always pass children as props. This will probably break other libraries that use JSX(unless it's configurable) and would still require...

>I don't see how this proposal would affect other libraries - unless they use `babel-plugin-react` @trueadm They do use the pragma option provided: https://babeljs.io/docs/en/babel-plugin-transform-react-jsx and this is not uncommon/taboo since...

>although it also sounds like you’ll be creating far more virtual objects than we do now? @trueadm The example doesn't create any more objects than what is currently done/what this...

@trueadm There are a few reasons. 1. Engines can better inline small single responsibility functions, they are effectively free except for the dynamic variant `jsx.from` which would need branching etc,...

@trueadm >Bit wise flags are extremely cheap to do and far more effective than object lookups. When i mentioned `jsx.node` or `jsx.text` this is more a readable presentation of for...

@trueadm Yes, the proposed monolith `jsx()` or granular `text/node/empty/children/from` could both serve as intermediate representations with a 2nd tier compiler that translates these further down the pipeline. I wonder if...