Если в России всё закупать, то скорей всего в пролёте в плане подтверждения и т.п. Но с другой стороны, никто вам не мешает взять одну лицензию и шарить по всей компании. Судя по их разговорам, никто не будет препятствовать этому, ибо подразумевается что лицензия и в ci/cd будет шариться
В защиту Феликса скажу, он в в аи движ решил залететь за долго до гермеса и клешни. Он давно вырос из блогинга, поэтому решил пойти в бизнес, а ai - сейчас самых ходовой товар )
тут как говорится "так исторически сложилось", многие либы сразу тянут за собой бинарники, чтобы работать под конкретную ос, или патчат зависимости за собой, чтобы конфликтов не было в проекте , или вообще тебе файлы в проект генерировать при установке. Мы платим большой гибкостью, большим количеством дыр. Но благо кроме стандартных пакетных менеджеров, мы имеем условный pnpm, который позволяет максимально минимизировать риски
Новость - это буквально цитаты Адама и чуток доплнений от меня, что лучше 100 раз подумать, чем брать технологию сейчас.
Не забываем что Tailwind Labs - это не только фреймворк, но и вся команда что делает платные ui киты. Поэтому вполне логично, что штат был раздутым для продажи. Официальных точных цифр нигде нет и их нигде не покажут скорей всего, ибо главная цель заявлений - поднять шумиху, чтобы инвесторы помогли.
В целом такая проблема сейчас у всего опенсорса. Люди идут в первую очередь в чаты с llm, когда у них проблемы, а не в доки. Поэтому получаем снижение трафика на оных, что не даёт им получать деньги с рекламы или свои платные решения продвигать.
Тут остаётся 2 стула - продаться условному vercel (подставь любого айти гиганта) или вводить часть функционала за пейвол.
Так тут и идёт проблема что у тебя становится код слишком заполненным комментариями и уже каша из нейрослопа и твоих.
а spec блок как раз отделяет спецификацию для LLM от уже действенных твоих записей и плюс для человека - у тебя есть буквально readmy для любого компонента.
Да, понимаю, почему кажется, что в React push подход.
Например пропсы передаются вниз по дереву, а зависимости в хуках типа useEffect выглядят как управление тем, что пушить в стейт. Но если копнуть глубже, React ближе к pull-based системе. Компоненты сами запрашивают данные (пропсы и состояние) на момент рендера, а не получают их асинхронно, как в push системах вроде RxJS. Зависимости в хуках — это больше про оптимизацию и контроль, а не про пуш данных. Хотя, если смотреть со стороны системы, React инициирует рендеринг, что можно интерпретировать как push. Но с точки зрения данных и компонентов— это скорее pull.
Так что Раян, может, и не совсем глупость написал, просто другой угол зрения.
Тут скорее не про правильность подходов, а то что тот и тот варианты дают свою плюсы в работе. Вапор же позволяет критичные участки кода, где нужна именно производительность, перевести на работу с нативным API DOM , вместо VDOM.
UI кит продавали для Русских, не думаю что будет проблема взять лицензию )
Если в России всё закупать, то скорей всего в пролёте в плане подтверждения и т.п.
Но с другой стороны, никто вам не мешает взять одну лицензию и шарить по всей компании. Судя по их разговорам, никто не будет препятствовать этому, ибо подразумевается что лицензия и в ci/cd будет шариться
В защиту Феликса скажу, он в в аи движ решил залететь за долго до гермеса и клешни.
Он давно вырос из блогинга, поэтому решил пойти в бизнес, а ai - сейчас самых ходовой товар )
если правильно понял, то да, напрямую, взломали автора и закинули в обход всех вредоносный пакет в зависимости
тут как говорится "так исторически сложилось", многие либы сразу тянут за собой бинарники, чтобы работать под конкретную ос, или патчат зависимости за собой, чтобы конфликтов не было в проекте , или вообще тебе файлы в проект генерировать при установке. Мы платим большой гибкостью, большим количеством дыр. Но благо кроме стандартных пакетных менеджеров, мы имеем условный pnpm, который позволяет максимально минимизировать риски
И правда код вставил, а абзац пропустил, когда текст переносил, поправил, благодарю.
upsert - "update and insert", что по факту и делает метод, считайте просто алиас). Но соглашусь что может реально запутать, заменю на более понятное.
Так пример есть
Symbol.Dispose, думаю что логично что async приставка требует await при обращенииНовость - это буквально цитаты Адама и чуток доплнений от меня, что лучше 100 раз подумать, чем брать технологию сейчас.
Не забываем что Tailwind Labs - это не только фреймворк, но и вся команда что делает платные ui киты. Поэтому вполне логично, что штат был раздутым для продажи. Официальных точных цифр нигде нет и их нигде не покажут скорей всего, ибо главная цель заявлений - поднять шумиху, чтобы инвесторы помогли.
В целом такая проблема сейчас у всего опенсорса. Люди идут в первую очередь в чаты с llm, когда у них проблемы, а не в доки. Поэтому получаем снижение трафика на оных, что не даёт им получать деньги с рекламы или свои платные решения продвигать.
Тут остаётся 2 стула - продаться условному vercel (подставь любого айти гиганта) или вводить часть функционала за пейвол.
Так тут и идёт проблема что у тебя становится код слишком заполненным комментариями и уже каша из нейрослопа и твоих.
а
specблок как раз отделяет спецификацию для LLM от уже действенных твоих записей и плюс для человека - у тебя есть буквально readmy для любого компонента.Спасибо за пояснение, материал поправил, чтобы не вводить в заблуждение
Да, понимаю, почему кажется, что в React push подход.
Например пропсы передаются вниз по дереву, а зависимости в хуках типа useEffect выглядят как управление тем, что пушить в стейт. Но если копнуть глубже, React ближе к pull-based системе. Компоненты сами запрашивают данные (пропсы и состояние) на момент рендера, а не получают их асинхронно, как в push системах вроде RxJS. Зависимости в хуках — это больше про оптимизацию и контроль, а не про пуш данных. Хотя, если смотреть со стороны системы, React инициирует рендеринг, что можно интерпретировать как push. Но с точки зрения данных и компонентов— это скорее pull.
Так что Раян, может, и не совсем глупость написал, просто другой угол зрения.
Тут скорее не про правильность подходов, а то что тот и тот варианты дают свою плюсы в работе.
Вапор же позволяет критичные участки кода, где нужна именно производительность, перевести на работу с нативным API DOM , вместо VDOM.
Перевод, а если быть точнее адаптации презентации - https://talks.sxzz.moe/2024-10-vue-fes-japan/1.
ссылка, как обычно, указана в шапке.