In this article, we will explore the eval() method. We will get to know the syntax and explain what is the purpose of the method. We will explore whether eval() is really evil and whether you should really stop using it. And if it’s not, are there any legitimate reasons when you should use the eval() method.
eval() method was first featured in ES1 – it dates way back in 1997, therefore it is fully supported in all browsers. Its syntax is simple:
- When the argument is an expression, eval() evaluates the expression.
eval() as a function property of the global object
Starting from ECMAScript 5, when using eval() method indirectly – invoking it through reference other than eval() – the method does not work in the local, but global scope instead. What does that mean? That means that when functions are declared they create global functions, and the code that is evaluated doesn’t have access to local variables within the scope where it’s being called.
So, why is eval so bad and should you really stop using it?
There are several reasons you should avoid using eval() or at least use it carefully. Let’s take a look at them.
1. eval() creates problems with debugging
This problem was actually more of a problem 10 years ago – back then, it was actually impossible to approach code with eval() in it. Luckily, Chrome Developer Tools worked this way around and nowdays it is possible to debug code that contains eval(). However, there are still problems with a normal development flow. Yes, compared to almost 10 years ago, you can view and go through the code, but you have to wait until the code executes before it will show up in the Source panel. For this reason, eval() could create problems with debugging, but essentially it is not the main reason you should stop using it.
2. eval() creates problems with a performance
3. eval() creates problems with renaming variables
In addition to the double interpretation and therefore a speed issue, eval() causes problems with the YUI compressor to convert variable names that are in the scope of the call to eval(). eval() has a great ability – it can access directly any of the variables. However, a problem occurs when you would want to rename any of these variables because renaming them would cause errors. Even tools that convert variable names could still cause errors, so renaming variables still presents an issue that is hard to avoid with eval().
4. eval() creates problems with security when users control the input
Last, but not least. eval() posses a security risk, but don’t take this as a general rule of thumb.
When working within a scope of XXS attacks, using eval() opens your code to these attacks because eval() executes arbitrary code in the context of the page and yes, it is dangerous when you take the user’s input and run it through eval(). Therefore, never ever do that – take the user’s input and somehow pass it through eval(). On the other hand, if your code has nothing to do with the user’s inputs and you’re the only one who controls the input, using eval() should not pose any security risk.
5. eval() creates problems with security in terms of man-in-the-middle attacks
Are there any legitimate reasons you should use eval()?
In the paragraphs above we’ve looked into a few cases when using eval() does not make your code so fragile after all, especially if you understand when you can use it. At the end of the day, there are problems with debugging, performance and security, especially when users control the input. But, let’s see if there are any legitimate reasons when you should use eval() after all.
To be honest, there are very few reasons and good use cases you should use eval(), and most of them are meta-programming and build tools, such as developing:
- template libraries,
- command lines,
- module systems.
In most cases, a good alternative to eval() is Funtion(), which just like eval() takes a string for execution from an expression. However, there is a small, but important difference. eval() will output the result directly, but a Function() will return an anonymous function to you which you can later call.