This post prompted me to have a look at optimizely's source. I won't give it away either, but I'll certainly be surprised if there's an appreciable difference between the 3 variations. In fact, if turns out there is, I'd be much more inclined to use A/B testing in general!
Now, a coding question. I'm wondering: For the all_experiments_json property of the main optimizely object, why is the value JSON-as-a-string, rather than just JSON? You're forcing yourself to parse it from a string to native JSON for no apparent reason. Just curious :)
As for your question, I think you're right that we could just write this as straight JSON without wrapping it in quotes. What are the benefits of doing this?
I tried just putting the all_experiments_json property in Firebug without wrapping it in quotes and I get a 'SyntaxError: invalid label' error. Looks like that is because the keys of the dicts are strings. Probably a way to generate this JSON server-side that makes Javascript happy.
One potential downside of making it just straight JSON is that this is generated by our Python template and if for whatever reason this isn't valid JSON it would throw a javascript exception when the file is loaded.
Right now our backend that generates this JSON does this:
First off, there aren't really any benefits, other than it being simpler and more elegant. Right now you're going from Python Dictionary -> JSON-like-string -> JSON. There should be a way to go Python Dictionary -> JSON. It just seems like a code smell. Really though, if it ain't broke, don't worry about it. I was just curious as to why there was this roundabout.
Removing the quotes won't fix the problem, because you've also altered the way characters are escaped via the .replace() calls.
One potential downside of making it just straight JSON is that this is generated by our Python template and if for whatever reason this isn't valid JSON it would throw a javascript exception when the file is loaded.
I'm not familiar with Python, but there shouldn't be any reason why simplejson would return invalid JSON. In the event that it does, your script would still break, anyway. Granted, it won't be a javascript exception, but it would certainly fail elsewhere.
Like I said before, it really doesn't matter because it works :)
Now, a coding question. I'm wondering: For the all_experiments_json property of the main optimizely object, why is the value JSON-as-a-string, rather than just JSON? You're forcing yourself to parse it from a string to native JSON for no apparent reason. Just curious :)