Graduating from desktop to online presence

Hi abousetta,

Quite a lot to go at here, so I'll start with the easy stuff

Vbscript is dead as far as the web is concerned and it only runs in internet explorer natively - so it's going to be JavaScript for the client side.
Similarly (ASP distinguishable from ASP.NET) is also dead, it will still run, but it isn't a path you want to go down - it's a very old technology and very much out of date. ASP.NET is different entirely, it's what MS replaced ASP with and it's like the transition from VB6 to VB.NET, the only thing they have in common is the name and is the name given to the ms web platform - it isn't really a language, it's a platform designed for use with VB.NET and C#.

In terms of choice of language it's really personal preference and horses for courses - you'd have to forget about Excel altogether, it doesn't work on the web in any way shape or form. You'd design your application from the ground up in the language of your choice, the easiest languages to get started in are probably PHP, Python and either C# or VB.NET - each have their pros and cons:

• PHP is just the language, just like c# or VB so you'd usually have a web framework around it. something like CakePHP, CodeIgnighter or Yii - Pretty much any webhost in the world will support PHP
• Like PHP, Python is just a language and you'll find that the general framework to use is django - Python hosting is less common that PHP, but you can still find hosts
• MS hosting (C#,VB) is probably the most expensive, since the webservers usually need windows installed and run MSSQL server which webhosts have to pay for (PHP and Python are free, run on Linux and generally use opensource databases like MySQL)

Without knowing more about your application, it's difficult to be more specific, but suffice to say, if you can do it in Excel, you can do it in any of those!

The major difference between how local applications work and websites/applications is that they are divided into 2. You have server side code and logic and client-side, server code runs on your web server, client code runs in the browser of the person using the website, so you generally separate your logic, of the tasks above, in all likelihood you would split them like this:
Server
1) Opening and creating text files

2) Creating and manipulating string variables

3) Creating and manipulating arrays

4) Creating and using Objects including "MSXML2.DOMDocument", "MSXML2.XMLHTTP", "Scripting.FileSystemObject", "Scripting.Dictionary" - This probably isn't necessary, it's unlikely that you'd use these type of things in your code directly

Client Once the page has loaded, the server can't change it, you need client code for this - therefore any dynamic changes need to be done via javascript
5) Generating Messagebox -

6) Generating and updating a progress bar - this is likely to be the most painful bit

To explain the above distinction a little more clearly, you need to understand a bit about how websites work (the following is an vast over simplification, but is generally true and makes things a bit easier to understand):

When send a web request (like clicking a link, or typing an address into your browser), you open a connection to the web server, send the message and it usually responds with a load of text (what text to send back is usually by your programming language), the connection then closes - the browser then looks at this text and renders it on the screen, this text is usually html. All a webserver does is take an inbound request and send something back, whether it be text, images, binary files etc. (this is why it's usually possible to webscrape in Excel without using IE, you just replicate the request that IE sends and it returns the same text that it would to the browser normally)

As there is no "always" active connection to the browser, it can't communicate with the web page. Any changes that need doing after the page has loaded therefore need to be done by client side code - javascript. This code is again text sent back by the initial web request, but instead of it running on the web server, it runs in your browser instead. This means that it can respond to changes on the page as the user does things.

So therefore, things like message boxes that are displayed in response to user events have to be done in Javascript (client-side) since the server has no way of knowing what has happened in the page (it just receives text and sends responses remember) - even if you did display a message box in server code, it would be displayed on the server running the server code, not on your website.

Taking the above into account explains why updating a progress-bar is tricky (though doable), the page has no-idea how far through processing something the server is since there's no connection to it. The only way this works is by using javascript to send a message directly to the server from your page to get the progress, but this is a massive pain in the **** - that's why you usually see "spinners" when you're waiting for something to load on the web, since generally there's no way of finding out how long it's going to be - they just spin forever and are hidden when the thing they're waiting for turns up

As an aside:

Looking at how websites/applications work, you can see why local application developers are a little put off by them - they're much more complicated, you can't respond to button clicks and dropdowns in the same unified way you would in a local application - there is no concept of clicks and change etc on server side code - how could there be? All a webserver does is take a request and send back text - there's no way of it knowing when someone has clicked something when it has no notion of "controls" - it just deals in text requests.

That's why MS invented ASPX Webforms, they allow programmers who are familiar with developing for local applications to develop for the web in a deeply convoluted way of sending a request to the server each time something changes - historically this mean horrible user interface since the page was always refreshing itself, but this is getting a lot better , so if you fancy learning a bit of web stuff, webforms might be worth a look - just remember that they're different to every other web framework in the world - by a long way and aren't the norm!!!

tl;dr
You can't translate what you've done in Excel directly to the web. The medium is just too fundamentally different and you store things in databases, which are very different beasts to spreadsheets - the end result being that you'd take your existing logic (but not code) and use that to build a new application in the language of your choice.

Any way, I hope this clears stuff up a little bit for you