Performance Client-Side scripting and rendering WiseJ compared to Visual WebGui


Hi all,

we recently upgraded our business application from Visual WebGui to WiseJ. So far everything is working as expected, but we have some serious performance issues compared to Visual WebGui, which were also noticed by a huge share of our customers.

We did several performance tests and profiling both on the server and client side to get to the root of it. The server side is looking fine and in some cases the performance is even better compared to Visual WebGui. However the client side is notably slower. Opening a form in some cases takes 3-4 seconds compared to 1 second in Visual WebGui. This adds up to a significant drop in performance and leads to a poor acceptance with customers, who worked on Visual WebGui previously.

We have attached a performance profiling done with the developer tools of the Chrome browser for WiseJ and Visual WebGui, which shows the difference. We used the exact same form with the same controls and the same data.

Have you had any experience with this and can you give us recommendations on how to improve the performance based on this profiling?

Your support will be much appreciated. Thanks in advance.

Best regards


  • You must to post comments

VWG used a completely different client-side system based on unreadable XSLT used to transform XML into a large HTML string then inserted in the browser using innerHTML. The first creation of the whole page was basically a large HTML string. Subsequent updates used smaller snippets of XLST again used to transform XML into HTML strings used to replace the HTML of the control to update. That’s why textboxes were losing the focus when a property changed and resizing a column in a grid with many rows and columns was painfully slow. Apart from the fact that it was close to impossible to maintain and extend. I worked on the VWG source code for years.

Wisej instead uses a different approach, in line with any other Single Page Application (SPA) system out there today. Every control is a javascript widget object, which is rendered by accessing the browser DOM through a FastDOM system that minimizes the access to the browser’s DOM. Having a real javascript object system has all the benefits that you can imagine, but obviously creating hundreds of objects in the browser is slower than creating zero (VWG didn’t have any javascript class, just a large flat set of functions).

This is to explain that if you compare a plain HTML page (i.e. VWG)  with a page composed with objects (Wisej) the HTML page is faster at first creation. Subsequent work with the application instead it’s faster when you just change properties instead of recreating the HTML every time.

In some of our projects that were on VWG we were able to reduce the initial gap substantially (probably to a 30% difference) while the subsequent interaction was always faster and way more reliable in Wisej.

There are some things you can check:

  • hidden controls that are made hidden after Form.Load. Wisej optimizes the creation of client widgets and doesn’t send them to the client until they are made visible the first time. But if the form is loaded and then the controls are set to Visible=false they still reach the client.
  • comboboxes or listboxes with many items, you can make them use virtual scrolling or enable the lazy loading option.
  • too many color or font assignments when the value is the same as the inherited value, it still causes the browser to resolve the color (VWG didn’t have a color system) and the font (VWG didn’t have a font system), etc.

Contact me at support at and we can look in more details at your app.



  • Markus Gschwendtner
    Hi Luca, thanks for the explanation and your tips. I have send you a more detailed message and a test account for our application to support at Would be great if we can have a look at this issue together. Thanks and regards, Markus
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.