0

Possible Duplicate:
When is JavaScript's eval() not evil?

I was wondering,

besides Eval activates the interpreter again, causing overhead,

the only situation in which it can be bad (except what I've just written), is when JS sends data (which is eval'd) to server.

I don't see any other scenario, if a user wants to play with the js, he will play only in his browser boundaries (unless JS is interacting with Server).

Am I right?

I'd be happy for corrections.

Community
  • 1
  • 1
Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • @canon i read that already , still didnt find answer there. ( except that i forgot to mentioned about the the debug problem) – Royi Namir Jul 20 '12 at 20:40
  • http://javascriptweblog.wordpress.com/2010/04/19/how-evil-is-eval/, http://berniesumption.com/software/eval-considered-useful/ – Blaster Jul 20 '12 at 20:41
  • It would be more effective if you stated why you want to use eval. Then we could assess if that's a good idea. Unless, of course, you're asking theoretically... – Šime Vidas Jul 20 '12 at 20:45
  • @ŠimeVidas ,theoretically Just for knowledge. I ususally use JSON PARSE , or JSON2 from douglas – Royi Namir Jul 20 '12 at 20:46

1 Answers1

3

Strictly speaking, there is nothing actually, phsyically harmful in using eval, because it does nothing more than what the browser's console can already do.

There is a potential danger of injection, but that's the same risk as putting any user-supplied input into a <script> tag, not a particularity of eval.

The main reason to avoid eval is because it has to interpret a string. Now, to be fair, just running a JavaScript file is basically the same as calling a great big eval over the whole file (broadly speaking), because JavaScript is interpreted (or at most compiled at run-time). Therefore, using eval sparsely, where it only gets run, say, when a user clicks on a button, is fine. Noticeable effects will only appear if you end up with eval running frequently, such as in a loop. This is why people will always tell you to pass a function to setTimeout instead of a string, for instance.

That said, there is always an alternative to using eval. It may require rewriting parts of older code, but it's always avoidable.

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • what bout the "user sandbox only" and "can hurt only if client talks to server" – Royi Namir Jul 20 '12 at 20:48
  • `eval` does no more harm than the browser's console can. For instance, since the console can't delete files on a computer, neither can `eval`. But my console can communicate with the server (AJAX, XSS etc.) but this is only an issue if the bad `eval` gets onto other people's computers - which it can only do if you inject user-supplied content into other people's pages (such as with a forum) – Niet the Dark Absol Jul 20 '12 at 20:49
  • "there is nothing actually, physically harmful in using `eval`" ... well, technically only 0.00001% (or so) of code is "physically harmful", so in that sense you are correct :-) However, you're wrong in the sense that `eval` has a performance cost (the details of which vary based on the code and browser involved). You can run the exact same code with/without `eval` and see it perform slower with `eval`, so in that sense there *is* actually something harmful about eval. – machineghost Jul 20 '12 at 21:01
  • @machineghost Regarding the time thing, the main cause for that is because the browser has to first parse the `eval` function call itself, and then the string passed to it. I'm fairly sure that if you could time just the execution of the string itself, it'd be the same as raw code. – Niet the Dark Absol Jul 20 '12 at 21:06
  • @Kolink there are other factors as well, but again they depend on the particulars of the code and (more importantly) the browser. It is safe to say that for newer browsers you are likely correct. Still, to me at least it doesn't matter where the slowness comes from; the simple fact that (all else being equal) eval is even a little bit slower should be enough to keep any developer from using it, ESPECIALLY given the non-performance issues with it. – machineghost Jul 20 '12 at 22:47