Is doing the following in a javascript going to be too slow?

[deadseasquirrel]

I am trying to build a small page that will basically do the following task. It will have all 50 states on top, whenever I click on a state it will bring up all the "starbucks" (just for example) in that state, on a left-column navigation bar (about 1/4 of the page), and then on the right will be the address and some additional information of the "starbucks" that I chose.

Now I chose starbucks, because they have a lot of stores. So lets pretend I have as many stores, or maybe around 2/3 as many stores. All I want to store is the name, address, hours, and manager. But there will be about 1000+ stores. If I stored all that information on a javascript would that run relatively well, or very poor.

It is all just text after all. I am not sure if the script is loaded into the JVM, or how javascripts are handled.

If somebody has a better idea of how to store all this information and use it faster than my implementation, I'm all ears. But everything I do has to be client-side. The page I am designing is sitting on somebody's computer in an intranet. No web-server capabilities.

[Kor]

Split the information in several blocks (the necessary for a single state, for instance, in a block). Use an IFRAME to brig up an need one of the 50 pages (50 states) with the correspondent block information. Thus you will not load 1000 data inputs, but 1000/50 each time you open a state.

Load only what is necessary once a time.

[deadseasquirrel]

But can all the information ultimately sit in the javascript, in the actual .js file? Or should the actually data/content sit in another file, say an xml file (which I am not actually fond of messing with right now).

I am not so much worried about the implementation of the data, more so on how it is stored.

Because I don't really know how javascript is handled by the browser or the JVM (if that even comes into play), I am not sure if the script is cached, or if it is referenced everytime it is called or what. If it is cached then it won't be so bad. The first time you hit the page it might take a little longer, every other time it should be fast. If it is called every single time a function is used, and it scans the whole .js file then it might be a problem.

[Kor]

Yes, an external JS file is cached, so once loaded, next calling will be done locally.

You may also build 50 different external JS files also...

maybe the best ideea (if a huge amount of data) is to work with a server database and a server-side application which will generate the desired pages loading only the needed data at a time...

[Garadon]

since stores assumably don't come and go all that often it would be a waste of server power having it make the same return page over and over since the page nearly always will be the same.

I would suggest u make 50 files assuming u don't need to make cross searches on them;

I attached a framework as a little help.

[deadseasquirrel]

hmm, interesting. 50 javascripts. So you guys think that having 50 javascripts is better than having one big one loaded once in the cache? Because that way once it's loaded isn't it pretty fast? Or are you guys thinking that that one file will be so big and unweildy that it is better to have to load a fresh one every once in a while than to have to handle a gigantic one once.

Thanks for the sample code I'll check it out.