Last Updated: February 25, 2016
· arkanciscan

Declarative binding is old school

I really like the declarative two-way data binding that's enabled by libraries like Knockout, Angular, and Ember. It's not just the nifty way things update automagically, or how it promotes the separation of behavior logic from view logic. What I like most about it is not how it creates a totally new way to do web development but how it lets me return to how I used to do things over a decade ago.

I got started in web development in the heady days of Web 1.0. Back when <font> tags were how you styled text, and onclick attributes were the most reliable way to attach event handlers. Then CSS and DOM Level2 came along and suddenly presentational markup and inline event handlers were taboo. Our HTML had to be semantic! The screenreader users of the world would cry if we used tables for layouts. People followed this dogma so fervently I remember seeing a web developer with a tattoo of three documents representing the holy trinity of Structure, Presentation, and Behavior emblazoned across her back.

There was reason to this madness of course. In those days websites were composed of many hundreds of separate static html files. External CSS stylesheets allowed us to make a change to a single file and affect all the pages in our site. Likewise, external Javascript files that used unobtrusive event attachment let multiple pages share common behaviors, among other benefits.

However this progress came at a cost. Looking at an HTML document you couldn't tell what might happen if an element was clicked. In order to change the way an element appeared you had to look up the CSS selector that provided the style rules for it in God only knows which file. Some IDEs could cross reference these files for you, but until recently even browsers couldn't really tell you what event handlers were registered on any given element until the event triggered. Our concerns were so separate that in order to maintain them you had to have an intimate knowledge of three distinct codebases.

Then things started to change again. Ajax and HTML5 gave client side Javascript the power to do more and more complicated logic, while REST made backend servers more and more simple to communicate with. We don't call them "Websites" anymore, we call them "Webapps". They are single files, and we minify our code and combine everything into as few files as we can to save precious load time.

I started to question the logic of arbitrarily putting CSS in external stylesheets ever since I started using templates to build my sites. If I wanted to change a style site wide I only needed to edit a partial. I couldn't see any valid reason not to use a style attribute unless the style needed to be applied to multiple elements on the page at once, or if I needed to style a pseudo class. But I did it anyway for my coworkers.

But when I started using declarative bindings it was like a glass of iced tea on a hot day to see Javascript back inline with the elements it was acting on. It's not strictly correct to refer to bindings in Knockout ("directives" as they are oddly called in Angular) as Javascript. They are more like "behavior rules", and having the behavior of my user-interface explicitly declared in the context in which that behavior occurs is gamechanging!