Pinderkent

If more and more software developers are going to be developing browser-based applications using technologies such as JavaScript, Flash, and AJAX, we will need to see the Web browser become a much more capable platform. In short, the browser will need to duplicate much of the work that has been done over the years in the operating systems field.

One of the main problems affecting browsers today is that of resource allocation and usage. These are the very same issues that operating system developers faced in the 1950s and 1960s, when their craft was first maturing. These days, we have the browser acting as a code execution environment, and allowing for multiple, concurrent executions (eg. in multiple browser windows or tabs).

It's very easy for a malicious or poorly-written JavaScript to execute in such a manner that it locks up the entire Web browser. Some improvements have been made in this area, such as the use of watchdog timers that will prompt the user to kill the script if it has been running for a long time. But this is not the correct path to take. It only scratches at the symptoms, rather than curing the actual root cause.

Web browsers today need greater isolation between the different Web pages that are being displayed in multiple browser windows or in multiple tabs within a single window. Konqueror does this to some extent. Unlike with browsers like Mozilla Firefox or Opera, it is by default possible to launch multiple Konqueror processes at once. That way, poor JavaScript or a browser crash will only affect one window. Unfortunately, such isolation is either not easy or not possible to do with Opera and Firefox.

Unfortunately, Konqueror doesn't offer that degree of isolation when it comes to multiple tabs. A resource-consuming JavaScript in one tab has a lot of potential to lock up the entire browser window, rendering the other tabs inaccessible or essentially useless. Of course, the situation is far worse with Firefox and Opera, where other browser windows will be locked up, in addition to the tabs sharing the window with the problematic Web page.

A problem in one browser tab should never be responsible for a decrease in the availability or usability of another browser tab, let alone another browser window running in the same process. This is the most basic level of isolation, an it is a disappointment that after nearly two decades, even the most popular Web browsers cannot handle this task in a suitable manner.

Scott Rosenberg recently wrote about how it appears to take an AJAX-based Web application about five years to mature. The examples he gives include the new Yahoo! Mail interface, as well as the new Bloglines design. But I don't think he's looking far enough into the situation.

While it may take an AJAX-based Web application five years to mature, what we have to focus on is the end result after those five years. After that amount of time, one would expect there to be significant improvements over what was available five years earlier. But that's often not what we see with AJAX-based applications. While there might be some small improvement over the previous Web-based interface, there's still usually a major gap between the Web application and an equivalent desktop-based app.

The new Yahoo! Mail interface is a really good example of this. From my use of it so far, it looks like a lot of time and effort was spent working on it. Yet I think it was mostly in vain. It still just can't compete with actual email clients, such as Thunderbird or KMail. For most scenarios, using Pine or mutt (over SSH for remote access) is even faster and more efficient.

So it seems pointless to me to spend four or five years developing a Web-based application, especially when it will only really be equivalent to desktop applications from a decade earlier, if it even manages that. If Web applications allowed for easier, more rapid development, which in turn allowed for more innovative products to be created, then it'd be worth it. But that just isn't the case. We don't really see any innovation; we merely see poorly-done reimplementations of decade-old desktop software.

Thanks to the Agile Ajax blog, I've learned about Remember The Milk. Essentially, it's an online service for managing a to-do list. It apparently integrates with a variety of other services, including Gmail, ICQ, MSN, Skype, AIM, and more. It claims to also allow for task lists to be published and shared with others.

I have to say, it looks like a major over-complication of what should be a relatively simple thing to keep track of. Over the years I've worked with many managers and co-workers who've deemed it necessary to use some little digital doodad to manage their tasks and time. And I don't think I've ever seen such devices prove to be useful. If anything, they've more often than not been a hindrance to getting things done.

Even getting information into the things seems to be a challenge. Some I've seen have used a stylus. But those often require you to learn a new writing style that the device can interpet. Others have an on-screen keyboard, where you poke the keys with the stylus. Yet other devices have small keyboards built in. And I've seen other devices that come with separate, nearly full-sized keyboards that can fold up. Nevertheless, none of those methods ends up being very efficient.

Of course, then there's also a need to power these devices. Some use normal AAA batteries. Others have specialized power cells. And others need to be charged using some sort of an adapter. The power sources of these devices always seem to run out at the most inopportune time. Trying to get your to-do list off of one of these devices when it's unpowered is pretty much futile!

What I tend to see happen is that these people end up spending a huge amount of time with these devices. They struggle to input data. They struggle to find the data they've inputted. It ends up being a situation of task over-management. What was supposed to make their lives more organized, and thus increase their productivity, has instead rendered them useless for a greater portion of the day.

Most of the successful people I've worked with have just written stuff down on paper. They carry a pen or pencil with them, and each day they fold up a new sheet of paper, and put it in their pocket. Others have used a tiny organizer booklet that contains a calendar and contact list. Along with the wristwatch they typically wear, they're all set to manage their time wisely and effectively.

If something comes up that requires their attention, they write down a brief note. If they have an appointment, they write down the time. These people tend to check their watches often, and have more than a one-second memory, so missing an appointment is rarely a problem. Best of all, these papers can be filed quite easily, for future reference. There's no digging around on some device for old records that often end up deleted by accident, or trying to synchronize it with a PC somewhere.

So while the idea of Remember The Milk may seem novel, I really don't see how it's that beneficial. A pencil, a piece of paper and a wristwatch render it nearly useless. While somebody is still sitting there inputting their reminder note one keypress at a time on a handheld device, the person with the paper and pen has written down his or her note, and has moved on to doing something useful.

I was just reading an article about the future of CSS. A main focus of the article is on the extremely poor layout capabilities of CSS. One such paragraph from the article goes a long way towards showing the futility of AJAX development today: CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!

UI layout is one of those problems that was solved years ago by traditional UI toolkits. Besides absolute positioning and sizing, there are a number of very rich dynamic schemes available. There are the AWT and Swing layout managers. Windows Forms allows for dynamic layout. Qt offers some very capable layout classes. Even lesser-known toolkits, like FOX, offer very flexible UI layout schemes.

So there should be no shortage of inspiration when it comes to flexible, dynamic UI layout. This is a very critical aspect of most graphical application programs, and thus it is no wonder that it's a problem that has received so much attention from so many different people in the past. But thanks to their effort, we now have a pretty good idea about how to deal with UI layout in an effective, sensible manner.

Of course, this knowledge doesn't seem to be able to make its way to those folks developing Web-based applications using JavaScript. It's not a problem with the knowledge, of course. It's a problem with the people who willingly keep struggling with an unsuitable platform (the Web browser) that fails to adequately address such an elemental task.

So I have to laugh when I see a statement like, "It is time to create a CSS module for layout that works." No, it was time to do that a decade ago, when CSS was first coming into the scene!

Today I shared the experience a friend had with one of the companies he works with. It involved a failed transition from what was mainly a console-based suite of applications powered by Sun systems and Oracle, to an AJAX and Web-based system running on Windows, .NET and SQL Server. It seems that that entry was submitted to Reddit, and so I've been reading some of the comments that were left there.

Some of the comments were quite insightful. But there were two that I found to be just plain funny! Here is the first comment, and here is the second comment.

In those comments I am accused of being "biased against windows and ajax" and guilty of "discrimination against Windows & dot-Net". Well, I would like to address those allegations!

First of all, I've been doing this long enough to not get to attached to certain products or technologies. In the end, it's all about solutions that work to solve the client's problems in an efficient and financially-sound way. I'm glad that I get to mostly work with Solaris, HP-UX, AiX, FreeBSD, Linux and other UNIX-like systems. But I've worked with Windows many times before. As long as the job gets done properly, I really don't care what software is being used.

In this case, my feelings regarding Windows, .NET and SQL Server have absolutely no impact on the problems that that company experienced with their transition. Beyond hearing about it from my friend, I had no involvement with the development of the old system, nor any involvement with the development of the new system.

Furthermore, the fact remains that the old, UNIX- and Oracle-based system worked just fine. The new .NET-based system did not work in a suitable manner. Pointing out that certain software did not perform in an adequate fashion in a certain situation does not indicate bias. All it indicates is that the software in question was not capable of performing what needed to be done.

Likewise, the AJAX-based UI proved inefficient compared to the previous curses-based interface. That's just how things worked out. Again, my feelings, thoughts or biases would have had absolutely no impact on the situation, as I was not involved.

I do thank the two comment authors for their thoughts and opinions. However, I also urge them to be more careful in the future when accusing others of bias. Just because a particular technology fails to work in a particular situation, and this failure becomes a topic of discussion, there is not necessarily bias against that technology. Sometimes technology fails. We must admit this, and learn from such failures.