На этапе альфа и бетта девелопмента docs-as-code очень удобна. При меняющемся коде отдельная документация быстро устаревает, у разработчиков пропадает мотивация ее поддерживать (отнимает много времени и усилий)

Javadoc (странно, что он ни разу не упомянут) является в данном случае для меня идеалом данного подхода, и за 25 лет использования доказал свою практичность.

Однако проблема в средствах генерации для других систем.

Взять популярные фреймворки - Vue.js например. Есть отдельные индивидуальные попытки создать jsdoc и прочее, но хорошего качественного средства так почему-то никто и не сделал. А жаль. Это очень нужная штука даже для команды из одного-двух программеров, не говоря уж больших группах разработчиков.

Это два подхода, но намного более важные, чем кажется

Первый отражает концепции абстракции и инкапсуляции ООП

base-icon - это класс. С определенными свойствами и методами. Иконка - свойство.

Вы же вместо создания объектов одного класса создаете множество классов

Классы, абстрагирование, инкапсуляция нужны на уровне программиста, а не компилятора или сборщика. Именно чтобы код был "прозрачный и красивый"

И Vue.js возможно более других фронтэнд фреймворков старается придерживаться ООП парадигмы

У вас в шаблоне новый тэг

Это и есть новый web component

Пришедший программер начнет его искать и не найдет

Свой base-icon - 30 строчек ясного кода и переиспользуемый! для производительности при надобности Vue компонент

Ваш подход - необоснованное закулисывание очевидной логики, усложнение билда, усложнение читаемости кода

Когда текста для перевода много, удобно делать локали не файлами json, а подпапками с файлами json

Подпапка 'ru'
В ней файлы account.json, footer.json и так далее
В каждом соответствующие переводы, иерархично
Обращение: $t("account.profile.usernameTitle")

можно в этих файлах задействовать массивы и выводить их циклом в тэгах li или p по надобности

Много текста, но так и не понял, чем подход кастомных иконок лучше <q-icon name="mdiDogSide" /> (в моем случае, самописный <base-icon> с font-size, color и другими няшками вроде умения работать со спрайтами)

Зачем плодить лишние сущности компоненты?

Придет новый программер
Увидит компонент
Начнет искать его и увидит сложную генерацию
Тихо заматерится, на "прозрачный и красивый код"

И для большого проекта глобальные переменные уже плохо идут. Удобней иметь конфиг в json формате - app.config.json

И доступ - Vue.$appConfig.oauth.google.clientId

Удобно также иметь app.config.local.json с переопределенными локальными переменными

vue.config.js:

process.env.VUE_APP_CONFIG = JSON.stringify({
  ...require('./app.config.json'),
  ...require('./app.config.local.json'),
});

main.js:

Vue.prototype.$appConfig = JSON.parse(process.env.VUE_APP_CONFIG);

Что и в каком формате лежит в директории docs?
Или для переводной статьи это спрашивать нет смысла?

Вроде бы говорили о простых PHP фреймворках

Не понимаю, как перескочили на Yii

Бенчмарки есть. Разные. Большинство, конечно, аффилированных, так что лучше самому повыбирать, если интересно

Slim, по сути, просто роутинг, а может понадобиться еще MVC, приблуды для Rest , а model CI4 данных вообще очень приятная и красивая штука для работы с БД.

По закону 20/80 CI4 дает 80% нужного функционала за 20% "сложности" проекта

Restful API со сложной бизнес логикой и трехэтажными запросами к БД отлично идёт на CI4

С учетом того, что SPA нынче вполне себе стандарт в web приложениях, CI4 прекрасно подходит для полноценного бэкэнда

Ну а его простота даёт ему скорость по сравнению с другими PHP фреймворками