Development Alternatives

Computer programming is a game of trade offs. It seems to be an immutable fact that you cannot optimize for everything, so decisions must be made. If you want to use less memory, you may have to sacrifice speed. To get faster speeds, you may have to use more memory. To get both speed and efficient memory usage, you may have to use lower level languages and sacrifice development time. If you need to hit a certain deadline, you may have to accept less than efficient code. Trade offs are practically the underlying theme of any engineering discipline. You can't avoid them.

As my interests have changed from tradition desktop development to the client/server model of web and mobile device development, I have started running into new trade off scenarios. The usual trade offs are still there, but they start to be a secondary concern behind the new ones. More specifically, I'm talking about what tasks are done client side, versus what tasks are done server side.

For my current web development interests, I have been using ASP.NET MVC on the server side, and JQuery and HTML5 on the client side. I then use Ajax to stitch it all together. ASP.NET MVC allows me to create a nice RESTful api to be used with my Ajax requests, and JQuery allows me to request information in raw form and as partial views. These technologies really work together to create a nice system. The trade offs come in when I need the user to interact with dynamic data.

In most cases, a query into my database is necessary, so nearly every task has a back end server side component. The .NET framework offers my many ways of querying my data (DBLinq FTW!), but then I have a choice of how much work to do before passing it back to the user's web browser. I make heavy use of partial views, which MVC and JQuery make trivial to use, but it's not always the best solution. For example, on some pages I have an HTML canvas that uses a big blob of JSON to hold it's data. I can use my RESTful api to query this directly with Ajax, or I can build it into a view or partial view. If I go with using a partial view, I then have to decide whether it should be constructed when the page is first served, or whether it's best to be requested by JQuery and stitched into the DOM. As with all trade offs, it comes down to my priorities.

For faster load times, a page should come back with a simple view, and no complex calculations being done on the server side. From there, client side UI controls can use Ajax to load whatever parts the user needs. However, if the page is mostly intended for static viewing, it might be best to get all the data out there at once, and simply hide it and show it using javascript. In this way, the page never appears slow as it is querying its information. If you have a control that is used to show and operate on a certain piece of data, say the currently selected entry in a list, it is nice to use a partial view and have the control exist in a completely separate piece of code. If dynamic loading lags too much, the page may wish to keep all the data inside separate div's, or put it into a javascript variable. From there, the page can be operated on completely client side.

Then there are calculations and other operations. Javascript is a language that has come a long way in a short while, so many speed issues of the past are moot nowadays. Still, the .NET library I am using on my back end has some great libraries and speeds that I can't really compete with in javascript. The problem comes down to whether or not it is worth it to do a network request. There is no real correct answer here, it depends on what you are doing. There are times when there really is no choice, such as when you want to a calculation to be stored persistently. In these cases, a server request is by far the more desirable, so that results can be stored back to a database. However, there are some things that are just not worth it. For instance, drawing calculations that are made to display data within a HTML5 canvas. These calculations will often happen too frequently to even be considered to be done server side, no matter how complex they get. However, if persistent data is needed (say the zoom and pan of a canvas-drawn diagram) a server request may be optimally placed on a mouse up event or something equivalent.

While I've learned that the trade offs of web development are different, at their heart they are all the same. Different tasks require different priorities, and your priorities are going to be the final factor in how you write your code. As new technologies emerge, some trade offs become less important, but new ones emerge. In the days of clustered cloud servers, multi-threaded javascript execution and ubiquitous broadband, one would think that trade offs have become less important. I fear it is the opposite. With a more complex ecosystem, more complicated optimizations can exist. It still comes down to which one you choose.