Valuable savings (a.k.a. String constants)

Has any one thought of this before ? I actually think this is a “good thing”.

Here I am talking about JavaScript as a stand alone programming language. Not about browser+JavaScript.

String constants. This is the feature, I would like to have (in the JavaScript language) :

Now imagine the space savings if You use this everywhere in your code ? Sizeable, but not dramatic.
And now imagine the savings if this is part of the ECMA 5?
Now, that just might be something we might call: “valuable savings” … The more we use it, the more we save.

Also.If this is part of the language (ECMA5) all of the string literals, lurking around JavaScript , should be made into an:

With the added benefit of them actually being constants. And yes, including this one too :

One non-trivial achievement for JavaScript. And a good thing for the wwww1. If this is made part of ECMA5, then everyone will be using this everywhere. Thus, the total size of HTTP traffic on the www will be measurably smaller. Is this just my speculation? I dare to think, not.

Update 2009 08 12

String literals are bad. Not having constants in a language is bad. Having string literals and no constants, is even worse. What are the constants for is well known. Imagine if Math.PI would not be a constant ? VBScript has contants2. String literals are always gouped in “one place” . Other platforms (.net, java) have resource files where string dictionaries are kept . Transforming “official” string literals into string constants, it the least we can do for the JavaScript. Especially these days when it tryes to grow-up with the help of ECMA comitee.

Update 2009 08 13

Jacke Archibald “made me” add this important clarification.
Before minimization there are no savings. After minimaztion, in the presence of global constants there are sizeable savings. String literlas can not be compressed, while a constant String.jacke // defined as: "Jacke Archibald" ; can be effectively compressed . This is also yet another convincing example on why string literals are bad.

Update 2009 08 14

I can present an workable solution for this straight away. I have found this interesting “compressor” here: It has an interesting (and unique?) feature of understandning #define commands. Example :

Is transformed into:

There are other commands like #if #else #endif etc . Of course #defines are hidden in /* */ comments. This compressor seems an ideal candidate to implement String constants support, before ECMA comitee does:

The rest of the code, now can use String constants for improved maintainability, changeability and less bugs.

After the transformation through the “compression”, the result is :

Above will work and will bring all the benefits of String properties (and other) as global constants. Until we have ECMA Script which has these constants built in.
After which event, we do the same compression technique, without our global constants. Looks a (bit too) complicated. For large javascript web applications this would be a very important feature to improve the code quality and app stability. With the help of the (ever important) code compression. Also, after global constants are part of the language, compressors can use the same technique, but transparently to the users.

1: “whole www” a.k.a. “wwww”
2: There are JavaScript “solutions” which are using VBScript to “implement” constants in IE+JScript.

11 Replies to “Valuable savings (a.k.a. String constants)”

  1. when you have to write String.empty rather than “”, to discover in whatever nested scope the String up to the global scope, and finally to use dynamic public properties rather than statically “compiled” strings, what exactly are you saving?

    1. Space?

      Less bugs?

      Also. This means introduction of (at last!) string constants into the language. Etc …

  2. Your proposed feature sounds like something a JS implementation could very easily do ‘in the background’ (probably some of them are already
    doing it for things like “string”, “number”), and not something you’d want to bother programmers with anyway (‘var name = String.empty’? Ewww.)


  3. Well that is the point exactly. If it is so obviously easy and usefull why not just have it in the language? Ohter languages are doing it too (C#: string.empty).

    String literals are bad.

    First thing with which I keep in suspense young colegues, is to ask them to write code where there is no string literals at all. In any prog. language. So yes, they are “bothered”. Especially after they realise what is good about not having string literals : Code becomes more manageable and maintainable. Which in turn elevates programers productivity.


  4. It could be that I’m missing something, but where’s the space saving using String.S instead of “string”, I count the same chars. In the case of String.T, that’s larger than “\t”.

    I’m not against string constants, but they’d need to be named differently. String.T doesn’t mean ‘\t’ to me, and why does String.T mean ‘\t’ while String.N doesn’t mean ‘\n’?

  5. @Jake
    Savings: before mini-mization|fication there are no savings. After it there are sizeable savings. String literlas can not be compressed, while String.jacke // defined as: “Jacke Archibald” ; can be compressed as any other var name. This is a good question, and I should have had it in original posting.
    Naming: lets leave it to ECMA comitee. Or not, they are known on not being able to agree easily between themselves ;o)


  6. There’s only a saving after minification if String.WHATEVER is aliased to a non-global variable. Once it’s aliased to a non-global variable, yes, a minifier will try to compress it down to a single char. So yeah, you’d save space if you did…

    But, you’d save even more space if you did

    Minifiers (as far as I’m aware) cannot compress property names, or global variables.

  7. @Jake

    You are completely right. But, I can think of more than one way to compress global language CONSTANTs.
    Which currently do exist in JS. But AFAIK no one bothers to compress their names ?
    On top of my head, my approach might be, perhaps something like this :

    (This works because unicode chars can be var names in JavaScript. Compressor would be inserting a unicode char in a source, not its ‘u presentation’)

    And then of curse there is always gzip-ing :
    Also there are other good sides to NOT having string literals spinkled arround a code ;)

    Thanks for your comments.

  8. That’s not going to work, someone can do window[“my” + “var” + “name”], and
    I’ve actually seen scripts that do things like that. All proper
    minifiers seem to just leave globals (and object property names) as

    I’m starting to doubt the utility of minifying in general. Just serve
    your scripts gzipped.

  9. (Ah, you were talking about constants, not globals. Still, how often do you expect these to repeat themselves? Humanity has challenges that are more interesting than getting a few bytes off a JavaScript file. Also, you’d make constant access slower.)

Comments are closed.