VWG applications do not require installation on the server! VWG is implemented as an IHttpHandlerFactory and is deployed with your application as a couple of runtime assemblies. Deploying a VWG application is no different than deploying an ASP.NET application, except that it requires you to register the WGX script map extension, mapped the same way as ASPX script map is mapped.
VWG does not process logic and data on the browser! A VWG application is implemented using a single layered server side code which manages a remote UI presentation layer on the browser.
VWG applications do not require opening services for browsers to consume! As said in the previous paragraph, a VWG application is implemented using a single layered server side code which is the only layer that needs to consume services. VWG applications are written as if they where local WinForms applications with the exception that they are still running in a web environment. That said you can still implement components that consume services.
VWG does not generate JavaScript code! The scripts used by the browser are either VWG core services or VWG UI components logic which should not change from one application to another. Every VWG component provides its own controlling script and it can interact with the VWG client services, VWG client state data and its DOM elements. Interacting with the server side component is done using the VWG client services, normally by raising an event that is handled on the server. This means that the code you write is the code that runs in runtime execution and as so debugging is done on the actually running code as opposed to GWT implementation.
VWG applications are stateful! VWG applications provide server based computing over ASP.NET. This is implemented by using the ASP.NET session object as the application container. In terms of scalability and redundancy VWG applications should currently utilize a sticky session hosting approach and can also utilize a state serializing UIP application block. Floating session support will be available in the future (currently not enabled because of delegate serialization).
VWG optimizes communication band width consumption to the minimum, by separating between UI logic, UI templates and UI metadata. The UI logic and UI templates which are comprised of scripts and XSLT templates, that implement the different UI component behaviors and appearances, are loaded to the browser once as cached resources. The reset of VWG communication is done through UI metadata updates sent to the browser and UI event queues sent to the server.
VWG does not rely on ASP.NET's page model! VWG applications provide a different pipeline dedicated for serving applications over HTTP which provides an alternative to ASP.NET pages. VWG implements the concept of WinForms forms over ASP.NET base classes. VWG forms are mapped using the web.config to virtual URLs. Every form can have multiple child forms and multiple controls just as a WinForms application form.
VWG projects are actually ASP.NET projects! This means that you can enjoy both worlds utilizing the right tool for the right task. VWG can extend existing ASP.NET applications by implementing dialogs in VWG and consuming them from ASP.NET pages. VWG can use ASP.NET pages through gateways (see next paragraph) enabling developers to use ASP.NET pages with in a VWG application. A sample usage could be populating an HtmlBox using an ASP.NET page for displaying reports.
VWG provides a concept of gateways to bridge the gap between the WinForms object model and the web architecture. "Gateways" are mechanisms that enable declaring a VWG component as a gateway, which can be compared to implementing an IHttpFactory. The URL of the gateway can by extracted using the GatewayReference object and used by the browser. A sample usage of gateways can be creating a graph control by inheriting the PictureBox control and implementing it as a gateway so that the image displayed will be dynamically generated (see the graph control sample with in the catalog application).
VWG provides a mechanism to implement custom controls. VWG custom controls are no different than the built-in controls except that built-in controls don't have to be registered. The VWG configuration section with in the web.config file contains a controls section which enables registration of custom controls (see the WinPanel control with in the catalog application or explore the open source code to see how the built-in control where implemented).
VWG provides a concept of themes to customize the presentation layer. A VWG theme is actually an assembly that has embedded resources. Those resources are used to override core component resources and custom control resources. This means that you can override the TabControl template for example to display the control in a completely different layout. The resources are embedded according to the namespace of the overridden resource. If for example you have a "TextBox.xslt" resource embedded in Gizmox.WebGUI.Forms you will embed your overriding resource in "Gizmox\WebGUI\Forms\TextBox.xslt".
VWG provides a concept of flavors to provide theme variations. A VWG flavor is actually a set of name/value definitions that can be used in the different CSS files. You can select the active flavor from the web.config. Flavor definition files can also be overridden using themes.