HTML / JS in the Shell - The new breed of Mobile apps

I wanted to use Ghost in the shell as the title, but then that would be misleading as it has nothing to do with the Japanese anime with the same name. Although Ghost is the name of a blogging platform ( which would entail a bit of HTML and JS. This article is about the new breed of applications that make extensive use of HTML and JS. These are not the apps that are websites withCSS transform to look native, but a combination of a WebView/WebBrowser and native components.

Types of applications

Broadly categorized there are three types of applications, that are either Native or a WebPage or a hybrid (combination of the two). Like binary numbers described with two digits, 01, 10 and 11.

Native Applications

This is the most common type of applications you will find for the mobile devices. These are made up of the native components and are written in a language like Objective-C, Swift, Java, VB, C#, C++ etc. Many of which require a code rewrite for a different platform. These apps are supposedly quite fast and are written specifically for the particular platform and encapsulates the features that are available on that platform. These applications can be state of the art, cutting edge with the latest technology and might not have the same features on another platform. These applications are generally run on the device and have little to no dependency on any external functionality like a website, cloud etc. The native apps are generally the ones that you download from the app store and then start the application from the home screen / launcher of your device.

Web Applications

This generally is a web application written using technologies likeASP.Net or PHP or plain static HTML. These are served off a web server and if this server is down or unreachable, the app cannot work. The advantage of this type of application is that it is like any website, it can be browsed / rendered on any device mobile, tablet or desktop that can render HTML. A lot of clients prefer this over native apps as it provides them with a larger outreach at a lower cost, when compared to writing native apps for iOS (iPhone, iPad), Android (Tablet, Mobile, Phablet), Windows Phone, Mac OSX, Linux, Windows, Raspberry Pi and the list goes on. This application is browsed via the local browser found on your device and you could save a bookmark to the launcher/home screen to launch the same later.

Hybrid Applications

This is the third type of application that is a combination of Native and Web applications. The architecture of these apps is generally a WebView/Browser that is embedded into a native application and the webview is provided with HTML/JS either from the data found locally on the device or even from a website. The most common example of apps in this category are the ones that render a login screen and work only when you are connected to the Internet. Since the entire app relies on the HTML that is rendered inside of the WebView, the native app is only responsible for supplying the HTML data to the webview. I have used this in the past for in-app help files as it is easier to create an interactive HTML document complete with Images, Styling, etc.

Advantages of Shell / Hybrid

There are a couple of issues that are associated with native apps, specially related to the Apple ecosystem in relation to application approvals, etc. One of the things that create a bit of anxiety is when an update is important AND you keep waiting for the app to be approved. If you have an app that is Hybrid, you can update your app without having to rely on Apple (unless there is some update that requires updates to the shell).

This and the fact that there is a whole lot of web developers that are comfortable with HTML in combination with one of the JavaScript frameworks makes hybrid apps more popular in comparison to native. Beginners that want to break into development who are in the school to first few year of University are not as comfortable with C, C#, Objective-C etc type of languages in comparison to technologies like HTML/PHP.

In fact the new ability that has been included with CoronaSDK to generate Desktop Applications uses a similar technique where the shell is like a stub that stores all of the resources. In fact all of the desktop apps have that same shell since there is not much to change since most of the app is run using the Lua code and the resources bundled.


This has become so popular and common, with large organisations like Adobe investing in PhoneGap and Facebook investing in technology like React-Native. There is a big shift towards HTML based UI and applications. While it does solve a problem at one end, it also creates a couple more with how it is used. My take on it has been and since the late 90's that if you can have an animated and fluid UI using HTML inside of a browser, why can you not have a similar UI for the desktop applications. HTML also allows for dynamic UI's where elements can be added, hidden on the fly and these can clip/reposition themselves where as with Native UI elements this was not easily achieved specially repositioning of elements when one was hidden. The way things are going, HTML seems to be a big influencer in the way apps are developed and the only discerning part is the numerous Javascript and related frameworks/packages that replicate vie for the same marketplace confusing a beginner.

For most of the applications that require the ability (read as "has the dependency") of an Internet connection, are developed on IIS or *AMP platforms. While in development you can run these environments on your laptop and when you deploy, most web hosting providers offer you these functionality, however with newer requirements like Node.js or a custom server created using Python or other code you are faced with issues when you want to deploy as not many traditional hosting providers offer you the ability to run scripts. So, in my opinion WHY can developers not create options that are easy to deploy and develop (my take is this is created with the sole purpose of drawing a digital divide between the developer and the rest. Take the example of MySQL that works for all platforms and is easily deployable for Desktop, Mobile and even web applications. What is required is an option similar to that for creating on-line applications and deploying them easily than tinkering with 10 different package managers just to install an option.

Some References


Popular Posts