Squeak browser plugin and JavaScript

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Squeak browser plugin and JavaScript

Rob Withers-2
 
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

Reply | Threaded
Open this post in threaded view
|

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

Bert Freudenberg


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?

- Bert -


Reply | Threaded
Open this post in threaded view
|

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

Rob Withers-2
 


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

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