Pull to refresh
6
MaratBektemirov@900k

User

4
Subscribers
Send message

Можно было не проверять, это можно сделать хоть на C.

Они не поняли сразу, а потом делают вид, что всегда понимали. Слишком большое увлечение LLM, притупляют человеческие чувства

Переведити с помощью чат гопоты, перепроверьте несколько раз и в arxiv.org
А потом мы на Хабре посмотрим

Да, уж React стал популярным и от этого не знаю уйдем или нет... Даже токенов жрут меньше задачи на React, из-за огромного pretrain. Но я на 100% уверен что проекты на React сгенерированные с помощью LLM, не LLM-independent, потому что такая путаница и когнитивная нагрузка, вообще жесть...

Вспоминаем Skype и Nokia, теперь туда вся Microsoft полетит, по причине LLM-фанатизма. Ну и поделом, что сказать... Останется Mac и Linux

Не смог проверить правду вы говорите или нет.
Ваша библиотека работает только на amd64.

Да, похоже на pr-акцию. Видимо событие рассчитано на массовость, хотя нужны ли будут массово так разрабы и прочии, под вопросом, видимо все по инерции просто движется

Да, здесь падает именно на detectChanges, заново вызовешь – если ок отработает

Ну вот, допустим когда в repeat передали строку
Ну вот, допустим когда в repeat передали строку

А $mol позиционируется как enterprise framework или что-то нишевое?

Да, до бенчей надо добраться) Не сталкивался кстати, с какой-нибудь методикой тестирование на утечку памяти на фронте?

Zero-dependency фреймворк, система реактивности тоже своя. В основе примитивы Rx и RxFunc
https://github.com/MaratBektemirov/cruzo/blob/master/lib/rx.ts

Ну если рассматривать rx значения в шаблоне, то да, это push-семантика. Здесь источник (свойство) сам сообщает шаблону (потребителю) об изменение данных. Я считаю pull-семантику (когда потребитель, т.е. шаблон сам запрашивает у источников данные об изменении) менее производительной. Но вообще у меня возможна и pull-семантика, просто надо будет вызывать this.template.detectChanges(), но для rx свойств это будет не очень.

Скилл для ллмки наверное надо сделать, если это полезный тренд

А HTML у меня не парситься. Т.к. шаблоны cruzo это расширение html, то сразу все что в getHTML можно прописать через innerHTML, а потом просто бежать по нодам и смотреть, где реактивные свойства, где обычные и т.д.

protected initTemplate() {
  const html = this.getHTML();
  
  if (html) {
    this.node.innerHTML = html;
    this.template = new Template({
      node: this.node,
      self: () => this,
      selector: this.selector,
      __tplFile: this.__tplFile,
      domStructureChanged: () => {
        this.domStructureChanged();
      },
    });
    this.template.detectChanges();
    this.updateDependencies();
  }
}

Я считаю, что разработка должна продолжаться без LLM, быть LLM independent. Недавний пример с Fable тому подтверждение

Ну по крайней мере, на моем опыте, для написанного мною фреймворка он пишет код достаточно быстро и корректно, ну тут еще зависит наверное от того как фреймворк соот-ет паттернам. К чему это я, для хорошего LLM не проблема на ходу научиться фреймворка, насчет траты токенов – не знаю как будет

В чем я утрирую? Я только вопрос задал, чтобы на определенные мысли натолкнуть. По факту теперь, в чистом JS нет шаблонизатора и роутера, ХТПП клиента с интерцепторами. Это все типовые случаи.
LLM работает в категориях мыслей людей и для них фреймворки тоже порой нужны.

Хорошо, а если просто все перевести в 0 и 1, это тоже будет более понятно агенту?

А чистый JavaScript код думаете будет более понятный, быстрый и компактный?

Information

Rating
5,225-th
Registered
Activity