Best javascript framework for mobile apps

Comparison of 8 open source cross-platform UI JavaScript frameworks for mobile app development

What is the best javascript framework for mobile apps? For app developers, it is essential to select suitable frameworks for their cross-platform hybrid mobile app projects in an evidence-based manner. The objective of this article was to compare 8 open source cross-platform UI JavaScript frameworks for mobile app development using web technologies and to find the most suitable framework for the requirements of the reference app (a mobile- learning demo project with multimedia content).
Based on the FURPS+ model for classifying software quality attributes, a set of criteria was established for comparison and evaluation of the frameworks.
The FURPS+ model was applied to evaluate the following frameworks: Dojo Mobile, Enyo, Ionic-Framework, Jo, JQT, jQuery Mobile, Sencha Touch, and The-M-Project.
Data were collected through secondary data analysis and experiments by developing 8 “Hello World!” apps and 8 reference apps (one for each framework) developed using RAD (Rapid Application Development) method.

Note: this article is an excerpt from a study that was done in 2014.

best javascript framework for mobile appsBackground

There are already more mobile devices than people on our planet. Yet the smart mobile device market continues to expand more rapidly than that of any other computing product (Cisco VNI Mobile Forecast 2013 [online]). This shift towards mobile technologies has a huge impact on the way we do business, communicate and research (Fidelman 2012 [online]).

Smart mobile devices are typically operated by mobile operating systems (mobile OSs), that allow various applications (apps) to run, thus enhancing the functionalities of the device. Apps can be games, books, shops, etc. and are generally distributed through online application stores. Most handhelds (mobile devices) have powerful on-board computing capability, Wi-Fi, GPS, ample storage space, built- in camera, and a large screen, contributing to the development of apps that support these device features. 80% of all ‘mobile time’ is already spent in apps (SuperMonitoring 2013 [online]), a fact that stresses the importance of mobile application development.

Because of the uprising mobile device market, the number of different devices, manufacturers, and operating systems in the mobile ecosystem is significant. Currently, there are more than a dozen mobile OSs that allow apps to run in their native environment. All of these apps are developed within a native OS language. So when a company decides to develop an app, they have to target the app for a specific platform (OS). The costs and resources required to target all OSs simultaneously could be substantial.

To maintain development resources and costs within reasonable limits, tools for cross-platform development arose. Ralf-Gordon Jahns states in research2guidance that developers are not fully aware of the potential of these cross-platform tools. He estimates that “the total addressable market for multi-platform app development is worth US $ 2.4bn in 2013” (2013 [online]). All platforms have the ability to render websites in browsers. Browser-based apps are called web apps or HTML5 apps and are not physically present on the device, but can be accessed through a bookmark to a web page on the home screen. Web apps simulate the look and feel of native apps (Budiu 2013 [online]) but are actually web sites. One disadvantage of web apps is that they are limited in their functionalities because of restricted direct interaction with the underlying hardware of the device.

To overcome the disadvantages of web apps, native containers are used to wrap web apps into native apps that allow access to device capabilities. These apps, referred to as hybrid apps, can be distributed through application stores just like native apps. While the battle for market share between mobile OSs continues, hybrid app development is the future (Gok, Khanna 2013, p. 5).

Problem Statement

Various frameworks are available to aid in cross-platform app development. Most of these frameworks are, in fact, user interface JavaScript code libraries with a collection of components also known as web app toolkits. All vendors claim to be the best javascript framework for mobile apps and provide the best user experience. It is often difficult to distinguish factual information from sales talk, so they require an independent analysis to determine accuracy.

Jahns states in research2guidance that choosing the right tool for cross-platform app is a project on its own (2013 [online]). Although numerous (superficial) articles have been written about framework comparison, most of them do not make this comparison with a specific end purpose in mind. To carry out a fair comparison of frameworks, a reference app (a nonfiction project example) should be (partly) developed with different frameworks in a parallel manner in order to be able to gain a sound insight into the possibilities and limitation of the frameworks. The reference app that I developed is a simple app that contains audio, graphics and video/animation in an interactive slider.

JavaScript frameworks

This article examines and compares 8 open-source UI JavaScript frameworks to determine which of these frameworks is most suitable for (the development of) a hybrid, multimedia, mobile application that can be used as an m-education app. Native app vs web app provides background information and describes the mobile app paradigms that can be distinguished. A description of the used research method is given below.

Selecting Subjects

If we wanted to know whether framework A performs better than B, then our selection of subjects would be evident. In the app development framework ecosystem, there is a considerable amount of frameworks that differ from each other greatly. In-depth comparison of random frameworks would not be meaningful and relatively impossible. To decide which of the available frameworks should be included in this comparison, inclusion and exclusion criteria were applied. By using these criteria, a group of frameworks with a high degree of homogeneity is defined in order to allow comparison.

Inclusion Criteria

The raison d’être of cross-platform hybrid frameworks is twofold: they allow app developers to use web languages and they target multiple platforms. Therefore, the characteristics that the frameworks must share to participate in the study are that they must support web languages (HTML, CSS, JavaScript) and support multiple platforms. The frameworks must also have the ability to customize the app’s UI or to mimic the native app’s look & feel so as to create a consistent user experience (UX). To allow modification and customizations to the source code, the frameworks must be completely open-source. The frameworks must also allow the deployment of hybrid mobile apps through a co-supplied wrapper or through integration with open source software called PhoneGap / Apache Cordova.

Exclusion Criteria

The next criterion is of a practical nature: the frameworks must be freely available for testing purposes. Paid frameworks are excluded. Some vendors offer ‘drag and drop’ interfaces for their frameworks. These tools are discarded in this comparison as well.

PhoneGap is often mistakenly mentioned in CP tool comparisons. PhoneGap, owned by Adobe, is a tool that is based on the open- source Apache Cordova project that wraps apps as native applications and does not allow the creation or styling of the UI. Most frameworks incorporate PhoneGap/Apache Cordova technology into their projects to allow app deployment to application stores.

Vision Mobile has listed the top developers’ tools in each sector. The selection they made for JavaScript UI frameworks was a starting point for my own research on similar frameworks.

Evaluation Criteria and Scoring System

The frameworks are evaluated on a set of criteria that can be divided into categories which are roughly based on the FURPS+ model. FURPS (which is an acronym for “Functionality, Usability, Reliability, Performance, Supportability”) is serving as “a model for classifying software quality attributes” (Mizouni, Salah 2009, p. 347) designed by Robert Grady from Hewlett Packard. The + was later added by IBM to remind us of the following concerns: “Design requirements, Implementation requirements, Interface requirements, and Physical requirements” (Shestserau 2012 [online]). This model can be used to specify requirements to implement apps (Santo, Block 2011, p. 48). Since we are comparing software tools (frameworks) that generate new software (apps), we sometimes have to decide which perspective we choose when applying the FURPS model. The chosen perspective is stated when situations are unclear. The model described by Santo and Block will be adapted as much as possible.


All mobile devices share a number of hardware features that can be accessed by CP frameworks. In addition, manufacturers try to differentiate themselves by using specific functions that are only available on a few devices. Most shared device APIs will be evaluated. Especially relevant for the reference app is: gestures/multi-touch and heavy media handling capabilities (with sliding videos and images). Tool selection is also based on cross-platform capabilities. The end product must run smoothly on multiple platforms. It is important to reach the public at large, thus most used platforms must be supported. Minor tweaks will be necessary to make the app look best on each individual device (progressive enhancement), but the amount of changes should be minimal. Supported platforms will be evaluated. Granted rights and restrictions on the use of frameworks is an important feature to know for the developer beforehand. The type of licensing is registered. The feature set/platform support matrix is checklist-based and is acquired through vendor documentation analyses.


Usability criteria describe how easy it is for a developer to use a certain framework and how well features and concepts are explained in documentation. The success of a framework depends heavily on the quality of the accompanying documentation. Documentation consists in different forms: written docs, videos, code samples, and/or ‘kitchen sinks’. A ‘kitchen sink’ showcases all of the UI widgets offered by a framework. The type of documentation is registered in the findings (Chapter 5.5) and the quality of the overall documentation is described in the conclusions based on the experiments (Chapter 6). Built-in components aid in the development of the UI and help achieving goals as efficiently as possible. The amount and types of components such as lists, buttons, navigation bars, etc. are analyzed.


Because software in general is getting more complex and users depend on it heavily, there is a great need for predicting its behaviour in a complex operating environment (Pham 2007, p. 1). Reliability can be seen from a developer’s perspective (reliability of the framework) or the end user’s perspective (reliability of the app). Reliability of the framework can mean: does the framework crash during development or is it easy to debug? Reliability can also imply the likelihood that an open source framework will continue to exist.
Reliability aspects that emerged from the experiments, secondary data research, and tests were recorded. This is a small-scale observation and should be adjudged as such.


As described above, performance issues of web apps are a concern for many developers. These concerns are not unfounded and are confirmed by several benchmarks (Crawford 2013 [online]). It is a fact that JS is slower than native code because it less ‘close’ to the hardware, but JS and devices are getting faster by just-in-time (JIT) compilation and simplified subsets of JavaScript (bright 2013 [online]). So, a performance comparison between a hybrid/web app and a native app would not be fair at this point. What is interesting to know is which mobile framework helps optimizing the code best in order to ensure a fast responsive performance. App elements will be measured individually by testing the reference app and/or other (vendor) demo apps in a controlled testing environment. Loading time, touch responsiveness, view-transition speed/quality, and scrolling list performances will be evaluated.


The online user community is a global resource for users to get support on framework issues that they encounter. Besides the forums offered by vendors, there is a more open type of question and answer website about computer programming called Stack Overflow. Stack Overflow has almost 3 million registered users according to their own metadata and has a dedicated group for each framework. Besides the amount of downloads, users, and followers provided by the vendors’ website, the amount of questions and (relevant) answers of Stack Overflow users give a good indication of how likely it will be to get support from other users when you run into ‘problems’. Data triangulation was used to determine the consistency of the Stack Overflow data by collecting data from Softpedia (software download website) and GitHub (software project hosting website).

The popularity of a framework is also an Indicator of long-term feasibility.
Another aspect of support is user-assistance provided by the vendor itself via a forum and/or on a paid basis. Commercial support possibilities by the vendor (or member companies) will be examined. Although the app development industry is highly volatile and most documentation is published online, the amount of published books on a certain framework does certainly say something about its relevance. The amount of published books on the topic is researched in the most popular online bookstores.

One purpose of mobile frameworks is to speed up developing time by reducing the developer’s workload. So, a framework should not only be easy to setup but also work intuitively and smoothly without the need for installing a lot of external libraries. The tool complexity is measured in controlled experiments during the development of the reference app, by timing the setup of a ‘Hello world!’ application and documenting complications. The overall tool complexity is described in Conclusions (chapter 6).

Design Restrictions

The success of an app depends for a great deal on its user experience. Rich UI tools should be incorporated into the framework. The ability in which the UI can be transformed into a look and feel that mimics its platform UX is measured. This is often calculated in the amount of available themes. A framework should also offer a custom theme that has the ability to match a certain (corporate) identity that is not depending on its OS. The overall impression of the UI elements is rated on a scale of 1 to 3 (3 indicates best). The findings will be partly subjective because the quality of the design elements will be judged by one developer / designer.

Implementation Requirements

Implementation requirements refer to considerations for implementation. This involves software and hardware requirements, construction of the framework (architecture and programming language focus) and possible external items a framework must interact with. The three architectural patterns can be: “MVP (Model- View-Controller), MVP (Model-View-Presenter), and MVVM (Model- View-ViewModel)” (Osmani 2012 p. 137). It is important to know if the architecture fits the developer’s skills. The information will be acquired through vendor documentation analyses and web searches.

Physical Constraints

The physical constraints refer to the actual size of the frameworks SDK and the footprint the framework has inside the app after minimization / optimization scripts are run. The size of the footprint relates to download time and can relate to speed performances.

Interface Requirements

Interface requirements describe external elements the framework interacts with. As described in chapter 2, some frameworks do not have a built-in wrapper tool, but make use of a third-party software component such as PhoneGap/Apache Cordova. The frameworks will be analyzed to find out about the way they deploy apps (third-party or built-in) and whether they make use of other/more third-party components.

“Many research methods in the areas of cognitive science have proven to be useful to web user interface design” (Ratner 2013, p. 149). An example of such a method is the experiment. Controlled experiments will be carried out to manipulate variables to evaluate and compare the results. They are controlled in a sense that variables such as the hardware, tested mobile devices, the emulator, and the developer will be constant, while other variables (different frameworks) will be the independent variable. The experiments examine differences in the product aspects and process aspects. Product aspects represent characteristics such as framework footprint and performance. The process aspects represent characteristics of the development process such as tool complexity, usability and reliability of a framework (Boehm et al 2005, p. 247). The performance test will be done on an iPhone5, iPad2 (both iOS7), and Samsung Galaxy Tab3 (Android 4.0). There will be no other background services running during the test. Demo apps (supplied by the framework vendor) or/and partial reference apps will be tested to evaluate the performance parameters (loading time, touch responsiveness, view-transition, and scrollable list performance).

Evaluation Approaches

A weight will be assigned to the criteria in order to decide their value for the reference app. Research2Guidens did a survey among more than 1000 app developers in 2013 and rated the driving decisions for CP tools. The top five mentioned reasons, besides the costs, are:

• Supported platforms
• Development time and cost • Performance
• Time and effort to learn
• Accessible device APIs

This list of importance (Research2Guidence 2013, p. 55) will be taken into account. The remaining criteria will be weighted equally.

Researching Frameworks

Vendor Documentation Analyses

Thirty-five frameworks have been investigated in search for a shortlist of homogeneous frameworks that could be suitable for the development of the reference app. A complete list of considered frameworks are listed in appendix A. The final shortlist contains the JavaScript UI frameworks listed by Vision Mobile (Vision Mobile 2013 [online]) with the exception of Kendo UI and Zepto.js. Kendo UI was excluded from the study because it does not meet the “freely available” criterion. Zepto.js is a minimalist JS library, which can be used as a substitute for jQuery. The Zepto.js library was used in the JQTouch framework experiment. It is not a complete UI framework and is therefore excluded from the study. Ionic-framework however, is added to the selection, which is a newcomer that does meet the set criteria. The list of frameworks that is further investigated and compared are: Dojo Mobile, Enyo, ionic-framework, Jo, jQT – (jQuery Touch), jQuery Mobile, Sencha Touch, and The-M-Project.

Most of the functionality/usability/supportability parameters and the implementation/interface requirements as described in the FURPS+ model in chapter 3.3 are abstracted from vendors’ documentation. Unfortunately, not all vendors supply their products with clear (easy to find) and complete specifications. Occasionally, information had to be interpreted.

Supportability Parameters

The activity of the user community on Stack Overflow is an indicator of the chance of getting support from fellow users (described in 3.3.5). Stack Exchange (the parent company of Stack Overflow) provides us with querying capabilities to determine the total amount of questions, the amount of acceptable answers (that were marked as interesting by at least one person), and the average amount of reactions to questions (Stack Exchange 2014 [online]). The query of figure 2 was used for data retrieval. Some frameworks have somewhat unlikely tag names in Stack Overflow (e.g. the tag name for Sencha Touch can be Sencha-touch-2 or Sencha-touch-2.1 etc.). The search words combine all tags containing the keywords. e.g. questions about “jqt” and its old framework name ‘jqtouch’ are all combined because of the “LIKE” operator and the use of wildcards.

Another supportability parameter is the amount of published books on a particular framework. Title searches have been done in the “Computer & Technology” section of the largest online bookstores: Amazon and Barnes & Noble. An essential condition was that the framework name had to be in the title of the book. A complete list of titles can be found in appendix B.


Experiments Environment

The ADE (Application Development Environment) describes the hardware/software and the computing resources required for developing, deploying, and testing the reference app.
The used hardware for the reference app development was a MacBookPro 9,2 (IntelCore i5, 2,5GHz, 8GB memory) running OS X 10.9.1 as a development platform. The JavaScript Console of Google Chrome was used to debug the apps. Ripple (a Google Chrome plug- in) was used as an emulator to emulate different devices before deploying the app to real devices. An Apache web server with Xampp was set up to test the apps locally. AptanaStudio 3 was used as an IDE. Besides the hardware and software, there are some online services required to be able to deploy the apps. An Apple development certificate was obtained to be able to deploy apps for iOS. A GitHub account was created for public software project hosting. A repository of GitHub was used to pull the app into another web service called PhoneGap Build. PhoneGap adds a cloud build service to the Apache Cordova project that allows building the app in the web without having to install local SDK’s such as Xcode (for iOS) or the Android SDK and make it a hybrid app (Harwani 2013, p. 77). Cordova is an open source community driven framework of code. PhoneGap is built on top of this framework.

Experiment Constraints

As described in chapter 3.4, one of the aims of the experiments was to establish the difficulty of mastering the frameworks and the complexity of developing the reference app with them (if at all possible). All of the projects started with a ‘Hello world!’ application as a skeleton to build upon. The time it took to download and install the SDK, read instructions, check requirements, and set up a basic project was measured. The complexity of the development of the reference app is described and the progress of the reference app is shown graphically. According to the RAD method, time constraints were set on the experiments. A maximum of 20 hours was devoted to each framework. The code complexity is illustrated by code snippets (in the appendices). If, during the experiments, a certain framework turned out to be unsuitable for the development of the reference app, the experiment was aborted.

Experiment 1: Dojo Mobile

The basic “Hello World!” app, FlickrView as Dojo calls it, was set up in minutes. Dojo uses a traditional script statement to include the basic Dojo codebase. A theme was dynamically loaded, depending on the OS, through another inclusion script (deviceTheme.js). The Dojo HTML tags are analyzed (by a “parser”) and defined by the CSS in the theme. Declarative markup provides a mobile look-and-feel. A loader plug-in, called domReady, is required to make sure that functions do not run before the DOM (Document Object Model) is ready (until all HTML is received). Dojo offers a Carousel widget with two optional sub classes for data store support (DataCarousel and StoreCarousel). It loads the content of the carrousel dynamically in an efficient way (only previous, next and current item at a time). Constructer parameters were used to implement the desired carrousel. The FixedSplitter was used to divide the screen in 2 vertical panes.

A new theme was derived from the custom theme, which is a generic grey theme that contains variables (e.g. @lightColor and @darkColor) that can easily be changed. The adjusted theme had to be compiled by a script for usage. A build profile was used to automatically detect dependencies in order to create optimized and minified files.

There were some difficulties in styling the carousel: a page indicator on top of the screen was difficult to customize, a poster image that covers the video on loading was not clickable, which makes is not work intuitively. The build tool for the creation of optimized builds was complex and poorly documented. The panels were not responsive (failed to adjust to screen sizes).

The Dojo Foundation developed Dojo Mobile as an “HTML5 mobile JavaScript framework that enables rapid development of mobile web applications with a native look and feel” in 2004 (2013 [online]).

Dojo Mobile is a very complete framework. Unlike jQuery Mobile, Dojo does not make use of community-driven plug-ins so as to prevent varying usage and distribution licenses.
When using the Dojo framework, it is still possible to develop the application in different ways (declaratively or programmatically). This freedom of choice can be attractive to developers.

Dojo mobile is a modular framework that supports AMD (Asynchronous Module Definition), which dynamically pulls in only the resources required (using Dojo.require). This keeps code modular and maintainable and improves speed performance.

Dojo’s website structure and documentation were unclear to me. For example, it was hard to find the proper “Getting started” guide and a PhoneGap interface guide. The overall design of the framework was not appealing to me. Because this framework was very time- consuming the reference app developed with Dojo lacks proper “make-up”.

Experiment 2: Enyo

The getting started guide provides instruction on how to layout a proper file/folder structure for pre-deployment optimization and how plug-ins are being loaded into the package.js file. This package file lists the dependencies of the app.

The reference app project started with a bootplate template, which contains a complete starter package including most used libraries, the Enyo core, and a deployment script.

The carousel consists of enyo.Panels that uses enyo.CarouselArranger as its arrangerKind. The carousel dynamically loads instances of enyo.ImageView when requested, creating a gallery (carousel) of panels.

The deploy script /tools/ generates a folder (called build) that contains two compressed JS (app.js and enyo.js) files and two CSS files (app.css and enyo.css). These files, combined with the assets and the index.html file, are the deployment files that can be pushed to PhoneGap build or hosted online as a web app.

Getting the carousel to work was very time consuming because of lacking good documentation. Although the images slide well, the video component did not work properly for example. This experiment failed for the most part.

The Enyo development team developed “a framework for building native-quality HTML5 apps that run everywhere”. It was initially developed by Palm in 2008 (Enyo 2014 [online]), which was later acquired by Hewlett Packard. It was originally based on the code that powered HP webOS 3.0 for the HP TouchPad device (StackOverflow 2014 [online]). In 2012 Enyo 2 was rewritten from the ground up.

Enyo is the only true cross-platform framework in this study. Not only does it support all major mobile platforms, but also PCs and TVs. Enyo uses JavaScript to construct its UI and provides a layer on top of it that makes it easier to express objects such as inheritance and encapsulation (Sutton 2013, p. 9). However, it is still difficult to use.

This framework was not suitable for the development of the reference app. There was not enough comprehensible documentation in relation to the code complexity. For this reason, this experiment resulted in an incomplete reference app.

Experiment 3: Ionic-Framework

After the installation of Node.js for building command line utilities, and the Cordova/Ionic command line tools, a project template was fetched from the command line: $ ionic start myApp sidemenu. The result of this tutorial was a modern looking app that was built in minutes.

The starter project has a file structure that contains an index file, which loads Ionic, Angular, CSS, and a navigation system. The navigation system loads the content from external templates. The starter project also contains a list API out of the box.

A slide box API was used as a container for swiping between panels. The List View (ion-list) consists of a list class and an item class that can contain any HTML element. They have lots of options and events that can be easily configured.

To customize the design, Sass files were included into the project.

The build process is fairly straightforward. In the command line, ionic has to be told which platforms it should enable: $ ionic platform ios (or Android). It is important that Xcode (the iOS SDK) is installed correctly (that was not the case in my situation). A few files must be removed from the project (index.html, the app folder, and app.css) after the build. Finally some configuration changes had to be made in the confix.xml.

Max Lynch, Adam Bradley, and Ben J. Sperry from Drifty developed the Ionic “front-end framework for developing hybrid mobile apps with HTML5” in 2013 (Lynch, Bradley 2013 [online]).
It is actually a framework built on top of AngularJS (a popular open- source framework maintained by Google). Ionic plans to support more framework back-ends in the future, but the UI components will remain the same. Although community support is not mature, the activity on StackOverflow was increasing during this study. Because it is in beta version, PhoneGap/Cordova plug-ins and Windows Phone support are not released yet, but that is just a matter of time, according to Ionic employees. Ionic has a compelling look and feel. It is very easy to build the UI because of the custom tag attributes that are very well documented. This framework was found suitable for developing the reference app.

Experiment 4: Jo

Jo needs an index file that includes the Jo library, a theme, and an application file (hello.js). The supplied code for the index file refers to the Jo library that did not exist in the download (core/_jo.js did not work either). A previous stable version 0.4.1 (uploaded 3 years ago) did work however.

Packaging was easy: running the command $ ./build within the app folder minified the package.

This experiment was broken off due to lacking documentation and support.

Dave Balmer, Jr. developed Jo as a lightweight JavaScript framework for HTML5 apps in 2010 (Balmer 2013 [online]). It has one of the smallest footprints of all the frameworks tested and has a simple data layer. Although the last version (0.5) was released late 2013, this framework currently does not get a lot of attention. There is no user community to seek help from and no books about Jo have been published. This framework was found unsuitable for developing the reference app.

Experiment 5: JQT

The “Hello World!” app does not have any functionality. It loads the themes and includes the Zepto library. JQT provides the developer with a choice between the jQuery library and the Zepto library. Zepto is recommended though because of its smaller footprint.

Div id elements represent different pages. So a reference to another page is actually a reference to an id within the same document. Only the first div or the one that is marked as “Current” is visible as a panel. The rest is hidden until they are ‘called’.

There is no carousel component available in JQT so that functionality has to be created in JS. With some help of other users on Stack Overflow, a carousel script was developed (which does not hold up when scaled). Making a list is fairly easy in JQT.

A theme was copied in the theme folder, overriding some of the colour variables. The new theme had to be compiled using Compass.

Interesting to mention is that the JQT web app opens in full screen without a visual browser environment. So is looks native.

David Kaneda developed JQT, formally known as JQTouch, as “a Zepto/jQuery plug-in for mobile web development” (Kaneda 2013 [online]) in 2010. Jonathan Stark currently maintains the framework. JQT allows developers to choose between the Zepto library and jQuery although it recommends Zepto because of the smaller footprint. It has a catalogue of CSS3 animations that can be applied by setting a class on a link, which runs very smooth. The CSS is easy to customize using Sass and Compass. It tries to emulate the iOS platforms as much as possible. Some of the animations do not work on Android and tablets, so it has its focus on the iPhone. JQT is easy to use and to setup. It provides a fairly good UX. Documentation is incomplete, but it is easy to get help from the user community. This framework was found not suitable for the development of the reference app, due to limited device support and performance.

The jQuery team developed JQuery Mobile as a touch-optimized web framework in 2009 (The jQuery Foundation 2014 [online]).

According to the StackOverflow and GitHub activity and the amount of published books on jQuery Mobile, it is the most commonly used framework.
It encourages a unique UI style for each app and facilitates this ability by offering a tool (ThemeRoller) to easily customize the look and feel of an app. The large amount of available code examples and third party plug-ins provided by the user community, as well as the ease of use of this framework make it very suitable for the development of the reference app.

Experiment 6: jQuery Mobile

In the “Hello World!” index file, a viewport tag is placed in the <head> section that sets the screen width to the device width. A theme is linked and two libraries are being loaded. The page is defined by data- role=”page”, which contains a header, a content block, and a footer. In the content block a listview was created with a client side data-filter, a slider, and a button.

jQuery does not have a built-in carousel function. A third-party plug-in called OWL-carousel was used, which is a touch enabled and responsive carousel that was easy to configure and install.

The appearance of widgets was easy changed by adding an attribute like data-theme=”a” (from a to e). A complete new theme could easily be developed using the ThemeRoller website. Once done, the new theme can be downloaded and linked in your index page (very easy).

The jQuery Mobile custom builder was used to generate a compressed JS file that only contains used components. This process was a bit time-consuming because every used component had to be identified.

The jQuery team developed JQuery Mobile as a touch-optimized web framework in 2009 (The jQuery Foundation 2014 [online]).

According to the StackOverflow and GitHub activity and the amount of published books on jQuery Mobile, it is the most commonly used framework.
It encourages a unique UI style for each app and facilitates this ability by offering a tool (ThemeRoller) to easily customize the look and feel of an app. The large amount of available code examples and third party plug-ins provided by the user community, as well as the ease of use of this framework make it very suitable for the development of the reference app.

Experiment 7: Sencha Touch

The “Hello World!” app was generated from the command line: $ sencha -sdk /path/to/touch generate app MyApp.

The carousel component contains multiple full screen swipeable pages. The orientation can be either horizontally or vertically. They were relatively easy to configure and can contain all kinds of content. In this app, the carousel exists of a Vbox (a vertical box with a flex configuration) that contains an image, background image and a video component with several controls. Indicator dots automatically show the available screens to swipe through.

Sencha Touch interacts very well with PhoneGap. Building the app was done in 2 simple commands within the app folder: $ sencha phonegap init and $ sencha app build –run nativecom.sencha.test. The generated files were placed in a repository and fetched to PhoneGap Build.

The app was not full screen in IOS7 although full screen was set to “true”. It turns out that Sencha Touch did not support the new iOS full screen views yet. A few lines of code in the app.js file (Russell 2013 [online]) and a new startup image with the iPhone5 (640×1136) resolution solved this issue.

Although Sencha Touch is considered to be a complex framework, the documentation is complete and thorough. Every time difficulties arose, documentation or tutorials guided me in the right direction.

Sencha Inc developed Sencha Touch as a “high-performance HTML5 mobile application framework” (Sencha Inc. 2014 [online]) in 2010.

It is a widely used framework with the best documentation of all of the frameworks tested. It focuses on hybrid app development; therefore, it has little browser support and offers 3 different ways to wrap up your apps. The UI can only be developed in JS, which makes it more difficult to learn than for example jQuery Mobile, but the results are very good on all devices. Sencha also provides a commercial tool, called Sencha Architect, which allows building apps visually. Sencha Touch is the only framework in this study that has a different licensing approach. It has either a commercial license option or an open source GNU GPL license option. This is something to look in to, when developing a commercial app. It was not an issue for the development of the reference app.

Experiment 8: The-M-Project

The getting started manual was not up to date. They recently switched to a new building tool called “yo m” which is based on grunt (the previous builder was called espresso). This had to be installed first: sudo npm install -g grunt-cli
There were some errors during Grunt installation that took a lot of time. The following command created a MVC structured boilerplate project: yo m.

I run immediately into problems and I did not find good documentation that could help me any further.

M-Way Solutions developed The-M-Project as a native-looking framework based on Backbone.js in 2011 (M-Way Solutions GmbH 2013).

It was time-consuming to install the framework because of many dependencies and the outdated “Getting started” guide (they recently switched to another system for their build, optimize, package and deploy tools). Although their website and their specifications looked promising, I think, at this moment, this framework is not mature enough to be utilized for projects like the development of the reference app. For example, the amount of code generated for the index file was tremendous. Maybe Backbone users have a flying start but I found it an unworkable framework.

Framework Conclusions

Although each criterion can be examined on its own, a more general comprehensive conclusion about each framework is formulated in this chapter. As discussed in chapter 3.5, extra weight will be attributed to the following categories: supported platforms, development time, performance, time and effort to learn, and accessible device APIs, because they are considered to be more important according to the Research2Guidance survey (2013, p. 55). The binary data of supported platforms and accessible device APIs are both part of the functionality characteristics of the FURPS+ model. Therefore, this section will be weighted double. P (performance) of the FURPS+ will also be weighted double. The development time and effort to learn a framework are strongly related to the criteria that were covered in the supportability section. This section will also be weighted double.

Since the reliability characteristics can be interpreted in several ways (continuity and stability of the framework or stability of the app) and the experiment is done only once, with limited functionalities, there is no weight assigned to this section. The most remarkable findings concerning reliability are documented in the findings.

MIT, BSD, Apache, and academic free licensing grant similar rights, are very flexible, and are compatible with almost every free form of open source licensing (Laurent 2004 p. 14). Apps developed under the GPL (General Public License) have to be made available, under the same license, to the developer community (Laurent 2004 p. 82). All licences are weighted equally in this study, except for the GPL license (Sencha Touch only). GPL might not be suitable for every project.

The platform support will be expressed in total market share 45 percentages based on IDCs research (2014 [online]).
The framework footprint described in the physical constraints section is interesting, but is less important because of the increasing download speed of 4G available to the mobile user (Rogerson 2014 [online]). Although app size can relate to performance speed, it is the perception of responsiveness that counts and this is already weighed in the performance section. SDK size is not a limiting factor for users. Therefore, the physical constraints are not valued.

So what is the best javascript framework for mobile apps? Final Conclusions

To compare the 8 different open-source JavaScript UI frameworks I used the FURPS+ model (RQ-4). The FURPS+ categories were rated on a scale of 1 to 10 (10 indicates best). Rating was based on the findings of the experiments, where reference apps were developed following the RAD method (RQ-7), secondary research, and app evaluation. Extra weight has been assigned to categories that are considered most important by app developers. The 8 frameworks were selected from a large list of available frameworks (Appendix A) by using inclusion and exclusion criteria in order to form a homogeneous collection of frameworks (RQ-2). The included frameworks were: Dojo Mobile, Enyo, Ionic-Framework, Jo, jQT, jQuery Mobile, Sencha Touch, and The-M-Project (RQ-3).

Keep in mind that this study focuses not only on the requirements of the reference app, but also on which framework features are considered most important by developers. Although the ratings of the FURPS+ elements and the suitability requirements of the reference app have a large overlap, they are two distinct entities. Since the requirements of the reference app and the framework features most valued by developers are almost identical (except for the hardware support, which the reference app only required for touch/swipe support), the resulted ratings of these two entities are next to equal.

As described in chapter 4.2.1, the reference app I was aiming for should be of a high performance and working on at least iOS and Android. It should include a carousel containing swipeable panels displaying an image and audio/video in a vertical box setting, an alphabetically ordered (JSON data) list with a master/detail structure, an info screen, and a welcome screen.

The most suitable framework for the development of the reference app, as well as the best framework according to the FURPS+ model, turned out to be Sencha Touch (RQ-1). Although Sencha Touch is not one of the easiest frameworks to come to grips with, it generates high-performance apps, has excellent documentation and has a large community support. It is worth the effort.

Second best is jQuery Mobile, both in fulfilling the requirements of the reference app as according to the FURPS+ model. The essential difference between Sencha Touch and jQuery Mobile is that jQuery uses tag attributes (HTML/CSS) for the creation of the UI, whereas Sencha Touch uses solely JavaScript for its UI. A practical advantage of jQuery is that there are numerous third-party plug-ins available for the framework, which can speed up development time (RQ-5).

The third most suitable framework for the development of the reference app is Ionic-framework. According to the FURPS+ model this framework came in fourth (and behind Dojo Mobile). However, I found this framework easier to use and better looking by default compared to Dojo Mobile. Since it is a newcomer, I have high expectations of this framework for the future.

javascript framework comparisonRecommendations

Which framework is most suitable as a cross-platform framework for a certain app, depends largely on the app’s functional requirements, the platform support it requires, and the developer’s skills.

If a future app requires a framework that is truly cross-platform (including TV), allows development of fast-performing apps in pure JavaScript without the help of community developers and that does not require a native look-and-feel or out-of-the-box device capabilities, than Enyo is something to look in to. In every other scenario, I would not recommend this framework.

Although Ionic-Framework was not designed for web apps and therefore has limited device and browser support, this framework is one of my favourites because it looks stunning and is easy to set up and work with. Its performance is great on all tested devices. Because it is the youngest of the frameworks in this study, I have high expectations of this framework for the future, especially when the user community and API support continue to grow.

Because of the incomplete documentation and the absent user community, I would not recommend Jo or The-M-Project frameworks.

While both Sencha Touch and JQT are from Sencha Labs, they serve different purposes. JQT is based on jQuery or Zepto, stimulates progressive enhancement (i.e. to optimize the UI for individual devices) and is used for smaller projects not requiring large platform/device/component support. Sencha Touch goes a step further and was designed for building data-centric, rich applications in JS. I would recommend JQT for smaller iPhone-focussed projects only.

Sencha Touch and Ionic-Framework have limited browser support because they focus on hybrid apps. For web apps I would recommend jQuery Mobile.

Furthermore, should the licensing of Sencha Touch be an obstacle, than jQuery Mobile is a good alternative.

Future Work

The 1990s saw a platform battle in the PC industry. Because of the multi-platform situation, a shift towards online software arose to overcome platform differences. Currently, the platform battle is being fought all over again, but this time in the mobile landscape. And again, there is a need to develop software for all platforms simultaneously. Due to the growing number of handheld devices, cross-platform tools are gaining popularity and since the Internet has proven itself, a logical consequence for developers would be to utilize web-skills for app development as well. My personal belief is that comparative studies on cross-platform tools will become increasingly important for app developers. The study I performed focused on the requirements of a hybrid multimedia/m-learning app, but of course similar studies on other types of (reference) apps (e.g. business/game) could be performed in the same manner. New platforms are arising all the time, claiming to guarantee the best user experience and fastest development. These (novel) frameworks should be investigated and compared critically.

Self-Critical Reflection

Looking back, I may have been naïve thinking that I could get to grips with 8 different frameworks, develop 8 identical non-fictional apps, perform a thorough analysis of 8 frameworks based on secondary data research, and compare and evaluate them, all in the time that stands for this thesis. Although I like to think that I came a long way, it was not feasible to create 8 completed apps, which is what I had in mind when starting this project. In the end, it was not necessary (and almost impossible) to complete all of them for the purpose of this comparative evaluative study. The goal was to get a good sense of the possibilities of the frameworks and the possible problems developers can run in to when developing an app like the reference app. This judgmental error is due to both my own inexperience with app development using mobile JS frameworks and incomplete vendor documentation. A smaller study with fewer frameworks might have been better. I assumed that web development (familiar ground) and app development were not that far apart. That assumption was proven inaccurate and I think that web developers do not always acknowledge this. There clearly is an overlap but a web developer/designer needs to undertake (a lot of) extra studying before he can call himself an app developer. To really compare frameworks, a deep understanding of the material is mandatory. Therefore, it takes a lot of reading before being able to write some words of substance. I underestimated this as well.

I hope this study contributes to the decision-making process for colleague developers who stand before the task of choosing a suitable framework for their next app development project.