Revisited: Google Suggest and GMail are a step backwards
I posted an article about three months ago called “Google Suggest and GMail are a step backwards,” (you can read it here) and many people read the article and thought that I meant something that I didn’t.
I’ve had time to think about the issue some more, and I’ve talked to people about it, and I think I can make my opinion clearer this time.
This entry is more technically oriented than my last entry, and you can probably read it more easily if you’re familiar with programming and software development.
Introduction
Web application development and desktop development have their benefits, but the latest trend of complex web applications like GMail and Google Suggest are abandoning years of desktop development progress for the simple reason of easy application deployment.
This isn’t necessary; with a little work, we can get the benefits of web applications while still using the frameworks and tools we’ve developed for years. We can have it all.
Part 1: A brief evaluation of web applications
I acknowledge that web applications are popular. Most of my friends use webmail for all their email. They do it because it’s easy, and they can check it from anywhere, and it provides most of the features that they want in an e-mail client.
So, users like web applications because:
- They open immediately (there’s no startup time)
- You don’t need to install anything to use them
- They work on every computer
- You are safe from viruses when using them
The first three reasons are issues of what software developers call deployment. Deployment is the process of getting a program onto a user’s computer so he or she can use it. The last reason is an issue of security.
Part 2: Using web applications sucks
As I described in my original article about GMail, web applications are usually less useful than desktop applications:
- They are usually more confusing and harder to use
- They usually have fewer features
- They perform slower, due to waiting for pages & data to load
- Data are displayed in static, simple formats (non-sortable tables, simple lists)
We all see web applications with these problems, and we accept them. It’s hard to make web applications that don’t have these problems. I think most people with experience in desktop and web development would agree that these issues are easier to avoid in desktop applications.
I think many people would say that GMail is a “good webmail program.” As I discussed in my original article, GMail lacks many features that Mozilla Thunderbird has, for example. There are people who say Thunderbird is not a good mail program. From this we can conclude that people generally have a lower standard for a “good webmail application.” I think that most people have a lower standard for web applications in general, as well.
Part 3: Developing web applications sucks
It doesn’t matter what framework or language you use - developing good web applications is hard, even considering that a “good web application” means less than “good application.” HTTP and JavaScript and HTML and web forms have been patched together over the years to allow richer web applications, but it’s still much harder to add a sortable table of data, or a dynamically updating search, to your webapp, when compared to a desktop application.
HTTP is a stateless protocol. People get around this using HTTP sessions and cookies, but the resulting behavior is not very cool (broken Back buttons, meaningless URL’s, etc.). Handling individual requests and responses does not map well to the idea of a coherent “application,” and using such a system as the basis for complex applications is unnatural.
JavaScript is a terrible platform for writing client-side webapp code. I think most people agree with this. Browser incompatibilities, lack of a useful standard library, and performance cost developers lots of time and prevent the development of useful features. Additionally a great deal of logic needs to be written twice - once in Java or PHP or ASP, and once in JavaScript, to provide a better experience for the user. This can literally double development time.
Finally, the limitations provided by HTML and CSS prevent useful user interfaces from being developed without a great deal of work. Desktop development frameworks have built-in support for complex, useful ways of displaying data, such as interactive tables, trees, graphs, and so on. While it’s possible to do these in JavaScript using the HTML DOM, it’s much harder.
Part 4: Desktop applications already work
The main point of my original article was that Mozilla Thunderbird already has all of GMail’s main features for sorting and reading mail, and that IE already has a dropdown box like Google Suggest. My point wasn’t that we should be using Thunderbird instead of GMail.
A huge amount of time has been spent refining desktop development. The applications we use like Thunderbird, OpenOffice, AOL Instant Messenger, weren’t written in a few months; they are the result of many, many years of desktop application development, both conceptual and physical. I think most people agree that modern mail programs are easier to use and more powerful than older mail programs like Pine.
As we move to web application development instead of desktop application development, we are losing a great deal of this progress that has been made. Features that are already present in desktop programs are being re-implemented only for the sake of making a web application.
Part 5: We could have it all
Desktop applications are easier to develop and to use. Web applications are safer and easier to deploy and open.
To make desktop applications as fast and easy to deploy as web applications, we would need to radically change the deployment methods we have now (such as installers). To make desktop applications as safe as web applications, we would need to develop them in a secure language, such as Java, C#, or Tcl.
To make web applications as easy to develop and to use as desktop applications, we need to completely re-implement features which are already present and mature in desktop applications. And, this implementation must work across browser compatibilities, and must be based on HTTP, HTML, and JavaScript, which were not designed for such applications.
I made a table to demonstrate:
| To use desktop applications | To use web applications | |
|---|---|---|
| What we need to do: | Drastically improve deployment methods and use safe languages | Completely re-implement the standard libraries available in desktop frameworks, on top of standards whose design conflicts with such features, and re-implement desktop applications using these libraries |
| Difficulty: | Hard, will take some time, almost nothing needs to be re-implemented except apps. using unsafe languages | Very hard, will take a long time & a lot of effort by many people |
I feel sure that improving desktop application deployment will be much easier and will require less work than throwing away all that we’ve done with desktop development and re-doing it using the web’s fragile languages and protocols.
I don’t think we should abandon the web, and I think being able to check your e-mail anywhere is cool. However, we can develop a method of making richer, better applications while still keeping the benefits of traditional desktop applications. We can have it all.
March 10th, 2005 at 6:23 am
> Desktop applications are easier to develop and to use.
This is where your argument totally breaks down. The desktop application is on its way to becoming extinct. The browser *is* the client. Operating systems will fade into the background being replaced by locally running portals. The standardized portlet will be the new application.
March 10th, 2005 at 11:03 am
Scott,
Why can’t the browser still be used, but instead we use Java or Flash? The _tools_ for doing JavaScript and XmlHttpRequest just plain suck! That’s personally why I think it is a step backwards…
March 10th, 2005 at 12:41 pm
> Why can’t the browser still be used, but instead we use Java or Flash?
No reason…as long as standards are adhered to and the presentation framework is cross platform. A JSR-168 portlet can render HTML, Swing, and Flash.
> The _tools_ for doing JavaScript and XmlHttpRequest just plain suck!
I generate my JavaScript using custom JSP tags. It is a very powerful solution.
March 10th, 2005 at 9:01 pm
Just because “The desktop application is on its way to becoming extinct” is a pointless argument. Kieth is arguing that web applications suck and desktop applications are better. How does the desktop application becoming extinct have anything todo with anything? I think Kieth is trying to point out that desktop applications going extinct is whats wrong with the whole situation.
March 11th, 2005 at 1:09 pm
How are dektop applications better? The GUI capabilities of web applications will relatively soon be comparable to those of desktop applications. When this happens why would a developer bother with having to create separate apps for Windows, OS X, Linux, Symbian, Palm, TiVo, etc. along with dealing with all the installation issues and having to support all the functionality that is provided for free when building cross platform browser-based applications; printing, support for plug-ins, etc. The question that Microsoft is asking themselves right now is how will they preserve their investment in monolithic complex dektop apps (Office) and prevent their extinction. I don’t see Longhorn and Avalon achieving this goal.
March 11th, 2005 at 1:20 pm
Scott, I get the impression that you didn’t read my article. It addresses almost everything you mentioned in your last comment. I don’t know if you’ve used Java before but it works on all the same platforms that HTML/JS work on. I’m saying we can integrate desktop apps with the browser, and get rid of installation for many programs, so you’d get the things like printing and plugins for free, without having to use JS and HTML.
March 11th, 2005 at 6:37 pm
I dare you to find or write a web based application that provides even 5% of the functionality of MS Office or OOo. And even if you managed to, the complexity of this application would be orders of maginitude worse than the “monolithic” version of the same thing. I dont see how you could ever match the speed, size, and usibilty of a desktop application using JavaScript the latest DRAFTED standards such as CSS3 and XForms. Not to mension you would need a compatible browser. A huge number of computers aren’t even running browsers that support even the most simple JS and CSS. You have to remember that home users are still using Windows 95 and 98 and using the defualt browser on those systems like IE 4 or 5, which we can alla gree has really really bad standards support in the way of JS and CSS. However, all these systems support Java. When you start running applications over a network, your going to be running into some serious bandwidth problems. Do you really want to clog your network with people ‘downloading coppies’ of their office suit? I wouldn’t.
March 11th, 2005 at 6:42 pm
> Scott, I get the impression that you didn’t read my article.
I did read it but was not able to buy into your premise that desktop applications are easier to use and develop than web applications. I can use a web site without needing to consult a manual. I used to develop desktop applications for the Mac in C++ and there is no way you will convince me that coding a full featured C++ or Java client application is simpler than developing an HTML/JavaScript web application with the occasional Java applet or Flash animation embedded in it.
> we can integrate desktop apps with the browser […] without having to use JS and HTML
You want to build a brower-based platform without leveraging any HTML or JavaScript?? What’s the point of this? Will you support the back button? It sounds like the platform you are describing would be better served being developed on top of something like JNLP rather than a browser.
> I don’t know if you’ve used Java before
I do have extensive experience with Java, HTML, JavaScript, and Flash. I typically start with HTML generated from a Struts or JSF server app. If I need JavaScript functionality I generate that too. If the app requires richer Java functionality on the client I write an applet. If I need animation I create a SWF file and a write a plug-in descriptor. Typically the applet and flash animations are data driven, generated from some XML file on the server.
I can generate most any interface using standard web application technology. If Google wanted to clone Thunderbird, I am sure that they could do it. The only valid observation that you have brought up is the issue of performance. I recall a time when C++ programmers refused to consider Java as viable because of performance issues too.
March 11th, 2005 at 7:03 pm
> I dare you to find or write a web based application that provides even 5% of the functionality of MS Office or OOo.
Who uses more than 5% of the functionality of MS Office? I would rather use simple web applications that are each focused on a particular task.
> A huge number of computers aren’t even running browsers that support even the most simple JS and CSS.
They can download the latest version of Firefox. It is compatible with Windows 98 and supports all the latest standards. Firefox Minimo will even run on devices like smart phones. How do you plan to port your desktop applications to these new devices that don’t have a desktop?
> However, all these systems support Java.
Not the same version of Java with the same level of functionality.
> Do you really want to clog your network with people ‘downloading coppies’ of their office suit? I wouldn’t.
No. However, with my approach they would only be downloading a spreadsheet or text applet when editing was required. Spreadsheets and text documents are easily presented in HTML and CSS.
March 11th, 2005 at 7:17 pm
Scott, I think we disagree so much, and have had such different experiences, and develop such different styles of applications, that we won’t agree about this without extensive discussion and explanation on both sides, and I don’t think this will happen on a weblog comment series. I think it will take actual development of the kind of deployment system I suggest, for you to be convinced.
March 11th, 2005 at 8:16 pm
Keith, I agree that abstract discussions on frameworks can be subjective? What type of apps do you normally develop? If you were to provide a simple spec of the type of application that would be well served by your deployment system then others might be in a better position to critique your solution. Is this solution going to be developed?
Myself, I am still convinced that ultimately most developers will be primarily assembling portal applications out of reusable standardized portlets that either they develop or obtain from 3rd party developers.
March 12th, 2005 at 2:00 am
Scott,
>Who uses more than 5% of the functionality of MS Office?
Hah, good point. Even so, I dare you to find a JS/HTML/CSS Word clone that supports the most basic features. I have yet to see one. The onlything that comes close (http://www.fckeditor.net/) is EXTREMELY slow (takes about 20x longer to start than word), is EXTREMELY buggy, and still doesnt have anywhere near the number of features as word.
>They can download the latest version of Firefox… Firefox Minimo …
Why download Firefox, and then the web app with less funcionality than download a full blown desktop app? Good luck getting any of your webapps that use advanced JS to run in that! Javascripts are slow on 2GHz machines, how can a cellphone with like 100mhz and a few meg of ram be able to handle anything worth using?
>Not the same version of Java with the same level of functionality.
What are you talking about? Even versions of java that existed before any of the latest web stardards existed can do more than a brand new browser.
>No. However, with my approach they would only be downloading a spreadsheet or text…
But every time they do download it, it is going to be re-downloading the whole ‘application’. I suppose it could be cashed, but it is still going to use quite a bit of bandwidth for X number of workstations over Y period of time.
Something that hasen’t been brought up yet is security. It is much easier to securea desktop app than a web app.
I think Macromedia also thought that webapps are going to be huge when they started making Flash more scriptable, but flash scripts are such a mess, and I have never heard anything of their big app portal Central except from their site. Flash was for animation, not applications. I think scripting and interactiveness in animations is pretty cool, but it makes for a very poor rich application platform however it is much better than javascript.
I am surprised you use such a varity of technologies in your web applications. It sounds like a serious integration nightmare. Not to mension maintaining your one application that uses at least 4 different logic languages (JS, JAVA, ActionScript), at least 3 different formatting/data/markup languages (CSS, HTML, XML), and at least 1 server side language (ASP, JSP, PHP, Perl). How do you sanely support something like that?
March 12th, 2005 at 2:46 pm
Scott, I develop applications like RPI Scheduler and Joust Secure IM which would be silly, terrible web applications requiring a lot of network lag and lots of server code.
March 12th, 2005 at 7:17 pm
Charlie,
> I dare you to find a JS/HTML/CSS Word clone
I don’t need or want a Word clone but if I were to create a text editor I would develop it as a Java applet and not as a JavaScript application. This Java editor would generate text content that could be then viewed as HTML/CSS.
> Why download Firefox, and then the web app with less funcionality than download a full blown
> desktop app?
Firefox would be a one time download. Most of the code for web apps run on the server…no downloading. I know Firefox is compatible with all the devices I own. Most desktop application vendors don’t have the resources to port their apps to all my devices.
> how can a cellphone with like 100mhz and a few meg of ram be able to handle
> anything worth using?
WAP is making a comeback. xHTML mobile profile looks promising. MIDlets are similar in some respects to desktop applications but I tend to position them as an XML-driven plug-in mechanism. Ringtones, wallpaper, and Java games are a billion dollar industry. These are mostly delivered using web applications.
> But every time they do download it, it is going to be re-downloading the whole ‘application’.
Nope. Caching is built in. Applets can even share cached libraries (jars).
> Something that hasen’t been brought up yet is security. It is much easier to securea desktop app
> than a web app.
I trust Firefox. I trust Java applets’ sandbox implementation. I trust Flash and Quicktime. Therefore, I don’t have to trust the supplier of every web application I use. When downloading desktop applications I have to spend time to evaluate the supplier so that I am confident they are not doing evil, time that I don’t have.
> Flash was for animation, not applications.
I agree. However these animations, usually providing some sort of interactivity, are just components of a web applications. With my approach I have a palette of component technologies to choose from. Each type of component has their strengths and weaknesses.
> I am surprised you use such a varity of technologies in your web applications. It sounds like a serious integration nightmare.
I don’t normally use all the component types within a single web app. However, they all work well together and often compliment each other.
> How do you sanely support something like that?
In most of the larger projects I have worked on, there are different types of developers and designers collaborating, each bringing their particular skill set to the table. The JSP, HTML, CSS, and Javascript work gets done by what is known as a content engineer. The Struts or JSF coding, JSP custom tags, servlets, beans, etc. are built by a Java engineer. On smaller projects I have been able to wear many hats, even UI designer, with success.
March 14th, 2005 at 3:32 pm
How did this turn into a web-app vs java battle to a java vs java battle? I support applets and java applications, so there is no need to defend those, I just dont think JS/HTML/CSS and all that are for applications, they are for content.
March 15th, 2005 at 1:43 am
Ease of Deployment is KING
I’ve done something three times over the past two weeks I never thought I’d do again: talk about the web as an application platform. Why, just over a year ago, I was explaining to anyone that would listen that “DHTML”…
March 15th, 2005 at 4:52 am
> I just dont think JS/HTML/CSS and all that are for applications, they are for content.
If you look at the bottom of this page you will see the text “Powered by WordPress”. I am pretty sure that Wordpress is a web application that uses HTML and CSS. Why aren’t we all using a superior desktop application to facilitate this debate?
March 15th, 2005 at 11:45 am
The VAST majority of the WordPress Application is server side. If the submit comments box started doing XMLHTTPRequests or whatever, and dynamicly adding comments to the page without reloading the page, then I would be worried. All the CSS and HTML you see on WordPress is for content.
March 15th, 2005 at 1:13 pm
I was interested in finding out what an expert in design and usability thought about this subject, so I asked Don Norman.
March 15th, 2005 at 3:11 pm
I read that response from Don, and I think he agrees with both of us. We all want applications which are accessible from everywhere, but we don’t all necessarily want to use fragile Javascript, CSS, and HTML to make it.
March 15th, 2005 at 7:52 pm
It’s funny that all these technologies are focusing on brining all the content and logic into the local browser. As Don said, you need to work on things locally to reduce the response time. If all your application logic (or most of it) is local, what your essentially building is a client-server desktop application around an HTML CSS JS FLASH whatever Framework. How is this any better than other cross-platform frameworks or envirnments like a full blown java application? At least with Java your only dealing with 1 standard.
April 2nd, 2005 at 1:20 pm
“I dare you to find or write a web based application that provides even 5% of the functionality of MS Office or OOo.”
Gmail is getting close. Not 5%, but maybe 3%: it now supports rich formatting. See “GMail as the Notepad of the Web” - http://jonaquino.blogspot.com/2005/03/gmail-as-notepad-of-web.html
May 19th, 2005 at 5:30 pm
Nice discussion,two completely different school of thoughts. Not sure which solution is preferable but it seems that people are more interested in developing Web Applications, the enormous development of web applications don’t make it best choice. There is very beautiful world beyond emails, come to real issues of Grid Computing, Scientific Computation, Workflows for web services. Are they suitable for Web Applications? Scientific Applications have lot of data, lot of computation to be done and it is better to have desktop implementations so user can use his OS for most of basic work and submit partially done work on Parallel Mainframe Computers. Applets have limited access to the OS resources so they are useless. Desktop applications have much better user interactivity, our scientists are not programmer they want to develop workflows by drag and drop, they want to store in-complete project to resume next day, how this can be achieved by web applications. It is easy to say that Web Applications let you login from anywhere … no setup headache …. no restriction of personal computers or location. It is entirely wrong … Login is not only username and password, our users have Digital sgined certificates to login … they can’t access their account from everyo
May 19th, 2005 at 6:09 pm
from everyones computer or from anywhere … for scientific computing cookies, url re-writing or hidden fields can’t work for session handling based on large quantity of data. Saying desktop applications will be soon part of history is un-acceptable. It is not possible to integrate desktop apllications with web applications but integrating web appilcations with desktop applications is possible i.e. JDesktop Integration Components (JDIC)(http://javadesktop.org/articles/jdic/index.html). In the end my understanding is that both type of applications will continue to grow, they do have overlapping in few cases but still they can’t outclass each other.
June 1st, 2005 at 8:41 am
News flash: both desktop and web apps will continue to exist. Neither is becoming extinct.
The apps I use most are a mail program, a source control application, a bug-tracking system, a highly customizeable text editor, a few IDEs, Windows Remote Desktop, and VMware.
I don’t think Remote Desktop and VMware are going to be replaced by Ajax apps. Same for the IDEs and the text editor. The source control app is a desktop app. There’s actually an intranet web-based version of it available for free. But I won’t use it unless it stops sucking. All these apps are too close to the hardware and/or the filesystem. There’s no way they’re going to work as web-based apps.
On the other hand, the bug-tracking system is a desktop app. It should be web-based. Web apps get free printing, copy/paste, e-mailing, linkability, and bookmarking, all using the standard browser UI. I only wish this program had all that.
More to come.
June 1st, 2005 at 8:58 am
The fact is, most apps are written by small teams that don’t have the time to do a good job, managed by people who don’t have the spine or vision to pick a small, good set of features and stick to them. For these apps, particularly internal apps for a company’s employees, a Web-based app is a lot easier to throw together, and orders of magnitude easier to support.
For those fortunate few actually in a position to do a good job, you just have to pick your poison. Web based apps are slow, annoying, baffling (often), scary (as they tend to lose data occasionally), quick to develop, incredibly complicated to develop and full of hacks (as the project grows out of control), searchable, printable, bookmarkable, beautiful, secure, and cool. Web based apps using Flash are tiny (typically using some small fraction of the screen), annoying, unusable (usually), musical, bright, cheery, cute, and fun. I find them hellish. Desktop apps are rigid, clumsy, ugly, crashy, memory-guzzling, a pain to install and upgrade, fast, well-integrated, powerful (in a Dark-Side-of-the-Force sort of way), and they can access the disk.
In a lot of cases it’s a toss-up.
June 1st, 2005 at 9:29 am
One more thing: “Ajax” feels like “Extreme Programming”, a tag applied to a bucket of vaguely related techniques, driven by a single successful project.
“Ajax” really means “all the really cool stuff they did in Google Maps”. Which is to say: pre-loading data into the browser; using XmlHttpRequest; using lots of Javascript to make the UI very interactive; a mouse-intensive UI; a very clean UI; doing something really useful that no one else did before. None of these is particularly tightly tied to the rest.
XP generated a ton of excitement and never really went anywhere. But we got test-first out of it, and it looks like that may come back in 15 years or so, when the industry grows up a little bit, and become a standard practice. Ajax sounds like it’ll have a similar trajectory: most of it never gets of the launch pad, but something worthwhile (I’m guessing XHP) will slowly be adopted.
June 11th, 2005 at 6:57 pm
The reason everything is going web based is in so many ways exactly why you say you dont think you can build as good of an app. (which is is wrong - I could easily recreate 95 precent of word using nothing but php and script - point is, why would someone re-invent the wheel?)
But anyway, web apps have huge advantages
1) Portability - its where ever you go.
2) Simplicity - yes, its not as feature rich as a desktop ap - Thank God for small favors - it tends to focus on what it does, and do that only.
3) Speed - really, I find it much faster to load up gmail than Outlook (though I use neither). Script only front ends are extremely fast. Its only when you throw Java and flash into the mix that they slow down.
If you need a more robust application than is available through script, though I strongly believe there is few times that is the case, that is what Plugins are for. After all - that is all that Flash is - a plugin/activex/whatever - same thing. You can literally take just about any program created with MS tools, and make it into a plugin that runs from the browser.
Personally, I think the only place to be looking at for the future is browsers. Seems like just about every program being made these days has a browser in it, or something like it. (I wonder what IE’s market share would be if you included every application that uses the webbrowser control?) Those that come up with the best ways to utilize the best of the web, and the best of the desktop - win - the days of their being an even thought of difference are also coming to an end. Programs will become intertwinced with the web more and more to the point where, yea, you have a desktop program - but it wont be able to run unless you are online as that is where config, settings, etc are kept. That also is going to become more and more common. Why on earth do I want to have my settings on a desktop computer? That means, I am on a business trip - using another computer - I have to deal with not having what I am used to, or use a laptop - which is a pain in the butt to switch back and forth from (keyboard size, screen size, keyboard difference) - and before someone screams security - really, think about it - how many of your config settings are you really gonna care if someone steals?
June 21st, 2005 at 12:49 pm
These types of discussion are hilarious. Anyone who is a serious developer does not make sweeping statements such as “XXX is going to be extinct” or “XXX is a step backward”.
Desktop vs Web based apps is really about what is the best tool for the job. You should be flexible enough to understand which application method works best for what you need. It seems that many folks try to apply their one sided knowledge and dismiss everything else as a “hack”. This reminds me of the saying, when you have a hammer, everything looks like a nail.
June 22nd, 2005 at 3:36 pm
Keith,
Excellent article.
Along the axis of state-preservation, reactiveness and usability, it’s obvious that Web-Apps were a backward step from client-server. When I first got into HTTP and saw the techniques used to preserve state, it reminded me of old COBOL/CICS “pseudo-conversational” programming. That’s what it was — with a sexy front end.
As network speeds keep improving, we’ll see a return of techniques used in client-server platforms.
October 26th, 2005 at 3:53 am
Can any of the Web Apps people understand the phrase “I’m not always connected to the network when I need to use an application!!!????”
When I go to a customer site and sit in a meeting and want to take notes, I can’t take them in a webapp because their WiFi network is locked downa and they don’t want me on it.
When I get out of the Boston metro area and go to a B&B to get away and write a business plan in Word, do a financial forecast in Excel, and put together an investor presentation in PPT, I don’t even have dial-up access, much less broadband. Web-based versions of these are non-starters.
When I travel to Europe, where high-speed connectivity is much more expensive (e.g. WiFi is $10/hour), the last thing I want to do is pay $10 to spend my 4 hours catching up on the emails I’ve received since I left. (Instead, I use my desktop email client to do a “dip,” disconnect, handle the mail, reconnect and resynch. All for a buck or two.)
And when I’m on the plane / train, web-based stuff is a total non-starter. (And even when Internet access is available on the plane, I don’t want to *have* to pay to use it just to do my email or work on an Excel spreadsheet.)
When, oh when are developers — who sit in front of fat pipes all day — going to remember that they should NOT assume that everybody works exactly like they do?????
Give me my desktop applications now, and forever.
February 3rd, 2006 at 12:17 am
I aggree with parts of the article. There is no doubt with the thicker clients work well! I have started work using AJAX and ASP.NET - I gotta say - you have to add at least three times to gour in terms of development.
The good points of new style web interface is the retiring of annoying postbacks and ease of deployment. The bad side is the amount of work you need to do to get it out and working! Time which could be spent enhancing and improving the interface/features atc. Anf Jay makes a good point about the fact that you have a huge dependency - you must be connected to the internet to use them.
However - in reference to the article… I was VERY impressed with google suggest… and just because Google wasn’t the first to do it does not mean we shouldn’t use it. I see no mention on googles website that they were the first and only people to do this. To say they are a step back is a bit much - but you have some valid point.