In my recent adventures as a junior programmer at a company i was introduced to a new development environment built using a framework called ExtJS. The purpose of said framework was to allow a company to build mobile applications based off of HTML5 and javascript. Specifically this framework targets two types of mobile devices; the primary one being IOS and the other being Android.
Already you may be asking yourself, why would i want to build a mobile application in this framework rather then use XCode or Android Studio (both native build environments)? I asked myself the same question when the software package was placed in my hands. When i originally started working with Sencha i was also taking classes to try and learn how to use XCode on OSX and had very little understanding of either environment. Over time i have learned a fair amount of the nuances about both these software products and have come to see the advantages of using one over another. Theses are the issues i will be discussing; starting with cross compatibility:
Cross compatibility:
Right out of the gate Sencha has the advantage here. The very concept of Sencha is to allow a app developer to easily swap between different platform builds using a combination of plugins and simple setting toggles. They have accomplished this. Android Studio and XCode both use their own proprietary setups that are not intended to be cross compatible as XCode (Apple) does not make plugins for Android and vice-versa. The fundamental concept though is that Sencha only has a serious advantage is starting from scratch.
In our case the IOS app was complete, and we only really needed an Android variant. This rendered the primary Sencha advantage obsolete and added complexity of not using native environment options directly (extra settings). Additionally we later learned that for $30,000 we could get a converter software for converting objective-c into Android APK, which when compared to the salary of a programmer was a bargain.
Advantage: Sencha (only from scratch)
Ease of use:
This issue became a fundamental problem for Sencha as time went on. The more complex your app became the more difficult it became to fix/enhance. The framework did not allow for creating sub-folders for views. This created an issue once the amount of views/models/stores we had exceeded 30 as it was very difficult to locate the code you wanted. On top of this issue there were no 'real' custom controls. I use the word 'real' loosely as you could technically override HTML placement; but, this tended to lead to other formatting issues later as you would have to push existing functionality out of the way rather then remove it. This created extra overhead on load and caused weird CSS shifts. In XCode, the programmer could easily make custom cells that could contain custom constraints and easily be manipulated into menus and lists. Additionally Sencha lacked basic controls like navigation controller (which had to be programmed by hand). This added unnecessary complexity considering the commonness of use. Looking at Android Studio, they to had this sort of controller functionality.
Advantage: Native (no contest)
Reliability:
This is the crux of the matter. Sencha's upgrade ability is basically abysmal. When we tried adding another developer to the project, we were forced to upgrade to the newest version of the software because the existing software had been 'improved'. This transition forced us to move from Sencha Touch 2.3.1 to version 2.4.1 which were primarily feature enhancements. This process completely and utterly destroyed the build. Code that had been proven to work on version 2.3 now was unable to compile properly as the update had apparently misplaced bootstrap configurations and resource management files had been spread to the wind. Additionally since Sencha compiler is a set of different frameworks it kept multiple versions of the same files, making it very difficult to know who the culprit broken files were. In XCode and Android Studio i simply updated my IDE environment, switched to the new API Compiler i wanted, and pressed build. No mess, no issue.
Advantage: Native (no contest)
In conclusion, i have found that the supposed advantages of being able to move cross platform using a interpretive language creates more problems then it is trying to solve. Unless the application you are building is simple, a project can easily get out of hand and unmanageable. As a software development company this is an unacceptable practice as it will eventually be the reason the software is abandoned.
