Why you DON’T want to build a web application and the only 3 times when you do

Why you DON’T want to build a web application and the only 3 times when you do

In this short video I will give you a comparison between building a web and a regular client – server application and give you the only 3 cases I think it makes sense to do a web app.

These days everything is done over the web. Web this and web that and some Web 2.0 J

So, when companies start building their IT projects, they want the latest buzz, so most will tend to build a web enabled application.

Don’t get me wrong… Of course, there are times when web application is appropriate and really makes sense but it doesn’t happen very often.

For example when I was designing a simple system that was supposed to gather cellular data and display usage reports, programmers were all for doing a large installation with web servers, application servers and so on, querying all the data in real time to get the MOST updated numbers…

Yada… yada…

Of course it all costs some pretty penny. So I started asking questions like:

How many people are going to use this system?

How many times a day?

How up to date do you want your data?

And so on…

And it appears that only two people in the whole company would look at these reports maybe a few times a day and it’s good enough for them if’s 15 minutes late.

Well now we are talking some sanity here, and YOU tell me, do YOU really think under these conditions we have to develop a web application?

I mean for two people?

So I asked them: “Do you guys know how to use Microsoft access?”

And they said: “Sure”.

Then all I did was a simple stored procedure on their database, that would run a query that prepares the data in a format that they wanted and I scheduled it to run once every 5 minutes.

That was even 3 times better then they wanted

I linked their Microsoft Access to their main SQL database and ran the reports from there.

It took me literally half a day to do.

There are a lot of drawbacks to coding a web application that client – server applications do not have.

First of all, web applications are not so easy to develop.

They require lots of server side logic, session and many other things.

And YES there are a lot of tools that help you and hide the problem behind some other code, but it is still much more work. This means your project will be longer and more expensive.

Second, web applications are harder to maintain. There are problems on both client and server side. Server has to be secured and updated which could break the backwards compatibility.

Ask me how I know this or how many times have I seen it happen.

Also updates to your app must be deployed on the server that runs 24/7 and you have to schedule some downtime or be VERY creative with your cluster architecture.

Client side incompatibility is a beast on its own. Ask any web programmer and they will tell you a whole bunch of horror stories how their app works on Firefox and breaks on Internet Explorer.

Heck it even breaks from version 6 to version 7 of Internet Explorer.

People can access your app from some weird places like Symbian mobile or TV appliance.

Developers usually give up and only support certain browsers.

They are not even completely platform independent. Firefox on PC may not work EXACTLY the same as Firefox on Mac.

If you need to support all browsers, it’s going to be a complete nightmare. You need a bunch of web programmers who can hide your compatibility problems and you should keep them all the time, because as soon as Microsoft comes out with a new version of IE, they have to fix your program in many different places and retest everything again. That’s a lot of time, money and a lot of aggravation for you.

In addition to that users can just turn JavaScript off, so you need trained support. That’s even more money out of your pocket.

Security is not that bulletproof. You must be very careful on every form, since a hacker can inject some data and pass through your security quite easily and it did happen a lot of times with web applications.

So your applications require much more testing to make sure your security is solid.

And besides let me be very frank… Unless you do not go to some programming extremes, your web app will be pretty ugly. No drag and drop or copy / paste that people are used to. Long refresh time and so on.

This means you have to plan for that in your project especially if you are doing an off the shelf product, you just cannot make it ugly these days.

This means more money and more pain for you.

You are tied to the Internet and can’t disconnect for a second, because your whole app is running on the server. This is not even feasible in many cases when you must work in standalone mode and synchronize when you come back to your HQ.

By the way, your server takes the load of all your customers connected to you all the time. Not only does it have to do the business logic, but it also has to take care of page refreshes, sessions and sending all the HTML code back and forth. Servers need more RAM more CPU and more network capacity. Your application better scale quite easily or you will have some real problems.

And besides, this creates a single point of failure. If your server crashes – you will know right away, because your phones will explode, so prepare to hire some web admin. And if your app is 24/7 you need more than one. Caching $$$… You know the drill.

Now let’s analyze your simple, run of the mill User Interface application:

I wouldn’t say it’s a breeze to develop, but it’s MUCH easier than identical web application.

In many cases client – server application has your database as the server so your integration will be done through it.

Even when you do have some server side logic, client can definitely help and make it simpler for the server.

In this case, your user interface is a matter of throwing a bunch of components on some forms and linking it all together with business logic. Regular apps are cheaper and faster to do than a web app.

They are also pretty easy to maintain. Most of the time, your server is your database and it has been tested to oblivion by millions of users before you and if you roll out an update to the database, most of the time it’s not disruptive and will not kill your main application.

Of course there is no browser incompatibility, because there is no browser J and you can tightly control the interface.

There are also many ways to make your application platform independent, like Java or Adobe air, which again is cheaper for you.

Security is not an issue, you can protect your whole program or even use a built in security from your database or one of free or paid code you can drop in to do access level permissions for you which makes you application cheaper, you can also force your users to log in to the main server periodically with username and password so that you can control hackers who may try to pirate your software. Without access to central database for a while, the software becomes obsolete in a week and you can disable or enable certain logins from your side.

Users are very comfortable with using stand alone applications and are used to standard drag and drop and copy/paste, so it will be easy and intuitive. This means wider acceptance and smaller learning curve for your users and of course less money for you to spend.

Your applications can run with or without the Internet and synchronize with the main database when you have connection to HQ. There is also a lot of code already written that does that.

There will be no stress on your server since most of the work is done on the client. If you don’t have an application server, your database will be almost idle and it can run for months without rebooting, most modern databases do. No need for cloud infrastructure, no need to hire admins. One guy that works on call is enough, so it is even cheaper for you.

Now, I don’t want you to get me wrong…

Stand alone applications do have drawbacks, but compared to the web app, they are much easier to overcome because the technology has been around for much longer so most times you have a choice of which solution to pick for each situation, but stand alone client – server apps have additional benefits, that web applications don’t have.

Since they all run in your regular environment, it is easy to integrate them with other apps. For example you can cut text from Word document and paste it into your application or just drag and drop it, whatever is easier. Most users know these basic actions intuitively and they are usually very easy to implement.

The software is also easy to update remotely. Any time your users connect to your server or the database, you can check if the version they are running is up to date and update it if it’s not.

They can access your local files without uploading, so it’s fast and does not put stress on the server and you don’t need any additional disk space to hold all your client’s files.

Isn’t this great? There are a lot of headache you can easily avoid by making a client – server application and it also gives you additional benefits you haven’t thought about.

But there are times when you have to make your application web enabled.

Mainly it happens when you are doing an off the shelf app, that will be bought and used by many different people and your architecture lends itself easily into the web format, for example you always need access to constantly updating back end. If it doesn’t, it may still be better to use a downloadable client – server application.

For example you are doing a service that allows people to upload and print their photos online or charge their credit cards online.

It is also needed when you must tightly integrate with an existing web application, so that users have a single experience unaware that different parts of your web site are serviced by different apps.

And in the case of an in – house development when you have a lot of people who will be using your application, that are not in the same place geographically, for example thousands of tellers in a bank.

It may make sense to spend extra money and concentrate your IT support and maintenance in the head office.

In the end you must weight each case. Ignore any “coolness” factor and assume you want to develop a cheaper and faster application unless you have some very compelling reasons to do a web enabled app instead.

Now you know when and why it makes sense to do a regular application and when you should do a web app. To get a lot more advice and a lot more videos like this one, visit our site and subscribe to our channel now.