Skip to content

Comment on Learn the MVVM pattern and knockout.js quickly with in-browser coding exercises

Comments

Props to the developers for making a nice in-browser tutorial. That said, commenting on knockout.js itself, seeing code like this in HTML makes me want to throw-up:

<div>You've clicked <span data-bind="text: numberOfClicks">&nbsp;</span> times</div>

<button data-bind="click: registerClick, enable: !hasClickedTooManyTimes()">Click me</button>

<div data-bind="visible: hasClickedTooManyTimes"> That's too many clicks! Please stop before you wear out your fingers. <button data-bind="click: function() { numberOfClicks(0) }">Reset clicks</button> </div>

I see this as being barely different than inline javascript with a few abstractions, which we as a community have agreed upon to be an awful practice.

I don't agree.

The argument that has gone on in the web community over the past 10 years or more has been about the separation of style and content. Adding inline javascript was no better than adding inline styles. Thus CSS gave us styling without changing content; jQuery gave us dynamic content without affecting content.

However, both require linking a tag property to the CSS or Javascript. Classes and IDs normally (although thus relationship has become more sophisticated over the years).

Dynamic data (XMLHttpRequest/Ajax etc) has caused problems with this pattern. The content and the structure of the data does not now have to live in the page structure. In fact many people completely dynamically generate the page structure along with the data.

Adding a data-bind property to tags in some ways repairs this pattern.

I agree that binding events to the tags at the same time is controversial. However, I am reasonably unfazed by it. It has to go somewhere and I'm not sure that the class definition is the right place either.

I rationalise this opinion like this:

In a dynamic web page we have: Data, Structure, Style, Behaviour.

We have agreed that data goes into structure if possible (when it is static) and that style and content need to be kept apart. But dynamic data often creates or modifies structure through behaviours. Where else should these behaviours go?

When you have dynamic data you often have holes in your structure that are filled or modified by behaviour. Showing the binding of the behaviour to the structure in the HTML, and the binding of the behaviour to the data in the Javascript seems like the best-worse case to me. The hole in your structure where your data will go has a clear marker showing you what will go there and when it will go there. Conversely when you look at the data definitions in the javascript it is instantly clear which data will be dynamically added to the structure of the page.

Personally I like it. It seems so much simpler to me than the other systems that try to solve this.

It also neatly dovetails with jQuery templates & animations.

The chief problem with this (that Knockout still hasn't solved to this day that I know of) is progressive enhancement. Time and time again I try Knockout but I can never get it to progressively enhance based on existing data on the page, because of how overly declarative it is within the HTML elements themselves.

I don't want to go so far as to say that it can't be done, but it's certainly not nearly as easy as my front-end framework of choice right now (Backbone). That's pretty much a deal-breaker right there, and should be for most people wanting to design accessible web applications (which should be nearly everyone).

Could you explain what you mean in a little more detail? In particular does this problem still persist if you use JQuery templates?

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.