Why?
nelsonic opened this issue · comments
Why?
Most of the time "developers" don't make the time to learn CSS. Some people consider CSS "messy", however a better description is: "quirky"...
There are many CSS/UI frameworks that attempt to give you an out-of-the box "solution" for CSS, and a few have been successful. These are a few we have used (but there are many more to chose from):
- Bootstrap: http://getbootstrap.com/ - by far the most popular, but it has morphed into a mega-framework with lots of CSS & JS ...
- Flat-UI: http://designmodo.github.io/Flat-UI/ - we really like Flat-UI and have used it a few times, especially like the form elements. Sadly, the "wow" comes at a price. In addition to including
bootsrap.min.css(22kb) your users still need to downloadflat-ui.min.css(27kb) andflat-ui.min.js(73kb) ... all-in you're going to force people accessing your site/app on a mobile connection to wait 2 seconds before the page is loaded... - Pure CSS: http://purecss.io - Yahoo's answer to Bootstrap. Much smaller (4.0KB* minified and gzipped) and CSS-only.
- Foundation: http://foundation.zurb.com/ - probably the most feature-rich UI framework. like bootstrap, has both CSS and JS.
- UI Kit: http://getuikit.com/ - lots of "fancy" (JS enhancements) some people will find "reasons" to use. which comes at a price.
- Material Design (Light): https://getmdl.io/components/index.html used it in a couple of client projects. hideous naming convention and difficult to override the JS interactions.
- Skeleton: http://getskeleton.com/ - v. lightweight. though appears to be un-maintained at time of writing.
Why Tachyons?
Tachyons gives you less. Much less than virtually all the other frameworks. Why is this a good thing...?
Read the Principals: http://tachyons.io/#principles and see if you agree ...
For one, who doesn't love being able to make sites so quickly!? I orignally started using Tachyons as a way to quickly, and I mean very quickly, prototype designs or layouts. Since, I've grown to use it in most projects.
Known as functional css, this method has been very easy to learn and understand. There is a growing library of tool around it, Jekyons being one of my favourites, and there is very little barrier of understanding developers and designers (me!) alike.
Tachyons draws its principles from Unix, and has lead to or been inspired by similar libraries such as basscss, gemma, and spector.
Adam has spent quite a while perfecting Tachyons for his use. As much as I'd like to add some classes, he's made sure to keep it to only what's really needed, providing for such a small size. When with tools like Uncss when moving to production, you can do things a lot faster with Tachyons.
I'm still figuring out how to use this in bigger projects. I know that it was a big part of Adam's time at The Grid. More projects where this has been used can be found in the "Gallery" section of the site.
So, I guess the main reasons why you might use it are because:
- it is performant
- it is easy to understand
- it is easy to use
- it is good fkin css
The debate shouldn't be on why tachyons, but rather why functional css.
WARNING: this comment contains links across both phrases and individual words. Check them all out for maximum knowledge gain 😉
@enociz thanks (so much!) for your feedback, links and insight!!
You're right, we should introduce/discuss Functional CSS first and then propose Tachyons as a potential option ...
Loving all the links @enociz, thank you!
How is tachyons different from inline styles? (it's worth reading this discussion...):
tachyons-css/tachyons#12
Tachyons Components: Full-bleed with Vertical and Horizontal Centering:
https://vimeo.com/174813041
I've started using Tachyons for a personal project and it's felt like a bit of a revelation so far.
I've used a couple of css frameworks before and whilst they've had benefits I've never personally really liked them. Heavy ones like boostrap and materialize I often find myself fighting against (and writing more css to override classes or make new custom ones), or letting their design decisions take over. Minimal ones like skeleton, whilst what they do they do very well I've ended up writing a fair bit more css to fill the gaps.
What surprised me with Tachyons / Functional CSS was
- being able to replicate quite a few designs exactly as I want them and I've only had to write 2 lines of CSS so far!
- the defaults the classes place on you out of the box are the right kind of defaults: a consistent set of spacing rules for paddings, margins, grids and font sizes, not what colour your buttons are or how big shadows should be.
- building responsively is a total breeze with screen size prefixes on almost every class (
-ns,-m,-l, for not small, medium and large) - the class names seem a little terse and abstract at first but became surprisingly easy to use and remember after a short while
- the html looks 'ugly' but I actually find it easier to debug and change, each bit is 'referentially transparent' (you don't have to go digging for media queries or other classes)
I really like how the screen size prefixes encourage mobile first design, there are no -xs or -s , the un-prefixed classes are the mobile classes and everything else is an enhancement as the screen size gets larger.
I've not encountered any serious gripes yet but will see how it goes as my project gets larger. However, currently finding this coupled with handlebars very powerful 👌😍
We seriously ❤️ that you took the time to share your thoughts on this @andrewMacmurray !
We always appreciate the shared learnings (as you can see the repo is pretty empty right now) 😉
No worries @iteles! 😄 , I could try and put something together for the repo if that would be any use?
Always @andrewMacmurray!
Original Comment from @nelsonic :
P.S. the more page-specific-CSS I read the more I'm tempted by [this issue] 😉
I am finding that as a project expands and goes on Semantic CSS becomes harder and harder to make re-usable - the fear being that it will eventually become "(too)" bloated -
Would be very interested to know whether
73kb of tachyons.min.css + an individual projects overrides / customs
is greater or less than
@OxfordAbstracts app.min.css, a single custom semantic file (BEM)
as of right now a minified version of that project's app.css is 31kb
@harrygfox yeah, sadly that comment is on a private repo... 😞
I think the work you are doing to tame the Semantic CSS on that project is
superb✨
My understanding is that tachyons.min.css was meant to be a lot smaller: http://tachyons.io/#features
But, I don't think the size of the Library/CSS Framework is the main concern.
The thing I care about is if it makes the code easier to maintain...?
(I don't know "facts" on this yet, but the people - experienced front-enders - I've spoken to love it!)
I'm itching to find out if someone has any data ... I've heard quite a few anecdotal "success stories"
@mrmrs is there an (unbiased) comparison somewhere?
@nelsonic sorry don't know if I followed exactly you wanted a comparison of? Happy to provide any data I have. As far as tachyons size, 73kb is not quite accurate. If it's gzipped (and it should be) the file is a bit under 14kb. This to me is actually still a bit large for my taste but is pretty easy to strip away some less commonly used modules and get the file size down if that is your biggest concern.
I think it is generally one useful to compare gzipped and minified filesizes though as that should be
what you're actually sending across the wire.
For me @andrewMacmurray really hit on the values I've personally gotten out of using the patterns within tachyons - but I think you could apply the same patterns in a variety of other ways and achieve similar results. To me the important parts of a front end system is that it's:
Responsive, fast loading, readable, easy to change and easy to debug. I've found managing css in js with something like http://jxnblk.com/cxs can provide a lot of similar benefits, but I've found I've lost some velocity as I'm a bit slower to compose visual styles in that paradigm, but it's also something I'm quite new to. That being said, it achieves everything I listed out above even though it's a much different pattern.
As far as additional overrides, anecdotally for myself I generally write somewhere between 2-100 lines of custom css which generally doesn't even add up to an entire kb. Most often my additions are custom animations.
For what it's worth v5 (which is almost in alpha) should be well under 10kb. Let me know what questions I missed though, happy to share my experiences or data concerning functional css.
@mrmrs Wow! Compelling stuff, thank you. I'm really excited for getting my hands on Tachyons.
The one remaining concern I have with Functional CSS
If the markup on a very large or complex project was not modularised into partials - is implementing a design a very involved / convoluted process. What are your resusable parts?
@andrewMacmurray, you mentioned the benefits of pairing a functional library with handlebars partials - the partial is the reusable part and you apply the designs with classes on the markup. Then the reusable pattern is the partial - those combinations of classes must be repeated in another part of the design.
BEM, by comparison, mimics modularised web design in having blocks and children elements. The reusable part is a part of the object-oriented library that you apply with classes to the markup. Basically the effect is to be ble to look up the requisite styles for, say, the navbar, intuitively. They are labelled by what they are or what they have an effect on.
Tachyons is a merging of styles and markup meaning that, when growing a project, there's a reusable action one must take - styling new markup - rather than a reusable pattern that one applies.
It would seem to me that an important part of using tachyons is having a tight design spec and small partials - I'm not sure if what I've said above makes a whole lot of sense but, I think there could be a significant effect on the implementation cost of each solution. Any thoughts?
@harrygfox I don't know if I follow your BEM comparison so I can't speak to any of that.
I can speak to - what about situations where you aren't using html templating? What about having lots of duplication in your HTML?
I've worked in more systems that use component based css architecture. Some of them have had shallow cascades, with low peak specificity scores. Some were very deep with lots of overrides. But the consistent part was that when we would try to standardize and redesign a button we always had to touch html and css. And we always spent time debugging.
I like to be able to do work iteratively. I rarely see front-end development at scale happen in a truly 'global update one thing in one place and have it go everywhere' paradigm. It's a goal, and often times achievable on small personal projects. But otherwise I've found this is not very realistic. I think that when you encapsulate the styles to the html in a composable multi-class pattern, you can edit a view and make changes iteratively with no consequence to other pages or components, and this has a very big effect on ui development velocity in my experience. If you abstract things into partials, you actually might have the same problem. Updating one component while it propagates out to views that you can't test or see... this can be daunting. So you'll probably just create a new component (I've seen this pattern happen before in several different templating systems). I think that not templating stuff isn't that big of a deal in many situations. If you do need to update many buttons to change their design, or make them more consistent, it's very easy to change a view and test it, and not affect anything else. This allows tickets to be broken down to their smallest bits in regards to scope. If you practice agile, it can definitely be easier to estimate smaller changes, and this is reflective of how a lot of places I've worked operate. They break things down to small testable changes.
I don't think you need a tight design spec, I think you just need a flexible system, and it should be that your design specs allow for flexibility in interpretation when you apply the design system on the front end.
I think design consistency on the component level is best communicated through documentation. The tachyons docs are open source and it's very easy to generate your own component library just by adding html partials with some front matter. e.g http://tachyons.io/components
In the codebases I have worked in and inherited I have not found a correlation between front end architecture and ui consistency. cssstats.com does a decent job at illustrating this. BEM architecture can lead to hundreds of font sizes on a site. People can use really heavy selectors with IDs and content semantic class names and have a nice type scale with 8 sizes. I think often consistent ui is a result of a team that communicates and documents ui really well. You can build really inconsistent UI with tachyons. But I also think there are a number of tools and patterns that lend themselves to promoting visual consistency and code reuse.
In short, I have found a wide range of people are at their fastest, editing html with hot reloading / browser-sync / live reload. Consistent feedback I've gotten is people are often surprised at how much lower the cognitive load is during development when you don't have to leave the html.
Let me know if I didn't address your concerns accurately and I will try to modify my comments to more accurately reflect your questions.
@mrmrs Thank you so much for your response. Your expertise are invaluable to me. I'll be using tachyons on my next project with dwyl - I can't resist anymore!
Modularised CSS components & spending less time maintaining are huge life-improvers for me.
it's very easy to change a view and test it, and not affect anything else. This allows tickets to be broken down to their smallest bits in regards to scope.
I have felt that drop in my stomach when I change CSS and rush around testing for undesired effects in unwanted places. Strewth.
Again, thankyou @mrmrs.
@harrygfox when do you want to start that #NextProject ...? 😉
Thanks everyone for participating in this discussion and sharing all these great insights! 😍
We have iterated on the "Why?" section and tried to summarise the main points (without making it too long) please let us know if we have missed anything or if there is a key feature/benefit/selling-point we should highlight to beginners and non-techincal decision makers (i.e. clients who may be "unsure" about us using Tachyons for their project). 👍
Let's see where these stats go now that everyone has write-access to the repo ... 🤔
⏭️ GOTO: https://github.com/dwyl/learn-tailwind#what-about-tachyons 💭
Keeping a keen an eye on: https://github.com/components-ai/css.gui 😍