Embrace the frontend

In my last post I wrote about getting out of the “forms” business and into the “AJAX” business, which I view as a pivotal step in the development of Web applications that are both better managed and more responsive.

The problem is that once you are liberated from the tyranny of <forms> you find that you can no longer be just a “backend developer” that surfaces web pages. You must learn the language of the frontend. I know you love your strongly typed, server side, cozy blanket, and you can certainly go work for some monolithic death corp and write the same code for the rest of your life. But if you want to develop interesting applications and stay current in the flow of software technology, get over it and start learning javascript.

One’s first steps into javascript invariably go as follows:

1) Write a bunch of crap in a <script> tag in the HTML file it’s self

2) Discover what a mess that is and how hard it is to debug and move same crap into a separate file.

At that point you think you are being responsible and call it done. A year goes by and you find that you have a lot of those files, with lots of duplicated code and/or duplicated functionality with different implementations. You consolidate that into some horrible library that contains every “helper function” in the world and include the whole file on every page. Probably minify it so when it breaks it’s a pain to figure out what’s going on and now you think you’re done.

Well you’re not. You wouldn’t write your C# application like that. In fact you’d probably go on some career-ending rant if you saw it being done (much as I am doing here with js). You must treat you’re javascript application with respect if you want it to respect you. Sure it lives for, perhaps 10 seconds, but those are pivotal seconds and that time can and will grow as you feel the joy of building an app on the client side.

So how do you treat it with respect? Well, the KEY to success is to employ a pattern, a nice pattern, and stick with it for every page. JS doesn’t have a very appealing, object oriented story out of the box, but there are a few patterns for creating objects or classes that are easier and more familiar to work with. Some are better than others. And there are several frameworks that provide implementations of these patterns and generally wrap them up with some other functionality.

As I mentioned in my previous post (not smart enough to know how to point to previous post here), I like very much the Knockout.js . However, Knockout endorses a rather repugnant pattern of dispersing your javascript between your HTML and a simple javascript object. You essentially (within Knockout’s attribute) put onclick -> fire this event in my ViewModel. Their ViewModel is just a plain old javascript object with properties and functions on it. The idea of putting a bunch of behavior inside of HTML is most unpleasant. However, I am willing to concede the need for a two-way binding attribute. The payoff is so great and the offense rather minor. But when you start putting all manner of logic in the HTML attributes, it’s my loud opinion that, you have crossed the line, Jack. Furthermore, the anemic Knockout ViewModel is not very helpful, when it comes to organizing your code. Thus, I say that KO.js has an excellent two-way binding story but you should leave it at that. Don’t let it take you down the dark road of HTML decoration.

I can see how KO would be compelled to provide other functionality so as to seem more like a “framework” than a “library”, and I can see how they would try to extend what is already working so well for them (e.g. the HTML decoration). I can see this but you can’t make me use it. Other “frameworks” Angular.js for one have taken a similar direction. Angular is very popular, but their HTML wrangling makes KO look like a minor offender. I won’t go any further into my objections. If you want to debate, hit the comments.

In my next post I will write about how I use a combination of backbone.js and ko.js to create a best-of-both-worlds cocktail.

Furthermore, I am cross posting this to my personal blog if you like it so much you want to read it twice. http://cannibalcode.blogspot.com/

Shredding your forms

Shredding your Forms

Using the <form> tag to wrap elements and then submit the data contained within worked in the 90’s. Hell it worked in the early 2000’s. But with the advent of AJAX techniques, the <form> element is now really more of a liability than a help. The problems are as follows:

1) Through some method, unbeknownst to me, when a <button type=”submit”> is clicked the <form> makes a post to the url found in one of it’s attributes. There is no hook into this process not before it goes out and not after it comes back.

2) Add to this that if you have something you need to submit outside of the <form>, you’re pretty much out of luck.

3) Thus you get what’s in your form and nothing else and you must redirect to a whole new page on return. No nice success or error message showing up smoothly, just a whole new page of HTML (which could include your messages of course).

4) This leads to the highly unappealing practice of packing hidden elements within the form, and/or - even worse - updating element names when you dynamically create a new element. Shudddr.

While there are work_arounds for these problems that allow you to use AJAX to catch a form submit, you can take it from me it can be a byzantine nightmare to try to customize.

So when you throw out your horrible <form> tags and start using AJAX to post and get data from the server, you will find that, while it did a rather crap job of it, the <form> tag did at least harvest your values from the elements contained. Without it, you must now query each element that contains data you want to post back. While this is exactly where you get the benefit, it is also a pain. Add to this the fact that, if you are using C# MVC, MVC expects that data to come back in a very precise and unintuitive manner, and you are now faced with a rather boring if not daunting task. In fact, it can be so daunting I may do a blog post explaining how to do it.

Luckily, the solution is not only beautiful it is wonderful and awesome, all wrapped into one. By employing a model binding framework like Knockout.js or one of it’s lesser cousins you can create two way binding between your DOM elements and a JSON object (heretofore referred to as the ViewModel). This means that when you change the value in, say, a text box, the corresponding property on the ViewModel changes as well, and vise versa. So now, when you want to submit your data via AJAX you don’t talk to the DOM at all. Insteadm, you just submit the ViewModel object. Again, the versa of this vise is that when you want to update the DOM you must merely speak, in it’s native tongue, to the ViewModel.

Creating this two-way binding, emancipates you to some degree from the business of mucking around in the DOM. I say to some degree because you most likely will still have to interact with the DOM to perform other actions: clicks, show/hide, fade out with pixels, etc. Still if you can find a way to abstract that noise, you could quite possibly, write tests for your javascript logic without the incredible hassle of spinning up a browser and mocking your HTML.

I have glossed over A LOT of the implementation details in favor of a much higher lever ( and much shorter post). I would be happy to write a post on the details should anyone ask.

In my next post I will discuss the strategy that I have found to be quite fruitful for employing two way binding without horribly polluting your HTML or creating a deep and vast plate of javascript spaghetti.