[ojame]

I’m a Tech Lead for a SaaS product that’s been around since ~2010. Four or so years ago we stared piecemeal transitioning away from jQuery/Backbone to React. Nearly all of our main UI is React now, but it’s still pretty coupled to Backbone. There’s a lot more risk removing that, so we’ve not had enough of a reason to yet.

Basically the high touch (from a developer point) areas of the app are always the most modern and the first place to get whatever treatment we transition to (React, typescript etc) and there’s some really untouched areas that might remain prehistoric for years, and that’s fine.

Its worked pretty well for us, and I can’t see why it wouldn’t continue that way.

[fhd2]

I'd call that a continuous rewrite, which is also the strategy that worked best for me. If you're not willing to make these investments as you go, you may well end up in a full-rewrite-or-die situation, I suppose. Comes down to how aggressively management prioritises short term results. I personally have never worked on a code base that far gone, but I can imagine they're out there.

[taeric]

The big risk of letting the high touch areas be what get migrated to the modern stack, is that for many companies this is largely driven by the fashion of new hires. And letting new hires drive the technical choices isn't necessarily bad, but you do have a major risk of them not understanding why things were there.

I'd say, historically, you were also lucky in the timing. The last 4 years have been absolutely rock solid for frontend development, compared to the time before. Still way more fluid than I personally think it should be, but I'm willing to ack that things have gotten a lot more stable.

Oddly, the backend has gotten worse in these years. The amount of service related churn that has happened in the past decade has been impressive. And mostly not in a good way. I can hope that we are going to be a bit more stable now.

[ojame]

High touch in the sense of being driven by product development. We let everyone make technical choices, sometimes autonomously but sometimes as a pitch. A part of technical leadership in smaller organisations is mitigating a lot of that “new hire/shiny thing” risk.

We used react a lot externally to the main product as early as 2014, but didn’t introduce it into the main product until we were comfortable.

[taeric]

Apologies if it felt like I was questioning your choice. I meant my post as an addition.

Using things outside the critical path is definitely the right choice. Making things to throw away is also great.

I do get worried, sometimes, that it is also correct to let the new coders pick the styles and frameworks. Letting them choose is a huge boon to their productivity. And letting them advance on a bet like this can payoff really well. Just expect losses along the way.