• 338 words
I expect some of the software I work on to be in operation for decades, so one question I ponder regularly is how to make its design viable for this assumed lifespan. Experience teaches it's certain that some of the third-party dependencies will breaking changes and even their end-of-life. Full rewrites are rarely feasible, let alone economically viable, so many application languish for a long time as long as they still generate revenue (a branch of my employer just a recently, without any trace of irony, advertised a position for a VB 6 developer). So how not to get trapped by that?
In the implementation context I state the problem as how to factor code in a way that does not dependent of any framework or external library. Beyond my day-to-day issues, in a more principled and generalized way of phrasing it, I think the UI layer needs, but currently lacks, a conceptual equivalent to what an object-relational mapper is for the application layer: a convenient level of abstraction that would enable to swap out the underlying implemention with relative ease, just that instead of the RDBMS it would be the UI toolkit/component library that were to be changed in (mostly) transparent way. I think a great step into that direction would demonstrate the feasibility for one major framework and the Top 10 of its component libraries, but the endgame of such a abstraction layer could also include the framework level.
An alternative and simpler solution would be a self-constrained approach that would deliberately limit itself to use only platform primitives. Although the proposition starts to look more plausible and viable from year to year as the web platform improves (for example customizable selects just very recently landed in Chrome), it would be orders of magnitude harder to advocate for in a corporate environment. It takes would likely take a bit more time and skill to satisfy the whims of your run-of-the-mill Figma jockeys and the exorbitant expectations they tend to raise in other non-technical stakeholders.