Plain Old JavaScript

Monday, February 27, 2012

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 RealityDragon by Jeda Villa Bali

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?


Comments
gravatar Joe Monday, February 27, 2012
I think these 'frameworks' are filling in the gaps of the platform. If we had a better client platform architecture, built for applications, then we wouldn't need them as much.

It's true that their surface area is too wide. As web applications get more and more complex this is going to become more and more of an issue.

What would really help is to standardize on the interfaces behind the frameworks. Why can't we have a standard notation for binding? A stanard for client-side templates? A standard observable pattern? Much like the promise/a specification.
gravatar The One Monday, February 27, 2012
What exactly is stopping you from writing JS the old way? You can have framework AND "old way" side by side!

Though it seems once you now a framework (ExtJS in my case) and realize it's benefits, you never want to go the "old way"...
gravatar NickV Monday, February 27, 2012
Back in my day, we didn't need frameworks! :D
gravatar Steve Gentile Monday, February 27, 2012
so... let's take a jQuery - it's a framework than encapsulates ajax calls. We could make raw calls without this, but it encapsulates functionality we use on a regular basis.

Now, KnockoutJs is surely further up the encapsulation tree. At that point, whether it's Backbone, KnockoutJs, etc.. there is a buying into the framework that occurs - people evaluate they decide the functionality it brings is worth the obtrusiveness / learning curve it brings. Some prefer to build their own - it's a catch 22, when you build your own you know how it all works, but it could result in taking longer to get to market, etc..

If I were to compare, I've been using NodeJs. Didn't take too long to want to use Express - because I don't want to code up my own webserver every time. But by selecting Express - its not going to be easy to just yank that in and replace with yet another framework. I just need to be sure, at that time, that Express has what I need to satisfy that project.

I think it depends on what you are building, if it's simple, sure ,you don't need all this cruft, but as it grows larger, I think some frameworks can really help. Frameworks that can be unobtrusive yet powerful would be preferred. They either have you doing more in the code (ie. all those observables) - or they hide in some black magic (ie. the Ember example) - it looks simple until you did into their base class.

Side note - KnockoutJs does have a mapping library that allows you to take a POJO object and make it observable.

Good post - it reminds me of the same arguments I had about NHibernate vs. EFv1 - the MS guys all loved the drag and drop - but it was a mess. Eventually MS admitted it and came out with 'code first'. Same concept perhaps?

Now we have this: http://www.asp.net/single-page-application - more black magic :)
gravatar Rob Conery Monday, February 27, 2012
Yes.... yes I do...
gravatar John Sonmez Monday, February 27, 2012
You are exactly right. This is a BIG problem that is going to bite us hard.

The biggest problem I see is that much of this just needs to be baked right into the language or the framework itself.
What have essentially built are internal DSLs of Javascript.

This is great for a while, but it needs to evolve. We need a real language with the functionality that has been duck taped onto Javascript. Either that or a built in framework or structure like the current DOM.
gravatar Adam Webber Monday, February 27, 2012
Hi,

I agree completely! There is at least one framework that is doing the right thing - http://angularjs.org

I just posted a comparison between Angular and Knockout, take a look at the plain old javascript in Angular - beautiful!

Here is the comparison zdam.posterous.com

Best wishes.
gravatar Rick Schott Monday, February 27, 2012
When it helps with cross browser compliance, yes, when it's the new shiny thing, no. Generally I find that people who wrote JavaScript before terms like AJAX existed, tend to feel this way.
gravatar Rik Hemsley Tuesday, February 28, 2012
"Does anybody else in here feel the way I do?"

Vera?
gravatar scott Tuesday, February 28, 2012
@Rik: What has become of you?
gravatar Chris Marisic Tuesday, February 28, 2012
I'm the architect at my shop and for our current large application we chose Knockout 2.0

We've been having tremendous success with it. This will likely become the staple to how we build rich client side interfaces.
Mayank Tuesday, February 28, 2012
The frameworks are started with the intention of making development efficient. But somewhere along the way, the objective replaced with making the framework efficient and elegant, which is where it hurts.

It also hurts to see new Devs not knowing the good old simple model the way I know (or maybe knew) it.
gravatar Codevendor Tuesday, February 28, 2012
I understand your point completely. I am the actual creator of Custom Javascript Event Manager (CJEM) www.codeproject.com/...

Frameworks bring on long learning curves and forced ways of doing things, but sometimes those costs can have benefits of producing better code and understanding. When I program, I try to stick to standards in javascript, css and html and the dom. Sometimes frameworks are too bloated with things that are not needed or excessive for just webpage development.
gravatar Daniel Wednesday, February 29, 2012
I'd say that the problem is not with the frameworks per se, but with BIG frameworks that try to do too much. KnockoutJS is a small framework (more of library) that is easy to learn, has good support and can be integrated easily with other small libraries.
gravatar Mike Wednesday, February 29, 2012
Old way / Frameworks?
I think it's in general a question of writing clean code. I take care of some online shops and what do you think how often I found two or three versions of the same Framework in ONE(!) shop? "Oh, I want this 'module' and this and this ..." after that: "Can you look into my shop? Something is broken!" Really? Should I be surprised about some "side effects" ... :-|

Ciao,
Mike
Adam Wednesday, February 29, 2012
Your post would have been more complete if you had mentioned that that kockoutJS code you wrote allows for **two-way** binding right to your dom. Like Chris I've had nothing but success using Knockout. It's simply amazing being able to get two-way MVVM binding like WPF offers, but with the simplicity that html / JavaScript offers.

Is there a specific thing you find wrong with knockout, or is this just a general rant because you find learning new tools to be too difficult?
Adam Wednesday, February 29, 2012
Your post would have been more complete if you had mentioned that that kockoutJS code you wrote allows for **two-way** binding right to your dom. Like Chris I've had nothing but success using Knockout. It's simply amazing being able to get two-way MVVM binding like WPF offers, but with the simplicity that html / JavaScript offers.

Is there a specific thing you find wrong with knockout, or is this just a general rant because you find learning new tools to be too difficult?
gravatar Jasmine Wednesday, February 29, 2012
I'm much more worried about the fact that heavy framework usage causes people to forget how to write Javascript. Or, it allows them to get things done without learning Javascript, and since they can get things done, they are tempted to lie on their resumes and say they know Javascript when they don't. They might even believe they actually do know it.
gravatar Chris Marisic Wednesday, February 29, 2012
@Jasmine there's a difference between knowing the language of javascript and being an expert at the intricacies of DOM manipulation in javascript. The intricacies of DOM manipulation reach a level of absurdity. Yes it's incredible easy to do, and even easier to do BADLY.


I honestly have very little clue what about is right and wrong with DOM manipulation, which is also very heavily browser centric. I trust a framework like Knockout to handle the binding of HTML templates to the UI, and the 2 way binding of my data to observables.

This allows me to focus on producing business functionality with a model that is very similar to the old school Presenter class in the MVP pattern. Instead of writing hours and 100s and 1000s of lines of code for mutating html and firing events all properly I only need to care about handling events I want to handle. It's been a gigantic boon, it also creates an extremely cohesive code base in javascript. Functionality is all attached to the ViewModel which separates the actions of the Server and the Client. Most frameworks I use I end up with a list of complaints about, with Knockout I can't even think of 1 compliant.
gravatar adamant Wednesday, February 29, 2012
@adam:
1st paragraph: good.
2nd paragraph: you are an a-hole.
Adam Wednesday, February 29, 2012
@adamant

Maybe I'm an a-hole, but it's a pet peeve of mine for bloggers to just rant against how bad frameworks are without really backing it up, and talking about their benefits. Especially bad is the fact this post dumped on KnockoutJS, one of the best JS frameworks in town, without even mentioning what it can do for developers.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!