Web based applications
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
I think from your questions that you're looking at things the same way I did about 3 years ago..... Well I can tell you why people want things web based -- they like being able to run an application from anywhere in their building, plant, WAN, home....and they like being able to avoid installing software to do it....in most companies there are so many applications, and they can't install everything....and it takes time to install software....if changes are made to the software, the user has to reinstall the app....ick! As for the downsides to Web Apps: 1. Browser comatability issues: Big issue....when we wrote a web based app, we tested with IE for Windows....IE for Mac generates different events for the same action (like a key press event for example). Netscape lagged far behind IE....maybe its better nowadays, but we now tell our customers we only support IE which hasn't been an issue. 2. Clinet side scripting is primative. What else can you say? Your alternative is Java....but it often executes slower than scripts and tends to be larger. 3. DO NOT CODE USING SCRIPT LANGUAGES ON THE SERVER! Are you nuts?!? Its bad enough that that have to use scripts on the client....use them on the server and you've given up speed and early error detection....not to mention that while you can write reusable JavaScript, its much harder than writing reusable C++! And if you already HAVE C++, why not use it! (I'm assuming that you know you can create a COM object in an ASP page and can pass the Response object to your script). 4. Web based apps are based on HTTP....which is indeed stateless....so your client page is going to have to provide state information. Seems like a problem at first, but I don't usually find it to be a big issue.....you just have to be careful to pass something which will maintain your state from page to page or maybe use session variables.
-
I think from your questions that you're looking at things the same way I did about 3 years ago..... Well I can tell you why people want things web based -- they like being able to run an application from anywhere in their building, plant, WAN, home....and they like being able to avoid installing software to do it....in most companies there are so many applications, and they can't install everything....and it takes time to install software....if changes are made to the software, the user has to reinstall the app....ick! As for the downsides to Web Apps: 1. Browser comatability issues: Big issue....when we wrote a web based app, we tested with IE for Windows....IE for Mac generates different events for the same action (like a key press event for example). Netscape lagged far behind IE....maybe its better nowadays, but we now tell our customers we only support IE which hasn't been an issue. 2. Clinet side scripting is primative. What else can you say? Your alternative is Java....but it often executes slower than scripts and tends to be larger. 3. DO NOT CODE USING SCRIPT LANGUAGES ON THE SERVER! Are you nuts?!? Its bad enough that that have to use scripts on the client....use them on the server and you've given up speed and early error detection....not to mention that while you can write reusable JavaScript, its much harder than writing reusable C++! And if you already HAVE C++, why not use it! (I'm assuming that you know you can create a COM object in an ASP page and can pass the Response object to your script). 4. Web based apps are based on HTTP....which is indeed stateless....so your client page is going to have to provide state information. Seems like a problem at first, but I don't usually find it to be a big issue.....you just have to be careful to pass something which will maintain your state from page to page or maybe use session variables.
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
Funny, we're re-writing one of our client's major applications. It definately needs it... it started life as a Windows 3.1 application, was ported to 32 bit, and just eventually got out of hand... too big, unmanagable. So, it needed the re-write. However, the client insisted on a web application! 90% of this application runs on the client utilizing ATL COM objects (many of them). It's not a good fit but you have to give them what they want.... besides it's turned out to be a lot of fun. 1) We don't support Netscape and since this application runs only inside the client's firewall... IE is required(5.0 or higher). 2) True. What's worse, we've found several examples where JScript didn't give us what we needed so we've ended up heavily utilizing both VBScript and JScript. Still, though we really struggled at first, I haven't found anything I couldn't do so far in IE that I could do with MFC. It just takes more work. 3) ASP is extremely difficult to deal with. Microsoft is promising the ability to debug ASP on the server in Visual Studio.NET. I can't wait. 4) You can certainly maintain states.... With COM writing web apps is really not very difficult.
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
I feel the need to put on a really bad tweed jacket and start smoking a large cigar while shouting 'Have we got the solution for you!!!' .NET dude. Seriously though, as others have said: distributed apps make it easy to work offsite or from any machine, and if done right, from any device. ASP.NET deals with (1), (3) and (4). Newer and more feature rich versions of IE deal with (2), and where the client machine has a low-end browser, ASP.NET (if written correctly) degrades gracefully to handle this. The one thing I would like to see ASP.NET address is client side scripting. cheers, Chris Maunder (CodeProject)
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
Hi, Like previously mentioned, Web based apps are easier to maintain and distribute than Client/Server apps, plus they're "web-based", which to some people means, "They're cool". 1. Browser compatibility can be a major issue or not at all if your clients all use IE 5. 2. Client side scripting is not the same but pretty close on IE. DHTML on IE gives you full access to the elements and you can do just about the same thing as with C/S apps. 3. Server-side languages vary. If you use VBScript, it's quite simple to use but it doesn't offer the benefits of strong-typed languages. I've used Visual Interdev to write and debug ASP scripts without problems. You can even use it to debug client-side scripts! Alternately, you can use JSP on the server side which means using Java -- a strongly typed class-based language with C++-like syntax. I like that too but I haven't had much luck finding a nice tool like Visual Interdev to write and debug with. 4. HTTP is stateless but you can maintain state in several ways. There's session variables, cookies, hidden fields, and my favorite: ASP remote scripting. Regards, Alvaro
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
MS hopes to steer people more toward rich client web apps with .NET See http://discuss.develop.com/archives/wa.exe?A2=ind0107B&L=DOTNET&P=R49813&D=0&H=0&O=T&T=1 But there are some weaknesses with the scheme: http://www.quicktopic.com/8/H/jLvW5DSBG4Wn/p-1.-1 CodeGuy http://groups.yahoo.com/group/wtl
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
Have you considered "reflection" technologies? In other words your client/server service, or whatever you've got _not_ http protocol based can still become "web" enabled _without_ a single line of code from your part. Check this out: http://www.citrix.com/products/nfuse/default.asp. The basic idea is that whatever UI you have is "reflected" on the destination machine. The destination machine may run Windows/Unix/etc. You being a UI user have a list of "published" apps. Each app is a symbolic name that the Citix client has acquired from the list of published apps. When you execute an app, just like any other app, by double clicking on the icon, the Citrix client goes to the Citrix server and establishes a connection with it. Then it send a request that the requested app is to be executed. So the server does that. So you end up with the UI being executed on the remote machine, but the remote user can see it on its machine. This remote user sends commands (mouse/keyboard clicks) to the your UI via Citrix client/server, then result is reflected back on the remote machines monitor. Now they have already implemented a COM and a Java client. So your app will ultimately run in the browser's window. You don't have to rewrite you program from scratch! I think its a pretty clever solution and it just brings us all back to the fundamentals of being "www" - it's just another network protocol layer that has been implemented on many platforms and the clients for this protocol are well spread. That's all. No magic here. I think managers’ tendency to switch to www solutions has more to do with the idea that all of the components of a distributed system has to be combined of standardized technologies. Here we have a standard network layer with reasonable security provided. But I think the way the www market is developing right now, we can see a clear “let’s do it my way” behavior pattern. I have a strong feeling that at the end the HTML, XML and whatever else standards are going to be striped down to some sort of messaging layer that is convenient to its initial designer. That designer is most likely to be a company that will suppress other companies/communities by the dominating amount of technologies adopted by the www market . After all a protocol/API/whatever becomes a standard as soon as enough number of users start using it on a regular basis. I think that’s where Microsoft is headed. If one could not just proclaim itself as an Internet leader (or even the Internet itself
-
Are there any products or initiatives to develop a stripped down version of browser with features added to support web based apps ?
Not that I'm aware of....but at the same time, if you're working with Windows boxes, you can expect some flavor of IE to already be installed. As for an enhanced browser for web based apps....that would sort of defeat standard browsers wouldn't it?? Afterall....if the user has to download and install a special browser to support your app, you might as well have them download and install your application!
-
Hai all, I have been developing desktop apps and have recently started working on web based apps. Why is there such a big momentum towards web based applications, even in controlled environs like intranets inspite of problems like 1)Browser compatability issues 2)Client side scripting is n't comparable to FrontEnd languages .support for normal destop UI's like menu, context require high level of javascript, DHTML & browser behaviour competence. 3)Server side scripting environ like ASP are difficult to maintain, debug and don't offer all the features of a prog language. 4)Web based apps are based on Http - a stateless protocol, adding additional complexity to application developer.
I'm impressed by Mambo Server. www.mamboserver.com Its a Aussie product and PHP and works very well, users can administrate the articles / look and feel of the site online.