JavaScript Frameworks and Your Business

Being a small business owner who does a lot of subcontracting on long term contracts, I have both the freedom and professional need to stay on top of new technology trends.  Sometimes this need becomes very pressing, like when I know or suspect a contracting gig may be ending, and at other times work makes such a huge mental demand that I don't have time to keep up where I would like to.

JavaScript frameworks are one of those areas where I wish I could have kept up better over the last 4 or 5 years.  My focus instead had been on systems integration and J2EE.  UI, while a sometimes important part of what I was doing, was in most of those cases a secondary concern, and while I was joyed to adopt Bootstrap and W3.css, they are really about decorating the UI, not frameworks. 

JavaScript Frameworks: Basic History

The idea of frameworks goes way back.  I don't know the precise origin but started getting involved with them when prototype.js, scriptaculous and ext.js were in their infancy, even contributing to a few bug fixes on prototype and ext through my connections with developers on those.  Early frameworks focused on reducing the amount of code you wrote.  Forks of ext.js included complete makeovers for some UI's generated by things like IBM Lotus Domino (notorious for its broken and ham-fisted HTML rendering). 

These two ideas, reducing coding effort by creating simplified and powerful boilerplate code, and redrawing the UI through DOM manipulation for better User eXperience (UX) continued to evolve over time, giving rise to things like ember.js, knockout.js and others.  All the while, the focus was moving away from just scripting the UI and towards more abstract concepts and solid design patterns.  Knockout.js, for example, introduced binding that worked in a way that made keeping the UI view and its underlying model in sync much much easier.

Modern Frameworks

Present day, 2019, Angular and React have become the dominant frameworks.  They build on a legacy of prior art while also reinventing and reconsidering the design challenges web application developers have faced over time.  Maintaining the state of an application from one screen or panel to another, handling server side requests for data, ensuring cross-browser or even cross-platform compatibility and deciding how to divide up logic and UI are just a few such considerations. 

Angular, created by Google leverages another open source tool, Typescript.  React, created by Facebook is a less opinionated framework that nonetheless offers a lot of benefits.  Sitepoint published a very good article that I recommend to anyone trying to choose between the two.  Importantly, it offers a conclusion I very much agree with as it meshes solidly with my view: don't choose one.  I believe, as others do, that there is a right tool for each job, and that it is often not the tool you have used the most or most recently.  Fresh analysis of the needs and environment of a project should be undertaken each time you embark on a new effort.

The Probable Future

Presently, both React and Angular offer CLI's to expedite and standardize the bootstrapping of a new project.  (I rather like the very structured approach Angular takes).  Code generation is just enough to get you started.  After that, you have some learning to do.  But, the everyday tasks we perform as application developers are largely the same.  The details are what make the biggest difference in each implementation, but we often enough repeat work done by others.  Mixins (in the case of React) and continued contributions to libraries and add-ons for both frameworks follows the same general trend of software development in other technologies, that being one of continued modularization,  code generation, standardization and ever more complete and competent frameworks. 

A merging of platforms is also underway where projects like React Native and Native Script provide the ability to take these primarily web browser focused frameworks and create native applications for both Android and iOS devices.  The number of different skill sets needed to create something with a broad audience is declining as time goes on.  However, the tools and platforms we build these solutions upon continue to improve and evolve through natural growth and innovation.  So too, the frameworks and tools we employ to make more utility out of less time and fewer people will evolve and change in step or just behind these platforms.  However, the core challenges of providing value to customers will remain, and that means good business requirements analysis will be an in-demand skill for some time to come. 

It also means that some skills will have more longevity in the market than others, though the details of how they are implemented will continue to change.  UI design continues to change subtly as customers move from the desktop and tablets to smaller presentation form factors on mobile devices.  Application development, though, is rapidly changing.  So much so that within the span of of 3- 6 months, a projects base code might need to be reevaluated from a dependency perspective as changes and updates to the ever increasing number of external dependencies projects have continues at a very brisk pace.  What was the best way to do something last year is out of date and clumsy now.  Core design principles remain important, however.  Even as we see a near constant flow of changes in tooling and libraries we may take from the open source community and commercial markets, understanding what reliable and maintainable designs looks like, and how to avoid common pitfalls remain foundational skills that do not age out.

All Things Considered

The challenge for a modern provider of software design and development solutions, then, is to balance time learning and updating skills with providing lasting value and value-added services to customers.  My primary concern for any client is always that the time they pay me for results in cost savings or profits.  We should be striving to optimize systems so that less time is wasted, efficiency of systems improves, friction of transactions decreases, and the investment in IT as a whole has a clear and measurable impact on the bottom line. 

These opportunities only arise as often as businesses have the presence of mind to ask key questions, just like any software developer should ask: are we making the best use of our resources? Are we duplicating work? Are we spending disproportionate capital on a problem(addressing a 1% problem with more than 1% of our resources, for example)? How can we improve?  What can we do better, faster or cheaper?  How do we continue to improve quality and reduce our future cost of ownership?

And that's the sort of conversation I like to have with managers and business owners.  If you haven't had a conversation like that lately, drop us a line at: datatribe at gmail dot com. 

Frameworks, then, should be viewed as value added investments.  Adopting them has an initial cost in terms of developer ramp up, but the benefits to quality and speed of development in the future are quite clear from a technical standpoint.  It's the sort of investment that is on the same level as adopting a source code control solution and giving consideration to continuous integration or continuous development solutions. 

If you're a big enough business to have a dedicated IT department, these will be familiar concepts, or ought be, and are worth careful consideration.  If you area small business, what you need to know is the value delivered when a solution provider mentions the use of a framework such as Angular or React comes in the form of quicker initial results with faster future updates.  You should expect turnaround times to improve greatly over older ways of creating custom solutions.  This means your overall or initial cost will likely be lower in terms of man hours, allowing more capital to be diverted to other needs or folded back in to making better tools for your employees and customers.