I’ve been thinking about the needs of decisions (technical or design) to translate across the self, the team, and the organization. On any project I belong to each of those “bodies” simultaneously. Choices I make needs to cascade across each context. One such decision I’ve been mulling is the option to employ a JS framework for a client’s site.

In matters of the self, I’m comfortable writing Vanilla JS. It keeps my code minimal and quaint. I prefer it and feel it unbinds us from bloat and needless dependency hell. In fact, almost all the necessary UI JavaScript for this project is already written in Vanilla JS and ready to ship.

From a wider front-end team sensibility, urgent demands and quick fixes mean the quality of the original Vanilla JS degrades quickly over a short period of time. With multiple teams (in-house, remote, and offshore) adding code to support more scenarios and workarounds, it’s unsustainable to nitpick each line of code. I don’t see the urgent demands subsiding soon. We need a system. As much as it pains my puritan heart, a framework seems like it could be the best possible solution.

A framework gives structure and conventions. Abide in the pre-agreed upon conventions and things should go well. Frameworks come with prefab open source solutions too which are basically free solutions. Need a modal? Install react-modal, it might be 81kb but it gzips away don’t worry, let’s move fast. Reducing the code we write reduces our surface area for potential bugs.

Small teams have a bit more freedom to switch tooling up as needed. The level of effort is fairly small as well; a few quick conversations, tell everyone to re-pull and npm install, update a readme, start a Slack channel for support. Easy. It’s great if decision can stop at this level.

For some decisions, it’s important to consider how this change effects the entire organization. Do your changes scale? Do technical changes or design changes create unnecessary workloads and process burdens? Is DevOps aware? Is marketing? QA? Legal? Does this break A/B Testing? Who is responsible for communicating the framework switch to offshore? Does offshore even know React? Are the Java devs who end up writing front-end code going to adopt the new framework? What is the actual cost in meetings of on-boarding other teams to this new thing?

I’m seeing technology and design choices as a mixture of compromises between these three questions; what can I do, what’s possible as a team, and what’s possible as an organization. It’s a lot to consider and I probably spend too much time thinking about it, but I’ve spent a lot of my life debugging various “solutions” that actually create more problems and were poorly designed, thought about, or implemented.

For our project we’re leaning towards Angular as our framework of choice. While a bit out of the JavaScript zeitgeist, my coworker Julian Jones (a real life MD who has shipped Java code into space on satellites) pointed out that Angular gives us familiar conventions for Java developers, well-defined code organization, and an HTML-first approach that shouldn’t “move cheese” too much and would ease adoption. It’ll be a big piece-by-piece rewrite. Angular’s TypeScript dependency is a bit out of my wheel house (so I’ll have to level up a bit) and there are still some infrastructure issues to solve at the organization level, but considering a handful of available options, we think we have a decent plan on how to solve the greater problem.