(* I know it's fun to handwave and bitch about stuff, but a lot of people get a lot of stuff done with this, and your experience doesn't negate that, as much as you would seem to like it to. *)

I agree that a lot of stuff is indeed "doable". However, it is an akward paradigm for biz forms and the implemenations are buggy.

(* What changes in IE are designed to increase lockin? *)

There are things that work in IE that don't work in Netscape,
and are probably not standard.

(* Where do you get your figures on Netscape market share? Do you think AOL and Compuserve going to the Gecko rendering engine (figure, say, some 50 million users) will change the way corporations design their sites? *)

I think you are misunderstanding me. I am making a distinction between B-to-C and B-to-B. JS+DOM+HTML is *fine* for most B-to-C. However, it is a poor match for B-to-B and intranets (BBI).

(* How do you know what the "biz market" (how delightfully vague) wants? *)

I have consulted at about 5 companies that seem to want the same thing: BBI web apps that behave like VB apps.

(* Why is DOM "broken"? What do you mean by this? *)

Again, it is optimized for e-brochures, not biz forms, and its implementation is buggy and inconsistent across vendors.

Business go with web-based BBI solutions because they don't like managing/visiting individual desktops. However, they *prefer* a classic client/server interface (VB/Delphi/Powerbuilder).

They want GUI's over HTTP. (Why other protocols are being excluded here was discussed in length about 6 months ago.)

Getting JS+DOM+HTML (JDH) to act like c/s apps is a royal pain in the butt. Even if you think that it is *possible* to get JDH to act like a VB application, you have to agree that it is not the optimum approach from a developer's perspective. VB/Delphi/PB are *optimized* for such application design, JDH is not.

At best, JDH could be "fixed" so that c/s-like apps are *possible*. But, it still would not be optimized for such solutions from a developer's perspective. (Perhaps it could all be server-generated such that the IDE acts like VB/D/PB, but the client only sees JDH. Until I see it in action, I am a bit skeptical, but would use it if it caught on and the IDE's were "normal".)

If orderQty < StockQty + 5
....ans = yesNoBox("Inventory is Low. Still order?")
....if not ans
.........closeScreen(foo)
.........return
....end if
end if
update_screen_with_new_order....

You cant easily have strait-forward code like this in JDH with the typical CGI-like "submit" approach. (And if you do it all client-side, then you are back to the fat-client model.) The yes/no box and CloseScreen operation have to be two different "web transations". In web programming, you not only have to recreate the state on each "submit cycle", but also recreate the program pointer (execution position in the code) to pull this off. If the model behaved like event-driven GUI IDE's, life would be simpler.

(* Perhaps in any discussion on the intracacies of DOM, one would seem more authoratative by using a little HTML - instead of trying to mimic Pascal block comments. :*)

HTML is not WYSIWYG. "(*....*)" is.

(* Use blockquote .....substantially easier to read. *)

Still not WYSIWYG. Do you really find that significantly harder to read? I personally see no problem with Pascal-style, but everybody's eyes are different. Besides, I got into the habit while trolling slashdot and others with anti-OO rhetoric :-) It might take a while to break the habit.

Blockquoting like that is too easy to mistype anyhow. A typo that may "work" in IE may not work in Netscape, for example. That is why I trended toward WYSIWYG ascii.

(* Pascal style "comments" in discussions are significantly harder to read because they have more visual overhead. *)

I honestly disagree. But, everybody's eyes and heads work different. Thus, if you say they are harder to read (for you), then I respect that. However, I am still gonna use Pascy. If you don't like it, then don't read it.

(* That's what the Preview thinger is for. *)

That does not necessarily detect browser differences for mistyped HTML.

(* The VS.NET IDE is VB like in that you double-click on form elements and define event handlers and all that rot. *)

Yes, but the result is still CGI-like, and not classic GUI.
I started reading up on it, and there still seems to be
a lot of "e-brochure" artifics in the .NET stuff.

What do you mean by "all that rot"? Those are what makes
GUI's powerful and relatively simple. An event can
change anything anywhere in the app display
without worrying about recreating state or
sending a complete new copy or what-not.

The point is that I don't see any reason why one
could *not* design an app in the traditional
VB/Delphi/PB way, and then have it run in a
GUI browser over HTTP without downloading
new Turing-complete programming code.
(I realize that certain features may
not work as well as under c/s, but
the majority of what is needed will.)

The .NET stuff does not seem like the
magic solution. It simply gives more
legs to the HTML browser paradigm,
but the paradigm itself is the fault
that must be replaced.

CRC should never have to leave Delphi
(a future version) to have a thin-client
GUI solution over HTTP.

(* There are other similar frameworks for Java and mod_perl as well. *)

Do you mean similar to .NET, or to my "ideal" solution?

The general solution, I have come to tenatively conclude, is to maintain the "master image" (MI) of the interface (widgets, forms, widget content, etc.) on the server. You don't write to the client directly, but to the MI, and then echo the MI to the client as needed. For regular CGI-like flow, you probably have to echo the entire MI to the client each time, since HTML forms were not originally designed to be incrementally altered. However, in a more GUI-friendly approach, you only echo the parts of the MI that changed back to the client.

Whether the MI is stored (on server) via XML, objects, linked lists, or tables is a secondary issue. (The advantage of tables over objects is that if you are using a load/unload paradigm, like CGI, then the table stays there between calls, but you would have to recreate the object web {including instances} if using OOP to store the MI. Perhaps Smalltalk can pull it off, but in other OOPL's it is a bit more difficult.)

Conceptually, it is a lot like the Cytrix/PC-Anywhere approach where the master image (bitmap) is on the server, except that the "primatives" are GUI widgets specs and *not* image pixels. This avoids having to send every cursor movement back and forth between the client and the server.

I have been giving these issues a lot of thot lately.

(* Now, although I agree with you that JDH is not as "powerful" as a GUI, I find that not to be a significant limitation in my work. *)

What I find is that managers keep wanting weblications to resemble VB-like GUI apps. JDH-CGI is crappy for that. The same app would be roughly about 1/2 to 1/3 as much code in a C/S GUI tool, be more natural UI-wize, and quicker to develop.

I don't like funky paradigms to get in the way of my vision of how I want the interface to be. I want to conduct a symphony with whatever instrument I feel like, within reason.

I will have more to post about this soon.

(* it forces me to think about bandwidth and workflow much more intentionally, *)

You like it because it herds and punishes you? Leave S&M to the hookers.

Just don't use bound countrols in C/S tools and filter large search lists/grids at the server stage, not on the client, and you shouldn't have that many bandwidth problems.

I continue to be under the assumption that bound controls and filtering on the client are the essence of VB-like GUI apps. If this isn't the case for you, then what do "VB-like GUI apps" entail that's different from web apps? Comboboxes?

You can change just about anything anywhere on any screen at any time (within the app).

If web apps are (or can be) so similar to C/S GUI apps, then how come there are no VB/Delphi/PB-like IDE's for developing them? (The closest thing I know of is the Oracle Forms using it's Java-applet-based "GUI Browser". But Oracle Forms stinks to high heck. It has a certain "personality" that you have to negotiate with. It does not easily allow "changing anything anywhere on any screen at any time" and forces outdated Windows-3x-like conventions on you. If their GUI Browser was only an open standard or OSS, then it might go further.)