5 questions a CEO/COO should ask the CTO before supporting a JavaScript framework choice
TL;DR; version — JS isn’t going anywhere, so hire JS developers with a penchant for learning so they can move from framework to framework across your stack. As a business focused exec, ask questions that translate tech choices into business risk and can be comparably quantified (in $) to your CFO.
1. Is this version 1?
Stop. Never, ever use version 1.0 of any framework. Imho, version 1.0's sole purpose is to determine which direction the complete version 2.0 will completely re-write the framework, to address concerns of scale and architectural patterns that better fit real world usage.
2. Who is behind the tech?
Let’s play exec for a sec and compare AngularJS, ReactJS, and Sencha. There are many options here, but these seem to come up the most recently in my discussions.
AngularJS? Then it’s Google and Microsoft.
Think of this choice as focused on pushing your app tier into JavaScript to connect UIs to services, not to make amazing UIs. Angular is complimented with the UI widget open source framework Ionic (by Ionic).
ReactJS/ReactNative? Then you’re talking Facebook.
Think of this choice as representing Facebook’s focus on highly performant user experience and HTML5's inability to compete with native mobile apps. Given Facebook’s huge mobile first use case, as well as their push to turn Facebook Pages into a small business eCommerce marketplace, this framework is one to watch.
Sencha? Then you’re talking Sencha, Inc*.
Think of this choice as matching to the business case for: 1) legacy browser support on desktop web, 2) internally focused grid-heavy apps (tabular data), and 3) employee and business partner focused enterprise mobile apps. If your firm has already invested a lot in EXT-JS apps, it may want to leverage the developer learning curve for it’s existing apps and evaluate all frameworks for B2C projects. With a new executive team, the business model seems to be evolving to a end-to-end dev, test, and deployment platform in addition to the ui and app frameworks.
*full disclosure — Modus Create is a Sencha Premier Partner.
3. How big is the developer community?
After all, you are going to need to hire people. The easy way to hack this answer is to search jobs post trends on Indeed or Dice (see charts below). Presentation tier frameworks will always evolve faster that server side code, so hiring front end devs that are into continued learning is the only way to go. How well attended are developer events? How many meetups exist?
4. What is the total cost of ownership?
This is a tough one to answer, but let’s give it a try. The short answer is always “it depends” but on what? Well, that’s easy, answer these three questions:
- Developer cost (specialist). based on questions 1–3, how much do freelancers cost hourly? what are salary bands for mid and senior local talent? how desired are devs (driving salary up)? Quantify the dev learning curve as a function of ((salary/365)*days to be proficient*# of devs), use this function to justify a new hire who can lessen any one of the variables. Now adjust for workplace variables — be honest and answer for yourself, “What kind of a premium does our company have to pay if we are not considered an exciting place to work, if we require on site work, etc?”
- Quality cost — how well does the framework support test automation? How many ‘things’ do I get out of the box? How much dev effort will be required to extend and customize the framework?
5. What is the cost of changing?
This is an easy one, as long as you (CEO/COO) are not actually the problem. “Me? How so?”, well yes, in terms of having an emotional bias to the legacy codebase when comparing the cost to barely maintain as-is code fraught with technical debt with the cost to improve or rebuild (always more expensive). We all know the type, “the codes worked fine for 10 years” “Joe wrote the old UI in 10 days.” If you are him, stop reading. Resign, you are the problem. If you’re not him/her, and I hope that’s the case, then consider the following:
- Avoid early adopter cost(s). Ask your CTO, “is now the right time to change our codebase?” “Is adopting a framework too early only going to incur more cost when we have to rewrite it in a year?
- Avoid the sunk cost fallacy. The opposite of moving to early is moving too late. Ask your CTO, “Are we overpaying our existing developers because our existing code is so brittle we can’t afford to lose them?” “Is our customer experience suffering because we our UI technology is lacking?”
