Mail.app on the web

Mail.app

ukijs matured and I put it to the test. The idea for the test was to replicate Mac Mail.app core experience in the browser. With as much attention to details as possible and acceptable performance. The whole thing took me about 15 hours and 65kb of gziped code.

Motivation

We’ve seen a tremendous paradigm shift in the last year. Desktop experience on the web is going mainstream. The very existence of SproutCore and Cappuccino proves that you don’t have to sacrifice user experience on the web. And yes, you can write desktop class web apps without a team of 10 developers.

But there’re two things that I don’t like about these, otherwise awesome, frameworks. First they’re huge. They even brag about how huge they are: “…20k lines of code…“, “…100k lines of code…“. Second there’s a fair amount of “magic” involved in building your app with any of them. In case of Cappuccino you have a completely new language (Objective-J). SproutCore will “magically” create bindings and magically process your css.

What this basically means is that you have to do more: read more source, learn more conceptions and tools, support more code, fix more bugs. And your users have to wait more for your app to load. And I think we can do better. That’s why uki was started. The main goal and the promise behind the project is that you can create desktop-class apps with less code and less magic.

And so far uki is pretty close to the promise.
1. There’s no magic involved if you want to use the framework. Simply add a

<script>

tag to your page and you’re done. And you write in plain old javascript.
2. The whole framework gziped with images included (base64 encoded) weights 35kb. For comparison SproutCore is 150Kb without images or styles.

There’re two notable things about less code
First ukijs leaves to the browser what it can do by itself. Without any additional conceptions/code in-between. For example if you’re with SproutCore/Cappucchino and want to bind a focus event you’ll end up with something like this:

view.didBecomeFirstResponder = someHandler

while in uki it looks like:

view.bind('focus', handler)

or even simpler

views.focus(handler)

Second I do a fair amount of meta-programming. The same that you’ll see in jQuery core:

How

Uki is an application framework. So there’s no HTML. All interfaces are build with javascript. And js will manage focus, selection, scrolling, layout, events for you.

There’re 4 common parts of an application: views, layouts, models and controllers.

Views are the basic building blocks of the interface. Uki comes with a collection of core views but you can add more or extend existing. Examples of views are: Slider, SplitPane or Table.

Layouts define how your views are placed on a page. Mostly the same way as HTML defines how your DOM nodes are placed within each other. But since you’re building the page from a complete interface components it is usually much much shorter. Look at the example of the main mail.app page.

Models store, load and transform the data from the server. You can stick to plain javascript objects but it is more convenient to add some behavior to your models. Like

message.markAsRead()

method. Models also trigger events when their data changes. So you can

message.bind('unread.change', handler)

Controllers bind everything together with events. You find views in the layout with css like selectors and then bind event handler to them. See the main page controller example.

This looks like the perfect missing piece we need for Amahi, the home/small biz server. It’s one of the most frequently requested features. We can easily take care of the backend infrastructure and make this the front end.

I wonder how far is it from being actually a usable app (i.e. how much is it still a prototype). Anything we can do to help finish it?

Cool. Sure it is not possible, but it would be very cool if there was a way to port the app to become the web interface for Snow Leopard Server’s mail server. The current squirrel mail web interface is primitive in ways that are long overdue improvement.

I am very impressed by the performance and speed of this UKIJS Mail.app.

Just wondering whether full functional communication of mails between client and server will take you extra times or not, if no big framework (both server and client side framework) is used.

BTW: I have implemented a Gmail-style web mail client ( http://demo.java2script.org/mail/ or http://kexmail.com/ ) some months ago. It took me about 7 days or so to implement both client side and server side. In my implementation, UI designing and event binding cost most of my time. As I were using Java2Script framework ( http://j2s.sourceforge.net/ Ya, a heavyweight framework with a little poor performance ), implementing the server side based on SimpleRPC and JavaMail did not cost too much time. But supporting all kinds of mail servers and protocols do cost some extra time.