Morfik Watch Test

Recently I was showing a friend how an application could be developed using Morfik AppsBuilder, when he was called away to look at some deployment issues with a ASP.NET application he developed. Since we were together I started to follow what he had to do to solve those issues and was amazed at how many different problems he was having.

It has been now over a week and he is still having issues with deployment. What really impressed me in this is that it is not problem that is directly related to the application he built. It is a complexity problem inherent to the Microsoft ASP.NET environment. Most of the issues he had were related to environment configuration and component dependency and versioning. He had oriented the support staff to move the application from test to production environment and the it was the differences in configuration between these two environments that caused all the issues.

Of course, a Morfik AppsBuilder application is also dependent on environment configuration, but it has far fewer dependencies than what you get with an application that has been built with Microsoft tools or even with Java. This simplicity makes Morfik-built applications ideal for scenarios where there is a small or no support staff. It also makes them a very good options for deploying to end-user desktop and notebook computers.

Recently I was contacted by a friend, who has always been a web developer, about writing a small custom desktop application. He wanted to know if I could help a friend of his that needed a small application for calculating customer bonuses for a referral program.

I asked him why he did not do it himself and he told me that the person wanted a desktop application, not a web application. He went on to tell me that he had considered the possibility of writing the application using Java but it would take him too much time to learn to do a desktop application with Java. This got me thinking because this fellow has been a Java developer for at least six years (which is to say as long as I've known him) but probably longer. I've had long discussions about this subject, with lots of people that, in one way or another, are involved with Morfik and it seems to be a consensus that it is much easier for experienced developers of desktop applications to learn to code web applications, than the other way around.

As web development diverged from traditional software development the people entering the web development camp without having done traditional development have less and less notion of how an application that is build from scratch works. Most of these people have been creatin classes that get loaded by an application server or scripts that are embedded in HTML code for all their professional lives.

When considering this case it occurred to me that Morfik AppsBuilder makes the creation of a Web-based destkop application very easy. Actually, everytime you run your Morfik application from within the IDE or debug it, you are essentially running a native windows application that happens to work as a web server.

If you compile a Morfik Web Application project as standalone you get a native windows executable that will invoke the computer's default browser when executed. This means that you can just drop a link to a Morfik application on your desktop, for example, and double click it to startup the browser accessing its start page.

This characteristic can be combined with an interface such as Mozilla's Prism project, which lets you give a browser application its own window, which will allow your web application to behave even more like a desktop application.

While Morfik AppsBuilder clearly was not meant to be a desktop application development tool, it can do a pretty good job at creating an application that will run quite efectively and look very good while doing so.

The title for this post, obviously, reflects my opinion, but it is not just a wild guess. Through the years I have worked with a lot of different web based applications, from many different vendors. I have seen a great many people start using them and watched how the process evolves.

Most people prefer to access applications through the browser, rather than using clunky desktop interfaces. Of course, not all desktop interfaces are clunky and many applications are better served by a traditional native interface. At this time I would say that office productivity tools are one of the main groups to fit in that category.

Most business applications however, can be implemented gracefully as web based applications and the use of Ajax and such techniques allows for the creation of very responsive interfaces. Recently I took part in a discussion about having web applications that mimic desktop applications or that look like websites. I consider this a matter of personal choice, but I believe that web applications should look like websites. Right now, I'm writing this article inside a browser and I am quite happy with the interface that is provided. It behaves as I expect and thought I would not want to write a book in this interface, it feels quite okay for writing a blog post.

The fact is that I have never seen a web based application that mimicked a desktop interface and that felt natural. Quite the contrary, actually. They normally feel slow and unresponsive. It might be due to the fact that you expect something that looks like a web page to have small delays in responding to your commands and when it behaves better than that it is a nice surprise, but the opposite is true for something that looks like a desktop application. If something looks like a normal windows application, you expect it to behave like one. In this case, even the slightest delay will fell odd and make the application seem to be unresponsive.

The more logic you implement on the browser side, the more responsive your application tends to be. (As long as you know what you are doing. :-) ) In building an application that will be available through the Internet, it is inevitable that there will be a slight lag anytime you need to do a round-trip to the server to obtain data. This is one of the main reasons why applications that try to simulate a regular desktop application are going to have a hard time being appreciated by end-users.