«Зачем Javasript-у DI контейнер?»

Это очень сомнительное решение, с какой бы стороны я не пытался на него смотреть

DI-контейнер на чистом JavaScript без TypeScript и reflect-metadata

Built on, не значит «сахар». Вы выделили то, что вам понравилось, но ведь сразу за выделенным текстом идет: but have some syntax and semantics that are unique to classes.

DI-контейнер на чистом JavaScript без TypeScript и reflect-metadata

Javascript классы это просто "синтаксический сахар"

Предрассудки...

class Bar {
  method1() {
    // ...
  }

  method2() {
    // ...
  }
}

class Foo extends Bar {
  
  // Static initialization block
  static {
    try {
      
    } catch {
      
    }
  }

  // Private static field
  static #field = 1;

  // Private static method
  static #method() {}

  // Private static getter
  static get #foo() {
    return this.#privateField;
  }

  // override parent method
  method1() {
    // ...
  }

  // extend parent method
  method2() {
    super.method2()
    // ...
  }

  // child private method
  #method() {}
}

Подскажите, это «синтаксический сахар» над чем?

DI-контейнер на чистом JavaScript без TypeScript и reflect-metadata

Нужен. Очень не хватает. Конечно, все себе по разному представляют js, но если отбросить предрассудки типа «корочки красят в своих интерфейсах», то вполне понятно зачем. JS такой же ЯП как и многие другие, с такими же примерно проблемами, на нем решают примерно такие же задачи и т.д.

DI-контейнер на чистом JavaScript без TypeScript и reflect-metadata

Как только у вас появляется container.register, это уже service locator. Вообще, все попытки реализовать тру di в js в конечном итоге сводятся к созданию локатора.

В вашем решении меня смущают анонимные классы, я привык к instanceof.

Передача параметров объектом тоже смущает. Аргументы в пользу — убедительные, но это софистика. Дело в том, что если мне нужен один-два аргумента, я не запутаюсь, а если 10, то стоит пересмотреть этот класс, с ним явно что-то не так.

Но попытка интересная.

Галлюцинации: почему LLM «тупеют» от «умных» промтов

Подключите эту же модель через LM Studio к Claude Code, обозвав ее Claude Sonnet, и вы увидите, что она прекрасно работает, используя абсолютно все возможности самого Claude Code.

Полный игнор релевантного скила

Даже после прямого вопроса продолжает про React Router + выдумала несуществующий

Не смогла правильно вызвать то ли скил, то ли саб-агента + спутала таски с todo list

Галлюцинации: почему LLM «тупеют» от «умных» промтов

Не знаю, кто эти ребята что плюсуют ваши комментарии, видимо ваши друзья. Других объяснений этому поведению нет. Теперь по существу:

Ваши выводы про Qwen3 Coder Next не подтверждаются моей практикой

Не интересуют меня ваши субъективные ощущения. Приведите пруфы и цифры, а не ссылку на ютюб.

В вашем случае проблема кроется не в самих моделях, а в Qwen Code и его настройках

Вы прочитали статью, но не заметили, что добрая ее половина как раз об этом? Вы даже TL;DR пропустили, давайте напомню:

TL;DR: CLI-агенты галлюцинируют даже с мощными моделями, потому что системные промпты раздуты лишними примерами, повторами и нерелевантными терминами. Это математически бьёт по вниманию модели и не даёт того эффекта, который обещают best-practices. Я форкнул Qwen Code, вычистил системные промпты, и на 4 моделях получил стабильный вызов нужных скиллов, меньше галлюцинаций и на 35-53% сократил расход токенов. Без потери качества.

Дальше вы пишите:

Насколько я помню, у Qwen Code он завернут в специфические xml теги

Давайте приведу еще один отрывок из статьи, которую вы читали:
Интересно, что доступные скилы в Qwen Code пакуются в некие специальные XML директивы (назначение которых мне неизвестно), и отправляются как сообщение пользователя а не системы (что похоже на баг).

Как же вы статью то читали? Точнее какую? Эту точно нет.

Вам определенно стоит покопать именно в эту сторону.

В какую? Не в сторону ли инструмента, то есть CLI, о чем как раз вторая половина статьи? О том куда я копал, зачем, что изменил и какие результаты получил?

Вы просто не умеете его готовить. Я специально написал это так категорично, чтобы дать вам заряд энергии выйти из отрицания и разобраться почему же он не работает у вас.

Пафос и демагогия.

Галлюцинации: почему LLM «тупеют» от «умных» промтов

Из ваших комментариев я могу сделать только один вывод: статью вы не читали.

Галлюцинации: почему LLM «тупеют» от «умных» промтов

не подтверждаются моей практикой

А пруфы будут, или мы просто должны поверить вашей «практике»?

То, что у вас она наотрез отказывается работать

Отказывается работать, и игнорирует инструкции системного промпта – это совершенно разные вещи. Для агентских систем reasoning обязателен, и проведенный мной эксперимент это подтверждает. Имея описания минимум двух релевантных скилов, Qwen3 Coder Next неспособен прийти к выводу, что надо бы их использовать. То есть ему не хватает умений даже инструменты свои использовать, не говоря уже о выполнении комплексных, многоступенчатых задач.

Whitepaper Сбера «AI-Disrupt PDLC»: разбор для тех, кто пишет код

Я принимаю код от агента, не потому что он мне нравится, а из-за кривизны инструментов, так как агенты печатают в консоль только часть изменений. Из-за этого приходится нажимать yes, а потом смотреть что он там нашкодил. Так что статистика эта бесполезная

Минцифры зафиксировало спад инвестиционной активности в телекоме и IT

Ухх… хорошо, что дело не в блокировках и отключении интернета.

Как я сделал групповые звонки в React Native мессенджере: WebRTC, CallKit и грабли production'а

В production это даёт задержку 8-12 секунд от момента "позвонить" до первого аудио. Причина: современные мобильные устройства собирают ICE-кандидаты медленно — особенно в мобильных сетях, особенно если STUN/TURN серверы далеко. ICE gathering может занимать 3-5 секунд на стороне caller, потом ещё 3-5 секунд на стороне receiver. 

Звучит как вечность. Есть какие-то примеры реальных измерений с дампами?

Что такое Реактивное Программирование

Эмодзи у Дмитрия были задолго до распространения LLM.

Факт))

Фронтенд — это REST-сервер

Автор REST в своей диссертации , в которой он собственно представил REST, очень явно обосновывает свое решение ссылаясь на другую работу, ссылку на которую я также привел в статье. Суть архитектуры в том, что она явно обозначает ограничения которые должны быть соблюдены для достижения результата, при этом архитектура не диктует «как» реализовывать. Он пишет:

We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request

То есть stateless – не REST, а «коммуникация» между клиентом и сервером. Это в том числе вытекает из ограничений остальных компонентов системы, например транспорта. Каждый TCP пакет в последовательности должен содержать идентификатор соединения, каждый Request должен содержать идентификатор пользователя и т.д.

Тоже остается справедливым и для фронтенда, где каждый Request (Event), содержит всю необходимую информацию. Когда мы пишем el.addEventListener('input', cb), браузер передает не просто строку с новым текстом, полагая что мы понимаем от какого именно <input /> оно пришло, а Event со всей необходимой информацией, делая нашу «шину» stateless по природе.

Почему JS/TS — не функциональный язык (и почему это важно понимать)

Что вы имеете ввиду, есть пример из других яп?

Имеется ввиду что map, filter и т.д. возвращают промисы? Это же принесет больше проблем, нет? Что если там девять элементов, и на обработке шестого произошла ошибка? Или например map отработал, а на reduce в третьем элементе произошла ошибка?

Почему JS/TS — не функциональный язык (и почему это важно понимать)

А для чего это может быть нужно? Что с ними делать?

Почему JS/TS — не функциональный язык (и почему это важно понимать)

Вы из какого года пишете?

Через пару лет может и до asynciterator дойдут

Завезли почти десят лет назад

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncIterator

Теневой рынок GitHub звезд

проект с сотнями звезд

Никогда бы в голову не пришло, накручивать. Даже больше скажу, для меня, как автора, мне важно не количество, а от кого эти звезды.

Как правильно реализовать кнопку «Назад» во Vue: просто о сложном

и что она всегда делает ровно тоже самое что нативная браузерная кнопка

Я как раз про нативную браузерную кнопку назад и писал, и да, она всегда делает ровно то, что должна.

В действительности же это далеко не всегда так

В действительности как раз все так. Браузерная кнопка назад имеет предсказуемое и стабильно поведение.

Как правильно реализовать кнопку «Назад» во Vue: просто о сложном

А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.