going to cut this one fairly short, as I think we're hitting the end of the discussion: > Using a browser-only solution? First, I'd ensure that navigation butt

going to cut this one fairly short, as I think we're hitting the end of the discussion: > Using a browser-only solution? First, I'd ensure that navigation buttons (forms) are available which could load a new page if the browser doesn't support features. Then, I'd augment HTML. which doesn't give the user a very compelling solution, it gives them a static map; which definitely has its uses, but feature-wise isn't something that people would really like to use: we're a long way from Mapquest, and it's not a paradigm that users are interested in at this point, which is why browsers have expanded functionality to include javascript, and css. > Have you measured it? yes: each tile is 25k at low resolution, 100k at retina, times 15 (for zoom levels), 20 tiles for your average web view of a map. that's 2mb per zoom level. adding a single layer of information to that would add 2mb per zoom level. take the 3 possible options that I mentioned and you're at 6mb. add the ability to pan for a small city, and you're looking at ~2000 tiles, or 200mb (or 600mb to account for each option). add another layer, such as population density, and you're doubling it per layer added. add the ability to change the opacity between layers, and you're adding up to 255 time more data. that's significant, as we've now reached 153gb without adding an additional layer to give me something to look at while keeping that functionality. now store that, for each person just in case they come back or render it real-time. >Also isn't 150mb considered a very large amount of data? Not everyone has awesome internet connections. I'm on a 1.5mbit connection with 700ms of latency on a sunny day, 150mb of data for that type of application is much preferred to rendered images being delivered to me. > If your server can't perform with basic image manipulation (take image, overlay a color, return result) then your server software and/or hardware needs some better developer/hardware resources assigned. at scale. we altered map tiles real-time no problem, but it still made sense to cache them instead of eating up the cpu time for each request (in that use-case, all users got the same modification, but if we were to render all changes to the map on the fly, instead of minor changes in the browser, it would not have made sense). > Third: become a VNC server, start a session, and render it in the client using the same technique described above. Speaking from experience, if VNC is less resource intensive and faster then something is going wrong in the development pipeline. and then it becomes inaccessible to the majority of users. same with requiring the user to download an application to view what should really be a web page (could you imagine having an app for every web page you want to visit? that would just be silly). I'm sure we can dive down further, but I'm not sure it's worth it - there are several problems that having javascript and a browser solve, you're welcome to attempt them without leveraging either javascript or the browser, but I'll happily continue to use web pages that are delightful to use, and leverage as many technologies as possible. I remember bbs's, and text-based interactive telnet sessions, as well as curses, and I think I prefer the modern web. (quickly editing to add a comment about using css and html and just "render it that way" - which is what is occurring, but the amount of data available [yes, it's all public data] to give a compelling data-driven experience to the user still needs to be dealt with - that's where web workers come in, putting those images layered on top of the tiles, across 500,000 buildings takes time to process whether you're using javascript or some as-yet-to-be-invented way to composite those images in the browser: it takes time and it is better to render them in the background in another thread than it is to lock the browser for 20-45 seconds while it renders - this is progressive enhancement)