Mitigating frontend framework lock-in fears

Question

My team is about to build a new user interface. The team has skills in a range of client-side and server-side technologies. Half the team argue for ASP.NET MVC, and half the team argue for a JavaScript SPA. Either technologies works with our business requirements.

The main point of contention seems to be how to survive the SPA framework churn. E.g Everyone feels more certain Microsoft will be around supporting ASP.NET in 10 years, but we don't feel as certain about a framework like React.

People seem to have addressed this problem with server-side components through the use of industry standards, interfaces and dependency injection.. but there doesn't seem to be the equivalent options for frontend frameworks.

How can we elevate fears of framework lock-in?

Answer 1

Don't get locked in

As advice, that is unhelpful (I know), but that isn't the point.

Set it as a goal in your team To Avoid Vendor Lock-in. The team is full of Engineers, they will find the way.

Shearing Layers

Code has different levels of churn, each rate of churn is a shearing layer.

If you honestly believe that the framework isn't going to be there in 3 years, treat it like any code on such a shearing level. Contain it so that it can be trivially replaced later (shorn off).

Essentially treat the framework + minimal amount of glue code as a plugin to the actual program. If the framework becomes unsupported, you need only replace the framework and shape it to the same plugin interface.

Anything that you might like to live longer than that, is on a lower shearing level. Do the work to shift it out and down to a lower shearing level.

Externalise Assets.

Keep your assets outside of the clutches of the given framework. Treat each asset as if it were to be used in several projects which don't have the given framework.

• Keep your graphics in ubiquitous formats, currently: JPEG, PNG
• Keep your CSS styles external to the framework.
• Keep your business logic separate from the framework. Provide the framework to the business logic by a strong plugin style interface - if you absolutely must and only so far as is necessary
• Write a second app with identical behaviour using a separate framework
• Keep all tests external from the framework. A separate JavaScript test library for unit testing, and browser driven integration tests.
• Ensure the API follows a given interaction standard be that SOAP, REST, Specific HTTP/2 message stream. Even better if there are other tools/frameworks that work with this seamlessly. Also ensure separate API level tests, driven by something other than JavaScript.

Avoid Features

Each feature is a piece of delayed work.

Make sure you know what you are delaying, and whether or not its worth it.

Three Mitigation strategies:

1. Look at the other offers, do they support a feature sufficiently similar that you could lift and shift.

2. Determine if you could provide it directly yourself. Some features are difficult to achieve independently, if you have to shift could you provide them yourself?

3. Can a different feature provide the same business benefit? Say biometric identification, could sms based two-factor be satisfactory?

The more yeses from those strategies the safer it is to adopt a feature.

The more noes the more you should avoid those features, at least if you want to avoid lock-in.