Posts

Showing posts from December, 2012

Looking back on 2012

2012 has been a very productive JavaScript year for me: I talked at several great conferences: April, Mix-IT , Lyon: “ An overview of JavaScript ” ( video ). I’m glad that people liked it . May, Fluent , San Francisco: “ Improving JavaScript ” ( video ). October, JSConf EU , Berlin: “ JavaScript inheritance: beyond the basics ” ( video ). More speaking engagements of mine are coming up in 2013, follow me on Twitter to be notified. O’Reilly has published “ The Past, Present, and Future of JavaScript ”, as a free mini-ebook (registration required). Articles of mine have been published in the free digital magazine Appliness (“ A closer look at Underscore templates ”, among others) and on the Adobe Developer Connection (“ Categorizing values in JavaScript ”). I’ve become the editor of the free email newsletter JavaScript Weekly . The JavaScript User Group Munich that I

Clearing the Decks

Image
William Michaelian's Work Space William Michaelian’s blog post today on Recently Banned Literature presented a picture of heaven on earth as well as an accounting of the books he has read this year.   He has inspired me to list a few that I have imbibed over the last few weeks of Christmas vacation. Silk Parachute By John McPhee Farrar, Straus and Giroux, 2010 When it was released, critics heralded this book as McPhee’s first to include autobiographical reflection.   Known as The New Yorker writer who could put together thousands of words on oranges or the geology of America, the book does indeed include some memoir-ish writing, and those sections are the most interesting parts.   But McPhee also includes ample material on his favorite subjects.   Here, we get a full and detailed accounting of the origins of those white cliffs at Dover, as well as an exhaustive piece on lacrosse.   I loved his personal insights, but most of them could be gleaned from a Paris Review interview Mc

The problem with blogs

I’m a big fan of blogs. After all, I’m writing one, myself. They are the contemporary version of a specialized newspaper. Regularly having new content is exciting and reading blogs is well supported by various apps, thanks to standardized publication formats such as RSS and Atom . The problem However, there is one aspect of blogs that I don’t like: They lead to an obsession with new content. Some blog authors have made it a rule not to update posts that are older than a few weeks. Seeing the date of creation for posts is great (I wish all web pages provided this meta-data), but there is a risk of dismissing good content, simply because it’s old. Redistributing old posts tends to be frowned upon at collaborative news sites such as Reddit or Hacker News. Furthermore, navigating blogs is often difficult, because there is little structure. If you are lucky, posts are well categorized, but even that falls short of proper instructions on where to start reading. Such instructions are especia

Two ways of clearing an array in JavaScript

Update 2012-12-27: Better example for aliasing in Sect. 1. In a blog post , David Walsh mentions two approaches for emptying (clearing) an array. This blog post explains the pros and cons of both approaches. In order to understand them, we first need to know about aliasing . Background: aliasing Aliasing means that the same piece of mutable data can be accessed from several locations (variables, properties, etc.) in a program. Sometimes aliasing is useful, sometimes it is harmful. In this section we examine an example where its effects are harmful. Take the following object, fruitBasket , a data structure for fruits: var fruitBasket = { _fruits: [ 'Apple', 'Orange' ], getFruits: function () { return this._fruits; } }; Obviously, this is not very good code, but it illustrates a general risk related to aliasing: Letting a reference to an internal data structure escape to the outside. Code that uses fruitBasket might look like

“Skyfall” plot holes

The latest James Bond movie, “Skyfall” was widely liked by critics and audiences. I left the movie a bit unsatisfied. There were also three plot holes that bothered me. All three have easy fixes. [Warning: Spoilers ahead.] The plot holes: Plot hole: Q examines Silva’s laptop, plugs in a network cable and the software on the laptop is able to infect the MI6 network via that cable. Not taking precautions against such an attack is amateurish. Fix: Invent a different way in which the laptop compromises the network, e.g. wirelessly. Plot hole: Going to Skyfall already seemed under-explained. But why didn’t they come a little better prepared – they had ample time to do so. Yes, Kincaid sold the armory, but why not bring a few MI6 gadgets? Fix: Invent an incident that prevents them from going somewhere else and from preparing. Plot hole: Silva sees M and Kincaid because they are using flashlights in the darkness. That is a rookie mistak

Language complexity: C++, Ruby, CoffeeScript and JavaScript

Image
Alex Corban has written an article on C++ Rocks that diagrams the complexity of three programming languages: C++, Ruby and CoffeeScript. Here is the bird’s eye view: One way of paraphrasing “the complexity of a programming language” is “how difficult is it to learn the language until you are productive”. Obviously, measuring complexity in the above manner is interesting, but not the whole picture: Some concepts are more powerful than others. And sometimes adding a new concept decreases the complexity of a language, without making other concepts completely obsolete. As an example, look at ECMAScript 6 classes [1] . They will simplify inheritance, but you still need basic knowledge of constructors. Furthermore, much complexity is contained in software stacks (runtime library, 3rd party libraries, etc.). The complexities of JavaScript and CoffeeScript are not too far apart. After all, the latter is based on the former. That made me think: JavaScript plus quirks is less to learn than many

The future of JavaScript: a CoffeeScript-like workflow

ECMAScript 6 [1] will bring many new features to the language. However, it will be years before we can rely on it being supported in most browsers that are in use. This post examines tools that will allow us to program with ECMAScript 6 much sooner. Evolving a web programming language JavaScript is a web programming language. You will thus always encounter a wide variety of language versions: Applications are written in many different ECMAScript versions. Even a single application is likely to be a mix of several versions, considering that it often includes libraries and external code (e.g. for analytics). Many different browser versions are in use, even quite old ones. In every browser, there is exactly one version of ECMAScript available. Users have little control over which version it is, because browsers often update themselves automatically (making new versions forced upgrades). This imposes constraints on what can be done with ECMAScript 6: First, this version ca