Table of Contents
Angular written by Google is another popular open source framework that is rapidly evolving. It started out as Angular 1.x – now known as AngularJS and then iterated to Angular 2.0x – 6.x – now known simply as Angular and uses TypeScript. Angular lacked backward compatibility amongst certain versions and that meant additional developer efforts to support new versions.
Challenges in enterprise adoption of Free Open Source Software (FOSS)
Today many businesses are relying on open source software to build their web, hybrid and PWA applications. Tool selection can be quite complex; as many factors need to be taken into consideration including what type of application you’re planning to build (is it simple or complex, what are your business goals as it relates to the app you’re developing), training/experience across your development teams, security/risk mitigation, maintenance and support costs and resources, and expected lifespan of the application, which can range from 5 years or more. Ultimately enterprise companies are going to want to hone in on tools that will allow their teams to be the most productive while providing their consumers with the best user experience, all of which directly coincides with getting applications to market faster.
Building robust, beautiful components that perform well on all devices and platforms is a time-consuming and costly undertaking. FOSS app developers shoulder the burden of supporting and maintaining components over the lifespan of the app as browsers and language standards evolve, establishing a consistent look and feel of components and the overall app, adapting to necessary display environments, internationalization, accessibility and so forth. For creating quality apps, there is an added burden of cobbling together FOSS testing tools.
There are a lot of options that address specific parts of that list, and there are very few options that help in all areas. In fact, adopting specialized solutions for some of the categories can make it much harder to address others. For example, many React teams use a combination of custom-developed components along with open-source and in some cases commercial components. This provides useful functionality in the app but can make it extremely hard to implement a consistent look and feel across those components and the rest of the app.
Using “Native” FOSS Components
The explosion of web application needs is driving demand for more ready to use components. The primary framework authors have little desire to develop such components, but the FOSS community is abundant with ready to use source code and components that are either free or low cost, and are usually framework specific. The majority of these accelerate builds, but have minimal considerations for maintenance. Because one can generate results fast and cheap, this is the primary way to build FOSS applications today. It is excellent for selected needs, such as start-ups or proof of concepts. However, it does result largely in customized apps, so ongoing demand on resources are significant.
Increasingly, traditional paid component vendors are entering the space with ready to use and maintained components that can be used in FOSS applications. There are multiple vendors with robust solutions. Many of these are cross-framework and can either be “native” in the framework or work within the framework, much like containers. Vendors implementing a set of components for all frameworks typically would use some sort of automated translation and is resource intensive both to develop and QA. However, they are still far more stable and easier to maintain. It is an interesting and dynamic space and we will see how it evolves.
More complex components for FOSS are increasingly non-native. In many ways, they are their own frameworks that work within the large FOSS frameworks, like Angular and React. A few good examples are Charting, Grids and Text Editors. Many vendors are evolving the components into self-contained SaaS applications. This model is a direct challenge for FOSS, but highlights the fact that the future is likely going to be a hybrid of tooling.
Top Considerations for development with FOSS
The easiest way to manage these challenges is by minimizing the number of sources used for your components, styling, data packages, and testing tooling. Components developed by the same team can typically be styled and tested in the same ways, enhanced through the same means, and in some cases even leverage specialized workflow tools that improve the development experience. These solutions can greatly decrease the effort and time required to build sophisticated FOSS apps that provide a rich, beautiful, cohesive user experience.
Developers are more productive with 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. This should be one of the top considerations as organizations are laying the foundation for their business critical applications, especially if the intent is to build enterprise-grade apps that can last beyond the average lifespan of 5-10 years.