Using hash routes allows you to keep track of state and decouple event handlers that set state from code that updates the page. Plus you get back button functionality and bookmark support.
Some background info on hashchange: http://blog.whatwg.org/this-week-in-html-5-episode-3
jquery library for dealing directly with hashchange: http://benalman.com/projects/jquery-bbq-plugin/
Higher-level jquery library for handling hashchange: http://code.quirkey.com/sammy/ . It has more assumptions and imposes more constraints on the structure of your code. But in return you get route parsing and a DSL.
If you go through the examples/tutorials in those two libraries you should gain enough knowledge to get started.
the first implementation i've seen of this is in Flickr. i was amazed when i ran into it yesterday. you have to be signed in to preview the new photo pages, but the zoomed/lightboxed photo pages use HTML5 history in compatible browsers and fall back when they can't. their JS is viewable at: http://l.yimg.com/g/combo.gne?j/history-manager.js.v90829.14
So I'd be really careful. Chances are you'll end up with lots of crappy code in js that would be hard to maintain, especially if your frontend is big and you don't have experience in creating interface frameworks.
I managed to find a better answer than it is suggested there, though.
If you take a look at gmail in a debugger you'll see there are 4 iframes. The controller is the 'js_frame', the 'canvas' contains the graphic UI elements.
Leaving the canvas in its own iframe allows it to be reloaded separately without affecting application state.
I used a similar frame-based technique back in '97 when our enterprise startup needed a snappy native-looking zero-deploy UI.
There's a lot you can do with regards to animation in Prototype/jQuery alone, but I like Scriptaculous, and I've heard good things about MooTools.
Making a GMail-like interface isn't all about XML-HTTP-Requests though. There's a lot of value in nailing the usability, the basic concept. Then there's maintaining the history, undoable actions, HTML fallback and such.
My best advice is to start building a decent static interface from the ground up, and when you have it nailed, just augment all the minor GET actions with AJAX first (like going back to the index after reading an email). Then enhance primary POST and UPDATE actions (replying, marking with a star, moving to archive).
Half way through, you'll probably notice most of the page reloads that remain are acceptable. At that point, focus on refining the original concept with new methodologies you picked up along the way.
It's just the way I do it though, make sure you investigate other suggestions to find a perfect fit (by the looks of it, GWT is quite a paradigm-shift).
Caoouccino/Objective-J, from the YC-funded 180north guys. It's an Onjective-C like language that compiles to web apps (and now Mac apps, too). It was used recently to create a Github issue tracker app, which looks pretty sweet.
No one seems to have mentioned SproutCore, which had a lot of buzz for a while since Apple was using it to develop their own webapps. It had a 1.0 release just a few months ago, but the buzz seems to have died down and I haven't seen any new projects using it. Apple is using something else now. Still, it's one option to check out:
Or GWT, just like GMail.
GWT though would be a step towards the OP's solution.
(Paul Buchheit was GMail's creator and lead developer)
Also, here is more proof:
You could tell me: "OK, but it doesn't prove that current GMail is not in GWT. It may have been rewritten". I'd answer that:
- using firebug and looking at the js scripts loaded by GMail, there is no trace of GWT (things such as *.nocache.js scripts). They might have obfuscated to hide it, but why do that?
- if Google indeed rewrote GMail using GWT, they would have announced it, like they did for Wave / Adwords.
More discussion in this other thread:
Also, if GMail is such a successful use case for Closure library, one could wonder why did they build Google Wave client with GWT?
You can read more about it the website, user blogs, or in this month's php|architect magazine cover story http://www.phparch.com/magazine/2010/may/.
Note that if you're really interested you can join us in our #noloh IRC room and someone can help you put together a prototype in relative short order.
Disclaimer: I'm a co-founder of NOLOH.
I primarily code in Py, but I do really want to sit down with GWT some day, it looks badass.
In a lot of my projects I just use raw JS. Big libraries scare me sometimes and honestly, JS isn't that hard if you know what you're doing and know how to code around the main browser issues. I like some of the functional paradigms from mootools though (well any other lib for that matter), and the XHR handling.
(sorry I didn't really answer your question -- just rambled a bit before I go to sleep)
Pyjamas is an RIA framework that started as a port of GWT to Python. Development has recently sparked up and they now offer new features beyond what GWT can offer.
In order to integrate pylons with pyjamas, I've started work on a JSONRPCController base class that I hope will eventually be included in pylons. Eventually I'd like to add other things like a project template and setuptools commands for compiling and deploying a pylons+pyjamas app.
You can get a peek at what I've started on my blog: http://agentultra.com
Then choose in which language the server talks to the world(browsers, mobile apps, native apps, flash,...) usually through json or xml services, REST or not. You are building your API at the same time.
For each platform you can choose different techniques depending on your skills and needs.
I'm not a fan of auto-pilot frameworks. I always felt they force me to think their way to build my thoughts(a personal limitation probably).
When we faced this decision to build our app, we took HTML5.
We know it well and it works on all platforms.
Native apps are cool, but we can't afford them as a startup.
Then on the browser, when you get the data you have to represent them.
I was a fan of XML+XSLT and used to templating logic on the browser.
We use JSON now, and have built a template engine(PURE) for a similar approach and get a fast HTML rendering of JSON data.
And we took jquery to cope with the DOM and browser differences.
The server streams only data, the network likes it.
The browser render all this very fast.
And this makes a very responsive app.
BTW, GWT is one option. Some JS libraries such as JQuery is another.
Question 1: What is your hacker handle?
A1: Zero Cool, A2: Crash Override, A3: Acid Burn, A4: Cereal Killer (select one)
Question 2: Which of these systems do you have control over? (Circle all that apply.)
A1: National Electric Grid A2: Local Electric Grid A3: Any Television Station A4: Any Cellphone Tower A5: Any Satellite A6: Your neighbor's wireless router
Libraries will help you with the DOM, but not a ton. They won't help you with the js.
I suggest you start with a library, but make sure you understan what you're doing in terms of the DOM.