16 comments

  • Sebastian GrazSebastian Graz, over 1 year ago

    Took a quick look, and it looks really solid. It's similar to Tachyons but with high configurability which was the main issue with Tachyons. I will deffo give this framework a wizz for any future projects.

    2 points
    • Sebastian Winther, over 1 year ago

      I'm curious: where did you find that Tachyons fell short, where Tailwind may not? I'm starting a project soon and was planning on using Tachyons, but will reconsider if it makes sense.

      0 points
      • Sebastian GrazSebastian Graz, over 1 year ago

        When using Tachyons I found it tricky to change the media query values. They are hardcoded in CSS so to speak. Whereas in Tailwind, because it PostCSS the media query values is simply a variable. Also I like Tailswinds responsive approach with the sm:, md: and lg: colon suffix, rather than specifying 'not-small', 'medium' and large.

        That said Tachyons is amazing, and I have 0 experience using Tailwind. Just my 0.02$. In fact Adam Morse Tweeted yesterday about being able to customise Tachyons, but I have not tried it (https://twitter.com/mrmrs_/status/925817836613677056)

        1 point
  • Chris GriffithChris Griffith, over 1 year ago

    This looks like an incredible system. I had been working on a framework that is similar to this (https://github.com/decent-css/decent) for about a year because of the lack of configuration available with Basscss and Tachyons.

    I transitioned to using functional CSS about two years ago and haven't looked back. Once you break the mindset of how we used to write CSS, it becomes incredibly quick to build good looking things — pair that with a component-based framework like React or Vue and the possibilities are endless.

    1 point
  • Roman Pohorecki, over 1 year ago

    Took a quick look at the button CSS in the first example:

    < button class="text-xs font-semibold rounded-full px-4 py-1 leading-normal bg-white border border-purple text-purple hover:bg-purple hover:text-white">< /button >

    That is a TON of micro classes to get a vanilla button going in HTML. I get the atomic movement, but writing all this every time you want to add a button is nutty. And it's hard to decipher.

    1 point
    • Chris GriffithChris Griffith, over 1 year ago

      If you're working in any templating or component framework you should create a reusable component for something like a button. Then you only write the classes once in the component and then in something like React, call <Button> everywhere else. This also provides a source of truth.

      Try using it in a project before providing the "hard to decipher" argument. Sure, there are a lot of classes there, but you can see every style that is being applied – right in the markup. I'd argue that is easier than parsing through markup and stylesheets and dealing with inheritance issues.

      5 points
      • Olivier FOlivier F, over 1 year ago

        OK, but if you're going to make a component, why not put normal CSS in that component? I use Vue which has single-file components and scoped CSS. With these capabilities I have a hard time seeing the advantage of tachyons and tailwind.

        2 points
    • Beni GartenmannBeni Gartenmann, over 1 year ago

      I get your argument, but Tailwind has got you covered ;) Did you see the second example about the component-friendliness? There‘s even a whole section about extracting components in the documentation: https://tailwindcss.com/docs/extracting-components/ I think the @apply directive is very powerful. This, together with the high ability of customization, clearly sets it apart from other atomic css solutions.

      2 points
    • Adam Wathan, over 1 year ago

      Hey, framework author here! Like Beni mentioned in his reply, we totally agree and have tooling and workflows baked into the framework for extracting these common patterns into component classes when you feel the need to do it:

      https://tailwindcss.com/docs/extracting-components

      We just don't provide classes like btn by default because in my experience with frameworks that do, you end up fighting with default styles and undoing things which I think is more trouble than it's worth. Better to give people the building blocks to create whatever button style they want, and give them tooling to easily create abstractions around those building blocks when needed.

      2 points
  • Pete Sadler, over 1 year ago

    This is madness. What is the benefit of this over CSS/SCSS + variables and mixins?

    1 point
    • Juan J. RamirezJuan J. Ramirez, over 1 year ago

      Many people find Functional CSS ridiculous at first but there are several advantages, like avoiding CSS legacy, better naming, easier debugging, more consistency in the UI, no global scope and no specificity issues, better adaptation to particular workflows, easier to scale and de-scale, and just a better understanding of what the CSS is doing.

      Also, this is not a pre-processor prohibitive approach. If you have a very complex UI you can just bake in your pre-processor approach or even better you can create a new stylesheet and address those problems separately.

      I started using Tachyons and I don't think I'm going back. It's simply a better way to work. People think that having the ability to do something like storing a color in a variable will give them ultimate control over a layout, but I think that's far from true . Functional CSS allows you to work with simple "find and replaces" tasks to change your whole website or a single page. Granted, this seems like an archaic approach but it's more predictable, readable and human.

      5 points
  • Ling Zhou, over 1 year ago

    If the goal is to encourage customization, I would recommend adding sass/scss version of the framework.

    0 points
    • Jonathan Reinink, over 1 year ago

      Hey there! One of the authors here. Tailwind is based on PostCSS, so you can technically use it with any preprocessor of your choosing.

      1 point
  • Matt Fulton, over 1 year ago

    I've no experience with functional CSS like this, but the dev in me loves how much easier/more legible this could make UI-testing. When testing small UI changes that follow state changes, it's seems like this could make test code much easier to read and maintain. For example:

    expect( !!element.className.match(/border-purple/) ).toEqual( true )

    is clearer and more maintainable when we change our shade of purple, than:

    expect( element.style.borderColor ).toEqual( rgba(43, 233, 123, 0.95) )
    0 points