Visual Studio - Past to Present

• Posted by Shay Friedman on December 8, 2010
• 47 comments

Recently I‘ve been working at a client site where they are using Visual Studio 2005 for their main project. I’ve gotta say that I was a bit surprised since I haven’t come across VS2005 for a few years… I immediately became nostalgic and decided to share. So I’m proud to present (with help from Wikipedia and the WWW), Visual Studio – from past to present!

The Big Visual Studio Usage Poll

Before we begin, I wanna find out which Visual Studio version people are using. And you want to know too, right? So go ahead and fill up the poll!

Year 1997 – Visual Studio 97

Included: Visual Basic 5.0, Visual C++ 5.0, Visual J++ 1.1 and Visual FoxPro 5.0.

A funny related resource: Introducing Visual Studio 97: A Well-stocked Toolbox for Building Distributed Apps

Year 1998 – Visual Studio 6.0

Included: Visual Basic 6.0, Visual C++ 6.0, Visual J++ 6.0, Visual FoxPro 6.0, Visual InterDev 1.0.

Year 2002 – Visual Studio.NET

Included: .NET Framework 1.0, C# 1.0, Visual Basic.NET (VB 7), Visual J# 1.0, Visual C++ .NET 2002 (Visual C++ 7.0).

Year 2003 – Visual Studio .NET 2003

Included: .NET Framework 1.1, C# 1.1, Visual Basic .NET 2003 (VB 7.1), Visual J# 1.1, Visual C++ .NET 2003 (Visual C++ 7.1).

Year 2005 – Visual Studio 2005

Included: .NET Framework 2.0, C# 2.0, Visual Basic 2005 (VB 8.0), Visual J# 2.0, Visual C++ 2005 (Visual C++ 8.0).

Year 2007 – Visual Studio 2008

Included: .NET Framework 3.5, C# 3.5, Visual Basic 2008 (VB 9.0), Visual C++ 2008 (Visual C++ 9.0).

The Present - Year 2010 – Visual Studio 2010

Included: .NET Framework 4.0, C# 4.0, Visual Basic 2010 (VB 10.0), Visual C++ 2010 (Visual C++ 10.0), F# 2.0.

The Future

Well, I really have no idea what Microsoft is planning for the next release of Visual Studio or when it’s gonna see the light of day. If someone knows more, tell us in the comments!

Conclusion

Visual Studio has gone a long way, with 7 major released in 13 years. However, I found out when making this post that the general concept and the UI structure have grown up over the years, but haven’t changed drastically. It’s correct, by the way, for all IDEs out there.

This leads me to one conclusion – the tools have, without a doubt, become better, but we’re still coding using the same general concept that was used 10 and even 20 (maybe even more?) years ago.

Will it be the same 20 years from now?

All the best,
Shay.

Share: :

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

• Posted by Shay Friedman on December 2, 2010
• 6 comments

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.