Last weekend I went up to Cambridge, MA for the ’09 jQuery Conference. Two days of great jQuery/JavaScript goodness! I gotta say that was the best conference I’ve been to in awhile.

There were a couple presentations I had to skip but the breakout sessions more then made up for them. All in all I took home some great tips & tricks for:

• writting efficient jQuery code
• using custom events for single page web apps
• speeding up page load with tools like labjs
• building iPhone apps via jQTouch
• and the biggest tip of all… get a hotel within a mile from conference

The conference was held at the Microsoft New England Research & Development Center aka MS NERD. Took this panoramic shot of Boston from the lunch area duing conference…

Great venue!! The wifi was sick! Looking forward to the next event @ MS NERD Center.

Check out the presentation slides from the conference. Make sure you go next year!

Such applications cannot efficiently be developed without relying on a solid build process to do all the dirty and repetitive work of reliably putting all the pieces together.

So its about time you setup your own build process. Julien’s blog post is great but I’m gonna start with the basics and try to give you all the info you need to get up and running asap. Everything fromorganizing the directories right down to the commands to run the build. This will help you get going with something you can build on (no pun intended!).

Over time I’ll post more advanced task I have in my build process but for now we’ll focus on the basics. At the end of this post are some links to extra resources so you can dig into more details about the tools used here.

Directory Structure

• My Projects:
  main projects folder for all your applications & libraries
• sample_project:
  sample project we’ll use to show the build process
• build:
  the results of a successful build. These files are what get deployed to your server(s).
• src:
  all your source code for a project
• shared:
  resources shared between projects
• bin:
  all the resource files required to get your build going.
• external:
  external code shared between projects
• local:
  local code shared between projects

Resources
You will need some well known development tools to get this going… here’s a list with links:
Ant – a build tool used to manage the build process.
Java – the Java Runtime Environment is required for some other tools in build process
YUI Compressor – tool for the compression of both JavaScript and CSS files

Create a folder for YUI compressor in the my_projects/shared/bin directory then unzip and copy over the yuicompressor-x.y.z.jar file from the download.

Ant Build Files
I’m far from an Ant expert but I know enough to get a basic build going so here’s an Ant build.xml for you to experiment with. Open up your favorite text/code editor and drop this xml in there. Save it to your sample_project folder as build.xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

<?xml version="1.0" encoding="ISO-8859-1"?>
 
<!--
   The <project> tag defines the ant project and 
   the default build task to run initiated. It 
   also defines the base directory which is set
   to the current folder this file lives in.
-->
<project name="sample_project" default="build" basedir=".">
   <!--
      The <property> tag defines variables we 
      are using to store the path to different 
      files and tools required and input/output 
      directories. You use those variables by
      like this: ${variable}
   -->
   <property name="BUILD_DIR"      value="build" />
   <property name="SOURCE_DIR"     value="src" />
   <property name="SHARED_DIR"     value="../shared" />
   <property name="EXTERNAL_DIR"   value="${SHARED_DIR}/external" />
   <property name="LOCAL_DIR"      value="${SHARED_DIR}/local" />
   <property name="RESOURCE_DIR"   value="${SHARED_DIR}/bin" />
   <property name="YUI_COMPRESSOR" value="${RESOURCE_DIR}/yui-compressor/yuicompressor-2.4.2.jar" />
   <!--
      The <target> tags defines an ant task.
      You have to give it a unique name and
      list other task (if any) this task 
      depends on. Ant will run those task first.
 
      This task below is the default task defined
      in the <project> tag. It will run all the
      dependents.
   -->
   <target name="build" depends="clean, bundle_javascript, compress_javascript" />
   <!--
      This is the "create JavaScript bundles" task
      used to create concatenated files for each 
      category defined and a main application bundle
      which contains all the code we need in one file.
   -->
   <target name="bundle_javascript">
      <!-- create the output directory for built files -->
      <mkdir dir="${BUILD_DIR}/js"/>
      <echo>Bundle JavaScript Files...</echo>
      <!-- external.js: all shared third party code -->
      <concat destfile="${BUILD_DIR}/js/external.js">
         <fileset dir="${EXTERNAL_DIR}/js" casesensitive="yes">
            <include name="**/*.js"/>
         </fileset>
      </concat>
      <!-- local.js: all shared local code -->
      <concat destfile="${BUILD_DIR}/js/local.js">
         <fileset dir="${LOCAL_DIR}/js" casesensitive="yes">
            <include name="**/*.js"/>
         </fileset>
      </concat>
      <!-- core.js: all the core project related code -->
      <concat destfile="${BUILD_DIR}/js/core.js">
         <fileset dir="${SOURCE_DIR}/js" casesensitive="yes">
            <include name="**/*.js"/>
         </fileset>
      </concat>
      <!-- main.js: the main big bundle of all the previous bundles -->
      <concat destfile="${BUILD_DIR}/js/main.js">
         <filelist dir="${BUILD_DIR}/js/" files="external.js, local.js, core.js"/>
      </concat>
      <echo>JavaScript Bundles Done!!!</echo>
   </target>
   <!--
      This task will compress the main.js bundle using YUI 
      compressor and rename the file main.compress.js
   -->
   <target name="compress_javascript" depends="bundle_javascript">
      <echo>Compressing JavaScript Files...</echo>
      <apply executable="java" parallel="false">
         <fileset dir="${BUILD_DIR}/js" includes="main.js"/>
         <arg line="-jar"/>            
         <arg path="${YUI_COMPRESSOR}"/>            
         <srcfile/>            
         <arg line="-o"/>            
         <mapper type="glob" from="*.js" to="${BUILD_DIR}/js/*.compress.js"/>            
         <targetfile/>
      </apply>
      <echo>JavaScript Compression Done!!!</echo>
   </target>
   <!--
      This task will clean out any previous build files by
      deleting the current build folder and re-creating it
   -->
   <target name="clean">
      <echo>Delete old build folder...</echo>
      <delete dir="build"/>
      <echo>Create new build folder...</echo>
      <mkdir dir="${BUILD_DIR}"/>
   </target>
</project>

Go over the comments to get an idea of what’s going on in this file.

The Process
So what’s the process? It’s all outlined in the Ant build file. A typical JavaScript build usually consist of code concatenation, compression and deployment to a build folder ready to get used by whatever needs to consume it. Each of these task are defined as nodes. One task can trigger others based on dependencies. So in practice, once your done coding your super cool long awaited web app and your ready to test it out… pick a build task and run the build.

Build It!!
To build your app you’ll need to navigate to your project folder from the command line. The same spot where the build.xml file lives. And type “ant” then the enter key. You’ll get some output on the screen as Ant goes through each task. If it fails it you’ll get something like “Build Failed…”. Double check the build file, your folders, files, paths and all that. If the build is successful then you see something like “Build Successful…”.

That’s it…the build folder will have all the output files. I encourage you to play around with Ant and customize the build file to something your comfortable with.

You can learn more about Ant from these books:
Ant: The Definitive Guide
Ant in Action
Pro Apache Ant

Next time I’ll talk about creating different builds for different environments and also deploying your code to your web server.

Send me any questions or feedback you may have to my twitter at http://twitter.com/JavaScriptr or hit me up on our contact form.

There were some minor issues and probably more to come but all in all I’m happy with this new design. I plan on adding more features and content to this site so stay tuned.

Ok, if your like me then you hate all templating langauges- they suck, they really suck. I hate them because I hate the rules they enforce upon me, they are slow, and they slow me down. Because of this, usually I end up making code that looks like this:

UGLY:

1
2
3
4

function display(data) {
   var output = "<div>" + data.text + "</div>";
   element.innerHTML=output;
}

How horrible is that? That’s probably worse than using a bad templating langauge.

Well, after disappointments with other jQuery templating plugins, I decided to make my own:

The Solution: PureJSTemplate

With PureJSTemplate you use old fashioned javascript in your template. You simply surround the javascript in special tags. Here’s an example of what you can do:

1
2
3

<# for(var i=0; i<10; i++) { #>
   <#=i#><br/>
<#}#>

That will output the numbers 0 through 9. Easy, isn’t it?

Using it:

You simply surround your template code with a textarea tag:

1
2
3
4
5

<textarea id="tpl" style="display:none">
 
<!-- TEMPLATE CODE HERE -->
 
</textarea>

and call it from javascript like so:

1
2
3
4

$("output").pureJSTemplate({
   id   : "tpl",
   data : {}
});

That’s it.

Get the Code:

Visit a demo/benchmark page here. Get the js here.

This implementation uses XHR long polling, glassfishv2.ur2 and grizzly comet 1.0.9.

The problem: RemoteServiceServlet

GWT loves POST. All RPC calls made back to your subclass of RemoteServiceServlet will hit the doPost method. However, this method is final and cannot be overridden – meaning we cannot create a comet handler for the request in our subclass of RemoteServiceServlet. We want to continue using RPC but we don’t want to use RemoteServiceServlet. WTF?

The solution: SimpleServiceServlet

Pretty much the RemoteServiceServlet is too secretive. So I pulled out its code and gutted it- creating SimpleServiceServlet. It’s new doPost method calls doConnect which you can override in your subclass – allowing you to create a comet handler. Yay.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class CometServiceImpl extends SimpleServiceServlet implements CometService {
   public CometContext cc;
 
   public CometServiceImpl() {
   }
 
   class GWTCometHandler implements CometHandler<HttpServletResponse> {
      ....
   }
 
   public void doConnect(HttpServletRequest req, HttpServletResponse res) {
      try {
         res.setContentType("text/html;charset=ISO-8859-1");
         GWTCometHandler ch = new GWTCometHandler();
         ch.attach(res);
         ch.attachRequest(req);
         cc.addCometHandler(ch);
      } catch (Exception e) {
         System.out.println("connect: e=" + e);
      }
   }
}

Other issues: The RPC Thing

GWT expects a return value from RPC methods. But what about in the case of comet? There technically isn’t an RPC method – a connection is established and then the client waits. Well, lets not re-write GWT, lets just make it happy. In traditional GWT RPC apps we extend the “RemoteService” interface that’s used by the server and the client. Let’s go ahead and do that:

1
2
3

public interface CometService extends RemoteService {
   Message comet();
}

And lets also create the object we are going to return via comet and RPC:

1
2
3
4
5
6
7
8
9
10
11

public class Message implements IsSerializable{
   private String text;
 
   public void setText(String text) {
      this.text=text;
   }
 
   public String getText() {
      return text;
   }
}

So we basically follow the pattern perscribed to us by GWT – but heres the catch. In our implementation of CometService we do the following:

1
2
3

public Message comet() {
   return null;
}

Yes, we return null! This way we make GWT happy – it can continue to do all of its fancy RPC’ing. And we can do comet without any hassles. But, how do we return serialized objects to the client?

Return serialized objects?

We do it in our subclass of grizzly’s CometHandler -

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class GWTCometHandler implements CometHandler<HttpServletResponse> {
   HttpServletResponse res;
   HttpServletRequest req;
   public void onEvent(CometEvent ce) throws IOException {
      System.out.println("onEvent");
      // GWTEvent event = (GWTEvent) ce.attachment();
      Message msg = (Message) ce.attachment();
      try {
         //LETS SERIALIZE!!!
         String encoded = RPC.encodeResponseForSuccess(CometServiceImpl.class.getMethod("comet"), msg);
         //LETS WRITE THE RESPONSE
         writeResponse(req, res, encoded);
         removeThisFromContext();
      } catch (SecurityException e) {
         e.printStackTrace();
      } catch (SerializationException e) {
         e.printStackTrace();
      } catch (NoSuchMethodException e) {
         e.printStackTrace();
      }
   }
   ......
}

The Code:

A good sample app is worth a thousand words – download it here. This is a very simple and rough attempt at getting GWT working with Grizzly Comet. I’ll be posting an improved version at some point. It does not work in the GWT shell. You will have to deploy it to glassfish.

Its a great time to be a Javascript developer (aka a JavaScriptr). So many things going on.

Find out more about Adobe Air here. Happy Scripting!

First, what is Aptana?
Aptana Inc. is a company founded by Paul Colton back in 2005 (Paul created JRun back in the day). The company’s first product is an open source JavaScript IDE called, you guessed it, Aptana which is based on the Eclipse platform. The IDE name was recently changed to Aptana Studio. It’s a pretty popular product that many JavaScript developers use. There are about 1,321,900 downloads to date according to counter on the Aptana website.

Ok, now what is Jaxer?
Jaxer is the latest product from Aptana. It is “The world’s first Ajax server”. Basically its an application server that speaks JavaScript. This means you can code your entire web application (front and back end) using JavaScript, HTML & CSS only! Aptana Jaxer is also an open source project licensed under the GPL. The JavaScript and DOM engine is the same one used in Firefox 3 (Mozilla). This means you can write your code using the latest JavaScript specs (1.5 to 1.8).

Cool! Now how will this change the game?
Are you kidding me? In my career as a web developer (since 1998) I’ve written code in VB, Tango, Perl, ColdFusion, Java, PHP and a bunch of unheard-of proprietary languages. The only programming language I’ve used in all my projects is JavaScript. Imagine a world where you don’t need to worry about all those other server side languages. Who needs Ruby on Rails? Why not use the most popular programming language on the web?

Now I know its a bit early to dump server languages like Java, PHP and ROR. Jaxer is still in beta (v0.9) and they just released a version for Linux. So we still have a long way to go but since this is all open source, I really hope the see it take off. I plan on doing my part so look out for future articles about applications I’ll be porting over to Jaxer.

Read more about Jaxer at http://www.aptana.com/jaxer

jRails is a drop-in jQuery replacement for Prototype/script.aculo.us on Rails. Using jRails, you can get all of the same default Rails helpers for JavaScript functionality using the lighter jQuery library.

I plan to start programming with Rails soon so I’ll definitely be adding this to my arsenal.

I’d like to push this further by creating a desktop app that can also live on the web. Maybe even communicate with the desktop version.

You can check out Snook’s article here.

I’m all for it. This is a big step for web development on portable devices. I hope other pda and smartphone makers follow Apple’s lead. I took a quick look at the developer documentation today and found some interesting things I wanted to point out.

• Integrate phone calls, maps and emails using links. Mail and map links are not different from what we use on normal browsers (“mailto:anemail@domain.com” and ” http://maps.google.com?address”) but phone links use a new url format which starts with “tel:”.
  Here’s an example:

  1	<a href="tel:1-123-444-5555">Call Me</a>

• Assign an iPhone style sheet with the link tag.

  1 2 3 4 5

  <link media="only screen and (max-device-width: 480px)" href="iPhone.css" type="text/css" rel="stylesheet" />

  This is new to me. Seems like its part of the CSS3 recommendation.

• iPhone doesn’t support window.showModalDialog(), mouse-overs, hover styles, tool tips, java applets, flash, plugin installation or custom x.509 certificates.
• PDFs, Cookies and user-initiated window-open calls are supported but there’s a limit of 8 pages (8 open windows) in page view.

Here are some iPhone third party apps:
http://www.launchpadhq.com/
http://www.37signals.com/svn/posts/502-ta-da-list-for-iphone
http://digg.com/iphone