I gave a talk this week at the Mountain View JavaScript meetup hosted by Google at the Google headquarters in Mountain View, California. Thanks to Michael Carter who hosts this event on a monthly basis. The event was also video recorded by Google and is being made available on Youtube, although I don’t yet have a URL for it. Below are my slides from the talk, available on Slideshare.

If you haven’t yet tried Appcelerator Titanium, I would encourage you to do that now. It’s a pretty awesome product and makes it much easier and faster to bring the world of desktop and mobile applications to Javascript / Web Developers. Titanium Mobile provides a web platform for building native iphone and android applications using web technologies.

Today, Titanium Mobile is still in private beta. However, if you’d like early access, please email me or get in touch with me through Twitter and I’ll be glad to activate you.

I gave a talk last night (December 2, 2008) at the SD Forum’s Java SIG in Palo Alto, CA.

The subtitle of the presentation was: “How the web has gone beyond the browser and we’re headed back to Client/Server”. I’m including the presentation slides below:

It’s been a little over a year and 4 months since Nolan and I started Hakano after the acquisition of Vocalocity. We have spent a lot of time during the past year trying to help a few companies build and launch rich Internet applications. It was hard and painful in the beginning. And, early on, we decided it was just still too hard to do interesting stuff these days. Javascript really sucks, and the cross-browser issues are a killer. Being software guys, we really wanted to solve the problem using a platform approach to the problem. That’s just the way we think, it’s our DNA.

Late last year, after spending the summer and Fall building some web2.0-style applications and struggling with tons of Javascript, stomping on each others variables (yeah, we eventually moved to namespacing in JS), playing with lots of javascript/ajax frameworks and learning the hard way about how to do complex RIAs in a lopsided browser world – we decided to build something to help solve the problem. We code named it Seamless and developed it with a few customers that were gracious enough to provide us with interesting enterprise projects that benefited from next-generation web features. We’ve continued to refactor it over and over this past year and today, I’m proud to announce that we’ve officially launched the product and company as Appcelerator.

Appcelerator is a name that signifies what we want to accomplish: More App. Less Code. It takes way too much code to do interesting web applications that push the limits of great user experience and a rich-application feel. And, throw in a little requirement to support IE6, IE7, Opera, Firefox, Safari, iPhone, Camino and a ton of other mutations and variations – and you’ve got entirely too complex of situation for even the most talented web developer.

There’s a lot of approaches out there. And ours is different and we think it revolutionizes the way people develop web applications today. We think model-view-controller (MVC) is no longer the best approach to building SOA-enabled web applications. We believe that SOA should include Service-Oriented Application architectures – a lot like the good old days of Client-Server. We believe that there should be a clean separation between the application and the services the application uses. And, the service should be developed with a clean contract and be available to different types of applications. Some people would call that a mashup (and if you get really fancy, an “enterprise mashup”) – where you can integrate multiple services using disparate pieces of information interwoven into a useful app. We think this is really just good SOA design. If you develop your services in an SOA architecture – and then cleanly separate your application from those services – you’ll get mashup capabilities out-of-the-box. It will also be much easier to layer cross-cut concerns across your architecture – such as security, auditing, governance, aggregation and composition and complex work flow – to name a few.

Separation also has the benefit of separation of concerns from a workforce standpoint. OK, we’ve been talking about this for a long-time – especially in the Java EE world. But have we realized this yet? No, c’mon. We still work with a designer (generally) to wireframe the design, we turn that into a page template (dependent on the server-side framework in use) and then we wire it up with our controllers (if you’re really good, otherwise, you just code it all inline) and call them “views”. Yea, right, “views” – nothing more than a fancy word for something that was really invented for tightly coupled graphical user interfaces of yesteryear. In Appcelerator, you have true separation between the application and services that the application interacts with.

Additionally, service-level separation provides a good demarcation for contract-driven programming (or as some might say, interface-driven programming but without real language interfaces). When you can cleanly separate services – you can now independently develop the application from its services – and even switch out those services underneath the cover (sounds like SOA, huh)? For example, application development can progress even before integration of services has even commenced – or can run in parallel. You can even completely mock out the entire application without any real back end services – which is how we recommend you do it – such that the user interface becomes true use-case driven development. And it’s very iterative – unlike traditional MVC where you have to re-templatize, re-wire and then re-integrate code for every UI change.

There are so many other great things about what we’re doing – way too many to discuss in one blog post. So, I’ll spread them out here and on our new developer community blog just launched, called Appcelerant (get it, rant!). Stop by sometime and subscribe with your RSS reader – we’ll be having some fun and interesting discussion over there.

A little bit about the company and the model. We’ve released Appcelerator under a GPL version 2 license and our business model is a traditional professional open source model. We’ll be offering strategic consulting, training, commercial licensing and a subscription model for support.

We also have grown quite a bit since we started. We’re now at 12 employees and we have some very interesting people that are joining our team very soon that I can’t wait to talk about.

We have a good bit of work to do to really round out the product and community. We’d really like your feedback and support. If you’d like to join the community, please do so at http://www.appcelerator.org. The first 250 people to join will get a special gift and forever be known as “Early Appdopters”. Come out and support us and you’ll forever be famous (at least in our eyes).

appcelerator ria soa atlanta web2.0 hakano

I have been doing a lot of cross-browser javascript coding in the past 6 months. It’s not fun, very miserable in fact. Most of the time, Firefox, Safari and Opera work without much effort and differences between the 3. However, throw IE into the mix and you’re in a whole different world. Most people don’t really appreciate how much different – and non-compliant – Microsoft’s browser(s) are. In fact, IE6 is probably 100 times worse than IE7. But, IE7 has it’s own problems as well.

Here’s how you can dynamically load an external javascript source file at runtime (from javascript). This is helpful if you need to dynamically inject javascript. And, the biggest problem was setting a function that you want executed after the script is loaded. Normally, this is done by setting the onload property to a javascript function which will be invoked after the external javascript file is loaded. However, like most things MSIE, you have to do it a little differently.

Here’s the cross-browser code:


var script = document.createElement('script');
script.setAttribute('src','myjavascriptfile.js');
script.setAttribute('type','text/javascript');
var loaded = false;
var loadFunction = function()
{
if (loaded) return;
loaded=true;
// your code goes here
alert('your JS file is now loaded');
};
script.onload = loadFunction;
script.onreadystatechange = loadFunction;


On all browsers except IE, onload works properly. However, on IE, you’ll need to use the property onreadystatechange.

I’ve tested this on the following browsers:

Safari – Mac and Windows
Opera – Mac and Windows
Firefox – Mac and Windows
Camino – Mac
IE6/IE7 – Windows

technorati tags: javascript, crossbrowser

Today, we introduced the Seam(less) web application framework. The project uses the open source Apache Software License, version 2.0 for flexibility. You can download Seam(less) from Sourceforge. We have also setup a Google discussion group.

We started Seam(less) because we believe that Ajax has enabled much more than rich web client interfaces. We believe it has paved the way for a paradigm shift in web programming – a shift away from MVC-based frameworks towards lightly coupled Client/Server-based frameworks.

We believe these next generation frameworks should have the following characteristics:

• Server language independence

Developers should be able to use any language for sever development (e.g., Java, Ruby, PHP or .NET) and this choice should not impact the development of the user interface in any way or vice versa.

• Integrate the Client and Server via a lightweight, language independent message protocol

You should be able to develop client and server components independently. The contract between the client and the server should be a very simple message-based protocol. This is the primary principle behind a Service Oriented Architecture (SOA), and we believe it’s mandatory if you want to rapidly build and deploy web-based services.

You should also be able to develop fully functional client prototypes without writing a single line of server code. Furthermore, client prototypes should be convertible into production clients with little to no change.

• Leverage Ajax and DHTML without Javascript

Using Ajax and DHTML requires a significant amount of Javascript. We believe that rich client functionality should be possible without writing a single line of Javascript, but there should be Javascript-based hooks available for developers that desire more control.

• Cross-browser Support

Application developers should not have to worry about the complexities of running an application across multiple web browser products and versions.

With these characteristics in mind, we developed Seam(less). We’ve been using the framework for almost six months. It has been used on all of our projects since its development, and it has saved us hundreds of hours in development time.

We decided it was time to give Seam(less) to the community. We hope you enjoy using it as much as we have. We welcome any suggestions, comments or contributions that you would like to make. We will continue to update this site with examples that demonstrate how to use the Seam(less) framework.

technorati tags: seamless, javascript, ajax, web2.0, programming

We use Prototype in our projects when developing AJAX applications. We recently started a project with a customer that is porting their Flash-based product to one that is primarily driven from Mozilla’s XUL framework. XUL has an entire framework for building cross-platform UIs – it’s mostly only for Mozilla-based browsers, although others have tried to use the XUL spec to run in other browsers.

I was planning on leveraging the Prototype library – the same that we do in typical web applications. The basics worked fine – until we ran into a pretty trivial prototype requirement – AJAX requests. You gotta love fun errors like the following:

TypeError: this.transport.onreadystatechange.bind is not a function

Geez, thanks – that was very helpful.

After summoning google to do a little research for me, I found a year old post in a Ruby on Rails mailing list with someone having a similar problem. Luckily, I found a patched version of Prototype 1.4 that has all the fixes. Basically, in Mozilla there is a very old bug that doesn’t allow you to add new methods dynamically to Function or Regexp. [1],[2] This new patched Prototype will replace all the bind methods on objects with a new generic bind method that does that same job as an anonymous javascript function reference.

Download the XUL for Javascript fix

technorati tags: xul, prototype, javascript

[1] Mozilla Group Discussion
[2] Mozilla Group Discussion

Microsoft IE is such a pain some time. I’ve been trying to create a dynamic stylesheet – one whereby the contents of the stylesheet are dynamic and not known at page load time. This is web2.0, isn’t it?

In Firefox, Opera and Safari it seems I can create a style object and then append content to it and simply append it to HEAD using DOM. However, in IE, if you try that, you’ll simply get an exception. I’ve tried several attempts before I came up with this solution that seems to work fine.

You can use this snippet of code for creating a IE based stylesheet.

You’ll need to then define to variables used within the code:

1. styleCSS – this is the CSS code
2. head – this is the DOM element for head. This can also be any DOM element you’d like to insert the CSS into

In the code above, I’m using the prototype JS library for one fraction of code for splitting and iterating over the individual rules.

technorati tags: javascript, msie, css