Note: most visitors to this page seem to be searching to find out why Firebug with the break all errors option detects an exception on obj.type. If that’s why you’re here, see the end of the article for edits that fix this problem.

I have seen the occasional attempt to build full windowing environments inside of a browser, and been only semi-impressed. After all, we do have mature remote desktop solutions like VNC. Why deal with the nightmare of browser inconsistencies when you can just set up a virtual machine of your choice, program to whatever hardened widget API you like, and let users control its screen through a terminal??

(That makes sense to me, and it will only make more sense as virtualization expands. For more on my thoughts, see the article “Virtualization and the Integrated Circuit”)

Putting this bias aside, I was somewhat inspired today by the Extjs Web Desktop Demonstration. Reading about the history of Extjs, I saw that it was conceived as an extension to the Yahoo User Interface Library. In fact, it could run on top of it and use its event model somehow. To test this claim, I got the idea to integrate the Yui Drag and Drop Groups Demo into the Extjs Web Desktop:

Despite my general ignorance from being on day one of meeting both of these frameworks, it sort of worked first try. I simply took the global variables out of the drag and drop demo page (slots, players, Event, DDM) and made them members of the created window object. I then substituted the HTML of the drag and drop space:

<div id="workarea">..blahblah...</div>

for the HTML that was in the default for blank windows in the Web Desktop sample:

<p>something useful would be in here</p>

The drag and drop worked as expected. But I use Firebug with the “Break on all Errors” option. And after gluing these two things together, clicking in the Extjs grid window causes a temporary halt in YUI’s connection-debug.js on line 240. It’s a little snip of code in _hasSubmitListener enclosed within a try/catch block, like so:

237
238
239
240
241
242
243
244

try
   {
   var obj = YAHOO.util.Event.getTarget(e);
   if(obj.type.toLowerCase() == 'submit') {
      YAHOO.util.Connect._submitElementValue = encodeURIComponent(obj.name) + "=" + encodeURIComponent(obj.value);
   }
}
catch(e) {}

What’s happening is that obj is div.x-grid3-cell-inner, which is an entity used by Extjs inside its grid. Yui somehow gets ahold of the click (how?), and finds the .type is undefined. This leads to an exception when toLowerCase() is called. Looking at the snippet I was puzzled… is the exception handling intentionally glossing over cases where the type isn’t defined? If that is the case, it would be much better to use a direct comparison with “undefined”:

if (obj.type != undefined)
   if (obj.type.toLowerCase() == 'submit') ...

If this situation isn’t supposed to happen, then the dereference of obj.type should be outside the try/catch block so that people who aren’t using Firebug with “Break on all Errors” will know they have a problem.

I posted about this to the YUI forum, and Thomas Sha (who works in the Yahoo platforms department) agreed that my change would be a good way to deal with it, at least until YUI 2.4.0 is released. So I made the following changes to yui / build / connection / connection-debug.js and yui / build / connection / connection.js :

237
238
239
240
241
242
243
244

/*try
   {*/
   var obj = YAHOO.util.Event.getTarget(e);
   if((obj.type != undefined) && (obj.type.toLowerCase() == 'submit')) {
      YAHOO.util.Connect._submitElementValue = encodeURIComponent(obj.name) + "=" + encodeURIComponent(obj.value);
   }
   /*}
   catch(e){}*/

In yui / build / connection-min.js, you should just replace the string:

try{var S=YAHOO.util.Event.getTarget(q);if(S.type.toLowerCase()=="submit"){YAHOO.util.Connect._submitElementValue=encodeURIComponent(S.name)+"="+encodeURIComponent(S.value);}}catch(q){}

with:

/*try{*/var S=YAHOO.util.Event.getTarget(q);if((S.type!=undefined)&&(S.type.toLowerCase()=="submit")){YAHOO.util.Connect._submitElementValue=encodeURIComponent(S.name)+"="+encodeURIComponent(S.value);}/*}catch(q){}*/

That seemed to take care of it, and the system no longer generates spurious breaks in Firebug. I had a working demo. Though there were issues with the scroll bars bleeding through the windows in Firefox on Mac, but that’s due to a Firefox bug:

I’m sympathetic to the nastiness of the quirk but I feel like this is what such frameworks must have workarounds for—as they exist precisely to help us not worry about all the bugs in commonly deployed browsers. I managed to work around it using theming—which might give Firefox OS/X users some peace of mind.)

Some developers of closed-source/commercial software are holding onto the idea that a program they have written is going to make them a lot of money in the future. Yet by and large, many small software projects—even very good ones—will not ever make money if they are held on to tightly. Some do make a few hundred dollars a month, but it’s usually a fantasy to believe that it will make the developer rich and famous. This fantasy keeps them from sharing their source and possibly merging ideas with other similar codebases and generating something even better for the public.

One possibility would be to convince the developer of a piece of good software to hand over their work by giving them a lump sum. This sum may be less than the hoped-for long-term revenue in the dreams of the recipient, but sufficient to fund the hours of their hobby, and offset the loss of the residual income. This has happened on at least one instance I know about. For 100,000 euros, the makers of Blender were willing to transfer ownership of their project to the free software community rather than let the project disappear when the company went out of business.

Can more people be paid off? If so, one helpful tool would be a project called Fundable. It lets you pledge funds to a pool for a specific purpose—and then the funds you donate are only billed in the event that the total donation goal is reached.

(2012 UPDATE: In 2007 when I wrote this, Fundable sounded like a great idea. Apparently, questions into the legitimacy of the people who ran it and some other issues drove that company out of business and into a bad reputation. However, the runaway success of a very similar idea called KickStarter suggests I might have been prescient in realizing this idea–which now is labeled crowdfunding–was something that had the potential to really take off!)

Something that might help people be more willing to offer money would be if developers presented a reasoned rationale for why they needed it. Discussing one’s budget in an open way and putting it under the scrutiny of investors may not appeal to most independent developers. But the experiment has been conducted by at least one individual—Jason Rohrer—who has disclosed his personal expenses and concluded that it would take less than $1000 a month to allow him to pursue free software development full time.

It’s not clear that he has been successful in this, but it’s a brave idea. I do not personally use the software he develops and so I am hard pressed to determine if this represents a good value proposition compared to other efforts. But it’s a fascinating precedent that might make people more willing to donate to buy public rights to the code of a particular developer (especially if it’s on an ongoing basis where their commitment to doing further work can be assessed).

I complain a lot about how things are, and offer ideas on how they could be better. But I don’t tend to try and predict the future.

This is mostly because I have no illusions that just because something is a bad way of doing things that it will get better! Look how the world just kept putting more gas-powered human-driven vehicles on the road…the myopia of most people is staggering. Deaths and pollution and wasted time in traffic is apparently not enough of a reason to try harder for the average person. In software, the myopia of the masses is strongly parallel.

I avoided web development for a very long time, because it always felt lousy to me. I’d watched APIs grow and develop, and I just couldn’t understand expressing user interfaces in HTML. Real programmers had been working trying to find ways of moving toward “skinnable” interfaces and rich behavior of form components that would lay out intelligently. The Web set back user interface design by decades, forcing people to recast their user interfaces into things like grids or tables of images rather than a richer compositional model. The result is boxy, and you’re forced to recast everything into this boxy way of expressing yourself with inflexible bitmaps.

Let’s take a common thing going on in browsers, the “curvy corner”. The number of documents where people talk about making little bitmaps for the corners that are necessary to give this simple visual illusion makes me want to gag. I’m no more pleased by the fact that this random, useless, singularly uninteresting visual concept was explicitly added to CSS because the morons who use and develop websites find this more important than actually solving real technical problems.

But being angry about the priorities of society is not unique to me. As Horace Walpole said: *”This world is a comedy to those that think, a tragedy to those that feel.”* I do both but, spend more time venting than laughing. Yet oddly this methodology of sticks and glue has given me web comedy series on YouTube. And I’ll also say that there has been a bit of a “less is more” evolution; the utter horror of how bad web-based software interfaces were caused a laser-like focus from companies like Google to get you directly to the top 10 results for your query. In a lousy UI, search is paramount.

But let me talk a little about the future, by analogy.

Some of us people remember the old-fashioned terminal programs, which would communicate with your computer in a linear way… churning a stream of characters at you. In the beginning, these were designed for printers and not screens; so once a character was output there was no going back. It’s possible to write a text editor under these circumstances, but it’s a bit painful. On the plus side, the protocol is very simple.

Then came along the ability to reposition the cursor on the screen. Suddenly, the computer you were talking to could erase characters it had written. It ushered in a new wave of interactive editors that featured the ability to “paint the screen”.

As with most people watching the rise of systems like Wikipedia, Gmail, Freebase, and Google Maps, I started wondering. My worst fears were confirmed. As horrible an experience as writing programs for Microsoft Windows was using the WIN32 API, doing it in Ajax is worse.

Yet what I am convinced of now is that the protocol is reaching its critical limit. With Ajax, web browsers are splitting at the seams. Evolution in web protocols is going nowhere fast, and it is the lagging advancement of browser installs that means that.

Browsers will be around for a long time–don’t get me wrong–and they will set a new bar for the lowest-common-denominator in UI, replacing the classic command line terminal. This is already happening in devices like routers…where you administrate them through the fetching and posting of web forms. Also remember that the web came into being largely because the network was not fast enough to handle screen remoting, such as through VNC (Virtual Network Computing). In developing countries, this will be the case for some time to come.

There are two options, as far as I see it, for the evolution of interactive computer software over networks:

1. The continued rise of network computing and virtual hosting, which will facilitate safe full-screen remoting. Where this is not possible due to either a lack of computing power on the server (talking to your router) or due to a lack of network bandwidth (networks in developing countries) Ajax will be the newer, friendlier VT100.

2. The other is the idea that a new browser codebase will arise, which does magic safe component downloading to the client to use its processor power. .NET wants to be this platform, and so do Flash and Silverlight, and Java wanted to be it too. All of these fall pretty flat because they’re based on very old ideas, and haven’t come up with any magic. Flash and Silverlight will not dominate the future of computing, because at this point, no one in their right mind is willing to hand over the future infrastructure to a corporation. The backlash from important developers has been so severe that they’d rather suffer through Ajax’s mediocrity and promote the broken browser metaphor than code to a proprietary platform. Right now Flash happens to be the best way to deliver cross-platform audio and video, but like the proprietary GIF standard it will be excised if they try to push it forward.

As I don’t believe in any of those technologies specifically, I’ll restate my belief that the real future lies in Virtualization, simply because there is no granularity that’s really working at this scale. Native apps inside of VMs or on devices that run only one OS, written against a backend, are going to eclipse the browser and relegate it to VT-100 status…an “old way”. You’ll sooner be running an iPad emulator than use a lousy website based on garbage.

It’s the future: hear me now and believe me later.