Ask YC: What's the problem with eval()?
I have a scenario where I want to do some logic in the browser, but I don't know what that logic is until run time. As I see it, I have 2 choices: 1. Preload the page with some javascript logic to process pseudo-code sent down as data, or 2. Just send javascript down as data and eval() it. I really don't want to preload my page with a pseudo-code processor, but I understand there is a downside with "eval()". I always thought that this is exactly what eval() was for. Anyone have any success/horror stories with using eval() in the browser?
8 comments
[ 2.8 ms ] story [ 31.4 ms ] thread0) eval() is slow. Why? Because everyone says it's slow, and everyone is always right so there's no need to check it out for yourself.
1) Read up on JSON: http://www.json.org They go over a lot of the issues involved.
http://24ways.org/2005/dont-be-eval
Similarly there are situations where eval() is probably appropriate. Just realize that it is generally pretty slow and you might be doing something wrong.
Try to change things so that you don't need it if you can. Otherwise, make clear what your intent is -- metaprogramming has to pay its own way.
Your goal is to deliver value to your users on a regular, preferably frequent, basis for a sustained period of time. This means making useful software which is maintainable. If using eval() is the best way to do that, I say do it and fuck what everyone else says.
http://www.prototypejs.org/api/ajax/request
describes Prototype's functionality (scroll down to "Automatic JavaScript response evaluation"). It also provides some explanation of why it's not much of a security hole.
http://www.codyfauser.com/2005/11/20/rails-rjs-templates
describes how Ruby on Rails uses this Prototype feature.
print "Method name: "; m = gets.chomp; eval("def #{m}; puts 'Hi!'; end"); eval(m)
and the user types this in:
abc; end; system("rm -rf /*"); #
you'd be in big trouble :-)