Slashdot Mirror

From: http://dojotoolkit.org/referen...
"Dojo has made a serious commitment to creating a toolkit that allows the development of accessible Web applications for all users, regardless of physical abilities. The core widget set of Dojo, dijit, is fully accessible since the 1.0 release, making Dojo the only fully accessible open source toolkit for Web 2.0 development. This means that users who require keyboard only navigation, need accommodations for low vision or who use an assistive technology, can interact with the dijit widgets. If you are new to accessibility, please refer to the Web Accessibility Issues page for more general information about accessibility"

http://dojotoolkit.org/ "Dojo starts with a minimal loader (less than 4KB gzipped) with thousands of loosely coupled lightweight modules and plugins available when you need them that are tested and maintained together for the best quality possible."

A few things I like about it are:
* internationalization
* accessibility
* modules
* support for making your own widgets

The first two (especially the second, accessibility) are examples of really important things that many developers leave for later when you are locked into a framework and discover they are not there.

Example:
"jQuery UI Accessibility Analysis"
https://www.ssbbartgroup.com/b...
"To summarize, the public jQuery UI library widgets as of July 1, 2013, are mostly inaccessible for both screen reader and keyboard only users."

Dojo is used in some IBM projects, so that is probably a big reason for the emphasis on accessibility and internationalization.

Of course, there are various things I don't like about Dojo (to begin with, the documentation leaves a lot to be desired when you are starting out). However, in general, so far, it is supporting us in doing everything we want to do... For example, I was very pleasantly surprised when the back button "just worked" when I used the URL "hash" module to navigate between virtual "pages" in a single page app (at least in FireFox, still need to test elsewhere).

Although I still have a fondness for the brilliance of Knockout.js for hooking up widgets to models...

https://github.com/kogmbh/WebO...

I like Dojo in part because it attempts to make all the core widgets accessible. From:
http://dojotoolkit.org/referen...
"Dojo has made a serious commitment to creating a toolkit that allows the development of accessible Web applications for all users, regardless of physical abilities. The core widget set of Dojo, dijit, is fully accessible since the 1.0 release, making Dojo the only fully accessible open source toolkit for Web 2.0 development. This means that users who require keyboard only navigation, need accommodations for low vision or who use an assistive technology, can interact with the dijit widgets."

If you want reusable, self-contained widgets that can be used to construct new more complex widgets that can int turn be distributed as self-contained reusable widgets, have a look at Dojo/Dijit. Basically, Dojo is a library that does what jQuery does, but a slightly worse, and Dijit is a library that does what jQuery-UI does, but about a million times better.

Far better than HTML5/Javascript.

I doubt it. Qt is nice but depending on what's being developed, HTML5/JavaScript can be the superior solution.

Besides, HTML5/JavaScript has so much momentum and is moving so fast that I'm afraid Qt will be irrelevant in a few years.

Check out this app.
https://moqups.com/
A native Qt app would have made the experience clumsy.

There are so many great JavaScript libraries in development that it's hard to pick one. Here are a few that you should keep your eye on though.
http://www.meteor.com/
http://angularjs.org/
http://emberjs.com/
http://dojotoolkit.org/
http://backbonejs.org/
http://jquery.com/

Another reason why Dojo Toolkit is more attractive than jQuery. Clients don't care that the JS executes however many milliseconds faster, and they also don't care that the developers have an easier time not supporting older browsers.

What they do care about is stuff that "just works", and being able to add new features at the speed of *click*. Like any tool, if it hinders you from delivering either of these, it's fit for the trip out behind the woodshed.

I'd like to hear comments from other toolkit devs (Sencha, YUI, etc).

The Dojo Toolkit definitely makes javascript feel a little more friendly.

I doubt that Apple will allow any scripting language on iOS anytime soon, or later, possibly never...

...but I think it will take a little longer than one might expect before they're fully supported on all mobile platforms

Except iOS already supports Javascript and browser components with a (reasonable approximation of) HTML5 (given that W3C are going to faff with the draft standard for a few years yet), I'm pretty sure that JS+HTML5 has always been on the list of Apple-sanctioned languages for Apps (which they've relaxed a bit now, anyway) and, anyway, you can run JS/HTML5 apps in the browser. Plus, pop in a "manifest" file and they can be "installed" with their own desktop icon and run full-screen with no browser furniture without having to go via the App store.

Android and ChromeOS have pretty good Javascript+HTML"5" too (they're all based on the same Webkit foundation that iOS uses, modulo a bit of version skew and different Javascript engines). Yeah, the touch interface hasn't quite standardized between Android and iOS yet, but dealing with that sort of thing is meat and drink to JS developers, and most JS application frameworks deal with it.

'course, I'm not saying MS won't jinx this by the old "embracing, extend, extinguish" maneuver, but this isn't like the corporate desktop where they inherited an unassailable monopoly from IBM - in the mobile market the jury is still out as to who might get "extinguished" if they try that.

"I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage," Robinson said. "Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform." What's next for him? He sees the older framework being rethought and reworked using the best ideas from Node.js. In place of callbacks, he sees ideas like "promises," "co-routines," "actors," and other objects that hang on to the information in the variables for use later. These objects may be easier to juggle than the callbacks.

Callbacks and promises are not mutually exclusive. In particular, a promise API can be built on top of callbacks. This has been well-understood for a long time in both the Ajax world (e.g. dojo.Deferred), and in Node.js development (e.g. node-promise module by Kris Zyp). So, I think this critique is a bit unwarranted.

This is an important debate, but Neil McAllister's article suffers from a number of problems. For example, it references the recently popular Webkit Comparison Table along with Peter-Paul Koch's claim that there is no “WebKit on Mobile”. The article didn't point out that some people like Alex Russel have dug deeper and have found that the facts don't support PPK's conclusions as strongly as one might think. Yes, if you include lots of older devices, there's quite a divergence in Webkit deployments, but what PPK and Neil McAllister don't say is that compatibility is much better on devices that ship recent versions, it's especially good for core features, and it's improving all the time.

McAllister also implies that the mobile Web is in trouble because "On my BlackBerry, JavaScript performance is abysmal". Using that argument, I can prove that Windows will never be successful, because I could in the early days show you PC's that ran it with abysmal performance. The potential of technologies like Javascript needs to be evaluated using the best implementation you can find; that shows what's possible. He does go on to say: "And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase." Aren't they all? "You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java)." Uh, so now the reason that the HTML and Javascript will fail is that ARM processors are too slow to run Java? What's the connection I'm missing? The fact is, that there are some pretty good AJAX sites for mobile, so we know the ARM processors are good enough to run that Javascript. Try, for example, going to http://www.gmail.com using Safari on your iPhone. Not a usable experience? Even works offline using HTML 5 local storage (not Gears). Also, even if Javascript performance were somehow related to Java performance, I bet the Android folks would like to hear that Java doesn't run right on ARM processors, since the entire upper level infrastructure of Android, including user applications, is built on just that combination (as optimized using the Dalvik VM).

Unfortunately, articles like this can do real damage. Many people who are not expert in these things are struggling to figure out which mobile application development models are going to be workable. I happen to believe that the Mobile Web will, like the desktop embodiment of the Web, grow as disruptive technologies tend to: from something that's a bit shaky at first to the model that dominates? Why? Because unlike Mr. McAllister, I believe that the underlying processors and system technologies are capable of running it, and the value of a model that is fully cross-platform, can support zero install operation (you might want to install a mapping application to find a restaurant, but you almost surely don't want to install the restaurant's application to read menus or get discount coupons), can also scale to support installable applications (Widgets) and offline operation, is compelling. Furthermore, as has been the case for years, the Web has the unique value of allowing you to link to the over 1 trillion Web pages, without jumping out from some proprietary application container to a Web browser. Whether I'm right about the likely success of the mobile Web or not, this whole question deserves a much more careful analysis than McAllister's article provides. Unfortunately, there will be many people who read it and jump to the conclusion that the mobile Web is failing. A shame.

I can respect your preference for statically-typed languages, even if I disagree with it. Dynamic typing has a long history going back all the way to the original LISP. Wonderful programs have been written in both kinds of language.

As for inheritance: Javascript is prototype-based, not object-based per se. It's actually a superset of many object models. You can easily use it as if it were a normal language with object-oriented features.

What do they plan to do to grant pixel-level access?

You can do this today with dojox.gfx and it's completely open source. You can use simple calls that are implemented differently on different browsers. On firefox and others your drawings are rendered in SVG, in IE its VML, on others its HTML5's Canvas.
Canva's event model isn't as nicely integrated with the DOM as SVG and VML, but you can pretty much draw things cross platform.

Pure javascript, no plugins required.

dojo.gfx does this as well.

If you have assets in Javascript, though, I'd still recommend obfuscating it, even if only for reducing the filesize. I wouldn't go "crazy" and do more than just using an off-the-shelf JS decompiler, something like this: http://shrinksafe.dojotoolkit.org/

(I've worked for companies before that decided to write their own JS obfuscator; this is a surprisingly complex problem to solve, and most obfuscators can't handle edge cases like complicated RegEx. So make sure the one you pick does actually work, but don't waste your own time writing it.)

I have the Web Developer add-on for Firefox and with a Ctrl+Shift+S, all CSS is broken/disabled. Does this mean I should not use CSS?

I've gone through various stages in web design. At one time I was in the "JS is evil crowd!". Now, I use JS to enhance the user's experience but the pages must not depend on JS.

I would recommend looking into DOJO. Though jQuery is also working on Section 508 compliance. From what I recall, the guy who worked on Dojo's 508 compliance is now working on jQuery's though I cannot cite the source off the top of my head (A catch 22. I do remember it was on the person-in-question's blog).

Dojo Accessibility Compliance
People familiar with accessibility and accessibility guidelines such as the W3C's Web Content Accessibility Guidelines, and the US Section 508 requirements, are often interested in a compliance statement for Dojo. While Dojo does not make an explicit claim of compliance to W3C WCAG 2.0 Level A or to US Section 508, every attempt has been made to meet those guidelines and to make the 1.0 and future versions of the core widget set, dijit, accessible to keyboard, low vision and assistive technology users. Keyboard support has been added to all of the dijit widgets and is supported in Firefox 2 & 3 on Mac and Windows as well as IE 6 & 7 on Windows (Safari and Opera do not yet support full keyboard navigation of scripted content). All of the dijit widgets support font resizing and work in Windows High Contrast mode to support low vision users. Dijit utilizes the under development W3C Accessible Rich Internet Applications (ARIA) specification so that all dijit widgets are accessible using the latest versions of the JAWS or Window-Eyes screen readers with Firefox 3. Additional WCAG 2.0 and US Section 508 compliance details are provided below.

If JSONP isn't an option for you, and you need to make use of a REST endpoint on another domain (or even subdomain), see if you can get the service provider to add Dojo's XIP server files to their server.

I can't help but think that all of these JavaScript/AJAX libraries keep reinventing the wheel over and over again. How many grid widgets written in JavaScript do we really need? How many toolkits for a progress bar or a div-based dialog box have to be developed? Is one of them really that compelling over the others. Consider:

http://dojotoolkit.org/ - DoJo Toolkit
http://www.activewidgets.com/ - ActiveWidgets
http://www.prototypejs.org/ - Prototype
http://script.aculo.us/ - Scriptaculous
http://jquery.com/ - jQuery
http://extjs.com/ - Ext JS
http://developer.yahoo.com/yui/ - YUI
http://code.google.com/webtoolkit/ - Google Web Toolkit (GWT)
http://www.sproutcore.com/ - SproutCore

Those are just the ones I have used personally. It's getting ridiculous. Personally, I like the approach GWT has, but of course that's only relevant to the java developers of the world. I'd love to see all of these "widgets" be compatible with one another.

Similarly, The Dojo Toolkit is a very strong JS library/toolkit/framework/whatever. I'm interning at WebEx, and I've been doing almost all my work with it. It's been a joy to use, especially for someone like me who has otherwise struggled with more complicated JavaScript.

The Dojo toolkit is going to get some love this SoC -- these things might be making their way into your machine even without you knowing it... Markup Previews, 3D effects and Drag&Drop form editor are all among the SoC projects this year.

The Dojo toolkit is going to get some love this SoC -- these things might be making their way into your machine even without you knowing it... Markup Previews, 3D effects and Drag&Drop form editor are all among the SoC projects this year.

The Dojo toolkit is going to get some love this SoC -- these things might be making their way into your machine even without you knowing it... Markup Previews, 3D effects and Drag&Drop form editor are all among the SoC projects this year.

Dojo is an Open Source DHTML toolkit written in JavaScript. It allows you to easily build dynamic capabilities into web pages and any other environment that supports JavaScript sanely. You can use the components that Dojo provides to make your web sites more useable, responsive, and functional.

So, thats what we do - and we're involved with the Summer of Code for the third time in 2008. And this summer we have lots of exciting stuff planned: charting, accessibility, visualizations, automated testing, 3d graphics, ... or suggest your own.

• Dojo Summer of Code homepage
• Straight to the project ideas

- Rob :)

Dojo is an Open Source DHTML toolkit written in JavaScript. It allows you to easily build dynamic capabilities into web pages and any other environment that supports JavaScript sanely. You can use the components that Dojo provides to make your web sites more useable, responsive, and functional.

So, thats what we do - and we're involved with the Summer of Code for the third time in 2008. And this summer we have lots of exciting stuff planned: charting, accessibility, visualizations, automated testing, 3d graphics, ... or suggest your own.

• Dojo Summer of Code homepage
• Straight to the project ideas

- Rob :)

Dojo is an Open Source DHTML toolkit written in JavaScript. It allows you to easily build dynamic capabilities into web pages and any other environment that supports JavaScript sanely. You can use the components that Dojo provides to make your web sites more useable, responsive, and functional.

So, thats what we do - and we're involved with the Summer of Code for the third time in 2008. And this summer we have lots of exciting stuff planned: charting, accessibility, visualizations, automated testing, 3d graphics, ... or suggest your own.

• Dojo Summer of Code homepage
• Straight to the project ideas

- Rob :)

This Web 2.0 "hype" is largely a phantom, imo, and this Intel release re-confirms it for me. Web 2.0 only escapes the realm of vaporware in the sense that applications and uses are actually created under this hype, yet it all seems pretty shallow considering how not only more than one person on this page has admitted it ( I could easily ask a bunch of friends both living on the internet and not). The only time I seem to really notice the hype, honestly, is when calling it by the accepted name: Web 2.0 lol. While all of these things are being developed, most of it isn't being taken seriously (MySpace the most blatant example, but honestly, any site with a design like that is just going to fall flat of the finish line; would it kill them to have some negative space on that site, or maybe kill some of the seizure inducing themes who seem to really like clashing bright colors & 120 videos on one page).

I wouldn't call it all a waste; eventually the fallout of this almost imaginary Web 2.0 hype will be more useful as experience from trying to make such things work: Yahoo Pipes versus efficient knowledge of PHP, older designs that work well, manage a decent amount of both functional CSS and media and DO NOT BREAK vs. newer, unproven designs involving ad hock amounts of AJAX, CSS 2.Fail, experimental CSS 3, not entirely understood uses of Rails, etc. I mean, Pets.com failed for reasons (like many a dotcom); many of this stuff will to for similar reasons under different as well as similar circumstances.

All in all, I'm beginning to actually see, however, useful things develop amid this Web 2.0 business, mainly because it's beginning to look like it's going to start to die down soon, specifically:

• Facebook being used as a portfolio (great idea, imo)

• Last.fm (with the obvious exception of their similar artists suggestions, that kind of needs work)

• Users, Coders/Developers working together to create alternatives to the largley failing CSS
  • + WHATWG finally getting the ball rolling on updating HTML 4 to HTML 5
  • + CSS Frameworks as a counter to the annoying b.s. CSS involves with margins and grids
  • +The prospect of using Python (CleverCSS), Pearl (HTML Mason, it's been around but yea still counts) mixed with CSS; I was even reading this interesting page on how a person rightfully pointed out the failings of CSS (and how CSS 3 will most likley continue this) and how CSS should be written: CSS 3: A Giant Serving Of FAIL

Admitelly, I'm not a programmer just yet, but I find it excellent that I can somehow get my foot in (hopefully) in learning the concepts of actual programming with stuff I already know (HTML Mason being the best as HTML is dead simple, so I'd imagine picking up on some of Perl in context would help ease the stigma of learning how to use a programming language). Web 2.0 sites , specifically about CSS 2.0, I've found for the most part useful when they are A. Not repeating the same things, which is a rare that they don't and B. Are not spouting pro-CSS only zealot B.S. about how tables only "data" when by definition, everything you put on a webpage is "data" LoL!

CMS I also find a very good consequence of Web 2.0, as it's helping me get my grounding in finally managing a comic navigation system for a future project and learning some minor but nonetheless PHP along the way. In theory, it should help keep me active, just like this whole Web 2.0 thing is really all in theory. In theory, I could easily put up my entire daily life on LiveJournal, Facebook, etc. etc. But if I sign up for those things, I do not use them any where near to the extent others may imagine others, or myself imagined, using them. Personal barriers became established, the "trendy" feeling went away, friends just keep sending the same fucking mindless bulletins via myspace, spam fills the youetube inbox, etc. etc. I

How does this compare to Dojo Offline?

http://dojotoolkit.org/offline

It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want.

If you're doing a complex website, you'll probably be better off with a custom library for now.

It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want.

If you're doing a complex website, you'll probably be better off with a custom library for now.

I'm Alex Russell, Project Lead for Dojo,

We're obviously flattered that our little project got covered in DDJ, couldn't they have reviewed newer versions of the tools they covered?

This sounds like the classic Framework versus Library debate. Some good reading:

The Dojo mailing list thread "dojo: framework vs library"
http://dojotoolkit.org/pipermail/dojo-interest/200 5-May/000231.html

Joel Spolsky's "Why I Hate Frameworks"
http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12

Arnon Rotem-Gal-Oz's "Frameworks vs. Libraries"
http://www.ddj.com/blog/architectblog/archives/200 6/07/frameworks_vs_l.html

That being said, there are plenty of features in Prototype which are more library-like than framework-like, so it is easy to use parts of it without buying into a whole framework methodology. I don't know much about the other evaluated tools.

I care because for the most part, people do not use IE/Windows out of choice, they use it by default, even when there are better alternatives available.

I care because enough people do this that IE/Windows become a defacto standard. Before Firefox started gaining ground, many websites were coded to IE, not to standards -- and IE broke the standards. This affected me directly, because when I was using Mozilla (and early Phoenix builds, which was later renamed to Firefox), I would often run into websites designed only for IE, which would not work properly on other browsers, even when they followed the standards, assuming they let me in the door in the first place.

There are still entirely too many websites, even non-ActiveX ones, which will use browser detection and block you at the door if you're not using IE.

So, if you use IE, you're directly responsible for parts of the Web sucking for Firefox users, and that is one reason I look down on you.

Even now, websites designed for standards, which work flawlessly in Firefox, Opera, Safari, Konqueror, and many other browsers, continue to fail in IE, because IE does not support the standards properly. But since so many use IE, the standard user response is, "This website is broken." The standard way to deal with this is to spend several times as long developing your website (or web app) in order to ensure that it also works on IE.

Go talk to any serious web developer about the problems of supporting IE. When they tell you, understand that they are not exaggerating at all. It really is at least that bad. And that's just with existing standards; IE has been the most resistant when it comes to supporting actual new standards. (Adding their own does not count; Microsoft does not (or should not) dictate Web standards, that's what the w3c is for.

(And if they are using a toolkit, like Dojo or Google Web Toolkit, that just means the toolkit is doing the work for them. It also means that a very large portion of that toolkit had to be written to fix the problems Microsoft introduces with IE.)

Windows is another problem for another rant. But let me just give you one: Anti-virus software would not have to exist, were it not for Windows. Also, hardware manufacturers tend to write their drivers for Windows only, meaning Windows gets the credit for working on just about any hardware, without having to do any of the work. It also means that they tend to not release specifications, meaning Linux has to reverse-engineer these things.

So, you, as a Windows user, are directly contributing to my problems -- things like my wireless card not working, and the difficulty of finding a wireless card known to work with Linux.

That is why we look down on you. You are making the computing world a hell for anyone who doesn't make the same choices you do (Windows/IE). Microsoft may have made Windows/IE hell to work with, but you, without even realizing it, are making it more and more difficult to choose anything else.

You don't even have to wait.

Firefox 2.x supports DOM:Storage objects that will already let you store arbitrary data client-side, and IE supports something similar with Persistence and DHTML Behaviors. If you want the same mechanism for multiple browser types you can do some crazy Flash-based stuff as well.

Within the browser storage objects there are some limitations as to size, so that could be part of the new versions. But make no mistake: this feature is already a reality. See Ajaxian or Dojo for more of the same, including concrete implementations.

don't forget the dojo toolkit, http://dojotoolkit.org/

Hello everyone, I'm a software developer at a company that develops training software for the government. Now some of the tools I've written in Java because I wanted to make sure they were cross platform and we are not binded to Microsoft tools if we ever needed to switch platforms 10 years from now, but for the most part our big projects will be web base. I'll give a little list why:

1. Create and fix lessons from anywhere - Like I said we submit changes to the client and when they want to rework something it can be done on site. Plus put in a request for changes when it comes to graphics for there lessons.

2. One location for using tools - As we get bigger more and more users will start using these in house tools. We look better just copying up our changes to a server, then to have users install/reinstalling software over and over again.

3. Community - Since it's web base when ever a user login the other users will see that person and what they are working on and will even be able to send messages. So if the Author of the lesson wanted to he/she could request a graphic or animation and it will be placed in a list for the Graphic Artist. This also makes it so the Authors of the lessons could create and borrow from other Authors. Plus the main thing...Communication and sharing!

4. Cross-Platform - The tools are build using the Dojo toolkit which support 5 different web browsers on the three major platforms I like to aim for which are Windows, Linux and MacOS X.

So there you have it! I normally don't post on Slashdot but I figured since some people are bashing AJAX/WEB 2.0/DHTML I had to step in and say something. Then again like my subject simply states, it's about using the right tool for the job. If I was building a 3D Engine, Video Editor or Sound Editor I wouldn't be using AJAX. I always do my best to keep an open mind when it comes to developing software.

Having said that, it's still a fact that we're using JS in ways the original designers probably didn't envision, although I must say that from a basic design standpoint JS is certainly impressive. You're still running within the constraints of the browser, which mostly treats scripts as a sort of annoying necessity rather than an integrated part of the client experience.

Before you instantly flamebait me for critizing a high profile OSS project please let me briefly explain my background.

I am an almost 100% Linux user simply because its the OS which works best for me. I keep a spare windows partition only for playing
games. Also I try to suggest OSS solutions in my dayjob and have so far succeeded in getting my company dependent on Apache/MySQL, Imagemagick, Ghostscript, PHP etc (unfortunately all on windows servers, which I loathe).

Anyway allow me to get to the point:
Can anyone tell me why Firefox both starts and run so much slower on linux than windows. It almost feels like its made for windows and the linux version is running on some emulation layer. Now I know thats not the case, I know about their XUL platform and all of that.
The very slow loading could have something to do with the dynamical linker being somewhat slower on linux?, or is the instantiation of lots and lots of objects? slow memory allocation. But I seem to recall linux being much faster at that although I can't point you at any graphs or papers.

Why is it slower than the windows version when you have lots of open tabs?. I've seem to recall hearing that this is due to the flashplugin for linux being slow and since almost every page have flash everywhere yadda yadda.. Haven't tried to compare the two using pages with no flash objects so that sounds quite reasonable.

Why is it slower doing DHTML? again I don't really know if that is the case but try opening http://dojotoolkit.org/ "See it in action"->General widgets->Fisheye (sorry but I can't be bothered to try and dig out a direct link into that steaming pile of javascript (no offense dojo devs)) and compare the rendering speed in firefox/win32 vs. firefox/i386?

This isn't meant as a whining post. Im genuinely interested in why there is such a huge different between the windows and linux firefox experience, I've been wondering about that simple fact for several years now.

and no I can't provide sources and all that crap but being developer myself and having used the software for a long time, I sure can tell when an application is noticeable faster on the same machine.

if any firefox dev is reading this: don't get me wrong im grateful for what I got, firefox is a great browser. I just think its sad that the greatest OSS browser runs worst on the greatest OSS OS (GNU/Linux).

As far as I know this can't be done with Ajax, since XHR can't make crossdomain requests.

There are ways around that...

However in a way it doesn't matter if you're using pure Javascript or a XMLHTTPRequest to send the request to the remote server, the results are the same. If you're developing secure web sites you still need to worry about this possibility.

I suppose this could be done with some sort of JavaScript trickery (a kind of linkTo(URL, RegexKindOfThing)).

It requires some cogitation and a bit of coffee though. A general purpose function for this would indeed be a very nice tool. It should be part of the Dojo toolkit or something like that...

<button dojoType="Button" widgetId="helloButton">Hello World!</button>

1. Not all all js libs are that large. (shameless plug: my ff javascript library is below 7k)
2. Use Javascript compression
3. Use gzip compression / gzip precompression ( ff javascript libray shrinks to below 3kb )
4. Use Firebug

I think the more limiting issue is that it is so hard to do AJAX across domains. XMLHttpRequest doesn't work, nor do hidden iframes.

Not true - there's a trick to get around iframe cross-domain security. You can still see the URIs of the frame. This means that the domain you are attempting to access can supply a special page that calls XMLHttpRequest on your behalf and streams the data to you by updating the fragment identifier.

It's an awful hack, but it's been wrapped up in an XMLHttpRequest emulation by Dojo.

Looking further ahead, there's already a proper model for cross-domain communication, and Opera already supports it.

I think the more limiting issue is that it is so hard to do AJAX across domains. XMLHttpRequest doesn't work, nor do hidden iframes.

Not true - there's a trick to get around iframe cross-domain security. You can still see the URIs of the frame. This means that the domain you are attempting to access can supply a special page that calls XMLHttpRequest on your behalf and streams the data to you by updating the fragment identifier.

It's an awful hack, but it's been wrapped up in an XMLHttpRequest emulation by Dojo.

Looking further ahead, there's already a proper model for cross-domain communication, and Opera already supports it.

We didn't really even need xmlhttprequest; you could use iframes, too. (And some notable "2.0" apps have)

Useful bits I've found getting into ajax stuff:

Dojo Toolkit, a nifty framework for doing all sorts of good stuff. Of particular note to me was dojo.io.* with its dojo.io.bind() function, which provides a simple, cross-platform compatible way to do an xmlhttprequest, with callback functions for completion and errors, an easy way to post variables, specify a method and caching, etc.

openrico. This provides all sorts of fun stuff. The smart stuff starts with declaring $ as a function, which after you get used to it provides a very convenient cross-platform way to access DOM nodes (ie, $('mydiv') or $(divvar)), and has all sorts of canned widgets for effects, like accordian widgets, move&resize, etc... although I've found practical application usually requires a bit more additional work, but their functions help get started.

I like Sarissa, but have moved onto using Dojo http://dojotoolkit.org/ due to it's friendlyness to JSON. Much easier accessing a returned object that walking the DOM.

Dojo has already solved this and is also an all-around great ajax toolkit. It's major drawback is a horrible gap in documentation. If you're not afraid of mailing lists and IRC, this is easily overcome.

Yeah, I think Echo is probably the most quiet framework out there that has all the great quirks even before Web 2.0 term was out. It receives less attention than it deserves.

Also, GWT doesn't seem all that complete at all. Dojo is a pretty good place to look for AJAX componentsd as well. http://dojotoolkit.org/

Have any of the other frameworks provided this mechanism?

I wonder how difficult it will be to write degradable applications with this toolkit. The demo applications I played with do nothing at all with javascript disabled... they're just a script tag in a body tag, so they make no attempt to render the application using plain HTML. I know they're just demos, but it won't save any time if you have to develop the non-js version separately... which is a problem particularly for those of us who have to develop to accessibility standards.

Also, this is coming right on the heels of the buzz about Oracle's AJAX Framework... and of course there's the Eclipse AJAX Toolkit Framework, which uses Dojo, Zimbra, and OpenRico (which in turn uses prototype)... others have mentioned Yahoo!'s toolkit and Atlas, as well, not to mention Rails... My point is that there are suddenly a ton of frameworks that all have slightly different approaches to the whole AJAX idea. Some are higher-level, some lower; some target a specific server backend; some offer UI libraries... Any or all of these might merge or die off or be made irrelevant at any time. It's almost harder to develop AJAXy applications now than back when you had to write your own HTTP request code... sure, you can knock one out in ten minutes now, but you spend the time you saved choosing the toolset beforehand.

I think I'll wait a bit... we've put the scorpions in the box and shaken it, so let's see who survives.

JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.