Trying Google Web Toolkit again – and liking it

Development, JavaScript January 11th, 2010 @ 11:01

A while back, I tried out Google Web Toolkit to see if it was any interesting. My main concerns after that early glance was the stability of the applications and the possibilities to mix GWT code with plain JavaScript code.

Giving it another stab

I decided to give it another go last week, when re-building the mixtape interface for my side project Spotiseek. A few things led me to creating an “Ajax” application with GWT:

  • quite a few requests are required to present the view – I needed the requests to be cached in the client to reduce the server load
  • I needed an application built on stable and easily maintainable code
  • I figured it would be a good chance to learn more about GWT
Spotiseek Mixtape based on Coldplay

Spotiseek Mixtape interface

Drawing some conclusions

After completing the first release of the new interface, I feel confident enough to draw a few conclusions:

Positive: It’s Java!

When looking to write stable and easily maintained code, I really can’t find any better candidate than Java. Since I’ve been working with Java for a number of years, I’m of course very comfortable with developing GWT apps.
The syntax is nice and clean and of course the magic of the fantastic IntellJ IDEA is indispensible.

Positive: It does what I want it do do

It might appear a ridiculuous header, but I have to say it’s very easy to create widgets that does exactly what you want. There’s little confusion on how to actually construct the application.

Negative: Problematic project setup in the IDE

Even though IntelliJ is a fantastic IDE, there’s appearantly some improvements that could be made to the setting up of GWT projects.

Just setting up a GWT project is not a huge matter, but trying to add a GWT project module to an existing web project was a lot of hassle. There was a lot of problems getting the built-in build/make process to put the files in the right place etc.

Negative: Surprisingly poor community support

I honestly thought that the usage of GWT would be more widely spread across the internet. But when I – from time to time – got stuck with an issue, there wasn’t really that much help from Googling.

There are of course a few good forums and such where many questions are answered, but unfortunately not the answers I was looking for. I had to dig deeper in the Google documents in  order to get enough info to draw my own conclusions.

EDIT: One nice resource I’ve found is Matt Raible’s blog.

Maybe it’s not inadequate for most issues, but I had expected more…

(Sort of) Negative : Building everything from scratch

Usually, you try to mix as much HTML and JavaScript as possible in order to write code more efficiently. Building it all up from scratch is often a quite expensive process and rarely gives you the most maintainable code.

But with GWT I didn’t really see any way of not building everything from scratch. Partly because it’s very easy to do so, but also because I didn’t find any good way of reusing existing HTML components.

I’m not sure it’s a true negative having to build everything from scratch, but it requires a somewhat different approach than you might be used to.

To sum it up…

Even though there was a few problems during the development, I’m glad I chose to develop the application in GWT. It’s resulted in a nice (enough) application, built on code that is stable and easy to maintain.

Also, I’ve learned a lot about GWT development and will have no problems going forward with the development.

(Apart from the conclusions I’ve drawn, there’s of course a bunch of positives that comes with developing GWT applications. )

Maybe not suitable for all products

As I’ve stated before, I still feel that you should always consider if GWT is the best approach for your particular application.
I guess a certain amount of complexity is required, as it’s probably more tedious to write GWT Java code than regular JavaScript. If you’re going to develop a small-sized application, you’re probably best of doing it the old fashion way.

SEO issues with JavaScript applications

Of course, there are some issues with building your applications in JavaScript. One of them being the drawback in Search Engine Optimization (SEO), as your content is hidden from the indexing robots.
I know Google have proposed a new standard for specifying JavaScript content, in order to make the robots understand how to activate the content. But we’ll see what happens there…

1 Comment »

Sometimes you’re just an honest guy trying to script

JavaScript May 27th, 2009 @ 18:05

Today, I ran into some JavaScript security issues that cost me a few hours too many of my life.

I wanted to show the user a confirmation message when closing a pop-up (OK I know, but sometimes you just got to use them!) to make sure he doesn’t lose any data when leaving.

But we can do this! Right…?

This isn’t really any big issue, as the onBeforeUnload event can be used for these exact scenarios, with a nice message too:

window.onbeforeunload = function (event) {
    // message to display (in between the standard message provided by the browser)
    return "Leaving now will have you lose everything."
};

The special case here was that I had a SWF running in the window, which needs to be unloaded (close its connections etc) when closing the browser window. That has to be done in the onBeforeUnload event as well, since it’s too late when we’re at onUnload.
The problem is that there’s no way of knowing what the user answered to the question arisen from onBeforeUnload, other than finding out when the event’s traveled onwards to the onUnload event. By which time it is too late.

So I ended up in a situation where everything was fine if the user decided to keep the browser window open (“Cancel” in the confirmation box), but should he close the window – which is fine too – I had no way of closing the connections etc in the SWF.

But why?

The reason to this is of course a security matter. Some clever fellas have set some restrictions to what you can do with Javascript to avoid misuse, for example extreme annoyance with pop-up ads or such. There’s nothing wrong with that.
But sometimes you just want to yell to JavaScript’s mom and tell her that I’m a perfectly honest guy trying to make the world better for my users! :)

What would’ve helped me

So what do I want, then? Well, it would’ve been nice if I could’ve gotten an answer from the confirmation box rendered with my custom message (“OK, leaving now…”).
It’s perfectly fine that the unload event cannot be stopped once the user’s said “OK, close”. But at least I would’ve wanted the chance to act upon the user’s choice before the document was unloaded.

So my final solution was just to warn the user that everything was hitting the fan, and at the same point notify my SWF that it was to be unloaded etc. It’s an OK solution, but not perfect from a usability perspective…

End of rant.

Make the first comment

Premature optimization is the root of all evil

Other April 24th, 2009 @ 10:04

From time to time, discussions pop up on how to optimize your code. “Create your arrays like this”, “define your variables like that” etc. Today I read a blog post by Sean Moore, summarizing a lot of (alleged) performance optimizations in AS3. It contains quite a few incorrect points, but probably serves quite good as a place to find out the truth behind some optimization myths. There are a few interesting comments in the “comments section”…

Anywho. My opinion is that you should rarely bother to do this kind of micro optimizations of your code. Maintainability and readability of the code is way more important, especially in larger products as those we’re working on. People should put more effort in that area, than saving a nano second here and there. (Also, there’s often far better places to optimize the code than in variable declarations and arrays…)

I hate it when I come across code like this (JavaScript in this example):

var i = 0, j = 1, k = 2;

… as opposed to the more human readable:

var i = 0;
var j = 1;
var k = 2;

There’s no real reason what so ever to write code like that! It just makes it harder to read and maintain.
I guess maybe that’s why I’m not a preacher of the chaining madness in jQuery…

(The headline is a quote from Donald Knuth, which I think applies to any programming language, at least all of those I’ve been working with).

Make the first comment

Is jQuery really that awesome?

JavaScript March 11th, 2009 @ 10:03

There is (and has been for a while) a lot of buzz around the JavaScript framework jQuery. It’s even gone so far that people (mainly softcore developers or non-developers) have started referring to Javascript/AJAX features (animations etc) as “jQuery features” (maybe not that wording, but in concept).

I guess one reason for jQuery being so popular is that it’s pretty light-weight and contains both useful “core” functionality, as well as easy ways of creating transitions/animations. It’s got a pretty wide and deep range of functionality.

Prototype and YUI are my old friends

I’ve mainly been using Prototype the past years and think it’s an awesome library. It’s got great functionality for traversing the DOM, handling AJAX requests and so on. But doesn’t have any easy-to-use fade or scrolling effects. That’s probably a great advantage of jQuery: it can be used for pretty much everything within a site.

I addition to Prototype, I’ve been using YUI for animations, widgets etc etc. Truly a great library too, but maybe a bit too heavy…

Now I’m not saying that Prototype in combination with YUI is the perfect solution. It’s a good enough solution, given that Prototype’s core features combined with YUI’s widgets are quite powerful. But combining several libraries can never be a truly good thing in the end, as it can get a bit confusing what to use where in the code. Also, it could make it more difficult to update to new versions.

It’ll be really interesting to see what YUI3 can provide us with, though! From what I’ve understood, it’ll contain all the nice widgets provided by today’s YUI, but slimmed down to less and more effective code. Maybe it can prove to be the ultimate library?

Don’t chain ’til you drop!

Now I haven’t been using jQuery to any large extent (yet), but there’s one thing that’s annoying me so far:

The overly excessive desire to chain everything into one line of code (OK, maybe that was exaggerating, but sort of…). Chaining code can be nice and make code more effective, but there’s only so much chaining you should do. Otherwise, your code will only be more and more difficult to read, while saving a few fractions of milliseconds here and there because you didn’t create a new var.

A colleague of mine came up with a good suggestion to only chain as far as the starting reference is needed. Meaning, if you’re performing actions on an element, you should only chain until you stop using that particular reference.

Example of some crazy chaining:

// clear foo, update text, create a clone and update its text
$("foo").empty().text("foo-text").clone().text("foo-clone-text");

Instead, this is how it should be written to understand what it does:

// clear foo and set text
$("foo").empty().text("foo-text");

// create a copy of foo and set text
$("foo").clone().text("foo-clone-text");

Now, maybe that wasn’t a perfect example. But my point being that chaining is OK as long as it’s easy to understand in what context the code is applied. Otherwise you’ll just confuse everybody else, and in the end yourself as well.

So what am I saying?

All in all: jQuery is a great JavaScript library. I’m not buying the hype to 100% and I’m not liking it enough to say that I’ll start using it instead of Prototype just yet, but as their community is so large, there’s obviously a good chance that they’ll keep evolving to something even better. Large and good communities are often an important thing when it comes to these things.

We’re currently only using jQuery sparingly in a couple of our products, so I will have more to say after we’ve evaluated it a bit more.

When I chose to use Prototype over jQuery, I did it because it was considered the best library at that point. It’s interesting that it can change pretty quickly: today, jQuery is considered the best and fastest library out there. Maybe it’ll change again…?

4 Comments »

A first glance at GWT

JavaScript March 9th, 2009 @ 15:03

Web applications of today are often required to be quite complex – AJAX offers lots of nifty ways of giving the user a great experience. But developing stable applications using lots of JavaScript code can be quite challenging. Even though there’s help from great libraries such as Prototype, YUI and jQuery, it’s tricky to keep the code bullet-proof and fully tested.
Also, it can be difficult maintaining a decent architecture as the application grows, i.e. how to implement an MVC solution.

There’s of course a few people out there trying to address these issue, one of which being Google Web Toolkit (GWT).
We’ve discussed GWT from time to time, but haven’t really made a true effort of delving into it. I decided to try to find out how it really works and if it’s something for us to use in our applications.

Do we really need it?

I guess the first question you need to ask yourself is if you really need anything like GWT. Is our goal to build a full-feathered AJAX site without any browser reloading of pages? Do we want something with features like Gmail (from dialogues to rich-text editors)?

After researching GWT for a while, my feeling is that you either fully implement it (with effects on server-side and all) or you stick to using “old, self-developed” Javascript code. If you’re to have any kind of client-server communication (which you are), you’ll probably have to make some adjustments on the server-side as well.

Anyway… I tested a sample implementation usin GWT and as a Java fan, I was of course enjoying writing nice, strict Java code with full IDE support instead of regular JavaScript. There was really nothing to complain about when it comes to writing GWT code and it was fairly easy to get started and the compilation was quick enough and provided a nice debugging tool.

Are there any limitations?

My main concern is that using GWT will come with some limitations:

  • What if I don’t what to write the code exactly like it’s done with GWT? Will I have to write all my code using GWT?
  • How painful is it really to mix “regular” Javascript with GWT code (they offer a way of doing it, but it doesn’t seem like something you’d really want to do)?
  • Is it really stable enough for an entire application/game? To be honest, the GWT site itself is actually quite buggy…

One nice feature that comes with GWT is the support for creating modules. It seems quite easy to create a smaller module (perhaps a text-editor) and plug it in to your application. I’d say that doing so would be a first good test of GWT, as it still feels a bit scary to rely on it for an entire application (i.e. creating entire pages, browser history states etc).
Maybe using it for smaller modules the best use of GWT in our case? It would be really nice if server-developers (Java guys) could implement advanced client-side features without being afraid to mess it all up… :-)

To sum it up…

I guess these questions never will be answered unless I/we actually try it out in a real implementation (or at least a real-enough prototype). There’s obviously a whole lot of things with GWT that is really nice, but I wouldn’t feel fully comfortable relying on it as of today. Trying it out in a module or two would probably be the best way to draw some real conclusions.

In the end, it’s all about what you and your product really need.

References

Google Web Toolkit Website

GWT in Practice – Ebook (lots of reading)

Ext GWT Library (great widgets)

Unofficial GWT blog

2 Comments »

Changing page without reloading browser

JavaScript March 6th, 2009 @ 13:03

I wanted to investigate if we can build web applications that doesn’t require reloading of pages in the browser, according to the principles of  Life above the Service Tier.

Evaluation

I started by reading the “Life Above the Service Tier” document, which was a description how it works today (and its flaws) and what the proposed solution is.
Also, I browsed the web for more articles, blog posts and comments on the issue.

Summary

The ideology (called SOFEA: Service-Oriented Front-End Architecture) is basically to put more rendering logic on the client side and only use the server side to transport data back and forth.

The principles of SOFEA could be implemented with help from AJAX. The controller resides on the client-side and is responsible for loading (XML) data and rendering the application using the received data, without actually reloading the page in the browser.
This means that JavaScript would be used instead of HTML/JSP to render the server data. Also, the server-side is much thinner and not really in need of any web framework (as all it does is receive messages and return XML data).

Conclusion

The principles of SOFEA seem very far away from today. There are several flaws with implementing in the suggested manor:

  • The web clients (browsers) of today are not good enough to handle could have problems handling as much logic as a large web site would require (given that old IE versions have so many users, ca 70-85%)
  • The client code (JavaScript) and architecture is not really mature/good enough to handle this much logic, given that it needs to be bullet-proof, easy to test etc (EDIT: unless using GWT or similar – it’s at least difficult to manage)
  • Developing applications would take much more time (hence be more expensive) as more manual labour is required to render content using JavaScript instead of letting the JSP engine do it with JSP/HTML/PHP/etc

Everything points to NOT implementing it in such a manor. At least not at this time, partly because the browser/client market isn’t ready for it.

Is there an other way?

Yes, there are other solutions to the main issue; changing pages without actually reloading the container (browser).

One suggested solution could be an extension to our model in Taikai, where AJAX can be used in combination with both XML, HTML/JSP and JSON, hence giving us the possibility to smoothly serve a full JSP page using AJAX.

A brief description of how it could be solved:

  • Make a JavaScript “controller” handle all URL requests to the server, in order to bind the answer to a certain action.
  • Set up “View XML files” for all views that are to be loaded with AJAX. The view could look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<xmlRoot>
<title>Document title</title>
<styles>
<src>/css/foo.css</src>
<src>/css/bar.css</src>
</styles>
<scripts>
<src>/js/foo.js</src>
<src>/js/bar.js</src>
</scripts>
<content id="targetContainerId">
<![CDATA[<jsp:include file="foo.jsp" />]]>
</content>
</xmlRoot>
  • When returning the response from the server, the returning page would be the pre-defined XML (as per above).
  • The controller parses the contents of the returned XML file and performs its magic:
  1. Changing the document title
  2. Loading new styles and scripts (and possibly unloading old ones to keep the page slim)
  3. Updating the content element (with id=”targetContainerId”) with the provided content, which has been rendered by the JSP engine and therefore taking advantage of its power (i.e. JSTL, HTML tags etc etc).
  4. Updating the browser history using hash (#) technique, allowing for back/forward movement while remaining in the same page container

The main advantages with such a solution would be:

  • Allowing developers to create content using known and powerful formats, such as HTML and JSP
  1. Very important in respect to time efficiency
  2. Still allows for easier debugging and development
  3. No need to put too much logic on the JavaScript side, i.e. creating elements etc (although it could still be done in some components, if needed/wanted)
  • Still providing the user with the quicker experience of a site without (or with few) full page reloads

Remaining questions:

  • Would there be any risk of memory leaks, especially in older Internet Explorer browsers? And is there an easy way of eliminating these?
  • Is the support for “hash history technique” good enough in all major browsers?

References

1 Comment »

JavaScript profiling in Internet Explorer

JavaScript March 6th, 2009 @ 11:03

Hello,

Here’s a long (but hopefully interesting) post about JavaScript performance in Internet Explorer. :-)

As I had some time over in between sprints, I started looking at the performance of our site in Internet Explorer again. The webapp runs very smoothly in Firefox, but some pages take a few seconds (!) to load in IE, due to its “JavaScript density”. In order to find out what we’ve done wrong, I decided to test changing our core JS framework from Prototype to jQuery. Although, this (alone) didn’t result in any noticeable improvements (in short: there’s been a few tests claiming that jQuery is X and Y times faster in general than Prototype in IE).

There wasn’t (and isn’t) any obvious parts of the code that would slow down the site in IE alone, so I decided to try to find the methods that were slowing it down. To do that, I needed a profiling tool. And finding one of those for usage in IE wasn’t easy (in FF you can always use Firebug’s profiling tool).
After some research, I found:

* AjaxView
* JavaScript Profiler 2.0

None of them gave me the result I wanted, as they provided little or no information on what was actually running slow (although it did show me indications of total mean times).
I knew when I started that YUI provides a Profiling tool, but my first priority was to use a standalone client to avoid having to alter my code. But with no other choices, I decided to try it out, and that was obviously a good choice. I read the docs of YUI Profiler and ProfilerViewer and tested them. Reading and setting up the profiler took about 15 minutes.

The thing about using the YUI Profiler is that you have to manually add the methods to profile, but it was an easy task and probably better/more efficient than profiling everything (as Firebug does) since the noise is heavily reduced.

After a while, it was pretty obvious which methods were running slow in IE (note that they were barely tracked in FF); some basic methods took up to 900 ms at first.

Worst methods from my first profiling iteration:

Function Longest (ms)
1 2 3 4 5 Avg
updateTotalStats 922 828 891 984 875 900
roundBrowser.setup 843 675 687 875 735 763
initBetProgress 563 656 703 563 859 669
initLocaleSelector - - 703 563 859 669

After iterating “optimizing-profiling-optimizing-profiling” for a while, I managed to reduce the load times with about 40%, without losing any real feature. It was mostly about modifying CSS selectors (i.e. removing one level in the hierarchy) and making sure some methods were only run if they really had to.

Results after optimization:

Function Longest (ms)
1 2 3 4 Avg
updateTotalStats (1) - - - - -
roundBrowser.setup 110 125 125 141 125
initBetProgress 62 63 78 62 66
initLocaleSelector (2) 0 0 0 0 0

1) Removed unnecessary call
2) Moved initialization to click

Note that the counts aren’t necessarily 100% correct, as several other factors affect the load time (current memory usage etc).
But anyway, the results were massive and the load times were heavily decreased.

So to conclude:

As mentioned. it’s not always easy to know which those methods are by simply looking at the code (IE always tricks us…).
All “JavaScript dense” pages should be profiled (with YUI Profiler until a better tool is found) in order to find methods with poor performance.

More or less interesting articles/documents on the subject:

http://blogs.msdn.com/ie/archive/2007/08/23/Analyzing-Web-2.0-Applications-with-Ajax-View.aspx

http://research.microsoft.com/en-us/projects/ajaxview/ajaxviewusage-1.aspx

http://www.whitefrost.com/documents/html/technical/dhtml/monitor.html

http://www.newearthonline.co.uk/index.php?page=article&article=338&pagenum=2

http://msdn.microsoft.com/en-us/library/bb250448.aspx

http://www.ajaxperformance.com/2008/02/20/yui-profiler/

http://www.titosoftware.com/

http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx

http://blogs.msdn.com/ie/archive/2006/11/16/ie-javascript-performance-recommendations-part-2-javascript-code-inefficiencies.aspx

http://blogs.msdn.com/ie/archive/2007/01/04/ie-jscript-performance-recommendations-part-3-javascript-code-inefficiencies.aspx

http://dev.opera.com/articles/view/efficient-javascript/

2 Comments »