Are Web Interfaces "Good Enough"?

I’m a web developer, working with PHP as my primary server-side language. Coming from a web development background, I can tell you it IS possible to make pretty, working code that performs many functions of a desktop app–especially with AJAX.

For instance, take a look at http://www.thephppro.com --look at some of his product demos and their source code. I work for this guy and have used his AJAX system before, and let me tell you it works like a dream. Two simple function calls on a PHP page will produce all necessary XML formatting, return data to the page, and overwrite any necessary element in the page. One of two different function calls can be used to request this data.

Using this technique I created–with relatively minimal effort, good OOP standards, and clean, efficient code–an application that can update large or segments of a page with information from a server-side database as necessary, modify the database and return results based on the modification in less than 100ms (depending on the client’s connection speed).

Again, take as an example Google’s Docs and Spreadsheets web application. Though I can’t speak for its code, having never seen it, their interface and abilities are nothing short of fantastic for a web app. Sure, it’s different than a desktop application–I won’t say worse, for though it does lack a few features such as default font selection, it has a whole range of features, many of which are inherent to web apps–such as being able to access your saved documents from any computer, anywhere in the world. Google Docs and Spreadsheets goes so far as to offer you the ability to save in formats including HTML, Word/Excel’s .doc/.xls, and several other formats not supported even by Office.

I won’t continue listing examples, but there are many, many of them out there–it’s mostly a matter of A. finding them, and B. finding people capable of making them. :slight_smile:

here’s another argument … even if I use 90% of the features of Excel 1% of time, I feel snug knowing that the rest is there when I need it. Akin to getting a 500HP car. You get the idea.

And pretty glad that Bill Gates et al , did not believe too much in the “path of least resistence” argument , otherwise we all would be happily chugging along logging into our *nix terminals. The point being , that many great innovations in computing have come about because somebody refused to take the “least resistence” path , built it and then they all came. 2 cents.

Doesn’t anyone see the problem that internet transfer speeds will NEVER be the same as system bus speeds… and thus, as fancy and ‘interactive’ as web apps get, they won’t be able to be as responsive as desktop apps. People will always have to wait: for the site to load, for the next ‘page’ (or in-page widget) to load etc.

I personally hate waiting… that’s why I spent thousands of dollars on a high end system. Otherwise a P2 would be enough. In software ‘good enough’ is usually never good enough.

Steve: The whole point of AJAX is to move more of the processing to the client side. Theoretically you could have the whole application load over the web, then through client side scripting it would run just as fast as a native app.

Of course, loading it over the web would be slower…

Some things you can’t do through the web UI, and their lack can be very conspicuous if you’re used to them.

A MAJOR one is that you can’t drag and drop files into your “application form” (to upload them, for example).

Another one is that you can’t load local icons from your desktop. Sure, the server can guess at your icons based on your operating system, but that’s about it.

You can overcome these with Java, but that’s a little not in line with AJAX, is it?

ON A RELATED NOTE, I WOULD ACTUALLY LIKE TO ASK THIS QUESTION:

We have, on the one hand, a standardized virtual machine platform such as .NET CLR or the Java VM. It has lots of classes already that you can work with, and it’s JIT-compiled to native code. Seems like a good solution for platform-independent applications! One thing that’s missing perhaps is wide deployment and a standardized front-end. If you want a less full-featured version of this, you can use Flash, which is VERY widely deployed.

On the other hand, we have HTML, Javascript, and a bunch of stuff to create and manipulate WEB DOCUMENTS. We are trying to make DOCUMENTS behave like APPLICATIONS! It’s kind of pathetic compared to everything you can do with the Mac OS or Windows or Linux. I mean, these OSes have had their APIs mature and become powerful tools for using the GUI and file system, and so forth. The base platform for your apps written in .NET or Java is a VM with JIT, which has a consistent spec across platforms. The base platform for modern WEB APPS is javascript running inside a DOCUMENT RENDERING ENGINE, i.e. a BROWSER… and these days, with the web being what it is, WHAT IS THE SENSE IN HAVING DIFFERENT BROWSERS AT ALL, IF THEY ARE ALL SUPPOSED TO DO THE SAME THING AND FOLLOW W3C SPECS?

I mean, isn’t it kind of silly that instead of having a base VM and a standard graphical subsystem, we have javascript which is interpreted slightly differently by each browser, and a document model that is interpreted slightly differently by each model, and our interfaces are literally documents hacked to be front ends to applications?

But imagine if web apps were written in MONO and ran on your system, instead of in your browser. If the internet was designed now instead of in the 1990s, I believe there would be documents on the one hand, and applications on the other. And applications would run in a standard VM with a standard GUI, have GUI standards, and not all look different on different browsers.

THOUGHTS?

I’ve thought about this for quite a while, you see.

Telos: I’ve only done limited development for the web, so I only know the theory behind how AJAX is supposed to work… but how would that be any different from a thin client, except that it’s loaded in a browser? And if that’s the case, then why bother with all of the cross-platform issues, and just make a thin client that has tried-tested-and true UI controls from the OS?

Isn’t it about time Web 3.0 replaced browsers with consistent renderers? But how to deploy to all the desktops? Ah, that’s flash, and perhaps java.

So flash sounds like the future. Maybe I’ll be investing in adobe :slight_smile:

Most of the technology for pretty good desktop/web clients is now ready, if a bit fragmented in the various offerings (XUL, XAML/WPFE, Flash/Flex/OpenLazlo, Java WebStart, etc.). What’s needed are some kind of common, simple industry standards, a la Web Standards (HTML, CSS, ECMAScript).

I don’t expect people who have a lot of .NET code will want to re-code in Java, nor vice-versa. But without some emerging standards, developers and users will be subject to endless struggle and flailing while the “war” is fought. To get standards going, I think participation would be needed all the major players: W3C, the Web Standards movement folks (Zeldman et. al.), Microsoft, Sun, Adobe, Apple, GNOME, KDE. (Ha! I just realized what a ridiculous Holy-Grail pipe dream that last sentence was.)

We are trying to make DOCUMENTS behave like APPLICATIONS!

This comment from GregMagarshak sums up in a few words the nebulous discomfort and vague dread that I experience whenever I work on a web app.

I always get one of two feelings.

Either I’m rigging things together with bailing wire and twine…

Or I’m trying to get a square peg through a round hole, without changing the it to the point where it disappoints all the people on the other side of that hole that are expecting a square peg with clean, sharp edges.

To put it bluntly, applications are square pegs. Web browsers are round holes. Something has to give.

WPF/XAML will end up being the replacement for flash and html. The fact that it will be easily remotable is also a big plus so you can have your cake and eat it to. Instead of sending raw screen data across the wire you will be receiving XAML commands and having them rendered locally. And Microsoft already has WPF/E which runs on Windows and OSX. In about two years we will hit the infamous “SP2” stage for WPF and it will be a viable technology for both web and desktop apps. And why shouldn’t it be? Why have desktop apps taken so long to catch up with what the web can do as far as content and layout are concerned?

I’m a Microsoft fanboy and this is how I see the future through my rose colored glasses.

Steve: Sure you could use a thin client, however what do we do? Have everyone create their own thin client to host their server based app, then have each user download it? It kind of defeats the biggest benefit of a web based app then, which is that all upgrades/deployment can stay on the server and all users get it instantaneously next time they use the application.

Besides which, essentially what we are doing now is using the web browser as the thin client. It may not be ideal from our perspective, but everyone has IE on their machine. (Everyone who counts, sorry Mac/Linux people. :stuck_out_tongue: )

I guess it goes back to least resistance again. Maybe someone will develop a standard thin client someday, and everyone will use it. Until then IE serves that purpose well enough.

Don’t forget that Steve Yegge has (in my opinion) stated that Adobe’s Flex/Apollo framework will take over. See:
http://steve-yegge.blogspot.com/2007/02/next-big-language.html

I like Microsoft’s WPF/E, but the fact of the matter is, WPF/E has 0% market penetration and Adobe’s Flash has, what, 97%? More?

I love that the screenshot includes a download of ‘The Chronicles of Riddick’. (Decent flick).

:slight_smile:

One my better college professors told me once that knowing what is “good enough” is the hardest lesson a programmer can learn, because it’s never perfect unless you do infinite improvement iterations, and you don’t have that much time.

I’ve always preferred a mix of flash and php over javascript, but there are times when people try to get too much from flash. Theres this annoying School Yearbook software run by johstons which is an interesting exploit of Flash, but is poorly designed. There would have been much better ways of making it on the web. There have also (oddly enough) been offline typing applications made in flash…which fail miserably and are annoying. Flash has many applications, and when properly used, it can be pushed hard, but when you start doing something complex as online programs that imitate offline ones - your better off with CGI, PHP or Javascript.

HI;

I’m an idiot; where can I see where XAML differs (abstractly and concretely) from being an XML-markup of an XServer C/S stream?

(Help) Teach me Obi-wan, you’re my only hope… I want to be on this bandwagon before the crowd discovers how cool the coffee is over there.

Yeah Morfik sounds like a great solution, but how does it execute on the server side? It looks like you have to use their proprietary Apache plugin, right? And you are able to use databases but all your computation is on the client side in obfuscated javascript, not on the server side – am I right?

Greg

Jeff,
The Torrent browser-based UI provides you with the ability to remotely administer your torrent system. You are willing to give up the rich UI for the benefit of remote administration (thus not needing to remote-desktop into the client).

What if in addition to providing a web UI, Torrent allowed you to administer any Torrent system from the rich UI? Would you still use the web UI?

One barrier to rich clients that browser based clients don’t have is installation. Imagine upgrading a critical client/server corporate application with rich clients installed with a setup.exe. Imagine trying to ensure that all 2,000 workstations are simultaneously upgraded. That is enough to give any IT admin nightmares.

Technologies like Java Web Start and Click Once are endeavoring to eliminate the installation issue. Once the corporate application server was upgraded, the users would download an upgraded rich client the next time they start the application. When these deployment technologies are mature, you the user will likely be oblivious to the download, just as they are oblivious to the download all the html, css, and js files that make up a web application.

Take a look an any of the XAML based XBAP applications. Surprise! XBAP applications are deployed via Click Once.

Many of the “applications” we use today are really services. Email is a service. Chat is a service. iTunes is a service. The service just happens to be hosted on my computer, which means I get the pleasure of maintaining it, backing up files and what-not.

Let’s see, what else do I have open? SQL client. Service. Command shell. Service. Windows Explorer, but only so I can use TortoiseSVN, which is a service.

I have Google Calendar open. The UI sucks, but I value being able to access it anywhere over being able to view and make changes easily.

And I’m listening to Pandora. And replying to your blog, through a web browser. I got to your blog via Google Reader. All services.

BitTorrent, of course, is a service. I’ve never used it, but I don’t know why it has to have a fancy GUI. Other than detailed monitoring (because you’re a geek), it’s just search and download right? Just like the web.

On the other hand, my IDE is a desktop app, and should be. And of course you can’t have a web based web browser. Desktop apps will never go away completely, and that’s okay with me. But the ones that are nothing more than specialized clients are starting to disappear from my hard drive.