Grzegorz Kossakowski, now studying for a Masters with the Scala team at EPFL, has been working on a research project to enable Scala to be used directly to write browser applications. In this interview  he explains how he has made it possible for anyone to write Scala browser screen code in Eclipse and a few seconds later see the results in a browser. A real neat trick using GWT!
He has created a 7 minute YouTube video  where he walks through the steps of writing a Scala program, deploying to a browser and debugging it interactively. Click Read More  to read the rest of the interview.
As he explains, this is a proof-of-concept research project and not a 'product' announcement. That said, the project is remarkably mature and you can down load the tool set to give it a whirl, instructions here.  If you like it, then Grzegorz would welcome feedback and contributors. This fascinating research was sponsored through internships first at Google with Lex Spoon and then recently at Typesafe with Martin Odersky.
How did it all happen?
Time ran out with Lex and the project became a personal hobby. I got lucky again. Martin Odersky at Typesafe liked the concept and Typesafe sponsored me to finish the project, taking me on as an intern. It was a tremendous environment, ready help from people like Martin, Adrian and Lukas from EPFL and Iulian from Typesafe.
What's the project status?
What is GWT?
GWT, a project with growing interest, provided a wonderful starting point for my own Scala project. It resulted from the dedicated work of great bunch of developers, people like, Lex Spoon, Rob Heittman, Aaron Novstrup and Stephen Haberman.
The Scala+GWT project has been running for over a year and during most of that time it was not really usable at all for real programs. Compiler projects are different to other projects. You need 90% of the functionality before even simple programs can run. Then the last 10% is a struggle as you discover the edge cases. For a developer, it's really frustrating. You work for months before seeing something work at all. It was just the same for the Scala+GWT project. Quite a bit of contributor interest at the begining but it soon faded away, nothing to try out. Compiler projects are difficult to join part-time. The learning curve is just too long and steep. The Scala compiler is sophisticated and intricate, a huge challenge for any newcomers. On top of that GWT is another compiler with another set of challenges. It's a lot to swallow.
We have got there. Now we have a working prototype that anyone can use and there are lots of areas people can usefully contribute without diving into the guts of the compiler. We finally got to the fun phase, making new releases every couple of weeks adding features that developers care about, like speeding up the compilation or making development in the Eclipse IDE really nice. Now we are seeing a lot of interest.
Why Scala instead of Java?
Using GWT libraries and abstractions to program widgets forces you to produce lots of boiler plate. For example event handling is implemented as an anonymous class which requires many lines of code. Very much a consequence of the Java idiom being carried into GWT.
My personal motivation for doing the project was knowing how much nicer it is to work in Scala. I wanted to bring that to browser application development. Now anyone who is familiar with Scala and Swing can easily write Scala applications for deployment in a browser. The API's are slightly different but the style and basic abstractions are the same. That's neat and a joy to use. Moreover, we are not restricted to GWT APIs. People looking for Scala2JS compiler should give Scala+GWT a try, too.
What were the challeges?
Getting some of the Scala libraries to run on GWT required some thought. Several of them use reflection and GWT does not support that feature. Platform specific dependencies like IO or JVM specific APIs are a problem too. Most Scala libraries, those not using low level platform services, should work with little or no modification. No real limitation as you do not general expect to do IO in a browser, it's restricted by the browser security layer.
To do this we took two really complicate projects the GWT and Scala compilers modifying each to integrate with the other. The Scala back-end was modified to produce "jribble", a human readable bridge language  that we designed to suit the needs of GWT and GWT was then modified to compile it.
Jribble was designed by starting with Java and removing all restrictions which are problematic for Scala. At the same time keeping it structured so that GWT can compile it successfully. It required a lot of work to get this right. Array handling is difficult. In Java they are special citizen and not erased while in Scala they are a regular generic collection and you can use it like any other generic collection. The Scala compiler uses lots of tricks to make arrays pleasant to use and generate efficient byte code for the JVM. We had to create a completely new implementation of those optimisations for GWT but without the help of reflection. A very intricate and tricky task.
We started with jribble having a similar syntax to Java and used the parser combinators from Scala in GWT to compile the language. Although very flexible and easy to implement it was slow. We eventually abandoned it and encode jribble as google protobuf messages. They are already used in GWT so no increase in dependencies and they offer a very compact, fast to read binary representation that did not need a parser. Changing from Jribble to proto path reduced the 'parsing' phase from 120 seconds to 1 sec for our 4,500 line Scala demo and some 40,000 jribble lines. http://code.google.com/apis/protocolbuffers/docs/overview.html 
What is Developer Mode?
How does it perform?
We can see how to optimise the GWT code generation too to close the performance gap. So still some work to do! As you know for most browser code performance is less important than shorter development time. Scala and GWT come with a very rich libraries for creating and interacting with widgets. You can inject HTML where ever you want or manipulate DOM directly and many services already have Scala wrappers.
While we are talking about HTML I should mention that in Java you must be careful to avoid escaping strings, especially if getting input from a user. You can easily get script injection problems. With Scala it is so much safer as HTML literals are supported and escaping strings are handled automatically. The Scala compiler catches these problems for you. One less thing to worry about.
There is no real support for multi-threading in todays browsers. Parallel Collections are not currently supported, but as multi-threaded browser standards firm up we will be ready to add support for the primitives that underpin Scalas parallel collection, fork-join and work stealing. Then it will be a simple matter to turn on the parallel collections capablity. The same applies to actors. It would be neat to have Akka actors running both in a browser and on a server and let them communicate seamlessly.
For a real product we need to integrate our changes with upstream projects like GWT and Scala. Right from the beginning Lex was really careful to design our required changes in such a way that we do not disrupt the existing design of projects. Changes are orthogonal to existing APIs, they carefully thought out not to alter existing APIs or functionality for current users. So from a technical point of view it should be straight forward to merge the changes. This means that people will be able to just download current versions of GWT and Scala and be ready to go. No more messing about.
Who will use Scala GWT?
Java developers already using GWT would find it much more productive with much less boilerplate frustration.
What about you?
Now working on my Master thesis at EPFL but 25% of my time still available to lead this project. I will be re-organising the project resources to make them easy for people use and contribute. I would love to help contributors get started, perhaps on wrappers around GWT libraries that are more idiomatic Scala or documentation. One of my first tasks is to help Adriaan with the pattern matching changes. Also, I’ll be supporting project by promptly fixing bugs reported by our users.