Squeak browser plugin and JavaScript

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

I'm more interested in doing a Squeak plugin for v8:) because we could potentially then make Scamper not suck.

If you're thinking along the lines of Squeak + JavaScript, it's worth (if you haven't already) checking out the Lively Kernel, Clamato, and OMeta/JS. I know this isn't at all what you're asking, but it's good food for thought.



On Sep 5, 2010, at 10:43 AM, "Rob Withers" <[hidden email]> wrote:

Casey,

You mention "Squeak plugin for v8:)".   What is v8:)?  Is that a smilie or
part of the name?

I have no idea about the packages you mention: Lively Kernel, Clamato, and
OMeta/JS.   What do they do?

Rob

--------------------------------------------------
From: "Casey Ransberger" <[hidden email]>
Sent: Sunday, September 05, 2010 2:06 PM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: Re: [squeak-dev] Squeak browser plugin and JavaScript

Rob Withers-2 wrote

You mention "Squeak plugin for v8:)".   What is v8:)?  Is that a smilie or
part of the name?

Google "v8 web" -> http://en.wikipedia.org/wiki/V8_(JavaScript_engine)

Rob Withers-2 wrote

I have no idea about the packages you mention: Lively Kernel, Clamato, and
OMeta/JS.

Google "lively kernel" -> http://labs.oracle.com/projects/lively/
This project is really cool.  You *have* to check out the demo and play with it - amazing.

Sean

Casey Ransberger-2 wrote

I'm more interested in doing a Squeak plugin for v8:) because we could potentially then make Scamper not suck.

+100 for a great in-image web browser!

Sean

--------------------------------------------------
From: "Sean P. DeNigris" <[hidden email]>
Sent: Sunday, September 05, 2010 2:52 PM
To: <[hidden email]>
Subject: [squeak-dev] Re: Squeak browser plugin and JavaScript

Interesting.  The link was bad - fixed link:
http://en.wikipedia.org/wiki/V8_JavaScript_engine

That led to this site: http://code.google.com/apis/v8/intro.html

which states:

"V8 enables any C++ application to expose its own objects and functions to
JavaScript code. It's up to you to decide on the objects and functions you
would like to expose to JavaScript."

So the thing to do is write a plugin?

Any progress been made in building a C++ target Parser?

Cheers,
Rob

 

--------------------------------------------------
From: "Rob Withers" <[hidden email]>
>
>
> Any progress been made in building a C++ target Parser?
>

Perhaps we will need to write one from scratch.

I would suggest we subclass VMPluginCodeGenerator and add or override
elements in the TParseNode hierarchy and add their creation and emission
protocol in VMPluginCodeGenerator.
 

On 05.09.2010, at 19:43, Rob Withers wrote:


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?

- Bert -

--------------------------------------------------
From: "Bert Freudenberg" <[hidden email]>
Sent: Monday, September 06, 2010 6:25 AM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Cc: "Squeak VM Dev" <[hidden email]>
Subject: Re: [squeak-dev] Squeak browser plugin and JavaScript

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
elements.

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
browsers?

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
it.

Cheers,
Rob

> - Bert -
>
>
>
>

 Rob,

Just one more link to add to your list of things to check out:

http://www.squeaksource.com/ST2JS.html

from Diego Gomez Deck.  It provides a Compiler that compiles Smalltalk
to Javascript with enough infrastructure to preserve Smalltalk semantics.

I can't tell from the rest of this thread if you'll end up needing such
a thing but it seems relevant to your original post.

David

(un-cc'ing vmdev)

On 06.09.2010, at 15:02, Rob Withers wrote:

> 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 elements.

Huh? All you do in Javascript is manipulating the DOM. Unless you draw your own UI using the HTML Canvas object.

> 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.

If you use ToolBuilder you don't have to worry about Morphic. It's whole purpose is to not depend on a particular UI framework.

> 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.

I did not suggest to use Morphic.

> 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 browsers?
>
> I barely recall the capabilities of the Squeak plugin.  Doesn't it allow for interactive Morphic in the browser?  

It runs a client-side Squeak in the browser, period. Anything else is optional. Running a Morphic app is one way to use it.

> 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 it.

Maybe you should re-read what I wrote in my previous message assuming I understood what you wanted ;)

Nothing I suggested required a server for interaction, it was all client-side.

- Bert -

Rob,

Based on what you seem to want to do (the impression I get is that you don't want a morphic look/feel, so Lively Kernel won't work for you, and that says to me that what you want is at least DOM-based dynamic applications written in Smalltalk.)

If you have not already done so, I *strongly* recommend checking out the tutorial at

clamato.net

This is a Smalltalk variant implemented entirely in JavaScript by Avi Bryant. Or rather I think he bootstrapped it from Squeak using PetitParser (which is also worth a look if you're into PEGs.)

So anyway you get a "standard" web look and feel, it runs entirely in the browser, has an API reminiscent of Seaside, a not-finished JQuery implementation, and the clincher: a Smalltalk code browser right in the web browser.


On Sep 5, 2010, at 10:43 AM, "Rob Withers" <[hidden email]> wrote:

Hi Guys -

This may be a bit off-topic, but I believe it touches on several of
the ideas at work here...

I'm starting a modest project (along with Robert Krahn and Marko
Roeder at the Hasso Plattner Institute) to extend the Lively Kernel
universe to...

        servers and databases via Node.JS or Jaxer or similar
        visualization via ProtoVis or InfoVis or similar
        other languages via OMeta
        the cloud via AppEngineJS or similar
        3D via WebGL

We're short on resources, so this will happen slowly, and we're not
even "done" making LK what it should be, but that's the idea.

Whether it makes sense or not, it certainly should be possible to
take the OMeta part of this and play around in a lively manner with,
eg, Smalltalk, Clamato and Newspeak.  If there is significant
interest, it would be fairly easy slide the OMeta work up a bit in
our schedule.

        - Dan

>>>>> "Dan" == Dan Ingalls <[hidden email]> writes:

Dan> Whether it makes sense or not, it certainly should be possible to
Dan> take the OMeta part of this and play around in a lively manner
Dan> with, eg, Smalltalk, Clamato and Newspeak.  If there is significant
Dan> interest, it would be fairly easy slide the OMeta work up a bit in
Dan> our schedule.

/me drools

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Cool!

On Sep 6, 2010, at 11:57 AM, Dan Ingalls <[hidden email]> wrote:

This is really great Dan!  Thank you.  I downloaded OMeta and initially
explored what I could.  I am struggling with the Javascript Compiler, as
there are no examples.   Am I correct that it compiles Javascript to
something (bytecodes?), and not taking Smalltalk and compiling it into
Javascript?

I was thinking we would have Smalltalk objects that get compiled to
Javascript.   Then, since I am looking for a way to get a vm on each
browser, we would need someway to run Javascript in the browser.  It seems
OMeta would fit inside those points to compile Javascript to bytecodes to
run in the plugin.  I am not sure what mechanisms could be used to tie the
Javascript to the browser.

Cheers,
Rob

--------------------------------------------------
From: "Dan Ingalls" <[hidden email]>
Sent: Monday, September 06, 2010 2:57 PM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: [squeak-dev] The Gromit Project [was: Squeak browser plugin
andJavaScript]

This might fill an architectural space between UI Squeak classes
representing Javascript prototypes put together with the Javascript
compiler.   I will put it on the list for later reading, along with all the
other packages, I might add.

Thanks,
Rob

--------------------------------------------------
From: "C. David Shaffer" <[hidden email]>
Sent: Monday, September 06, 2010 12:45 PM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: Re: [squeak-dev] Squeak browser plugin and JavaScript

--------------------------------------------------
From: "Bert Freudenberg" <[hidden email]>
Sent: Monday, September 06, 2010 1:17 PM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: Re: [squeak-dev] Squeak browser plugin and JavaScript

I don't understand this.  Could you explain what you mean when you say "All
you do in Javascript is manipulating the DOM".  I realize a DOM comes from
the servlet, but there are all these objects that are created and interact
(to mouse events, timers, other events).  It talks to the server with DOM
but the behavior is more than just manipulating the DOM, isn't it?


>> 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.
>
> If you use ToolBuilder you don't have to worry about Morphic. It's whole
> purpose is to not depend on a particular UI framework.

Sweet.


I struggled to get past the assertion that HTML was the way forward...

Cheers,
Rob

Okay, I'll check it out.  Added to the list (OMeta, Clamato, ST2JS, Lively).

Cheers,
Rob

--------------------------------------------------
From: "Casey Ransberger" <[hidden email]>
Sent: Monday, September 06, 2010 1:52 PM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: Re: [squeak-dev] Squeak browser plugin and JavaScript

On 07.09.2010, at 04:05, Rob Withers wrote:

Err, no. The DOM lets you manipulate HTML:

http://www.w3schools.com/htmldom/

The DOM is JS's view of the HTML page, and it can manipulate it. That's all there is to it (if you cut through the piles of marketing bs). It's a very simple idea, and as often, those are the powerful ones ;)

E.g. if you want to hide or show a control in JS you change attributes on the DOM which the browser then renders.

> , but there are all these objects that are created and interact (to mouse events, timers, other events).  It talks to the server with DOM but the behavior is more than just manipulating the DOM, isn't it?

This has nothing whatsoever to do with a server. As I pointed out earlier ;)

- Bert -