Home Original page

[Q] In-Browser technology

Cameron Laird claird at starbase.neosoft.com
Wed Jul 21 07:49:29 EDT 1999 
In article <932522335.684.43 at news.remarQ.com>,
Vladik <reason at shadow.net> wrote:
>OK, I will try to clarify my question.
>With the warning that I may not be speaking
>authoritatively about the web technologies yet:
>I am just starting this research.
			.
			.
			.
>I do not know what it is supposed to be
>a plugin or not --- but a technology that
>allows to develop not-trivial GUI applications
>that run withing a browser.
What's the benefit of the browser?  It sounds
as though you want something that works over
a network, and operates something like Java
and JavaScript, but programmed in a language
"better" than Java or JavaScript, and with no
particular server-side component.  Why are we
talking about Web applications at all?  Is
there some reason you're not choosing your own
language and designing your own protocol?  Many
of us do that sort of work daily.
			.
			.
			.
>
>> 2.  "... a prototype of the client
>>     in MS ASP (active server pages)
>>     and, I think but not sure, blended
>>     with Visual Basic ..."  I have no
>>     definite idea of what you're say-
>>     ing here.  Is it that your
>>     customer has a picture of the
>>     visual appearance of the desired
>>     deliverable?  What is there about
>>     the ASP prototype that does *not*
>>     meet the requirements?  Is VB
>>     blended on the server or client
>>     side?  Does it matter?  Is it really
>>     VB, or VBScript?
>
> I meant that VB script was used in the prototype, not VB
I'll ask again:  what constrains your team from
rewriting the display-handling in JavaScript,
refining the prototype business rules, and
declaring that you have won the war?  Is there
something in the architecture of the prototype,
apart from VBScript's non-portability, that
doesn't meet your requirements.
>
>> 3.  Are you aware that *lots* of browsers
>>     read pages served as ASP?  You can
>>     use ASP without requiring IE.
>NO I was not aware.  Thanks for pointing out
>I will try to find more about netscape (the only
>two browser we are to support are Netscape and IE).
What does it mean to support the browsers?
It sounds as though you're willing to deploy
plugins on every desktop anyway; what benefit
do the browsers give?
			.
			.
			.
>I guess what I was looking for is something like
>this:
>"Here is a technology like Java (or different
>but accomplises the same thing), and it is based on this
>OO programing language and here is the page where you
>can read more about that also includes technical comparasings
>between this technology and JavaScript (or other)
>"
OK, sure.  Tcl has a plugin.  There's a whole book
on Perl-coded Web clients.  The Grail Web browser
is written in and fully programmable in Python.
You've already found out about Juice.  People have
done wonderful Web and more general client-server
things with Eiffel and Forth and Scheme and ...  I
have unpacked a few of my notes on language compar-
isons at <URL:http://
starbase.neosoft.com/~claird/comp.lang.misc/language_comparisons.html>.

Still, I feel I'm just not getting it.  You want
something just like Java, except faster; you're not
going to find it.  I acknowledge Juice is zippier
and more compact for particular test cases; I have
no way of knowing, though, whether those isolated
measurements have *any*thing to do with your domain.
I rather suspect they don't.
			.
			.
			.
>I have never used JavaScript for development, for comparising Juice
>applet gets to my computer faster and draws the wireframe
>example faster.
>The client app we will have to develop will have to
>a) maintain a limited set of bussiness rules
>b) apply a to relatively large sets of data from the database
Are you quite sure you want all this processing to
be on the client side?  Why is this a Web application
at all?
>
>
>> 6.  How much client-side programming are
>>     you doing?  Why does object-orienta-
>>     tion there matter to you?
>
>Yes it does. Because the app will contain some bussiness
>rules, some data access and data presentation layers.
I'll take this as a religious matter.
			.
			.
			.
>Well, I guess what I was asking the ability to have
>the server run on any platform and this web client
>be executable withing a browser that runs on any platform.
Everything we've discussed, apart from
VBScript, is as portable as you seem to
need.
			.
			.
			.
>They make SRC available, I downloaded it,
>the license does not seem to be restrictive, but I am
>clear on that 100% yet.
I repeat:  talk with them.  Perhaps Juice
is more portable than you realize.
			.
			.
			.
There's something about this picture that
doesn't make sense to me.  You are rela-
tively inexperienced in designing Web
architectures, so you're asking for help.
Good.  It sounds as though you're respon-
sible for quite a serious project.  If
this work is as important as it seems,
and you don't have local experts to offer
seasoned judgment, and you're in the hurry
I gather you are, then I advise you to fly
in someone you trust for a couple days of
consultation.  It will be far less expen-
sive than trying to recreate on short
notice the expertise that comes only with
practice.
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
claird at NeoSoft.com      +1 281 996 8546 FAX
More information about the Python-list mailing list