Re: SQUEAK should go AJAX Re: Smalltalk w/o IDE, etc.?

I gather this is your main point, so I'll respond below:

On Mar 23, 4:03 pm, Friedrich Dominicus <just-for-news-fr...@q-
software-solutions.de> wrote:
And why not give them the chance to do in Smalltalk? Tell me one thing
JavaScript can do which one could not do in Salltalk. And if everyone
is getting to install any kind of plugins why could it not some
Smalltalk plugin? What would it take you to develop a plugin for your
Smalltalk? And trying to make "web-development" easier not more
difficult harder to test etc?

First, I thought this thread was about Ajax integration, not plugins.
It sounds like we're talking about two very different scenarios here.

The scenario I have in mind is this: as a web developer, you implement
your server application in Smalltalk. You use Seaside, or Smalltalk
server pages, servlets, etc. On the client side, you can (if you want)
use a bit of Ajax so that you have a few more options available.

The idea, then, is simply to make it easy for developers to use Ajax
if they want. This is a very modest idea. It's really just about
putting together a few patterns and showing what the Smalltalk code on
the server side looks like. It's mostly documentation, really, and
then you can leverage a lot of stuff that other web developers are
working on.

The scenario that you seem to be describing is this: as a web
developer, you implement your server application in Smalltalk, and on
the client side you also use a Smalltalk plugin (which doesn't exist
yet) to communicate with the server application, and then you turn off
JavaScript because you might be phished or otherwise scammed (although
the generally accepted statistic is that 94% of browsers on the
Internet have it enabled).

In the first scenario, we would do a very small amount of work to
leverage a bunch of stuff that already exists. In the second, we need
to develop a plugin that can effectively replace JavaScript, and then
we need to convince developers that they should use this new client-
server regime to build their web applications.

So, this brings us to the question of what it would take to build such
a plugin. I can tell you this: Cincom has been working on a Smalltalk
plugin for several years now. You ask the "what would it take...?"
question as if it were easy, just a small matter of programming, but
based upon my colleagues' experiences it's been a real b*tch.

To build a plugin that could do everything that JavaScript does, you'd
need code that works with all the existing browser APIs and port it to
all the platforms that JavaScript browsers run on. Also, to do the
same things that you can do in Ajax, you would need a way to access
and modify the HTML DOM from inside Smalltalk. I don't think that is
really part of the basic plugin API, and involves some extra thinking.

Cincom has been working for several years on this, and I can tell you
that it's not been trivial. Our developer has nightmarish stories
about APIs that aren't documented or don't work (because we're talking
about interoperating with Microsoft IE, right?), compiler problems,
etc, etc. etc. Some basic information on the browser APIs is not
available. And then there's the whole matter of making Smalltalk work
as a DLL that you can load into another running application (we're not
there yet), or being able to manipulate the HTML DOM (I don't think
we're even trying to do that with Cincom's plug-in -- it's just about
getting access to the display inside the browser and receiving input
events). We don't have domain classes for an HTML DOM as part of the
core class libraries. And on that note, good luck getting any
agreement on those classes between all of the various stakeholders in
the Smalltalk community. Good luck even getting e-mail replies back
from some of them.

To recap: I'm talking about the very modest step of making some
existing Smalltalk web application frameworks work with popular Ajax
libraries that already exist out there. There is evidently some
support for this in already Seaside. The idea is to just give web
developers some more options, not argue with them and tell them they
are crazy/wrong to use JavaScript, etc.

For me, the key word in what you are suggesting is "could". Sure, one
"could" do more if Smalltalk were cleanly integrated in every existing
browser on the market, but it isn't. Sure, in some hypothetical future-
subjective alternate universe, all browsers might have Smalltalk
support instead of JavaScript, but today they don't.

The point of your message seems to be: why are we messing around with
JavaScript and Ajax when we could be building a 100% Smalltalk
replacement for JavaScript? To this, I would say that at least one
vendor (Cincom) has been working on this, but it is really non-
trivial.

If you really feel strongly about building a plug-in, maybe you want
to get involved? ;-)

Best,

M. Roberts
Cincom Systems, Inc.

.

Relevant Pages

  • Re: Determining the font characteristics of any web page?
    ... You might also want to consider creating a document and using Javascript ... The second possibility is to write a browser plugin which means it is ... I need to know this on a web-page by web-page basis. ...
    (alt.html)
  • Re: Rubyscript instead of javascript
    ... the browser to the HotRuby bytecode interpreter which is implemented ... browser-side Ruby. ... It should probably be done like a plugin. ... Javascript that already has them? ...
    (comp.lang.ruby)
  • Re: Determining the font characteristics of any web page?
    ... You might also want to consider creating a document and using Javascript ... The second possibility is to write a browser plugin which means it is ... I need to know this on a web-page by web-page basis. ...
    (alt.html)
  • Re: Rubyscript instead of javascript
    ... the browser to the HotRuby bytecode interpreter which is implemented ... in JavaScript. ... browser-side Ruby. ... It should probably be done like a plugin. ...
    (comp.lang.ruby)
  • Re: Running Smalltalk in web browser?
    ... Smalltalk running natively "in the browser" like javascript, java, ... etc. via a plugin or module. ... Both VisualWorks and Squeak have plugins that allow one to run in the browser. ...
    (comp.lang.smalltalk)