3 ms·

True, but I believe that this approach is fairly gzip friendly. So repetition is not an issue. Ok, that's true. But what about browser caching? Using tradition

True, but I believe that this approach is fairly gzip friendly. So repetition is not an issue. Ok, that's true. But what about browser caching? Using traditional CSS, users only have to visit one page and they've downloaded the stylesheet for the entire site. They can navigate to 100 other pages and never have to re-download the stylesheet because it's cached. With DSS, our CSS files are smaller but our HTML bodies are larger due to all of these class names. That means every time we load a new page, we're downloading thousands of bytes of class names that we already have. For static rendering this is a no-go, regardless of gzip. Controlling things globally could be handy but it won't scale. I don't think that it is a deal breaker to toggle some state in your app and hit refresh. It's a deal breaker for me because my designer doesn't know Elixir. You act like toggling "some state" within an application is trivial. Maybe it is to you or me but it might not be to one of your team members who is only concerned with the CSS. I don't know what you mean by "won't scale". We're talking about changing styles in the browser. This is a developer workflow issue, not a technical issue. The main feature of DSS is deterministic styles resolution anyway, atomic CSS classes are only the medium to achieve that with plain old static CSS. Not true. There's another way to achieve that: good CSS.

ggurgone 8y ago
Typically this is a concern only for server side rendered and dynamic pages. When you render on the client you don't have these kind of issues (only pros). When pages are fully static (e.g. a landing page) you can configure your server (or proxy) to also send the right headers so that even the HTML is cached. In the case of dynamic SSR pages instead you lose caching but that's not an issue imho. You should optimize for initial rendering and delivery a small amount of CSS (critical CSS) is a recognized best practice. Again gzipped the HTML is fine dss-lang.com's heaviest page is 6kb. > It's a deal breaker for me because my designer doesn't know Elixir. You act like toggling "some state" within an application is trivial. Maybe it is to you or me but it might not be to one of your team members who is only concerned with the CSS. I don't know what you mean by "won't scale". We're talking about changing styles in the browser. This is a developer workflow issue, not a technical issue. As I said you can add readable class names and can tweak styles in the browser and then copy/paste to the .css file. I am also going to add source maps support. If designers are authoring production or dev styles they should be able to control simple states like that (the same way they should be able to add a css class to an html element in your templates). An escape hatch could be introducing a `:global` pseudo class like in css modules - it'd allow to add the dev and prod classes you are talking about but it would break deterministic styles resolution (unless everything is wrapped with one or the other). > Not true. There's another way to achieve that: good CSS. Define "good". Even if you have a reasonable definition, experience has taught me that it is very hard to do so (specially when you work in teams) see this thread: https://twitter.com/giuseppegurgone/status/1028595207825186816 https://twitter.com/giuseppegurgone/status/10285952078251868...

ggurgone 8y ago

Typically this is a concern only for server side rendered and dynamic pages. When you render on the client you don't have these kind of issues (only pros). When pages are fully static (e.g. a landing page) you can configure your server (or proxy) to also send the right headers so that even the HTML is cached. In the case of dynamic SSR pages instead you lose caching but that's not an issue imho. You should optimize for initial rendering and delivery a small amount of CSS (critical CSS) is a recognized best practice. Again gzipped the HTML is fine dss-lang.com's heaviest page is 6kb. > It's a deal breaker for me because my designer doesn't know Elixir. You act like toggling "some state" within an application is trivial. Maybe it is to you or me but it might not be to one of your team members who is only concerned with the CSS. I don't know what you mean by "won't scale". We're talking about changing styles in the browser. This is a developer workflow issue, not a technical issue. As I said you can add readable class names and can tweak styles in the browser and then copy/paste to the .css file. I am also going to add source maps support. If designers are authoring production or dev styles they should be able to control simple states like that (the same way they should be able to add a css class to an html element in your templates). An escape hatch could be introducing a `:global` pseudo class like in css modules - it'd allow to add the dev and prod classes you are talking about but it would break deterministic styles resolution (unless everything is wrapped with one or the other). > Not true. There's another way to achieve that: good CSS. Define "good". Even if you have a reasonable definition, experience has taught me that it is very hard to do so (specially when you work in teams) see this thread: https://twitter.com/giuseppegurgone/status/1028595207825186816 https://twitter.com/giuseppegurgone/status/10285952078251868...