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.

Unfortunately not. The design of with not only makes the code difficult to reason about for humans, it also makes the code difficult to reason about for js engines, and so it typically prevents any interesting optimisations. So code written using "with" will be both confusing and slow.

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.

You really can think javascript and write coffeescript.

No help on the DSL front though - still stuck with various kinds of brackets and parens.

On the other hand, it doesn't do the utterly horrible mistake of conflating variable declaration and variable assignment while forbidding shadowing, resulting with surprise bugs and spooky action at a distance.

Server-side, sure, use the latest build you can get.

Certainly an option; keeping the syntax recognisable helped rather than hindered adoption, which was slow enough as it was at the beginning.

JS+DOM could have lost to Flash rather than vice versa.

I don't think that JS+DOM beating flash/java has much to do at all with "gee, this looks superficially like java, but is different enough to trip me up in rather weird ways".

In order for that to have not happened, it would have had to be so unpopular that Microsoft would decide it wasn't worth adopting, but still popular enough to get Microsoft on board with the general idea. I just don't think that is likely; people would have sucked up a scheme-based javascript even if it was a tad unfamiliar; it was that useful.

(Not to mention, going with the cynical "three E's" theory of 90s Microsoft, they would have at least first adopted it before perverting it.)

I think people overplay the importance of being C-like. AutoLISP hit a bit earlier and found a very strong following in a non-programmer niche. People doing web development were already fucking around in HTML of course, so clearly they could wrap their heads around things over than curly braces.

microsoft had visual basic in the browser, working like php works. that was microsoft's vision, which would have been the web if netscape didn't still have significant market share. IE had to implement javascript to be compatible with pages written for netscape.

simple as that. just microsoft's famous "embrace, extend, extinguish" strategy at work.

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