It’s happening Ever since Swift was open sourced by Apple including a release for Linux, people speculated about why Apple would do this. The most popular theory was that Apple itself wanted to use Swift on the server. And these days, even for Apple — server equals Linux — hence the Linux release. As far as we know, much of Apple’s server infrastructure (at least the stores) is build on WebObjects — a technology that is showing its age (to put it mildly).

Today, TJ Holowaychuk, one of node.js’ most prolific module writers (express, jade, mocha, koa) has announced he’s leaving node.js for Go: And PopTip: It’s not just node.js users making the switch. Others are too. One of Python’s most visible users, Dropbox — who also employs Python’s creator Guido van Rossum — recently announced it has migrated major parts of its back-end infrastructure from Python to Go: And, less surprisingly, Google is also switching projects over:

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.

Twitter open sourced Flight: “a lightweight, component-based JavaScript framework from Twitter”. Its killer feature: develop components that are loosely coupled, through the power of events. Cool, right? We all love events. Events are a powerful idea. They give you a nice way to decouple, and a great way to support extensibility in your software, by letting developers hook in and respond when certain events occur. A good example is the browser’s DOM, which defines many events on HTML elements: onclick, onmouseover etc.

A few days ago I talked about Dart and Javascript and the features of Dart that the web desperately needs. I did not say much about Dart as a language, or whether I believe Dart is going to make it or not. I’d like to elaborate a bit on that now. I would like Dart to succeed, let me start with give a few reasons why. First and foremost are the reasons I mentioned previously: Dart provides a few vital features that the web needs:

Remember Dart — that language that Google is developing to replace Javascript? Frankly, I haven’t given it much thought the past year. When I heard it being pitched as a “web scripting language that we can make run really fast” about a year ago by Lars Bak, I kind of dismissed it. I don’t find the ability to execute programs in a language very quickly a particularly important property of a programming language, nor do I believe that VM implementers make for very good language designers.

Live programming is the idea of getting immediate feedback while you’re writing your code, allowing you to get an early idea of what you program will be doing and how it works, or even to see what its potential problems are. I first became aware of this idea by watching a video from Bret Victor, entitled “Inventing on Principle”. If you haven’t seen it, definitely worth a look. Later, other projects based on these ideas came along.

In Pick Your Battles I listed a few problems that we had in our production deployment of a big node.js codebase. Some people asked me to elaborate on one in particular: So, why did this happen? The short answer is our code blocked the node.js eventloop from time to time. As you may be aware, node.js — like Javascript in the browser — is a single-threaded, event loop driven environment: only one thing can happen at a time.

When you run a big mission critical web app, you have to two big challenges on the operational side: 1. Handling _failure_ — failure is all around: servers fail, processes crash, datacenters blow up. 2. _Scaling_ as traffic increases and decreases. A tool in use by practically everybody to solve both of these challenges are load balancers. Here’s how most of them work: In this architecture, the load balancer is the single entry point for the client (often a web browser).