Aaron has a nice editorial piece on going from zero-install to instant-install in which he discusses the notion of web apps:

Bringing back a lightweight notion of installation offers an interesting way out of Web constraints. If an author uses APIs like window.open() and desktop notifications in an annoying way, his app will be uninstalled. The UA can make it easy for the user to discover the uninstall button, so there’s a strong incentive for authors to not be assholes. Since there are a manageable number of apps installed at any one time (by definition, since they were manually installed), UAs can offer permanent storage to apps. If the apps abuse the privilege, the user can easily scan a list, see which one is doing it and uninstall it.

He discusses the revolution of the “zero install” Web. We pass people URLs. We link to things. We don’t think of this as “running apps”. He then brings up the issues of this freedom. Since my mum doesn’t think of this as running apps, we shouldn’t grant access to these URLs, and we end up with a strong sandbox, which limits functionality.

With “installable web apps” we get some of the best of both worlds, but it doesn’t quite feel like we have matched a perfect equilibrium yet. As a power user, I am excited about taking a strong sandboxed model and opening it up with APIs that all go through the sandbox. This means that I can monitor everything that is going on. Add to this social monitoring (so if something bad happens it quickly moves through the social network to be fixed and blocked) and I look forward to a blended world of permissions. We have long had the ability to break through the sandbox in browsers. Unfortunately, these methods are browser specific, and result in annoying prompts that drive you nuts. As we scale out the permissions, this becomes more annoying. To get around this, some platforms are asking the user to accept permission at install time. You have the advantage that: a) the user has to agree before anything is even downloaded; b) one click, at the time of install, and you are off to the races.

However, there are huge problems: When prompted at this time, there is a strong likelihood that the user is trying to do something and will thus say YES YES YES no matter what. Some may question an 8-ball app that asks for deep permissions, but even then…. we run into the same prompty neglect that we get on the desktop. Have you ever downloaded a Mac app, ran it, and then when the “this app came from the Internet” dialog showed up…. said “you know what. Naaaah”? And what about nuance? Weather apps ask for access to the GPS. What if you want to use the app (and search for an area) but don’t want to give location information? Some systems won’t let you download the app (this is where the Web Geolocation API is great!)

Installable == special powers. Uninstalled == less powers. I still have hope that after these first steps we get the right metaphors that offer simplicity for users, but nice fine grained control and awareness.

Progressive enhancement.

Disconnected offline applications.

There is a tension brewing in how we deliver applications on the Web. This isn't a new tension. It has been around ever since we started to do more than just throw HTML down the pipe for the hypertext document runtime to render.

With the Ajax revolution we talked a lot about "Web applications". Gmail. Google Maps. Those are written in a very different manner. The architecture isn't one of: client asks for a URL.... server does all of the work: business logic, and view logic, since it sends back the entire view as HTML. A popular Ajax pattern was that of still keeping the client kinda dumb, and having the server return interface elements and behaviour in the form of HTML/CSS/JS that the client would eval/innerHTML/etc. This continues to be used a lot as it is flexible (especially if the bulk of the team is on the server side) and sometimes easier to do (chop up the functionality on the backend into more discrete tasks). This is a progressive enhancement style of richer Web applications.

When I was working with Gears I saw first hand how reluctant developers were to move from the progressive enhancement style into a more aggressive client server-esque style of Web application development. The Gears APIs themselves are trivial. Nicely implemented. Simple APIs. We get to use them these days in the form of App Cache, SQL database API, Web Workers, GeoLocation, etc. Taking your application and sprinkling a GeoLocation API is very simple and fits into progressive enhancement easily. Even doing what the WordPress guys did early on, and using App Cache as an aggressive fast cache is easy.

The harder sell to developers was: If you want to have your Web application work offline, you need to re-architect it to enable that. Instead of having your PHPs firing down interfaces, you need the client to coordinate the work and just speak REST to services that give you the data, and then have a layer of abstraction that can get the data locally etc. Then you can look at handling sync and the like. This is real work. This is moving code from point A to point B. It is a big deal. Many developers didn't see the value proposition. Do they REALLY care about the offline use case? Getting some performance improvements by taking out latency is nice (hit cache first etc) but is that worth the rework?

For many people, it just wasn't worth it.

As I look at what is changing in the world, I see a few things that may add up collectively to a tipping point:

"HTML5" hype

HTML5 has a lot of great functionality. There will be pressure for developers and sites to raise the bar. Expectations of what a Web application "can do" is drastically going to change, and as soon as that change happens you don't want to be left behind. MapQuest was fantastic. Until Google Maps came out. Then, on that day forth, it felt archaic. All of that with XHR++..... what will happen with all of the HTML5 functionality available? A lot of code we will be rewritten and changed for "HTML5ication", which is an opportunity for a change in how things are done.

"Apps" and the Web as a unified device platform

I haven't been quiet with my concern at the rise of the proprietary app platforms. The Web needs to fight back, and it has the opportunity to actually solve developer problems (rather than just rant about how the world should be more open damn it!).

As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No. The Web has the opportunity to share a lot of that code and development. It has to compete with the native platforms on features, performance, and the like.... but I would argue that it is doing a great job and getting better FAST.

Within the apps ecosystem there are some very interesting things happening:

Chrome Web Store: The Chrome Web Store is happening. I know of other Web store efforts in various stages of life too. A lot of developers want to get into the app distribution bandwagon, and will be looking at the notion of a "web app" in a new light because of this. This will give a lot of momentum, along with the fact that HTML5 is the first real spec envisioned for "app" functionality versus documents, to the web app movement.

Mobile Web: As developers want to get applications to as many devices as possible, they are finding that the Mobile Web is an attractive development platform. But, how do you do it? If you think about Web distribution, then you have the progressive enhancement world again (device and layout tweaks via CSS, JS, etc) all the way up to a mobile framework. We see the two worlds with jQTouch on one side and Sencha Touch on the other.

Take a look at how an app looks in Sencha Touch:

templates in HTML

OO app framework with layout and components

This looks similar to how we build apps on webOS with Mojo and other frameworks like Jo. Rich full featured mobile frameworks.

Once you have built your Web application, technology such as PhoneGap and Appcelerator Titanium can package it for the various app distribution platforms.

So, when I put this all together, I see the opportunity for the growth of Web applications through both progressive enhancement, but also via rich client frameworks. The tension will be there between the two, and I am sure that there will be more solutions that blend the best of both worlds.

What do you think? What are you seeing as you build richer Web applications for a variety of devices and form factors?

What does Open Web mean?

What does Ajax mean? Is it AJAX or Ajax?

Remember those discussions? We had the arguments ... the purists who would shout and scream if you said something was Ajax and didn't use XHR with async mode + XML as the format. Ajax beat our AJAX and became the new term for DHTML and the term that meant "all of the cool shizzle that browsers and JS library authors are now doing!"

The new king on the hill is "HTML5" which has taken that exact mantle. One extreme view is that the term is marketing drivel. The other is that it should ONLY be used to mean the W3C version of the HTML5 core specification.

Brad Neuberg enjoys thinking about these things and has put together some thoughts in two posts: Why I'm Going to Keep Calling it HTML5 and HTML5 Defined! It's Not Just a Marketing Term.

I really like how Brad goes deeper on HTML5. It is far too confusing to know what capabilities are in browsers, what specs they are in, and what really matters... what can I use as a Web developer.

Brad takes apart the various specs and APIs:

Going deeper, I've broken these down into separate areas:

• "HTML5 Strict" - Things that are strictly inside the W3C's HTML5 spec.
• "Referenced by HTML5" - Things that are referenced by the HTML5 spec and which can optionally be parsed into the DOM and displayed.
• "Broken out of HTML5" - Things that used to be part of HTML5 or its older iterations, called Web Applications and Web Forms.
• "HTML5 Family of Technologies" - Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5.
• "HTML5++" - More experimental technologies pushing the web forward that are not part of the HTML5 spec at all; may or may not see broader adoption.

One small note; there are actually two HTML5 specs, one maintained by the W3C and the other maintained by the WhatWG.

You need to understand that HTML5 began as a revolution to the established order, initiated by the WhatWG. A peace of sorts developed over the years, with the upstart "Web Applications" and "Web Forms" specs brought in-house to the W3C under the moniker HTML5. Over time I'm assuming that the W3C spec, when Final Call has happened, will be the canonical spec.

To simplify things below, I'm only referencing the W3C HTML5 spec for now. Here's how I would break things down based on what I said above; if you think something should be somewhere else or things get moved around email me and I'll update this (Last Updated: June 7th, 2010). If you want to know the state of where these technologies are implemented see caniuse.com; if you want your code to detect what is available see Mark Pilgrim's book for details.

"HTML5 Strict": Strictly Inside the W3C's HTML5 Spec

• HTML5 Doctype: <!doctype html>
• HTML5 parsing
• XHTML5 serialization
• Cleaning up edge cases of existing web content for greater compatibility
• New semantic, behavior, and application tags: section, nav, article, aside, hgroup, header, footer, address, figure, figcaption, time, code, var, samp, kbd, output, progress, meter, details, summary, command, menu
• Being able to nest H1, H2, etc. arbitrarily
• Sandbox attribute on iframes
• Video tag, API and events
• Audio tag, API, and events
• New form input types: telephone, search, url, e-mail, date, time, month, week, number, range, color
• New form abilities: multiple file upload; placeholder text; directing focus on initial page load; constraint validation by input type and properties
• New link rel types: alternate, archives, author, bookmark, external, help, icon, license, nofollow, noreferrer, pingback, prefetch, search, sidebar, tag, index, up, first, last, next, prev
• data-* attributes for SCRIPT tags
• Offline Web applications
• contenteditable for editing
• Drag and Drop
• UndoManager for consistent undos
• Parsing empty and unknown tags into the DOM: <foobar />
• async attribute on SCRIPT tags
• PUT and DELETE methods for form submission
• Deprecated elements: acronym, applet, basefont, big, center, dir, font, frame, frameset, isindex, noframes, s, strike, tt, u

"Referenced by HTML5": Referenced from W3C HTML5 spec, including how to parse into an HTML5 DOM; HTML5 parsing engines can optionally include these in DOM and display them

• MathML
• SVG

"Broken Out of HTML5": Used to be inside of HTML5, Web Applications, or Web Forms specifications

• Web Sockets
• Local Persistent Storage (localStorage and sessionStorage)
• SQL Storage (in contention versus IndexDB)
• DataGrid
• Specific HTML5 Video codec: H.264, Ogg/Theora, WebM (contention between video codecs)
• Specific HTML5 Audio codec
• Device element
• Ping attribute
• Timed track model for media elements
• Canvas
• Microdata and Microdata Vocabularies (some level of contention versus RDFa and Microformats)
• Cross-document messaging
• Channel messaging
• W3C XMLHttpRequest specification
• Server-Sent Events
• Ajax Session History
• MIME type and Protocol handler registration
• P2P connections

"HTML5 Family of Technologies": Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5

• CSS3
  • Flex Box Layout
  • Multi-Column Layout
  • Animations
  • Transforms (2D and 3D)
  • Transitions
  • Masking and Effects (rounded corners, shadows, etc.)
  • Gradients
  • CSS3 Selectors
  • Media Queries
• Web Fonts - CSS 2.1 @font-face + OpenType/WOFF (slight contention for OpenType vs. WOFF)
• W3C Geolocation
• Metadata - RDFa, Microformats (Some level of contention vs. Microdata)
• Web workers
• ARIA
• EcmaScript 5
• Faster JavaScript
• CSS styling of new HTML5 input types (color, range, etc.)
• IndexDB (in contention versus SQL Storage)
• querySelector/querySelectorAll
• getElementsByClassName
• GPU acceleration of HTML, Canvas, SVG, and CSS3 Animations/Transitions/Transforms

"HTML5++": More experimental technologies pushing the web forward; may or may not see broader adoption

• WebGL
• O3D
• Firefox Audio APIs
• XBL 2.0

We can argue about which term to use when, but I am much more excited about is explaining the capabilities and working together on nice stacks so we can build killer applications on the Web platform in a productive manner.

Check out a nice info graphic on all things HTML5:

I have been talking in analogy for the last few days. The common meme is relating the computing usage trends to that of the car industry. As I watch continue to watch my family use their devices, it does feel like things are changing. My mum continues to thrive on her iPad / Palm Pixi combo. She feels empowered to try the different corners of the experience. To download new experiences. She is having fun.

One friend suggested that it is like the shift (pun intended) that we saw when automatic transmissions were introduced. At first they were expensive and had some issues, but being able to have simple controls changed the way that people drove. It became so simple. There were people who cried that it would never take off. "People want the control of a manual stick shift system!" However, although we continue to see some die-hards, the vaste majority of the US population drive automatics (this isn't true everywhere in the world). That battle is over. We will never go back.

The iPad experience is like driving the computing experience without the manual hassle. You don't have to know how to install the engine to start out (install an OS), nor deal with (and worry endlessly about) the workings. In general, you just don't need to worry about all of the abstractions any more. The notion of files. And, don't get me started on viruses.

As my mother thrives on her iPad, I use it sparingly, mainly as an entertainment consumption device. Wait a minute: Am I am the guy who loves the stick shift and never wants to jump to an automatic? I am a little different from the religious chaps who claimed they couldn't understand why anyone would want an automatic. Or looked down on those people. I understand why my Mum prefers the iPad experience.

I do find the iPad experience often frustrating however. My "why did the car shift then? it wasn't time!" moments occur mainly around the restricted access to customization, and the inherent and enforced immersion.

First a small thing, which will unfortunately show off an how anal I can be:

I want to rename this to "BBC News". I am the guy who winces when someone bookmarks a page and doesn't rename it, thus having "Foo.com - a barish company that deals in widgets, gadgets, monkeys, and flubbers". I want to jump in and rename it to "Foo" on the bookmark bar. More space. More room. Petty for sure.

Where it gets more real for me is in the lack of integration between applications. Being immersed with one application at a time can be a fantastic thing, I will give you that... even if I often would love to give a bit of screen real estate to me Twitter stream while working on another app right next to it. However, if you live in an immersive environment, you need great integration between experiences. I should be able to Tweet/Share from any application, and not have to close down the app, go to a Twitter client, and get back to the app that had content I was tweeting. A lot of this comes down to multitasking, but more comes from integration..... and putting intents on a stack. On the iPad I feel like I am jumping through doors without an easy way to go back.

The browser has some of these notions baked in. States have URLs that I can bookmark. I can go forward and back. I can search. I can fork off (new tab). Turns out, I really like those abstractions, and miss them when they are not there, and every single app tries to reproduce some of them. They are often cross cutting concerns. I don't want the app developer to have to write code and choose where to put a "Share" button. I want the system to know that I have an account on Twitter and let me share with a simple gesture.

Back to the Web. I was a little stunned when a friend showed me the Speed Test.net experience on an iPad:

Yup, if you go to speedtest.net, you are automatically redirected to the App Store. There is no way to trick it (again: would be nice to have customizability and tweak user agents etc).

To the credit of the speed test developers, the website is driven by Flash, which won't work.... so they are trying to do something good for a user. I get that.

However, I am scared to death to think of the Web going this way. You go to websites and get sent to apps directly. I *do* want user agents to tell me if apps are available (hence the App Discover experiment), but don't force me into the world of apps. I also think that doing what YouTube does and take over a URL in a certain way can be a good thing. I would love to install handlers for mime types.... so a certain link always opens up my favourite Twitter client say.

I personally prefer many of the Web experiences to the "new" app experiences. (I talked earlier about the abstractions that I find useful). This could break the Web. Data that was shared at the ReadWriteWeb Mobile Summit showed that the same users often hit a site using: mobile website, full website, and application. We are context switching in real-time already. Different views are best for different use cases.

It definitely feels like there is a shift in the force. We need to get the balance spot on as we move to automatic transmissions. What should be customizable. What should be locked down. As developers as well as consumers, we need to make our voices heard. What do you think?

The Chrome Web Store and its .crx installable zip archive bring up the question yet again of what a web app is. http://gmail.com is a Web app isn't it? What is the difference between that and gmail.crx?

The notion of an app can be a little scary when we think about the current incarnations. Having centralized closed marketplaces are un-webby. However, that says nothing for the technology, but rather the policy and implementation.

Atul has written a very nice piece that dives deep into the core issues:

I am not sure exactly what webby means, but if I had to guess, it would involve the kinds of qualities that Mitchell Baker and Mark Surman believe make the web better: more transparent, participatory, decentralized, and hackable.

He goes into detail on the benefits of untethered applications, beyond "working offline". We can get to a better place where some apps, and pieces of apps, can work very well untethered. Of course, many applications out there quickly talk to the Internet, but a disconnected cacheable world makes a lot of sense (CouchDB apps :). It feels silly to go to a simple one player game at http://somegame.com/ and not be able to play because of the Internet connection. AppCache and friends go along way, but there is more.

Another key piece is permissions. As I watch folks talk about the W3C Widget Spec and the Chrome Web App manifest, permissions seems to be the crux of the matter. We need people to focus on this piece. If we can collectively crack that nut, my gut tells there will be an explosion of amazing things... and the world will make more sense.

Atul also talks about the Web of Trust:

Another area in which Installable Web Apps could decentralize the internet has to do with the field of trust. It’s currently very difficult to actually prove that a piece of Web content or functionality I created came from me, and wasn’t altered at some point by someone else. The only viable way to do this is via Secure HTTP, which requires asking an authority for permission to issue you a certificate. That this frequently involves paying them money and that the system is susceptible to corruption are besides the point. As Mark Surman mentions in a draft of Drumbeat’s mission statement:

"Ultimately, our goal is a strong, safe open internet: an internet built and backed by a massive global community committed to the idea that everyone should all be able to freely create, innovate and express ideas online without asking permission from others."

It should be possible to prove to other people that something came from you without having to ask permission from someone else, and in this respect, even though this mechanism is part of the Web, I would argue that it is profoundly un-webby. Google’s proposal for Installable Web Applications associates an application’s identity with a public key that doesn’t require a blessing from any kind of authority; all versions of the application are self-signed by the key, which makes it far easier to establish trust between a user and an application. The trust model is also more granular and secure, because it creates a trust relationship between the user and the particular application they’re using, rather than the server they’re connecting to—which often isn’t even under a web developer’s full control. It’s because of this that we’re using a similar mechanism in Jetpack; extending it to the entire Web would be very webby, not coincidentally because it establishes a foundation for what could eventually become a web of trust.

I am really enjoying the conversations and thoughts that have come out of the strong competition from proprietary app platforms.

It feels like the scale of our movement has changed from infighting (Gecko vs. WebKit vs. Trident) to collective war (Web vs. proprietary app platforms). The Google folks who believe in the Web (Chrome++) are more aligned to what we are doing at Palm, and what Mozilla is doing.... than the Android platform. Ditto for Safari/iPhone.

The world keeps getting more interesting. The browsers have strong competition internally, and now the platform has competition.

On the panel were distinguished gents. In the photo (courtesy of TechCrunch) you see (sitting from left to right): Alex Russell (Google), Brendan Eich (Mozilla), Charles McCathieNevile (Opera Software), Giorgio Sardo (Microsoft Corporation), and Douglas Crockford (Yahoo! Inc.).

TechCrunch has a detailed post on the Q&A, and then also dives into one question, responding to Joe Hewitt's Tweets from last week on the Web platform.

I think that Alex Russell responded fantastically. He has been a developer, dealing with the ugly underbelly of the browsers (and old ones). He is fighting to make a difference with Chrome Frame among other things. The Web has a long way to go. The last thing we want is for it to become the ghetto which Steve Jobs wants. In an ideal world, "apps" would be premium real estate, and the long tail of crud lives in the Web ghetto.

Chris Anderson scared me a little on this topic in a keynote he gave at the MarkLogic conference yesterday. He talked about having the Web be a way to engage with community and tease them into the premium options. Maybe a few free Wired articles here and there, but get the "App" for the real deal. People are used to purchasing apps, and he thinks that he can technically do more on app platforms.

However, it doesn't have to be that way. Scribd is going HTML5 and the screenshots of their new code looks great:

As a community we need to come together again and show the world that we can deliver amazing experiences, that the Web can be THE platform (and has a role in the world of apps....) and engage with browser vendors and standards to push the Web faster. We can do it.

One other topic of conversation from the panel was IE9 and Canvas. I asked the crowd who would like to see canvas supported in IE9 (didn't show up in yesterdays preview). 80% of the crowd put their hands up, and I am sure the other 20% just didn't get them up in time ;) Giorgio of Microsoft himself put his hand up, which was nice. The strange comment from him was that the canvas spec is "big" which was refuted by Brendan. Microsoft has implemented SVG support which is massive in comparison, and I am sure they could wire together canvas API calls to the underlying 2d engine ;)

I would love to hear a reason from Microsoft on why they are not supporting canvas. They may have a valid reason, but I haven't heard it yet. Dean has been open to communicating on HTML5 video on his blog, so maybe you could answer this one mate? It could be that they just haven't gotten around to it yet and it will show up in a new preview. Let me know and I will shut the hell up.

It is fantastic that Microsoft is being more open. Giorgio showed up at the panel yesterday. Dean is blogging. Compare that to the Safari team. I would *love* to have those guys speaking.... Dave Hyatt, Maciej, etc are all amazing.... but that isn't the Apple Way. Thanks for sitting at the table Microsoft..... and I hope it continues.

• They gave us Canvas, and CSS transforms, and ...
• They brought us WebKit, and now WebKit 2
• By blocking Flash on their mobile platform, they force people to take HTML5 video seriously
• iAds shows off HTML5, and Jobs was sure to let us know about that.

Great technology. Great for the Web.

Then we see the section 3.3.1 change to their developer terms which has people thinking that the Flash compiler is toast just before CS5 is about to come out.

This same change to the terms may also affect some of our own. For example, the Titanium crew. PhoneGap appears to be safe by the letter of the law, since they link to the iPhone OS WebKit engine. I hope that Apple responds wrt Titanium.

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Some on the Apple side are arguing that:

• Objective-C apps are good. Anything else is crap. When folks try to go meta, they shouldn't be allowed
• And hey, Apple can do whatever they want.

Although I can see how this could in some ways help the Open Web (less Flash, more HTML), I can't ignore the other feeling. The Web is so special as it isn't owned by a single vendor. This means that this kind of crap can't happen. One company can't change the rules in one fell swoop. There isn't that one company that can become misaligned with the interests of certain developers and Do Bad Things.

I continue to look forward to what Apple does to help the Web. But I am very glad indeed that the Web itself isn't run by them, or any one group.

I hope that the Web becomes the unified platform on mobile.... and that folks like Titanium have the opportunity to do their best. Developers should be able to use the languages and tools of their choice, and let the best apps win.

Many (if not most) current Flash games, menus, and even video players require a visible mouse pointer. They are coded to rely on the difference between hovering over something (mouseover) vs. actually clicking. This distinction is not rare. It’s pervasive, fundamental to interactive design, and vital to the basic use of Flash content. New Flash content designed just for touchscreens can be done, but people want existing Flash sites to work. All of them—not just some here and there—and in a usable manner. That’s impossible no matter what.
....
Mouseover examples:

* Video players where the controls appear on mouseover and hide otherwise. (This seems to be the norm, in fact. Whereas a click on the same video does something different: usually Pause. Try Hulu for instance.)

* Games where you steer with the mouse without clicking (extremely common).

* Menus that popup up subpage links when you mouse over a main button, vs. going directly to a main category page when you click.
....

He claims all the alternatives are unsatisfactory, e.g. re-coding every application manually, introducing gestures, substituting double-clicking for clicking and clicking for mouseovers.

The issues are relevant to Javascript developers; for example, PPK has previously speculated on the demise of mouse* events, as well as hover in touch environments. How will that play out with a web app that relies on them?

It's a bit like Dion's recent tweet: "I find myself typing click^H^H^H^H^Htap 20 times a day at the moment. Is there a term that abstractly could mean both? :)". We can get away with simple substitutions with straightforward web apps maybe, but it gets a lot more complicated with seriously rich interaction styles, the kind traditionally seen in some Flash games and now possible with Javascript. We tend to think of mobile device design as a matter of massaging the look with some CSS...the harder part to get right is often the "feel" in the look-and-feel equation. Platforms, like the web, which want to support multiple interaction styles, need to provide ways to ease the transition for developers, automating degradation and enhancement in the first instance, but allowing application designers to customise further for each device. Dan Saffer's sideshow below makes the point well, regarding gesture design in touch devices:

Steve Jobs didn't hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out "stupid keys" (print screen, F keys, and the like) and swore a lot.

We love to paint with broad black and white brushes these days don't we? Whenever I hear people talking about Google being "evil" or not.... I sit back and think about how interesting it is that companies become "people", especially in this country.

It makes sense when you look up Corporation:

Corporations are recognized by the law to have rights and responsibilities like actual people.

That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn't a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.

I have been thinking about this ever since the recently surprise court decision the other day that "allows corporations and unions to pour unprecedented amounts of money into elections."

Lawrence Lessig had some interesting commentary:

The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.

Fun aside

My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on "the mind".

The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.

Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn't just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren't solely based on profit. They want to create a different kind of legacy and company.

That being said, I think it is quite easy to fall into a trap such as:

If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!

Google will sometimes do things that could be considered "evil" by some. That is life.

The good news with Google is that their search and ads business deals in a trust economy. It doesn't take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.

Not all corporations are profit driven

I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make .... you think of the mission.

It was interesting to work there knowing that I actually wouldn't want Firefox to be a 90% browser. You can fall into the similar trap as above and think:

We are mission based! If we had that domination we would use it for good!

But, not having that power in one hand is even better. Imagine working somewhere thinking "in my wildest dreams, the market would be shared somewhat evenly with the competition." The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can't move as fast as a dictatorship, but there is a reason we don't want dictatorships in our government (even if the trains run on time!)

And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn't dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.

I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don't want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can't Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.

I don't want to "kill" these other platforms as they offer competition and spur on the industry. I just don't want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?

Erm, no.

And thus I find myself torn. I really want to go out and by that iPad....... but when is it "too late". Surely I have a few years right? I can enjoy the shiny new toy? :)

Faruk Ate? also has a nice post on where he see's Flash going which is bolder than mine :)

What do you think?

Do you feel that view source added to the popularity of the Web? or that it was just a nice to have that is neither here nor there? Other technologies have tried to bolt it on (e.g. in Flex you can opt-in to view source) but opt-in to a developer flips a bit of "hmm no I will keep this to myself" for various reasons.

I personally feel like the ability to view source fit in perfectly with the culture of the Web, and was especially important early on. I am willing to bet that we have all learned from the notion of view source.

However, it is also true that in some ways our front ends are getting a lot more complex and by the time you run a compressor through, or a tool like GWT/Cappuccino/insert others there isn't much to learn. Of course, on the back end all the code is hidden and we have found ways to learn there (big thanks to open source and communities that have sprung up).

The notion of view source is under attack. How hard to we try to fight it? How do we fight it?

Keep reading Alex's post which has some good stuff such as:

To understand the importance of view-source, consider how people learn. Some evidence exists that even trained software engineers chose to work with copy-and-pasted example code. Participants in the linked study even expressed guilt over it the copy-paste-tweak method of learning, but guilt didn’t change the dynamic: a blank slate and abstract documentation doesn’t facilitate learning nearly as well as poking at an example and feeling out the edges and possibilities by doing. View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, loading it in a browser and switching between editor and browser between even the most minor changes. This is a stark contrast with other types of development, notably those that impose a compilation step on development, in which the process of seeing what what done requires an intermediate action. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop. The only required equipment is a text editor and a web browser, tools that are completely free.

"View Source is your friend", we've learned countless times as web developers. It's something special about web development that we can seamlessly lift the covers on anything we see and find out how the sausage is made. And it gets even better with great tools to interrogate the system in real-time. This capability has helped us evolve practices and patterns, and contributed to the production of many a fine browser extension and Greasemonkey script.

Our friend might sadly be going the way of the blink tag. View Source has always worked because the standard development model is to put up some static Javascript files on a server somewhere and serve them out. That model is changing though; performance is a very hot topic right now, and View Source is playing victim to that trend.

Google's Let's Make the Web Faster initiative is a case in point. Here is a multi-pronged attack on the performance issue, involving new protocols (SPDY), tools (PageSpeed), browser improvements (Chrome), on-demand loading (Closure), and - most pertinent - compression techniques (Closure again). And we ain't seen nothing yet; there's every reason to believe Google will soon be putting its money where its mouth is, by rewarding faster sites with higher rankings. (I guess I was alone in assuming they always did that.) While performance should always be a consideration for site owners, a dangling SEO carrot would no doubt convert the best of intentions into the most concrete of actions.

Site owners can't (much) control factors such as browser choice and browser efficiency, but they can get their own performance-fu in order, and code compression is low-hanging fruit. Looking at the top 20-ranked sites, filtering only English-language sites, I found the very top guys (Google, Facebook, Yahoo, YouTube, Windows Live) predominately using Javascript compression, with the others not using it much, if at all. I expect most of them to be using it in the next 12-24 months.

In addition to compression, there is also obfuscation. With Javascript being used for more complex tasks and replacing desktop functionality, more companies will be wondering about all that intellectual property sitting in plain view. (And let's not mention the security-by-obscurity fans, who will also go this route, however flawed their thinking.)

Is it all bad? No. There's a much healthier respect for plain old semantic HTML these days, which means HTML documents should be View Sourcier now than ever before. (CSS, not so much, with compression also likely to grow.) If I had to choose between one or the other, I'd take clear HTML over clear Javascript. Also, we will probably find the majority of sites in the long tail won't feel the need to do anything about their code (but the ones who do make efforts are probably the ones with the most interesting things to look at). Also, the aforementioned tools, which do things like XHR sniffing, will help us to understand from a "black box" perspective even if we can't peer into the code. Hopefully, there will also be more attention paid towards Javascript beautifiers as well, to make sense of compressed code.

I can't speculate on the waning of View Source without mentioning the tremendous counter-balancing act played out by Open Source. From the get-go, open source has played a vital role in Ajax, with individuals and companies releasing code for all sorts of reasons. Most of this is library and framework code, rather than production-ready applications, so we might lose something there, but we still have much to gain from the ever-growing corpus of code that's out there, free to be studied and incorporated into our own applications.

CBC Radio 3 is a community, radio station and user-generated independent music library which is a small department of the Canadian Broadcasting Corporation. When the CBC Radio 3 web team was called upon to rebuild the site we were confronted with the technical problem of having an uninterrupted music experience for our users. The old design of the site (see image) achieved this by embedding a flash player in the body with the content being served through a statically positioned iframe in the center of the page. Radio 3's content offerings were outgrowing the design so we went with a full page 1000px-wide layout with the player resting in the page. This created an obvious hurdle being that with a fresh page load comes a bad listening experience like myspace where a single wrong click breaks the audio. Also, not having popup player was a design decision that was made to give the website a more integrated feel.

We decided to completely removed flash from the UI equation and went full html/ajax because we found that it offered more flexibility and play with the page. The hardest part was figuring out a way to maintain state on each page load while keeping the audio continuous.

We went with an old-school frameset to create a type of inter-frame communication with the top level frameset acting as the orchestrator/bootstrapper. The visible "UI Controller" frame is completely blown out with the stateful player frame hidden from view.

The stateful player frame contains hidden swfs to handle playing audio and connecting to RTMP for our live streaming. All the communication in and out of flash is handled by a couple gateway javascript classes to abstract out the flash from the rest of the application.

Here's an example of a communication gateway for wrapping the events coming to and from flash. The event objects are native flash event objects that get sent by Flash's ExternalInterface and come in as JSON that can:

A single instance of this gateway is always maintained in the application which is called by a sort of simple container like this:

An instance of the gateway has to be maintained by the player application because events coming from flash have no context. This way the application classes can subscribe to events coming from flash like this:

At the core, audio is always played by Flash. The swfs broadcast events, such as audio head position and download progress of mp3s, and connection, streaming, meta data events from RTMP. Those events get passed on the instance of the hidden stateful player.

Since the server frame is only loaded once when the site first loads, an instance of the stateful server player is instantiated for the entire session on the site. On each client frame page load, the server player instance is "injected" into the visible client UI controller by the "bootstrapper" top frame. State is maintained in that instance which allows for the controller to query the state of that object and reestablish everything like which track is playing, progress, time, thumbs up or down status, shuffle, play mode (stream or individual mp3 and playlists), etc. Everything had to be covered like if an mp3 was in mid-load when someone browsed to a new page, the loading progress had to pickup on the next page. Here's a example of the bootstrapper code contained in the frameset:

We used Prototype/Scriptaculous as the base for the entire site. All the AJAX communication is handled with asp.net web services with scripting enabled. ASP.NET takes care of all the serialization of DTO's (Data Transfer Object) into JSON which are specific to the player application.

All of the classes in the application are written using Prototype's Class/inheritance model. Most of the classes subclass from a base EventDispatcher much like AS3, which is adapted from Matthew Foster's example for Prototype and our own custom Event model. This allows for a nice separation of concerns and decoupled classes throughout the application and allows the UI Controller to add event listeners to custom events coming from the server player instance.

This also allows the UI Controller to unsubscribe from all events when the page unloads. This was key in memory management and so that we don't get orphaned references to instances of the UI Controller.

The most difficult part of the whole player project was re-establishing state of the controller on every page load. We hoped that we could implement some sort of state-pattern with no luck. In the end, the UI controller contains a couple monster resume methods that we haven't been able to abstract out of that class. We'd like to bring in some sort of MVC architecture that wires up the UI player view to a state object. Any suggestions would be welcome! Go check out the site and give us some feedback!

Dion: I then asked Phil about the CBCR3 library and he replied

CBCR3 is the base namespace for all th javascript controls and apps written for the site. Everything for the player is in CBCR3.Player, the concert calendar is CBCR3.Gigs, etc. We have a shared base lib which is in CBCR3.Commons.

An issue with Prototype that we had was some bug with including 1.6.1 in a frameset in Opera. So, right now the frameset is holding an older version of prototype while the frames have the latest. One thing that Prototype was seriously lacking was Date extensions. (like addDay, addMonth, addWeek) etc.
We ended up going with YUI's DateMath widget for that which really smoothed out working with dates.

Most of the issues we had cross-browser stuff was with IE6 (no surprise), which were almost all related to CSS rendering bugs, and IE DOM manipulation problems. A big one was upon the dynamic removal of items from lists. IE has a real hard time refreshing the positions of items. We had to write methods like

this would in effect "nudge" the browser and force it to update the position of the remaining DOM elements. In the end, we chose to drop IE6 support and to tell you the truth, we haven't heard a single complaint about it!

As editors-in-chief so to speak, I always feel that it is important to fully disclose to the community any affiliation change. We have always tried to by balanced, and show that by featuring all kinds of news (for example, we haven't been shy at posting about great WebKit tech while at Mozilla, or amazing IE news ( ;) when at Google.)

Ben and I are now at Palm leading up the developer relations team.

We started devphone awhile back as a place to talk about mobile dev, but I personally didn't have the gas to write a lot about that as I was mainly interested in the Web side of mobile development. Thus, my excitement when Palm released webOS and I had a nice path to take my Ajax skills to the rapidly growing mobile Web market.

You can expect to see some more mobile Web news, just because I will be looking at that world a lot more. However, you shouldn't expect to see any lack of other news, and we also love to accept contributions both as quick links to great Ajax news, but also guest posts. We really do see this as your community!

Also, expect to continue to see Bespin and Mozilla news, because we are very much going to continue to be involved in that community. I am in a Bespin meeting right now! Yay open source, and open companies like Mozilla!

Thanks for being loyal readers for the life of Ajaxian.com so far, and we look forward to serving you even more in the future!

Cheers,

Dion and Ben

He talks about an application that he has traditionally sold as a desktop app, and how it is faring on the Web. Bingo Card Creator is the application in question, and he has strong opinions :)

Over roughly the same period my day job has changed and transitioned me from writing thick clients in Swing to big freaking enterprise web apps. I’ve learned SQL, Rails, etc and used them to fairly decent effect in selling Bingo Card Creator, which is a Swing app (if all you have is a hammer…). This summer, I decided to try stepping my web programming skills up a notch, and released a web version of Bingo Card Creator. It has exceeded all my expectations: in ease of writing, in features, in sales, in support burden, in marketability, etc. In game theory terms, it strictly dominates the desktop version, when seen from the eyes of the developer at any rate.

If I were starting out today, I would, without a shadow of a doubt, write a web app instead of a desktop app, for these reasons:

• The Shareware Funnel Is Lethal
• Web Applications Convert Better
• Your AdWords Strategy Is Very Sensitive To Conversion Rates
• Web Applications Are Easier To Support
• The Age Of The Pirates Is Coming An End, Jack
• Phone Home vs. Google Analytics
• Web Apps Can Be Customized Per User

Interesting to read. Note, Patrick does admit that he much prefers desktop apps in general (e.g. Excel > Google Docs).

We are all so into the Web, that we are often very critical. Web apps are too hard to build. They are too hard to monetize. However, the grass isn't always greener on the other side, and this shows you how brown it can be.

Chrome OS created a whole slew of buzz around the Web finally being an OS. There are many other examples of this of course. On the desktop we have had the likes of moblin and Jolicloud for quite some time. On the phone we have webOS.

The Web as a virtual machine

In many ways, it seems obvious that this will happen. When I look at my desktop, I often find it looking like this:

which looks surprisingly similar to this:

Wait a minute. Can't you look at the browser as being a virtual machine for the Web? A hugely successful one that has been ported to almost every platform known to man. It is a viral virtual machine that has become so successful due to its simple yet powerful constructs that allowed the platforms to do the porting (oh and it was friggin made to be free! Take that gopher!). As a virtual machine it grew so fast that it is quickly usurping the hosts themselves. The traditional operating systems. Applications are being written for the VM rather than the OS. This is very different to the diagram that has Windows running inside a VM on the Mac. In that case you are running applications written for Windows on the Mac. The virtualization crew have done wonders to make that emulation possible. With the Web you didn't quite need those tricks, and instead thanks to Web standards, you just had to write a browser.

Going inside out

Normally, we have seen systems built natively and then we virtualize them. In the case of the Web, the "Web platform" is the host environment and the VM. As this environment has become stronger and stronger, there is bound to be the time to ask "do we need our host anymore?" We are on the fringe of that time right now where a huge bulk of the applications that people use are Web based.

I just ran an experiment in this area myself. The hard drive in my Macbook Pro died and while the kind folks at the local Apple store replaced it I had to pick up a random machine for use. What would life be like if I had to work on a random machine? I purposely didn't restore from my own backup, and ended up with a week seeing how much of this cloud thing I use.

It turned out that all of the apps that weren't somehow cloud based were now a pain in the arse. Obviously I could get my email with Gmail and the other Web apps were there. However it went further than that. I could download Tweetie and be instantly up and running where I left off (thanks to the fact that Twitter is just a Web service). I got to see which IM servers did a good job keeping my server based contacts, and what a pain it is when you make changes on the local client to tell you that flubber65 is Frank and suddenly you have no idea who anyone is without that (NOTE: if you build a service, for gods sake save everything up there!).

It even made me happy for Bespin, as I was able to get to a bunch of my code. That has incentivized me to help make Bespin great :)

So, I learned that Web based services won. I was productive on a random machine in minutes, and cursed the situations where this wasn't the case (mainly around development).

If the entire OS was Web based, with a rich cloud infrastructure, then I could literally login to any machine and be ready to roll. X Windows productivity will be back! :) This will greatly change the role of devices too. Seamless upgrades. Multiple devices sharing data. Fun times.

So, Web OS it is. Hopefully the Web platform will be complete enough, and where it isn't this kind of force behind it will push it even faster (this is why I am excited to see the space heat up, and also wanting to keep a watchful eye to see how things get standardized with crazy timelines behind them).

What do we lose?

But, wait a minute. We have seen that virtual machines are actually pretty awesome. Having an entire system in a single file that I can suspend, backup, and run multiple off? Cool. I am running multiple "Web OS's" every day (Firefox, Safari, Chrome). I can update them whenever I want, and they can compete.

We also see fantastic features where we can watch over all of the connections from the virtual machine to the host. Tweak how ethernet works, set limits on various usage, etc. Just as we are getting amazing things out of virtual machines.... maybe we don't need the Web platform to move from there just yet.

User-Agent

Chris Beard (Chief Innovation Officer at Mozilla) is often talking about what it means for the browser to be the "users agent". There is so much that the s/browser/virtual-web-machine/g can be doing for us, and we have only just begun.

We need to be wary of losing out on any of these thoughts if the Web becomes the OS on the computer (whatever that means, of course!).

As we think about Jetpack and granting enhanced functionality from Web apps to browser-chrome I am often thinking about a morphing browser. When I am on Gmail, I don't need the URL bar and all of that jazz. Instead, add new Gmail specific UI for me to use, and let me tie into the local system for contacts etc.

In that vein, it has been nice to see a step in that direction when listening to Alexander Limi speak about UX in Firefox last week. He and the UX team showed some concept mockups for future versions of Firefox such as this:

By the "home" tab you can imagine other tabs that are for applications. Thin tabs that just have an icon (e.g. an email notification icon showing new message counts). These "app tabs" can be slightly magical. The user has to bless them, and at that time can grant special powers to access local services such as a File API, or a Webcam, or Geo location, or [insert cool thing that native apps can do]. This feels like a small step for the browser, but one that can open up a lot.

In conclusion, I am bullish about the Web being called the 'OS' on certain computing devices. I am most excited about seeing this driving innovation into the Web platform as a whole, and also exploring the great side of having a platform run as a virtual machine on your hardware. Gotta love the Web :)

Ben gave a fantastic talk on creating compelling user experiences that discussed craftmanship in software.

He details the somewhat opposing views of Alan Cooper (pictured above) and Joel Spolsky talking about how IT people are screwed when it comes to quality. A depressing thought, and one that we need to combat in the trenches by just creating great software at work and proving that it is a winning strategy.

One piece of the talk I wanted to highlight was when Ben discussed UI latency. He has a simple feedback test page that lets you see how various delays make you feel. Give it a go and think about what feels sluggish and annoying. It differs between people, but 100ms feels like the "noticeable" level and 200+ feels sluggish. We should have a page that doesn't show numbers and is randomly setup, and then do a test. What do you think?

Also, to finish off, you owe it to yourself to spend a couple of minutes watching this awesome rant of Louis C.K. as he discusses how screwed up we are wrt expectations:

This is actually incredibly relevant to us as developers, as we run up against expectations in software too. Do you want to meet expectations? Or set new boundaries?

The PhoneGap team has been winning awards and developers like it.

However, we have just heard that some applications using PhoneGap have been targetted by the Apple review process:

Upon review of your application, cannot be posted to the
App Store due to the usage of private API. Usage of such non-public
API, as outlined in the iPhone SDK Agreement section 3.3.2 is
prohibited:

" An Application may not itself install or launch other executable
code by any means, including without limitation through use of a plug-
in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple's Published APIs
and built-in interpreter(s).

The PhoneGap API implemented in your application is an external
framework.

This is just wrong. They haven't targeted RegexKitLite or Google Toolbox for Mac, or Joe Hewitt's cool new framework. PhoneGap only uses official APIs, so it isn't doing anything wrong there.

You could assume that this is on purpose, to keep people in the Obj-C sandbox. Or, you could consider the fact that the review process is probably manned by a LOT of people who sit there with check lists. I am hoping that someone at Apple gets to see the outcry from developers and steps in to do the right thing, just like they did when Trent Reznor and many others complained about the hypocrisy of his iPhone app not getting in the store.

So, fix it Apple. Please.

Some people are offended by tone and such, but if you ignore that, Mark is actually normally spot on!

In this case, the font world feels like the DRM world of music. They can battle up hill all they want, but if they don't start working with their users (who are willing to pay for fonts, just like we are willing to pay for music!) they will find themselves in big trouble.

I was chatting with a GFX engineer on Firefox and after a fun time talking about how freaking fun it is to get fonts right cross platform (holy subtle-ties batman!) he pointed to a nice M+ font (multiple weights etc):

There are tons of great open source fonts out there. One day, instead of looking up to the foundries in their ivory towers in the sky, we will look down on the floor and see the gold is right there! And, then what? What will the foundries have after they push everyone to go the open source route?

Let's enjoy font squirrel and find some nice friendly fonts and use them to make the Web more fontific, and hope that the other chaps work out how to play nicely.

Ah, that time of year is here again. The day of the "Microsoft bought us" jape. Are there some good'uns this year?

The early chaps who jumped the line a touch were the smashing magazine people talking about IE 8.1, all with WebKit/Gecko integration, fast JavaScript, CSS 3 support, and more.

Then Opera does something actually quite cute with their Opera Face Gestures gag:

Looking ahead, we recognize the future importance of touch interfaces, but we believe that there is another input device that is already present in most new computers and it’s ready to enable a whole new way of user-interaction: the webcam.

Today we introduce Face Gestures, a revolutionary technology designed to make interacting with your browser easier and simpler on computers with cameras. Face Gestures lets you perform frequent browsing operations with natural and easy to make face gestures. By using an internal technology dubbed Face Observation Opera Language, we are able to recognize pre-determined facial expressions and match them to commands on the Opera browser.

What else do you see out there?

He talks about how some frameworks have code paths for specific browsers to shorten the if (foo) type overhead. Having a compile step like GWT does makes this easy. TIBCO GI "builds an optimized code tree for each major browser release (the opposite of the approach jQuery 1.3 and others have taken, as code only makes it into a build for that browser if that browser is known to support that functionality)."

excludeStart(”webkitMobile”)

Dylan then discusses what is happening in the Dojo community:

In recent discussions on the Dojo mailing list, discussions turned to how to make Dojo faster for mobile users. In most cases, this involves removing code and features that are not needed on that platform given the precious resources available on mobile devices and over mobile networks.

Alex Russell checked in some work he started last year that looks like this:

[javascript]
//>>excludeStart("webkitMobile", kwArgs.webkitMobile);
!dojo.isIE &&
//>>excludeEnd("webkitMobile");
[./javascript]

The syntax is a bit verbose, but it excludes the code between the start and end in a Dojo build created for webkitMobile:

./build.sh profile=base action=clean,release webkitMobile=true

While we would love to switch to pure feature detection over browser version detection like John has done with jQuery 1.3, version detection is generally more concise and precise, and does not necessarily make Dojo any less forwards compatible.

Version detection also makes it easy to exclude code created solely for browsers that require major workarounds, such as IE 6. To get the most out of this though would require doing something similar for each major browser, which would make Dojo more challenging to understand and maintain, would probably require a build step even during development (not just in production to improve performance).

At this point, there are no clear answers, just a lot of questions on how to create a toolkit that offers edge of the web features for desktop users, and still preserves performance for mobile web users. What approach do you think is best?