I've got a question closely related to this one. I'm cleaning up a colleague's mess, and I'm afraid that that means trying to work with a language -- JavaScript -- that I'm almost completely ignorant of.

Basically, we've got C code, with a bunch of enums defined in headers, passing data to JavaScript, which uses a bunch of magic numbers in place of those enum values. Any time the enums change, the JS breaks. I want to pull the values from the C header files into the JS, changing the magic numbers to symbols.

Our build process already has a small utility which processes all of the enums in specified C header files into C code consisting of lookup tables of strings, which code is then made part of the main app. This lets us use the literal strings corresponding to those enums in our XML data files... kludgy, but it gets us where we need to be. I think I could do something similar to generate JS code which defines constants having the values of those enums from the C header files.

My question: It would probably be much simpler, and easier to maintain, to simply process every enum in a *.h file than to try to narrow it down to only the ones we actually need for the JS stuff. My guess that if the JS has to include a bunch of constants that it never does anything with, there will be something of a performance hit. How bad is this likely to be? Is it worth the coding hassle to try to keep the resulting generated JS as lean as possible?


2 Answers 2


There are a few considerations to take into account.

  • Even unused constants will take up memory and processing time on the client's browser. How much of an issue this might be depends on how many of those unused constants you have and how many resources (memory and CPU power) your clients are expected to have.
  • Everything you send in JavaScript should be considered to be public knowledge. If you have enumerations that are meant to stay internal in the company, you better make sure that they don't end up in a JavaScript file.

If your code is already structured in such a way that the enumerations that are relevant for the JavaScript interface are located in header files by themselves with no (or few) unrelated enums, then I would recommend to go the same route you have done for the XML data files: Use a utility in your build process that takes a select number of header files (preferably specified on the command line or in a configuration file) and creates JavaScript files out of them with the enumeration contents.

  • I hadn't considered the privacy angle, thanks. But practically speaking, I think that ship sailed long ago. Many of the enums are visible in those XML files, for anyone who troubles to change settings and then see what the changes in the files are. To say nothing of anyone who runs 'strings' on the app itself -- in violation of our license, of course, but still. In retrospect, we might have considered running some kind of encryption on those XML files. But one of the design criteria was that they needed to be easy to read/understand by our support people.
    – BunsenH
    Commented Aug 2, 2019 at 17:53

I've come up with another solution that I think may work. For all of the .js files that we've currently got in a working directory (e.g. "script_dir"), we maintain the original code with meaningful symbols in a source directory (e.g. "script_dir_source"). The build process copies all of the .js files from the source directory to the working directory, then generates a 'sed' script from those C header files and runs it on the files in the working directory, converting all of the symbols into their numerical equivalents. There's no overhead at run time, and as a bonus, the files that the users see are obfuscated because they're just getting the magic numbers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.