A blog post titled Things To Avoid When Writing CSS caught our attention a few days ago. We appreciate the author’s point of view, but we just couldn’t bring ourselves to agree on all the points raised.

We thought it would be useful if we shared our experience and views on how to write efficient and maintainable CSS.

A CSS file is an ordered set of rules, so when writing CSS, a developer should always pay attention to the order of the rules.

Even a small project can rely on a CSS file that can grow quite large. As the project grows, the CSS file becomes bigger and bigger. Eventually, keeping track of all those rules becomes hard, and even a small change becomes fertile ground for your baldness.

While writing HTML or JavaScript, you organize it in multiple files. You should follow the same principle while writing CSS. It’s easier to find related information as it is grouped in separate files. Also, when a versioning system is used, more people are able to work on the project with less merge conflicts.

As for the specificity argument, if a rule depends on another rule, both of them need to be in the same file. In that way, it’s easy for you to manage that dependency.

You should always be aware that your files will generate one big CSS file and that, in some cases, the order of CSS files is crucial.

As a rule of thumb, we try to keep our SASS files under 200 lines of code with optimal length of around 100 lines per file. Also, complicated blocks that have over 50 lines of code should go into separate files.

From our experience, the modularization of CSS pays off even in cases when a single developer works on the project. Furthermore, the benefits of modularization increase with more developers working together.

Summary: Split your CSS code into different files and then use one main file to manage the loading order. Be wary of specificity as you would be if it was all in one file. Keep individual files under 200 LOC.

Nesting improves code readability and eliminates duplication. Most problems with nesting come from not understanding what the generated CSS will look like.

That being said, there’s no good excuse for not using it. Someone who writes SASS code with obnoxiously deep nesting would probably also write lousy non-nested CSS. For them, nesting is just another tool to shoot themselves in the foot.

We use BEM methodology and keep our nesting no more than three levels deep. There are some exceptions where we use four levels of nesting. This keeps our generated CSS code relatively flat.

Summary: Nesting in SASS is NOT inherently a bad thing and you should use it. However, in general, it should be no more than three levels deep.

Using measurement units other than pixels is great, but you just can’t use them for some designs. There is a reason why it’s called pixel perfect. A designer has a vision of what the design should look like. By using pixel measurements, a developer has full control over the sizes, which is sometimes necessary.

This doesn’t mean that you shouldn’t use relative measurement units (em, rem, %, etc.). They are useful and powerful for elements that change depending on the screen size.

Summary: Using relative units of measurement is great, but they aren’t applicable to every metric in your CSS.

This is actually the part of the article we agree on the most. There are many different devices with different screen sizes and, of course, you won’t have breakpoints for every single one of them.

Summary: Determine the number of breakpoints based on the design. A few breakpoints are usually enough.

CSS is not a programming language (rather a stylesheet language), but there are a lot of good programming practices from other languages we can learn from and apply them to CSS.

Also, there are plenty of tools today that help us write cleaner CSS with less “I want to kill myself” moments. By using these modern techniques/rules/guides/tools, our CSS becomes cleaner, maintainable and easier to work with.

The key is understanding what is going on with your code, how the language works behind the scenes, and what your code will generate. After that, situations like Peter’s will be less frequent.

So you heard that JavaScript is the best programming language and you’ve decided to become a JavaScript Warrior? LearnQuery will launch you on a wild adventure where you will learn how to use JS swords. Swords? Yeah, swords! You’ll find them, believe me. It’s an adventure after all.

Maybe you’ve wanted to learn JavaScript but have only had bad experiences with simple tutorials that you complete without putting much thought into and that don’t end up teaching you anything except syntax? If this is the case – you’re in the right place.

The story is this – we wanted to train new JavaScript developers in the best possible manner. We wanted a standard learning path to learn quality JavaScript development. We looked around, couldn’t find a solution for our problem – and so decided to scratch our own itch and create one ourselves.

If you’re a web developer, chances are you’re familiar with jQuery. Most developers know how to use the popular library, but a very small fraction of them know how jQuery really works internally. This was our starting point – to teach JavaScript and jQuery at the same time. And so, learnQuery was born.

LearnQuery is an open source learning exercise that teaches developers the basics of JavaScript by building their own jQuery clone.

It was developed with the main objective of imparting a strong JavaScript foundation that allows simple and fast mastering of complicated JavaScript concepts. The final product is your own jQuery clone, with a subset of functionality that the actual jQuery has. The main purpose of completing this exercise is that afterwards you’ll have a pretty good impression of how jQuery works under the hood.

In order to successfully solve learnQuery, a student is expected to have a basic knowledge of programming.

LearnQuery is divided into a number of tasks and gradually introduces core JavaScript concepts. The tasks become more challenging as one progresses and by passing through them a student is forced to constantly acquire new knowledge that builds on what was learned in previous tasks.

Each task has its own folder with the following structure:

The src folder contains a .js file in which a student must write a function to perform the requested task.

The spec folder contains a .js file which applies specs to the written function. Students are encouraged to write several specs on their own.

The specs are written using the Jasmine framework for testing JavaScript code.

LearnQuery contains the following tasks:

One example task of medium difficulty is provided, and has already been solved. This task introduces basic JavaScript concepts that are applied in subsequent tasks.

Tasks are described with very little or no text at all (just a function definition). Student’s functions must behave just like corresponding jQuery functions.

The goal is to encourage students to do research on their own. Additionally, a student can review the given specs, and from the test descriptions they should be able to deduce how a function should behave.
Jasmine syntax is obvious, so it’s easy to learn and specs are easy to read. For example:

Writing your own specs is an important task because it encourages you to think about the corner cases.
By writing specs, a student discovers his bugs and gets familiar with debugging (the best way to learn is from your mistakes).

LearnQuery can be solved without a help of a mentor, but internally, we assign a mentor to each student. A student writes his own specs which allows him to experience the full learnQuery potential. In the other words, a mentor is not necessary, but it’s recommended.

A mentor is a person who advises a student, teaches him good programming practices, and reviews his code. After a code review, a mentor will point out the flaws and/or propose a better solution.

A mentor covers the things that can’t be tested automatically, like, for example, code quality. Additionally, a mentor’s feedback will provide a student with valuable information that will help a student to progress rapidly from task to task.

Solving learnQuery will probably induce emotional highs and lows. You might require an entire day to solve a very simple task. This is not wasted time, however, because it will help you gain very valuable experience.

Please do not give up!!!

We believe that in the end you will definitely feel the effort is worth it. Solving LearnQuery will probably take a beginner student about two weeks.

LearnQuery is an open source project and is available on GitHub.