
A Large-Scale Study of the Use of Eval in JavaScript Applications (2011) [pdf] - luu
http://the.gregor.institute/papers/ecoop2011-richards-eval.pdf
======
bshimmin
For all the people who spend time on HackerNews and suffer from impostor
syndrome, I hope this snippet (pg. 21) will make them feel a little better
about themselves:

    
    
      var ev;
      eval("ev = control." + eventType + ";");
      eval("control." + eventType + " = func;");

------
TheAceOfHearts
It's probably judicious to avoid using eval in a lot of everyday application,
but there's places where using it isn't particularly harmful. One example of
this is when using Webpack, if you set the devtool option to use eval, it'll
build and rebuild faster than the other options.

Another cool thing that you find is JavaScript is the "with" keyword. A lot of
people don't even know it exists. I think Chrome's DevTools uses it along with
eval. When you type something invalid, you can see stuff like:

with (typeof __commandLineAPI !== 'undefined' ? __commandLineAPI : {
__proto__: null }) { whatever }

~~~
orf
> A lot of people don't even know it exists

Good, it's fantastically broken and shouldn't be used.

~~~
Klathmon
That's the kind of black-and-white thinking that he is talking about.

It might be terrible to use in the vast majority of situations, but it works
and it works great for those few situations that it's extremely useful for.
Blacklisting something like that as a hard rule ends up doing much more harm
than good in my opinion.

~~~
LunaSea
The issue is rather that even though the situation isn't black and white, a
very large majority of web developers aren't security knowledgable enough to
make the decision of if it is or isn't safe to use it in each specific case.

This is why blanket black-listing (or white-listing in cases where it is
possible) is a better option because, similar to Murphy's law, if something
(like eval) can be misused it will be.

~~~
Klathmon
But that kind of hand-holding doesn't ever work.

if someone wants to do something "bad" in a language, it's better to teach
them why it's bad than to blacklist certain parts of it.

I've seen developers tell me that eval is bad, but they found a way to do what
they want by using `new Function()` (which takes a string of code and makes it
into a function that can be executed...)

Teach why these things are a good idea to avoid, teach why it's dangerous,
teach scenarios where it's tempting but there is a better way, but don't
disallow their use entirely. We wouldn't be developers if we just gave up the
first time someone told us that we couldn't do it that way.

~~~
LunaSea
I disagree. Security is a job on it's own and although you can teach some
security know how in the grand scheme of things a web developer will never be
at the same level of understanding than an actual penetration tester or
security researcher.

To enforce rules like this, the best practice I would say is to add JSLint or
ESLint with a strict rule set on a pre-commit hook and then refuse any commits
/ merges that don't pass the static analysis of those tools.

~~~
Klathmon
I agree that security stuff is best left to security researchers. However you
need to draw the line somewhere. Allowing a while loop can be a security issue
for some applications. I was more talking about issues like the `with` in JS
or `goto` in other languages. Yeah, they are a really bad idea for the vast
majority of situations, but every now and then they are incredibly useful or
provide an insane speed improvement and they can be safely used.

An eval example i've seen recently was about sending functions to web-workers.
The only way to allow code to run in a web worker without a separate file is
to convert a function to a string and eval the code in the web-worker side. So
i could massively over complicate my build system, duplicate code in a bunch
of places, and near-double the size of the downloaded code to get it working
without eval, or i could setup a simple eval system and have it run a function
passed in as a string.

Yeah, you shouldn't be using eval to decide if the number entered was 5 or 6,
but saying it's disallowed from the codebase entirely is silly. Even a policy
like "any code that uses eval must be approved by X, Y, and Z before they will
be allowed in the codebase" is much more sane.

------
archgrove
An interesting paper, but worth noting it was published in ECOOP 2011 (so
written largely in 2010, probably). The landscape has undoubtedly changed a
lot since then.

