You searched for: 'native'

Monday, September 17th, 2007

ZK 3.0 RC Released

Category: Announcements, Framework

One of the enduring criticisms of ZK, the server-side Ajax framework, has been against its perceived slow performance. Critics have observed, and supporters have conceded, that applications written with ZK seem a touch slow. So it’s no surprise that a major focus of the latest major release has been improved performance. The ZK team found two major bottlenecks in performance testing:

After a series of stress test and reviewing the kernel code, we found out 2 bottlenecks on ZK 2.4.1 and fixed them in ZK 3.0 RC.

  1. The executing time is too expensive when rendering components. ZK uses templates to render components, and the EL is generally used in templates to simplify the variable access and templete maintenance. However, when the concurrent access rises to a large number, the overhead on rendering component with EL is too heavy.
  2. Threads spend too much time on waiting the synchronization when many threads access to the same cache under current cache mechanism.

ZK 3.0 RC solves these 2 bottlenecks by using the renderer class and new cache mechanism. The test result shows ZK 3.0 RC is four ~ five times faster than ZK 2.4.1.

I haven’t validated these performance figures myself, but an initial comparison between some demo applications confirms a much more responsive user experience.

ZK 3.0 RC has also added a number of other new features:

  • Server push is enabled which allows you to update client’s information actively and the usage is simple and intuitive.
  • Add forward property of components to forward event without programming.
  • New expression of annotation is ease of use, and easy-to-read.
  • TreeModel is introduced which simplifies the job of Tree rendering.
  • Flash components allow you to play audio and video files. (including youtube clip)
  • Native namespace is implemented to speed up the performance while integration with HTML.
  • To speed up the performance of ZK, EL evaluator is pluggable, and a new way to render ZK components is introduced.
  • More integration with other frameworks, ZK has integrated with JSF, JSP, and Ext-JS.

Server push was already supported in ZK through use of the timer component, but the enhancements make it even easier (note: we’re not talking comet, but rather client polling). Even more exciting for me is the dynamic loading of ZUML (the XML-based markup language for specifying ZK interfaces) pages dynamically from sources such as a database. That’s very helpful if you want to allow non-developers to deploy interface changes without having to spit out ear or war files.

As usual, the ZK folks have done a good job documenting the changes and additions. It’s too early to tell if 3.0 will solve all of ZK’s previous shortcomings, but ZK is well on it’s way to becoming my favorite server-side framework.

Posted by Dietrich Kappe at 8:27 am
Comment here

++++-
4 rating from 46 votes

Friday, September 14th, 2007

Taking your Web Development skills to the desktop Using Adobe Integrated Runtime

Category: Adobe, Conferences, Presentation

Kevin Hoyt of Adobe gave us a personal tour of how you can take your web development skills to the desktop using the Adobe Integrated Runtime (AIR). The talk was designed for the Ajax developer, and special emphasis was given to the latest features in the AIR Beta to include:

  • File Pickers
  • Native Clipboard
  • Native Drag and Drop
  • Service Monitoring
  • Native Windows with Custom Chrome
  • Local Database

Kevin walks through these examples as he builds out sample AIR applications.

Go ahead and click here for the presentation from The Ajax Experience.

Posted by Dion Almaer at 7:18 am
14 Comments

++---
2.7 rating from 38 votes

Thursday, September 13th, 2007

SVG on IE via Silverlight via XSLT

Category: Microsoft, SVG

Sam Ruby has done it again, this time taking Toine de Greef’s work and making it better. Now your SVG can work on IE via Silverlight:

Cool. SVG to Silverlight via XSLT. But, embedding in HTML using comments? I think I can improve upon that.

Demo: Toucan. Rendered using native SVG on recent Gecko, Opera, and Webkit based browsers. Converted to Silverlight and rendered (after a brief delay) using client side XSLT on MSIE browsers with Silverlight.

This technique may also be useful for people who want to embed Silverlight into Webpages, which apparently isn’t so easy to do.

Demo: Raven — currently MSIE/Silverlight only, but clearly the reverse is also possible.

The magic bridge to the XML is in svg2xml.js:

javascript

  1. if (window.attachEvent) window.attachEvent("onload", function() {
  2.   xmls = document.getElementsByTagName('xml');
  3.   for (i=0; xmls.length>i; i++) {
  4.     var source = xmls[i].XMLDocument.documentElement;
  5.  
  6.     var script = document.createElement('script');
  7.     script.id = "_svg2xaml_" + i;
  8.     script.type = "text/xaml";
  9.     if (source.nodeName == 'Canvas') {
  10.       script.text = source.xml;
  11.     } else if (source.nodeName == 'svg') {
  12.       var svg = new ActiveXObject("Microsoft.XMLDOM");
  13.       svg.async = false;
  14.       svg.loadXML(source.xml);
  15.       var xsl = new ActiveXObject("Microsoft.XMLDOM");
  16.       xsl.async = false;
  17.       xsl.load("svg2xaml.xsl");
  18.       script.text = svg.transformNode(xsl);
  19.     } else {
  20.       continue; // ok, script is never used.  So what?  Shoot me?
  21.     }
  22.     xmls[i].parentElement.insertBefore(script,xmls[i]);
  23.  
  24.     var embed = document.createElement('object');
  25.     try {
  26.       embed.type = "application/x-silverlight";
  27.       embed.setAttribute('source', '#' + script.id);
  28.     } catch(err) {
  29.       embed.title="SVG or Silverlight required";
  30.     }
  31.     embed.width = xmls[i].style.width;
  32.     embed.height = xmls[i].style.height;
  33.     xmls[i].parentElement.insertBefore(embed,xmls[i]);
  34.   }
  35. });

Toucan

Posted by Dion Almaer at 9:15 am
9 Comments

+++--
3.1 rating from 36 votes

Tuesday, September 11th, 2007

Qooxdoo Tech Talk Presentation

Category: JavaScript, Library, Qooxdoo

The first of our recorded sessions from The Ajax Experience (East coast coming!) is now live.

You can view the presentation on qooxdoo, with Andreas Ecker, Project Lead of qooxdoo and Derrell Lipman, qooxdoo Team Member.

qooxdoo is a comprehensive and innovative Open Source JavaScript framework. In this session, you’ll learn how to leverage qooxdoo to develop professional JavaScript applications, using its state-of-the-art GUI toolkit that allows for easy development of impressive cross-browser web applications. Project lead Andreas Ecker and team member Derrell Lipman will also demonstrate and discuss qooxdoo’s elegant Ajax and remote procedure call communication layers.

In this session, you will learn how to:

  • Use qooxdoo’s wide array of widgets and its tool chain to easily develop truly innovative web applications;
  • Create applications with zero-footprint and no memory leaks;
  • Have your application run transparently to the user;
  • Build applications without any knowledge of CSS or even HTML, using typical commands from other major toolkits for native applications.

Once you launch the presentation window, you will see a full transcript that you can peruse.

Posted by Dion Almaer at 6:48 am
19 Comments

+++--
3.8 rating from 38 votes

Monday, September 3rd, 2007

The Pros and Cons of Adobe AIR

Category: Adobe

Adobe AIR is really getting a lot of press and I have to say that I am a fan of the technology. Having come from a client-server background, its nice to leverage the technologies that I’m currently using to build desktop apps.

There are pros and cons, though, and I think Tim Anderson has done an excellent job of listing some of the good and bad of Adobe AIR:

Some pros:

1. Fast execution. ActionScript 3.0 has a JIT (just-in-time) compiler, putting it on a par with Java or .NET for raw performance.

2. Cross-platform. AIR apps will run on Windows XP and Vista, Mac OS X (PowerPC and Intel), Linux (though not in the beta).

3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.

4. Easy installation. Provided the runtime has installed successfully, installing AIR applications is likely to be be trouble-free, since all the files go into the application directory.

Some cons:

1. Limited extensibility. AIR apps have file access, clipboard access, support multiple windows, support drag and drop, and can trigger notifications (”toast” in Windows). If you app needs to interact with the desktop in other ways, the chances are that AIR is not suitable. For example, there’s no access to COM automation, and no way to execute external applications. The reason is to maintain cross-platform compatibility. That’s a worthy goal, but it would be good to have a way out of the sandbox. Unlike Java or .NET, you cannot extend AIR with custom native code libraries. Nor can you call operating system APIs.

2. Database access limited to SQLite or web services.

3. Enterprises need to roll out applications over the network in a controlled manner. AIR has no specific support for enterprise deployment. On Windows, AIR does not use the Windows Installer service. Either Adobe or 3rd parties will need to create deployment wrappers to overcome this.

4. Proprietary technology. AIR applications depend on Adobe’s runtime.

Two things that I’m not quite in line with are his concerns about the proprietary nature of AIR and security concerns. First, being “proprietary” doesn’t mean its a bad thing. I realize that people have become accustomed to OSS but that doesn’t mean that EVERYTHING needs to be OSS in order to be a valuable solution.

Secondly, I had a great conference call with Adobe regarding the security considerations with building AIR apps and can say that they are very much in tune with this. They’ve had conference calls with some JavaScript industry heavyweights and are taking security VERY seriously.

Overall, though, Tim does touch on some very key points and its definitely a good read for those considering Adobe AIR.

Posted by Rey Bango at 7:00 am
13 Comments

+++--
3.8 rating from 28 votes

Thursday, August 30th, 2007

CompressorRater: Compare the squeeze

Category: Performance

The JavaScript camp can get a bit obsessed with squeezing, and Arthur Blake’s CompressorRater tells you how far you can go:

There are many tools available that can help you compress your JavaScript code but it can be time consuming and difficult to analyze which tool work the best for a given situation. The goal of this web application is to report aggregated statistics on the general level of compression in all these tools, as well as allow developers to easily play with and compare the different tools on their own JavaScript code without having to set up all the tools on their own.

The following compression tools are compared, both with and without the affects of additional gzip compression that are supported natively by modern web browsers.

The tool will try all of the usual suspects for you, in various modes. I ran gears_init.js into the sausage factory and got out:

CompressorRater

Oh, and it has been a couple of days, so Julien has released a new version of the YUI Compressor (2.1).

Posted by Dion Almaer at 7:40 am
10 Comments

++++-
4.7 rating from 21 votes

Thursday, August 16th, 2007

Tales of the Rich Text Editor and Safari Support

Category: Yahoo!

I love to hear the stories behind the technology. This way you have a chance of learning from a fellow developers trials and tribulations.

Dav Glass of the YUI team was in charge of building the new Rich Text Editor that was just released, and has documented part of the journey which includes how he managed to get this puppy working on Safari 2:

My development approach was to bend Safari first. I built it to work in Safari 2 before retrofitting it back to Opera, then Firefox and lastly Internet Explorer. I figured that if I could make Safari do what I wanted, the other three would fall into place nicely. And they did. By choosing to make Safari work first I was able to make the others do things in a standard way as well. I hope that Safari will eventually catch up to its A-grade peers and add support for the things that I have “emulated”, so I took that into consideration too.

How did he hack around Safari 2?

Safari 2 is a really good browser, but it was also the most challenging browser to support with the RTE project. It lacks some serious and critical features when it comes to editing HTML content from JavaScript. I will try to explain the main hurdles that Safari presents:

Iframe Focus – One of the biggest issues was actually quite simple to solve. Safari (and Internet Explorer) has an issue with selecting text inside of an embedded iframe. If you select text within the editor’s iframe then click/focus the parent document, the selection within the iframe is lost. Clearly, this makes it rather difficult for a button click to take action on the selection (because the selection is lost when you click the button!). It also makes it difficult to use, say, a YUI Menu Control for a drop down. As I investigated this problem, I determined that if you stop the mousedown event on the button/href the selection doesn’t get lost. However, if something else (say a href in a dropdown menu) gets focus, the selection will still get lost. This leads me to the next Safari trick.

Selection Object – The selection object in Safari is very limited (to say the least). To work around its limitations, the YUI RTE caches a copy of the current selection in the _getSelection method. Then, the next time _getSelection is called I check to see if a cache existed. If the cache is there, I “rebuild” the selection and destroy the cached copy. This little trick is what lets Safari use a YUI Overlay as a menu instead of the more classic approach of a select element. It’s roundabout, but it works.

execCommand limitations – This is the mother of all hacks for Safari (and the others). My biggest problem with the native execCommand method (in all browsers) is that the browser doesn’t tell you what it applied the command to. So there is no real way to get an element reference back after running a command on a selection. The world of JavaScript editors would be so much more civilized if this would happen (hint, hint, nudge, nudge). So what I had to do was implement this feature myself. My current approach may not be the best way to do it (I have some other ideas that I am working through), but it does the job for now. The method is named _createCurrentElement and basically it runs execCommand('fontname', false, 'yui-tmp'); on the given selection (since fontname is supported on all A-Grade browsers). It will then search the document for an element with the font-family/name set to yui-tmp and replace that with a span that has other information in it (attributes about the element that we wanted to create), then it will add the new span to the this.currentElement array, so we now have element references to the elements that were just modified. At this point we can use standard DOM manipulation to change them as we see fit. In short, I’m using the iframe’s DOM to store metadata during editing as a way to enrich the communication that’s possible between the editor and the iframe.

Thanks for sharing the story.

Posted by Dion Almaer at 10:05 am
6 Comments

+++--
3.3 rating from 79 votes

Friday, August 3rd, 2007

Google Mashup Editor powered by GWT

Category: Google, GWT

I sometimes get asked “why doesn’t Google eat it’s dogfood and use GWT”. I normally point them too:

  • GWT has been out for just over a year (> 1 million downloads), so it is obvious that properties from 4 years ago may not be running GWT :)
  • There are several parts of Google that do use GWT (such as Base)
  • Just because we offer an open web toolkit doesn’t mean that it is the right tool for every web application out there.

We are starting to see more and more applications from Google make it out with a “powered by GWT” sticker. One high profile case is the new Google Mashup Editor which actually consists of three distinct parts:

  • The Mashup Editor, which is itself an Ajax application.
  • A server-side hosting framework, which provides developer services (e.g., source code management via Google Code project hosting) and mashup services such as Google Base and a data store that can be accessed via feeds.
  • A JavaScript client library that implements the mashup UI controls and data processing functionality. The server-side components leverage Google’s scalable infrastructure and provide access to Google services via the Google data APIs protocol; the client-side components were developed exclusively using the Google Web Toolkit.

Rich Burdon, of the Google Mashup Editor team, wrote about why GWT was chosen. Here is a closer look:

Before starting the project, our team already had a lot of experience building complex AJAX applications by hand — and had experienced many of the problems associated with this approach. Here are some of the reasons why we chose to use GWT rather than rolling our own native JavaScript framework this time around:

  1. Tools matter. As a veteran of the long-ago vi versus emacs debates, it’s interesting to see the same enthusiasm go into the Eclipse vs. IntelliJ IDE arguments. Whichever side you’re on (I fought for the latter in both cases, but we have members of both camps on our team), tools can make a huge difference in terms of developer productivity. You used to think twice before refactoring a large component that needed attention; having the tool take care of these kinds of complicated, repetitive (and error-prone) tasks makes life easier and can lead to better quality.
  2. OO is a good idea. I remember figuring out how to make JavaScript objects polymorphic and finally understanding what a closure is. Indeed, my colleague Stephan Meschkat, who works on the Maps API, often reminds me of JavaScript’s inherent power and elegance. However, I like to have keywords like “interface,” “private,” and “final” at my disposal — even better to have my compiler (and my editor) remind me that I’m attempting to call a function with inappropriate arguments. Type safety saves debugging time, and OO abstractions can help to reduce complexity in your code.
  3. Compatibility. Java’s original slogan of “write once, run anywhere” fell victim to the intense competition between browser developers. Although JavaScript, being a smaller core language, has fared somewhat better, the complexities of juggling different DOM implementations over a growing number of browser platforms makes writing cross-platform AJAX components difficult. GWT’s ability to insulate you from much of this complexity probably makes it a no-brainer for this benefit alone.
  4. The client is only half the story. Both the Mashup Editor and the resulting mashups themselves interact with Google services; being able to code both sides of a remote method call in the same language has some obvious benefits. Aside from the relative simplicity afforded by the GWT RPC mechanism, both client and server components can share constant definitions and in some cases, simple functions.
  5. Open systems are less scary. A programming framework is something that introduces abstractions. The benefits include making complex concepts simple and quicker to implement; the downside is that if you want to do something that the framework wasn’t designed for, you’re on your own. It was important for us to be able to get under the hood and tweak the native JavaScript. For example, the Mashup Editor’s template-processing functionality uses a native JavaScript library that we borrowed from the Google Maps API.

Posted by Dion Almaer at 8:59 am
5 Comments

+++--
3.6 rating from 32 votes

Thursday, August 2nd, 2007

Monthly Ajaxian Roundup for July, 2007: iPhone and the Plugin Wars

Category: Roundup

The summer is traditionally a slow time, but this July had some fun happenings. The iPhone buzz continued, and Episode 2: The Plugin Wars continued. Mozilla announced that their front was moving the battle to enemy territory. Brendan Eich said, “If we fight them over in IE, they won’t come fight us over here” ;) He then launched his Iron Screaming Monkeys and Microsoft retaliated by hinting that “for performance reasons” they may have to take out the scripting host in future versions of IE.

iPhone

Frameworks

Dojo

Script.aculo.us

ExtJS

Yahoo! UI

jQuery

JavaScript

Offline

CSS

Browsers

Tools

Showcases

Posted by Dion Almaer at 12:01 am
6 Comments

++++-
4.1 rating from 21 votes

Tuesday, July 31st, 2007

Joe Hewitt presentation on iUI (Video)

Category: iPhone, Presentation

Joe Hewitt popped down the road to talk about iUI, his look-native-on-the-iPhone framework, at Yahoo! HQ.

This is a short, 15 minute presentation, that shows Joe providing an overview of how iUI works and how you can use it to jumpstart any iPhone-specific interfaces you’re considering for your web apps. He also provides an outstanding overview of just what you can expect from the current iPhone web browser in terms of standards support; if you’re curious about what works and what doesn’t with iPhone’s Safari implementation, this is a good place to start.

Posted by Dion Almaer at 12:34 am
Comment here

+++--
3.9 rating from 49 votes

Friday, July 27th, 2007

The End of TAE and Browser Possesion

Category: Browsers, The Ajax Experience

Another Ajax Experience is over. We had a blast and it was a tons of fun to see so many of our friends in the community and to have so much top-notch content. Many thanks to all those who came out, especially the speakers, many of whom came to present at great personal sacrifice. And, a tip of the hat to those who held some announcements for the show, such as:

As the last sessions were wrapping up, a group including Brad Neuberg, Glen Lipka, Alex Russell were seen huddled together in an animated discussion. Glen kindly pointed us to a summary of their chat, which includes what he’s calling “browser possession”:

The most exciting idea, which several people seemed to be noodling on at the same time was what I am loosely calling Browser Possession. It goes like this:

1. You make a web page using HTML, CSS and JS.
2. You test it in ONE browser. Probably Webkit.
3. You include a single JS at the top of your page, a spinoff off of SWFObject.js
4. The JS would instantiate a SWF file which would fill the 100% of the height and width of your browser window.
5. The JS would then suck in the HTML of the page, and feed it to the Flash Movie.
6. Then the Flash movie would instantiate Webkit inside it and render the page.

Glen goes on to simplify the proposal as:

1. Same as above, but instead of a Flash movie, it would be a Webkit native plugin.
2. This would need it’s own JS that was specific to this task.

Back when Adobe started briefing developers on Apollo/AIR, a few of us joked about WebKit running in a plug-in rendering web pages inside of a web browser. Funny to see it proposed as a serious idea.

With ScreamingMonkey proposing essentially the same idea with the JavaScript run-time, it’s interesting to imagine a world where Ajax applications can choose from several HTML renderers and JavaScript run-times, much like IE lets devs choose between the “Quirks” and “Standards” code paths.

Posted by Ben Galbraith at 9:02 pm
15 Comments

+----
1.7 rating from 135 votes

Tuesday, July 17th, 2007

Sales Builder AIR Application Update

Category: Adobe, Showcase

Christophe Coenraets has released a new Sales Builder (which he didn’t do on the bus! bad Christophe! :).

Salesbuilder is a Sales Force Automation application that demonstrates local persistence using the embedded SQLite database, data synchronization, native drag-and-drop, and other features such as direct chart manipulation.

It makes you wish that you had an “Experience Design team”.

Sales Builder AIR

Posted by Dion Almaer at 12:06 am
3 Comments

+++--
3.9 rating from 34 votes

Tuesday, July 10th, 2007

Bay Partners Announces Facebook AppFactory Seed Program

Category: Ajax, Announcements, Social Networks

Salil Deshpande has announced a bold move with the Facebook AppFactory. Bay Partners is announcing The AppFactory, a seed program to fund Facebook application developers via a fast-track process.

This program shows that Bay Partners believes that Facebook, in essence, has become the Social Operating System. And historically the creation of an operating system, or platform, has always led to the creation of an applications market atop that platform. “We think that the Facebook platform is broad enough, technically sound, appealing to businesses, and such a culture-fit for today’s internet ecosystem that it will become a significant and meaningful social operating system platform, if not the dominant one.”

We asked Salil, Partner at Bay Partners, a few questions on the news:

What are you investing?

We will award between $25,000 – $250,000 to between 10 and 50 entrepreneurs with a flexible, fast-track process. Because early investments of this size are really bets on people and concepts, Bay Partners looks at the AppFactory as a fantastic relationship starter with tomorrow’s innovators. Because the investments are small, when compared to traditional venture investments, and because the amount of due-diligence that be done on kernels of ideas is often also small, Bay expects entrepreneurs to invest no more than a few hours into the process, and expects to make go no-go decisions in days rather than weeks.

What does this mean for Ajax developers?

With announcements such as this, and Google Gadget Ventures, firms are putting money where their mouth is. We are seeing the birth of web platforms, and these platforms become distribution mechanisms for entrepreneurs. The technical bar is lowered, as it is easy to create applications on top of Facebook, Google Gadgets, and the other platforms out there.

Currently we see simple, almost trivial apps. As time goes on those apps will become more and more sophisticated, and will be a blend of on-platform and off-platform experiences, and will likely involve a lot of Ajax.

What types of applications do you foresee coming from this platform?

We definitely see the open Facebook platform resulting in real, valuable applications. We believe that the Facebook apps of the future will be deep and sophisticated and will strike the right balance between adding value to the Facebook fabric, and having value independent of Facebook. For example, a shipping app that lets Facebook friends transparently use a service such as LicketyShip to physically lend and borrow books listed as favorites from each other, can monetize by charging for the shipping. A stock picking app that lets friends view each others’ stock portfolios could monetize at the point where friends want their own portfolio to reflect a friend’s picks.

And can people really make money from Facebook applications?

Yes! Incorrect conclusions are being drawn from the unmonetizability of some apps that have spread fast on Facebook to date. Some apps are like jokes that get forwarded around by email – and will always be unmonetizable. But meaningful apps will be monetizable just as meaningful web 2.0 websites are monetizable. We are interested in backing entrepreneurs that will be imaginative about what types of applications can be built on Facebook’s Social OS.

Facebook’s user interface is critiqued as being sterile – not very rich , flexible, customizable, or personal. Will this change things?

First off, the Facebook apps we are looking to fund are not necessarily those that focus only on jazzing up the user experience. Having said that, yes, we definitely think that the open API will allow a whole new level and set of rich experiences to be available on Facebook. Now that Facebook has put itself in the platform business, the application developer community is bound to create rich user experiences, whether they are enhancements to Facebook’s current user experience, or alternative user experiences.

What will the other social networks’ APIs look like?

Here’s some bold speculation. By the time other social networks open up their platforms, Facebook may have a sizeable lead in developer mindshare, and in the number of applications on their platform. The other social networks may struggle if they introduce APIs that are not compatible with Facebook’s. We think that the other networks should consider making their API compatible, if not identical, to the FaceBook API. This will allow one-click deploy of apps written for the FaceBook platform, onto the other platforms, thus mitigating Facebook’s lead. And we think they will seriously consider this.

This once again shows what a great time it is for Ajax developers. Everyone wants us!

Posted by Dion Almaer at 12:38 am
7 Comments

+++--
3.9 rating from 32 votes

Monday, June 25th, 2007

In defense of Ajax for the iPhone

Category: iPhone

Ryan Breen has been reading our coverage on the iPhone and has some opinions that he lays out in defense of Ajax for the iPhone.

He comments on the latency issues, how offline storage can come into play, the place for Ajax frameworks, access to “native” features, and community, finishing with:

But perhaps the most important factor behind the inevitability of Ajax for the iPhone is the way it opens development to such a broad community. Traditional mobile application development, with its ‘Real SDKs,’ is restricted to the few with the time or inclination to develop for a specific device. The iPhone’s model means that anyone with the time and inclination to build a web application is an iPhone developer. Certainly there will be a spectrum of applications, from web applications you happen to use on an iPhone to those that have been tuned for the interaction model and presentational features of the iPhone, but again, frameworks should make it easy for all developers to move towards the end of the spectrum that approximates native applications.

The iPhone is one of the first mobile devices, and definitely the first with a cell phone form factor, to provide a true browsing experience. But in a few years I expect all mobile devices to provide the same browsing experience. With that, the line between traditional and mobile web development will further blur, with Ajax frameworks helping developers deliver consistent and appropriate experiences on each.

All good stuff. Although I bet some of the Nokia guys, with their WebKit phones and saying “look at me!”.

Posted by Dion Almaer at 12:19 am
18 Comments

++++-
4.1 rating from 18 votes

Thursday, June 21st, 2007

DP_Debug: JavaScript Debugging Extensions

Category: JavaScript, Library

Jim Davis has released a simple little JavaScript dumping library, DP_Debug, that supports circular and recursive references, most system objects and specifies certain otherwise ambiguous conditions. It allows for depth of recursion control, labeling and interactive collapse/expand of results. It’s based in essence on the ColdFusion CFDUMP.

In addition the library allows for simple access to Query String and Cookie values and provides basic logging, code timing support and program integration support (the ability to enable or disable debugging). There’s also built in quick reference documentation.

  • dump(): Converts JavaScript objects (their properties, values and relationships) to an HTML representation and displays this in the console for review. It supports objects with circular/recursive references. It’s similar to the insanely useful CFDUMP tag in ColdFusion.
  • dumpCookies(): A convenience method which dumps all available browser cookies to the console.
  • dumpQueryString(): A convenience method which dumps all available query-string names and values to the console.
  • logger(): A method for logging messages to the console using either custom or predefined types. logInfo(), logWarning() and logError() are all shortcut methods for logging specific types of messages easily.
  • timer(): A method for timing blocks of code.
  • getType(): Provides more advanced Object type-recognition than the native “typeof” operator.

Posted by Dion Almaer at 12:04 pm
8 Comments

+++--
3.6 rating from 22 votes

Wednesday, June 20th, 2007

Ajax applications and SEO

Category: Articles

Rich McIver has written a piece on The best ways to incorporate the benefits of Ajax without making your site blind to search engines.

The article talks about how not to use cloaking, div layering, and instead:

  • Design your site with degradable AJAX, that way users with JavaScript disabled can view a working version of your website along with JavaScript enabled visitors.
  • After you’ve established a non-AJAX working version of your website, go back and include an alternative AJAX enhancements where you desire.
  • When designing, make sure to check your website with JavaScript disabled as well as through the eyes of a text only browser such as Lynx or SEO-Browser.
  • Perform a browser check to make sure the user has JavaScript enabled, that way you’re only serving AJAX pages to users that can view them.

What has been your experience with building SEO aware rich Ajax applications?

Posted by Dion Almaer at 8:58 am
5 Comments

+++--
3.5 rating from 22 votes