Closed mcjazzyfunky closed 6 years ago
Oh and BTW: I've read issue #7 which has some discussion about the children syntax ... but my syntax question above does not really find an answer there.
1) If you're worried about performance, I would suggest something like https://github.com/roman01la/babel-plugin-react-hyperscript with a pre-compilation step if you want a different api from jsx but no de-ops.
2) I have not encountered issues, but ymmv; again, a babel plugin would be what you're after in that scenario.
3) As mentioned in #7, was primarily for consistency in api but I never had a strong opinion :)
@mlmorg Thank you very much for the information - that helps a lot.
No bug, no feature request - just some questions :-)
First, thanks a lot to the whole "react-hyperscript" team for providing such a nice alternative to JSX.
Please allow me to ask some "why-questions" about "react-hyperscript" (people sometime consider "why-questions" as a bit unfriendly - hope you do not mind my curiosity and my frank questions):
1.) Regex parsing is costly. JSX does not have to do any Regex parsing. "react-hyperscript" uses regexs, but does not do any caching of the regex parsing results, which would speed up everything tremendously. Is there a special reason why "react-hyperscript" is going without caching?
2.) Any hyperscript solution (even if aggressively optimized) will by nature always be slower than using JSX/createElement directly. As "react-hyperscript" goes without aggressive optimizations it's normally several times slower than JSX (in one stupid simple test of mine on Firefox it was even more than 10 times slower - but be aware that even "createElement" itself is fast with e.g. Chorme and slow with any Microsoft browser). Do you have any experiences whether that performance loss could cause some problems in special scenarios (for example on highly frequented SSR view servers or on very slow smartphone etc.) or is that no issue at all in your opinion?
3.) About the syntax: "react-hyperscript" forces children to be passed as array and not as varargs. This means a litte bit of additional syntactical noise: "[" and "]" plus some white-space/line-feeds. Is it for a matter of taste that you prefer the following syntax a) to b) or are there also some other reasons besides taste?
a)
b)
Thank you very much in advance for your answers.