[messages] [Developers] Re: Roadmap for VASSAL 4

generateui rtimon at gmail.com
Sun Mar 27 08:43:01 MST 2011

> wxWidgets suggested by Michael looks like a good cross-platform
> framework. It looks to me like higher level entry for developers
> though, so I don't know if the developers could/would make that step.

First of all, wxWidgets is indeed cross-platform, but: it's still
__platform dependant__, as currently every UI library is platform
dependant. Namely: wxWidgets is dependant on the wxWidgets platform.
This may sound a bit weird, but the current state of UI toolkits is that
none of the toolkits/libraries implement a set of standardized
interfaces. Truly platform independance would be achieved by having a
set of interfaces for widgets/behaviour defined, and then implemented in
the various libs/toolkits. Example: Say I make a login window. I *HAVE*
to tie the code in the loginwindow to the UI lib. I cannot define an
instance of interface Button. Instead, I have to define wxButton, or
gwtButton, or javafxButton. If I'd be able to define a 
private button Button;

, i can have the instance of the button be polymorphic. 

> Please don't consider JavaScript, it's great for scripting web pages,
> but not for complex applications like this. JavaScript is interpreted
> code, so you will get a huge performance hit from that alone. You'd
> also need to use some other means for the "GUI" with JavaScript, so
> you'd end up with browser dependent display code (DHTML/CSS) which
> breaks every few months with updates. Despite the hype nothing serious
> gets written like this. You have web games, but they are either flash
> and/or very very simple. There is google apps, but although nicely
> done, they do nothing as complex as VASSAL. HTML5 adds a lot of
> features, but is far from final and there is inconsistent support for
> it. Instead of JavaScript you could write an application in Flash/Flex
> or Silverlight (ZunTzu 2 is planned to use Silverlight), but the step
> to just making a desktop app with much more flexibility in what you
> can do is small

GWT is a different beast. It can support Javascript, without ever
working with javascript code directly. Modern browsers such as Chrome
and Firefox actually compile javascript objects into anonymous classes,
which are then consumed by the javascript engine. This results in very
fast code execution. You can say the old IE <8 and FF <3 engines are
indeed code interpreters, but newer engines lean towards JIT
compilation, like Java or .NET. Especially for boardgames, performance
is not really an issue. The above link to OpenSettlers demo uses 1MB of
minified javascript code (!). That's a lot of interpretation. When
loading locally from SSD, loadtime on a single core 1.5Ghz is below 1
second. That's surely acceptable. And I even have not yet optimized the
OpenSettlers code yet. There's a huge set of classes which are not
really necessary, but are compiled by GWT nevertheless because I needed
only a few classes.

GWT only supports features which work in all major browsers. That's the
reason SVG is not yet supported: it's implementation in the different
browsers is not yet on par for every major browser. On the other hand,
canvas _is_ supported by the major browsers, and as such supported by
GWT 2.2.

As I noted in my previous post, when there is a UI agnostic codebase, it
doesnt matter if you want to use SWT of GWT of JavaFX or flash or

Read this topic online here:

More information about the messages mailing list