What is the "acceptable" upper limit for JavaScript array size?

Question

I left this question as generic as possible, but I do have a specific problem that I need to solve in my application and the answer to this would help.

The application I am working on uses PHP/MySQL as its backend, and is set up so that no text/words/phrases visible to the user are hardcoded in the HTML/JS that is output to the browser, rather they are stored in a database table associated with a language key that is used to fetch the correct translation of the word/phrase based on the user's language preference. Now this works great for text that exists inside the application's HTML, but in order for this system to work with the javascript files, all javascript must be placed in a .php file and wrapped in <script></script> tags and included inline with the HTML, CSS ect.

This creates some problems with the flexibility in the system's javascript, as it cannot be included as external scripts via <link> tags (I guess unless you set the .php file's headers manually), and perhaps more importantly it cannot be minified/packed etc. when served in the production environment.

My first thought of a solution to this problem is to have a php script that's placed before any other javascript which loops through every record in the language database table and creates an associative javascript array using the language key as the array keys and setting their value to the translated phrase according to the user's preference. So, in this way all javascript files could be made into actual .js files and link'ed, minified, packed, etc. as needed, and they would just reference the phrases they need from the master language array that was created (i.e. alert(LANGUAGE.some_text);)

Only problem is, the number of elements in this array could easily get into the thousands possibly even bigger. So back to my original question, what is an acceptable max size for a javascript array, based on the average PC? Or am I attacking this problem entirely wrong to begin with?

Answer 1

JavaScript is by its nature a scripting language. The interpreter is nestled inside the browser's kernel. Correct me if I'm wrong, but I don't believe there is a definitive upper limit. The only thing that constricts an unlimited upper bound are memory constraints.

You can house gigs of uncompressed data (more if you compress it).

You're more likely to get one of the top errors in the list here, before you'll see any "upper bound limit reached."

Answer 2

I tried solving a similar problem as a non-web programmer before, and ended up hosting the language package as a separate XML which JS queries into. Bad idea, and I'll tell you why. Google can't see pages filled dynamically with JS. But if that's no issue to you, I would recommend that way, simply because I don't know any other. :)

Answer 3

I think the problem has less to do with how much data javascript can theoretically handle and more to do with how your application is handling the data.

It sounds like you're returning all of the phrases for the user's language on every page, not just the phrases they need on that particular page. If that's the case, fixing it will be part of the solution to your problem.

The rest of the solution will be not using javascript for anything until the app is completely functional. Then go back and do progressive enhancement stuff with js.

Instead of generating javascript from those database queries, generate pages (server-side) in the user's natural language, and serve them from a separate subdomains/subdirectories. Have your web server load the appropriate config for the user's language based on subdomain/subdirectory.

It's not the answer you were looking for, but I hope it helps.

Answer 4

The method Array.prototype.push , append arguments to the end of the array, and return the new length.

In some JavaScript engine such as v8, the length is bounded to 32bit unsigned integer, so this might be the limit you want to know.

Answer 5

in order for this system to work with the javascript files, all javascript must be placed in a .php file and wrapped in tags and included inline with the HTML, CSS ect.

This creates some problems with the flexibility in the system's javascript, as it cannot be included as external scripts via tags

Actually, not necessarily true. You can serve javascript files (not html) using PHP. Of course doing this most likely mean that all your javascript file will have the extension .php but that is a small matter. If you don't care about being strictly correct you don't even have to set the Content-type to js since browsers will treat anything served by <script> tags as javascript anyway.

A lot of sites actually do this, though not necessarily in PHP. Google, Yahoo etc often serve javascript using a server side scripting language to enable them to do any or all of the following:

• automatically concatenate javascript/css files into a single file
• automatically minify the javascript/css files
• automatically obfuscate the javascript files
• automatically do dependency resolution to source needed javascript files

Some people use mod_rewrite to rename the .php (or .pl or .cgi) files to .js to hide the details of the implementation. But it's strictly not necessary.

Here's an example bookmarklet that I serve as a .php file.