[Vm-dev] Re: [squeak-dev] Squeak browser plugin and JavaScript

Rob Withers reefedjib at gmail.com
Mon Sep 6 13:02:39 UTC 2010

From: "Bert Freudenberg" <bert at freudenbergs.de>
Sent: Monday, September 06, 2010 6:25 AM
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Cc: "Squeak VM Dev" <vm-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Squeak browser plugin and JavaScript

> On 05.09.2010, at 19:43, Rob Withers wrote:
>> Hi everyone,
>> I have an idea for a large scale project.   Hopefully some of you will 
>> find it interesting and give me a hand as I don't really know yet what I 
>> am doing.  Please speak up with advice, pointers, links and opinions.
>> Here is my idea...develop a Squeak browser plugin for the various 
>> browser/os combinations which will emit and communicate with JavaScript 
>> which will run in the browser.
>> JavaScript runs in most browsers as a client-side scripting language.  It 
>> has reasonable UI widgetry for a client.  GWT is a really powerful 
>> framework/toolkit, which integrates a JavaScript front-end with a Java 
>> back-end.   In the process of development with GWT, you use Java classes 
>> and your own subclasses to develop the front-end.  You can code, test, 
>> inspect and debug in Eclipse (using a browser plugin from GWT for 
>> development mode testing in the browser).  When ready, you compile all 
>> the client code into JavaScript for performance.
>> I think it is possible to stream JavaScript to a running JavaScript page 
>> (page/instance/vm?) dynamically.
>> I think the place to start is to revive the browser plugin build for 
>> squeak. Next would be to serve up some initial JavaScript to prototype 
>> the concept. Next would come a thorough development of Client classes in 
>> Squeak to represent and emit JavaScript.  Not sure what that entails 
>> exactly.
>> Does anyone have any interest in such a project?
>> Best,
>> Rob
> Here's what I would do:
> You would have a web page, it would embed the Squeak plugin, but the 
> plugin's window would be hidden (or only visible while developing). The 
> User Interface would instead be done in HTML, and the DOM would be 
> interactively modified by Squeak.
> If you had a primitive for DOM manipulation you could start doing that 
> today (though last time I looked a couple years ago there was no 
> cross-browser way to do it). You could basically have Seaside running 
> within a web page instead of requiring a server and network connection.
> I just don't see where JavaScript is needed for that, and why you would 
> want to "compile all the client code into JavaScript for performance". You 
> can of course use JavaScript UI elements just like you can with Seaside or 
> any other Smalltalk web server.
> If all you wanted is developing a JavaScript application using Squeak, 
> then why not just run Seaside on your local machine and use any browser 
> you like? What do you need the plugin for?

Hi Bert,

I should start by explaining why I think the use of JavaScript is desirable. 
JS enables client side UI and behaviors.   It is back to fat client, with a 
server publishing the UI and the content, but the UI runs in the client.  JS 
supports client-side behaviors to respond to mouse over, hover, move?, 
click, selection, etc.  It is a professional look and feel and accepted 
industry wide - broad support in modern browsers.

Let's look at the alternatives you mention, and please correct me if I have 
the wrong read on it:

1) HTML/DOM - no client side behavior.  Not a robust UI.   All static 

2) Serving up JS from Seaside - This is possible I think, using Seaside as 
the Servlet.  My intention is to use a ToolBuilder, which I am woefully 
ignorant of, to build UI objects that would get translated to JS.  I think 
this is my "GWT" solution.  We would just need to figure out the best way to 
translate Morphic windows to JS.

3) Seaside running is the plugin/web page - In the GWT case, Seaside is the 
Servlet - why not run on the client?  In the v8 case, there is no servlet 
required, so Seaside would not be explicitly needed.

4) Squeak plugin rendering Morphic - I think Morphic is phenomenal. 
However, it still has a researchy flavor to it.  It has capabilities which 
are "non-standard" and fails to deliver a look and feel that is "standard", 
although it is getting better.  There may be solutions to these problems, 
but I want focus to stay in a widget even if I mouse off, I want the entire 
border of a window to be resizable, I want table widgets, multi-column list 
widgets, I like the power of JS for mouse-over/hover in popping up a 
borderless window for action.   I am sure most of these things can be done 
with Morphic, but I don't see it yet.   I think one thing I really want is 
for these windows to exist on the os/browser without being embedded in the 
Squeak desktop.

GWT(Seaside) and v8 integration are two ways for Squeak to interact with JS.

1) GWT emits JS and the JS communicates back to Squeak by talking to a 
servlet.   Squeak could be located in the client as a plugin or remotely on 
the server.  Possible latency issues with the server-based solution.

2) v8 looks like it publishes objects whose methods are registered as 
callbacks, such that a mouse event in JS would call the squeak method 
registered as it's handler.  It only runs in Chrome - what to do about other 

I barely recall the capabilities of the Squeak plugin.  Doesn't it allow for 
interactive Morphic in the browser?   Since I want JS as my UI, a third 
approach in addition to GWTSqueak and v8 integration is to write a JS 
compiler/interpreter/jit in Squeak and run Squeak as a JS plugin in the 
various browsers.  We would still need to translate Morphic to JS.

I hope this helps clear up what I am looking for and the reasoning behind 


> - Bert -

More information about the Vm-dev mailing list