RFC: Remove Build Time Transforms

It is currently possible to transform icons at build time from components into plain HTML using the option enableExperimentalBuildTimeTransform. This option was taken from the community addon and intended to accomplish two goals:

1. Reduce file size of the application
2. Remove unused icons from the build

Reduce application filesize In order to support dynamic options <FaIcon @icon="pencil" spin={{isSpinning}} /> we were never able to ship plain strings which the template compiler could de-duplicate. In FontAwesome v5 with it’s use of inline SVGs these transformed nodes are actually very large so application file size could be larger when build time transforms were enabled.

Remove unused icons It is not possible in the current ember build system to detect what icons are used in templates and include only those icons in the build. While the build time transform does allow some icons to be detected it still requires developers to include dynamic icons into the environment.js file and was never reliable across addon boundaries.

Conclusion As the enableExperimentalBuildTimeTransform adds significant complexity to this addon and may be impossible to port to the new ember embroiderer addon build and as the main goals of this option were never accomplished I propose removing it entirely before a v1.0.0 is released.

[arthur5005]

@jrjohnson we couldn’t find any proper tools, so we decided to come up with a setup that illustrates the basic overhead of initial renders using the 3 types of components in Ember: Classic Ember, Glimmer Components and Template Only Glimmer Components.

Did some benchmarking by rendering 10,000 components; all we were looking for was the component rendering overhead.

We fed a uniq value to each component to render (1-10,000) to make sure we weren’t triggering some optimization.

On Ember 3.14 we compared:

• Rendering 10,000 Ember Components
• Rendering 10,000 Glimmer Components
• Rendering 10,000 Template Only Glimmer Components
• Rendering 10,000 <div>s with the value, instead of calling a component.

We had a button to render each set, then a reset button to measure teardown of the components, the following flame chart from the browser shows the results:

[jrjohnson]

Nice @elgordino, one option I’ve been thinking about is only transforming completely static icons and an explicit component to signal that would possibly work very well.

This would combine very well with transforming <FaStaticIcon> into using a sprite instead of the fairly lengthy SVG string. This should speed up rendering significantly in places where many of the same icon are being used without blowing up the template size at the same time.