Recently I have been being perplexed by the decision of using either Smart Client or ASP.net for a project that I need to set up in our company. Here are some facts about the project:
- The users of this system include intra-department personnel (which we have better control of the computers they use) and inter-department personnel (less or no control).
- The system has both simple data entry forms such as service request, and complex forms which require to use multiple attachments and multiple embedded images.
- The system also has the workflow features which can notify the corresponding parties of any updates or new assigned action items. By clicking on the link of the notification, it should bring the user directly to the form/report of the content.
- For future scalability, the system should also be able to open to personnel in different countries (more accessibility).
My initial analysis concludes that I should have two versions for the project with Smart Client as the master and the ASP.Net as a support. All forms should be available in Smart Client version, while the simple forms or reports should be available in webform version as well to benefit the users who only have web access. The update/deployment of the application should be simplified by the click-one technology.
This seems to be all good until today. I just realized the cost of using Smart Client:
- All client machines need to install .Net framework.
- All the users need to have administrator privilege of their machine.
In reality? It is very hard to achieve. Not to say the IT department would not allow us to install the framework in all the machines, and would definitely not allow all users to have the administrator’s privilege, just think we have more than 100 machines in our department, what’s the cost of installing the framework as well as the application in each machine?
So back to square one – Smart Client or ASP.Net?
Here are some reference to smart client:
Smart Client Part I
Smart Client Part II
Smart Client Part III
I have been thinking of switching my website to Community Server 2.0 for a couple of days now. The look and feel would remain the same, only the codebase would change from my source code to CS source code. I will have some migration to do, but I'm thinking it won't be a big deal.
What do I gain?
They have a slew of features in the product. You get blogging, forums, photos, themes and whole bunch of other features out of the box.
What do I lose?
Well the website in it's current form is all hand coded by me. Although I have taken ideas from a whole bunch of other projects, the coding is all mine. Since the solution I have is not complete, it gives me the oppurtunity to add more features and learn new things as I go, but then I wonder is there really any point in reinventing the wheel.
Hmmm.... this is really difficult (I am leaning towards CS), hopefully I will make up my mind in a couple of days. By the way, for anyone who really wants to learn how solid software is built needs to look at the Community Server source code. Yup, it is free to download, although they have better configurations (like ability to deploy in a web farm) that comes at a price. For the rest of us, we should be pretty happy with the free version.
If you are new to AJAX and want to know all about it, please read this wiki. I couldn't have put it in better words myself.
Now that you have at least some understanding of AJAX, let's look at what we need to be aware of. First of all for those who did not understand the above wiki, here's what it all boils down to. When you write a desktop application, you use at least one additional thread (other than the main thread). The reason you do that is, you don't want the screen to hang due to some complex computation that would eat up all the resources. It is simply bad user experience when the client cannot do anything (cannot even move the window around) because of resource intensive calculations. So what do you do? you create a new thread and do all calculations on that thread without blocking the main thread. AJAX can be thought of as threading (just an analogy, I don't mean actual threading) for the web. You create an iframe and all computations / saving of information / loading of information, you do through that iframe. To the user the screen is not refreshing / hanging up until the next screen loads. That's the basic of AJAX, better user experience. This is turning out to be a big post! so let's get to pain points. We shall leave the coding for another post.
Paint point 1: Debugging - it just is a hell to debug an AJAX application. You obviously cannot put detailed alert messages on the production server, so you have to resort to other techniques like logging of errors in the background (i.e. sending detailed messages back to the server in a background thread and storing that information in a database). Obviously this method could turn out to be very costly if you have too many error messages. Things get even more complicated even in the development environment if you have hidden frames and server side errors happen within those hidden frames.
Pain point 2: Knowing when to stop - this is just plain old experience. Obviously I could have created the feedback / post entry system of this site in AJAX, but what's the point. If my screen is fast enough or if I am not going to save a lot on the server as well as the client, why do it and go through all the pain.
Pain point 3: Training - remember that the world is used to the traditional three tier architecture where you code a bunch of server side files that spit out html code. Even if you master AJAX and write up awesome code, it is going to be very difficult for the fresh kid out of college to understand / adapt to this new world of client side (javascript) hacks.
Pain point 4: Learning curve - (Thanks Lilly) you may be a good web developer but it does not mean you are a good JavaScript developer. With all the drag and drop components that are in the market, you don't have to code a single line of JavaScript (exaggeration) and still have a decent web solution. The first step is to learn JavaScript + DHTML, this should get you ready to learn AJAX.
Pain point 5: Session timeouts - imagine your screen doing most of the stuff using AJAX and the user being idle for X hours causing the server session to time out. When the user comes back and clicks anything, the AJAX code would fail because the server time out. You need to handle all such situations.
Pain point 6: Framework - there are a lot of frameworks that are coming up in the market, but none have reached maturity yet. Which means that if you need something fancy you have to code it i.e. build your own little framework. Remember to build a framework i.e. all your AJAX code in one JavaScript. All other web pages need to talk to this framework to get any AJAX done. If you don't follow this you will have JavaScript code all over the place and it would become a nightmare to maintain it.
The biggest pain point of them all: Not every one can build an AJAX app. I don't mean to insult you in any way, but Yahoo is the best example. They have redesigned their mail application into an AJAX app. The UI looks and feels just like desktop Outlook, but the app is very resource intensive. IE takes a whopping 150 MB and the browser slowly starts to crawl after about 30 minutes of usage. I am sure the Yahoo developers will figure it out and improve it over time, after all it is still in beta, but imagine you getting into a similar situation. Debugging those leaks is going to be darn hard. Which brings another point. Browsers in particular IE have a lot of memory leaks, before you know, as the user navigates around, the browser keeps bleeding memory and eventually comes to a grinding halt.
Obviously security is a key issue and you may be susceptible to a JavaScript injection attack, just like the sql injection attack. You always need to keep security in mind as you code your stuff.
Moral of the story: The aim of this post is not to scare you away. The intention is only to educate you so that you make the right decisions before jumping into the the AJAX bandwagon. My advice, go slow (slower than when you work with any new technology). Do small things at a time and slowly evolve your framework. Eventually you will be a winner by taking one step at a time.
Today when I was typing up my Internet Explorer bug entry, I messed up so many times that I had to retype some of it. I still ended up hand editing the entry from the backend for the hyperlinks and line breaks. At that point I decided I had enough and started googling for a free web based rich textbox. Here's what I found, a real diamond FreeTextBox. It was very very simple to include it in my project and here I am typing away using FreeTextBox with all the possible formatting at my finger tips.
WOW! it works in Firefox too, and no I am not a sales person for FreeTextBox.
When I started working on this website I wanted to create a new logo (title) for it, so I cranked up Sparkle (a.k.a. Microsoft Interactive Designer) and created the above logo. Sure I could have done the same in Photoshop but I chose to learn something new and different.
Anyways the point I wanted to make was when I created the logo and saved it as png file I saw that the background color for the logo appeared totally different in IE than what I had used. Just to be sure I opened the same website in Firefox and it displayed correctly. I thought it may be a problem with png format so I saved it as gif, still the same problem. I finally gave up on it and created two different gif files and hacked up a small JavaScript code that detects the browser and displays the appropriate image. When is Microsoft going to learn to do the right thing I wonder. It's like Girish said in this post "I hate you. But I still cant live without you."
Sparkle is the a new tool just like the Flash tool that targets the upcoming Windows Presentation Foundation. What is WPF, well I think it needs a post in itself but for now you can go here and read all about it.
This is my second attempt at blogging. I had big plans when I had started this website the first time around about a year back. Today I don't want to make any promises to myself that I can't keep. I am going to use this blog to document anything new that I learn over the course of the day so I can refer back when need be.
