Wouldn't it be great for bundle sizes around the world to be reduced from 13 bytes per element where jsx transposes a 13 character function name down to a single byte function name called 'c' or 'e' (12 bytes per node rendered sounds like huge savings to me)
I am sure there are crazy people out there directly calling createElement, so keep the function name there and fix the jsx transpiler to use the one byte function name for all the normal people who never write a lick of createElement.
Can this be looked into or advise me on where I can hijack my jsx transpiler to do this globally. I want to see just how much savings I have on a 7 year old application with over 1400 components and probably at least 14mb of gzipped bundles chunked out.
Thanks for being awesome react maintainers!
Just close if you think this is a garbage idea. I'm just trying to save 12 bytes " n nodes in their entire application. Maybe it could save some apps 100kb unminified if they have a large enough dependency tree of JSX output.
Next my mission is to find a webpack plug in to rename react globally to an alias like R. so everytime webpack imports react I'll save 4 more bytes (that's not your problem) but if I got both the library and create Element down to two bytes from previously 18 bytes per create element call. That's what I am interested in seeing just how many create Elements are in my bundle and if it reduces it by 100kb or 30kb gzipped I think that's a win in my book.
I'm sure my calculations are not right on how many createElement calls there are in some of my apps, but very verbose html apps with huge imports of very Dom heavy jsx trees could probably benefit from a 2 byte package and function call.
There is a Babel plugin that makes sure it just ends up as
createElement instead of
React.createElement in the bundle at which point you can minify the code which will end up creating a function name with as few letters as possible. If you're using the automatic JSX runtime you already get a function call without property access i.e. minimal bytes.
But these optimizations are negligible compared to having 14mb of gzipped JS. The only thing you're making smaller is the uncompressed size since gzip will already compress often repeated strings better (e.g.
@eps1lon thanks for the info, I'll check out that babel plugin I've never found and fork and play with it. Yea our react app isn't public on internet so we have less latency for downloads and is lazy loaded in many areas. I still wanted to see how much can be decreased though because I know one bloated area of our app was a ton of forms and copy paste coding with lots of Dom and that became like 8mb compressed so that became it's own chunk at least out of our main pipeline.
Have a great weekend! What are you currently focusing on with the react repo personally?
|Issue Title||Created Date||Updated Date|