Мир сегодня с "Юрий Подоляка"

Труха⚡️Україна

查看

Николаевский Ванёк

查看

Мир сегодня с "Юрий Подоляка"

查看

Труха⚡️Україна

查看

Николаевский Ванёк

查看

kravets b.log();

Самые отборные репосты только на этом канале!
Ставить свои звёздочки⭐️ сюда - https://github.com/kravetsone
По вопросам - https://t.me/noname2544

TGlist 评分

类型公开

验证

未验证

可信度

不可靠

位置

语言其他

频道创建日期Jul 07, 2021

添加到 TGlist 的日期

Dec 26, 2024

我是频道所有者

变更历史

关联群组

Джаваскриптизёрная

Telegram频道 kravets b.log(); 统计数据

详细信息

订阅者

316

24 小时00%一周

20.6%一个月

279.2%

引用指数

0

提及0频道上的转发0频道上的提及0

每帖平均覆盖率

1 720

12 小时1 6520%24 小时1 7200%48 小时2 046

299.5%

参与率 (ER)

6.8%

转发117评论0反应28

覆盖率参与率 (ERR)

0%

24 小时0%一周0%一个月

30.75%

每则广告帖子的平均覆盖率

0

1 小时00%1 – 4 小时00%4 - 24 小时00%

详细信息

将我们的机器人连接到频道以了解该频道的受众性别。

过去 24 小时内的帖子数

0

动态

"kravets b.log();" 群组最新帖子

所有帖子

转发自:

artalog

22.03.202510:19

В next.js все это время можно было на изи мидлвары скипнуть (авторизацию, пейвол и т.п.), срочно обновитесь, если у вас есть в них логика.
https://security.snyk.io/vuln/SNYK-JS-NEXT-9508709

11.03.202515:10

Microsoft решились переписать TypeScript на go 🤯

Обещают 10-кратные улучшения по времени сборки, быстрый запуск и меньшее использование памяти

Из планов - к середине года выпустить CLI тайпчекинг, а уже концу полноценную поддержку в редакторах

Нативную реализацию TypeScript планируется выпустить под 7 мажором, но не забывать о 6 (сейчас актуальна 5.8), до тех пор, пока вариант на go не будет достаточно зрел и не получит признания

На некоторые вопросы команда уже успела ответить в дискуссиях на GitHub

~~Почему не rust~~

Репозиторий | Discussions | Blog post

10.03.202516:48

раскрыта причина падения твиттера

06.03.202510:10

Lynx - ответ React Native от ByteDance (создатели TikTok)

Из интересного:

- Тулинг основан на Rspack и Rsbuild (объединили и назвали Rspeedy)
- Они написали движок PrimJS основанный на QuickJS
- Довольно долго был closed-source (уже 3 мажор), т. е. уже применялся в коммерческой разработке и популярных проектах (например, TikTok Studio)
- Используется два потока:

Основной - для особо важных задач, таких как первый запуск, рендеринг или обработчики событий, требующие немедленного отклика

Например, так можно показать что этот обработчик особо важен и должен быть обработан в основном потоке:

Фоновый - Тут выполняется пользовательский код и весь жизненный цикл компонента (Смотрите на картинки, чтобы лучше понять)

Для начала они выкатили react-based вариант использования (ReactLynx), но очень хотят, чтобы он не был единственным и их Lynx не был завязан на определённый фреймворк

Статья в блоге | Quick Start | Rspeedy | Подробнее о двухпоточной модели выполнения - #1 #2

23.02.202513:32

https://docs.docker.com/desktop/features/gordon/

А вы уже используете докер эйай?

> docker ai 'How do I run redis?'

30.01.202514:36

Спокойной ночи, гитхаб!

status.github.com

26.12.202419:58

--no-experimental-strip-types заменил собой --experimental-strip-types!

В будущих версиях Node.js type stripping будет включен по умолчанию. Наконец-то CLI-шкам не придётся за собой тащить бандлеры, чтобы просто прочитать конфиг в .ts формате. Вот такой tsconfig.json рекомендуется для этой фичи:

На данный момент планируется выпустить в будущих обновлениях 23 мажора, понаблюдать и обдумать бэкпорт на 22.x версию.

Для полной поддержки TypeScript всё ещё рекомендуется использовать сторонние решения, такие как tsx, который и я вам очень советую.

PR | Documentation (пока что без обновления с --no-experimental-strip-types)

29.05.202422:29

Не забываем что у нас есть аналог!

转发自:

Андруша пишет код

24.05.202409:41

Почему реакт идёт куда-то не туда pt2

- React Server Components(RSC)
- React Compiler(RC) вы тута

RC - это "штука, которая позволяет упрощать ваш код, так как вам больше не нужно думать о мемоизации", как продаёт нам это решение команда реакта. Причём продаёт агрессивно. Этот продукт настолько хорош, что ребята из команды реакта ходят(https://github.com/bluesky-social/social-app/pull/4161) по репозиториям и сами внедряют его. Весьма красноречиво, не так ли?
Давайте глянем на реализацию RC. Если вы заглянете в исходники, то увидите, что ребята решили не переиспользовать уже текущие решения на рынке, а попросту написать всё своё: парсер, систему типов и логику мемоизации. Ни одно из решений, которое уже есть на рынке не было переиспользовано. К примеру, они могли бы хотя бы воспользоваться тайпскриптом, который уже давно протестирован сообществом. А это значит только одно: мы будем иметь максимальное количество магии и перестанем вовсе понимать что происходит в собранном коде.

Другая весёлая проблема: ваш итоговый код становится ещё больше. Но это же не проблема, правда? У нас же есть RSC, да? Теперь реакт - это анти-svelte. Если тот с помощью компиляции делает небольшие приложения, то RC делает толсто, но быстро(спорно).
Третье: наш код теперь не является отражением того что в реальности будет выполняться. Если в ангуляре и вью вся компиляторная магия происходит только в одном месте: в компиляции шаблонов, которые не являются кодом, то команда реакта решила собирать js.
Далее: RSC приоткрыло нам дыру в ад метапрограммирования своим "use server". Но теперь нас ничего не останавливает, поэтому RC добавляет ещё одну подобную директиву: "use no memo".

И самое печальное, что реакт своим компилятором не решает проблему ререндеров - пропы при изменении всё равно вызывают ререндер всего поддерева компонентов. И вместо решения проблемы как точечно обновлять DOM, как это делает, к примеру vue/angular/preact/svelte/lit/да_кто_угодно_кроме_реакта благодаря наличию реактивности, мы имеем монстоузное решение, которое просто позволяет разрабам не писать useMemo(sic!). А вот useEvent, который делает часть пропов стабильными, мы, конечно, вводить не будем(https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md).

Кстати, не удивлюсь, если в будущем мы будем иметь библиотеки, которые не будут попросту работать без RC. Люди же любят делать решения без сборки, ага.

В итоге, RC показывает, что фейсбук живёт в каком-то своём мире, который максимально оторван от реальности. Написать собственный язык, чтобы не писать useMemo - это прямо удивительное расходование ресурсов. Как раз по той причине, что это маскировка проблемы, а не её решение.