What's next for suitcss?

[timkelty]

Hey all,
Wanted to start up a discussion to share some ideas & concerns I have about what might be next for suitcss. Would love to get everyone's input.

/cc @suitcss/contributors

Monorepo Done in #151

This came up quite a while ago, and we decided not to pursue it. Lerna makes this pretty damn easy. I think the benefit to development efficiency would be more than worth it.

If we proceed, we would have to decide if we wanted to release packages in a fixed or independent versioning mode.

• fixed is simpler and has less complications with interacting packages. (my preference for suit)
• The drawback is unexpected major version bumps for end-users (e.g. user is only using components-grid@4.x but a breaking change to components-button bumps all packages to 5.x. However, in that case a user could just simply stay on components-grid@4.x with no harm.

Here's an example of what the conversion process might look like: https://github.com/babel/babel-preset-env

Leverage postcss ecosystem

Now that our build is fully postcss, there is a lot we could do to streamline development, and also provide a level of extensibility for our users. For example, currently whenever we have a responsive variant of a utility, we just duplicate the code and change selectors. If a user wants to add a new viewport def (e.g. --xlg-viewport), they're stuck recreating all the code if they want to use it with responsive utilities (e.g. .u-xlg-size1of4).

We should be able to leverage postcss more into our build process to make things like this more configurable. Tailwind CSS, for example, has an @responive directive for generating these.

Spec changes/clarifications

media prefixing for components

Whether or not it is a common or "suggested" practice, I still feel that we should have media-prefixing for components written into the spec. Previous discussions here and here.

Long ago @necolas stated:

For components, you can use media queries directly in your component CSS instead. And in general, I'm not really sure that viewport-width should be the concern of UI components. Certain frameworks will allow you to efficiently re-render the component HTML, and I think swapping out HTML is often simpler and more robust.

While I agree, I think there are still simple situations where media prefixing for components can make a lot of sense. Consider something like this, where you might want to render a gutter on md and lg only:

<div class="Grid md-Grid--withGutter lg-Grid--withGutter">…</div>

NPM Scoped packages

Would be nice to release things on npm with scoped packages (e.g. @suitcss/components-grid)

deprecate preprocessor?

I'm wondering if we should deprecate the preprocessor in favor or using just a postcss and a suitcss-postcss plugin directly. It seems like it's really only used internally anyway (correct me if I'm wrong).

suitcss-contrib

Wondering if it would be a good idea to have a community-managed suitcss-contrib org for people to source "vetted" community components and utils.

Along these lines, I think it would be nice to somehow provide more guidance to the community for common problems everyone needs to solve. Currently , I think everyone kind of figures out how to manage things like typography components, forms, spacing, etc. on their own. While I don't want to provide a kitchen-sink, many of these seem so common that guidance would be helpful.

[giuseppeg]

Monorepo

Sounds good. Maybe independent versioning is the best way to go with the contingency that for example it allows us to bump a dependency and release (eg. npm version patch && release) every package at once.

Leverage postcss ecosystem

If by this you mean use advanced/non-standard features to generate static, production ready code then yeah we could do that. We could ship a pre-built basic version eg. .u-size1of4 and the file to generate custom ones.

Another idea could be to let the preprocessor infer the component name from the main @define comment and automatically add it to the class selectors. This would also make the styles CSS Modules-compatible.

eg.

/* @define Button */

.root { } // replaced with `.Button` can be configurable
.root--secondary {} // `.Button--secondary`

.child {} // .Button-child

This would make authoring also more pleasant.

Spec changes/clarifications

I've been using modifiers for cases like md-Grid--withGutter: Grid--withGutterMd or utility classes to tweak the gutter. But either ways work for me.

On a side note, I agree with Nicolas that with JS e.g. React sometimes you'd rather render a different html structure rather than hacking with CSS to make it work on smaller/bigger screen.

NPM Scoped packages

Y not!

deprecate preprocessor?

If we manage to extract preprocessor into a plugin that'd be great I think!

suitcss-contrib

We can start it any time and see where it goes.

---

Awesome ideas Tim, I think that most of them are actionable, in case we should just prioritize.
Unfortunately I won't have time to work on any of this (with exceptions but I cannot guarantee anything).

[AntonTrollback]

I find myself rarely installing anything other than the Button component, the display utils, maybe the text utils, and perhaps the Grid. The official SUIT components and utilities can be a fantastic way to abstract quirky snippets of CSS (hiddenVisually is a good example) but most of them, are in my opinion, too specific and simple to make it worth installing, configure, and referencing the documentation.

This, in combination with that I also strongly believe (based on long-term and large-scale experience) that SUIT got too excited about utils, makes me not care that much about many of the repositories.

SUIT never solved working with viewport size. The Grid with media query prefixes was really cool and innovative when it was released but I think that extending that approach to other cases doesn't work long term. Agreeing with @necolas that new technology was/is needed.

I think SUIT is the fanciest and cleanest of BEM like methodologies. Love the style guide and the newish tools around that. But, other than keeping it all alive and supposedly improving and cleaning up the documentation, I consider SUIT as finished ✅.

[giuseppeg]

Last time I used SUIT in a project I ended up building a handful of components and a lot of utility classes. As I see it right now most of the times it is hard to come up with the right abstraction for a component and a more utilities/atomic-css driven approach works very well https://medium.engineering/simple-style-sheets-c3b588867899

I don't like Atomic CSS (c) per se or libs like tachyons but writing inline styles using object literals in JS and let a tool compile them down to atomic classes is really nice.

At this stage if I were to use CSS in AnotherLanguage I would write a library for that language similar to one of the CSS in JS' or use CSS Modules. That's why I proposed that we make SUIT, CSS Modules compatible: namespacing with the ComponentName can be automated, and authoring would be a slightly more pleasant experience.

[kristoforsalmin]

Hello everyone,

I've been using SUIT CSS for years now, what a great project.

Monorepo

Great idea, it'd take away most of maintenance burden.

deprecate preprocessor?

I think it makes sense, personally I use PostCSS plugins directly (not to introduce yet another dependency).

Leverage postcss ecosystem

Please don't take me wrong, but I actually like that SUIT CSS uses only proposed CSS features (almost). It makes it lightweight and technology-agnostic. I also do agree with @AntonTrollback regarding the overall state of a project.

NPM Scoped packages

👍 I think, this could be done alongside with the monorepo transition.

---

Going forward, personally, I'd like to see SUIT CSS putting more focus on tidying up documentation and improving SUIT CSS's website. That would make project more appealing for newcomers. Adding small things like logo or moving documentation to the website would definitely increase developer experience in my opinion.

Thanks

[simonsmith]

Finally got around to adding some thoughts

Monorepo

Yes, I agree that we should make this a priority now. The biggest reason for lagging on maintenance for me these days is remembering to publish all the relevant modules. Initially I was worried about losing the issues and what not but I think it's worth the hit and just having a suit repo with everything in there.

PostCSS ecosystem

I'm not in agreement here. Whilst I see the logic I really like the idea of users being able to gradually drop parts of PostCSS out as browser support improves and one day not have a build step at all. I think this is a big win over a little bit of file duplication. A good example is calc and custom-properties.

Media prefixing for components

I can see the value in this and whilst I too have seen great results with things like react-media I don't think there is any harm in permitting in SUIT if it helps users solve problems.

npm Scoped packages

Yes, would be nice to have our own namespace

Deprecate preprocessor

I'm inclined to agree. It's essentially a glorified wrapper around PostCSS anyway. If we formalised a plugin pack we could make it easier to use with the postcss webpack plugin too, or even add our own thin webpack plugin around it.

suitcss-contrib

This is a good idea as linking to them is one thing but if they're not managed or updated it's not great. We could move polished packages into the core org as well if they're good enough. I'd like to nominate my form field package which has been working well 😄

components-grid

I feel like there could be value in moving from Flexbox to CSS Grid as seen in this example

Priority

I feel like focusing on the monorepo first would be wise as it will make working on the other tasks far easier. I'll start looking at Lerna and seeing what is involved

[timkelty]

Sounds like monorepo is unanimous!

The biggest decision is deciding if we want to do fixed/locked versioning or independent: https://github.com/lerna/lerna/#fixedlocked-mode-default

Lets work here; #151

[timkelty]

@simonsmith:

PostCSS ecosystem

Yeah…I guess what I was envisioning was using it more for a development

Media prefixing for components

Yep, I agree solutions like react-media are better, but I think assuming users are in a React/Vue/SPA environment excludes lots of people.

components-grid

Yeah! How do you envision this working? Like would v4 grid be flexbox and v5 be grid? Wondering if we'll want to maintain both for a while until support is greener.

suitcss-contrib

Hey that looks just like the one I never published!

[simonsmith]

Yeah…I guess what I was envisioning was using it more for a development

Ah I see. Well this might be easier to handle in a monorepo which I'm sure we've discussed previously. Perhaps using the suitcss postcss pack to generate the files that go into the npm packages? That could be quite nice.

Yep, I agree solutions like react-media are better, but I think assuming users are in a React/Vue/SPA environment excludes lots of people.

Yes, not everyone has the luxury of swapping out branches of their component render tree so I'm all for this. SUIT still has a place in non SPA/JS app scenarios

Yeah! How do you envision this working? Like would v4 grid be flexbox and v5 be grid?

Yes. We did the same with 2 > 3.

[timkelty]

Yeah…I guess what I was envisioning was using it more for a development

Sorry I submitted that before finishing my thought…yes what you said :) So the end user would include the generated files, but a power-user might want to include the source, provided they're using the right postcss plugins. Would cut down on all this type of duplication and provide extensibility for users that wanted it.

[mlnmln]

Sorry if I am resurrecting any zombies, but could somebody give an update on the current state of SUIT CSS?

• How far did you progress 2018?
• Are there any specific areas where you would need support in 2019?

Thanks!