Sublime Text 2, also known as TextMate 2 in my office, is becoming increasingly useful to me. The only trouble thus far is the lack of community involvement to the extent of TextMate. That’s to be expected, it’s an alpha that went cross platform two seconds ago.

All that aside though, it’s an impressive alpha. I seriously love it’s potential and I’m really hoping to make it my own over the next few months. Naturally, the biggest hangup is the lack of tools I’ve become so accustomed to in TextMate. The great thing there is that the snippets and color schemes can be carbon copied into Sublime Text 2, the only outstanding items are Commands. Those aren’t directly portable from TextMate to Sublime Text 2.

I work in HTML, CSS, JavaScript, and PHP. In TextMate I make heavy use of the validators because it’s not an IDE and doesn’t have inline validation as you would find in an integrated environment. Sublime Text 2 doesn’t come with any such validators out of the box, but there are some forum posts. I found some resources on getting JavaScript validation working in Sublime Text 2:

Sublime Text 2 (Alpha) Google Closure JavaScript Linter Build package
(V2 only) JavaScript Google Closure Linter Build

I went through the process of getting Google Closure Linter installed and running fine via Terminal, but got [Errno 2] File not found errors in Sublime Text 2. Additional Googling to find out why got me nowhere so I went with JSLint for the time being and thought I’d share how.

Adding JSLint validation to Sublime Text 2
To implement JSLint we’re going to first need JSLint. There are a number of resources for this, but I went with an OS X executable provided courtesy of javascriptlint.com. I made a new folder in my Applications folder and called it a day. JSLint is prepped and ready to go.

The other half of this puzzle is integration with Sublime Text 2. To do that, you’ll need to create a new Build System:

Upon invoking that menu, Sublime will give you an empty file to work with, outlining the structure of Build Systems. Sweet, but what to do with that? We want to send the current file we’re working with to JSLint for validation. To do that, our Build System will look like this:

{
"cmd": ["/Applications/jsl/jsl", "-process", "$file"],
"selector": "source.js"
}
Note the path to Applications/jsl/jsl — that’s where I store my JSLint install, but you will need to modify that to the path on your system. The next parameter is the -process flag that JSLint uses to define the file to validate, and the final parameter is the $file flag that will be replaced with the file path to the file you’re currently working on.

The selector will help Sublime Text 2 automatically use this JSLint Build System when you’re working within a JavaScript file.

After modifying for your system, save the file to the default path Sublime Text 2 brings up in the save dialog and restart Sublime. Open up a .js file and hit CMD+B, or use Tools > Build. An inline prompt will appear giving you the JSLint results:

I’ll continue fiddling around with getting Closure Linter to work as I’d like to have the option, but if anyone’s got a tip regarding the error I was getting I’d love to hear some feedback.

The first part of my post of 1 February was not an attack on Flash. It described a way of working with Flash that also supports users who don’t have access to Flash. I’ve followed and advocated that approach for 10 years. It has nothing to do with Apple’s recent decisions and everything to do with making content available to people and search engines.

It’s how our agency and others use Flash; we’ve published articles on the subject in our magazine, notably Semantic Flash: Slippery When Wet by Daniel Mall.

We do the same thing with JavaScript—make sure the site works for users who don’t have JavaScript. It’s called web development. It’s what all of us should do.

My point was simply that if you’re an all-Flash shop that never creates a semantic HTML underpinning, it’s time to start creating HTML first—because an ever-larger number of your users are going to be accessing your site via devices that do not support Flash.

That’s not Apple “zealotry.” It’s not Flash hate. It’s a recommendation to my fellow professionals who aren’t already on the accessible, standards-based design train.

THE SECOND PART OF MY POST wasn’t Flash hate. It was a prediction based on the way computing is changing as more people at varying skill levels use computers and the internet, and as the nature of the computer changes.

There will probably always be “expert” computer systems for people like you and me who like to tinker and customize, just as there are still hundreds of thousands of people who hand-code their websites even though there are dozens of dead-simple web content publishing platforms out there these days.

But an increasing number of people will use simpler computers (just as we’ve seen millions of people blog who never wrote a line of HTML).

THE THIRD PART OF MY POST wasn’t Flash hate. It was an observation that Google and Apple, as companies, have more to gain from betting on HTML5 than from pinning their hopes to Adobe. That’s not a deep insight, it’s a statement of the obvious, and making the statement doesn’t equate to hating Adobe or swearing allegiance to Google and Apple—any more than stating that we’re having a cold winter makes me Al Gore’s best friend.

(Although I like Gore, don’t get me wrong. I also like Apple, Google, and Adobe. My admiration for these companies, however, does not impede my ability to make observations about them.)

THE THIRD PART OF MY POST ALSO WASN’T a blind assertion that HTML5, with VIDEO and CANVAS, is ready to replace Flash today, or more adept than Flash, or more accessible than Flash. Flash is currently more capable and it is far more accessible than CANVAS.

We have previously commented on HTML5’s strengths and weaknesses (Exhibit A, Exhibit B, Exhibit C) and are about to publish a book about HTML5 for web designers. HTML5 is rich with potential; Flash is rich with capability and can be made highly accessible.

That it is unstable on Mac and Linux is one reason Apple chose not to include it in its devices; that this omission will change the way some developers create web content is certain. If the first thing it does is encourage them to develop semantic HTML first, that’s a win for everyone who uses the web.

Carry on.