Google Web Toolkit + Scala. Pros and Cons.

The last article here was "Reactive Programming Tutorial in Scala + GWT". Now is the time to become more familiar with GWT in general.

developers.google.com/web-toolkit/overview

Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript. GWT is used by many products at Google, including Google Wave and the new version of AdWords. It's open source, completely free, and used by thousands of developers around the world.

The best GWT pros and cons list I could find on the web is a post by Ganeshji Marwaha, a JavaScript lover. I decided to cite it here and put my comments in the Cons section with regard to GWT + Scala.

Reactive Programming Tutorial in Scala + GWT. Signal.

This is the second (and last) part of the tutorial. All those Scala live examples have been compiled to JavaScript and are running inside your browser. The first part of the tutorial is here.

-----

Signal

Introduction

While EventStream represents a stream of discrete values over time — that is, each value only exists instantaneously (in practice that means that you can never say "what is the current value?"), Signal represents a continuous value. In practical terms, a Signal has a current value, and an EventStream that, whenever the Signal's value changes, fires the new value.

Reactive Programming Tutorial in Scala + GWT

Reactive programming is quickly gaining popularity with more libraries popping up such as KnockoutJS, EmberJS, JavaFX, C# Rx, Flex, etc. So now that we know what is reactive programming and have deprecated the Observer pattern, it's time to write some code.

Let's look into reactive-web.co.cc library written in Scala by Naftoli Gugenheim. I like its support of incremental updates. As Naftoli states: "you can have a set of items transformed it in all sorts of ways and rendered, and when the set of items changes, only the necessary changes will be made to the DOM." Reactive-web has two parts: reactive-core (a general-purpose reactive programming library) and reactive-web (adds reactive-core support to Lift web-framework). You can find a tutorial with live examples on its site.

I've modified some bits of reactive-core (code) to make it work when compiled to JavaScript by Google Web Toolkit (Scala+GWT). Below is the text from the reactive-core tutorial with live examples converted to work with GWT. It means that all those Scala examples are running inside your browser.

Deprecating the Observer Pattern

This is the title of the 2010 paper by Martin Odersky (Scala creator, Java compiler author), Ingo Maier and Tiark Rompf. It shows how the ideas of reactive programming we discussed in the previous article can be implemented in Scala. Here is an excerpt from it:

lambda-the-ultimate.org/node/4028

Abstract

Programming interactive systems by means of the observer pattern is hard and error-prone yet is still the implementation standard in many production environments. We present an approach to gradually deprecate observers in favor of reactive programming abstractions. Several library layers help programmers to smoothly migrate existing code from callbacks to a more declarative programming model. Our central high-level API layer embeds an extensible higher-order data-flow DSL into our host language. This embedding is enabled by a continuation passing style transformation.

Reactive Programming

The last time we've been thinking "Are Variables Evil?" Now let's try to understand the ideas behind reactive programming.

The author of the Haskell library Reactive-banana writes:

apfelmus.nfshost.com/blog/2011/03/28-essence-frp.html

At this point, I should probably explain the design philosophy that makes it all work. What led me to my library is the following question:

What is the essence of functional reactive programming?

A common answer would be that “FRP is all about describing a system in terms of time-varying functions instead of mutable state”, and that would certainly not be wrong. This is the semantic viewpoint. But in my opinion, the deeper, more satisfying answer is given by the following purely syntactic criterion:

The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration.

For instance, take the example of a counter: you have two buttons labelled “Up” and “Down” which can be used to increment or decrement the counter. Imperatively, you would first specify an initial value and then change it whenever a button is pressed; something like this:
...
The point is that at the time of declaration, only the initial value for the counter is specified; the dynamic behavior of counter is implicit in the rest of the program text. In contrast, functional reactive programming specifies the whole dynamic behavior at the time of declaration, like this:
...
Whenever you want to understand the dynamics of counter, you only have to look at its definition. Everything that can happen to it will appear on the right-hand side. This is very much in contrast to the imperative approach where subsequent declarations can change the dynamic behavior of previously declared values.