Long-Term Goals of elm-css - feedback appreciated!

[Richard Feldman]

I wrote up some thoughts on the long-term design goals of elm-css. If anyone has feedback on this, I would love to hear it!

In particular I'd love to know if I missed something which might change the conclusion. :)

[Peter Damoc]

It would be very useful to have the assertions made in the article backed up by relevant tests.
Maybe a complex enough example could be made and the performance of each approach (buildtime vs runtime)  properly tested.

With proper design, one can have the runtime compilation happen once (on load) for the majority of the app's styles and it could have similar performance. 

I would be interested to see where would that approach break down performance wise. 

Also, since this is related to future goals, one of the approaches that will become available soon is the approach of web components. 
I understand the concerns regarding "mutation-as-service" but there is one way to use web-components where we could have just a bundling of Html with CSS. 

That could prove very attractive. It is functionally similar to the mentioned styled-components.
The main advantage of this approach is that it can be (theoretically) optimized at build time.   

  



  

On Mon, Mar 27, 2017 at 6:53 AM, Richard Feldman <richard....@gmail.com> wrote:

I wrote up some thoughts on the long-term design goals of elm-css. If anyone has feedback on this, I would love to hear it!

In particular I'd love to know if I missed something which might change the conclusion. :)

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/75c8137b-b5e2-4f3f-8581-eba9a4aefce5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Kevin Yank]

On Monday, March 27, 2017 at 2:53:26 PM UTC+11, Richard Feldman wrote:

I wrote up some thoughts on the long-term design goals of elm-css. If anyone has feedback on this, I would love to hear it! 

Great writeup, Richard! Do you mind if I promote this a little more widely? My corner of the React community is having the same debate about build-time CSS (with CSS Modules as the leading implementation) vs runtime CSS (with Styled Components as the newest iteration of this idea), and I’d be interested in what the proponents of Styled Components thought about the rationale you lay out here.

[Richard Feldman]

Sure, although I'd point them to the #elm-css Slack channel to discuss rather than this list. :)

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/7ed9404a-e7e8-4ba8-a651-01e1b5a3484c%40googlegroups.com.

[Liam Curry]

Nice write-up. I agree with your conclusion that generating CSS files at build time are the way to go, and that runtime styles should only be used for dynamic styles.

I use this approach because it lets Browsersync inject CSS files without reloading, instead of needing to completely refresh the page because the JS changed. This also means I have to keep my elm-css code separate from my regular Elm code (aside from a common module with the CSS class/ID union types), so I can't mix my styles with my views ... but I think that's probably a good thing anyway.

Another benefit to CSS files is that they can be ran through PostCSS which can do a lot of fancy things like add vendor prefixes, inject image dimensions/URLs, etc.

Runtime styles are still nice to have for letting users change the look/feel of the site. This might be a good candidate for CSS variables! So then you'd have your pre-built CSS files with CSS variables, and inject an inline <style> element that defines the CSS variables. Best of both worlds?

[Samuel M. Gwilym]

I'm not sure whether this has any bearing your conclusion, but I've been thinking about this paragraph:

Another factor to consider is that precompiled styles benefit more from gzip. The reason elm-css supports mixin (but not an inheritance feature like @extend from Sass or composes from CSS Modules) is that in practice these inheritance features are worse for both performance and download size (because of gzip) than mixins, making them turn out to be footguns that should never be used for any reason.

My understanding is that CSS Modules' `composes` does not work the same way as Sass’ `extend`, and this conclusion does not apply to CSS modules. Here's a comparison, starting with Sass:

.big-text {
  font-size: 5em;
}

.big-red-text {
  @extend .big-text;
  color: red;
}

Is outputted by Sass into:

.big-text, .big-red-text {
  font-size: 5em;
}

.big-red-text {
  color: red;
}

Here's how the same thing would look with CSS Modules and `composes`:

.bigText {
  font-size: 5em;
}

.bigRedText {
  composes: bigText;
  color: red;
}

would be output to: 

.bigText_obfuscated {
  font-size: 5em;
}

.bigRedText_obfuscated {
  color: red;
}

This looks strange at first, as it looks like the two aren't being connected in any way. This is because there is another transformation occurring at the call site of this CSS, where we are importing these styles:

import styles from './styles.css';

const warning = () =>
  <p className={styles.bigRedText}>Warning!</p>

is transformed to:

const warning = () =>
  <p className={"bigText_obfuscated bigRedText_obfuscated"}>Warning!</p>

I don't know how this would impact the test linked to in that blogpost, and also I'm not even sure it's a fair comparison as CSS modules is more intertwined with the application source at build time, whereas Sass is simply a case of transforming Sass files into CSS.

[Sebastian Porto]

I agree that performance is really important and because of this build time css seems to be a clear winner.

However, in most apps I have work on static css like this turns out to be limiting. A typical example I come across is theming of the app.
You want to change some colors on the fly and runtime css make this very easy. With static css you need to make alternatives classes for each theme.

So it would be great if the default is static CSS and also a escape hatch is provided to do run time css when needed by injecting style tags. It would be nice if the function names make this distinction quite clear.

[OvermindDL1]

This is where CSS variables are useful, supported by some browsers now but there is a polyfill available as well for the others (*cough*IE*cough*).

[ggur...@gmail.com]

You may want to take a look at styled-jsx for some more inspiration. 

It works at build time and you can get similar benefits of styled-components

[Konstantin]

Hey, I am one of the members of styled-components and I am also the creator of elm-styled. I would like to put my two cents into this discussion.

I do agree with you that performance is really important and thus build time CSS should be used whenever possible but I disagree with you that this is a one or the other discussion. In my opinion there should be one api and the tool should decide whether it injects the rules into a CSS file at build time or injects the rules at run time.

At styled-components Max and Glen removed the mapping between elements and styles. In convinced that this is the feature why styled-components is better than all the previous CSS in JS solution. I would love to see elm-css take a similar step as I think it's a good practice to encapsulate the styles to a single element. E.g. you don't want to have your input styles applied to a div. This feature is the only reason I decided to create elm-styled.

In the end I would love to see elm-css going a little bit away from the classical CSS preprocessor approach and to have a more seamless integration with elm-reactor.

I would love to discuss the future of elm-css further and help whenever possible.

[Richard Feldman]

My understanding is that CSS Modules' `composes` does not work the same way as Sass’ `extend`

Thanks for pointing this out, Sam! I removed the reference to composes.

Another benefit to CSS files is that they can be ran through PostCSS which can do a lot of fancy things like add vendor prefixes, inject image dimensions/URLs, etc.

Thanks Liam - I updated this section to include that.

 

So it would be great if the default is static CSS and also a escape hatch is provided to do run time css when needed by injecting style tags.

Yep, great point Sebastian! This is already doable today, even without CSS Variables, but it's not really called out in the docs. (Maybe it should be though?)

I added some details about this approach to this section. Curious if anyone knows about an upside to the <head> approach I'm missing.

I think it's a good practice to encapsulate the styles to a single element.

Konstantin, this is already doable; no need for a whole separate library, just call withClass. :)

(Granted, this currently takes more work to do at build time because we have to come up with a class name to connect the precompiled stylesheet and the DOM element at runtime, but in a world where we are automatically generating classnames at build time, that downside goes away.)

I added a paragraph to the end of this section about this.

Thanks for the feedback, everyone! This has been really helpful to hear. <3