JSON vs. Flash for Distributed Mapping

A few years ago I wrote a “Flash connector” for the ArcIMS HTML Viewer.  This “connector” took advantage of Flash’s security sandbox model, which allows cross-domain data connections under special, protected circumstances.  The point was to allow ArcIMS to get around JavaScript’s “same-domain policy” limitation — to allow distributed web-map calls without a proxy. 

Really the point was to put an ArcIMS HTML viewer on my HTML-only web-resume host, but I digress.

 In the browser, ArcIMS’s JavaScript and Flash communicated via Flash’s “External Interface” methods.  ArcIMS could post ArcXML to and from other domains.  Flash’s security model requires a “crossdomain.xml” be published on the remote-domain.  Jan Bliki’s excellent Flash + ArcIMS work at the EEA offered both the ArcIMS backend and “crossdomain.xml” to test all of this against.

The whole point, again, was to get around JavaScript’s ”same-domain policy” limitation.  Fast forward to 2007 where JSON is commonplace.  One accepted JSON paradigm is On-Demand Javascript – a special case where JSON-encoded data may be accessed across domain boundaries.  Essentially, an HTML <script> tag may be dynamically generated in the DOM, thus loading the JSON data.  There is some debate whether this is a feature, or a bug. 

For a moment, I considered rewriting my “Flash connector” as a “JSON connector”.  However, the lack of domain restrictions on DOM-based JSON requests does not apply to XmlHttpRequest JSON requests.  This means that JSON data may only be loaded via an HTTP “GET”; you can “POST” information to remote domains.  Hence, Javascript still cannot POST data to remote domains.

Overall?  If you’re not interested in proxying, 2-3 year old Flash technology is still better than JavaScript.  Why?  The security model.  Microsoft has been hinting at giving Silverlight a permissive cross-domain policy.  I suggest they do so.

Let me know in the comments if there is any interest in me posting a “Flash-connector” walk-through.

Silverlight first impressions

Being a .NET GIS programmer, a former Flash developer, and an bit of a JavaScript hacker, I’m a natural to be interested in Silverlight.  I remember in 2003 when Microsoft first announced Sparkle (now Silverlight) in the frame of a Flash-killer.  In the mean-time, AJAX seems to have stolen the show.  Silverlight clearly represents a shot over Flash’s bow, but I have to wonder “how does Silverlight compete against AJAX?”

There is really little to say about rendering performance.  Early tests seem to show that WPF/e XAML rendering speed is comperable to Flash and DHTML.  Pretty good performance for a beta product.  Overall, WPF/e should work great for displaying small GIS vector feature datasets.  WPF/e is nicely integrated, and its straightforward how to programmatically create layout.

The part of Silverlight that interests me the most is its support for a subset of .NET.  Microsoft has a demo showing .NET for Silverlight running up to 1000x faster than Javascript, effectively 10-15x faster than Flash’s Actionscript.  Sweet.  In an odd coup, the DLR will allow you to write your Silverlight .NET code in Javascript, facilitating high-performance AJAX ports.  Beyond that, a quick look at the HTML bridge quickstarts shows that we need not rely on WPF/e XAML – Silverlight can bind to the HTML DOM quite handily.   Again, score for Silverlight. 

Here is where my opinion really starts to diverge.  I can’t find Silverlight’s supposed “serialization classes for handling data.” I haven’t seen them in the remoting quickstarts or a quick API examination.  Yes, there’s support for plain XML, REST, and SOAP… but I can’t find any automatic object/class-level serialization.  Until I see object serialization between ASP.NET and Silverlight, its not the JSON-killer I hoped for.

In fact, despite the high-technology, its hard to see what Microsoft has done here.  Certainly they’ve given their C# programmers a skyhook into browser-based development.  They’ve upped the computing-performance ante for browser capabilities.  That a pretty big deal.  However, Silverlight still comes off as direct competition against Flash, not a competitor to AJAX.  So why push out a zero-installation-base plugin when you own the browser marketshare?  Had IE7 matched Mozilla’s support for SVG/Canvas, E4X, and Javascript getters/setters — this would have given us 80% of the functionality of Silverlight’s limited APIs.  Perhaps because they’ve been planning this since 2003. 

 UPDATE:

As pointed out in the comments, Silverlight is based on AJAX in a very non-disruptive way.  The afforementioned support for SOAP is really support for ASP.NET AJAX JSON-enabled web services.  Beyond that, this is all documented exactly where I said it wasn’t … http://silverlight.net/QuickStarts/Remote/UsingJSON.aspx.  …And I wasn’t even trying to troll.

ESRI and Silverlight

ESRI is hiring for a “.NET software development programmer” to “build core business logic for our Web-based GIS applications” with “Background in graphics programming and WPF” and “Familiarity with .NET 3.0″.  They want someone with “Experience with ASP.NET AJAX” but who can “master new technology quickly” in a “changing environment.”

 Can anyone say Silverlight?