There has been an interesting discussion going over on James Fee’s blog on the merits of ESRI’s new javascript API and Flex API. James has thrown his lot in with the JavaScript API, and a host of Flex/Flash developers have been exposing their technology’s merits. While we don’t use either of ESRI’s APIs internally we did have to make a choice between Flash and JavaScript/HTML when we were developing Maker. At the end of the day we ended up blending the two approaches – implementing JavaScript where it made sense and utilizing Flash when we needed powerful vector rendering capabilities.
One of the most useful references for me in this process was a workshop Tom Carden gave at ETech last year on the data rendering capabilities of a variety of approaches. The readers digest version of the workshop went something along these lines:
HTML/Javascript – handles 100-1000 data points – loads in .1 seconds
Flash – handles up to 10,000 data points – loads in 1 second
Java/Processing – handles up to 100,000 points – loads in 10 seconds
OpenGL – handles upwards of 1,000,000 points – loads in 100 seconds
For Maker we wanted to be able to handle 10,000+ points/polygons and there was no way JavaScript was going to be able to handle it. Of course rendering the data was just one of many problems. Not only did we have to render the data but also parse it from the server out to the client while running the mathematical operation enabling you to take advantage of the structured data being sent. The team came with lots of clever tricks to pull it off, but the level of performance afforded by using Flash for rendering the vector data was not available with JavaScript. Processing could be a very cool option as the technology matures. Silverlight could also be a great option if they can get the plug-in universally embedded into browsers as with Flash.
While Flash was a great option for the tiling and vector rendering we did not want to build out the entire application in Flash for a variety of reasons. In GeoCommons everything outside of the map itself is JavaScript/HTML. This is probably rudimentary for many folks, but reading the debate on James’ blog I think sometimes developers lose sight of picking the best tool for the job. Oftentimes it is easy to get wedded to an approach just because it is what you know well. We were complete Flash rookies when we started, but got some great help from Tom with Modest Maps, Axis Maps with the Flash development and cartography, hired some full time resources, and learned a lot on our own. It ended up being a great approach for the specific problems we were facing. As long as you are using standard interfaces in your development, you should be able to fluidly adapt to the technology that makes the most sense for your set of problems.
5 Responses to Flash vs. Javascript for Web Mapping Applications: Our Experience with Maker!
Leave a Reply
New GeoCommons Maps- Mapping Democratic Participation: Money & Recalls geographer
- Petition Circulators in SD13 geographer
- MILITARY_INSTALLATIONS_RANGES_TRAINING_AREAS_PT sparker
- test 2 sam.felipe
- Colorado snow totals Feb 3, 2012 kevingraves
- Colorado snow totals Feb 3, 2012 kevingraves
- New GeoCommons Datasets
- REGMGR.VOTING_PREC_092011 REQUIRED: The person responsible for the metadata information.
- Snowfall reports for Denver's February snowstorm, Feb. 2-4, 2012
- Area C Samples
- Merge of 'Large/Medium U.S. Military Bases, 2009' into 'MILITARY_INSTALLATIONS_RANGES_TRAINING_AREAS_PT'
- Merge of 'Large/Medium U.S. Military Bases, 2009' into 'MILITARY_INSTALLATIONS_RANGES_TRAINING_AREAS_PT'
- snow_totals_0730
Oh dear – I knew those numbers would come back to haunt me! They are made up, but I stand by them as a rule of thumb. I will note here that out of all of the available web-based technologies, javascript’s capabilities are accelerating fastest.
FWIW the main reason I continue to use Flash is because that way I don’t have to think about cross-browser/cross-platform issues at all, and the tools (Flex Builder in my case) really are better (Firebug is awesome, but profiling and debugging in Eclipse is easier). The cross-browser/cross-platform issue is really apparent when you start thinking about interactive vector graphics which are clearly essential to Maker.
In my obviously biased opinion I think you made the right choice, although at some point the data gets too big (like map data itself) and you end up moving to tile-based approaches where javascript really shines right now.
The funny thing is I usually loose all my scribbled notes from a conference, but some how kept those numbers. I think we got slightly better numbers than that with Flash if you do not count the parsing of the data to the client, but just details at this point.
We had some real cross browser problems on the first version of GeoCommons where we were using a javascript API for the heat mapping. IE would not handle the alpha transparency for the PNGs and the work around was clunky. Not sure what my point is all this other than generally agreeing with you.
Do you think JavaScript will at some point surpass Flash when it comes to data rendering?
Not sure. The underlying scripting tech behind Flash’s actionscript 3 is open source and moving into Firefox, resulting in great speed increases. It also results in increased competition for Webkit too, so they’ve also made great speed improvements this year. And Chrome is another story. All this makes the raw computation speed of javascript much closer to Flash, but Flash still wins for vector graphics and I don’t see canvas or SVG touching it soon (although if it’s in IE8 I may change my story…)
The idea of Canvas and SVG stuff is always appealing, not least because in theory it still works on the iphone, android, mobile opera, etc. and also because of native parsing of JSON
But IE support for canvas is essential and it’s not there yet without third-party plug-ins or slow emulation in VML or (ha!) Flash.
Also, the new version of Flash has some excellent support for graphics style objects, a new text engine, faster (and completely custom) bitmap filters, type-safe arrays, and more. All these things are going to be useful for maps and are going to be faster and better supported than Flash than browsers for a while yet.
In terms of interactive graphics features and performance I’d say the browser is 2 years behind Flash, at most – and given the different constraints on the platforms, that’s nothing to be ashamed of. But in terms of computation speed I’d say there’s not much in it now at all.
Thanks for the perspective – still trying to catch up on the details of where Flash is going. Interesting about the text engine. We are doing some Metacarta integration for a customer and could be quiet handy. We’ve been looking at some interesting blends of JavaScript and Flash for our next release even within the Flash app. Hopefully should work out. We did Finder Express in Maker with JavaScript and should be able to refine that approach for other pieces as well.
look http://www.cromaps.com flash searchable city maps