High Performance CSS code design

In the last few years much emphasis has been placed on web performance issues. Browser vendors have optimized JavaScript engines, JavaScript libraries have been honed, and content delivery has been improved. Unfortunately, CSS has received less attention. Developers have been advised how to optimally transfer CSS files, and instructed to use CSS shorthand, but very little has targeted CSS code itself.

Ms. Nicole Sullivan is among those looking to improve CSS code. She has been promoting “OOCSS,” or “Object Oriented CSS,” her methodology for how to design and refactor CSS 1. She has collected a number of best practices for architecting a CSS framework. The benefits are simple: CSS will perform better, become more modular, as well as being grounded with a consistent API, making it easier to learn and use. This is accomplished by reducing the file size and complexity of our CSS.

While many of these techniques can be considered common practice for experienced CSS programmers, implementing them can be difficult. The art is in analyzing trade-offs and picking the optimal path. That said, these rules are not for everyone, or every site. It all boils down to deciding if the site’s performance gain is greater than the time it takes to learn and use the techniques.

Useful for sites with

• Many pages
• A common visual and structural design
• Critical performance requirements

Less useful for sites with

• A few pages or just one page
• Varying design (possibly “portfolio” or design sites)
• Few performance concerns

So how do we get started? We go hunting for bad code smells. In Chapter 3 of Refactoring: Improving the Design of Existing Code, Martin Fowler and Kent Beck coin the phrase “code smell,” meaning “structures in the code that suggest the possibility of refactoring.” Simply put, we go looking for chunks of code that our intuition tells us could be cleaned. In the chapter heading, Grandma Beck is quoted (then talking about child-rearing), “If it stinks, change it.” We’ll take a more formal approach to finding these code smells, going from easy to difficult. First, we’ll sniff around the CSS selectors, and then move onto the CSS properties. Finally we’ll look for visual design patterns that can direct the structure of our CSS.

Selectors

Selectors are both the easiest place to find code smells in CSS and the easiest to correct. Three big code smells tend to stink up CSS selectors; unused selectors, location-based selectors, and overly specific selectors. Each contributes significantly to increased CSS file size.

Cutting Scheme in Half

The Scheme steering committee has decided to sever the Scheme language into “Large Scheme” and “Small Scheme.” Can we expect the same from Scheme-inspired languages like JavaScript? 🙂

Review of "Expert Python Programming"

Based on the title, Expert Python Programming, (by Tarek Ziadé) I had expected a book covering the Python language… syntax, advanced data structures, maybe some functional programming… stuff like that. This book surprised me. Rather, it contains a hodgepodge of information about the world of Python development, from setting up editors to distributed version control to application distribution. “Expert Python Programming” does contain some information on the Python language itself, but not as much as I would have hoped. While it does contain a good amount of useful information, overall, I’d have to say that it misses the target.

Quickly summarized, the book contains 3 chapters on package management and distribution, 2 on syntax, 2 on optimization, and one each on language setup, naming conventions (style guide), version control, project management, documentation, test-driven development, and design patterns. Based on the content, I might have titled this book “Expert Python Development Practices”, and think I would have been happier reading it in that case. The discrepancy between the title and the content is especially bothersome to me, since it would be easy to assume this book focused specifically on programming, rather than code management.

Expert Python Programming’s greatest asset is the number of tools and utilities that it covers. As a mostly casual Python programmer, there were a number of things that I learned, especially with regard to package management and distribution. I’ve never needed to build a package, and never used Atomisator or zc.buildout before, so I found these chapters rather interesting (though not personally useful at the moment). To be sure, when I need to use these, this book will the be the first place I come.

I was familiar with a decent amount of the information in the documentation, test-driven development, and style-guide chapters from reading some of the Python Documentation and a few of the PEPs (Python Enahncement Proposals). These chapters would be good for anyone who doesn’t want to have to go and search for this information on their own, and I think it would be rather handy to have all of this information in one place.

The weakest part of the book were the chapters focusing on Python itself. The majority wasn’t anything particularly groundbreaking here that I haven’t read elsewhere, while the interesting sections, such as “How Python Deals with Memory” and “Multithreading” were short and not particularly detailed. The sections on optimization were nice, but limited.

Review of "Object-Oriented JavaScript"

I recently read Object-Oriented JavaScript, by Stoyan Stefanov. In reviewing it, I found it was one of the most interesting books I’ve read in a while, for some good reasons and a few more curious reasons.

Object-Oriented JavaScript was authored by Mr. Stefanov, who is a developer at Yahoo. It features an impressive number of reviewers (twelve), among them Douglas Crockford, the author of JavaScript: The Good Parts, and Ross Harmes, author of JavaScript Design Patterns, both of whom are Stefanov’s Yahoo co-workers. In a reasonable 330 pages, it features eight chapters on JavaScript’s History, Basic Syntax/Features, Functions, Objects, Prototypes, Inheritance, the DOM, and Patterns/Best Practices.

Readers with little to no JavaScript knowledge will be able to read this book, but I’m uncertain how much they’ll be able to glean from the meaty inner chapters (functions, objects, prototypes, and inheritance). Readers with moderate JavaScript understanding should be able to learn a great deal from this book. At the very least, advanced readers should be reminded of some of the language’s quirkier parts, as well as benefiting from an organized chapter on inheritance techniques.

It is tricky placing Object-Oriented JavaScript in context of the corpus of JavaScript literature. This book includes more than a little introductory material (chapters 1-2), while the core chapters (3-6) are way beyond an introduction. Only after those chapters (which I will discuss in a second) is the reader introduced briefly to the DOM and XHR before a chapter on design patterns and best practices. At a minimum, every chapter is useful and full of hints that are difficult to grep from run-of-the-mill JavaScript books. The book steers clear of the murky world of browser differences unless they’re pertinent to the topic of Object-Oriented JavaScript, which seems perfectly acceptable.

Back to those middle chapters, they are sheer gold. I am going force myself to make time to re-read this book, if not those chapters alone. They present, in a clear and organized fashion, many difficult aspects of the language, including closures, prototype, and 12 different methods for inheritance. In comparison, I believe Harmes’ book isn’t as well organized, and Crockford’s book isn’t as clear. Stefanov doesn’t break much new ground here, but the clarity describing these techniques is quite valuable regardless.

Object-Oriented JavaScript appears occasionally try to be something to everyone. This is kind of disappointing, since I would have loved to have seen any additional discussion or insight the author could have offered in the core chapters. There are tons of introductory JavaScript books, so I don’t know what a book titled Object-Oriented JavaScript gains by including more introduction. This shouldn’t detract from the book’s overall value. All of the chapters are well written and useful. However as a reader gains a better understanding of JavaScript, the introductory chapters will become far less useful, while the other chapters will remain an excellent reference.

Funny thing about bugs…

They just keep popping up.

I just scrolled down my own blog, and saw a post titled “Down to three bugs.” Funny enough, three months later, we’re still trying to push the website out. (Wow, those were some really big bugs!!! Haha, jk…) In fact, I’ve been pressing for the last 2 days, trying to expedite a few last-minute bugs so that QA testing could begin (for about the 18th time, now in snapshot 21). Kinda odd, when QA finds bugs in round 20 that they didn’t find in round 10… despite no code changes in the meantime…

But I’m not going to complain. Programming is still a lot of fun when you’re actually doing it. It ends up being almost therapeutic when you’ve got other stuff going on that you’re trying to ignore. Not only that, but there’s always room to improve. A co-worker came to my desk yesterday and schooled me on how to write code. When you’re young, you’re stupid. He had lots of experience, and was… well, right… most of the time. I was boxed into a corner at some points, but also made a few bad decisions. The good thing is that I always learn from my mistakes, and next time will be much better.

I remember writing 3.5 websites before I really got common code working the way I wanted. It was similar to the way I learned how to write CSS. Excerpting common code so that I would only edit once, vs. editing 6 files just to make one update. It was easy when I was using CSS, SSI’s, or PHP includes to simply import exactly what I needed, but I find it is far more difficult when using XSLT’s. Why? Because in XSLT you need to know not only the structure, but the context. That’s what makes it difficult… writing context dependent generic code is difficult.

[Of course, dirty secret (I know you’re skimming at this point, not really reading) is that I’m almost on only my 2 year anniversary (Sept. 20) of doing programming/development work. So my progress is still quite good.]

Alright, I admit that this post was far more stream-of-conciousness than actual post, but it was good for me. It wasn’t intended to be a “I haven’t written in a month, here’s what I’ve been doing” post, but more a “I’m busy, I’ll be back soon, but I don’t know when” type post. So on that note…