Plans for SUIT

[patrickberkeley]

I read the SUIT preprocessor is going to be deprecated in favor of cssnext (or something else), and am curious to know the status of the framework itself (foundation, utilities, components). Is the plan to continue development on the SUIT framework?

[simonsmith]

+1 this.

Happy to help with anything

[AntonTrollback]

+1, happy to help

[timkelty]

+1, also happy to help with anything needed.

[timkelty]

Currently I feel like SUIT is lacking a strong community collaboration aspect. I think it would also help to have a list of known 3rd party components and utilities.

Frankly, I thought I would see more 3rd party SUIT components pop-up in the past year, as people use SUIT in more real-life environments, but it's been pretty sparse.

E.g. https://github.com/VinSpee/suitcss-depth/ https://github.com/briandrum/suitcss-components-text-input https://github.com/trunkclub/suitcss-components-form

I'd like to see more (not to mention, from myself)!

[timkelty]

To expand on my former comment:

An example: If SUIT had a form/field/input component that was either 1st party, or "endorsed", we may see support appear in things like: http://formvalidation.io/examples/#supporting-other-frameworks

[simonsmith]

The tooling also needs to move to PostCSS. It's pretty easy to do yourself but would be good for the official repos to move off Rework.

I believe @necolas has already done this at Twitter based on his comments elsewhere.

[timkelty]

It would also be nice to see a list of public projects build using SUIT.

[patrickberkeley]

Ditto on seeing a list of projects using SUIT. So far it's been helpful to dig through @simonsmith's portfolio.

[necolas]

Hey. I can tell you about some Twitter projects using SUIT conventions:

1. twitter.com (millions of users)
2. embedded tweets (billions of impressions)
3. analytics.twitter.com
4. periscope.tv (with Sass)

---

At Twitter, I don't think we really use any of the SUIT component repos outside of twitter.com. The utilities are used across various project, and the utility pattern is used to create custom utilities.

About the CSS component files. The button one is useful because it styles a single element. The others are less useful if you are using a component framework (rather than writing raw HTML all the time), because they need to style multiple nodes. I've found myself copy-pasting SUIT CSS component code into a UI component's code. For example, I've used all the code in components-flex-embed to create an AspectRatio React component that uses inline styles to set the aspect ratio based on x and y prop values.

As a result, I don't have any plans to add more CSS components. I think SUIT is a BEM-based methodology and supporting tools. The methodology is "done". It works for component-based frameworks. But if it helps we can maintain a list of other repos that are helpful for anyone not using a component framework.

The postcss linter has had some great improvements from @davidtheclark https://github.com/necolas/postcss-bem-linter – I'm hoping to integrate that into one of our apps and then cut a new release. That provides some solid tooling to lint SUIT and other BEM-like syntaxes.

Unfortunately, I think cssnext has turned into sprawling, monolithic library that has to expose the API of each of its dependencies. Installing a module to handle the preprocessing is convenient though. Will probably use it for development but recommend postcss in general, since there are several postcss preprocessors that can transform the existing packages.

I'm also happy to accept pull requests, and will update the documentation and suggestions at some point (to reflect some of our experiences over the last year or more). But the aim of the project was for it to be very limited in scope, not to be a framework or tooling, and to provide an enforceable means to avoid some of the major pain points of working with css on apps…I think it's largely done that.

[simonsmith]

Nice update. It's great that you have various parts of Twitter to battle test this stuff.

Unfortunately, I think cssnext has turned into sprawling, monolithic library that has to expose the API of each of its dependencies

Yeah, it covers a lot of things. I decided to use just the necessary PostCSS plugins and it's only about 4-5. It felt too small to even justify a postcss-suit really. Plus it's nice to mix and match your own collection of PostCSS plugins for each project.

(to reflect some of our experiences over the last year or more).

Have often thought about a collection of best practices on the repo. When I started with SUIT I definitely struggled with some concepts that we could round up in one document. I'm sure there are a few people here that could contribute advice from using SUIT on larger sites.

I'd be happy to start something off in a PR.

[timkelty]

Thanks for the update @necolas.

I agree with @simonsmith about cataloging some best practices and common SUIT design patterns. It's really nice to see to see how others approach building components and comparing it to your own (th

In general, the SUIT methodology is pretty simple, but digesting how one builds components that interact with each other to actually compose an entire screen/page can be a hurdle. Common patterns I've seen are "super"-components like Container, Page, Type, etc. There's no "right" way, but it would be nice to see examples in one place.

[MoOx]

@necolas I am not sure what do you mean by "Unfortunately, I think cssnext has turned into sprawling, monolithic library that has to expose the API of each of its dependencies.". How is it monolithic ? Under the hood, it's just a small wrapper of some postcss plugins enabled/disabled depending on your browser scope. You do not need to know the dependencies at all to use cssnext. That's the idea behind it (the api to customize each dep is just a something so people can tweak each dep if needed) The idea of cssnext is to be a sort of autoprefixer for the entire css syntax. A sort of babel for css. Nothing less, nothing more. If something does not looks good to you, or if you think I am leading this project in a bad direction please do not hesitate to share your ideas, I feel lonely sometimes because I do not get a lot of input (even if I saw more & more people using it each day).

[dcadenas]

@simonsmith @timkelty I noticed that most of the time when working with this methodology I evolve components from utilities. Somehow what Refactoring to Patterns describes: http://martinfowler.com/books/r2p.html. First I start to draw the css with the utilities as much as I can. As soon as I start noticing repetition or things I can't do with just utilities, I extract the tiniest component possible. Does someone do the same thing or have similar patterns and tips to share?

[patrickberkeley]

Thanks for the info @necolas !

to provide an enforceable means to avoid some of the major pain points of working with css on apps

SUIT has nailed down what I've been approaching on my own. The documented naming conventions are gold.

@dcadenas Within the past month of discovering and using SUIT, I've begun following the same pattern: use as many layout and utility classes in the markup as possible, then add my own component class only when I have to.

This has resulted in few, small components without much (or any) layout styles, and primarily decoration styles (typography styles mostly). The benefits in my mind:

1. Less CSS to write and maintain
2. Once you learn the helper classes, development can go much faster

I haven't yet come across a repeated combination of utility and/or layout classes that warrant their own component.