Performance test of HTML CSS vs. HTML Inline vs. Stylish Elephants

[dmy]

I would be interested to see your benchmark with elm-css. I expect its performance degradation to be similar to Stylish Elephants.

There were some interesting points in this discussion about elm inline css performance:
https://discourse.elm-lang.org/t/how-to-do-css-in-elm/

and unfortunately, lazy does not solve everything (and performance varies greatly between different browsers).

From my experience with my real-world app, if you have a page with tenths of “highly styled” elements (for example a list item flexbox container with a few flexbox children, each having margin/padding/font/color/flex set), it will matter in practice if you want a smooth experience with scrolling/hovering/menus. My strategy for now is to use Css.Foreign styles or SCSS for all elements that are rendered a lot (list items, icons, very common custom css styles batches) and use standard Html.Styled elements for everything that is rendered once.

However I believe strongly that the elm-css roadmap will improve the performance a lot and allow me to remove those work-arounds:

@rtfeldman

There are three major performance optimizations I want to do for elm-css :

1. Move the compatibility checks to a phantom type , so they no longer have runtime overhead.
2. Hash things more efficiently . Plenty of room for improvement there.
3. Use insertRule . This is on Evan’s radar, and he’s talked through some API ideas with me. style-elements would benefit from insertRule too.

In the vein of Make it Work, Make it Right, Make it Fast , the current elm-css API has gotten positive responses on its working and working right, so it makes sense to start shifting focus to performance!

Once point 3. has been reached (insertRule), I expect indeed those issues to become “it does not matter in practice” for almost everyone, whereas today, dense styled pages (like gmail for example) are likely to have issues.