Crockford on Javascript

A couple of years ago I read a book – “Javascript: The Good Parts” – which changed my mind about a language that I’d struggled with back in the nineties. I realise now that much of my struggle then was with the DOM and horrible browser incompatibility. Nevertheless the scarring was bad enough to keep me on the server side for the next decade.

I recently found a series of videos featuring Doug Crockford expounding on Javascript and its place in history. This series provides an interesting and entertaining perspective on computers and languages beyond just what runs in the browser.

The whole lot is a bit of a marathon but you can sample some of the main themes in a couple of episodes. I especially recommend episodes 1 and 4.  Episode 6 stands well on its own as a compressed version of the whole series. Episodes 2 and 3 are very specific to Javascript the language if that’s what you’re after.

I like episode 1 because it has nothing whatsoever to do with Javascript but is an interesting tour through the history of computing, describing how we got to the languages and architectures that we work with today. This is essential context for any working programmers today. If you view only one episode, I recommend this one. The historical perspective is reduxed in Episode IV where Ajax is discussed in the context of HTML and its origins.

The important take away from these two talks is how the history of computing is anything but linear and deterministic. We got to the place we are via  a series of steps, mis-steps, loops, accidents and fashions. And the random-walk continues. Crockford says:

“…important new innovations are received with contempt & horror and are accepted very slowly – if ever.

Often it is necessary for the previous generation of technologists to “die off” before major progress is made – especially in programming languages.

A key problem is that it usually requires many years of hindsight to determine which innovations really are useful and innovative.

Privacy, Censorship and the new Oligarchs

I’m crotchety enough to have used the world wide web in the early nineties and before that, Usenet in the eighties. Back then the internet was a wild west where anarchy was viewed as a benefit. Openness and “freedom” – however you defined it – was ruthlessly defended, often to lunatic proportions. Back then the press blamed everything bad on the internet and privacy was a big issue. We seem to have come a long way from that world, but still the press blames everything bad on the internet and privacy is still a big issue.

Even bigger in the last few weeks with the furore over Facebook’s antics and Google’s drive-by privacy violations. A couple of good commentaries on this have been the Background Briefing report on the “Privacy Paradox” and Nicolas Carr’s observations on Facebook’s identity lock-in.

It is not surprising that the anarchy of the early web led to the building of “walled gardens” as a form of protection (this was AOL’s first web business model). It’s perhaps also not surprising that some of those walled gardens have become fortresses where the new Oligarchs exploit their netizens as “bonded labour”. Meet the new Oligarchs:

  • Steve Jobs rules fortress AppStore. He is chief censor and code reviewer and wants to protect our iP* user experience. All for our own good.
  • Sergei and Larry rule fortress Google. They have the largest correlation engine on the planet. They “[W]on’t be Evil” but we must trust that they know where lies the boundary. Google only wants to improve our search experience. All for our own good.
  • Mark Zuckerberg rules fortress Facebook. He generally only opens his mouth to change feet, but lately says he wants to unburden us of all this privacy nonsense. Privacy is just so 20th century. All for our own good.
  • Stephen Conroy wants to rule fortress Australia. Protecting us all from internet nasties by throwing a big censorship net around the country – just like China and Pakistan. All for our own good.

The problem with these new Oligarchs is that they purport to have our best interests at heart, but there is no openness or recourse, no rationale as to how they will separate our interests from their own. Google is too protective of their information assets and conveniently forgets to tell us about much of what they gather. Facebook views our private data too much as their own property to be onsold to others without our knowledge. AppStore acceptance or rejection appears arbitrary and fickle. As for the Net Filter, Conroy claims that a democratically elected government is more trustworthy than Facebook & Google – but there is nothing so undemocratic as a secret blacklist.

The new Oligarchs have built their fortresses on the architecture of the internet. Capitalising on Metcalfe’s law to build unbelievably valuable networks. But Metcalfe’s law also applies to our personal information. The value of any one piece of data about us is proportional to the square of all the other pieces of information they can correlate it with.

Is it all bad? Not really, the lesson of the web is that networks can provide powerful advantages. The Google search engine is testament to the power of massive collaborative filtering. Social networks such as Facebook have opened up wonderful social landscapes. The iP* AppStore has revolutionised the way we go mobile. To some extent this is also what was bought-into when we smothered all internet business models that involved payment. Web users want everything free but data centres, unlike clouds, don’t build themselves. The only currency we have allowed on the Web is that which can be obtained covertly. The real danger arises when power becomes so concentrated and subject to the whims of a few individuals. This is the lesson in the architecture of the underlying packet-switched internet.

From the old anarchic internet to the new oligarchic internet – everything and nothing has changed. Perhaps we should feel a lot less safe now when such people have our own interests so much at heart.

Push versus Pull

From OSCON via O’Reilly Radar here’s a good case study of an architectural decision driven by the system requirements rather than the usual religious considerations that pollute the bloggosphere.

FriendFeed needed update info from Flikr but a REST-based “pull” approach is highly inefficient in this case. Instead the solution architects opted for a “push” approach using xmpp as the message transport. This is a really good presentation because it goes into the architectural choices and implications of “push” versus “pull”.

I characterize this as “pull vs push” rather than “REST vs xmpp” (or “REST vs *” or “why REST is crap”) because fundamentally it comes down to the best choice of how to synchronize changes between systems. You make this choice based on the usage characteristics of the different systems, the likely traffic volumes this will result in and the consequential resource impacts. Having made the choice between push or pull you then choose the appropriate message transport.

The web doesn’t do a lot of “push” and consequently there is not a lot of discussion about push and REST. Dare Obasanjo characterises it nicely:

Polling is a good idea for RSS/Atom for a few reasons

  • there are a thousands to hundreds of thousands clients that might be interested in a resource so the server keeping track of subscriptions is prohibitively expensive
  • a lot of these end points aren’t persistently connected (i.e. your desktop RSS reader isn’t always running)
  • RSS/Atom publishing is as simple as plopping a file in the right directory and letting IIS or Apache work its magic

The situation between FriendFeed and Flickr is almost the exact opposite. Instead of thousands of clients interested in document, we have one subscriber interested in thousands of documents. Both end points are always on or are at least expected to be. The cost of developing a publish-subscribe model is one that both sides can afford.

Inside the firewall, the situation is often more akin to that between FriendFeed and Flikr. This is why messaging is more common inside the firewall than outside – not because of any universal superiority between REST versus messaging, but because the system requirements are different and often favour a push approach rather than pull.

While your over at Dare’s excellent Blog, be sure to also check out his discussion of push versus pull in the context of scaling Twitter and MS Exchange.  These are important considerations for designers of federated systems such as federated databases or federated messaging systems. The example of FriendFeed to Flikr could be considered as the first incremental step toward a federation.