Plain Old JavaScript

Once upon a time there was a pure JavaScript model. The model sang songs about simplicity in a land full of complexity and confusion. The model's clear and beautiful voice comforted many hearts in the land.

var protagonist = {

    firstName: "Priscilla",
    lastName: "Flannery",

    todos: [
        { description: "Kiss frogs", done: false },
        { description: "Slay dragons", done: false }
    ],

    addTodo: function (description) {
        this.todos.push({
            description: description, 
            done: false
        });
    }
};

One day framework dragons descended on the land, enslaving inhabitants and ravaging models. The model songs, once all keyed in F major, became never-ending vamps over B flat augmented arpeggios.

var protagonist = {

    firstName: ko.observable("Priscilla"),
    lastName: ko.observable("Flannery"),

    todos: ko.observableArray([
        { description: "Kiss frog", done: false },
        { description: "Slay dragons", done: false }
    ]),

    // ...
};

The models exchanged melody for infrastructure ...

var protagonist = Ember.Object.create({
    firstName: "Priscilla",
    lastName: "Flannery",
    
    // ...
});

... until one day the models stopped singing and fell silent.

Getting Back To Reality

It's getting harder to write a client-side domain model using plain old JavaScript these days. Frameworks have always been a part of JavaScript programming, mostly thanks to the hostile environment of the DOM, but the frameworks grow more intrusive all the time.

Plain old JavaScript is capable of expressing all the concepts and core ideas of an application. On the server-side we've learned to isolate and protect this sort of code using hexagonal style architectures, and what I fear about many of today's frameworks is just how deeply they need to intertwine themselves with my code. Everyone manipulates the DOM and communicates with the server, but there should also be some logic in the scripts folder that makes an app unique. Can anyone find it? Is it hidden by all the framework code?

Libraries like Knockout and Ember bury themselves into the deepest parts of an application's code. Even using extensibility points that can remove some infrastructure the frameworks change the public API of an object, they change how an object is tested, they change how an object is used, and they change how the object looks in the debugger. Most of all, they change your ability to move to some better, faster, newer, or updated framework in the future without touching and rewriting large sections of code. In exchange you'll get features like data binding, which isn't difficult to do (but is admittedly laborious). I'm not convinced this is a fair trade.

Does anybody else in here feel the way I do?