Atul Vasu, November 2011

Traditionally PSA rewriters were simple, and only modified urls in HTML or CSS etc, to provide new processed resources. But as rewriters get more complex, even simple filters like computing the load time, needs a non trivial amount of javascript to be served or embedded through PSA.

Pros:

• Provides better syntax highlighting, and works better with existing tools.
• Ensures JS readability within google3, and hence JS will be better readable.
• Can write js_test, and unit tests easily.
• Can compile JS at compile time.

Cons:

• Makes it an overkill for small scripts, but an exception can be made for those.

Pros:

• No need of a new data file while serving; this can be linked in PSA library
• Can be used either to serve directly as a path or as a embedded inlined script. (Even though if purpose is to inline, the original script must be "inline safe" escaped)

Cons:

• Makes C++ binary a bit bulkier
• This is done using a new tool, and not a well used mechanism.
• The line width must be restricted to 75 or so so that generated c++ file follows style guidelines.

file.js

doSomething = function() {
    callSomeOtherFunction();

}

file.cc

/** Copyright .. .
*/
// Author: ...
const char* kDosomethingJs =
    "doSomething = function() {\n"
     “    callSomeOtherFunction();\n”
    "}\n";

The string becomes correctly escaped, the variable declaration file header etc. are provides as flags to the converting code.