To blog or to tweet?

Yesterday Anil Dash wrote a great piece about being on Twitter’s “Suggested User List.” I tweeted it this morning, as did many other people. This afternoon Anil tweeted:

Thanks to all who retweeted my piece about Twitter’s suggested list. (I miss the days when people responded with their own blog posts, tho.)

Yeah, I miss those days too. Twitter (which I will use as shorthand for any short messaging service) makes it very easy to post a quick thought, a status update, or a link to something interesting. Much of blogging used to be like that, but the blog postings used to be longer, with more context. I rarely posted one-line blog entries or simple links, because I felt that a blog entry should have some kind of story — a thread, a narrative — to guide the reader to a particular conclusion or insight. This classical “essay” model of blogging has problems, though:

  • If you are locked into the classical mode, a sense of obligation to write a more elaborate piece can prevent you from writing anything.
  • Not all thoughts, insights, and amusing moments you want to share with your friends (and the rest of the world) warrant more than a brief sentence or two. Explaining an aphorism can ruin the joke.
  • And sometimes all you want to do is point to a link, or stick up a photo. In first-generation blogging tools the overhead of creating an “entry” could be more effort than the mini-message was worth.

Over the last year, I have heard many people say that they blog much less now that Twitter is around. By providing an outlet for people to express themselves quickly and efficiently (albeit in 140-character chunks), it bleeds off a certain amount of creative pressure that would otherwise have led to more and longer blog postings.

I don’t want to make this a lament on the “death of blogging”, because blogging emphatically isn’t dead; otherwise, where would we all find the cool links to tweet about? In fact, good blog articles benefit from Twitter, because it provides a fast and social notification medium in parallel to the existing mechanisms of RSS feeds and reblogging.

Furthermore, “The Tweet” is as much a new form of writing as blogging was, with its own grammar and conventions. In his article “How the Web and the Weblog have changed Writing“, Philip Greenspun talks about how blogs have given a natural home to ideas that don’t need to be padded out to a whole book or a full-length magazine article; Twitter is just the next logical step.

The web has given us an unprecedented range of tools with which to express ourselves. It is up to us to learn to use these tools, and to understand when it is appropriate to use each one.

JavaScript: Rule 1

JavaScript development (for the web) is big right now, and in 2010 it’s only going to get bigger. There is a lot of information available on good practices for web application development with JavaScript, but if performance and maintainability matter to you, few things* are more important than Rule 1:

Source code is for humans, live code is for machines.

I first heard Christian Heilmann state this rule at @Media Ajax 2007 as “production code is for humans, live code is for machines” but I prefer the term “source code” to “production code”. The rule was important and prescient then; now I consider it the absolute foundation of any significant web application.

Development code is transformed into live code before being sent to the browser.

Rule 1 comes into play as soon as you have a project that involves any of the following:

  • More than a couple of hundred lines of JavaScript source code.
  • More than a couple of JavaScript source code files.
  • More than one developer.

In olden days (say, 2006), the JavaScript code for many web applications consisted of a single file. Comments were few and far between, and variable names were kept short because we wanted the code to be as small as possible. But this strategy does not scale. As projects get more complex, a single file filled with non-descriprive functions and one-letter variable names quickly becomes unreadable. In modern web application development there are two weapons we can use to tackle this problem: concatenation and minification.

Concatenation is the process of taking multiple JavaScript files, and combining them into a single file. Minification is the process of transforming a JavaScript source file to make it smaller. Early JavaScript minifiers just removed comments and unnecessary whitespace, but modern minifiers (YUI compressor, Dojo Shrinksafe, Google Closure Compiler) can also perform more aggresive optimizations, such as shortening variable names and removing unneeded code.

Basically, the JavaScript source code that developers write is no longer the JavaScript code that end users receive, and can see when they view the components for the page. The first benefit of this is performance: concatenating files reduces the number of HTTP requests web app requires, and minification reduces the download size (and can also reduce parsing time on the client). The second benefit comes in the form of better source code clarity, which is good for development and maintenance:

  • You can use multiple files to hold your source code, and organize them (naming convention, file hierarchy) however you want.
  • You can use lots of whitespace and comments throughout your source code.
  • You can use descriptive (long) variable and function names, because the minifier will try to reduce them to one-letter variables (identifier replacement).

A further consequence of this is that when you are writing JavaScript code, you now have to keep three audiences in mind:

  • The browser’s JavaScript interpreter. Your code MUST run in the target browser(s).
  • Humans. Your code SHOULD be clear and comprehensible to your colleagues.
  • The minifier (“compiler”). Your code SHOULD be structured to help your minifier apply its optimizations.

Personally, I am most familiar with the YUI compressor. If you choose to use it, then Nicholas Zakas’ slide deck on structuring your code for optimal optimization is required reading. In addition to helping the YUI compressor make your code even smaller, many of these tips make for tidier, more comprehensible code; and because they encourage the use of local instead of global variables, they can even make your code run faster too. Here are some of the main points:

  • Any literal value used two or more times should be stored in a local variable.
  • Any global variable used two or more times should be stored in a local variable.
  • Any property used two or more times should be stored in a local variable.
  • Try to use only one var keyword and one return statement per function.
  • Don’t use eval, with, or JScript conditional comments.

Where exactly you apply the concatenation and minification is up to you, and will depend on how your deployment pipeline is set up. You can do it as part of your build process, or you can do it at runtime — provided you have some form of caching enabled so that you don’t repeat the process for every request.

*Finally, I should note that the process of concatenation and minification is not the single most effective strategy in reducing the download size of your JavaScript components; that honour goes to gzipping, so I suppose that enabling gzip compression on your web application should, in the programming tradition of zero-based lists, be considered as “Rule 0”. But when it comes to maintaining a complex application, and delivering a compact download package, this is the way to go.

Movable Type drops support for Safari?

I’ve been an enthusiastic user and advocate of Movable Type since version 1 in 2001. I can’t remember any statement from Six Apart that has shocked me more than this one, made by Jun Kaneka on the MT support forum on 9th December:

Just to be clear, MT5 should work fine with Safari. Actually, the UI designer mainly uses Safari to develop MT5.

On the other hand, supported platform is defined by
the platform which QA team conducts their test. It is now

* Mozilla Firefox 3.5 or higher

* Internet Explorer 6.0 or higher

He slightly elaborates on this on the MTOS-dev mailing list, also on 9th December:

That’s the difference between “Supported” and “Should work fine”.
I’m sorry that the System Requirements page on MT.org
is not precise on that part. We will fix it.

The System Requirements page for MT was last updated on 10th December. The “Web Browser” section currently reads:

As Movable Type is a modern web application which uses Javascript and AJAX extensively, it requires a modern web browser. We strongly recommend the latest version of the following browsers. Browsers are free and easy to upgrade!

The Movable Type is tested and supported on the following browsers:

  • Mozilla Firefox 3.5 or higher
  • Internet Explorer 6.0 or higher (We STRONGLY recommend the latest version).

Movable Type should work fine with other modern browsers, but is not tested with these browsers:

  • Safari 3 or higher
  • Opera
  • Chrome
  • etc.

As a web developer, I completely understand the difference between “supported” and “should work”. Yahoo’s Graded Browser Support policy, with its definitions of A, C, and X-grade browsers codifies this concept neatly. With limited development and testing resources it is impossible to fully support every browser.

But for a company like Six Apart to restrict their list to IE6+ and Firefox 3.5+ is mind-boggling. First of all, there is a huge contradiction between the two platforms they do support: IE6 is eight years old, used by a small and rapidly declining percentage of users, and is widely known as the least capable browser platform still in common use today; Firefox 3.5 is one of the most advanced browsers currently available, but it was released a mere six months ago. Secondly: no Safari. Safari is the browser of choice for the vast majority of Mac users, and enjoys significant use on Windows, too.

The only thing I can think of when I look at that list is: enterprise. Movable Type has now completely abandoned its former user base of hobbyists, bloggers, and geeks, and wants to concentrate on selling into the corporate market. The vocal minority of people who will be pissed off by the absence of official Safari support &mdash the trendsetters, the evangelists, the plugin developers, the tutorial writers — are not the people 6A is interested in reaching any more. To be honest, most of them left for WordPress, Drupal, or ExpressionEngine a long time ago. For several years now, Movable Type has been lacking in product momentum, community, and cool factor, but damn it, it’s a great product with a fantastic feature set, and it’s an awesomely stable platform on which to build a site.

But if MT is abandoning me (I’m writing this in Chrome — not Safari, but part of the Webkit family), I don’t think I can continue to recommend it any more, and this makes me very sad.