Is Eval Evil for Ajax Responses

[Larry]

Hi there:

I have seen numerous postings about eval() and its evils on this forum.
However, one of our developers is using it in the following way,
which seems like a great use of it.

Page makes Ajax request to ASP.Net web service. Web service does some
data lookup and builds a string representation of a Javascript array
which is then returned to the client. In the ajax callback, call to
eval on the returned string and voila, instant populated data
structure.

Another way to do this would be to pass back xml and walk the xml dom
in the callback, populating an array as you go.

Either way you have to do roughly the same amount of work on the server
(perhaps slightly less with no xml).

I am not worried about the compilation of the eval'd string. Our tests
have been lightning fast. Is the biggest danger in this case x-browser
issues?

Thanks,

Larry

 

[Jim Ley]

I am not worried about the compilation of the eval'd string. Our tests
have been lightning fast. Is the biggest danger in this case x-browser
issues?

No, this is a perfectly fine reason to use eval.

personally I use

new Function("return "+str)();

but either way it's a sensible approach, much more sensible than an
XML document.

One other alternative is iframe's and regular script elements rather
than xmlhttp methods.

Jim,

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Wed, 16
Nov 2005 15:54:51, seen in Jim Ley

No, this is a perfectly fine reason to use eval.

personally I use

new Function("return "+str)();

but either way it's a sensible approach, much more sensible than an
XML document.

Is yours worth adding to the newsgroup FAQ section?

Presumably it can be misused in the same way as native eval.

It does have the disadvantages of being less obvious to a reader of the
code, and longer; how about
function EVAL(str) { return new Function("return "+str)() }


To the OP : FAQ 4.40 indicates your usage as being sound.

 

[RobG]

Hi there:

I have seen numerous postings about eval() and its evils on this forum.
However, one of our developers is using it in the following way,
which seems like a great use of it.

Page makes Ajax request to ASP.Net web service. Web service does some
data lookup and builds a string representation of a Javascript array
which is then returned to the client. In the ajax callback, call to
eval on the returned string and voila, instant populated data
structure.

Another way to do this would be to pass back xml and walk the xml dom
in the callback, populating an array as you go.

Either way you have to do roughly the same amount of work on the server
(perhaps slightly less with no xml).

I am not worried about the compilation of the eval'd string. Our tests
have been lightning fast. Is the biggest danger in this case x-browser
issues?

Sounds a lot like JSON:

<URL:http://www.crockford.com/JSON/index.html>

 

[VK]

Hi there:

I have seen numerous postings about eval() and its evils on this forum.
However, one of our developers is using it in the following way,
which seems like a great use of it.

Page makes Ajax request to ASP.Net web service. Web service does some
data lookup and builds a string representation of a Javascript array
which is then returned to the client. In the ajax callback, call to
eval on the returned string and voila, instant populated data
structure.

This is a perfect use of eval() and yes, it is very fast. The whole
idea of JSON (which is what you're actually doing) is based on eval()
and on its speed *equal* to the regular code parsing between
<script></script> tags.

I'm finding <http://www.jibbering.com/faq/#FAQ4_40> as well as "Eval is
Evil" slogan more as polemic exclamations of some historical buttle we
are not aware of. IMHO at the very least JSON should be mentioned in
4.40 as a sample of a legal use of eval(). ?

A real misuse of eval() I may think of is in retrieving object
references like:
var ref = eval("document."+formName); // etc.
Not because it will not work ar will be slower - but just because it's
programmatically ugly and unnecessary.

 

[aundro]

A real misuse of eval() I may think of is in retrieving object
references like:
var ref = eval("document."+formName); // etc.
Not because it will not work ar will be slower - but just because it's
programmatically ugly and unnecessary.

I personally tend to think of the whole "Eval is Evil" thing as a
contamination from the Lisp languages. (not that I find lisp
contaminating in a bad way, it would be the absolute opposite: I
always code in Common Lisp (CL) as much as I can; it's my language of
choice!)

The use of eval in CL is often regarded as bad practice because you
rarely have to eval *yourself* some code.
On the other hand, there are very handy functions, like 'load' that
loads a (compiled) file (evaluating all it contains),
or 'read-from-string' to which you pass a string and whose primary
return value is.. an object!

The latter is not really the same as eval, as it expects a 'readable'
representation of an object, and does not evaluate it's argument
(that is: (read-from-string "(print \"Hello there\")" will _not_ print
"Hello there", but rather return a list containing the symbol 'print,
and the string "Hello there").
Still, even though 'read-from-string' does not evaluate it's argument,
a parallel can be established between:

(read-from-string "#(1 2 3)") ==> an array containing 1, 2 and 3
eval("[1 2 3]") ==> an array containing 1, 2 and 3

See my point?
In many cases, it seems we are using eval in JS just as we would be
using read-from-string in CL, so I don't think Eval really is that
Evil.

Arnaud

 

[aundro]

eval("[1 2 3]") ==> an array containing 1, 2 and 3

eval("[1, 2, 3]")

of course

Arnaud

 

[Evertjan.]

aundro wrote on 17 nov 2005 in comp.lang.javascript:

(read-from-string "#(1 2 3)") ==> an array containing 1, 2 and 3
eval("[1 2 3]") ==> an array containing 1, 2 and 3

See my point?
In many cases, it seems we are using eval in JS just as we would be
using read-from-string in CL, so I don't think Eval really is that
Evil.

a = eval('[1 2 3]')
that is not JS.

If you want to transform such string, what's wrong with:
a = '1 2 3'.split(' ')

Yes, eval is certainly evil.

 

[Evertjan.]

aundro wrote on 17 nov 2005 in comp.lang.javascript:

eval("[1 2 3]") ==> an array containing 1, 2 and 3

eval("[1, 2, 3]")

of course

a = eval("[1, 2, 3]")
??

Still, the below way is simpler,
not using an extra instance of the JS-engine.
This especially important in a long loop.

a = '1,2,3'.split(',')

 

[aundro]

aundro wrote on 17 nov 2005 in comp.lang.javascript:
a = eval('[1 2 3]')
that is not JS.

Yes, sorry bout that

If you want to transform such string, what's wrong with:
a = '1 2 3'.split(' ')

That is in case you absolutely know the objects you expect, and their
format, for a particular request.

What if you want one single 'request point' (that is: a function that
performs the XmlHTTPRequest, for example) that you can call for many
purposes?
For example: the first time, you'd like to fetch an array of
numbers (that's the example above); the second time, invoked from some
other code, you'd like to fetch Objects that represent some
server-side resource...
You could of course return the 'responteText' from that 'request
point', and do the parsing back in the caller's code, but I don't find
that particularly elegant either..
Of course, you still have the 'Function ("return" + str)()' solution.

Yes, eval is certainly evil.

Do you (or others) have real examples why eval is absolute evil?

Arnaud

 

[VK]

a = eval('[1 2 3]')
that is not JS.

Well, evidently it meant to be:
a = eval('[1,2,3]')
in which case it's a perfectly valid JS code. Programming languages
like human ones: if you have to use several of them at once you can
occasionally mix words and grammar

The code by itself is meaningless though. A direct:
a = [1 2 3]
is of course better.

But we are talking in the context of OP's question related with the
object serialization and how could it be implemented in JavaScript. And
for the object serialization eval() / new Function() is often the only
way.

In reference to this question one can look at:
<http://www.crockford.com/JSON/index.html>
and specially at:
<http://www.crockford.com/JSON/js.html>

P.S. It is very interesting btw that in order to implement his concept,
the author had to accept eval() method and to admit existence of
hashtable and array as two separate programming entities. A perfect
proof that you can *believe* in whatever you want - but in order to
*do* something material you have to accept the materal nature of the
things you are dealing with.

 

[Thomas 'PointedEars' Lahn]

A real misuse of eval() I may think of is in retrieving object
references like:
var ref = eval("document."+formName); // etc.
Not because it will not work ar will be slower - but just because it's
programmatically ugly and unnecessary.

I personally tend to think of the whole "Eval is Evil" thing as a
contamination from the Lisp languages. [...]

An eval-like construct is available in many programming languages,
so I doubt that argument is valid. While LISP (1959) may be one
of the first programming languages, those languages did not all
follow the LISP approach.

It is generally bad practice to have source code evaluated through
a subprocess if the same result can be obtained in other ways. This
regards code quality in general (see "debugging") and especially
code security (see "code injection").


PointedEars

 

[VK]

It is generally bad practice to have source code evaluated through
a subprocess if the same result can be obtained in other ways. This
regards code quality in general (see "debugging") and especially
code security (see "code injection").

OP posting is called: "Is Eval Evil for Ajax Responses" (not "Is Eval
Evil In My Code").

Could we stay a bit closer to the topic?

<http://www.jibbering.com/faq/#FAQ2_3>

 

[Evertjan.]

aundro wrote on 17 nov 2005 in comp.lang.javascript:

Do you (or others) have real examples why eval is absolute evil?

Please do not change my words, I did not say "absolute".

The evil is in the extra calling of an instance of the JS engine.
In a loop, this can be prohibitive.

The evil is in the use, where it is not necessary.
[and in this forum, giving a bad example to the newbies]


s = "[1, 2, 3]"
a = eval(s)

this use is accepable to me, but for the notion that defining an array from
a string with [] is really the way to do.

and even then a regex could do the same:

s = "[1, 2, 3]"
a = s.replace(/[\[\] ]/g,'').split(',')

longer in code, but no engine trouble.

 

[Thomas 'PointedEars' Lahn]

OP posting is called: "Is Eval Evil for Ajax Responses" (not "Is Eval
Evil In My Code").

And I did not refer to the OP's posting but to aundro's statement.

Could we stay a bit closer to the topic?

This is a discussion medium, not a support forum. When will you get that?

<http://www.jibbering.com/faq/#FAQ2_3>

Irrelevant regarding your note.


PointedEars

 

[aundro]

s = "[1, 2, 3]"
a = eval(s)

this use is accepable to me, but for the notion that defining an array from
a string with [] is really the way to do.

In this case, where you know the format of the string you evaluate,
it's not very appropriate to use eval, I think.

Actually, I was thinking of creating objects whose
properties/structure you can't 'guess' on the client-side; those can be
pretty complex. In that case, using an eval might probably become more
efficient than parsing strings.

and even then a regex could do the same:

s = "[1, 2, 3]"
a = s.replace(/[\[\] ]/g,'').split(',')

Agreed, but then again you know the structure before parsing (in this case,
you know it's a flat array).

Arnaud

 

[Evertjan.]

aundro wrote on 17 nov 2005 in comp.lang.javascript:

s = "[1, 2, 3]"
a = s.replace(/[\[\] ]/g,'').split(',')

Agreed, but then again you know the structure before parsing (in this
case, you know it's a flat array).

Then again, if you don't know the structure,
how could you be sure it will eval to an array?

I think you always have to know the structure or possible structures.

If you don't, as with unvalidated clientside input, you would have to
validate first [or do a try.. catch every time]

 

[aundro]

aundro wrote on 17 nov 2005 in comp.lang.javascript:

s = "[1, 2, 3]"
a = s.replace(/[\[\] ]/g,'').split(',')

Agreed, but then again you know the structure before parsing (in this
case, you know it's a flat array).

Then again, if you don't know the structure,
how could you be sure it will eval to an array?

Precisely: for more complex cases than arrays eval() might, I think,
be more efficient. Perhaps an example would be appropriate

What I'm thinking of is a tree, for example.
Let's say the server return this kind of string:

"{value : 'top', nodes : [
{value : 'x00', nodes : [
{<deeper, deeper structure>}]},
{value : 'x01', nodes : [
{<again, deeper, deeper structure...>}]}]}"

Then, you'd have to do a rather complex parsing yourself, and then
build 'node' objects, setting their properties, setting up a tree
.... while eval() would make this straightforward.

That's why I actually compared some uses of eval() to Common Lisp's
read-from-string: in order to _build objects_. (probably I didn't make
that clear, sorry)
I personally rarely send code to be eval'd, that has any other
effect than creating objects.

I think you always have to know the structure or possible
structures.

In this case, I know the structure.
Yet, it can be very tedious (and very inefficient) to parse, I
guess. Am I mistaken, here?

Arnaud

 

[Evertjan.]

aundro wrote on 17 nov 2005 in comp.lang.javascript:

In this case, I know the structure.
Yet, it can be very tedious (and very inefficient) to parse, I
guess. Am I mistaken, here?

Tedious and inefficient programming yes, that is a valid point.
Inefficient executing no, IMHO.

However, discouraging eval() in this NG is a valid, as most of the users
that are influenced by it are the newbies, I hope.

 

[Lasse Reichstein Nielsen]

JRS: In article <[email protected]>, dated Wed, 16
Nov 2005 15:54:51, seen in Jim Ley


Is yours worth adding to the newsgroup FAQ section?

Presumably it can be misused in the same way as native eval.

Pretty much. It has only one difference, perhaps advantage, compared
to eval: The evaluation does not happen in the current scope.

/L