Imo, the most important technique (besides standard ajax with js lib of choice) is making use of hashchange and organizing your behavior into 'routes' based on the hash. You'll notice that Gmail does this -- it has URIs ending with #inbox, #label/action, etc.
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.
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
I'm not sure if you asking exactly this, but here's what I'll tell you. We're building a frontend interface for our webapp now (almost finished) and I have to say it's a difficult design task, in terms of code, of course. The truth is that libraries like jQuery have really nothing to do with building interfaces. They have a couple of effects, a couple of useful shortcuts (like selecting dom elements easily), a couple of solved issues (like browser compatibility), but if you're going to write an interface - be ready to give a good thought about how to arrange the code, so that it would not look ugly.
Especially because we're talking js now, I think it's a hell of a task, as I have this impression the language was designed to duplicate as much code as you possibly can. It's not Python or Ruby and you have to understand it inside out to make it right. In Ruby, for example, it's easy to write nice looking code even if you're a beginner. I haven't tried ExtJS or some other frameworks, maybe they provide some necessary background that helps you organize things better. But jQuery and Prototype definitely don't do that. Then there's the question of testing, which is a pain in the ass in javascript, even though we have nice tools like jspec.
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 have this impression the language was designed to duplicate as much code as you possibly can
You're right about the limits of jquery, but JavaScript is not like Java inasmuch as repetitious JavaScript is a near-sure sign that you're doing it wrong. I'm working on a larger script too these days, and code organization is a problem for me, too, but repetition isn't really.
unDRY code is a problem for me in JavaScript probably because I don't have too much experience. The point is: you can write DRY code in js, it's just not as easy as in Ruby. Also, here's an example: http://stackoverflow.com/questions/3077335/how-do-i-implemen...
I managed to find a better answer than it is suggested there, though.
Gmail's interface is unique in that the rendering is being done by a Javascript Controller in a hidden iframe. Gmail itself only requests raw data over the wire.
If you just want the look and feel of Gmail, there are plenty of frameworks referenced in the comments (Cappucinno, YUI2, Sencha, etc) that can give you the basic layout. But if you want the mimic the speed/functionality, it'll require getting dirty with Javascript controller design in the browser.
Sure. The hidden iframe allows you to do 3 things: 1) preserve state across view changes (mail vs. preferences, etc) 2) isolate code 3) reduce over-the-wire data size because all the rendering/UI generation is happening in-browser.
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.
Javascript still modifies the canvas iframe DOM. But that modification is cross-frame from the controller iframe.
I used a similar frame-based technique back in '97 when our enterprise startup needed a snappy native-looking zero-deploy UI.
Well you definitely need something to handle AJAX. I pick between Prototype and jQuery, depending on the project. Sometimes I mix and match with both, since jQuery can coexist.
Next, you need to decide whether you will transport XML/JSON and have client-side code stick in in the DOM, or eval the AJAX response. In the latter case, you need to be generating JavaScript on the server-side. I know the Ruby on Rails RJS piece of the stack can be extracted from Rails 3, but I'm unsure about Python, so you might be better off taking the former approach.
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).
Not Python, but there are a few Rich Internet Application (RIA) frameworks you should look at if you don't want to do low-level HTML/CSS/JS work (still the most common approach, mind you). GWT is the most popular, but probably only worth using if you're Java-fluent. Here are a couple of others:
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:
Finally, if you do wind up working at the JavaScript level, I strongly recommend that you try CoffeeScript, which has a very Python-like syntax yet compiles directly to JavaScript. I've used it with jQuery for some pretty complex apps, and it's definitely made me a lot more productive:
Be very wary of SproutCore. It is not only a Rich Internet Application framework. It is also a MVC framework in javascript, which adds a lot of complexity to the design (mostly when compared to GWT and cappucinno).
On the other hand, its designer tool is the only free one among javascript frameworks. However, it is quite new, and a bit buggy.
Not that I have a dog in this race, but sometimes seemingly arbitrary convention can be exploited. For instance, some pioneering lad[y] might be compiling a collection of Ask-HN-questions. It's easy to see why it would be nice to have "Ask HN" in the title. Convention implies "easier to parse", and that makes programmers happy.
Not everyone uses the web interface. For instance, I read HN via RSS. If I see a post without "Ask HN" or a similar prefix, then I expect to be taken to an article. It's a useful nicety.
I'm currently evaluating WT (www.Webtoolkit.eu) which is the C++ equivalent of GWT. I noticed that WT examples were much faster than GWT's examples on my iPad. For python, I think Django should be the way to go.
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.
Although you're a Python hacker, you may want to save yourself some time and use NOLOH (http://www.noloh.com). It handles most of the aspects of development that usually distract you and let you focus on your core application. It features a lightweight and on-demand core that offers cross-browser compatibility, automatic AJAX, search-engine-friendly, numerous syntactic features to make developing in it a joy, and much much more.
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.
I'm a Mootools fan myself. I use it over the seemingly more popular libs like jquery because very little of my JS code is actually touching DOM. I usually start my projects by creating all my "classes" (actually prototypes, etc, but classes make sense to most OO people).
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)
I'm working on a neat project to integrate pylons with pyjamas for this very task.
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.
I think you could limit python for server tasks(data read/write, security and authentication).
We use Erlang for that.
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.
I don't remember where I read it, but you're only a true hacker if some arbitrarily large enough community has bestowed that label upon you. As of today, hacker is almost synonymous with programmer, and people who can compile a C++ program sometimes think themselves as 'hackers'. It's kind of sad, but I don't really care. The media has long since killed the term for general usage.
ESR's "How to become a Hacker" guide lists:
"Has a well-established member of the hacker community ever called you a hacker?" as a requirement. I guess that's what you were thinking of.
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
The term "hacker" has become so diluted by forums like this one that it's totally meaningless. Calling yourself a hacker at this point is just a form of self-aggrandizement.
GWT is certainly a very useful tool for rich client web applications. If you are familiar with Java, it might be the quickest way to start building very complicated javascript based interfaces.
You need JavaScript, and though there are lots of libraries that make things simpler, you'll need a good understanding of JavaScript and preferably have a good understanding of the DOM as well.
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.
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.