CHOOSING WEB APPLICATION LIBRARIES IN AN OPEN SOURCE WORLD

By Peter Varhol

Table of Contents

Web application development represents the overwhelming choice for applications today. Applications employing web architectures can be developed incrementally and deployed in stages to the cloud. These applications use a wide variety of architectures, tools, and techniques to deliver a high performing and worldwide reach for the company.
This development can be accomplished using commercial turnkey packages from the likes of IBM with WebSphere and Microsoft with IIS and Visual Studio. Alternatively, more and more teams are focusing in on open source infrastructure, such as the LAMP stack (Linux, Apache, MySQL, PHP) or the MEAN stack (MongoDB, Express.js, Angular, and Node.js).

For developers, these technologies represent the state of the art more so than commercial tools. Further, they help prevent teams from being locked into specific vendors and technical approaches. Upgrading to new versions doesn’t typically come with a monetary cost, and removing one framework and replacing with another is an engineering rather than cost decision.
Open source stacks can be very robust, offering development teams a great deal of flexibility in libraries, development approaches, programming languages, and application architectures. Often teams appreciate the ability to choose open source libraries based on technical and business needs, rather than have to use a single commercial platform.

MULTIPLE OPEN SOURCE TOOLS FOR THE TOOLCHAIN

Development teams use open source software for more than simply application infrastructure. They also use it to manage and automate the process of software delivery. Free and open source software (FOSS) tools such as GitHub, languages such as Python, Go, and JavaScript, continuous integration and deployment tools like Jenkins, Puppet, and Chef, and orchestration products such as Kubernetes. Specialized open source language libraries such as node.js, Angular, and React have increasingly become necessities in getting code out quickly.
Commercial offerings simply have not kept up with the needs of modern development practices. While new commercial products have begun to

COMMERCIAL TOOLS DON’T YET WELL SUPPORT THE PRINCIPLES OF DEVOPS, SO TEAMS FIND AN ADDITIONAL ADVANTAGE IN USING OPEN SOURCE.

appear, open source alternatives have been available for years, giving them mindshare among teams. They have also had time to mature, making them more reliable and secure than many commercial alternatives.
This is especially true in Agile and DevOps practices, where continuous integration and deployment play a large part in the success of a project. Commercial tools don’t yet well support the principles of DevOps, so teams find an additional advantage in using open source.
The likes of Python, Angular, and React are great libraries for building Web applications. Collectively, they accelerate the use of JavaScript in building Web applications, letting developers work at a higher level of abstraction and write better and more consistent code more quickly.
These are just a few reasons why development teams need to be creative in looking for alternative development resources. And with the plethora of fine and high-performing open source frameworks and libraries available, using open source solutions may seem like a clear choice. They are free, generally of high quality, and work well in isolation.

OPEN SOURCE FRAMEWORKS AREN’T A PANACEA

But more productivity and modern practices come at a cost. In this case, it means more

uncertainty in the future of the frameworks and libraries, and how they may interact with other software packages. Teams have to balance the advantages of open source with the limitations, but often cost or experience factors also play a role. Individual team members may drive decisions toward specific frameworks without a proper evaluation of the benefits. The reality is that many teams will take the immediate path of least resistance, not properly weighing, or deferring, potential issues farther into the project.
There are also other disadvantages in using open source frameworks in Web application development. There is often no organized support or training available for these libraries. While there are likely ample resources online, they have also been developed by the community and may be of varying quality, and difficult to track down. There may also be key errors or omissions in open source documentation that prevent a clear understanding of using the library.
Further, there is no single place to turn to for service and support. While there is likely to be one or more forums that can be queried, getting a quick and accurate answer can be an exercise in futility. It may also be possible to purchase a support contract for a particular library or framework, but the cost involved may be substantial.
If the team is using multiple open source libraries, together with a one or

more open source frameworks, it may be impossible to tell where a particular problem lies. Because open source libraries are not developed and supported by vendors, there is no single source of reliable advice on use or issues, especially on the interactions between multiple libraries and frameworks.

developers to build attractive and standardized user interfaces. This forces developers to use many different component libraries, one or more for each framework. While technically possible, such an approach is not a software architecture best practice.

IF TEAMS ARE USING MULTIPLE OPEN SOURCE LIBRARIES, THIS MAY PROVE ALMOST IMPOSSIBLE TO DIAGNOSE AND FIX.

Dependencies can also be an issue. A lot of interacting code has dependencies, whether they be through APIs, REST, direct connections, or through intermediary software. Calling conventions frequently change from one version to the next, usually for good reasons, but it may mean that what worked with the previous version is completely broken with the current one. That can lead to hours of examining new documentation, if it exists, and retooling the interfaces. In extreme cases it can result in major development work. If teams are using multiple open source libraries, this may prove almost impossible to diagnose and fix.
Last, frameworks like Angular, while valuable in terms of abstracting key programming concepts and accelerating development, still fall short in usability. In particular, popular free open source software frameworks such as React and Angular lack a single, comprehensive component library for application

MANY TECHNICAL TRADEOFFS WITH OPEN SOURCE

But while open source frameworks and libraries have a lot of technical and business advantages for Web application development, there are also some significant tradeoffs. Perhaps the largest is that these frameworks, while enabling more productive development through a higher level of coding abstraction, almost always lack an important capability – that of easily designing and coding an attractive user interface to make users productive.
Building robust, functional, and attractive components that perform well on all devices and platforms is a timeconsuming and costly undertaking. Developers need a comprehensive framework that includes a pre-built component library to build applications quickly and efficiently so that businesses can get their apps to market faster and with better usability.
Some open source component libraries exist, such as JavaFX and SWT, but they

tend to have a lower level of abstraction, and don’t necessarily work well with frameworks such as Angular or React. And once again, support for these can be problematic, with open online forums typically the only place to turn.
Overall, application UI components have to be useful to the requirements of your application, fully functional as defined in their description, visually attractive, and unambiguous in both their programming and their use. Further, they should be supportable and supported with detailed documentation, technical expertise, and a definite roadmap. When a team invests in a set of solutions, whether commercial or open source, it invests not only in the capability provided today, but also in the viability of those solutions in the future, for the lifecycle of the application.

double duty. First, they enable ease of use and user productivity, by making it clear what data needs to be entered and where. Second, they facilitate the transfer of data from the UI layer to the business logic, and ultimately the database.
Development teams depend on the ease at which controls can be integrated into an application, with data APIs that reflect the desired application architecture. That’s because applications typically operate on three tiers. Data is largely entered by the users at the presentation layer, is processed at the business logic layer, and stored at the database layer.
It is certainly technically possible to intermingle the process of data flow in an application. For example, a popular shortcut is to not have any defined separation between the presentation and

THE BEST PRACTICE FOR QUALITY, UNDERSTANDABILITY, AND SUPPORTABILITY IS TO HAVE A COMPLETE SEPARATION BETWEEN LAYERS, WITH AS FEW INTEGRATION POINTS AS POSSIBLE.

DATA-DRIVEN COMPONENTS DELIVER DATA, ENFORCE ARCHITECTURE

Most applications are also designed with the explicit goal of accepting and returning data in some form. The user may be inputting data for processing, or may be asking a question of the application data. Almost every request from the user interface is for a data read or write of some sort. In this regard, user interface components serve

business logic layers, with the data entered going straight into code connected directly to the control. However, the best practice for quality, understandability, and supportability is to have a complete separation between layers, with as few integration points as possible. This separation gives the application a structure that enables different engineers to work on different

parts of the code, with only a few discrete and well-defined points of integration.
Typically, commercial components make it easier to integrate into a bestpractices data architecture, thanks to well-documented interfaces and many example uses. Interfaces also tend to be easier to use in production than some

specialized expertise and scripting skills that enterprise testers may struggle with. In many cases, Selenium and other open source tools need an expert understanding of both the tool and one or more scripting languages.
Further, most open source testing tools are general purpose in nature. They are

COMMERCIAL COMPONENT LIBRARIES OFTEN INCORPORATE CUSTOM TESTING FRAMEWORKS THAT MAKE TESTING SEAMLESS AND EASY

open source alternatives, because they are usually the result of professional user experience design targeting a specific user community.

TESTING AND SUPPORTING TOOLS

While open source frameworks provide a level of abstraction over JavaScript or other language to make coding more productive, development teams have to seek out other tools for use as the development environment, design, analysis, testing, and deployment. Typically the teams put together a tool chain consisting of frameworks and libraries, IDE, language editor and compiler, continuous integration, building, testing, and continuous deployment. Many of the most popular tools are also open source, which adds an additional layer of complexity to a development effort.
Testing web applications developed using open source frameworks is certainly possible, using automation tools such as Selenium. However, Selenium and other open source testing tools typically require

not geared toward testing one specific area, such as components. This means that they may not be the most effective way of testing.
Commercial component libraries often incorporate custom testing frameworks that make testing seamless and easy. Rather than having to script tests in a scripting language, teams should be able to define tests based on use cases directly from the UI. And commercial tools geared toward specific libraries should be able to readily identify components so that changes over time are minimal.
Using open source frameworks and libraries is often a smart choice. Development teams may already have that experience, and many individuals prefer open source experience over a commercial alternative. But it’s not necessarily for all of the code used to be open source. Teams should look at the tradeoffs carefully, and be prepared to adopt the right library or framework for their project, whether open source or commercial.

COMMERCIAL COMPONENT LIBRARIES USED IN CONJUNCTION WITH OPEN SOURCE FRAMEWORKS OFFER THE BEST OF BOTH WORLDS.

CONCLUSIONS

Commercial component libraries used in conjunction with open source frameworks offer the best of both worlds. Teams get to learn and apply popular open source frameworks into their applications, which gives both the applications and the team some technical cachet.
By rounding out the development effort with commercial component libraries, these teams can limit development and maintenance risk by having a better understanding of code interfaces, obtaining detailed information and accountability of the library and its interactions with open source components, and having a clear support understanding with the vendor. The intent of the team should be to reduce development and operational risk, and commercial components offer a specific way of doing so.
One popular set of commercial component libraries is from Sencha, which provides component extensions to JavaScript, React, and Java GWT. In

addition, Sencha Test provides a highly productive and automated way of testing these components when integrated into a larger application.
The Sencha team can help you design, develop and test enterprise-grade web applications quickly, along with full support. Sign-up for a free 30-day trial of any Sencha product today.

Learn more at: www.sencha.com

Peter Varhol is a technical evangelist. He has more than 20 years of experience writing technical articles, blog posts, and papers on technical practices and products. He has graduate degrees in computer science, mathematics, and psychology, and experience as an evangelist, product manager, software developer and tester, and technology journalist.