For a long time, JavaScript has been my go-to language. Of course, in the browser, but on the server too. When I started with JavaScript I spent a lot of time finding ways to reduce “callback hell”, but eventually I just gave in: code generators and systems that require a patched JavaScript engine are just not the way forward — they’re not “native” JavaScript solutions. So, for years I wrote callbacks like everybody else until I they became part of my muscle memory.

Events are an integral part of Javascript programming. No matter if you use Javascript in the browser or on the server with node.js, you will be listening to, and perhaps trigger numerous events. Yesterday I talked about Twitter’s Flight, which, I argued, might be pushing events too far. Nevertheless, the fact that something can be pushed too far, does not mean it should avoided altogether. Events are still a good solution to many problems.

Ever wanted to take a peek under the hood of v8, Google’s Javascript virtual machine, without having to check out the code and poke around? Here is a nice post that gives a look at what’s going on behind the scenes: The quick-and-simple compiler is known internally as the “full-codegen” compiler. It takes as its input the abstract syntax tree (AST) of a function, walks over the nodes in the AST, and emits calls to a macroassembler directly.

280 North (bought by Motorolla) is the company behind the impressive 280 slides web-based presentation application (a la Keynote) and the framework it was built on: Cappuccino. Cappuccino is an oddball compared to other Javascript frameworks. First of all, it abstracts completely from HTML and CSS, and second of all: it’s not built using regular Javascript but with Objective-J, a strict superset of Javascript that adds support for classes and message sending to Javascript — much like Objective-C adds those features to C.

From the node.js blog: This requires a rather large modification of the core structure, and we’re very happy to have official guidance and engineering resources from Microsoft. Rackspace is also contributing Bert Belder’s time to this undertaking. The result will be an official binary node.exe releases on nodejs.org, which will work on Windows Azure and other Windows versions as far back as Server 2003.node.js has become the de-facto server Javascript implementation.

Starting September 1st I will be employed by Ajax.org, the Amsterdam based company that is developing Cloud 9 IDE — not to be confused with the similarly named Amsterdam-based soccer club. Why an IDE in “the cloud”? During the past decade more and more of the stuff we do every day has moved online: e-mail, word processing, spreadsheets, chat, collaboration tools. The obvious next — almost inevitable — step is to move the IDE (Integrated Development Environment) to the cloud as well.

Yesterday I posted about spaghetti-free Javascript code. A lot of reactions followed. As it turns out, most people misunderstood my point. That’s probably my fault. Here is at again, more concisely: When you write Javascript you have to think ahead: in the code I’m about to write, is there going to be an asynchronous call at some point? If not, I can write Javascript in a nice, synchronous succinct style. If so, in many cases I cannot really use many of the regular language Javascript constructs, such as for-loops, but instead have to use one of the many Javascript libraries that implement asynchronous versions of loops, conditionals, etc.

(If you are familiar with the problems of moving from synchronous to asynchronous programming, feel free to move to the next section.) Update: A lot of people misunderstood the main issue: here is another shot at explaining it better. Let’s build a script that determines the titles of a set of URLs. Let’s start simple, we create a function that takes a URL, and returns the title: var reg = /(.

Javascript comes with a nice method on Array objects called forEach, it takes a function as an argument and applies that function to eacy item in the array sequentially. It’s Javascript’s version of a for-each loop, allowing you to write code like this: for(var i = 0; i < ar.length; i++) { alert(ar[i]); } or, for the performance-obsessed: var len = ar.length; for(var i = 0; i < len; i++) {

I think that it’s well-established by now that the majority of desktop software will move to the browser at some point. It happened to e-mail, calendar, word processing and many more applications already. But here’s a crazy idea: what if we move the server to the browser as well? The past week I’ve been playing with socket.io in mobl, my language for developing mobile web apps. Socket.io is a library that greatly simplifies building real-time web applications — applications that keep a connection (a socket) open to the server, allowing the server to push content to the client and vice versa.

A while ago I released persistence.js, a light-weight ORM for Javascript. It was built to use the HTML5 SQLite database that modern browser implement. I use it as part of mobl, but others have also started to use it for their own projects, e.g. on Palm Pre and Nokia’s QML. I spent some time adding a nice new feature: full-text search. Enabling it simple, just include both persistence.js and persistence.search.js in your HTML page:

Hello, and welcome to the second part of “Javascript: The Scope Pitfall”. Let’s get started, shall we? What does the following code print? var n = 0; function add() { var m = n + 1; print(m); } add(); That was easy, right? The answer, of course is 1, because 0 + 1 == 1. Alright, a slight variation on the same example: var n = 0; function add2() { var n = n + 1; print(n); } add2(); What does this print?

When you build a code generator you have two basic options: Generate code to be read, complemented and possibly modified by humans Generate code purely as a convenient intermediate step toward bytecode/machine code compilation The first approach seems to be the most common. It is the most pragmatic option. “Hey, I keep writing the same code over and over, can’t I simply generate part of it and make minor adjustments by hand?

Somewhere at the end of the eighties, my dad started work at his local university where he became the WordPerfect expert, which was the dominant word processor at the time. Beside acting as a helpdesk and laying out documents, he also spent a lot of time writing WordPerfect macros. WP’s macro language allowed you to add functionality and automate common tasks. All was well, until Microsoft came along with Microsoft Office.

About 14–15 years ago my uncle took me to the university at which he was studying at the time. He had something to show me. He sat me behind a computer in the computer room and started a program called “Netscape”. He typed in an internet address ending with .au. I saw my first website and it came all the way from the other side of the world. It looked like crap, loaded incredibly slow, but it was cool.

I have been watching parts of Douglas Crockford’s talks on the history and future of Javascript. In his third talk Douglas talks about functions. If you are somewhat familiar with Javascript you know that functions are, somewhat oddly, used to create new objects. The original “intended” way (which Douglas calls the pseudo-classical way) of doing this is as follows: function Person(name, age) { this.name = name; this.age = age; } Person.

Array Boolean Date Error EvalError Function Math Number Object RangeError ReferenceError RegExp String SyntaxError TypeError URIError Recognize that? Yes indeed, it’s the complete list of standard Javascript objects of Javascript 1.5. 16 objects, of which 7 are error objects. Of course, this is just the Javascript language by itself. In practice Javascript executes inside a browser, which gives it access to additional objects like the DOM, and all kinds of fancy HTML5 and non-standard browser-specific features.

For the past few weeks I’ve been programming almost exclusively in Javascript. And to be quite honest it’s not as bad as you may think. In fact, Javascript is quite a nice language, as long as you are aware of its quirks. One quirk that bit me in the ass a few times already is its lack of block scopes. To make the problem clear, let’s look at a code fragment:

While abstraction is a great thing, some abstractions are completely unpredictable. For instance, object-relational mappers are very convenient to get started, but if performance is important these frameworks can get very unpredictable performance characteristics. Let’s take Hibernate as an example. Java does not support properties, instead there’s a convention of using getter and setter methods for this purpose. The general assumption is that calling these methods has little overhead: Person p = em.

The past week or two I have been developing an asynchronous object-relational mapper in Javascript, called persistence.js. Its main use-case, right now, is to simplify the database component of offline-capable web applications, like the mobile web applications that I’m working on. But with some tweaking it should also be usable in server-side applications, like node.js servers. It uses the SQLite database that is available in modern Webkit-based browsers (like Safari 4 and Google Chrome), or the Google Gears datastore that is available in any browser that runs the Google Gears browser extension (like Firefox).

MSDN: Asynchronous programming clearly has performance benefits, as mentioned in the explanation I just quoted. What I have complained about before is the programming model that follows from it. In Javascript this becomes painfully clear. In Javascript you do not have threading (although it’s coming), therefore, anything that is not going to be instantaneous, needs to be executed asynchronously or it will freeze the browser. The typical example of this is Ajax (Asynchronous Javascript and XML, a term that is way too general, when you think of it), but you get the same things when you start interacting with local databases.

Now that we decided on a domain and target platform of our DSL, it is time to explore our target platform. Although I have used HTML, CSS and Javascript for many years, I never looked that seriously into the possibilities of especially CSS and Javascript. To help me with that I’ve been reading a few books: Javascript: The Good Parts, excellent book about Javascript, helping you avoid all that bad parts * jQuery in Action, good book about jQuery

Yesterday I watched this talk by Ryan Dahl about node.js. node.js is a environment, based on Google’s v8 javascript engine, to build high-performance servers using the Javascript language. Here’s a simple hello world HTTP server:  http = require(‘http’); http.createServer(function (req, res) {  res.sendHeader(200,  {‘Content-Type’: ‘text/plain’});  res.sendBody(‘Hello World’);  res.finish(); }).listen(8000);You may ask yourself “why the hell would you use Javascript for server-side programming?” And that’s a valid question.