quasi-literal strawman

Andy Chu andy at chubot.org
Fri Dec 18 22:15:37 PST 2009

>> So then my question is why it needs to specify a desugaring.  Why is a
>> quasi-literal not a string?
> I still don't understand the question?
> Why `foo$bar` and not "foo$bar"?  Well, the latter doesn't do anything
> useful with the expression (bar).

OK, so to back up a bit, the point of quasi-literals is to shift the
burden of escaping from the application developer to the library
author (e.g. authors of the DOM API).  Is that an accurate and
reasonably complete summary?  (If it is I might suggest making "safe
string interpolation" the feature name)

My question is why the entire quasi-literal scheme can't be in a
library.  In your doc you have something like:

new StringInterpolation(["SELECT * FROM TABLE WHERE name='", name, "'
AND modified > ", new Date(d)])

Does this variation express all of what quasi-literals can do?

var sqlStatement = new StringInterpolation("SELECT * FROM TABLE WHERE
name=$name AND modified > $date", {name: name, date: new Date(d)})

sqlLibrary.execute(sqlStatement)  // does "autoescaping" of name and date

The syntax of the first string argument is the quasi-literal syntax in
your doc, with $, {}, etc.

Reasons why I ask:
- People could use this scheme *now* if it were a library, and start
changing their APIs to autoescape.
- Quasi-literals have a bit of a meta-problem.  You're lamenting the
complex escaping rules of HTML (rightly), but then this proposal adds
a third escaping mode to JS, which is probably the most
programmatically-generated language on the planet (since it must go
over the network).  Certainly I'm already confused by the discussions
of escaping quasi-literals on this thread.

> PHP and JSP were the gold standard when I built it, and Django and
> others have addressed that to some degree.
> Do you know of any statistics on how much PHP code is running versus
> Django code?

I don't know, but certainly tons more PHP code.  BTW Smarty also does
this and I think this is the most common PHP templating language now:
(I don't understand why a templating language needs a templating
language, but I'll never understand PHP I suppose)

I think the quasi-literals are a cool idea -- but they're also a
pretty large innovation.  This scheme is not used by "production"
library or language that I know of.  The point being that innovation
in standards has the problems that Douglas Crockford has spoken about.

This would shift the boundaries between JavaScript and the DOM, and
make them an anomaly among literally hundreds of other
libraries/languages.  Template languages are a well known commodity by

I would also say that the biggest boundary is actually getting people
to write auto-escaping.  It's not the lack of syntax in the JS
language.  I didn't study the end of your doc, but it certainly isn't
a simple problem for someone to write HTML autoescaping.  Considering
how much HTML is malformed out there, I don't see how there won't be
holes 0.1% or 0.01% of the time due to heuristics.  I would rather use
my templating language and the equivalent of auto-escaping via static
analysis to get it 100% right (since a static analysis tool can issue
warnings where there is ambiguity and a human applies their judgement,
to fix their code before it has to run).

JSON Template is trivially tokenizable for this reason: \{.*?\} (or
e.g. \[.*?\] depending on the delimiter) splits it into literals and
substitutions.  Then you can put the work into autoescaping rather
than parsing the template language (which always sucks because of

> What is locals()?  Why does expandTemplate need access to all locals
> to do its job instead of just the specified ones?
> Does this suffer from the "formatting string from untrusted source"
> problem that python suffers from, and the "substitution value from
> untrusted source" problem?

That was just a shorthand to get around the verbosity of passing in
{name: name, date: date}, and also specifying name and date in the
quasi-literal string.  It's not strictly necessary.

Not saying that quasi-literals won't work, but things to consider.
It's an ambitious solution and it would be cool if we can forget about
escaping as application developers, but I see more than a few

I think an existing library would help firm it up... I was thinking of
writing a mini-template.js that implements almost exactly what Python
3k string formatting does.  This is a hole in the feature set of
JavaScript, irrespective of security and escaping.  I think a default
.format() method on strings would go a long way, rather than the
current "foo " + var + " bar" idiom.  Perhaps there could be a hook
for autoescaping, but it may be tricky.


More information about the es-discuss mailing list