Frisky is merging into magnum

I created a web server to experiment with some concepts about a WSGI web server. The other day read about magnum which is the exact same concepts but with a much cleaner implementations. I was planning on spending the holiday rewriting Frisky to something usable. It is nice to know that there are some like minded people out there. I will now be taking the features that I experimented and ended up being good and rewrite them and submit my patches to magnum.
Once I can get my existing software working on magnum I will sunset Frisky. Based on the conversations I have had on the magnum mailing list magnum will be faster and better implementation of the same concepts soon enough. The collaboration will do me good I am happy to get out of my cabin in the woods.

Picking Javascript Web Framework Poison (YUI and GWT)

This is the second blog I wanted to write about javascript web framework. The first post I wrote covered what I called "lightweight" frameworks and this I plan to cover "heavyweight" frameworks.The heavyweight frameworks that I have been working with are YUI and GWT. The heavyweight frameworks    longer learning curve and a problem that requires more complex UI.

YUI
For the last six months I have been working on a couple projects using YUI. The set of UI widgets that YUI supports are very impressive. YUI is very fast to develop in. One of the projects I am working on has tons of dialog boxes, data tables and other thick client features which YUI makes dead simple and quick to use. Yahoo using this for there main site has made it very easy to support multiple browsers. For me this is perfect for a project that has lots of features.

GWT
Recently I have started to learn Google Web Toolkit (GWT). The amazing part of GWT is that is is optimized produced per browser optimizations. Since you generally don't write any javascript just Java which is compiled into Javascript the code will be cross browser compatible. The largest downside is learning curve because if you don't know Java (first language I taught myself) it is going to be painful. However the UI widgets are nice and it is blazing fast. This is on the high end of the framework however the effort is worth it if you are dealing with high volume of users or you need as fast an application as possible.

To GWT or to YUI?
So it comes back to combination of the needs of the project. My guess is that most of the time either having the skill set of Java or getting developers to learn Java to use GWT will not be worth it. If the project is significant volume of users (IE browsers) because I think performance is alway a critical aspect to user experience then GWT is the way to go. Most application start small and don't have the resources to use GWT so I would think YUI is a better choice.

Tool for the Job (IMO):

• jQuery - small simple quick application that does not need a lot of AJAX
• Dojo - I don't think there is really a need for something between jQuery and YUI but there might be if a project developers already have experience with Dojo and the project is pretty small
• YUI - A good size application and I think the majority of projects fall under. Probably the most useful framework in the group to start a project on.
• GWT - end all be all (currently) I think the most ideal solution if the resources allow for it because the end user gets the maximum performance. 

Picking Javascript Web Framework Poison (jQuery and Dojo)

This is the first in a two part serious that I wanted to document my experiences building a web application with different frameworks. The first part I will talk about my experience with two of what I call "lightweight frameworks" and then the second blog I will discuss the two "heavyweight frameworks". I will not be covering any of the why use a framework in this or discussion about user experience however if you are not concerned about user experience and using a framework to support the X number of browsers out there then dust off you resume you are going to be looking for work soon.

Lightweight vs Heavyweight
All though all of the javascript frameworks I am going to write about you "can" do the same thing some make things easier than others. In fact I believe that there is a spectrum based on the user interface of the application I am trying to build or said better "the right tool for the job". Also some other consideration are prototyping and one offs.

jQuery
jQuery was one of the first javascript frameworks I used. Mainly because of how simple it is to use and how much I was trying to avoid writing javascript. My favorite feature with jQuery is how terse the syntax is. This is probably why I like Python so much over Java just the speed of getting simple easy things done. jQuery is great for doing all kinds of simple DOM traversal and manipulation. There are a lot of plugins for doing all kinds of other things however I have found the jQuery UI and a lot of the plugins much to be desired in ease of setup and functional (cross browser ect).
Dojo
Dojo was another framework that I followed and managed building a rather large embedded project with it. Mainly because at the time the support for UI windows and things was much better. The syntax is kinda bloated and it takes some time getting things setup and coding but once you have the compile process working well it was very stable and functioned extremely well.

Picking Poison
As I have already mentioned it depends on the project. I would choose jQuery for any project that is mainly content but needs some simple quick DOM manipulation and maybe use of a plugin or two. The full UI is usable and I built a prototype with it but there was more typing and cross platform issues than I wanted. Dojo is kinda the next step in the spectrum if you have a product you need just a small amount of UI features like the occasional dialog box or small amounts of embedded pieces. Dojo I found to be a bit slow at times even with all the compression tools they have. I generally don't use Dojo any more because I use jQuery for simple things and use YUI because ... well that is the next blog .

Adventures in Event Everywhere

So yeah I am smoking the event system though and though. Javascript based on around event system that is directly sending and receiving events to and from the backend. Which is also sending and receiving events from/to the front end. Of which it just has a bunch of event handlers which then create more events that are sent back to the front end, handled by the backend or stuffed on a message bus....

STOP!!!!

Why would anyone in there right mind every do anything like this? One of the problems I am reminded about a lot is that large software gets complex. And trying to keep everything in my head at once doesn't work. I need to break things down. More over I need to have a clean way of slicing up the functionality. The second part of this is that modern applications have server side code and client side code of which they are usually two different languages if not more because of the many mobile platforms ect. So I also would like a clean way to communicate between languages. So both client and server side can agree a protocol of events and data that is going to be passed for those event. Then both client side and server side will write event handlers for all the communication code. This is easy to quickly write communication wrappers that just call function / methods that have registered for event(s).

Pros:

• Simple (conceptually and implementation)
  
• Cross platform
• Design works well with both front end and backend development
• Protocol is quick and easy to be agreed on by developers
  

Cons:

• RESTful urls are bit strange they can be generated based on event names but won't be as clean
• If you don't like event programming then you will hate this
• Can be difficult to debug with many listeners to a single event

At the moment I am thinking about pushing this system into a repository on bitbucket.org since I have Javascript, Flash, Python and Java bindings for it. I think I even can create a C which would cover C, C++ and Objective-C (Iphone).