Comment by c-smile

16 days ago

What if:

1. JS supports JSX literals so

   let elDef = <div id="some">Text</div>;

will be compiled into

   let elDef = ["div", {id:"some"}, ["Text"]];

2. We extend DOM API to accept such constructs:

   element.append(elDef);  // same thing as element.append("<div id=some>Text</div>");
   element.prepend(elDef); // ditto
   element.patch(elDef);   // patch element's DOM by elDef

3. Add appropriate events: componentDidMount, componentWillUnmount, etc. for cases when tag in JSX (uppercased) resolves to a class or function.

4. Add render() support. A method that generates tree of elDef's. It gets called by append(),prepend() and patch().

And we will get native React implementation. This will be quite useful and allowed to marry React alike approach with WebComponents into single mechanism.

1...4 is how it is implemented in my Sciter as the Reactor thing, see: https://docs.sciter.com/docs/Reactor/

1 comment

c-smile

WorldMaker 15 days ago

If you are making it native to the browser, why have a "virtual DOM" "definition language" middleman and not just jump straight to real DOM, the browser's existing bread and butter?

  let ele = <div id="some">Text</div> // ele is now HTMLDivElement

Doing that `element.append(ele)` just works with existing DOM APIs.

Instead of supporting classes and functions in browser-supported JSX with their own life cycle model, you can just require registered Web Components and reuse existing Web Component life cycles.

I think if Browser-native JSX support were to happen it should probably either be real DOM or remain a function tree so that at least some tree operations can be amortized by the function compiler.

Which is that most JSX is actually compiled to nested calls like:

    let elDef = jsx("div", {id:"some"}, "Text", jsx("div", {id: "inner"}, "Text2"), ...otherChildren)

The `jsx` function can potentially avoid some future tree walks/recursion by the nature of being unrolled by the compiler into nested calls instead. That's a useful property lost in trying to agree on a single virtual tree definition. It's also one maybe unnecessary if just relying on real DOM trees, because browsers have their own optimizations for DOM tree walking.