ASP.Net Woes

So, R&D is involved in deep web browser development utilising our old favourite ASP.Net which we first used to develop TriSys Web over 13 years ago.

Not a great deal has changed with ASP.Net in that time. We have a new complexity layer called MVC (model, view, controller) for people who need a bigger learning curve to knock up a simple web form, and for people who like wrestling with frameworks - not for the faint hearted. The debugging tools in VS2010 are superb and ASP.Net remains the leader in developing and debugging server based logic.

The client side is a different matter. We have found 10 year old Javascript which we first used in 2002 still relevant today for overcoming some shortfalls. We do not advocate writing CSS or JS generating code in our server side code, as we have seen many others do. We also do not advocate writing more and more business logic in JS on the client, instead rely upon third party vendors server controls to emit the necessary browser independent JS code on the fly. This is however not without many drawbacks, but if you have proper support, it will save considerable time. JQuery has also come along and provides client-side assistance, but is new/cryptic and has a long way to go to mature.

Here is a message to third party ASP.Net/Ajax vendors:

Whilst I appreciate that I can write DIV tags, this is missing the point of using a third party control. The reason we choose to buy ASP.Net/Ajax controls from vendors is so that we DO NOT HAVE to write HTML/CSS. We are application developers, not web designers. We expect the third party controls we use to emit the necessary HTML/JS/CSS on the fly so that we do not have to worry about that.This keeps our code focused on solving the business problems, rather than fighting against browser compatibility issues.

In an ideal world, I want to 'draw' my interface using the toolbox in VS2010 onto the design (not markup) surface. I want to use smart tags and the property grid to configure it. I want to click into the code behind (C#/VB), NOT markup (HTML/CSS), and write my business logic, then I want to compile and run it and have it open up inside a browser, and work on all browsers. I do not want to have to deal with ANY markup.

Consider the analogy of winforms, or even early SunView (the notifier), or PerQ, or any other highly productive graphical development tool: The developer draws the interface, sets properties and writes code to make it come to life. The programmer did not have to write native Win32 or Unix etc.. low level API's. The toolkit controls did that for him 90% of the time. If he wanted to he could call the native API, but it was not essential. Therefore when I use your controls, I want you to do the HTML/CSS/Browser (in)compatibility thing, not me.

So, what are we building? Aha, that's top secret, but we'll let you know on this blog first with the first screen shots in March 2012.

Stay tuned.


Add comment

  Country flag
  • Comment
  • Preview