IronShay

Ironing code, geek t-shirts and even presentations!

NAVIGATION - SEARCH

Embrace it–JavaScript will Rule the World (Wide Web)

At the moment, we’re witnessing two opposite yet related changes – on the one hand, front-end computers become smaller and more mobile and on the other hand, servers are centralized into large server farms – moved to the cloud.

Web development has changed quite a bit as well – more and more functionality has moved to the client along with the rise of client-side frameworks like JQuery, MooTools and others. Having said that, it seems at the moment that there’s still a lot going on on the server-side of web apps. It does depend on the site, but you can’t deny the fact that postbacks are still a usual practice.

This concerns me. The new cloud era means that we will pay for our server’s computation time, storage and network traffic. Which means that if your developers write inefficient code, you’ll pay more; if your developers consume more network traffic, you’ll pay more; if your designers use high-quality graphics, you’ll pay more; etc.

The immediate effect on web development would be, IMHO, more client-side code. Why? because code that runs on the client doesn’t cost us anything, that’s why.

Postback Vs. AJAX – the Test

To show you what I mean I’ve put up a test – I wrote a very simple page with a form; You write a message inside a textarea box, click submit and your message is written to the server’s event log. Pretty simple.
I implemented this page in two ways:

  • Using a postback.
  • Using JQuery to call a WCF AJAX-enabled service.

The Postback-driven Page

  <%@ Page Title="Home Page" Language="C#" %>

  <script type="text/C#" runat="server">
    protected void btnSubmit_Click(object sender, EventArgs e)
    {
      System.Diagnostics.EventLog.WriteEntry("EventLogger", "Logged: " + tbMessage.Text);
      tbMessage.Text = String.Empty;
      lblThanks.Visible = true;
    }
  </script>

  <html>
    <head>
      <title>DemoApp</title>
    </head>
    <body>    
      <form runat="server">
      <h1>Welcome to Event Logger!</h1>
      <h4><asp:Label runat="server" ID="lblThanks" Text="Thank you!" Visible="false" /></h4>
      Your log message:<br />
      <asp:TextBox runat="server" ID="tbMessage" TextMode="MultiLine" />
      <br />
      <asp:Button runat="server" ID="btnSubmit" Text="Submit" OnClick="btnSubmit_Click" />    
      </form>
    </body>
  </html>

When I click the submit button, about 800 bytes travel to to server and about 1000 bytes travel back – a total of ~1.8Kb (according to Fiddler).

The AJAX-driven Page

The page (I’m using Microsoft’s CDN servers for the JQuery file to reduce network traffic to my cloud-based web server):

<%@ Page Title="Home Page" Language="C#" %>

<html>
  <head>    
    <title>DemoApp</title>
    <script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.4.min.js" type="text/javascript"></script>
    <script type="text/javascript">
      $(document).ready(function () {
        $("#submitButton").bind("click", function () {
          $.ajax({
            type: "GET",
            contentType: "application/json",
            url: "LoggerService.svc/Log",
            data: { "message": $("#message").val() },
            dataType: "json",
            success: function () {
              $("#message").val('');
              $("#thanks").show();
            }
          });
        });
      });
    </script>
  </head>
  <body>    
    <form>
      <h1>Welcome to Event Logger!</h1>
      <div id="thanks" style="display:none;"><h4>Thank you!</h4></div>
      Your log message:<br />
      <textarea id="message" rows="4" cols="20"></textarea>
      <br />
      <input type="button" id="submitButton" value="Submit" />      
    </form>
  </body>
</html>

The service:

using System.ServiceModel;
using System.ServiceModel.Activation;
using System.ServiceModel.Web;

namespace WebApplication4
{
  [ServiceContract(Namespace = "")]
  [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
  public class LoggerService
  {		
    [OperationContract]
    [WebGet]
    public void Log(string message)
    {
      System.Diagnostics.EventLog.WriteEntry("EventLogger", "Logged: " + message);
    }	
  }
}

When I click the submit button, about 550 bytes are sent to the server and about 250 are send back – a total of ~800 bytes (according to Fiddler).

Result

Postback: 1.8Kb <—> AJAX: 800 bytes.
The postback approach took more than twice the network traffic that the AJAX approach took! a 125% addition!!!
Consequently, in the new cloud era, for every dollar you spend on the AJAX approach, you’ll spend 2.25 dollars on the postback approach (for this very simple example)… The situation is even worst actually because outgoing traffic costs more than incoming traffic.
This all might not seem like a big issue at first, but for high traffic sites which would pay $500,000 for the AJAX-based page it would become a huge issue - they’ll have to pay more than $1,000,000 for the same page that uses postbacks. THIS IS C-R-A-Z-Y!!!

Conclusion

This was a very very very very simplified example but it demonstrates my point very well. Postbacks use far more network traffic than AJAX calls; that’s a fact. And this is the reason why, in the future, their usage will be reduced the bare minimum or even disappear entirely.

This was only a single example and I have no doubt that cloud computing will dramatically affect the way we write code. The change won’t be quick, but it will be drastic as we get there. As soon as the big bosses understand that using a different technology/tool/approach within their development teams reduces costs, they will make the needed adjustments to use it.

And if you’re wondering what’s the first tool you need to save money when moving to the cloud then make no mistake – it’s Cloudoscope!

All the best,
Shay.

kick it on DotNetKicks.com Shout it



Comments (1) -

You missed some points.

How much cost the postback software to make ?
How much cost the ajax/javascript version ?

"Classical" web application can be written very fast. For RIA application it is very complex, less people know how to do it the right way. (I think that only a few web app like Google App do use Ajax and javascript in a effective way).

There are lot of problems, costs, and you are not sure to gain much bandwidth. The naive implementation of a ajax application is that you make "chatty" applications that consume much time requesting the

Reply

Pingbacks and trackbacks (1)+

Add comment