Getting Started with Myth: the Preprocessor of the Future

I moved a post to an existing topic: Welcome to The New SitePoint Forums

I wrote an article that discusses what I believe to be the best CSS preprocessors (which includes Myth and Stylus). That article might shed some light about the advantages and disadvantages between using one or the other.

1 Like

That is a valid concern! Thank you for mentioning this point. This is something anyone thinking about using Myth should keep in mind.

There’s always the possibility that the specs will change between now to final rec.

In production, since we’re deploying stylesheets that use final rec CSS specs, there’s no issue at all, the site will be unaffected with any sudden spec change.

But it is definitely a maintainability concern though: We need think about the steps we will take if the proposed specs change significantly between our initial development and a development-iteration/redesign/feature launch we are working on.

For example, what will we do if the CSS variable syntax is changed in a couple of years and we’re going back to update one of the sites we built with Myth? Will we update our input/development stylesheets to whatever the newest specs are? Or will we just stick to a backwards-compatible release of Myth and just develop with the “original” proposed specs we used during initial development?

1 Like

I strongly disagree, a preprocessor does so much more. It’s not just about changing a color value. Some examples:

  • loops help you to avoid repetitive code (i.e. if you have different areas on your site, each one in a different color/style) and make changes much easier (than being forced to replace the values multiple times)
  • true, it’s quite unlikely that you’ve used the same color for different things, but what about measures of length? As soon as you’ve got numbers, search and replace will be much harder as the same ones are used in different contexts. Furthermore search and replace will fail if different color syntax’s (#hex, rgb, rgba) are used.
  • nesting of selectors saves time (no need to repeat the long selector list all the time) and provides much better readability
  • You intrinsically avoid “magic numbers”. If you need to calculate a value, you don’t write the result, but the expression. e.g. instead of writing “12.66667em” you write something like “$parent-width - $margin-left - $margin-right”, which is some sort of documentation out of the box

When porting a huge project to SASS (design/structure remained very similar), the new sass-project had ~2.800 lines, whereas the old CSS-Project had ~12.000 lines. Of course there were some other optimizations as well, but about 60-80% of the savings was due to SASS (loops, no need for prefixes, nesting)

Have you used any Preprocessor ever intensively in a real project? I would never want to switch back again (unfortunately I’m from time to time forced to use plain old CSS again in legacy projects…and it’s a pain)!

1 Like

I work on a ~9000 page website where SASS is used, so yes I think this project is big enough.

I have used preprocessors before.

I’ve never refuted any of your benefits that you are listing so I’m not sure why you feel the need ot remind me of them.

It seems that a straight-forward find/replace using a regular expression would do the job well there.

Find: border:(.)#30353b(.)
Replace: border:\1#30353f\2

Hm, can you do that in a text editor? Will have to try it.

Not in a simple editor like Notepad, but Notepad++ has the feature

OK, you can search in Sublime via regular expressions, too, but I’m darned if I know how to write them. Probably easier just to search the file manually!

Sacrilege!
You can use tools such as regexr to help you compose them, or just ask in the forums.
They’re not difficult once you get the hang of them and save a ton of manual labour!

I don’t know if there’s a better reason to start learning about regular expressions than this one :slight_smile:

Here’s something that could help: Sublime Text 2: Find and Replace with Regular Expressions for Idiots

1 Like

Or css preprocessors… :smiley:

1 Like

whenever a new tool appears ,people start shifting to it just because ,as a long standing web developer i learned to stick to tools that have a long support and community ,as long as it works why would i need to reprogram my mind to use a new tool that’s going to give me the same result as my current one.

1 Like

Sorry, I didn’t intend to offense you. I just wanted to know why you think CSS Preprocessors are so bad, but as you seem to acknowledge the advantages of them, I probably just misunderstood your posts :slight_smile:

No offense taken! I was simply pointing out my opinion. Likewise, I hope I didn’t offend you. It’s hard for people to read tones on the Internet so it’s easy to be insulted :slight_smile: . Nothing I said was meant to have any offense to it.

I don’t think they are bad per say, I just find them unnecessary.

We’ve gone years and years without the need for them, now people treat it like it’s a limb attached to their body.

Guys, you should take a look to cssnext.

Why ?

  • more features
  • less bugs
  • a lot faster
  • better error & warning.

Note: upgrading from myth to cssnext should not bring any issue.

I have to agree wholeheartedly with this. SASS gives you access to loops and true logical computations (if/else etc). I’ve found these to be invaluable in creating things like on-demand grids which as far as I can see just wouldn’t be possible with this.

I believe that computational logic such as calculation of dimensions based on variables is slated for future inclusion, but SASS gives me that capability now and without the need to worry about whether the syntax is going to change suddenly in a month.

As far as the arguments against having to learn a “new language”… I would argue that anyone working on any remotely enterprise-scale websites or webapps would probably already have at least some exposure to preprocessors - There’s just too much time saved by using them for dev teams working on projects of that kind of scale to ignore. They not only make the initial code faster to write, but increase maintainability as well.

1 Like

Ugh Yuk!!! That’s the proposed variable syntax for css?! Ugh nooo! That’s awful…

They’re big reason for not bringing in variables before was it would make it more complicated so instead they bring in the most convoluted syntax unlike any other programming languages syntax. So if someone learns variables through css frst (which is likely) they’ll need to unlearn it when moving to javascript or php or something else.

That’s a travesty! It could have just been something like:

–text_color: #fff;

.color {
color: --text_color;
}

1 Like

Ugh Yuk!!! That’s the proposed variable syntax for css?! Ugh nooo! That’s awful…

I also don’t like the proposed syntax for CSS variables. I prefer the syntax in Sass and Less.

However, there’s big value in the concept of CSS variables. CSS variables is one of the reasons why I believe preprocessors have become popular. I might not agree with W3C’s proposed syntax, but I want CSS variables.

1 Like

I’ve been looking forward to them for a long time, but sometimes I do wonder if they will be as much of a pain as not having them. If lots of elements use a variable, and then you want to change some of them—potentially over and over—it seems it would be as much of a pain to sift through the CSS file to change variable names as it would be to change styles declared inline in the first place.