Well, with the Dow making its biggest single-day point gain ever today, maybe things aren’t going to be so bad after all. However, the economy is still on everyone’s mind these days, especially us independent consultants. Will shrinking demand for development services cause our business to decline, or will hiring freezes and tight budgets cause IT managers to look to variable-cost options like consultants and small development firms to keep key projects alive? Time will tell.

In case it’s the former, I’ve put together my predicted top ten growth industries for 2009, so we can all focus our limited resources wisely:

1. Brisk trade in gold, guns
2. Generating electricity for
3. Foraging for nuts and berries
4. Being a Democrat in elected office/Not being a Republican (tie)
5. Repurposing credit default swaps into lightweight, waterproof shelters
6. Issuing public guarantees of underperforming bank assets/nationalizing the banks (tie)
7. Innovative financing methods to enable less-creditworthy borrowers to participate in the dream of home ownership, only in this case the dream is a blood-chilling national nightmare
8. Law practice specializing the the raft of rushed and poorly thought-out regulations about to be imposed on the financial industry
9. Fix and flip!
10. Providing Agile training and coaching at recession-sensitive prices to give businesses the tools they need to remain competitive in the face of shrinking budgets and to position themselves for success in the recovery, following Tim Bray’s recent suggestion

With so many options to choose from, 2009 could still really be an exciting year. As for me, though, I think I’m going to go with #10. Who’s with me?

At the DOSUG meeting last night, Matt Quinlan talked to us about his company’s product, Appcelerator. Appcelerator seems at first blush to be another JavaScript framework wanting to make AJAX and UI widgets easier, but actually does have a pretty neat spin on the problem that makes it something more than just another dōjō or jQuery. Appcelerator brings delcarative, remotable messaging to HTML. Put another way: the Observer pattern is back in your web UIs, and it misses you.

Early in his talk, Matt laid out the competing philosophies in the RIA space: to wit, plug-ins vs. the open web. These terms themselves are a bit tendentious (whatever is the opposite of “open” can’t possibly be good), and some of his arguments in favor of the open web were a bit thin, but at the end of the day I am with him here. Despite the power of the Flash plugin to deliver pixel-perfect UIs, cross-domain networking, and snappy user interaction with impunity, I still think HTML, CSS, and JavaScript are the best way to go most of the time. Call me a masochist.

Appcelerator includes some nice UI widgets and a framework-agnostic means of wrapping others’ JavaScript- or Flash-based UI widgets with a consistent API, but the talk was not about the widgets. The real value of Appcelerator comes in its in-browser message bus. Using nonstandard HTML attributes in your markup (something like

), any of a large set of DOM events, key presses, mouse events, drags, drops, etc., can be published to a message bus running in the page in JavaScript. Likewise, any scriptable element can be delaratively advised to subscribe to messages in the bus. Thus HTML elements become Observers of an impressively generalized stream of events in the browser, and you are free to think about your UI at a level of abstraction bordering on the appropriate.

But wait, there’s more! The message bus isn’t constrained to the browser alone. You can publish messages to remote endpoints, which in the case of Java are consumed by annotated POJOs on the server (presumably through the agency of a canned servlet-cum-Controller you’ve mapped in your WAR). Back-end services are responsible only for returning JSON data, which is more or less automatically consumed by the Appcelerator front end according to some friendly-seeming naming conventions and the message subscription declarations already described. This is cool in the extreme.

This architecture has several positive implications. Chief among them is that your HTML pages become an entirely static resource, able to be served from a vanilla Apache instance disconnected from Tomcat, JBoss, WebLogic, the Black App Server of Mordor, or whatever. Your code does not render HTML anymore. Further, it becomes easy to mock back-end services in pure JavaScript. This allows front-end developers to write a complete and functional front end user interface—an artifact which is not a mock in any sense of the term—while easily mocking the back-end services by including a single JavaScript file. This JavaScript mock (really just a bunch of functions returning some JSON) then becomes the ultimate Agile spec document to be consumed by the back-end team one iteration at a time. It’s like the product practically builds itself.

And hey, as an aisde: some Appcelerator ninja should suggest a convention for this mock file, perhaps using JavaDoc-like comments that could easily be processed at build time into a publishable HTML spec document for quick reference. The code itself shouldn’t be too hard to read, but this extra step would be a nice touch.

Matt also talked about tooling a little bit, but with Appcelerator’s embrace of the open web, the tooling question becomes less important as a part of their value proposition. They can assume that we all have tooling we like for building HTML, CSS, and JavaScript—or perhaps more to the point, tooling we hate, but tooling we at least can call our own.

Appcelerator  was founded and is advised by veterans of the open-source world, including Matt himself, who was Employee 31 at JBoss and an early hire at Appcelerator. The company’s site puts forth the image of an open-source startup, but there is no mention of any way to give money to them, and Matt was coy on this question when I asked him. Given the recent tremors in the Enterprise Java community caused by Spring Source’s changes to their support policy, I feel a new sense of caution on this front. The product is licensed under Apache 2.0, so there’s no questioning its open-source-ness, but I’d still feel a little more relaxed about trying to adopt it for a future project if I knew how the company planned to make money some day. Now, don’t get me wrong; I love philanthropy, but the knowledge that somebody, somewhere is trying to make money from a product I use still gives me a certain sense of comfort, as if I need not speculate about future motives or present sources of funding. It makes sense that Appcelerator would be giving things away with abandon now, while trying to grab market share, but I’d recommend that they modify their messaging to include something about their future business plans. It would just give us a warm fuzzy, is all.

Notwithstanding that minor note of caution, this is a really impressive product that I’d like to try to take for a test drive as soon as I can. I’m very glad to have seen Matt’s talk.