Выбор инструментов в условиях ограниченной определённости

Некоторое время время назад выбирали мы между fetch и axios в проекте. Ну типа очевидно, что для современных проектов, когда все пишется с нулей тащить старый большой axios - борщ. Ведь да? Нет.

Выбирать fetch или XMLHttpRequest (упаси хоспади) можно и даже нужно, если вы готовы писать обёртку длинною в жизнь проекта, перекрывая каждый новый случай, который вам понадобился при работе с ним, но которого у него нет. Например интерсепторы или какая-нибудь хитрая работа с заголовками, или пост/пред обработчики и т.д. В целом в этом ничего сложного нет и в 2к23 наверное уже нет сильной проблемы накидать 100-200 строк на тайпскрипте, чтобы это реализовать. Но внимание вопрос - вы уверены на старте проекта, что сразу предугадаете все нюансы работы в легаси или строящимся api?
Если скажете "да", то вы либо еще молоды и слишком уверены в людях и себе, либо у вас понятный маленький проект с хорошей полной спецификацией. Но, даже в этом случае, вы не застрахованы от изменений спецификации в сторону необходимости имплементации вещей, которых в fetch по умолчанию нет и которых вы не заложили в начале. Это axio-ма =)

Правильным путём построения приложения будет выбрать решение перекрывающее все ваше потребности с горкой и выстроить над ними абстракцию, где детали реализации можно будет подменить в любой момент. Например, когда проект подходит к концу или вам ударила моча в голову посреди проекта, вы решили переехать на fetch, - просто подменяете axios в этой абстракции на fetch и ваше приложение продолжает работать, как и раньше.
Инверсии зависимостей, солид, ю ноу, бла-бла-бла..

Ну ок, а почему сразу то не бахнуть fetch? Если он будет за слоем абстракции?

Чтоб код писать полезный сразу, а не реализовывать инфраструктурные функции, просто потому что вы можете.

Fetch vs Axios тут особо не причём на самом деле, просто к слову пришлись.

Просто одно из самых страшных вещей в которую можно удариться в разработке проекта при его реализации - это несвоевременные детали.

Хорошей аналогией будет прогрузка progressive jpeg (https://i.stack.imgur.com/SpGmy.jpg). Вот проект лучше строить также (имхо), от общего к частному, а не наоборот. Иначе может получится, что проект напишется на половину. И это будет шикарно написанная половина. Но полезного в ней будет ничего.

Поэтому выбирая инструмент в условиях ограниченной определённости руководствуйтесь имплементацией готового решения широкого спектра, которое (в частности) решает требуемую задачу и упаковывайте это дело в возможность подмены реализации в будущем.
Это не сложно, но сэкономит кучу времени в будущем.

PS: Но иногда дешевле просто переписать 😉