Web Technology Blog by Gion Kunz

Menu

Tag Archives: Javascript

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.

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.

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.

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.