Web App with Native Capabilities

Web

We have a new client who develops software for a specific niche. While developing a web application for him, we encountered very unconventional requirements. The purpose of this blog article is to share that with you.

Software Requirement

Our client has developed several DOS utilities. Just to make it clearer, they are executable files which are launched in a DOS terminal, and the program runs in the terminal. 20 years ago we used to see many programs of this kind, but these days those are quite rare. (Does any reader remember Lotus123 and Wordstar?)

The over-simplified version of the requirement from a new software is to read a spreadsheet from the disk, show the content, allow the user to make changes to it, and then download the file back to their disk. They can make a DOS based application, of course; but they want to make a web application this time, as that makes the distribution easier.

Easy-peasy, huh? The file input element <input type='file'> has existed for long. Just use that for uploading the file. The browser shows the file uploader dialog box and the user navigates to the directory of choice and picks up the file to upload, and then...

Sudden Roadblock

"Wait a minute", the client intercepts, "You cannot ask our users to navigate to the directory. They are not as much computer savvy.".
"What do you mean?"
"Well, they are comfortable only with our DOS based software and not with newer fancy applications with the newer UI gimmicks, remember? So here, if you want them to navigate through the directory structure, then that will confuse them for sure. They will not use the software then."

Ouch! The requirement to upload a file from a local directory suddenly takes a center stage. Dragging and dropping the file from the explorer is also not an option, as it just shifts users' navigation need to the explorer.

"Well... we can fix up that directory so you can hardcode it in the software if you like", they offer, "Or else, when we hand-hold them in their initial setup, we have opportunity to do any local setup for them".
They continue, "Or else, can you just launch a local program from the browser? We'll keep ready a DOS application which can do what we want."

Local setup for a web application?? Running a local executable directly??
If this is a hard requirement, then technical feasibility seemed to be melting away.

You see, they are not talking about reading/ writing to the server's hard drive. That's straightforward. Instead, they want the web application to do reading/ writing to the user's local hard drive. Well, a local application (a desktop application or a DOS-based application) can do it, but can a web application do it? Is a web application even allowed to do that directly -- without the browser's well-known upload file / download file mechanisms where the user manually chooses the file? We were not sure.

We remember the good old days when ActiveX technology enabled web applications to do that, They had to withdraw it because it was an unsafe practice. Java applets offered similar power, even with some elaborate mechanism of requiring user permissions to do that, but it still lost out in the market because of the same perception of being unsafe. Given this background, would web technology venture into the same murky waters? We didn't think so.

Typically when people move from old DOS based systems to Web based systems, it is to embrace the richer UI / working style that is associated with the web applications. In this case, the need was for a web application to do what the DOS based systems easily did, on their home pitch. Looked pretty counter-intuitive and 180 degrees opposite of the direction of progress, didn't it?

Pursuit of a Solution

However, before calling quits, we decided to do some research anyway. To our surprise, our research started unravelling that there is indeed a new Web technology that is boldly exploring these use cases again. The first ray of hope was an article on File System Access API. Then, the consolidated list of Web APIs showed us that there are a bunch of new Web APIs related to the file system that we needed to explore.

Equipped with this knowledge, the first thing we did was to go back to the client and check whether the use of experimental API is okay with them. Particularly, this showOpenFilePicker feature is supported on newer versions of Chrome and Edge browsers, but not on Firefox and Safari. The client confirmed that this is not an issue, as they expect their users to use Chrome anyway.

The rest was the development-as-usual story. We experimented with the APIs, found what works and what doesn't, and delivered to our client a solution that can work for their users.

  • It is a pure web application, so our client sees easy distribution / upgradation without going to individual users (as opposed to a native application)
  • In the initial setup they have to choose the local folders on the user's machine and allow access. That access is then stored permanently, and next time onward, the file gets directly imported and opened.

Final Words

If you are looking for one takeaway from this article, then it is that our web browsers have become a lot stronger recently, and it makes sense to be aware of the power. To understand the capabilities, explore the Web APIs.

There are various fronts on which these capabilities are blowing up. For example, a few months ago, we had used the Audio Output Devices API to create a music generation demo, entirely on a browser.

If you are specifically interested in the developments on the file system side, look up the articles by Thomas Steiner on this subject.

Credit: Image by Pexels from Pixabay