source: http://java.dzone.com/news/desktop-versus-web-application
Advantange:
1- Web is shaping software world: After client-server applications era, every company tried to port their applications to web. But this was very hard since this selection requires very different technologies; HTTP, HTML, XHTML, DOM, XML, CSS, Ajax, JavaScript. ERP vendors still hasn't completed this effort since complete rewrite needed. Web world is still evolving; Web 2.0 and client-side Web is recently booming.
2- Browsers are deployment tool: One of the most important problems of application is release and deployment management. This problem had 2 part; 1st is for server-side and 2nd part is client-side. Web-based applications solves nearly all problems of client deployment since requires zero installation. Browsers are evolving in their own direction with many improvements and standard support (i.e. caching, rendering, new CSS specification support); browser-based Web applications utilize all new features with zero price.
3- Network is getting faster: One of the most important problems of the web application is downloading pages and its content. As the network speed increases every day, both in home and offices, web page downloading becomes faster and faster. This leads much more satisfactory user experience in the UI.
4- Web programming is easy: In java, this is true but for other languages like VB or Delphi this may not be true. java has very strong server-side capabilities. HTML and JSP provides declarative programming which is much more easy compared with desktop-based applications UI development. If true frameworks are used or developed, code generation is very easy. I think the only hard part is in client-side JavaScript which Ajaxian libraries are still trying to solve. Hardness of the JavaScript programming is caused by both the nature dynamic language and the distribution of client function into both client and server code.
Today, after years of heavy server-side only development and lack of understanding even JavaScript and java difference, software world are awaked of client-side capabilities. In 2002, we were working our own JavaScript libraries and I had noticed that although many DHTML features added to JavaScript, there was mere usage in software world. Ajax is not a new JavaScript technique, we were using this technology with the name of Remote Scripting. Coming to 2004 and 2005, eventually Ajax had appeared as the cure of some problems. Today, web and desktop application gap is not yet filled. Some part of this problem is from the reason that JavaScript features are inefficiently or wrongly used (i.e. missing of server-side code support). Some part is caused by the nature of web platform.
Let’s try to list what was the rich functionality of desktop applications that we are still trying to fill:
1- Windowing System: Multiple document function is much more advanced in desktop applications compared with browser pages. Inter-document relation is very hard since some events may require navigation and this causes delay. Popup pages can’t be customized very easily; for example IE modal dialogs don’t allow you to navigate (we could achieve this with iframes). For filling this gap, many JavaScript libraries try to invent their own windowing system with layers, but most of them problematic (heavy or not easy to integrate with server-side).
2- Tab Component: Tab pages are micro edition of windows. Every tab page should be matched with a JSP page. But again JavaScript libraries were loading every tab content at one time. Partial loading of tabs may be recently utilized. We developed our own tab components which supports many sub-tab levels which were not existed in even most of advanced JavaScript libraries at the moment. We could implement that because of the help of server-side JSP pages. I think, currently available rich tabs are still can’t be easily integrated with your server-side page or object model.
3- Grid Component: We have searched a grid component many times but for many years web-based grids couldn’t reach to the desktop grid functionality. Only a few years ago, in-line editing etc. could be added to the feature list of web grids that DOM capabilities explored at last. We firstly developed a list component for the some functions of grid component (Sorting, Filtering, Selection, Paging). We could finally developed a grid component with has in-line editing with the help of Ajax. Our grid component supports many cell input types, insert row which eases data entry.
4- Master-Detail Forms: To provide this functionality, we must have grid functionality since Detail is formed with many input lines. After developing grid component, we easily supported this structure with detail tabs. One of the most important problems of this structure is mapping master-detail form into JSP pages. Current web-based master-detail solutions mostly don’t have detail tabs (One detail) or detail in-line editing and insert row causing to navigate another page for insertion.
5- Poor-Featured HTML Components: For many years, native form components are not improved. HTML 5 had many exciting components but should be earlier. Every JS library developed their own components to add features, but complexity and heaviness of those components still prevents us using them. I see many efforts; magical combo-boxes, super auto-completing text boxes, masked inputs etc. I think added feature value of these libraries doesn’t weigh its cost. We could only use partial codes like menus, tooltips etc. not the whole JS library. One of the big challenges for this is browser compatibility which still a burden of JavaScript coders.
6- Navigation: Page navigation causes UI interruption and users have to wait your page or component load. With the poor of server or network performance, users’ application satisfaction diminishes. Ajax libraries try to decrease page navigation, and this brings new problems. One of the major problems is that we have to synchronize server-side JSP page state with client-side state. Everything done in JSP pages should be done in JavaScript which causes us to keep track of 2 states. This is duplication of efforts and another burden on Web programmers.
7- Client Host Access: HTML doesn’t have this functionality. You can’t access client PC from Browser since security. The only feasible way to achieve this was using ActiveX components which are platform dependent and requires some security setting changes. Web site may not require this feature but as ERP web applications, we needed native printing or some manufacturing device access through the client host. Desktop applications are much more comfortable since have nearly no restrictions.
As the development and enhancement continues in Web world, we will see if this gap filled in the coming years. As a supporter of Web-based development, I think desktop applications will not be replaced completely with web applications. Both architectures had some powerful aspects and every software should be placed to the true platform considering software requirements. I give following link as a supporter of this idea: http://www.infoworld.com/article/06/10/02/40FEbrowseapp_1.html
