If you wander why I have not published a single line of code from Project Banana, it’s because I am not happy with it yet.

I have some fully working code of version 1 with an engine but the architecture is wrong and it does not have CMS/SMS, it was a prototype to prove that certain aspects could be done. However, version 1 used too much bandwidth, was not search engine friendly (and could never be), was solely based on ASP.NET 2.0, could not make use of URL rewriting, was not maintainable and used ASP.NET Ajax which is too bulky for South African bandwidth.

Then I started version 2, keeping in mind the issues that were raised in version 1, I started to look for an ASP.NET platform to work form. I looked at a couple of approaches such as MVP Pattern as implemented in Web Client Software Factory which had 70% of my basic requirement out the box, however it was not going to work in a Medium Trust environment and needed major changes to do so, hence I gave it up, it may very well have been my worst decision. Then came ASP.NET MVC, though it only has 40% of my requirements, I thought it was to be my saviour, it may work beautifully for the public facing web application but would bring very little for the SMS, so I abandoned it but only for the SMS. I still think that the website API can work well with MVC. After much debate, I opted to try to create a base framework of my own, one I have now abandoned and let me explain why.

Firstly, my core requirements for the Site Management System (SMS) are as follows:

• Modular, plug in a new module maybe run an SQL script and voila the SMS functionality is working. This means that it will integrate itself into the SMS without the need to configure anything, in short copy a folder to the SMS and it auto-magically works, integrates into the menu, uses the SMS HTML layout, configurations and database without further intervention. (WCSF does most of this out of the box)
• Updatable modules, bug fixes should only affect the module affected and not break the site.
• Upgradable modules, assuming that the client wants to upgrade a module to something more complicated it should be as easy as copying it across and maybe run a SQL script, thus no loss of data. The upgraded module must be compatible with the previous module’s API and database.
• I also want to start using TDD for this as there are needs for backward compatibility and there will be more than one developer on this project sooner or later, something that “classic” ASP.NET does not provide. (WCSF does this out of the box)
• Highly optimized HTML output for fast responses in the South African bandwidth environment.
• Lastly, I want to secure the code at least for now until I decide on a licensing scheme, that will mean that the code will be compiled to 1 or more dlls and that there will be a licensing system on the master application.

So, as I embarked on my development mission to achieve the basic requirements above I found myself writing a solution that did what the Web Client Software Factory does, thus reinventing the wheel and wasting my time. After all, WCSF was written by the Microsoft Patterns and Practices team for us to use, and they kindly supply the entire code with a lenient licence. And it solves 70% of my problems. So, back to the drawing board it is, this time with the WCSF and having to learn IoC, TDD and more.

Project Banana 3.5.2 here I come, as for the version number well, nevermind.

I am currently optimising a web site that I am writing, aptly called "Project Banana™", the requirements are quiet steep as it is a site management system and needs a lot of user interactivity, Web 2 stuff if you will. I will be discussing my finding so far in a series of postings, starting with this one.

When I started with this I promised myself not to change the look and to keep or improve functionality, you will see how I faired over these posts.

The HTML

I started with a layout I got from a graphic designer friend, Neels Van Den Berg of Evoke Media, his HTML comprised of tables, spacer blank pixels and graphics for effects. The first thing I did was to throw out all the unnecessary tables as well as images and replaced them with styled div's or styles, I have more than halved the size of my HTML doing this. So my first advise is: Use Div's with styling instead of tables where possible. And I know it's a lot of work but it is all worth it in the end.

Images

Avoiding unnecessary large images is vital to a fast site however even more important is using the right compression for the right purpose. A simple guide line would be that pictures (non photo) that do not require more than 256 kb be GIF with optimisation on colour depth. Where as photographs should either be JPG or PNG. Compression should always be set to the maximum before loss of quality. These simple guide lines will gain you a few valuable kilobytes.

Cascading Style Sheet

Put all your styles in a (or more but not too many) separate CSS files this will allow you to reuse stiles and keep consistency across the site but more importantly you can “minify” the files when you deploy them to the production server gaining you more valuable kilobytes. Call all your CSS files from the Master Pages, the less they are the more the “minify” and “GZip compression” will have effect. Also if you can archive a visual effect in CSS rather than using images do it.

AJAX (or the JavaScript factor)

Firstly, when it comes to optimising ASP.NET over the wire, on fact is certain! The Microsoft controls are evil! So, throw away all those over the top bloated Microsoft Composite Web Controls such as the Menu, Tree, DataGrid controls and the supper heavy (83 kb) Microsoft Ajax Library and toolkit they download resources that will never be used. In stead use the repeater in association with Jquery or another and plugins to that library. The good thing about JavaScript is that the source code is always available, so no surprises. Bottom line use a JavaScript library such as Jquery, Moo tools, Prototype, DOJO, Ext JS to mention but a few. Additionally, put your reusable JavaScript in a JS file and “minify” and "GZip" the files when deployed to the production server. Also when using .NET make use of Master Pages it will ensure browser cashing. Furthermore, combining and compressing the JS files using the modified script manager will gain you more bytes then you bargained for, go to http://weblogs.asp.net/bleroy/archive/2008/07/07/using-scriptmanager-with-other-frameworks.aspx for more information.

Web Services

When using web services use Json, it nearly ½ the size of XML and JavaScript understand Json natively, therefore all the JavaScript libraries should too. The good news is that ASP.NET has a Json library and if that does not help James Newton-King has the answer in the form of Json.NET including features like LINQ to Json and the ability to convert JSON to and from XML

Server Side

Set compression “ON” on the web server.

ASP.NET

The second evil from Microsoft in ASP.NET is the forever useful viewstate. truthfully, if a .NET control does not need state, as is usually the case, set the viewstate to false. It is by far the biggest bloater of HTML pages ever. As useful as it might be as dangerous it can be. And now for the one we all forget, to set the Debug to false in the Config.web file and compile as release before we deploy to the production server. This will allow for browser caching and a faster application as it no longer needs to run the debug data.

Testing

Test all sites on Microsoft Internet Explorer 6+, Mozilla Firefox 2+, Google Chrome, Opera and the even the dreaded Apple Safari. Apple Safari is one of the two oddballs it does not follow the same font convention as the others. The other problem child is Microsoft Explorer, if you are going to have layout or JavaScript issues, it's going to be here. Firefox, Opera and Chrome seem very happy, if it works in the one it seems that it will work in the other two. During my development cycle I tend to use Firefox and Internet Explorer mainly for the developer tools that are available which I will be discussing in Part 2 of this series as a part of the Essential ASP.NET developer's toolbox.

Conclusion

Monitor how much data is downloaded for the site during development and fix any bloats immediately. It will avoid lots of issues later, make the site more responsive and save bandwidth, something very important here in South Africa where petrol is nearly cheaper than a few Megs. In some cases 1 Mb can cost up to 2 Rands (about 20 cents US)makes 1 litre of petrol = 4 Mb. South Africa is also a country where a 56kb analogue modem is still common place.