TypeScript, VSCode и GitHub - это всё продукты Microsoft. Вот поэтому с JS/JSdoc так неудобно работать в VSCode. Я этого в IDEA вообще не чувствовал. А в VSCode - да, там надо писать types.d.ts в проектах, чтобы JSDoc заработал.
"Talk is cheap. Show me the code." (c) Linus Torvalds
Я вам свой код показал. Вот ещё ИИ-код с DI. Покажите свой продукт.
Да и по производительности кодогенерации видно.
Важна не производительность, а управляемость. А то, как говорила одна секретарша из анекдота: "Я могу печатать со скоростью 1000 знаков в минуту. Но такая ерунда получается".
DI очень популярен в таких языках, как Java и C#, на которых строят совсем не персональные веб-странички. DI используется в Magento обеих версий. Во второй версии как раз и есть несколько миллионов строк на PHP и это только в ядре, без учёта сторонних расширений.
Если вы считаете, что статическое связывание JS-кода на этапе компиляции через импорты - хорошее решение, то ознакомьтесь с причинами появления архитектурного шаблона Inversion of Control. А если вы считаете, что true IoC - это Ambient Context, а DI - лажа, то вы явный сектант. Авторы книги "Dependency Injection" Steven van Deursen и Mark Seemann прямо называют Ambient Context антипаттерном в IoC и формулируют причины.
Чтобы экономились токены как раз и нужна декомпозиция и позднее связывание. В npm-реестре свыше 4 млн. пакетов, а строк кода - сотни миллиардов. Тем не менее, и человек, и ИИ-агент спокойно могут выдернуть любой пакет из этой кодовой базы и использовать в своём приложении.
"Кожаные" уже всё придумали, "силиконовым" осталось только использовать.
Если спросить у разных Ai построить архитектуру Ai first приложения и какие антипаттерны лучше не использовать то все ai вам скажут что di это зло.
Это я не проверял, но уверенно предположу, что это ложь. DI десятилетиями (!!) использовалась "кожанными" в разных ЯП, особенно в "кровавом энтерпрайзе". Это проверенный временем и практикой архитектурный шаблон, на котором, кстати, модели сами учились программировать.
Да, и вообще, ваша LLM ответит вам то, что вы хотите услышать. Они те ещё манипуляторы! Мой GPT-чат от DI в JS в восторге. Вот пример кода, полностью написанного ИИ (Codex-агент), и там DI ¯\_(ツ)_/¯
Правда, тут JSDoc вместо "строгой типизации", но для навигации по коду этого хватает, а в runtime JSDoc не используется точно так же, как и "строгая типизация" TypeScript. Зато одинаково хорошо работает и для фронта, и для бэка.
На этом фоне у традиционных DI-решений есть три пути, и все три — тупиковые
Есть ещё масса нетрадиционных тупиковых путей. Надо только покопать.
Я, кстати, у себя вообще отказался от container.registerXXX , оставил только для тестового режима. Всё остальное "на магии", как вы говорите - через настройку маппинга пространства имён на пути в файловой системе (калька с Java с их classpath и PHP с PSR-4).
Зато такой подход даёт возможность вообще отказаться от статических импортов (они есть только в Composition Root) и добавить в приложения такие экзотические для JavaScript вещи, как interface.
То, что это, кроме меня, нафиг никому не надо в JS - это отдельный вопрос. Но у меня есть :)
Если взять фрагмент размером 67К токенов (это примерно 29 глав романа "Анна Каренина") и попросить любую модель произвести замену "Степан Аркадьевич" на "Павел Петрович" с учётом падежей, то результирующий текст с правильными заменами и будет представлять собой практический предел возможностей данной модели.
На момент написания статьи GPT-5 через веб-интерфейс даёт максимальный выходной результат примерно в 4К токенов (12.5К кириллических символов), а веб-интерфейс для Gemini 2.5 Pro - 12К токенов (37К кириллических символов). При этом модели ведут себя по-разному: GPT-5 просто дополняет результат необработанным текстом после 4К (без замены Степана на Павла), а Gemini перестаёт выдавать результат в браузер и рапортует о потере подключения к интернету, стирая при этом уже полученный результат.
Производители этих моделей заявляют о теоретических пределах в 128К токенов для GPT-5 и 64К токенов для Gemini 2.5 Pro, но через веб-интерфейс такие пределы на практике недостижимы.
Я проводил такой простой эксперимент, чтобы узнать реальные возможности Моделей, а не заявленный маркетинговый булшит производителя. Думаю, модели и сейчас ещё не вышли за 67К токенов повторяемого результата. Это чертовски энергетически затратно - экспоненциальное развитие ИИ требует экспоненциальных энергетических затрат, а у нас за околицей углеводороды дорожают...
Ну так это так и есть - агенты могут обновлять кодовую базу по тикетам пользователей и выкатываться на прод. В ограниченных мной пределах. Что не так-то? Где тут заявка на полный доступ? Вы можете предоставить по такой схеме доступ к своему сайту и установить свои пределы. На свой страх и риск. Welcome, как говорится.
Ну, я не универсальный проблем солвер. У меня есть ответы лишь на определённый класс вопросов. Да и не то, чтобы есть, я их всё ещё ищу. Но спасибо, что поделились своим мнением :)
Я имею опыт взаимодействия именно с кодексом. С Copilot'ом как-то не сложилось. Плюс, я могу агента менять, на того же Клода, например. А вместо гитхаб взять гитлаб. Ну, могу думать в эту сторону. А решение от Майкрософта - это вендор-лок.
А где здесь критика? В том, что "ресурс можно превратить в тыкву"? Я согласен, что можно. Это не так просто сделать, но можно. Абсолютной защиты не бывает, но хороша та защита, затраты на преодоление которой не оправдываются "призом". Мне, например, не сложно откатить мой сайт на несколько коммитов назад, если что-то пойдёт не так.
А так-то я тоже не во все свои проекты всех подряд запускаю.
У вас же не вижу ответа в статье
А ответ простой: "серебряной пули не существует". Каждая задача требует своих решений. У вас - свои задачи, у меня - свои. Применять мои ответы к вашим задачам... ну как-то неправильно, что ли. Сами ищите.
TypeScript, VSCode и GitHub - это всё продукты Microsoft. Вот поэтому с JS/JSdoc так неудобно работать в VSCode. Я этого в IDEA вообще не чувствовал. А в VSCode - да, там надо писать types.d.ts в проектах, чтобы JSDoc заработал.
А так-то статистика разная бывает - https://innovationgraph.github.com/global-metrics/programming-languages
Talk is cheap. Show me the code.
"Talk is cheap. Show me the code." (c) Linus Torvalds
Я вам свой код показал. Вот ещё ИИ-код с DI. Покажите свой продукт.
Важна не производительность, а управляемость. А то, как говорила одна секретарша из анекдота: "Я могу печатать со скоростью 1000 знаков в минуту. Но такая ерунда получается".
DI очень популярен в таких языках, как Java и C#, на которых строят совсем не персональные веб-странички. DI используется в Magento обеих версий. Во второй версии как раз и есть несколько миллионов строк на PHP и это только в ядре, без учёта сторонних расширений.
Если вы считаете, что статическое связывание JS-кода на этапе компиляции через импорты - хорошее решение, то ознакомьтесь с причинами появления архитектурного шаблона Inversion of Control. А если вы считаете, что true IoC - это Ambient Context, а DI - лажа, то вы явный сектант. Авторы книги "Dependency Injection" Steven van Deursen и Mark Seemann прямо называют Ambient Context антипаттерном в IoC и формулируют причины.
Чтобы экономились токены как раз и нужна декомпозиция и позднее связывание. В npm-реестре свыше 4 млн. пакетов, а строк кода - сотни миллиардов. Тем не менее, и человек, и ИИ-агент спокойно могут выдернуть любой пакет из этой кодовой базы и использовать в своём приложении.
"Кожаные" уже всё придумали, "силиконовым" осталось только использовать.
Тут согласен.
Это я не проверял, но уверенно предположу, что это ложь. DI десятилетиями (!!) использовалась "кожанными" в разных ЯП, особенно в "кровавом энтерпрайзе". Это проверенный временем и практикой архитектурный шаблон, на котором, кстати, модели сами учились программировать.
Да, и вообще, ваша LLM ответит вам то, что вы хотите услышать. Они те ещё манипуляторы! Мой GPT-чат от DI в JS в восторге. Вот пример кода, полностью написанного ИИ (Codex-агент), и там DI ¯\_(ツ)_/¯
Положительно отношусь. Даже запилил свой DI-контейнер под чистый JS - https://github.com/teqfw/di
Правда, тут JSDoc вместо "строгой типизации", но для навигации по коду этого хватает, а в runtime JSDoc не используется точно так же, как и "строгая типизация" TypeScript. Зато одинаково хорошо работает и для фронта, и для бэка.
Есть ещё масса нетрадиционных тупиковых путей. Надо только покопать.
Я, кстати, у себя вообще отказался от
container.registerXXX, оставил только для тестового режима. Всё остальное "на магии", как вы говорите - через настройку маппинга пространства имён на пути в файловой системе (калька с Java с их classpath и PHP с PSR-4).Зато такой подход даёт возможность вообще отказаться от статических импортов (они есть только в Composition Root) и добавить в приложения такие экзотические для JavaScript вещи, как
interface.То, что это, кроме меня, нафиг никому не надо в JS - это отдельный вопрос. Но у меня есть :)
А вот это - зря. Ложная скромность. Как говорят критики произведений Булгакова, "Сами предложат и сами всё дадут" работает только с "люлЯми".
Вот канал - https://telegram.me/tassadarai
https://habr.com/ru/articles/948282/
Я проводил такой простой эксперимент, чтобы узнать реальные возможности Моделей, а не заявленный маркетинговый булшит производителя. Думаю, модели и сейчас ещё не вышли за 67К токенов повторяемого результата. Это чертовски энергетически затратно - экспоненциальное развитие ИИ требует экспоненциальных энергетических затрат, а у нас за околицей углеводороды дорожают...
Спасибо. Не надо откатывать, пусть остаётся как есть. Не будем повышать энтропию :)
Ну так это так и есть - агенты могут обновлять кодовую базу по тикетам пользователей и выкатываться на прод. В ограниченных мной пределах. Что не так-то? Где тут заявка на полный доступ? Вы можете предоставить по такой схеме доступ к своему сайту и установить свои пределы. На свой страх и риск. Welcome, как говорится.
Ну, я не универсальный проблем солвер. У меня есть ответы лишь на определённый класс вопросов. Да и не то, чтобы есть, я их всё ещё ищу. Но спасибо, что поделились своим мнением :)
И в каком месте автор "говорил о полном доступе"? Вы очень странный для айтишника.
Да, конечно. Вот промпты и весь workflow - http://cms.teqfw.com/output.zip
Можно и посерьезнее, но, конечно, не через доступ всем, кому ни попадая.
Никогда. Теперь уже никогда. Привыкайте.
Я имею опыт взаимодействия именно с кодексом. С Copilot'ом как-то не сложилось. Плюс, я могу агента менять, на того же Клода, например. А вместо гитхаб взять гитлаб. Ну, могу думать в эту сторону. А решение от Майкрософта - это вендор-лок.
Это делается путём изменения промптов к агентам. В других репо у меня другой workflow.
Уже сделали :)
А где здесь критика? В том, что "ресурс можно превратить в тыкву"? Я согласен, что можно. Это не так просто сделать, но можно. Абсолютной защиты не бывает, но хороша та защита, затраты на преодоление которой не оправдываются "призом". Мне, например, не сложно откатить мой сайт на несколько коммитов назад, если что-то пойдёт не так.
А так-то я тоже не во все свои проекты всех подряд запускаю.
А ответ простой: "серебряной пули не существует". Каждая задача требует своих решений. У вас - свои задачи, у меня - свои. Применять мои ответы к вашим задачам... ну как-то неправильно, что ли. Сами ищите.
Попробуйте, не голословьте.