Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
Don’t get me wrong. I am a big fan of Ajax. In fact I spoke on Ajax at the Progress Exchange conferences in 2006 and 2007, and was very excited to see that several customers were speaking at Exchange 2008 on how to use Ajax with OpenEdge. However, given all of the hype around Ajax, I was surprised to see a recent Forrester Research report, reported on by ComputerWorld,
that Ajax is not exactly living up to expectations.
You see conventional wisdom would say that with Ajax, we have finally solved the rich vs. reach problem. No longer do we need to decide if we want our
applications to give users a rich dynamic experience that is tightly integrated
with the desktop like a traditional desktop application, or do we want to allow
our users to have access to our application where ever they are without
installing anything by building a Web (browser)-based application.
And while that certainly would be great, according to Forrester, apparently things aren’t as simple as that. According to the Forrester report while Ajax
is great for the “occasional user” or the “very infrequent user”, for the “power user, ' that is the user that is using the application for a significant part of the day to do their job, Ajax just isn’t holding up.
You can read the Forrester report, or the ComputerWorld article yourself to get all the details, but suffice it to say that the reasons why Ajax is not holding up is centered around rendering performance when building complex screens, and network performance because most Ajax tend to go to the server to do validation much more than they do in a desktop-based client-server application. And while many of the Ajax libraries do a pretty good job of hiding
differences across the latest versions of the most popular browsers, the
problem is not completely solved because many IT organizations use several versions of many different types of browsers and incompatibilities still do exist even with the latest versions.
So, what does this all mean? Should you stay away from Ajax? Of course not. What it does mean, however, as Salvador Vinals points out in his post in the
Progress SaaS blog, and as is discussed in the Forrester report, is that you need to pick the UI technology that meets the needs of the end-user, and if your application has multiple different types of end-users with different usage patterns, then it may be highly appropriate to support more than one type of UI.
So if you have occasional users or infrequent users, users that move around a lot, and need to be able to get to the application from where ever they are then you certainly should consider building a Web UI and using Ajax to get a richer experience. I certainly would encourage it.
However, if your users are power users using a complex UI and primarily using the application from one location, then using one of the more traditional desktop UI technologies may be more appropriate.
And because we know that needs of the users and UI technologies change fairly frequently, one of the most important things you can do is architect your application based on the principles and guidelines of the OpenEdge
Reference Architecture so that you can more easily change your UI or support multiple UIs when the need arises.
View all posts from Ken Wilner on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.