Two symbols 'foo can always be considered to mean the same thing, two strings "foo" can't, they may be only the same by coincidence. This matters if automated refactoring tools become available because you can safely rename all occurrences of a symbol, the same cannot be said of strings.

    function Person(first, last, age) {
        this.first = first;
        this.last = last;
        this.age = age;
        this.full = function() {
            return this.first + " " + this.last;
        };
        this.until = function(year) {
            return year - this.age;
        };
    }

    function Person(first, last, age) {
        this.first = first;
        this.last = last;
        this.age = age;
    }
    
    Person.prototype.full = function () {
        return this.first + " " + this.last;
    };
    
    Person.prototype.until = function (year) {
        return year - this.age;
    };

From what you say mind I haven't had this experience, I have found it easy to grasp and lots of examples to get me on my way with nothing left out, always finding that solution to a given problem.

Maybe I should frame the question like this, what would make me enthusiastic to migrate to a RoR or pythan etc. is that they are quicker to develop with, or have lots of prebuilt functions / classes saved you much work. etc. Can you give advantages such as these?

Javascript, though, I feel is a better language. Real first-class functions and closures, innumerable examples and tutorials (though not always good ones), and more. Its problem is that every browser understands it slightly differently.

The method you're suggesting would make it excruciating to converge on a good design with any real designer. Look at the markup any good looking and well-implemented web page (especially one with dynamic content), and you'll see a huge amount of extra tag work to accommodate the real world of cross-and-backwards-compatibility between browsers, CSS limitations, browser quirks, and other concerns that people making professional sites require.

If every one of these changes and workarounds required changes to the code, which would require my time instead of the designer's time?

- If you get the layout, including both how it should look and how things should work, from an external source, or if there is substantial external input, use templates. It will save time and headache.

- If you are just about the only one responsible for the layout but support skins (for lack of a better word; the CSS part), use the HTML tag functions and macros embedded in Arc.

Since Arc is at this point targeted for exploratory programming, the former is an unlikely case.

What I would like to see, though, is a templating engine akin to HTML::Template [1] in Perl 5. It has the minimum of control structures and extra syntax on top of standard HTML, just enough to make it possible to use the template for dynamic content. All templating frameworks suffer from the same fault, though: they define a new but severely restricted embedded language that's mixed in an unpleasant way with the HTML source. The language embedded in Arc is a much cleaner way to do things.

Complex designed websites are pretty much impossible using Arc's current library. Well, unless you're a programmer/designer with a high pain threshold.