points
10 months ago
| 1 comment
| HN
A problem with going straight to objects is you potentially create a lot of GC churn if the `interpretJsx()` converts it to a different data structure. Also because it is a tree structure, you are probably talking a recursive depth-first-search or other tree-walker algorithm that can easily blow up the stack while it works. If you are doing something Virtual DOM-like and evaluating lots of trees, that memory/GC and CPU churn compound quickly.

This is part of why JSX has always been function calls rather than a data structure to interpret: the recursion to walk the tree is flattened at "compile time".

I don't see why it is a problem you'd need to import your `jsx` function in every file that uses JSX syntax, but perhaps because that's how I've always preferred to use JSX, even with React. Explicit imports are better than implicit ones. If you use lit-html you have to import its `html` function everywhere to get html`` template literals to work. It's not a lot of overhead and it works well. You can add the auto-import smarts to your editor, to your snippet files and template files. Typescript already has a ton of auto-import suggestions as you write a file.

90s_dev
10 months ago
[-]
Yeah I guess you're right. This proposal has serious performance issues.

Still, I don't like the React-classic style, the React-autoimport style, or the hybrid that you're advocating for. None work be very ergonomic and require tooling to at least give you errors that you forgot an import, which defeats the purpose of standardizing it at that point.

reply