R.I.P. REM, Viva CSS Reference Pixel!

The web is full of resources telling you to use the relative lengths “em” and “rem” over pixel, because they would make your design more accessible. Almost all Front-End Developers I know (including myself) were blindly following these instructions for years and it became a de facto standard in the industry. I’ve done some research lately that completely changed my mind about these two relative units. I won’t use “rem” going forward and only use “em” in very specific use-cases. In this article I’m going to share my observations and hopefully convince you to put an end to our beloved “rem” unit, that finally made it into our tools without fall backs (given IE8 dying slowly), but became totally useless in favour of the more popular CSS reference pixel.

Getting the best out of BEM with Sass

Let me be completely honest with you here. When I first read about BEM not so long ago I completely dismissed it and I didn’t like anything about it. Well, the only thing that appealed to me was the fact that people would start to think more holistically and component based. But why use BEM for this? Why do I need to write classes like .header__link--huge? At first, I really didn’t like the idea to name my selectors with bulky class names that consist of prefixes and weird character sequences. But once again my mind got shifted.

Functional Style Mind Shift in JavaScript

In my job as a front-end developer and consultant I speak to other developers a lot about how to write code. Let’s be honest, actually there is no holy grail of how to write code. There are different opinions and just many factors like stability, re-usability, maintainability, code scannability (which is also very subjective), performance, testability, beautifulness (Admit it! Sometimes you just prefer sexy beautiful code over efficient code!) and probably many many more. However, I strongly believe, that a few of these factors are more important than others depending on the context. While talking to developers and performing JavaScript code reviews at clients, I always figured out that people who adopted to a more functional style of writing JavaScript, created much more readable, maintainable and efficient code.

In this article I would like to show you a few examples how ECMAScript 5.1 changed the way I write code and how I learned to prefer, readable, maintainable and functional code over the lame old-school procedural (but sometimes more performant) code.

The new Object.observe() and some pitfalls

There is more Harmony inside of Chrome, since they release Chrome 36 stable a few days ago. Object.observe, a specification to observe property changes in Objects and Arrays, is awaiting final approval by the ECMA TC39 guys and there are already tons of blog posts about how to use the new functionality.
A lot of people are very excited about this new API and there are also statements flying around that this will make two-way data binding frameworks unnecessary. I was playing around a bit with Object.observe which was promoted by many as the new holy grail of client-side MVC frameworks and I’ve found a few pitfalls that I’d like to point out here.

Angular’s $parse for intelligent product suggestions

I’ve recently spent some time working on a prototype for a client who wanted us to implement some intelligence in a product suggestion process. For this purpose I was thinking of something I know from game development. As soon as it comes to AI (artificial intelligence) stuff you’re happy if you’ve implemented a DSL (domain specific language) into your game already. This then allows you to solve the AI problems with little DSL scripts that you can modify for each enemy. You can port your internal events like collisions, way point triggers and environmental changes into your DSL and build scripts that get used as strategies for your enemies to deal with them. A smarter enemy may also gets a smarter script.