January 1, 2006
@ 07:57 PM

Reading the blogs of Tim Berners-Lee and Jon Udell this morning, I was struck by how clear it is that the Javascript platform within the browser is somewhat immature and incomplete.

In his post Links on the Semantic Web Tim Berners-Lee writes

To play with semantic web links, I made a toy semantic web browser, Tabulator. Toy, because it is hacked up in Javascript
....
Here is the current snag, though. Firefox security does not allow a script from a given domain to access data from any other domain, unless the scripts are signed, or made into an extension. And looking for script signing tools (for OS X?) led me to dead ends. So if anyone knows how to do that, let me know. Untill I find a fix for that, the power of following links -- which is that they can potentially go anywhere -- is alas not evident!

In his post Predictions for 2006 Jon Udell writes

June 15: Browser local storage

An Alchemy application, though, always works with a genuine local data model that it stores as sets of XML fragments and navigates in a relational style. Bosworth's hunch is that a Web-style thin client, driven by a rich data model intelligently synchronized with the services cloud, could do most of what we really need -- both offline and online.
That's from a column entitled Thin client, rich data. The next turn of the AJAX crank has to involve an intelligent local data store. It's been on my wishlist forever, but Mozilla CTO Brendan Eich told me to expect results in 2006, so I do.

Almost everyone who has attempted building an AJAX application has hit the issues mentioned by Jon Udell and Tim Berners-Lee in their posts. Everytime I mess around with AJAX I can't help thinking how much more interesting the applications could be if I could offload the data aggregation/integration to the client browser instead of doing it on the server. I've thought the same about offline storage, why can't I store richer information than just cookie data on the local client in a cross-platform manner?

It's hard to get wrapped up in the AJAX hype when such fundamental holes exist in the functionality provided by modern web browsers. I hope Jon Udell is right and the Mozilla folks plan to fix some of the more fundamental problems with building AJAX applications on the Web today. 


 

Monday, 02 January 2006 08:45:59 (GMT Standard Time, UTC+00:00)
I faintly remember that IE 5.0 or 5.5 introduced a facility for that, but can't remember the details anymore (it may only be available for HTAs).
Julian Reschke
Monday, 02 January 2006 12:14:41 (GMT Standard Time, UTC+00:00)
"why can't I store richer information than just cookie data on the local client"

You have been able to do that for years on Windows clients with Zeepe [www.zeepe.com].

Review the Zeepe SDK: Brendan's folks will have to work very hard to equal that rich functionality cross-platform.
Tuesday, 03 January 2006 09:31:45 (GMT Standard Time, UTC+00:00)
Why isn't Microsoft doing something to fix the current AJAX issues but is instead concentrating on Windows only technologies, such as Windows Forms?
Whatever improvements can be made to AJAX it will still be a hacked technology meaning that it will still not be clean and still full of complexities. On the other hand, "cleaner" ways for writing web applications, (ie. apps that can run in the browser and not only by the browser), such as Java, Flash and .NET with Click Once, have been around for years. It is interesting to ask why such technologies have not taken on, or at least why they did not become so popular, as AJAX has, although 7 years after its inseption as DHTML. Why?
Well, the reason given many times is that AJAX is cross-platform and standard. However, if .NET Windows Forms running from within the browser is not currently crossplatform other technologies have been for years, for example Flash. However, the most notorious example is Java. Although crossplatform it has not perhaps receivedthe attention it requires on the web. Why is that? Is it because Java is not standard? But neither is the XML transfer part of AJAX if you think about it, since different browser have their own different implementations. In any case Java is consistent across the board, while AJAX is not. On the other hand, the essential parts on .NET have been standardised. Why is no web centric implementation of .NET been developed across all platforms? Flash has also been around and proved useful. Isn't it easier to code in Flash than in AJAX? It even has local storage that you talk about. Or, is Java and Flash no so much simpler and not so much powerful compared to AJAX after all? After all, Windows users account for 94%. Why is crossplatform then so big an issue. If it was in any other industry or field of science and a product or theory had 94% supporters, then the rest would not even be mentioned, let alone spend money on. I am not saying the crossplatform compatibility is a bad thing, however there should be a insentive behind all this crossplatform fuss.
The question is then, why AJAX? And why not another, more programmer friendly system and language has prevailed. And why does not Microsoft move toward helping developers in this field of web applications by putting up for standardization a better programming system, such as a combination of the already developed XAML specification and the .NET paradigm of multible language support. I strongly believe that inovation is and should be provided in this field. Please plan your next moves with this in mind.
Nektar
Tuesday, 03 January 2006 18:43:30 (GMT Standard Time, UTC+00:00)
"You have been able to do that for years on Windows clients with Zeepe"

I absolutely detest comments like this. No, you cannot do what Dare describes. Downloading a non-free piece of software is nothing like what Dare describes.
pwb
Tuesday, 03 January 2006 21:10:51 (GMT Standard Time, UTC+00:00)
@pwb

>> Downloading a non-free piece of software <<

Sorry to raise your ire, but the Zeepe framework can be freely installed on as many clients as you need.

>> absolutely detest ... No, you cannot <<

Why be so aggresively closed-minded? Review the Zeepe SDK, you may learn something.
Wednesday, 04 January 2006 15:15:20 (GMT Standard Time, UTC+00:00)
Whilst I understand the desire for cross-domain functionality in Javascript, I'm still personally concerned with the potential for security risks, not to mention the privacy issues.
It seems security issues are on a pendulum, initially there is little security worries, then someone abuses the system, then there's near total lock-down, then we forget the abuses and start wanting functionality again, which gets abused...
If this sort of functionality were to be made available, I would want very granular control over what was happening and where. If some javascript started loading material from a 3rd party site, I'd want to be able to know what it was sending there, and likewise what it was receiving. But if these things can't be made easily understood by a non-geek user, I really can't see the functionality being widely adopted.
We have enough trouble impressing on people the importance of the security padlock icon when submitting credit card data, and there has still been a slow reaction to the IDN issue.
Doug
Monday, 09 January 2006 21:06:04 (GMT Standard Time, UTC+00:00)
While I would love native browser support for storage, which I do agree will come eventually, I'm not waiting for the browser makers to catch up. See the work I've been doing on AMASS (http://codinginparadise.org/projects/storage/README.html) and dojo.storage (http://codinginparadise.org/weblog/2005/12/dojostorage-api.html); both of these approaches simply use a hidden Flash applet and its SharedObject infrastructure to save megabytes of data securely and fast. Even if Firefox gets local storage, which they will probably do this year, it will be years before IE gets the same, which means browser shims like AMASS/dojo.storage will be necessary for IE.

Brad
Wednesday, 18 January 2006 21:06:27 (GMT Standard Time, UTC+00:00)
FYI, a prototype for an AJAX-based online/offline wiki: http://blog.monstuff.com/archives/000272.html

This approach still takes a lot of work and needs to be improved, but it shows some promise.
Comments are closed.