@albertdahlin, I think that 0.19 --optimize unboxing is likely to play a role explaining some runtime performance improvements.
On a side note, I have not taken the time to think about it deeply, but given the performance improvements done in elm-ui, I wonder if a low-level inline CSS “hashing/merging/node styling” library could be extracted from it so that elm-css and other (future) UI libraries could use it to benefit from a common efficient format/API?
This would lower the difficulty to make new UI libraries. Then all libraries using it could work in common to improve it even more. Future major improvements like the hypothetical use of insertRule could benefit immediately to all users of the library once it uses them.
At last this could also allow to include directly some elm-css styled nodes in an elm-ui interface without converting by using elm-css Html.Styled.toUnstyled then elm-ui Element.html (or maybe even just a typed style when a css hack is needed)?
@mdgriffith, @rtfeldman, what do you think? This is just a thought so I may have missed something obvious that makes it impossible (I don’t know elm-ui well yet).
Edit: @albertdahlin, sorry to widen the scope of your post, if the proposal is actually possible, let’s move the discussion to another post.
Sounds like a great idea. If I remember correctly, I think there was an issue with using the atomic CSS approach of elm-ui (one single line of CSS per style class and using that line as the class name so no need to do hashing) when used with media queries in elm-css, because order matters. I am trying to find the discussion thread on here from about 6 months ago…
@dmy, I have talked with Richard and Matt about having some sort of insertRule support. Some kind of CSS rule diffing. The plan we came up with was to let folks explore the core idea in libraries first. That would mean we could wait to do the work until they had shown that (1) it is a useful technique and (2) the CSS rules actually were a performance bottleneck in practice. The idea being that this would lead to an API that met their needs more directly, rather than guessing at it in advance.
I made a note to revisit it with them, but I think the next step is to demonstrate the percentage of perf in elm-css and elm-ui that are taken by changing style rules. Knowing if it is 3% (or 20%) would be very valuable for prioritization.
Concretely, elm-css has a very large project in the works which could result in potentially huge performance gains, and it doesn’t really make sense to measure its performance until that’s done.
There’s also a decent chance that once that project is done, measurements might reveal that the bottleneck is actually computing the hashed classes, which currently has a very naive implementation with plenty of room for improvement!
Well, it seems I totally missed my point by mentioning the hypothetical insertRule example or by focusing too much on performance I was more talking about interoperability and grouping effort (which could lead to better performance among other advantages).
To be clear @evancz, I agree with you and I am not particularly advocating its use at this point.
Let’s try again: currently elm-css and elm-ui use two different APIs and algorithms to attach styles to a node, then merge all styles (usually at a higher level in the DOM tree), currently in a style node, and applying them (usually using a class).
I was wondering if it was possible to find a common API for this, with one or several implementations in libraries (that would not require any elm modification or kernel code). The advantages would be:
it would be easy to test different implementations and compare them (speed, DOM size, ease of debugging, readibilty, etc.). For example elm-css could test the elm-ui one and vice-versa if both are implemented, before choosing a common one.
once a common implementation is used, it might allow to use nodes or styles from one UI library into the other without conversion. It seems interesting to me as we could add some (unfortunately sometime needed) css hacks using elm-css in an elm-ui application, or include some elm-ui elements in an elm-css application without conversion.
a new UI library using inline styles could focus on UI, widgets and layout instead or having to re-implement this. And libraries using the same inline styles merging implementation could be used together without conversion (like elm-css toUnstyled)
it could be more practical to benchmark at such a low level, easier for a new-comer to understand the code and propose some improvements, and if elm someday adds some new API to improve this (because it has been proved to be worthwhile), then once this/those low-level librarie(s) use it, all the UI libraries that depend on it/them would benefit from the improvement.
This is only for the last point that I mentioned insertRule, but it was just a very hypothetical example, maybe a bad one.
At last @rtfeldman, I am aware of the work in progress in the elm-css phantom branch as I am trying to actively contribute to it (#452 and #453), but it seems to me to be partially at a higher level, maybe not incompatible with what I am talking about.
However as I said, this was just a thought and I don’t know elm-ui well yet, so I may be completely wrong. Anyway I am sorry if I wasted your time by missing my point (it is sometimes not so easy when english is not the native language), or by wondering about some non-sense. I will try to give a more concrete example when I find the time.
That looks encouraging. I decided to use elm-css rather than elm-ui because I need to make use of media queries. As far as I can tell elm-ui does not do media queries, if you want that sort of thing with it, you just query to get the window size and write logic to adapt what you show depending on the width yourself - more flexible, but it won’t work for rendering static Html.
That said, I think there will be plenty head room before I hit the performance limits of elm-css, especially seeing how much better it is under 0.19.
I was more talking about interoperability and grouping effort (which could lead to better performance among other advantages).
as I am trying to actively contribute to it (