Converting dBase IV programs to run in the browser

Recently, my mind drifted back 35 years ago. A time when I was developing business applications in dBase for DOS and Windows was only starting to become a thing.

At the time my colleagues and I joked about business applications being developed for Windows. Imagine having to use a mouse to move around the screen and click on things instead of just using the keyboard to do everything?

Time has, of course, proven that Windows is perfectly suitable for these types of applications but my reminiscence did prompt me to look at some of my old applications and think about whether there is still a place for text-based and keyboard-oriented applications. Are they better or faster to use for certain types of business applications?

Then in a moment of insanity, I thought maybe the world might need or want a JavaScript framework for text-only, keyboard-oriented web applications.

That lead me to wonder how would my old applications would run in the browser. One way to find out: try and convert one to run in JavaScript.

So I created a HTML page with a fixed-width (monospace) font, created an element to house my 80x25 screen, and then copied across my old dBase program file to work on.

I had to strip out all the database code as this was purely a test of the user interface and any database functionality would, of course, have to be done separately on a server.

Converting dBase code to JavaScript is simple: I just had to change things the various dBase commands to the equivalent JavaScript. Like the WHILE, DO CASE and IF commands. The comparison operators = and # need some attention. String functions need to be changed. A lot of semi-colons and curly braces need to be added.

But to make the dBase code work the same I needed to write some new functions. SAY prints some text at a specific row and column so I needed a way to do this. I opted for an array of strings for each row to act as the screen memory and this would be modified by the new say function and then the screen redrawn each time it changed.

GET adds a control where data can be entered and needed some thought. I could use a HTML INPUT control or I could listen for keyboard input and write my own input control. I opted for the HTML INPUT control initially, mainly because it would be easier and quicker. So the GETs are now stored in an array and HTML controls inserted into the "screen" when the screen is redrawn.

Now dBase IV is a procedural system where code execution waits for things like data entry and keypresses before it continues, but JavaScript is more event-driven and doesn't like to wait in loops for something to happen. To make it work I needed to add async functions and promises.

I wrote a function equivalent of dBase's READ to handle form entry and added READKEY and LASTKEY equivalent functions to store the key(s) that were used to exit the form. I also converted the JavaScript key codes to the original dBase values.

Various other functions added and changes made, and here is the result:

Open in new window

It's a working application! And it actually works reasonably well except the data entry and key handling is not quite the same as dBase and has some issues. If I were to make a framework for these kind of applications I think it would be better to not use HTML controls and write my own. Or possibly embrace HTML form elements fully.

Ideally any framework would be event-driven to better work with JavaScript.

So are business applications better in a text and keyboard-orientated environment than in a GUI like Windows? If the application requires typing and you know what key does what then it can be quicker to enter data and complete a form. Typing into a normal web form with text inputs and selects can be a little slower as you alternate between keyboard and mouse, and most web forms have a button to submit the form, not a specific key, so you need to switch to the mouse or use the tab key to get to the submit button and then an extra keypress to operate the button using the keyboard.

So I can kind of see a use for a framework that is focused on quick data entry using the keyboard. I have no idea if something like this already exists but will look in to it further.