AJAX or Plugin

[#1]

Hi Qliksters...

I'd like to take some comments or feedbacks about how do you roll out your QV applications.

Whether it's in ajax or plugin?

Knowing that in future, QV will work only in ajax? i'm not sure how true is this, are there any supporting doc on this?

I have not really use the QV applications in ajax, are there any known issues compared to plugin?

would be great if anyone can highlight the PROS & CONS of AJAX.

As much as maintenance and support are concerned, i'd go for ajax.

One of the main reason is that, we no longer need to give advance notice to the IT team to prep the SMS package for the users so that they can "push" the new version of plugin to all users. and i mean, world wide users in different geographical locations and in different languages. the advance notice took a long time, and by the time, the next sr might be out.

Please share your thoughts, any comments, feedbacks are appreciated.

Thanks.

qlik qlik ...

[Miguel_Angel_Baeyens]

Hi Nick,

This has been long discussed in the forums, and I can send you to previous discussions here and here. You have already pointed out the obvious reasons for both, specially for Ajax: it does not require any installation client side. This is, I'd say, the main pro. The main con is that it's not completely WYSIWYG yet, so if you want fidelity to the original development, use Plugin.

But it's not only about visualization, but about network, performance and reliability as well.

To summarize links above:

• Plugin is WYSIWYG, allows more macros and is usually faster.
• Ajax does not require installation, only a browser, works in mobile devices as well

Hope that helps.

Miguel

[#3]

Thanks Miguel for the info.

As for the QV roadmap, will the plugin be ceased totally? any insight of that?

Knowing the pros and cons, what would be your opinion in general ? whether to use plugin or ajax.

or what about the market trend? do you see more customer choosing ajax over plugin or vice versa?

Thanks.

[Miguel_Angel_Baeyens]

Hi Nick,

My personal view (because I'm not on R&D and I cannot speak on behalf of them) is that certainly the Plugin will be some time in the future discontinued, because it requires a very specific version of browser (Internet Explorer 6+), operating system and so, and I base this assumption on how other clients have been removed (Android and iOS app to Ajax, Java Blackberry to Ajax...). Some features such as session collaboration are only available in Ajax... And that makes a lot of sense to me.

Regarding market trend, HTML5 (Ajax) is clearly the way to go, although not immediately.

Again, my personal opinion is that you better use the Plugin for the time being, until some enhanced Ajax client/interface is released. Why? Because of total reliabilty on design and behavior in regards to QlikView Desktop (as of today) and because performance (avoiding the Web Server makes less traffic and less network infrastructure). Of course I know (and I suffer) the cons, usually IT related issues with firewalls/ports, deployment of plugin to remote clients and so.

Having Plugin will allow you to use Ajax if needed.

Hope that makes sense.

Miguel

[#5]

Miguel, your personal opinions are much appreciated.

i agreed with you for the time being.

Until a better version ajax is released.

Thank you very much !

[Alexander_Thor]

Another personal opinion not associated with QlikTech etc.

I'm on the opposite end of the spectra. I strongly advice against the use of Plugin for a new deployment with new users.

This is for a number of reasons. From an IT-perspective it should be quite obvious, no local installations, a lot less network traffic making it very suitable for world wide deployments where latency is an issue, allowing more then one browser, easier to deploy new applications into more user groups.

The one "issue" with AJAX is that you will have a larger RAM-footprint on the server but hey RAM is cheap, local IT-support on clients is not

For the users, I know some of our long time users have a problem moving over to ajax since they miss the plugin look and feel. Hence, don't even bring the plugin into the equation. Remove the need to re-educate your users on a new look and feel and don't create that requirement for you down the road.

I won't go into the discussion of writing macros in a language that has been marked for end of life

[#7]

For once, I have to disagree with my colleague Miguel Ángel

It is true that in the past, the AJAX client wasn't very nice (about look & feel, compared to the plugin) and doesn't support some macros, but for me, those cons aren't as bad as not having the pros it has: no installation on clients (instant deployment for everyone), mobile access, lighter data communication between client and server and also less hardware required in the client, not having to update the plugin every time the Server is updated, etc.

So, for these and maybe other reasons that I can't recall now, for me, and personal opinion, AJAX is my way to go in the near future and also today.

Cheers,

Borja

[#8]

Hi.

I think they are planning to discontinue the plugin.

Maybe not in the next version but a couple of the new features are only included in the Ajax client. Session collaboration and document extensions are two of them.

There has been some issues with the Ajax client. Mostly smaller problems with copy table data to clipboard, saving object as picture.

There are small design changes when opening a qlikview with Ajax compared to the plugin or the QlikView Developer. However, from version 11 you can change the view in the developer to webview and see what the Ajax version will look like.

Macros can be used in Ajax but they don't allow creating objects like this one or similar: Set objhttp = CreateObject("Microsoft.XMLHTTP"). The macro issue can be solved by using document extensions.

But there are two major benefits with Ajax. You don't have to install and update the Ajax client as you do with the plugin. It works with the most web browser including Safari on ipad/iphone and Chrome.

In my opinion, if you have complex macros that you don't know how (or have time) to translate into a document extension then you should use the plugin. Otherwise I cannot give you any reason to use the plugin.

For large migrations where they are planning to move from plugin to ajax, we always test all QlikView applications in Ajax by installing a testserver. It's a bit of work but you don't get any unhappy surprises during the migration.

BR, Per

[Bill_Britt]

I too have heard that the plugin is going away. My understanding is that  Microsoft is or will not be supporting the OLE Control eXtension for much longer. If this is true, it will force the end of the plugin.

[#10]

Usually our decision here is influenced by compatability. Hands down, if you want to talk about multiple browsers and mobile, you want to use AJAX. From an IT perspective, as most people have commented, AJAX is also simpler to deal with, since there is nothing (read: "less") to worry about.

It's true that this was a bigger deal in Version 9 and the earlier Versions of 10, but as of 10 SR4 and 11, the differences are very subtle. pellewa's description is spot on. Although, I'm almost sure that since 10 SR3, the Create Object macros are even working.

Without getting into the "is the plugin going away" conversation, I can tell you that in the last 6 months, we've probably built around 6-10 apps, and all assumed AJAX.