Ross Ferris wrote:
I like hearing specifics about products like Visage and would also miss
it if you ever stopped pitching ;-)

Some of us are better thinking in terms of products and others in terms
of services.

AJAX and XML are both buzzwords that have behind them content that
could help everyone doing non-1NF data persistence get a boost,
including the PICK world. The client data model and the persistence
data model need not have an impedence mismatch as in the relational
world. That will soon be more obvious to others and we can either
watch or engage and lead.

The term I coined (I haven't googled for it to see if others have too)
for my writing is "WebDev," although I do like Tony's BUI. I want to
talk about the entire process of developing software and focus my
efforts on the profession of developing data-backed web-fronted
applications. It eliminates a lot of s/w dev that is going on today by
zeroing in on the web, but I think it is time to do that. Almost anyone
starting something new has to be thinking about giving it a BUI.

I did a talk in 1993 (12 years ago!) entitled "What Hath Mosaic to do
with Envision?" Mosaic is the browser that became Netscape that became
FireFox and Envision is the development platform used by my vendor at
the time, a UniData VAR. [And for those interested, the "Hath" comes
from Tertullian "What hath Jerusalem to do with Athens" where his
answer was "Nothing". My statement was that just as I disagreed with
Tertullian ...] I said then that the future of software development
was with the web and the evolution of the browser to front-end our
database applications. I had one of my employees do a prototype of
browser to UniData (query-only), and turned a few heads with that talk
(my ideas did too ;-)

I have been watching, testing, and even jumping in occasionally ever
since to determine when it was just right to switch all development to
the web rather than only shopping carts and such. The evolution of the
underlying tools (browsers, ECMA Script, PHP, XMTHttpRequest object) as
well as the boost on the marketing front with AJAX are a good part of
what makes the time right for me even though I have to learn a whole
new suite of tools. I'm having the hardest time caring about PHP, but
Tom D's examples have been helpful. Cheers! --dawn

Dawn,

I think the next few years will be "interesting". As you know, whilst
the AJAX buzzword is "new", the underlying technologies are quite
mature, and have been in use in various forms for the past 7-8 years,
thoug the actual implementation is now "easier" thanks to XMLHTTP.

The fact that AJAX is creating a BUZZ, and the technique is now widely
documented (and increasingly understood) means that more people will
adopt the technique.

However, some of the more interesting stuff that is done by some tools
(which might start with V:-) still doesn't sport a catchy buzzword, and
it will take time for these to be "discovered" by the mainstream

As Glen (?) mentioned, there are also some alternate, 3rd Party
alternatives like "Flash" that can cut through the red tape because
they have their own internal scripting engine (jScript based, but not
quite up to scratch last time I looked seriously) which IS consistent
across multiple platforms.

However, I'm also equally sure that if an alternate technology does
emerge, it will be plagued by just as many security issues as IE,
Firefox, Adobe etc

Ross Ferris wrote:
Yes, many of them are. The changes in the past year include the
maturation of the browsers that are out in the field so that the old,
old browsers no longer need to be addressed by those developing most
web pages; the better ability to use XMLHttpRequest in FireFox in the
same way as the ActiveX object in IE; the FireFox browser itself; and
successes such as various Google software.

Yes. Since there is buzz around the front-end, there is opportunity
for all back-end solutions to jump in.

Of course we have learned that it isn't the case that "if we build it,
they will come" and the lack of marketing across the PICK space doesn't
help.

Yes, there is room for proprietary solutions, and Flash has made as
much of an inroad as any proprietary solution requiring a plug-in.
There are many things that Flash does better than AJAX.

Security is definitely a concern, but one that can be mitigated, right?
There is also the flip-side concern of access -- things you cannot do
that you might want to, such as storing a document on the local file
system -- too risky for the standards to permit. Reliability is also a
concern. Problems have solutions and solutions ...

--dawn

Ross Ferris wrote:

One thing that stands out when you run an AJAX app is that the initial
page load is a slow, heavy process - and, as others have pointed out,
tends towards a thicker kind of thin client. Much the same as loading
some Java apps.

Going way out on an imaginary limb here:

Things are going to continue to get faster aren't they? How long will
it be, do you imagine, before it's possible (licensing issues aside for
the moment) to run a VME inside a browser. The browser, currently
repsonsible for rendering mark-up and imbedded images and interpreting
JavaScript could, conceivably, run like a D3 monitor, interpret
PickBasic and manage a small DBMS in its own blob. I'm thinking back to
the old "small footprint" days when much was made of the efficiency of
Pick compared to its competitors. I'm not really going anywhere with
this... just musing...

Mike.

michael (AT) preece (DOT) net wrote:
The tools I've seen to help address this fall into three categories:
1. Tools that let you add libraries (like prototype.js) but strip out
all functions that are not used by the page
2. Tools that compress javascript (typically limiting which browsers
can be used because they will not all uncompress it)
3. Tools which make some kind of cache for javascript, which I guess
wouldn't help the initial load at that web site, but could make
subsequent pages load more quickly

I haven't seen anything so compelling that I thought I'd try it,
however.

The tools that I have seen that make a cache in the browser are all
proprietary and I don't know how they do it. But it sure seems like
this area is only going to get better and better. As it stands it is
amazing what can be done -- google groups still impresses me every time
I go there.

The odds of the browser doing this without an additional install (like
flash or pdf) is very slim simply because so many groups have to agree.
That is why we are stuck with ECMAScript for the forseeable future
unless you work with a plug-in approach. But if you add in caching,
you could take a dbms-in-cache approach.

Good musing. Maybe Maverick in an applet with JavaScript communicating
with the Java code? --dawn

"Tom deL" <ted (AT) blackflute (DOT) com> wrote


First, good point.

Second, please accept my apology for the jump-in-middle tread reading that
prompted my comment. On review, your original post was actually pretty
close to the point. It's all the stuff after that began to go astray.

BFaux-