Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘angry birds

Accpac, GWT and other Web Technologies

with one comment


Last weekend I travelled down to Seattle, Washington for a nice getaway weekend and to see the Science Fiction exhibits at the EMP.  Then on Monday night I gave a presentation to the Seattle GWT Users Group on Sage ERP Accpac’s use of the Google Web Toolkit (GWT) in our 6.x product line. I found the group to be really knowledgeable and they asked great questions throughout the presentation. I learned a lot from the meeting and from chatting with the various people attending. Definitely very worthwhile. I previously blogged about Sage ERP Accpac’s use of GWT here.

Games on GWT

id Software makes many of the most popular first person shooter games including Doom, Quake and Castle Wolfenstein. Their lead programmer is John Carmack who is a legend in the gaming industry. One of the cool things they do is release the source code for some of their older games. They also port their games to various platforms, so often there will be an OpenGL version as well as a proprietary version, and perhaps a version ported to Java as well as the original version in C. A key metric of new computers, operating systems and devices has been how well they run the open versions of these games. I was really impressed when Google ported Quake II to GWT. Seeing Quake II work really well in the Chrome browser just using HTML5 was really really impressive. To me this really showed the power of the Browser as an application development platform, that if you could get Quake II running with a reasonable frame rate, then getting ERP screens going should be a piece of cake.

Of course the times have changed and Quake isn’t the most popular game anymore. So I was really surprised to see the latest hit game, namely Angry Birds ported to GWT. Angry Birds originated as an iOS game that has been hugely popular on iPhones and iPads. Angry Birds has perhaps more than anything been the killer application that has driven people to these devices. Of course Rovio wants to capitalize on the success of the iOS game, by porting it to other platforms. The easiest way to do this is to port it to HTML5 so it will work on all platforms, rather than doing separate ports for Android, Windows, WebOS, Blackberry, etc. For some more details on the porting of Angry Birds to GWT, have a look at this blog. GWT seems to be becoming quite a good technology for developing HTML5 based games. Many people are predicting that doing separate ports to all the mobile platforms, desktop platforms and game consoles is already way too expensive and most game development houses are looking to solve this with HTML5. This won’t work for all games, but it will work for many of the popular classes of games that are so popular these days.


Cascading Styles Sheets (CSS) are a fundamental part of the Web today. All Web Sites use CSS to some degree to control their appearance and layout. Knowing and using CSS is a fundamental skill required of all Web developers. However CSS can be quite hard and quite tricky. When we use GWT it solves the problem of JavaScript differences between the browsers and does a really good job of this. However GWT only makes sure that you can use CSS, it doesn’t help you write it and it doesn’t shield you from Browser differences. There is a CSS version 3 standard that everyone purports to support. However support for this standard is variable across the different browsers. Generally for what we are doing, things work great in Firefox, Safari and Chrome. But then they break down in IE. Plus the support is quite variable across different versions of IE and since MS doesn’t support all versions on all their operating systems, software vendors get stuck supporting several versions of IE, all with different CSS bugs and omissions.

Fortunately we discovered an open source project called CSS3Pie which fills in many of the gaps missing in various versions of IE’s CSS3 support. What CSS3Pie does is recognize the version of IE and when CSS is processed, if IE can do it correctly then it lets IE handle it. But if IE can’t do it then it performs the operation for IE using JavaScript. I hope the Microsoft programmers on IE’s CSS handling team see this project and feel bad seeing how others implemented what they claimed was too hard.

When we started moving our Accpac screens to the Web we did all the layout using DOM layout nodes (which are abstracted as layout controls in GWT), but over time as we’ve become more proficient in CSS and now that we don’t have to worry so much about IE’s deficiencies, we are actually doing much of our layouts using CSS. This tends to lead to finer control than you can obtain using layout nodes so we can refine our look and feel to a higher level.

Asynchronous Programming

One of the reasons we chose GWT as the foundation for our new Web UIs, was that GWT was all about AJAX fundamentally from the start. AJAX wasn’t tacked on later to a system that was really from the Web 1.0 days. The support for AJAX in GWT is really great; but, our programmers coming from the VB world sometimes have trouble wrapping their heads around it. One of the fundamental differences between programming for the Web versus Client/Server is the issue of latency and how this accumulates as messages move across the Web. As the Web has progressed we now have tremendous bandwidth; so there are services that can stream a 4Gig movie to you in less than half an hour. However if you need to send a message across the Internet and wait for a response, it might takes 100ms which is still really fast, as long as you are only doing 1 message. If you do 10 messages then it takes a second, 100 takes 10 seconds, etc.

Programmers used to client/server programming on a LAN that probably spans only 1 building, don’t have to worry about this. Their latency is less than 1ms and they can make 1000 calls to the server without annoying users with a delay too much. As client/server programmers move to the Web there is a strong discipline required that if you have a process that require 10 server calls, then it must be re-factored to only require 1 call. Within our SWT framework, we make it easy to make 1 call, but don’t provide any help to string together multiple calls. This is intentional. Then we provide a good framework for our programmers to move “bad” code from the VB UIs into server classes where they can make many calls without penalty.

Perhaps the point here is that you need to do this independent of the Web programming framework. GWT has good support for AJAX, but it falls to the application programmers to use it correctly and this mind set change is really a function of moving to the Web rather than the choice of Web technologies.


Sorry if this blog posting is a bit disjointed. This is really just some thoughts based on discussions at the GTUG meeting on the pros and cons of GWT as well as adapting to other general Web programming models.

Written by smist08

September 24, 2011 at 10:21 pm