Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
john_duffy
Partner - Creator III
Partner - Creator III

IE Plug-in vs. AJAX general discussion

Hello all.

We are just beginning the process of migrating from QlikView 8.5 client installs to QlikView 10.0 SR2 web based access. We are trying to decide whether to use the IE Plug-in or AJAX.

I'm looking for some feedback from anyone who is on v10 and using AJAX - issues converting to AJAX, effort required to reformat charts, macro issues, benefits found when converted to AJAX, etc.

Any information would be greatly appreciated.

Thanks,

John.

1 Solution

Accepted Solutions
Miguel_Angel_Baeyens

Hello John,

First of all, it may be quite general, but I answered something similar here.

I see both pros and cons for both clients, but if I have to decide only one, I'd choose the IE Plugin. Most of the reasons are in the post I mention, and are in summary (and in general, network hardware, system requirements and so may vary, of course):

  • Likeness of layout, Plugin is WYSIWYG, so you don't need to redesign anything (if any, except for new objects like the container...)
  • You can use Zoom in the Plugin
  • Speed and performance in general, if QVP (port 4747) is allowed between client and server, you save to communicate with the WebServer, and the communication is more fluent and faster.

Although version 10 has improved significantly the AJAX client, it still lacks of some functionality. Some macros will not work, it's not OCX/ActiveX, so although it will work fine in IE you will not take advantage of those.

In my experience, performace is a bit poorer than the Plugin, in case of AJAX you have a WebServer in between always.

You don't have zoom either, which means that unless all your users have the same exact screen resolution, scrollbars will appear.

Anyway, the major benefit of the AJAX client is that it doesn't need any installation, and with the SR2 of version 10, works quite fine with tablets, browsers, and so.

Hope that makes sense.

View solution in original post

4 Replies
Miguel_Angel_Baeyens

Hello John,

First of all, it may be quite general, but I answered something similar here.

I see both pros and cons for both clients, but if I have to decide only one, I'd choose the IE Plugin. Most of the reasons are in the post I mention, and are in summary (and in general, network hardware, system requirements and so may vary, of course):

  • Likeness of layout, Plugin is WYSIWYG, so you don't need to redesign anything (if any, except for new objects like the container...)
  • You can use Zoom in the Plugin
  • Speed and performance in general, if QVP (port 4747) is allowed between client and server, you save to communicate with the WebServer, and the communication is more fluent and faster.

Although version 10 has improved significantly the AJAX client, it still lacks of some functionality. Some macros will not work, it's not OCX/ActiveX, so although it will work fine in IE you will not take advantage of those.

In my experience, performace is a bit poorer than the Plugin, in case of AJAX you have a WebServer in between always.

You don't have zoom either, which means that unless all your users have the same exact screen resolution, scrollbars will appear.

Anyway, the major benefit of the AJAX client is that it doesn't need any installation, and with the SR2 of version 10, works quite fine with tablets, browsers, and so.

Hope that makes sense.

john_duffy
Partner - Creator III
Partner - Creator III
Author

Thank you Miguel. This information was very helpful.

shaunsomai
Contributor
Contributor

Hi Miguel

Have you done any testing with regard to Bandwith usage  between Ajax and IE plugin or is that

negligible.

Also  any speed test with regard how fast the same model would be used in plugin enviroment vs ajax

thanks

shaun

Miguel_Angel_Baeyens

Hi Shaun,

Unfortunately, I don't have log files worth sharing... I do can say that tunneling encapsulates the information and all the authentication must take place between the client, the web server and the server, and all the way back. With the plugin, the amount of information is sensibly less, since you authenticate once and for the session, and you skip the web server step, communicating directly server to client, without middle servers.

Hope that gives an idea.

Miguel Angel Baeyens

BI Consultant

Comex Grupo Ibérica

EDIT: I have updated to this QlikComunity the link in my previous post