Technology is not eternal, especially when it comes to the fleeting frontend frameworks of the javascript community. You can see below that even the most popular frontend tools have a rise and fall, some more dramatic than others.

Each generation builds on the foundations and work of previous generations. When this happens, no matter how time-tested a technology might be, it can and will reach the end of its life. If you work on web applications, have you ever been impacted by the death of significant dependency or the end of a framework’s life? React.js is still riding high in the chart above, though it may have begun to experience a downturn. Are you ready for the death of React.js?

The stream will cease to flow;

The wind will cease to blow;

The clouds will cease to fleet;

The heart will cease to beat;

For all things must die.1

This poem may be too dramatic for the occasion, but it is meant to highlight a reality. Every dependency will eventually be deprecated. Regardless of the type of technology, the scope of its usage, and the benefits it has provided, there are limited options when a technology’s end-of-life is on the horizon. Let’s consider those below.

What happens when a dependency dies?

I have migrated multiple applications from one framework to another, and limited options are available when your dependency is no longer maintained. This is incredibly challenging when that dependency is as foundational as a frontend framework. You could do nothing, but this introduces a host of problems that are usually unacceptable such as:

• Security vulnerabilities will not be patched

• Breaking changes may prevent future upgrades

• Fewer developers will want to work using “dead” tools

• Related dependencies may also die, creating even more issues

These risks require a mitigation strategy. I’ve considered multiple as I’ve participated in and led migrations from older, less popular frameworks (e.g., backbone.js) and those that have officially lost all support. (eg. angular.js). There are four main options to consider though all come with costs.

1. In-place migration

While this might seem the most straightforward answer, most applications have been written over many years with very little planning for the end of a technology’s life, especially regarding a frontend framework. Usually, code is tightly coupled, leaving migration paths risky and prone to bugs. It can be done, but it is generally preferable to rewrite the application as the cost is unpredictable, and migrations are known to draw on and on if the plan is not coordinated, well-scoped, and controlled. Preventing interoperability between new and old code is essential. If normal development continues on the application, everyone must follow the plan, or a migration project may never end. Untangling the mess of code migration is often not worth the trouble or the cost.

2. Rewrite on a new foundation

A rewrite might seem just as expensive, and in some ways, it is a type of migration, but rebuilding a house is easier when people aren’t living in it. Like a migration, a rewrite can be iterative, but rewrites build new foundations. The best course of action with a rewrite is to ensure solid end-to-end testing is in place. Product audits are essential and an excellent opportunity to “clean house” if certain features are not worth maintaining. The rewritten scopes should pass the identical end-to-end test suites. While a migration tries to decouple and use existing code paths, a rewrite creates entirely new ones. You might copy some code from previous locations, but there is no chance of continuing to couple new code to old dependencies if they aren’t found or allowed in the new location.

3. Fork & Maintain

Depending on the size and complexity of a dependency, you might consider forking the project and then maintaining and upgrading it as needed. This is usually not a good long-term option because of the developer cost required to understand and maintain an outdated tool. The end-of-life tool was also retired for a reason, and keeping it alive and working is asking for trouble in most scenarios, even if you can afford it. Most companies wouldn’t have the specialized engineers or headcount to keep something like a frontend framework alive.

4. Outsource the Upkeep

Lastly, while you might not be able to keep it alive, there are sometimes options to contract others to extend the life of a dependency. This is also usually prohibitively expensive and can be likened to COBRA insurance in healthcare. You may need it in an emergency while you find a better option, like migrating or rewriting, but this is not a long-term solution as the problems are just being delayed and at a tremendous financial cost. However, this is usually a better and safer temporary option than forking and trying to do it yourself.

Planning for dependency end of life

The reality of dependency death or deprecation is not often considered at the beginning of adoption. Usually, the most pressing problems win out, not those 10-15 years in the future, but tech companies can and have faced these scenarios already. For example, many web applications are still coping with the pain caused by the end-of-life of angular.js. This begs the question, what can be done to plan for the end? Just like planning for one’s own death, or the death of a loved one, the estate should be managed, and affairs should be put in order, but planning early can often prevent pain. Like any loss, pain is unavoidable, but there are some practical ways to ease the burden on those who follow, whether or not we are still around to see it.

Write the will before the terminal diagnosis

Writing a will is a good metaphor for understanding how to plan for the death of a dependency. A will outlines a plan for each scope of ownership. It spells out the scopes. It specifies the new owners. It tries to avoid ambiguity. As we choose to purchase or invest in new technology, future owners aren’t often on our minds. If we consider the scopes this new technology owns and possible new owners, this can make the handoff smoother in the future. A good first step is outlining each scope of ownership and any challenges that will occur when that ownership needs to be transferred. This may expose opportunities to transfer ownership early or reduce debt to avoid pain during the transfer. In the case of react.js, this could mean outlining the high-level scopes. Perhaps you only use react.js, as originally built, to render HTML views. You likely have introduced hooks (many relationships) and might even use React to manage significant amounts of application state with the Context API. You may also need to consider each peer dependency relationship like react-router, react-redux, etc. All these relationships make end-of-life even more challenging.

Avoid unnecessary relationships

The more relationships in a person’s life, the more difficult it is to write and execute their will. The same is true with any dependency we add to our applications. Each reference to that dependency and each peer dependency establishes a coupling that eventually needs to be removed or replaced. A few tips may help avoid the often massive work of decoupling that must happen at end-of-life.

Keep references to a minimum

While this may seem straightforward, when it comes to your code, you need to be ever-vigilant in reducing the number of dependencies and keeping references to those dependencies consolidated and controlled. The more you import or reference a dependency in your code, the more difficult it will be to remove it later. This means adding abstractions when possible so that you maintain the interface contracts instead of using a dependency directly. The less the dependency is directly invested in your code, the easier it will be to refactor and replace.

A diagnostic tool for understanding how much you may owe to various dependencies is easily found in your testing expectations. The more you mock a dependency in your unit tests, the more you can count on that dependency creating havoc at the end of its life. I tend to prefer patterns that follow functional patterns or dependency injection. Mocking in tests is a symptom of technical debt that eventually must be paid when a dependency dies.

I once took a course on Frontend Masters on angular.js by Scott Moss, but much of the code in the course was written so that it could be tested without angular and the traditional bloat of angular.js test runners. If your unit tests don’t require your frontend framework, you can bet it will be easier to reuse that logic in a future application when needed.

Invest in tools that promote modular design

Some tools promote modular design, and some do not. For example, react hooks will cause great pain when many apps eventually need to migrate away from React. This is because each imported hook introduces a side effect. This is true even in the most consolidated and well-written custom hooks. All hooks tightly couple those features and components to the react ecosystem. They will make it very difficult to remove.

An app that uses redux, react-redux, and its more dated connect function is a good example of decoupled and modular code. (Using react-redux’s useSelector and useDispatch does not promote modular decoupled code) When used correctly and not immediately invoked, the connect function creates reusable higher-order components with shared application state and actions. It may feel like a pipe dream for most modern react apps, but react connected to redux following this pattern will be much easier to replace with another rendering tool when the time comes. It may be an unpopular opinion, but decoupled state management libraries like redux will endure longer than the state management of many current frontend tools because they are not coupled to the browser or its ever-changing API. Most popular frontend frameworks and tools are written without an escape plan.

Consult the heirs, even if they aren’t here yet

Estate planning is not a solo project, and while we can and should plan for the death of our dependencies, we shouldn’t do it alone, and we shouldn’t expect to do it perfectly. I recommend starting a technology capabilities plan (TCP) at your company if one doesn’t exist. This outlines the current decisions and practices around current dependencies. It should also include estimates for future usage and plans to document best practices to limit those dependency touchpoints. This TCP will not cover or prevent all technical debt, but starting and continuing the conversation will leave everyone better prepared. Often, taking on technical debt is the best investment a company can make, but all debt needs to be paid, and when a death occurs, that payment becomes forced. Don’t be caught off guard when your dependency dies.

Are you a high-performing software engineer, or maybe you work with or manage one? We often hear high-performers labeled using terms like "10x developer" or "rockstar.” When thinking about your growth related to these labels, you may think, “if only I do 10x more than I’m doing now, then I’ll be successful.” You might think you need to solve more significant and complex problems and that being a high performer is doing things others can't.

While increasing your output or improving the quality of your work might seem like the best path to being a high performer, I’d like to suggest a better way that doesn’t focus on comparative output or highlight dramatic performances. A high-performing engineer may have significant output (10x) and solve complex problems with elegance and ease (rockstar). Still, if they only adopt these roles, their contributions will not scale as large and may not even endure.

Technical Trailblazer

The highest performers I have seen and learned from are those who don’t simply charge off into the wilderness on their own but know how to lay a trail. I like the metaphor of a trailblazing engineer because the parallels, though often neglected, are practical, simple, and straightforward. Like a real trailblazer, a trailblazing engineer is headed somewhere others will follow. So let’s consider practices that can make you a successful trailblazer.

Plan their journey, not just yours

Setting out to impact your team or add value to the product you work on is a great goal. However, when going somewhere new, you need to know where you hope to end up, how you plan to get there, and how others will follow. Documenting the high-level steps of that plan and outlining how you will get from where you are now to where you are going is the first step of trailblazing. If you skip this step, you leave yourself open to many risks, including not ending up where you wanted to be, leaving no trail, and possibly ending up at your destination alone.

I once attempted to blaze a new trail for migrating from a deprecated frontend framework to a new one. As I tackled the problem, I tried to make it easier for people to follow my work and contribute. However, this first attempt failed, and it did so because it needed to include a plan with well-scoped steps to reach the end. I had only provided a pattern and some tooling but had not spelled out the scopes, milestones, and steps required to do the work.

It is essential to consider your destination and route. Still, even more importantly, remember how those who follow you will get to the same place. This means considering all the required steps and the contexts and abilities of those coming after you.

Prepare for the "dysentery.”

If you are old enough to remember the computer game Oregon Trail, you know that someone in your traveling party eventually gets dysentery. This means that trail-blazing work will have challenges outside your control. People change companies, get sick, tragedy strikes, team members get reallocated to other projects, and the list goes on. The reality is that trailblazing can get interrupted; no matter how great an engineer you might be, you cannot blaze the trail if you aren’t on it.

This brings me to some of the best advice I’ve received for maximizing my impact. Once, a manager recommended that I deliver work with the expectation that I might not be doing this tomorrow. The best technical trailblazers leave a clear enough path that even if they are pulled off the trail, someone can pick up the work and do so without much delay.

For example, I once had a co-worker who knew he would leave me in a difficult position by accepting a new role and leaving my team. However, instead of simply walking away, he spent his final weeks documenting a massive backlog of well-specified tickets and laid out a clear plan for his remaining work. This trailblazing and stewardship make him the kind of engineer for whom I’d always write a referral, and I would be glad to have him join my team again. If you are blazing a difficult trail, will it be successful if you are forced to be absent for a time? Would it be successful without you? Those who can answer yes are the kind of engineers I’d want on my team and at my company any day.

Don't go too far ahead of your party

It can be tempting to charge ahead and get stuff done, and sometimes, this type of work is required, but some projects require engagement and adoption from more than just a few engineers. Sometimes you need buy-in from the whole organization, including leadership and individual contributors. Even if you can blaze a new trail, it is essential to consider whether anyone will be able or want to follow, especially if they can’t see you or what you are doing.

I once spent the better part of a year developing and documenting a backend service layer written with a newer technology that was supposed to make everyone’s lives easier and speed up the process of delivering value to our customers. Unfortunately, as I developed this work with a few others, we made the mistake of getting too far ahead of everyone else. We had a plan, the steps, and we had it all laid out, but we lost our party. Those we needed to travel with us were not bought in and were not ready to invest in learning the new technology. As a result, the company wasn’t prepared to adopt the new layer into its product-development lifecycle. Had we considered the current company climate, the readiness for change, and the lack of resources needed to support the successful adoption of new patterns and practices, we may have planned an easier or more gradual route.

When thinking about blazing a trail or making an impact that is bigger than you can accomplish on your own, it is paramount that you know who will be following and that you aren’t blazing a trail that no one is willing to travel, no matter how well groomed it might be.

Be ready to backtrack

As I’ve referenced earlier, sometimes we blaze trails that others are not ready to travel. Other times we hit roadblocks that force us to take a different path. Especially when traveling into unfamiliar technical territory, we need to be ready to backtrack, pivot and chart a new course.

Earlier, I mentioned trying and failing to introduce a pattern for migrating a legacy application from one framework to another. When I realized this path was not gaining adoption or being followed, it forced me to backtrack, regroup and chart a new course. I didn’t do this alone because the key to backtracking is getting back to your traveling party and ensuring you aren’t blazing ahead alone.

I regrouped with others at my company and worked with them to formulate better plans, scopes, milestones, and patterns. This led to much more cooperative progress. While it isn’t always fun, trailblazing requires backtracking because even the best plans cannot account for everything.

Know when to write the map

When learning how to backpack and camp in the wilderness, I was taught to

“Leave no trace.” This principle is great for taking good care of natural resources and lands and allowing others to experience the beauty of untarnished nature. However, when blazing a technical trail, the opposite is true. We should leave lots of traces and even “prepare campsites,” “leave lots of pre-gathered firewood,” and give a clear indication of the next steps of the journey.

This metaphor is about documentation and isn’t always something most people are excited about writing. Leaving good traces can easily take the form of writing good, self-documenting code, and helpful code comments are needed in more complex solutions. We should leave clear trail markers that others can follow when the trail gets complicated or could be easily lost. More than that, we need to know when to write the map.

There is a certain point in blazing a trail where you must slow down and write out some documentation. This shouldn’t be a solo process, as writing documentation is almost always not for ourselves but for others. Good documentation should be requested and reviewed often, especially when it involves trailblazing. A good map can make or break a project, mainly because time is limited, and just because you’ve blazed a trail doesn’t mean you can go back and serve as a personal sherpa to everyone that follows. Good documentation and technical writing is a skill that helps technical trailblazers multiply their impact and save time for even more new trails. As I mentioned earlier, some of the most successful engineers I’ve seen can write well-specified technical tickets that they can hand to others. As a result, these “map-makers” multiply themselves by generating huge backlogs of tickets that help blaze new trails.

Bring others with you

This idea is simple and easy to understand; the more people take a trail, the easier it is to follow. Making a trail is easier with many feet, multiple guides, and extra map-makers. This can be seen in most companies around the concept of technical onboarding. These aren’t new trails for anyone; they are usually well-documented and well-trodden. Since everyone onboards, the path is generally well-defined. Numbers are a massive benefit to trailblazing. I have seen this clearly in roles where we have adopted processes around documenting technical decisions and initiatives. If a few people begin to use the process or “trail” and prove its worth, more engineers follow suit, and the trail gets easier to use. This means trailblazing is easier if you don’t do it alone.

When you set out on a new trail, look for traveling companions who can share the load. Some are better map-makers, and some are better at breaking through the brush. Trail-blazing is more manageable and sustainable when we network and work together to establish the route to our destination.

Build trails that multiply

Lastly, you may be a rockstar who can create a fantastic show. You may produce ten times more than your peers. However, as a technical trailblazer, you can deliver value that will scale well beyond yourself. Others will follow not only your footsteps but also your example and blaze new trails of their own.