>> Uh, buh? That can be the case with any library. You can say the same thing about SCGUI if you're only running a single app with it. <<
In SCGUI you don't download libraries because most of the processing is on the server, not the client.
>> [Complicate the browser design]
Are already coded, complete, and installed on 90+% of the desktops out there. <<
What do you mean by 90+%? 90+% of *all desktops* with browsers? So you have to emulate on the other 10 percent?
>> In what way? As opposed to SCGUI where the user has to download a completely new version of the browser when new functionality comes out or is needed, in stark contrast to downloadable JS libraries which change immediately on the server with the app that includes them? SCGUI has the versioning problems here. <<
When it has vector support, it can draw any fricken shape or gizmo you want. However, it is designed to move most of the processing to the server. Skinny client, skinny needs.
>> [Create security risks]
On a secure VPN application used via an extranet or intranet connection? In what way? <<
In your particular case, it may not matter. However, much B-to-B is not via VPN.
>> [Increase download times]
Wrong. The JS is downloaded once in a library and cached. <<
Everytime the cache runs out, a download wait. I have seen applet downloads that take around 5 minutes on a T1 line. And, the bigger it is, the more it will need changing in many cases.
>> [More things to crash]
What? How so? How are there "more things to crash" than any other client-server architecture? You're reaching again. <<
Who said anything about client-server?