Over the last five years, there has been an explosion of innovation in both web and native technologies. With the rapid release of libraries, frameworks and tools, developers now have many options to create applications for this new world. But, have design patterns and the general utility of micro-library stacks really added productive value to full-scale enterprise web development?
I’ve had the opportunity to interact directly with Sencha enterprise customers over the past several years, and I’m frequently asked how Sencha compares to alternatives in the wider web application development ecosystem. With the evolution of popular (but limited) libraries like AngularJS, Ember and others, developers today have an incredible number of tools to choose from — and often the resulting “solution” is a completely customized stack of multiple, single-purpose, third party libraries.
While these individual libraries and the resulting custom stack have the potential to do some things very well, the unfortunate reality is that a great deal of the functionality must be gathered together from disparate sources, written in-house and require a dedicated team of maintainers in order to meet the demands of enterprise software development.
To learn more, join us for our upcoming webinar.
Table of Contents
Tuesday, 10/14 at 10:00am PDT
Before you start work on your next project, ask yourself these four questions:
- How can you make your development teams more productive?
- Can you accurately estimate the development effort involved in making long-lived enterprise applications?
- Can your developers easily re-use code across the company’s complete application portfolio, regardless of the end-user device or platform?
- Can you accurately predict the long-term maintenance requirements of an application across its entire lifecycle and potential end-point delivery platforms?
Let’s address each of these questions in detail and examine why the Sencha Ext JS framework is a better choice for building enterprise web applications compared to an arbitrary stack of solutions built on top of third party libraries like AngularJS.
How can you make your development teams more productive?
Every company wants to know how they can help their employees be more productive, and this is particularly true in software development.
One of the most important benefits of HTML5 is that web developers share a common skill set — allowing them to build powerful, interactive applications in a variety of environments. But despite the fact that HTML5 is a common skill set, the reality is that fragmentation exists across the popular libraries and tooling, and it’s difficult to train developers consistently.
Consider the matrix shown above, which contains all of the different features an enterprise application will likely need. Most popular application libraries, like AngularJS, only implement a small subset of these features — meaning the developer (and by proxy, the enterprise) becomes responsible for pulling together an array of third party software components (and their dependencies) to cover the missing features, unless these features are developed and maintained in-house.
With this approach, it’s also important to consider that each of these third party libraries is independently distributed, each with their own release cycles and “best practices.” Combining many disparate libraries into a single highly-customized application stack often highlights the lack of integration for individual features across the stack, and documentation is also usually incomplete because no two application stacks are exactly the same.
Clearly the challenges companies face with this approach involve:
- Adequately training their developers across all of the moving pieces
- Testing the latest releases of all third party dependencies against many internal applications
- Finding enterprise-level support
This “Rube Goldberg” approach will adversely affect productivity over time, and usually sooner rather than later. The overall efficiency of the development and IT organizations suffers because large development teams are frequently split into two areas of focus: the team doing the updating, documentation and maintenance of the internal custom framework and then the team doing the actual application development that matters to customers or end users.
By contrast, the Sencha Ext JS framework contains nearly all of the features in the matrix. These features are fully integrated across Ext JS, helping your developers design, develop and deploy applications consistently. Our world-class dedicated Training, Support and Professional Services teams also ensure that your organization can get the training and support when needed, giving them the additional resources they need to stay focused and on schedule.
Can you accurately estimate the development effort involved in making long-lived enterprise applications?
It’s no secret that the most common cause of runaway software projects and budgets is poor estimation. A large part of this problem is poorly defined scope, but IT managers also frequently neglect to look at the tools being used to write the software.
No software library or tool is perfect, and it’s certainly unrealistic to expect anyone to know 100% of the tools being used. When you apply that fact across all of the dependencies a project might require, you can easily see how complicated the project estimation matrix becomes.
By applying some simple mathematical formulas, you begin to understand the real-world consequences of having too many dependencies. Assuming every dependency has a 90% reliability factor, and if we treat these dependencies as existing in series, all you need to do is multiply by the number of factors to visualize the overall reliability of the architecture:
(Dependency A = 0.9) x (Dependency B = 0.9) = 0.81 //or 0.9^2 (Dependency A = 0.9) x (Dependency B = 0.9) x (Dependency C = 0.9) = 0.729 //or 0.9^3
Although 90% is an average (and perhaps a somewhat arbitrary) metric, the mathematical premise remains intact. You can clearly see how adding more dependencies reduces a system’s reliability exponentially — and that reduction in reliability will translate into problems like delays in delivering features, additional maintenance and testing time, or the need to allocate additional development resources. This directly leads to increased costs and a whole lot of “attention and help” from senior management — something most developers don’t enjoy.
When choosing to build your own framework with AngularJS, your team immediately assumes a number of external dependencies. The customized application stack typically involves AngularJS, jQuery, Bootstrap, Grunt, and others — not counting any code developed and maintained in-house. While this might be fine for smaller projects and teams building relatively straight-forward applications and websites, the potential risks and consequences become very pronounced in the enterprise, where teams are larger, geographically diverse, and maintain a large code base common to many applications.
A full-featured framework, such as Ext JS, has fewer development dependencies because the framework simply contains more functionality, eliminating the need for most third party libraries. But the factors of reliability even go beyond the number of dependencies — because Ext JS contains more functionality, that functionality is inherently more reliable because each feature is guaranteed to be compatible across the framework. With fewer required points for third party integration, it’s easy to see how estimating future development is less complicated by using a full-featured framework.
Can your developers easily re-use code across the company’s application portfolio, regardless of the end-user device or platform?
There are two popular acronyms often used in software development: DRY (Don’t Repeat Yourself) and KISS (Keep It Simple, Stupid). And while most developers and application managers understand those terms, it’s also clear that not everyone follows this advice.
For example, most senior developers understand how to extract common code patterns into a higher-level abstraction to be used in multiple places — and therefore the problem of re-use at the small scale is pretty well solved. But what happens in the enterprise, where an organization may have very large software teams managing many applications across a variety of devices and platforms?
The reality of software development in the enterprise is that large-scale code re-use is mostly an unsolved problem. Modification of re-used code is particularly error-prone in these situations, so the “third party library” approach to application development really begins to cause issues as individual modules, developed by different teams with uncoordinated release cycles, need to be updated or replaced.
Ext JS solves this problem by applying a standard application development process, organizing the code itself and providing a consistent methodology. Combining Ext JS with Sencha Cmd, the fully integrated Sencha product line makes it simple to share code across teams and applications.
Can you predict the long-term maintenance requirements of an application across its entire lifecycle and potential end-point delivery platforms?
It has been said that software maintenance is largely about adding new capability to old software — not necessarily fixing bugs. In fact, maintaining existing applications typically consumes between 40 and 80 percent of software costs.
With those sorts of numbers, it’s absolutely critical that development teams actually understand the tools used to build the product. If simply reading and comprehending the existing code consumes as much as 30 percent of the total maintenance time, you can conclude that application maintenance is more difficult than the initial development. This problem only gets worse when the teams maintaining applications inevitably change over time, and the constant influx of new developers results in additional confusion.
Because all Sencha applications follow the same design patterns and methodology, any developer on the team can handle both new development as well as maintenance of legacy software. Ext JS also supports legacy browsers (including IE8) in addition to the latest “modern” versions, so your applications are guaranteed to work for years to come with no additional worry.
Ext JS is clearly positioned to address these concerns, and does so through a robust and tightly integrated set of features. Download the free 30-day trial and see for yourself how building powerful enterprise web applications is easier with Ext JS.
Want to learn more? Join us for our upcoming webinar.
Tuesday, 10/14 at 10:00am PDT
Steinar Stølann says
Although I am a big fan of Sencha and Ext, I think the above comparison is very unfair and tailored to favor Ext. Both can coexist and need not compete against eachother. In my view its just another tool: I wouldn’t build a small and simple checkout process using Ext, nor would I build a feature-complete CRM using Angular.
Also, consider the following:
Angular is free. Ext (with updated fixes) certainly is not.
Angular has a small footprint, Ext has, by far, the largest footprint.
Angular has complete freedom when it comes to theming, Ext requires wild ninjaskills if anything outside of changing colours is needed (not to mention the unannounced breaking changes every so often)
Angular can be neatly integrated with regular websites, Ext….. well…..the footprint alone makes you not want to do that.
Please, Sencha, don’t be the bully company that talks others down just to ensure their own position, you’re better than that.
Different tools for different tasks.
(Still) Founder of the Path of Exticism
I don’t see this post as bullying. Of course it is tailored to favor Sencha, since Sencha is a better fit for complex business applications with loads of different view components and data stores and patterns that bind them together nicely. I definitely agree with your points on when not to use each framework, but I think many users are not that sure about the difference between the two and when to use them. Sencha and Angular solve very different problems. One thing that would clearly illustrate this is to build a medium complex application with multiple stores, grids and tree components etc. The finished Angular sample would contains lots and lots of 3rd party components, just check out the Angular datagrid (still in beta btw). http://ui-grid.info
How do you build a complex data-intensive application based on that? Please note I have nothing against Angular, though I’m like you – big of fan of “Right tool for the right job”.
Further, all JS libraries have breaking changes and Angular is no exception. In Angular they state that it is even to be expected for *minor* revisions which to be is quite surprising. Ideally breaking changes should only be done in a major version upgrade. Read the top section here https://docs.angularjs.org/guide/migration
Just my 0.03 SEK :)
Arthur Kay says
@Steinar – I don’t think this post in any way communicates Sencha being “the bully company that talks others down just to ensure their own position”. To be clear, I don’t think I’ve said anything demeaning or untrue about alternative libraries in this post — and I’ve been very deliberate in framing the conversation towards “enterprise software development”.
Looking at this from the other side, I am constantly confronted by Angular apologists (and those from other communities) citing many of the points you raise. They are fair points, but as has been discussed by you and Mats, the “right tool for the right job” is the key takeaway here… and Ext JS is clearly the “right tool” for building enterprise web applications.
Ahmed Mahfouz says
Actually I totally agree with Arthur in all the answers for the 4 questions above, and from my experience using a framework with a full stack of components better than hassling behind finding good 3rd party components and every enterprise in US they are ready to pay support for the right tool.
I will tell you one example of the issues that I faced using Angular JS on IE8 and you can find the description on the following link: https://github.com/angular/angular.js/issues/4147 and unfortunately we didn’t get a fix for that and we did a work around to make it working.
On the other side I was a member of the product development of HRMS using Ext JS 2.2 and It is really interesting to see how successful the product is and how users are preferring it over Oracle HRMS even though its build by small company in India ( http://www.greytip.com).
Regarding the heavy footprint excuse me that’s far from the truth from my little experience.
I am not working for Sencha but I think it’s a perfect candidate for any enterprise web application.
Jeremy Youssef says
What about Sencha touch? Its team members have been removed from team page and there’s no mention of it for many months. The last update seemed to be old BB code with a small bone thrown in (toast component). Are we to build companies on a dead framework? I’m concerned, please help decide.
“Plus, what happens if you need help?”
You ask a question on their *thriving* IRC channel, Github Issues, or Google Group. I can’t say I’ve gotten the same level of support from Sencha in all of their communication channels.
Open Source = Open Community = Happy Devs.
Another thing is that you mention “a dedicated team of maintainers” for AngularJS applications – I’m curious, who maintains your Ext apps? You can’t just hire joe-blow off the street and expect him to be productive with Ext. I’d argue that Ext has a STEEPER learning curve than Angular, and even more technical debt.
Arthur Kay says
@Anonman – The AngularJS community (and by proxy, all open-source communities) are fantastic, and I’m sure even the core maintainers are willing to help answer questions. However that kind of support isn’t satisfactory for most Fortune-500 companies, government agencies, and other organizations who require accountability from their software vendors. That’s not a knock on AngularJS (or open-source), but it is a reality. The fact that Sencha offers Training, technical Support and even Professional Services is a clear bonus for “choosing Sencha” in this context — because the enterprise companies can’t just hire “joe-blow off the street”.
That may mean a smaller pool of Ext JS developers exists, but considering ALL Sencha applications work the same way I’d argue the technical debt in this case isn’t as bad as you suggest.
Finally, Ext JS certainly has a steeper learning curve than AnguarJS — but Ext JS does a *lot* more than AngularJS. Again that’s not a knock of Angular, but the reality is that Ext JS offers far more functionality. Whether you find the extra stuff comparatively appealing is certainly a topic for another discussion.
Belief and trust in the company are also paramount. At least the following are important:
– history of license changes
– history of price changes
– history of delivering on promises
Shreeraj Pillai says
Well, again nothing against angular. However I personally believe you can’t compare ExtJS with Angular at first place. Its like comparing apples with oranges. ExtJS is a complete framework to build apps while Angular requires support from other libraries to build enterprise apps. For small to medium scale apps requiring very low footprint, open-source, no license fee & YES, dev team has time to validate their UI against all browsers say from IE8 onwards etc..Angular will be a good candidate in such arena.
Romain Caisse says
Nice article, there’s a lot of great tips here. I’m really passionate about Extjs. I found an interesting article regarding Extjs here you can find it http://goo.gl/dKOzhO.