Dynamic Flash

I’ve been meaning to sit down and this article on SproutCore ever since it shot to fame as the underlying client-side framework used to build Apple’s recently released MobileMe web application. You see, SproutCore seems to have had a falling out with web standards and web development best practices, something that wasn’t getting picked up in all the mainstream coverage it was receiving.

For the uninitiated, SproutCore is a JavaScript framework developed by SproutIt. It was initially developed to enable them to build their Mailroom application, which according to their website is a hosted help desk service for consumer-oriented businesses . So far, so good. The description given on the SproutCore website makes it sound like the framework is similar to other JavaScript libraries like YUI and JQuery, only a little more focussed on the application as a whole:

SproutCore is a framework for building applications in JavaScript with remarkably little amounts of code. It can help you build full “thick” client applications in the web browser that can create and modify data, often completely independent of your web server, communicating with your server via Ajax only when they need to save or load data.

What the above paragraph only hints at, though, is that SproutCore doesn’t just ignore progressive enhancement — it hacks it into tiny little pieces, urinates all over them and then mails them back to you one by one:

After lots of testing, we have found that the most efficient way to server a SproutCore application is as a … static web page! Once a SproutCore application is loaded into your web browser, it communicates with your backend server using Ajax.

Can you guess what an application looks like with JavaScript disabled? If you said “a blank page”, you can give yourself half a gold star. The unfortunate truth is that what you get is even worse than a blank page - you get a page devoid of any content but with UI controls that do absolutely bugger all. Don’t just take my word for it; check out the check out the SproutCore Photos example and then turn JavaScript off and hit refresh.

I thought we’d moved past this whole progressive enhancement issue back when Jeremy Keith was banging on about it to anyone who stood still for long enough. Alas, it seems there are still some poor unfortunately souls who have yet to benefit from Jeremy’s wisdom.

The total disregard for progressive enhancement is not the only thing wrong with SproutCore. Almost every UI widget and container in the framework is represented by nested <div> elements, differentiated only by their combination of class names. Where semantic elements are used they are used incorrectly (i.e. using <label> for headings). There is no sign of tab-enabling them or WAI-ARIA support, and all of this means that SproutCore applications are likely to be totally inaccessible out of the box.

OK, so SproutCore is bad, but what does all this have to do with Flash? That’s a fair question, given that the main focus of this blog has been Flash / Flex / AIR for the past 3 years. The answer is that the About SproutCore page takes a fundamentally misinformed swipe at Flash, and I’m calling them on it:

Why should I use SproutCore instead of a plugin like Flash or Silverlight?

Nobody likes using software running in a sandbox and no one likes to download plugins before they can use your software. If you want to create an application on the web that is fast, fluid, and native, and usable by everyone, use the only technologies that come built right into every browser: HTML and JavaScript. SproutCore makes it easy to do just that.

It seems that the SproutCore developers may have forgotten that JavaScript also runs in a sandbox, and it’s a great deal more restrictive than the Flash Player. Just try making a cross domain request using JavaScript, or setting up a permanent connection to a socket server, or (as is available in Flash Player 10) run-time access to local files.

They also seem to have missed the fact that the percentage of users unable to see Flash content is significantly lower than those fumbling around the Internet without JavaScript disabled. According to Adobe’s statistics content published for Flash Player 9 is viewable by an average of 97.4% of web users across all markets. That compares very favourably with the 95% of users who have JavaScript enabled according to w3schools.

Oh, and there’s nothing special about SproutCore’s fast, fluid and native controls - they are no more or less fast, fluid or native than Flash or Flex components. You can make either one look like native operating system controls but that doesn’t mean you should, and speed of execution and layout is down the to the implementation. On the speed front, it’s interesting to note that Mozilla are busy integrating Tamarin (the ActionScript virtual machine built into the Flash Player) into Firefox in order to support ECMAScript Edition 4 and speed up JavaScript execution.

The worst thing about all this for me is that this is the framework that Apple have chosen as the foundation of their MobileMe web application. There are lots and lots of bad frameworks on the Internet, but to see one used in such a prominent application by a company normally very meticulous about application design and user experience is disappointing.

I hope that the SproutCore developers read this article and take on board at least some of the points above. There’s nothing in the framework that cannot be fixed, though fixing the whole progressive enhancement issue is going to require a shifting of the framework’s focus away from 100% client-side application logic.

Whilst reading Simon Willison’s latest post about how he’s sticking with Opera 9 as his main browser, I discovered something about Opera that I didn’t know before: it modifies the DOM and/or JavaScript of certain websites to make them compatible with the Opera browser. Opera calls this feature Browser JavaScript:

Browser JavaScript is a feature that allows Opera to automatically fix incompatible Web pages, out of date scripts, and pages that inadvertently block Opera.

The affected sites include some big names, including barnesandnoble.com, blogger.com and yahoo.com. The fixes range from small design tweaks to disabling browser sniffing code. In addition, a number of standard DHTML menu libraries are patched, regardless of the site they appear on.

Apparently this feature was included in Opera 8.01 but was turned off by default. It was enabled by default when Opera went ad-free, which was almost a year ago now. Given how long it’s been around, I’m surprised I haven’t heard of this feature before. Then again, I only use Opera for compatibility testing.

Some will day that this is no worse than Firefox adding undetectable support for document.all in order to support IE-only JavaScript. However, that was a passive fix that allowed non-standard code to go about its business; Browser JavaScript actively modifies the DOM and/or JavaScript of a site to make it work in Opera.

I’m not at all comfortable with Opera ‘fixing’ these sites in this way, even if they are doing so with the best of intentions. Who’s to say that the fixes created by the Opera engineers won’t break something else on another part of the site? And what happens when the site in question is updated? Are they going to test every area of every site regularly to check their fixes? Maybe, but probably not. You can be sure that the majority of users who complain about a broken site in Opera will do so directly to the site owner and not to Opera.

Incidentally, on the subject of good intentions, the quote from Opera above says that they’re fixing incompatible websites, not non-standards compliant websites. Does this mean that this is Opera’s solution to properly implementing CSS standards? I hope not.

The one saving grace here for us poor developers is that whenever a site is modified by the Browser JavaScript feature a message is posted to the JavaScript console. Still, if we find that Opera is causing a problem we have to email Opera and wait for them to fix it, which is less than ideal.

If you think Opera is modifying your page incorrectly or unnecessarily, or if you have removed the cause of the problems, please mail web-compliance@opera.com.

I can’t believe I’m the only one who’s concerned about this, but a quick google only turned up tutorials of how to write JavaScript for the Opera browser. Typical! I’d be interesting in others thoughts on this issue.

Somewhat in preparation for my joining Yahoo! later this month, I have been familiarising myself with the YUI Library, using it to build a small internal application that we need at Featurecreep.

One of the things this application needs to do is communicate with our SiteServer application using its XML API. Inevitably there were some issues, and having quickly tired of clicking my way though numerous alert() windows, I thought I'd take the YUI Logger component for a spin.

Unfortunately, no sooner had I integrated this into my mini application (a simple matter of including a few external JS files and adding 2 lines of code) than I hit a show-stopper of a problem: the YUI logger didn't attempt to escape any of the big 5 entities (<, >, &, " and ') before using innerHTML to inject the message into the logger entry list. This meant that Firefox treated my XML data as HTML elements it couldn't understand and silently skipped them, rendering my XML data unreadable. Bummer.

Never one to be defeated, I rolled up my sleeves and got stuck into the logger.js file. I needed to catch the message and replace the entities as the HTML string that will be injected into the document is being built. This is being done on lines 2024 to 2034 (or 1012 to 1017 if your line breaks aren't messed up like mine are):

Now, it's only actually necessary to encode two of the big 5 entities for the browser to show us the proper information, so all we have to do is change the last line of that statement to read:

A small change, but all of a sudden I can log messages that contain HTML or XML code, or any message that contains the encoded characters. Hopefully this'll get incorporated into the main YUI Library, but in the meantime feel free to download my modified logger.js files (logger.js, logger-min.js and logger-debug.js).