I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
I think software that is easier to adopt is additive instead of a replacement. If you have plain JavaScript and want to use TypeScript, you can probably set it up without having to refactor code (or at least limit the upfront refactoring). In that regard, I think TypeScript has a thoughtful adoption path because it is not a new language entirely and was designed with that in mind. I think this extends to other language's optional type systems and superset languages like SCSS. But even with that, there still might be some gotchas and pain points to adopting it in an existing codebase.
For anything else that is more of a replacement rather than supplemental (like going from Node to Deno), I'm not sure if there is a great adoption path. Going for the full application rewrite is usually not a good idea because it may take a while, cost a lot, and there is no guarantee that the code or system will be any better off than it is now. Doing an incremental adoption also has its issues because you have to develop new features in the new system while maintaining and deprecating things in the old system. Depending on how monolithic things were in the old system, it may be time consuming to get the two to play nicely together or get to feature parity.
I think the thoughtful adoption path for anything is asking: why? Is there something wrong with the existing system that it will solve? If not, stay on the old system until it makes good business sense to think about adopting something else.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think software that is easier to adopt is additive instead of a replacement. If you have plain JavaScript and want to use TypeScript, you can probably set it up without having to refactor code (or at least limit the upfront refactoring). In that regard, I think TypeScript has a thoughtful adoption path because it is not a new language entirely and was designed with that in mind. I think this extends to other language's optional type systems and superset languages like SCSS. But even with that, there still might be some gotchas and pain points to adopting it in an existing codebase.
For anything else that is more of a replacement rather than supplemental (like going from Node to Deno), I'm not sure if there is a great adoption path. Going for the full application rewrite is usually not a good idea because it may take a while, cost a lot, and there is no guarantee that the code or system will be any better off than it is now. Doing an incremental adoption also has its issues because you have to develop new features in the new system while maintaining and deprecating things in the old system. Depending on how monolithic things were in the old system, it may be time consuming to get the two to play nicely together or get to feature parity.
I think the thoughtful adoption path for anything is asking: why? Is there something wrong with the existing system that it will solve? If not, stay on the old system until it makes good business sense to think about adopting something else.