State of CSS in Meteor

help
1

TL;DR If you had to start a project from scratch, what sort of combination of preprocessors, CSS patterns and tools would you use together with Blaze+ViewModel?

My app has outgrown the need for a fast prototyping framework and I’m about to start removing Semantic-UI, element by element.

In a way, I’m starting from fresh with the components and their styles, so I would like advice on the state of CSS currently in Meteor.

It’s been a rough ride so far, with varying support for Stylus, LESS, SASS, improved build tool performance (but not so much if you’re using SASS for example) to having PostCSS (but not all plugins work, ha!) and CSS Modules.

If my project is using Blaze+ViewModel (and that’s not gonna change), what would be my tool kit for awesome, well organized and fast styles with Meteor?

Plz hlp :innocent: :heart:

1 Like
2

Any experience using CSS Modules by @nathantreid ?

Specifically I’d be interested to hear

  • cons compared to plain SASS + BEM?
  • impact on build time compared to vanilla Meteor CSS builds?
  • is it reliable and mature enough to use in a real app with real users?
  • can it be used only on some components, so I could migrate in parts, given that I’m now using juliancwirko:postcss and fourseven:scss ?
2 Likes
3

I’d love to use CSS Modules, but last I checked, it was not trivial to use with Meteor.

Currently I’m using 100% JavaScript styles (no CSS) in combination with Radium.

4

I found this quite interesting: https://github.com/rtsao/styletron

There’s some trade-offs, and I didn’t find anything Meteor-related for utilities for this library, so I would need to start figuring it out from scratch.

5

I’m sticking to old school sass and gulp… Sometimes I think you can over-engineer stuff for little to no benefit.

6

At first glance I thought Vue’s one-file-style with the template, js and template-specific styles in one single place seemed really nice, so I’ve been keen on trying to accomplish something similar. Also, handling all the typical burdens of CSS in a rather large application can be quite…depressing.

Still, in lack of further recommendations or experiences from the community, I chose to stick with what I have now to get “stuff done” (I’m writing component specific CSS with plain old SASS + BEM combo).

Edit:

I’m sticking to old school sass and gulp…

Out of interest, are you actually running Gulp parallel to Meteor’s build process, handling the Sass compilation separately?

7

I can’t speak to much to the first, I’m quite biased and see no cons, but then I never liked BEM. :slight_smile:

It will definitely take longer to build than vanilla CSS since you are compiling SASS and running some PostCSS transforms, but while I haven’t compared it much to vanilla in a large app, I can say that the latest version is pretty quick when compiling changes thanks to caching.

Hopefully others can chime in on the reliability - I’m currently using it in 3 enterprise apps with a few hundred users each, with no issues.

Using it in combination with fourseven:scss gets a bit trickier due to the way Meteor’s build process works. Since 2 plugins can’t handle the same file extension, the easiest way would probably be to use a separate file extension like m.css and have my package only pick up those files (see https://github.com/nathantreid/meteor-css-modules/wiki/Package-Options).

Let me know if I can be of more assistance!

8

Thanks for detailed answers!

About performance, given that I’m currently using juliancwirko:postcss and fourseven:scss:

  1. Pre-meteor 1.4, updating a single file on the client took about 25 seconds to get the browser refreshed
  2. After Meteor 1.4, updating a single file on the client takes about 5 seconds to get the browser refreshed
  3. If I migrate all my styles to use CSS Modules, will my client refresh time be closer to 5 seconds, 25 seconds or something else? :slight_smile:

Are there any other (besides the one you mentioned about SCSS) known issues, bugs or quirks due to Meteor’s build system or other packages that are of type “won’t fix” or need a workaround?

Thanks!

9

I’m with ffxsam on this. I do pretty much everything in JS:

Example({
  styles: {
    label: {
      color: 'red',
      'font-weight': 'bold'
    },
    button: {
      color: 'blue'
    }
  },
  render() {
    <div>
      <label b="style: styles.label" >This is the label</label>
      <button b="style: styles.button" >The Button</button>
    </div>
  }
})
10

I’d expect it to be close to 5 seconds. On my decently fast machine, rebuild times on Meteor 1.4 when changing one of the scss files is <4s. Build times will likely increase if you have a large number of files / npm packages that Meteor has to scan. I know that one of the other users of my package saw their build times drop from 50 seconds to 3 seconds after upgrading to Meteor 1.4 and the latest version of my CSS modules package.

The biggest open issue right now is SSR. It doesn’t appear to be working with the latest Meteor updates, and I have yet to really dig into that.

The most common “gotcha” that I see reported is compilation errors caused by extraneous SCSS files in npm packages.
For example, say you install package foo, but the author didn’t set up the package correctly and included a bunch of test scss files that require a special configuration to compile (or even included some broken scss files so that the tests would fail). Meteor’s build system doesn’t know this - it just sees an SCSS file and sends it over to my CSS modules plugin which of course fails to compile it. The solution here is to the ignorePaths option (see the https://github.com/nathantreid/meteor-css-modules/wiki/Package-Options) to exclude those files from being processed.

1 Like
11

That sounds great. I have no use for SSR, so I think I’ll give it a shot. Thanks for helping me out!

12

I have wanted to try something new - but I just use LESS.
It is easy and fast enough for what I need.

1 Like
13

@arggh
Why are you abandoning Semantic-UI? Our app is now in production and Semantic is working very well. Even on mobile. We have a custom main.css which adds our own styling.

That being said, are you using the official Meteor package for Semantic, which allows you to customize your theme?

1 Like
14

Why are you abandoning Semantic-UI?

I am not using the official package, since it slows down the rebuilds a lot. I have a local custom Meteor package with all the Semantic-UI’s source files, build tools etc. that allows me to customize the build by declaring my own rules, overriding or changing pre-existing variables (the setup instructed in S-UI website). I think it’s the best way to use Semantic-UI if you need to to do changes to it (took almost 10 seconds away from my rebuild times pre-1.4)

I’m abandoning Semantic-UI because:

  • It’s really developed with the focus in desktop use
  • It’s huge in size and it’s hard to pick what you really use. You can pick modules and elements to include in the build, but if I end up using just four types of buttons in my app, I’m still getting all the gazillion different types that Semantic offers, together with their custom versions and combinations.
  • It’s buggy. I’ve spent so much time trying to fix an UI bug, just to find out it’s caused by S-UI.
  • Fixing the bugs takes a lot of time, since it’s this one guy pulling the strings and the library is huge. Even if there is a pull request, it might take 4 months to get it merged.
  • Some of the documentation are just plain false - sometimes I try to use a setting, but it doesn’t work. After reading the S-UI source code for 20 minutes I find out that “oh, that setting is not even used”.
  • it has a lots of surprising side effects. Add a sidebar to your app and suddenly it’s unusable on iOS because of really strange quirks.
  • It’s not respecting the HTML spec (for which I admire the project owner’s courage and vision)
  • It’s time consuming to customize. I found it a real pain to make a minor change in the styles, partly because the library is huge and every variable wraps another variable … it’s a labyrinth you have to solve every time you need to make a tiny miniscule change.
  • It relies heavily on using !important in it’s css rules, which makes it really hard to work with.
  • It’s slow. I have a habit of testing on low end devices (like a 6 years old Windows laptop or Samsung Galaxy S2). For example, building a popup component with Blaze vs. using S-UI, there can be a world of difference in usability. With Semantic-UI it might take 3-6 seconds just to have something happen on the screen, where as with Blaze it’s pretty instant even with lower end devices.
  • It restricts my creativity. I want to have absolute freedom when designing my UI’s.
  • Writing CSS with today’s tools, such as Sass and Autoprefixer, is really fast. I just have a vision and I code it, instead of doing yet-another dive into the selection of S-UI elements, then try to force them to my vision.

The reasons with most impact are emphasized. I think in the end I got fed up using so much time trying to fix Semantic-UI issues or trying to customize the components, when I could just “do it myself” in no time.

It literally takes me the same amount of time to write my own markup and styles for a new component from scratch, that it takes just to pick the right Semantic-UI element and learn it’s “syntax” and API.

Once you know the framework It’s great for prototyping, or if you don’t care about performance, how your app works on mobile or how it looks. I still use it in our project’s admin app, where it’s a perfect fit.

Overall I feel Semantic-UI will be even more popular in the future. I also doubt that the main pain points would be fixed in the near-future, since they would require substantial refactorings in the entire codebase.

1 Like
15

I re-read my post and want to clarify that I’ve been using Semantic-UI for years, initially fell in love with it and think it’s an amazing feat from it’s creator. However, it has now served it’s purpose for me and it’s time to let it go :slight_smile:

1 Like
16

I agree with a lot of your points. adding SUI creator @jlukic to the discussion

1 Like
17

Thanks @arggh,

It is true that it is becoming easier with pre-processors to have solid styles quickly, you do need to know what you are doing though, so not everyone can take that path.

I would like to comment onh a couple of points:

Agreed, but mobile works good regardless, and I feel there is an expectation that you will build your own css overrides for screen sizes.

Agreed, but that’s the same with most frameworks. Deeper customizations will be very expensive somewhere in the development chain, either for developer of the framework (including maintenance) or for us to painstakingly tweak everything.

Agreed, we stopped using sidebars altogether in our app.

Your are talking about six wide mobile two wide desktop kinda-thing? :slight_smile:[quote=“arggh, post:14, topic:33516”]
Some of the documentation are just plain false
[/quote]

Yes! I accepted that as part of using an open source package, there are a LOT of issues on GH. I think @jlukic needs to bring a community on board to help with dev. It might be critical for the future of the framework. Case in point, we use external calendar and range UI elements, which were developed FOR semantic. But could not be merged to the main repo, even though they work great.

18

Thanks for taking the time to outline your thoughts on SUI in a constructive and reasonable way @arggh et. all.

The most important thing I’ve wanted with SUI is not to just create a UI library that people can be used to build websites, but to promote a new way of thinking about writing front end code.

The core tenants being:

  • Begin with a list of tangible physical components which correspond 1:1 with language for describing websites.
  • Use a strict, internally consistent system for defining UI using single english words and fixed system of grammar (types, variations, state, etc)
  • Encapsulate rules using noun/modifier relationships (i.e. “small” has no absolute definition without context. i.e. small ant vs small planet)
  • Provide a tiered theming system so people can style it without modifying the base rules
  • Create behavioral modules built around simple (verb+predicate) relationships for describing an API for functionality (set active, get value etc,)
  • Provide, as best as possible, neutral default values for variables that express the most commonly used case
  • If something is arbitrary in the framework, make it a variable or a setting so that developers can change it
  • Include a system so that developers can extend the library as necessary (overrides)

Generally the thing I want developers most to take away, even if they dont decide the framework is for them, is that there are other ways to think about constructing meaning through physicality, and that it is most effectively modeled around natural language (not the existing vogue in abstraction)

With regards to the specific complaints, which are all real difficult and useful points of conversation.

w/r/t slow pace of dev, lack of community dev

I’ve decided for reasons of internal consistency and voice to generally maintain the direction of the project individually . To me this is like the difference between a novel written by one author vs. a academic paper co-written by multiple scientists. They are both effective strategies to expressing truth, but have trade-offs. I have personally been a fan of the novel approach for SUI because the aspirations of library might be an overreach for this generation of programming, and instead might be most useful as a roadmap for another generation on how this kind of thing, could be done.

w/r/t desktop use

I don’t believe that its the case that SUI is a “desktop use only” framework. I think generally mobile development is a mixture of three things: useful patterns for reducing complexity, (doubling/stackable), decisions about reducing complexity (what part of my app can i cut out for mobile), and correctly swapping out “mobile-first” UI, for example vertical menus from horizontal menus where appropriate.

I think SUI provides good patterns for handling mobile, but doing mobile effectively will require you to think critically about your specific content. I dont think adding classes like show mobile hide mobile etc will solve this issue entirely.

w/r/t gazillion options

I think the next version of SUI will include some strong decisions about separating ‘core UI’ (represented by usage stats, surveys etc) from non-core ui. This might include something like two packs for each component, “basic” (most commonly used styles) and “extended”.

w/r/t restricts creativity

I dont believe there is much time left for creating new salient UI. I do believe there are many new UI patterns which are not encapsulated in SUI, but I dont think a library that describes only some patterns is necessarily restrictive.

w/r/t meteor package

All credit to @flemay for the heroic effort of maintaining the port, but the meteor package is very slow. I use my own custom forked package in prod that uses the LESS only package.

The difficulty is allowing for flexibility in customizing the package while also allowing downstream updates.Its difficult but possible to do this in NPM with post-update hooks, but in meteor with atmosphere its not very viable. I wish I had a better solution here.

I know I’ve been on radio silence for the last year or so, and dev might seem to have slowed down, but this will be the year for important announcements around SUI. This is my core lifetime project so you can count on reliable updates to SUI, albeit with some dead time for life hiccups coming up along the way.

7 Likes
19

This thread went a bit off topic, but it’s nice to hear thoughts from @jlukic regarding Semantic-UI. Thanks for a thorough reply, appreciate it. I think you pretty much listed the reasons why I found SUI so intriguing in the first place few years ago.

Some of the given reasons to abandon SUI don’t have much to do with SUI, but UI frameworks in general, such as restricting creativity: With a framework, the components tend to be my first line of defense when solving a problem. I find myself browsing the API for a “suitable ready-made block” to fill the need. So, in a way it’s not the framework that’s restricting, it’s myself if I have the framework at hand. And the solution for me is to ditch the framework.

Regarding desktop vs. mobile,

I don’t believe that its the case its desktop use only framework

SUI definitely is not desktop use only, but in my experience it’s desktop first. Some of the components don’t play along that well with mobile, or then I lacked the skills to use them properly. Sometimes some SUI-components’s javascript would be doing undocumented DOM manipulations and that sort of sorcery, causing issues specifically on mobile devices. Or I was expecting a “huge padding” to be less huge on mobile, when it ended up eating all my screen space.

At the same time some of the things I really liked about SUI was the grid system, it works really well for mobile design, though I would have personally worked out a way to specify the different widths and alignments without duplicate class names.

For SUI’s future, I think the idea of separating SUI into two different packs would be great. Having a core of well thought and tested defaults that basically have nothing to override but provide easy styling, coupled with the natural language for describing the UI. That would be something. Maybe there already is something like that, but it’s not well known since the results wouldn’t be pretty out of the box or it’s lacking a date picker or some other fancy feature.

I don’t understand why people complain about a missing date picker. I’m more likely to complain for adding too much. That’s probably also why I’m feeling the need to give up on SUI, it’s too big for me to handle elegantly. I find it easier to maintain my own tiny subset of styles - even if some of them will most likely end up being copy-pasted from SUI sources, like the grid :wink:

To finish off, I want to state that I didn’t mean to throw negativity at Semantic-UI, I was merely explaining my motives when asked. I hate it when people find nothing positive to say about the accomplishments of others, and I don’t wish to be regarded as such people :slight_smile:

20

@arggh

As I re-read the post and the different comments, here are some thoughts from a Semantic power user:

Edit: Understood … good constructive criticism is good. I just feel that some concerns are exaggerated. Examples: modals, dropdowns, form validations etc. that need JS back-end. That’s a LOT of work to develop from scratch. It’s not just CSS. Bootstrap doesn’t nearly offer as much.

Back to SUI and @jlukic

I applaud your mission. [quote=“jlukic, post:18, topic:33516”]
The most important thing I’ve wanted with SUI is not to just create a UI library that people can be used to build websites, but to promote a new way of thinking about writing front end code.
[/quote]

Seems a bit grandiose, but granted. Truth is, myself (and likely others) have our noses in the grindstone. We are not looking for great missions, we are just very happy and grateful for SUI.

From a PM perspective, I heard this before: to switch from one-person team to a multi-person team, you need to jump to three people right away, as the drop of productivity, meetings, docs etc. slows things down. So I understand. You are definitely (way) top-notch. Yet, there is obviously a risk for us with a single developer, but … it’s open source. So no complaints there.

On re-building, sure. But if there are no changes. We didn’t feel any delays … am I wrong? Should we use your package instead?

1 Like