4 ms·

Nah, the idea of realtime communication between browser and server is as old as javascript. I implemented my first version in 1997, using hidden iframes loading

Nah, the idea of realtime communication between browser and server is as old as javascript. I implemented my first version in 1997, using hidden iframes loading scripts, but I don't imagine I was the first to do so. Relevant to the article, I actually also implemented a draggable map that loaded tiles dynamically on demand for a little failed outdoor startup in 1998. The limiting factor back then was actually the server. You just couldn't store enough tiles on the drives of the day, or generate them fast enough from gis with the machines available. The thing would work nicely, so long as there was only one person using it. ...which isn't really the sort of scale one would wish for in a web app.

sk5t 7y ago
> The limiting factor back then was actually the server. Do you still feel confident that the server was an unsolvable limit? Like, the expectations for map resolution were not all that lofty in 1997, and it's still today pretty common to precompute tiles at different ranges/scales.
- reaperducer 7y ago
  Sounds like a capacity issue. How many tiles can you store on a hard drive with a maximum capacity of about 6GB? Especially at 1997 prices.
  - sk5t 7y ago
    6GB doesn't sound untenable if one were to store map/graph data in some optimized text or vector form, rasterizing tiles as needed with a cache mixed in. Maybe keep the 20-mile tiles hot all the time... I guess this depends on the geography covered and use case though.
    - reaperducer 7y ago
      Still, think of the expense. Plus you need at least second for backup. And probably a whole bunch of them in production to handle many users. Think about the web in 1997, before "scalability" was even a word.
- jasonkester 7y ago
  Our tiles were essentially USGS topo maps, generated by GIS on the backend. This pre-dates even IE's first vector stuff, so the only way to deliver things like this was images (with transparent .gif overlays for things like our trails and markers). The only two options available were pre-computing and storing, or generating on the fly. Drives were nowhere near big enough to store enough precomputed tiles to be useful. Machines weren't cheap enough to buy the sort of computing power (on our budget) to generate on the fly, since a handful of users could peg a machine. We might have been able to write our own fast, stripped down, GIS renderer to get costs down a bit. Instead, we took the 90s option of burning through our VC as quickly as possible and hitting the ground hard. It was a fun time.

sk5t 7y ago

> The limiting factor back then was actually the server. Do you still feel confident that the server was an unsolvable limit? Like, the expectations for map resolution were not all that lofty in 1997, and it's still today pretty common to precompute tiles at different ranges/scales.

reaperducer 7y ago
Sounds like a capacity issue. How many tiles can you store on a hard drive with a maximum capacity of about 6GB? Especially at 1997 prices.
- sk5t 7y ago
  6GB doesn't sound untenable if one were to store map/graph data in some optimized text or vector form, rasterizing tiles as needed with a cache mixed in. Maybe keep the 20-mile tiles hot all the time... I guess this depends on the geography covered and use case though.
  - reaperducer 7y ago
    Still, think of the expense. Plus you need at least second for backup. And probably a whole bunch of them in production to handle many users. Think about the web in 1997, before "scalability" was even a word.
jasonkester 7y ago
Our tiles were essentially USGS topo maps, generated by GIS on the backend. This pre-dates even IE's first vector stuff, so the only way to deliver things like this was images (with transparent .gif overlays for things like our trails and markers). The only two options available were pre-computing and storing, or generating on the fly. Drives were nowhere near big enough to store enough precomputed tiles to be useful. Machines weren't cheap enough to buy the sort of computing power (on our budget) to generate on the fly, since a handful of users could peg a machine. We might have been able to write our own fast, stripped down, GIS renderer to get costs down a bit. Instead, we took the 90s option of burning through our VC as quickly as possible and hitting the ground hard. It was a fun time.