3 ms·

Taiwind is nice. For those interested in Functional CSS, I've made a Scss/Sass framework too, with different approach. https://github.com/meerita/utilcss https

Taiwind is nice. For those interested in Functional CSS, I've made a Scss/Sass framework too, with different approach. https://github.com/meerita/utilcss https://github.com/meerita/utilcss here is the article related http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/ Once you start using funcional CSS, you don't want to go back.

holler 7y ago
> We have been programming CSS for a long time wrong. Have we though? I firmly disagree with the premise. I agree that like anything else, css can be abused and misused, and the example cited of Newspapers fits the narrative perfectly. I've worked at a major regional Newspaper in the past and their website was one of the worst sites I've seen. The lead developer at that time (10 years ago) switched to using a functional/semantic css pattern much like tailwind/UCSS, and I found it to be terrible. Any experienced FE developer should and will know css, whereas they will not know some random css framework dsl, nor should they have to learn it. Most modern js frameworks are moving towards web-components and scope css to a component, which eliminates much of the past structural ambiguity and reasons for seeing e.g. !important (if implemented properly). The argument about file size is not strong imo. You are trading css file size for html file size. How many modern web apps are slow due to their css file size? I doubt many. The Newspaper websites were always slow due to churn & many people touching the code, often with lower experience, leading to spaghetti. If it works for a team then more power to them, but I'm sticking with css :)
- meerita 7y ago
  Hi, yes, the premise is a bit sensationalist. But any FE experienced will not work for too long on the projects. The projects I've surveyed and work for, changed personnel all the time. I didn't choose the projects to fit my narrative, I did it because most projects die within 5-10 years. Few projects live longer than that, and newspapers are great example for the research. The codebase is really hard to maintain as business grows. That's why I firmly believe, it is not the developer, it's the metodologies they use: they force you to do technical debt, bad arquitectures, etc. Of course functional CSS is not the solution to all, there are situations where, componetize everything will make more sense. But the more you work on, the more useful you see it becomes. The file size is strong for one reason: most connections to CSS resources are blocked by the queue of priorities, HTML files are downloaded between 12ms-100ms range and that means it's already done, plus, if you use reactive HTML, things speed up even more. Most of the CSS made with BEM or other metodologies don't end up with that much HTML saving too, they're quite verbose. You cannot control the verbosity since it's human made. With UCSS or other funcional frameworks, you can control the verbosity of the outputs, etc.
- weego 7y ago
  No we've been trying to turn CSS into programming for too long and doing ridiculous things that other domains wouldn't tolerate like encoding structural annotations in string names (BEM) and endlessly trying to genericise things that are similar only by coincidence or forced coercion which is the obsession of functional CSS "frameworks"
- meerita 7y ago
  One quick extra note about the argument of file size. Those who argument about "more html size" never thought people has to download a huge CSS file for 2 o 3 pageviews. With the current state of the web, the trade off isn't that painful, in fact, you will see that projects done with React, Vue or similar the trade off is a bargain you cannot avoid. HTML is faster, by default, as I state in the article. It's the first document and it's the first one processed. If you have a CSS file of 10kb gziped your chances will be huge in comparison with the averaga ~160kb of some projects. The problem with inline-css (how the modern js framework are handling) is that clashes with the responsive world and cannot be preprocessed so easily as other projects. Besides the file size factor, give a check to the other points in the arguments: amount of rules slows the loading speed, rendering and painting, etc. You're sticking to CSS, we also stick too :)
ivanhoe 7y ago
One question about this approach: If I understand correctly, if I have some text that is bold, and later I want to change it into italic, I have to go into templates, locate all instances of the text and rename all the classes from font-weight--bold to font-style--italic? Seems like "quick to build, but hard to maintain" approach?
- meerita 7y ago
  Before I answer, do you want to change a particular module, particular text or you want to change site-wide things?
  - ivanhoe 7y ago
    Let's for starter say that we need to change something site-wide?
    - meerita 7y ago
      Well, I assume is a component. Can be a layout or a partial, you go there, read the classes, make your changes according to the new design. In case you need extra clases, let's say, you need to introduce something like pointer-events, you go to the framework, you activate it in the config file, then use the class on the div. In case you need extra customization, you write a custom class ex. c-10 and you apply interactions needed (:hover, :focus, etc.).
- meerita 7y ago
  The approach is like programing with inline-css but using classes. Once you start working, you will realize you will reuse more classes and your code will be 100% redeable. Anyone coming behind your work can easily work it. Otherwise he needs to re-learn all the architectural tidbits and change it to his way to architecture it. This doesn't stop you to code small and repetitive components like "buttons". There's an article where you can see how it works.

holler 7y ago

> We have been programming CSS for a long time wrong. Have we though? I firmly disagree with the premise. I agree that like anything else, css can be abused and misused, and the example cited of Newspapers fits the narrative perfectly. I've worked at a major regional Newspaper in the past and their website was one of the worst sites I've seen. The lead developer at that time (10 years ago) switched to using a functional/semantic css pattern much like tailwind/UCSS, and I found it to be terrible. Any experienced FE developer should and will know css, whereas they will not know some random css framework dsl, nor should they have to learn it. Most modern js frameworks are moving towards web-components and scope css to a component, which eliminates much of the past structural ambiguity and reasons for seeing e.g. !important (if implemented properly). The argument about file size is not strong imo. You are trading css file size for html file size. How many modern web apps are slow due to their css file size? I doubt many. The Newspaper websites were always slow due to churn & many people touching the code, often with lower experience, leading to spaghetti. If it works for a team then more power to them, but I'm sticking with css :)

meerita 7y ago
Hi, yes, the premise is a bit sensationalist. But any FE experienced will not work for too long on the projects. The projects I've surveyed and work for, changed personnel all the time. I didn't choose the projects to fit my narrative, I did it because most projects die within 5-10 years. Few projects live longer than that, and newspapers are great example for the research. The codebase is really hard to maintain as business grows. That's why I firmly believe, it is not the developer, it's the metodologies they use: they force you to do technical debt, bad arquitectures, etc. Of course functional CSS is not the solution to all, there are situations where, componetize everything will make more sense. But the more you work on, the more useful you see it becomes. The file size is strong for one reason: most connections to CSS resources are blocked by the queue of priorities, HTML files are downloaded between 12ms-100ms range and that means it's already done, plus, if you use reactive HTML, things speed up even more. Most of the CSS made with BEM or other metodologies don't end up with that much HTML saving too, they're quite verbose. You cannot control the verbosity since it's human made. With UCSS or other funcional frameworks, you can control the verbosity of the outputs, etc.
weego 7y ago
No we've been trying to turn CSS into programming for too long and doing ridiculous things that other domains wouldn't tolerate like encoding structural annotations in string names (BEM) and endlessly trying to genericise things that are similar only by coincidence or forced coercion which is the obsession of functional CSS "frameworks"
meerita 7y ago
One quick extra note about the argument of file size. Those who argument about "more html size" never thought people has to download a huge CSS file for 2 o 3 pageviews. With the current state of the web, the trade off isn't that painful, in fact, you will see that projects done with React, Vue or similar the trade off is a bargain you cannot avoid. HTML is faster, by default, as I state in the article. It's the first document and it's the first one processed. If you have a CSS file of 10kb gziped your chances will be huge in comparison with the averaga ~160kb of some projects. The problem with inline-css (how the modern js framework are handling) is that clashes with the responsive world and cannot be preprocessed so easily as other projects. Besides the file size factor, give a check to the other points in the arguments: amount of rules slows the loading speed, rendering and painting, etc. You're sticking to CSS, we also stick too :)

ivanhoe 7y ago

One question about this approach: If I understand correctly, if I have some text that is bold, and later I want to change it into italic, I have to go into templates, locate all instances of the text and rename all the classes from font-weight--bold to font-style--italic? Seems like "quick to build, but hard to maintain" approach?

meerita 7y ago
Before I answer, do you want to change a particular module, particular text or you want to change site-wide things?
- ivanhoe 7y ago
  Let's for starter say that we need to change something site-wide?
  - meerita 7y ago
    Well, I assume is a component. Can be a layout or a partial, you go there, read the classes, make your changes according to the new design. In case you need extra clases, let's say, you need to introduce something like pointer-events, you go to the framework, you activate it in the config file, then use the class on the div. In case you need extra customization, you write a custom class ex. c-10 and you apply interactions needed (:hover, :focus, etc.).
meerita 7y ago
The approach is like programing with inline-css but using classes. Once you start working, you will realize you will reuse more classes and your code will be 100% redeable. Anyone coming behind your work can easily work it. Otherwise he needs to re-learn all the architectural tidbits and change it to his way to architecture it. This doesn't stop you to code small and repetitive components like "buttons". There's an article where you can see how it works.