Is a function plotter a legitimate use of eval() in JavaScript?

Question

From PHP development I know that eval is evil and I've recently read What constitutes “Proper use” of the javascript Eval feature? and Don't be eval. The only proper use of eval I've read is Ajax.

I'm currently developing a visualization tool that lets users see how polynomials can interpolate functions:

• Example
• Code on GitHub

I use eval for evaluation of arbitrary functions. Is this a legitimate use of eval? How could I get rid of eval?

I want the user to be able to execute any function of the following forms:

1. a x^i with a,i in R
2. sin, cos, tan
3. b^x with b in R
4. any combination that you can get by
   • adding (e.g. x^2 + x^3 + sin(x)),
   • multiplying (e.g. sin(x)*x^2) or
   • inserting (e.g. sin(x^2))

Answer 1

I see nothing not "legitimate", eval isn't evil per se and it has been precisely designed to evaluate arbitrary code. It lets you here make a fast, complete expression evaluator without resorting to complex libraries and it gives your user the power of JavaScript.

But right now you're evaluating the input for each x. This is very slow.

I would do this so that it can be used more efficiently :

var f = Function('x','return '+input);

When input is Math.sin(x), this builds a function you can simply call as

var x = 3;
var y = f(x);

Proof : jsperf

---

If what you want is to let the user enter function with a more classical mathematical language (like x^y), then you'd better start importing a mathematical expression parser.

An example of such a library : Silent Mat's evaluator

Answer 2

You don't want to evaluate Javascript functions. You want to evaluate some subset of the computable functions from the reals to the reals. So eval doesn't do what you want, although in principle you may be able to abuse it for that. Apart from this philosophical objection, if you want to use ^ for exponentiation, you can't use eval because it uses Javascript syntax where ^ is binary xor.

If you just want to be done quickly and leave this project, you can use eval (especially since this apparently runs on the client site, so the potential for abuse is limited). But the right thing(tm) to do would be using an expression parser specifically for the kind of syntax you want to allow, coupled with an evaluation routine for the parsing output.

It's not that hard to write such a thing yourself, and quite fun. I'd use either the shunting-yard algorithm or a top down operator precedence parser. Alternatively, use an existing library as recommended in the comments.

Answer 3

A lot of people who know eval is dangerous on the server side also reflexively shun it on the client side. There is a huge difference. It is not a security hole to be able to execute your own arbitrary code on your own computer. The only time to be concerned about eval security on the client side is if you're using it to execute code from an untrusted third party, for example from email or a twitter feed.

However, there are other factors to consider. The eval solution is going to be much simpler for basic functionality, but much more difficult to add things like useful error messages. You may end up implementing your own parser anyway to add those sorts of features.

There are also performance considerations, but I think the difference is likely to be negligible. eval will probably have higher startup times, but faster execution times.

Personally, I would use eval for a tool for my own use or within my company, for its simplicity of development. For wider distribution, I would want the polish a custom parser can provide.