The Problem for Developers – Open Source and Non-Proprietary is Complicated, Part Two

Naveed Sami Headshot

Author’s Note: A Technical Architect with GeoDecisions, Naveed Sami designs and develops web-based, desktop, and mobile GIS applications and enterprise applications. With his finger on the pulse of the latest geospatial trends and technologies, Naveed will regularly discuss a variety of technical topics on our website.


By ENERGY.GOV (Photo of the Week: 70s Supercomputer style) [Public domain], via Wikimedia Commons https://commons.wikimedia.org/wiki/File%3APhoto_of_the_Week-_70s_Supercomputer_Style_(8971052970).jpg

By ENERGY.GOV (Photo of the Week: 70s Supercomputer style) [Public domain], via Wikimedia Commons https://commons.wikimedia.org/wiki/File%3APhoto_of_the_Week-_70s_Supercomputer_Style_(8971052970).jpg

As discussed in my Part One blog, JavaScript is the number one language used to develop interactive web applications.

Programming languages that target a particular hardware or operating system platform, and are not open source, tend to support a small number of robust application frameworks. The canonical example is Apple’s Cocoa Framework built using the Objective-C language. The platform for JavaScript is the web browser – it does not target a particular hardware or operating system, and JavaScript has evolved in an open source eco-system. The original web browser started as simple document display software, and has evolved at an incredible rate to turn into the great feat of software engineering that the modern web browser truly is. This is why we have 64 JavaScript Frameworks to deal with!

Front-end web development moves faster than any other type of software development; thus, there is incredible pressure on developers to learn new skills to add to their portfolios. Time pressures result in difficult choices regarding knowing what to pay attention to. Appropriate forecasts about the future direction of technological change have to be made under rapidly changing circumstances.  If good decisions are not made, then costs for developers and clients increase to build and maintain applications. 

Stay tuned for Part Three - "Angular to the Rescue?".