Styling - a big challenge these days

community
1

People are talking about JS fatigue these days. I believe styling is a big part of the problem today, especially with React.

The fact is that there are about 10 (or more) different perfectly valid choices to handle styling. Take a look at this article: Styling React on survivejs

Here’s my favorite picture. CSS was supposed to make styling easy but now I could probably do a PhD just studying CSS:

3358×2233 240 KB

So here are some of the options – Methodologies: OOCSS, SMACS, BEM. Pre/post-processors: Less, Sass, Stylus, PostCSS, cssnext. BUT you could also use inline styles with React, or Radium, react-style, JSS, react-inline, jsxstyle, AND/OR finally ‘css modules’. (comparison table of React styling options)

But of course, if you don’t want to start from scratch, you should probably pick some kind of a starter framework, like Bootstrap (3 or 4?), or Semantic UI. Material-UI or Materialize? Or maybe PureCSS? Foundation? Polymer?

Also, there are lots of React wrappers of some popular CSS libraries, for example React-Bootstrap and react-semantify (not to be confused with react-semantic-ui!) But I’m not sure these wrappers add much value, in fact I wonder if they just confuse me even more.

What are your thoughts, and what are you using, or planning to use on your next project? cssnext looks cool and promising, but frankly I’m overwhelmed with it all, I want to say ‘fuck it’ and make my websites look like craigslist :smiley:

4 Likes
2

It’s easy to get overwhelmed with so many options and soapboxes, but give this a try. Here’s what you should be aiming for:

  1. SASS for syntax/features.
  2. SMACSS - Method for writing clean styles. https://smacss.com/
  3. The fourseven:scss package to autocompile your .sass files.
3

I don’t know much about style organization, but I think SCSS + PostCSS basically covers everything, and it’s super easy to set up with Meteor - I think the big diagram with lots of boxes makes it look complicated when it really isn’t.

5 Likes
4

I use React, BEM class names, SCSS, and fourseven:scss. Then if I want to, I’ll use a start kit like Materialize SASS or Bootstrap SCSS.

5

Don’t get too caught up in all the details and noise.

  1. Sass for pseudo-elements, pseudo-classes, media queries, and general stuff such as UI, layout, typography that’s on a broad scale across your app.
  2. Inline styles (in JSX) for styling specific components or aspects of components that you want easy access to in order to make quick changes to said component (plus, that style is nicely bundled with the component for simple reuse).
2 Likes
6

Have you seen this:

https://speakerdeck.com/vjeux/react-css-in-js

Ultimately I’m a pragmatist - I can use SCSS if that solves most of my issues without adding much complexity.

But I’m also looking for a good starter kit of UI components. I don’t want to write everything from scratch, and I’ve tried bootstrap and semantic UI but I’m not convinced by either. I like modular approaches.

7

I feel like the usefulness of a CSS framework is inversely proportional to its modularity. IMO the whole point of something like Bootstrap is that you get something nice out of the box - if you don’t like that, then I’d guess the amount of code you would have to write to customize it exactly to your needs is similar to what you would write if you did it from scratch anyway.

If you use something that is very modular and configurable, I feel like you’ll need to learn just as much as you would to use “raw” CSS in the first place - it’s not too hard to write your own SCSS mixin for a rounded button.

3 Likes
8

Thanks for suggestions @idmontie.

I’m curious do you use a meteor package for materialize SCSS or bootstrap SCSS, or do you just copy the .scss files into your project?

9

Yikes, that’s just nasty.

1086×532 243 KB

Use SMACSS, be organized and you avoid going Frankenstein on your codebase. (But really, that’s just awful)

https://www.smacss.com/book/categorizing

10

I use the package poetic:materialize-scss with fourseven:scss. And then I’ll have something like this in my main.scss:

@import "{poetic:materialize-scss}/bower_components/materialize/sass/components/_color.scss";

@import "variables";
@import "colors";

@import "{poetic:materialize-scss}/bower_components/materialize/sass/materialize.scss";

// Bem imports here:
// This is just an example, ;)
@import "{}/client/components/Brand/Create/Create";
11

I hear you @sashko, however it assumes that a developer like myself has the time to “write something from scratch”. In reality I’m going to want to start with something that looks ok, and then modify it as I need to.

This is why I’d rather copy some .scss files, and then modify them.

12

My biggest pain is file separation. I have my html and js files close but styles are in another universe.

1 Like
13

Why not put your CSS next to your JS and HTML files?

3 Likes
14

If you use CSS, you can just put the CSS file right next to your JS and HTML files and Meteor will automatically load it in.

If you are using SCSS, you can do the same thing unless you want to import other files, in which case I recommend putting your scss file next to your JS and HTML, but prefix the name with an underscore and import it from a common main.scss file like so: @import "{}/client/components/Brand/Create/Create";

15

You think that’s nasty? What do you call this: https://github.com/Semantic-Org/Semantic-UI/blob/master/dist/semantic.css

Beautiful? I guess you love poring over a CSS file 35,000 lines long? :wink:

1 Like
16

I’m using sass, so lots of imports, variables, etc, depend on file structure, and the load order is very important too. Would be great if there were a sass package that let you import as if everything is in the same folder.

17

Nothing nasty about it. Material-UI uses this pattern. And I use it now in my React apps. But again, the key is to balance it out, and use it properly in the right scenarios. It can’t be overused. There are times when it makes more sense to use Sass of course.

1 Like
18

BTW I certainly don’t mean to talk like I’ve been doing this for ages. :wink: Some folks on the forum recently educated me as to the whole inline style thing.

1 Like
19

What I do (hasn’t changed much for 2 years):

  • Use a UI framework as base. Currently I use Semantic UI.
  • Use BEM for own styling
  • Use a preprocessor (Less, SCSS) for some useful features, like variables.
  • Each UI component has its own stylesheet
2 Likes
20

CSS has always been way more complex than most people realize. Traces its roots back to TeX/LaTeX and Knuth, by way of fonts and typesetting. And anybody who has ever looked at the innards of a typesetting system will know that the algorithms used to implement word-wrap and font-antialiasing are as sophisticated and complex as any other algorithm in the rest of the web stack. There’s a strong case to be made that CSS is the ‘View’ layer of MVC, since it’s the tech that handles viewport size, media types, opacity, colorspace, and other opthamology aspects of beaming data into a person’s eye sockets.

Anyhow, a few comments for surviving CSS:

  • use a post-processor that supports nested CSS classes, which allows you to confine your CSS rules to a component. Prevents styles leaking out to the rest of your app. Otherwise, LESS, SASS, SCSS are all mostly the same.
  • keeping CSS files next to HTML/JS is the easiest way to manage large apps, just so long as the rules are scoped to the local component
  • use inline styles (with Blaze/React helpers) for layout and animation effects; they will be GPU optimized if they’re not attached to CSS classes, since the browser won’t have to parse the render tree and do lookups on class names
  • JSS and Style objects are useful for organizing and managing inline styles and animation effect
  • best one-liner in the entire Atmosphere package server is rahul:animate-everything
  • mixins are brittle and slow you down when you have large apps
10 Likes