Hacker News Reader

Comment by wccrawford | Hacker News Reader

"Wary", not "weary".

I'm not sure that I agree that data binding is a 'sloppy coding trick'. It's a time-saver. It enables what you were going to do anyhow, but with a lot less code. (And hopefully a lot clearer.)

View on HN

I actually meant weary as in "tired" so there!

(Just kidding, I was totally wrong on that. Thanks for the correction)

As far as data binding there are two reasons I consider it sloppy...

1. It's magic box coding (as in I put these simple commands in and the environment just handles it for me and I have little idea how)

2. It (by Microsoft's admission) hogs bandwidth. In the desktop world that wasn't a problem but in web applications its a big one.

Which is basically my point. Data binding was a desktop application technique that Microsoft carried over into Web Forms and which is now trying to make its way into MVC. But it's not technology built with the web in mind and designing a new model around it doesn't change that.

I will take Mr. Sanderson's advice in the other reply here and try the thing out but for the reasons above I don't see myself adopting it.

I can't endorse KnockoutJS because I've never used it. However, I'd like to address the two points you made.

> 1. It's magic box coding (as in I put these simple commands in and the environment just handles it for me and I have little idea how)

Is this not abstraction? I'm not familiar with the internals of the Python interpreter, but I'm able to be productive and creative with it.

> 2. It (by Microsoft's admission) hogs bandwidth. In the desktop world that wasn't a problem but in web applications its a big one.

I'm not convinced that this is a problem outside of edge-case scenarios. However, from my understanding, this limitation is overcome in two ways: 1. Large application are broken up into small modules which can be loaded lazily. 2. Time. The average bandwidth of an internet user increases exponentially over time.

I'm not sure I know what you're talking about. I was talking about Data Binding in the context of Microsoft technology. So, for example, when you want a grid to reflect an entire database table you can define the table and this with two lines of code (grid.datasource = table and then grid.databind()) the grid will reflect the table. It takes care of all the hard stuff as far as pagination, sorting columns, and even updating and deleting are taken care of automatically.

It is a really quick and easy way to do things (and I don't question how amazing it is in its depth of ability). But it creates almost constant chatter as the grid is reflecting all changes off the database.

Oh, that kind of databinding. That doesn't really bear any relation to what knockout does :)

I'm sure there must be a template for this where you can see pretty intimately how it works and completely change it. In WPF land they're lookless controls. The databinding gives you a local copy of an object that is updated (via things like INotifyPropertyChanged) and then templates render it. There's no magic. Just a lot less code to write.

I see what you're saying. Yeah, one certainly needs to be careful with those sort of high-level abstractions. I remember when I first started learning WPF, I ran into the exact problem you described. I had a data grid bound to an sqlite database. Without optimization, every row update was making three of four calls to the database. When there were a few thousand records, the UI would screech to a halt.

I like Magic Boxes. They let me get stuff done quickly, and then I can go figure out how they work later.

To be fair, I used to hate them... Back before I started investigating how they worked. Now I'm only slightly uncomfortable with one I don't understand, and love ones that I do.

Bandwidth, and and its brother Responsiveness, are a concern, however. I didn't look into this, but it appeared that the data binding was done in-browser, and only saving the data resulting in bandwidth usage.

Reply on news.ycombinator.com