- Последний пост
- 27 окт. 2024 г.
- Последнее чтение
- 16 авг.
- Постов за неделю
- 0
- Всего постов
- 20
- Тип
- открытый
- Язык
- русский
- Категория
- Технологии (по похожим)
- В каталоге с
- 13 авг.
- 1/24сутки в ленте
- —
- 1/48двое суток
- —
- 1/72трое суток
- —
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
Things you should never do Создатели Arc Browser смачно кинули всех пользователей и фактически закрыли проект чтобы запустить брузер с ИИшкой (куда же без неё). Буквально, браузер для энтузиастов не принес столько денег сколько нам хотелось бы, так что поедем на хайптрейне. Жаль что понятия «репутация» и «доверие» им видимо не знакомо Arc won't be abandoned, but the new focus will primarily be on stability updates and bug fixes Одно из классических клише VC-новояза, в котором вторая часть предложения противоречит первой, проект по сути остановлен в развитии, все планы отправились в on hold (в утиль) Вспоминается классическая статья Things You Should Never Do, Part I, в которой рассказывается как флагман браузеров Netscape Navigator сел на мель во время переписывания с нуля и какие выводы из этого можно сделать. Захватывающее чтиво. Прошло почти 25 лет, по меркам IT — целая вечность, а тезисы становятся всё более актуальными. Главный вывод: please dont. В эту ловушку люди попадались множество раз, и судя по текущей новости, будут попадаться вновь и вновь. Я понимаю, что расчёт Browser Company на успешный pivot (резкое изменение курса компании в попытке нащупать market fit) в сторону ИИ, но с такими конкурентами (свои фичи завозят google, apple и microsoft) и с таким отношением к своим пользователям перспективы у них не вдохновляющие В целом, могу сформулировать «Things you should never do part 2»: не пользоваться продуктом VC-стартапа до тех пор пока он не покажет своё истинное лицо (vercel) или не выживет после кучи pivot-ов. Либо не расчитывать на длительное пользование, легко пришло — легко ушло А если вы решили поучаствовать в переписывании проекта с нуля, то стоит убедиться, что ключевые участники действа знакомы с этим классическим текстом и понимают на что идут
Архипелаг проблем Недавно Великобритания отдала маленький атолл Чагос посреди Индийского океана Маврикию. Тем самым завершилась история Британских Заморских Территорий (BIOT). Новость была бы абсолютно не интересной если бы не один нюанс — домен этих территорий, .io, который многие используют из-за его «технического» вида Гугл рекламировал этот домен как дженерик, но это не так. Любой двухбуквенный домен это домен какого-либо региона, когда независимая история региона подходит к концу, доменная зона прекращает своё существование .cs — Чехословакия .yu — Югославия .zr — Заир .dd — ГДР .tp — Восточный Тимор .an — Нидерландские Антильские острова .um — United States Minor Outlying Islands .bv — Необитаемые территории Норвегии (надёжный план, конечно) .eh — Западная Сахара, домен отдадут когда страна обретет независимость, то есть никогда, эх Конечно, есть контрпример в виде доменной зоны .su советского союза, которая до сих пор активна (её создатель сейчас кстати сидит), но вы готовы поставить свой проект на то, что Маврикий будет таким же дипломатически сговорчивым? Скорее всего (но это ведь не точно), с данным доменом будет всё в порядке, у name.com и гугла хватит влияния чтобы сохранить его работу, но государство, даже маленькое как Маврикий, может решить иначе и никто ему будет не указ, поэтому будущее всё ещё не определено В целом эта история относится ко всем «модным» двухбуквенным доменам: выбирая такой домен вы попадаете в зону деятельности государства-владельца, и вам может очень сильно не понравиться то, с чем вы столкнётесь: .co (как в слове «корпорация») — Чтобы сделать вашу корпорацию более зловещей, оформите домен Колумбии 👍 .la (сайты Лос-Анжелеса) — Лаос. Уверен, не все в ЛА знакомы с практиками ведения дел с Лаосом .ly (bit.ly например) — Ливия. Без комментариев .ws (web site) — Самоа. Одна из первых доменных зон, позволивших регистрировать домены с эмодзи. Есть ещё Американский Самоа, заморская территория США, так что есть риск повторения истории с архипелагом Чагос. Надеюсь урл 🍆.ws стоит этих рисков .tk — Мало того, что мусорный домен, вдобавок Токелау это ещё и заморская территория Новой Зеландии, риски те же Так что же делать? По правилам ICANN все двухбуквенные домены — региональные (ccTLD), все трехбуквенные и больше — общего назначения (gTLD). Предполагается что люди будут использовать домены по назначению: региональные — для регионов, дженерики — для своих задач В такие моменты истории самое время задуматься, не стоит ли воспользоваться этой идеей пока не стало слишком поздно
Мы не можем использовать термин JavaScript. И это хорошо Недавно попалась на глаза петиция к Oracle с просьбой освободить термин JavaScript от копирайта. Что? Да! Термин JavaScript это торговая марка oracle, защищена копирайтом и поэтому спецификация языка имеет такое странное название ECMAScript. Конференции разные проводить с этим термином тоже нельзя. Меня на самом деле в этой петиции удивило не наличие копирайта, а то что кто-то пытается чего-то добиться от оракла с помощью подписей 😁 И написано грамотно, сразу наворачивается слеза и появляется желание начать массово репостить и просить подписать Стоп На секунду задумался, зачем нам вообще нужен этот термин? Слово JavaScript это максимально абсурдное словосочетание, это по факту даже не java, и давно уже не просто скрипт. Это искусственный термин девяностых годов, когда планировали что жс будет добавкой к java апплетам. Сейчас это уже неактуально абсолютно. На самом деле есть вариант который избегает всех подобных проблем — сама аббревиатура JS. Она не находится под копирайтом и не имеет прямых странных коннотаций. На самом деле аббревиатуры не обязаны как либо расшифровываться вообще: GNU: GNU is Not Unix PIP: PIP Install Packages WINE: Wine Is Not an Emulator PHP: PHP Hypertext Preprocessor DMA: Doesn’t Mean Anything (потом стали Rockstar games) И эти технологии отлично живут, наверняка в процессе все примеры сбросили старые смыслы во время развития С аббревиатурой JS можно делать конференции, можно даже переименовать саму спецификацию и всем будет ок, это уже де-факто часто употребляемое название языка У меня ровно ноль иллюзий по поводу oracle, я считаю отобрать у них трейдмарк невозможно, да возможно и не нужно; писать ECMAScript чисто физически больно, может есть смысл попробовать такой вариант?
No reason Недавно увидел open source проект Дмитрия Коваленко subtitler, приложение для генерации переводов, привлекло внимание то, что он написан на rescript, необычный стек в последнее время. Rescript — проект с тяжелой судьбой, многие слышали о нем как о ReasonML У ризона был ряд преимуществ — отличная типизация, фантастическая скорость компиляции, лаконичный синтаксис, публичные типы для модулей (позволяют качественнее скрывать абстракции, оч архитектурно), крутейший паттерн матчинг а также доступ к большому ассортименту библиотек для OCaml. Один из важнейших алгоритмов в эффекторе, leftist heap, я смог найти только в пейпере с античным диалектом окамла, закинул его в репл ризона и тем самым скомпилировал в жс Развитию и адопшну технологии сильно помешала череда ребрендингов с мутным статусом, судите сами: • Сначала был Bucklescript как возможность компилировать Ocaml код в javascript • Потом появился ReasonML: более дружелюбный для фронтендеров синтаксис для окамла, они начали работать в паре, но по прежнему были разделены, даже документация была разная, но с обилием кросс-ссылок. И каждая, разумеется, была ущербна по своему • Потом фейсбук как владелец ReasonML потерял интерес к проекту, авторы форкнулись и назвались Rescript OCaml → Bucklescript → ReasonML → Rescript 🫠 Уверен, у них в команде был отдельный специалист по ребрендингу, и работы у него было непочатый край Reason/Bucklescript в свое время позволял использовать все фичи окамла, даже самые странные: классы которыми никто не пользовался, row types, всякие абстрактные эзотерические фичи, всё что угодно. Компилировалось это в сущий ад, объекты становились массивами, инстансы — натуральным байткодом в хэш таблицах и так далее. Учитывая, что ризон подразумевал сохранение результатов компиляции в репозиторий рядом с исходными файлами, работать над проектом быстро становилось некомфортно Сейчас же зашёл в репу subtitler и приятно удивился: синтаксис избавился от окамл вайбов и стал лаконичнее, все скомпилированные файлы хорошо читаемы, всё понятно и приятно, рядом сразу генерируются тайпскрипт типы для интеропа, красота. На секунду представилось альтернативное развитие событий, в котором у тайпскрипта есть весомый конкурент, который подгоняет его по фичам, не давая делать спорные решения. В такой ситуации пользователи всегда выигрывают! А то мы все любим тайпскрипт, и, разумеется, за дело, но всё же я хочу спросить, кто написал четыре миллиона пакетов хелперов? Более того, культурный обмен всегда обогащает обе стороны, никому из нас не нужно писать на окамле, достаточно чтобы разработчики с другим бэкграундом находились рядом. Например в окамле есть нативные эффекты, это могло бы привести людей к интересным мыслям и новым свежим подходам помимо useEffect. Даже жаль, что этого не случилось. Интересно, как бы мы сейчас писали код, если бы ризон не растерял всех пользователей во время бесконечных ребрендингов? Я думаю у нас есть шанс узнать: довольно скоро к нам полноценно заедут люди с новыми языками из WebAssembly, сейчас всех останавливает отсутствие интеропа с DOM API и прочие чисто технические вещи. Уверен, скоро настанут интересные времена 🔥 А само приложение классное, автор сильно заморачивается по ux и активно агитирует других уделять этому больше внимания. Респект
Блокировка cookies замедляет веб, к радости Google Многие наверняка уже слышали о скорой всеобщей блокировке third party cookies, на которой строится заработок рекламных и партнерских программ и заметной части веба в целом. В safari и firefox трекинг пользователя через куки на сторонних сайтах выключен уже довольно давно, но Chromium, разрабатываемый бизнесом построенным на рекламе, бан кукис всё откладывает и откладывает, хотя британские законодатели давят на них и в конце концов вынудят полностью отказаться от такого трекинга. Казалось бы, замечательно, улучшение приватности, одни плюсы? Оказалось, что у этой медали есть вторая сторона: отсутствие нормальных альтернатив. Недавно, я в свой практике увидел несколько новых заходов на то, как вскоре будут работать все: жесткий кастомный фингерпринтинг. Бизнес, построенный на рекламе то умирать не планирует, а раз нельзя трекать через куки, но можно вставлять свои скрипты партнерам, то каждая сеть лично для себя начнёт собирать свой собственный слепок пользователя для идентификации. Фингерпринт скрипт — это код, который пытается собрать как можно больше информации о системе и юзере, проверяя на расхождения в реализациях различных браузеров и девайсов. Вы вот например знали, что в V8 есть console.context чтобы вылезти мимо оберток типа роллбара и писать в консоль напрямую? А скрипт знает, и запишет, что у юзера движок V8 в таком-то диапазоне версий. Создаст невидимый canvas чтобы проверить нюансы работы gpu. Проверит все плагины браузера. Попробует написать в почивший WebSQL. Заглянет к typeof document.all. Короче задействует как можно больше дырок чтобы создать уникальную комбинацию параметров, чтобы отличить одного юзера от другого. Можете себе представить, насколько медленно это работает? А теперь представьте, что вскоре у каждой партнерки будет свой скрипт фингерпринта, потому что практики переиспользования кода в этой части индустрии нет, каждый скрипт уникальный и независимый. В итоге, количество скриптов будет ограничено только количеством партнерок у сайта. Ну, к примеру, штук 15. Каждый скрипт в 80-400 кб веса и по 200 мс работы. Кажется, я представлял себе будущее с запретом на трекинг слегка иначе И тут возникает вопрос, а как планирует жить гугл, почему он не торопится сделать альтернативу? А у него оказывается всё хорошо. Спасибо недавнему сливу документации к движку гугла, теперь мы знаем, что для себя любимых в гугл оставили возможность собирать данные напрямую с пользователей Chrome и для них этот запрет уже роли не играет, это пройденный этап. Этап на пути к процветанию в технологической монополии: для нас есть метрики прямо в браузере, для вас — 5 метров фингерпринтов. К счастью, движущая сила всей этой истории, британские законодатели, явно не в восторге от таких раскладов и предлагают гуглу подумать ещё The UK wants to make sure that Google isn't making changes to Chrome to prop up its advertising business at the expense of competitors. Гугл пробует что-то сделать, но пока это выглядит довольно странно, технология Related Website Sets для работы требует открытия PR на гитхабе, мержить который будут сотрудники гугла. Очень удобно, спасибо, это точно поможет снизить уровень монополизации. И тут возникает интересный вопрос — а куда мы в итоге движемся? Я вижу столкновение двух непреодолимых сил: желания рекламных бизнесов выжить и стремление европейских регуляторов снизить уровень чужой слежки за своими гражданами. Отказ от кукис не обсуждается, это явно проблема с приватностью, но ведь и фингерпринты же по прежнему работают? Если ввести аналоги кукис но урезанный на пол шишечки, то что мешает новой Cambridge analytica вновь слить все наработанные данные на сторону? Зачем всё это противостояние, если конечная проблема не техническая реализация cookies а сама модель рекламного бизнеса? Зачем это всё, если всё останется как есть, но с фингерпринт-скриптами? Много вопросов, мало ответов
без подписи
Абсолютное безумие: roblox портировал весь жс стек на lua: react, jest, graphql, apollo, redux 🫨 Впечатляет то, что там не просто "react inspired library", они прямо предоставляют чеклист какие пакеты из реакта портированы а какие нет, подход похож на классовый апи реакта без jsx. Jest конечно целиком портировать сложнее (он просто большой), но матчеры и основной апи на месте Я даже догадываюсь как такой подход появился: в игровой индустрии в качестве скриптового языка используется lua, потому что его рантайм радикально легче огромных жс движков, а в командах разработки набралось критическое количество людей с фронтенд-бэкграундом чтобы принять решение о копировании подходов. С одной стороны такое мега монстрячество конечно завораживает, но с другой — возникают вопросы, не идет ли то что они делают в противоречие с парадигмами языка? Например реакт-код на ReasonML и (в меньшей мере) Rescript в свое время выглядел крайне чужеродно, было заметно что концепции языка натягивались на то, к чему они изначально не были приспособлены. При этом вся идея идет в рамках тренда портирования жс подходов на другие сферы в которых применяется UI, просто они зашли в этом заметно дальше других Необычное решение, в любом случае
Кыргызы против Intl.NumberFormat Когда лучшее враг хорошего. Недавно к нам в команду web platform в aviasales пришли из техподдержки со странным багом у пользователя: в Arc браузере сломано отображение символа валюты кыргызских сомов, вместо него выводится непонятный символ. Проще всего конечно было ответить, что браузер не поддерживается, но стоп, разве арк не на хромиуме, чем он такой особенный? Начал разбираться Действительно, в обычном хроме сомы показываются как KGS, а в арке как символ, и символ явно ошибочный. Для отображения валют мы используем стандартный Intl.NumberFormat и в арке он действительно выдаёт другой символ. Начало проясняться. Возможно, арк использует новую версию хромиума и поэтому показал проблемы раньше? И действительно, Chrome Canary получил точно такой же баг. Получается, совсем скоро, валюта сломается у всех, вообще у всех сайтов и пользователей страны, и отсчёт времени уже пошёл 🫠 Куда отправлять баг? У хромиума есть свой баг трекер, но работа с ним оставляет желать лучшего, выглядит он мягко говоря антично. Никогда не заполнял баги для браузера, но видимо этот час настал. В процессе подготовки репорта вспомнил, что вообще говоря, локализациями занимается не хромиум а отдельная библиотека ICU, то есть проблема ещё глубже, чем просто баг браузерного движка. А, казалось бы, невинная проблема Описываю свои приключения коллегам, один замечает, что это первый раз, когда мы нашли баг не в самом лучшем браузере safari а в хроме, теперь счёт багов 4:1 в пользу первого. А действительно, а как себя ведёт в таких условиях сафари? Открываю. Встречаю тот же баг 🫡 Очевидно, проблема на уровне операционной системы. Решил присмотреться к символу внимательнее, это просто мусорный вывод или он имеет какую-то семантику? Символ который выдаётся на macos выглядит так: ⃀, если вы читаете с macos то почти наверняка ничего не увидите (в первом комментарии скриншот как это рендерилось в реальности). В базах данных по юникоду описание: Unicode Character 'SOM SIGN'. Бинго. Это не баг, это настоящий символ валюты, но в стандартных шрифтах macos его нет, на windows всё отображается нормально В итоге получается ситуация: раньше вместо символа валюты выдавалась аббревиатура, библиотека ICU исправила эту проблему чем ухудшила вывод на девайсах apple Это многое говорит о нашем обществе Issue в багтрекере хрома или ICU открывать не стал. Очевидно они всё сделали правильно; парадоксальная ситуация в которой никто толком не виноват. Ну, точнее, можно конечно попинать apple чтобы добавляли символ, но это всё равно что орать на баобаб Оценив диспозицию, решил что надёжнее всего будет просто сделать .replace для проблемного символа на старый вариант. Мимоходом заметил, что в некоторых других условиях у нас на сайте кыргызская валюта отображается нормально. Оказалось, что вместо официального символа используется юникод-комбинация c + нижнее подчеркивание под символом: c̲. Как говорится c̲мекалочка ок. Но чтобы я не сильно радовался, оказалось, что в том самом стандартном шрифте apple этот символ тоже отображается криво, проще заменить обратно на KGS, как это было раньше и всех устраивало Когда я заходил на эту пятничную задачу последнее чего я ожидал это изучения багтрекера браузеров. А вот проблемы с apple наоборот вполне были в рамках! Разумеется это ценно, что у движка chromium есть конкурент который не живёт на пособиях гугла, но нельзя не признать, что девайсы apple и веб разработка это головная боль. Всегда. Пока писался этот пост, «улучшающий» апдейт хрома был раскатан на всех пользователей. Кыргызский интернет оказался уже сломан, сломан для всех
Молоток, гвозди и tailwind Одна из технологий, которая в последнее время реально продвинула фронтенд вперёд это tailwind. Его преимущества очевидны, примечательно, что до него было много попыток сделать атомик стили, но не у кого не получалось так хорошо, он заслуженно получил массовое признание Но с массовым признанием технологий к ним приходят и новые проблемы, например экстремальные попытки пользователей определить, где кончается предел применимости. Некоторые попытки серьёзные, некоторые нет. SQL запросы на jsx? Отлично. Калькулятор на typescript типах? Ещё лучше. Интерфейс windows на реакте? Ну вы поняли Когда в руках молоток, всё вокруг кажется гвоздями Для тейлвинда же нарождается целый спектр плагинов, которые пытаются нащупать грань того, что ещё можно записать в className. Последний пример — tailwindcss-signals. Это плагин, который реализует включение вариантов стилей родителей на основе состояния детей. Отдельный респект автору за попытку хайпануть сразу на двух трендах Глядя на синтаксис, приходит понимание, что плагин предлагает отходить от идеи описания стилей ключевыми словами к описанию логики активации Типичный пример выглядит примерно так: signal/custom:after:!content-['_🦄'] Everyday we stray further from god Очевидно, что это уже не тейлвинд, это dsl на его основе. И возникает вопрос: а что дальше? Растёт число кейсов, которые такие смелые ребята как Brandon McConnell пытаются уместить в концепцию, она трещит по швам, но пока что выдерживает. Рано или поздно в сообществе должен сформироваться консенсус, на основе которого тейлвинд либо станет чем-то больше, чем он есть сейчас, либо уступит место чему-то более продвинутому и больше подходящему для описания вариативной логики Даже интересно, во что всё это выльется
React compiler проклинает mobx Все конечно уже успели обсудить анонс реакт-компилера, но одна вещь привлекла моё внимание: упоминание проверки на несовместимость библиотек Вернее, библиотеки При попытке поставить компилер в проект с мобиксом, react-compiler-healthcheck выдаст в cli сообщение о проблемах с пакетом. Мне стало интересно, каким образом компилер проверяет на совместимость, может находит импорты различных DON_NOT_USE_OR_YOU_WILL_BE_FIRED? Оказалось всё гораздо проще, есть чёрный список несовместимых библиотек. Чёрный список из одного пакета. Mobx. По моему, получить персональное проклятие от тимы реакта — это довольно почётно! Так что же послужило причиной персональных санкций в отношении проекта? Причина в хоке observer/useObserver. Этот метод работает оборачивая компонент в магическую сущность, которая автоматически определяет, какие обсерваблы используются в компоненте и вручную вызывает ререндер при их изменении. То есть, вместо того, чтобы сделать хук в духе useStore как все остальные стейт-менеджеры, в мобиксе решили сделать рационализацию и поставить всю концепцию реакта на бок. Очевидно, что тима реакта осталась от такой идеи не в восторге. Пакет оказался достаточно популярным, а эвристики компилера достаточно слабыми, чтобы получить единственный на всю экосистему персональный бан. Можно предположить, что в дальнейшем такая участь постигнет все проекты, которые захотят оборачивать реакт-компоненты во что-то магическое: либо оптимизации от реакта, либо от библиотеки, теперь вопрос поставлен ребром. Учитывая, что пока реакт компилер не имеет версии под swc и крупнейший проект экосистемы nextjs его использовать не будет, то есть время с этим что-то сделать Для мобикса это грозит полной сменой подхода к реакт-биндингам Но мне если честно сложно представить, что можно сделать в такой ситуации и как они будут выбираться из персонального бана даже если всё переделают как надо
Привет! Я Дима Zerobias, создатель effector, в данный момент работаю в Aviasales. Я решил возродить свой старый канал про фронтенд. Канал был заброшен в 2020 году, я тогда разочаровался в развитии фронтенда, точнее в его отсутствии: после сумасшедших по интенсивности 2017-2019 годов появилось ощущение, чисто субъективное, что ничего больше не происходит, пропозалы не двигаются, фреймворки пытаются разобраться с тем что они наворотили (Vue 2 -> Vue 3 как пример) Сейчас же ситуация поменялась: фронтенд окончательно принял rust и новый уровень быстродействия тулинга, появились новые инструменты для улучшения dx, особенно примечательны работы Эвана Ю (vite, vitest) и Tanstack, фронтенд внезапно конвергировал к концепции сигналов, окончательно дистанцировавшись от примитивных подходов с ререндерами, в общем, вновь становится интересно! Буду обозревать фронтенд вместе с вами 😃 Добро пожаловать!
Channel photo updated
интерактивный разбор понятия эффектов и коэффектов в языках программирования эффекты это то, как код влияет на окружающий мир: чтение и запись мутабельного состояния, IO, а коэффекты это то, как окружающий мир влияет на код к примеру, чтение текущего времени через performance.now() это коэффект, так как таймеры предоставляются системой и могут быть заменены по её усмотрению. примечательно, что именно это произошло после обнаружения уязвимости spectre, которая использовала таймеры системы для кражи защищённых данных через javascript. для борьбы с этим браузерам пришлось временно понизить точность результата, чтобы предотвратить утечку данных через процессорный кэш. иными словами то, что должно было быть чистым коэффектом (способом системы повлиять на ход выполнения программы) получило непредвиденный побочный эффект — чтение данных самой системы понятие эффектов уже давно активно проникает в мейнстрим программирования и упоминается даже в реакте; наверняка адаптация идеи коэффектов тоже не за горами, думаю это позволило бы углубить понимание процессов, протекающих в наших приложениях и системах http://tomasp.net/coeffects/
без подписи
Cloudflare год назад: Verizon поломали часть интернета, потому что забыли про лимиты для защиты своей конфигурации BGP, вот лентяи! Cloudflare на этой неделе: как вы уже заметили, мы уронили сеть на трёх континентах и кажется всему виной отсутствие BGP лимитов в наших настройках... 🤷🏻♂️ https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/ https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
вкладка performance в девтулзах хрома имеет настолько невменяемый ux, что ей можно пытать. зато просто в реализации и поддержке. я надеюсь приоритет простейшего решения не повлиял на то, что половиной инструментов девтулзов хрома абсолютно невозможно пользоваться, но шансов мало выбирайте наилучшее, а не самое простое решение https://t.me/defront/568
мало нам было баннеров при вызове npm install, теперь кто-то додумался создать полноценный слив данных в виде аналитики для нпм пакетов: встречайте scarf отсылает на левые сервера информацию о вашей операционной системе, айпишники, название корпоративной сети и метаданные корневого пакета. здорово, правда? 😕 пакет уже начали использовать redux-form, final-form и react-table, проверьте свои зависимости
вирусы на страже здоровья: криптоботнет лечит уязвимости и накатывает апдейты на заражённую систему для защиты от конкурентов
группы для табов в chrome. разработчики самого популярного браузера неожиданно решились на добавление групп и лейблов для вкладок, наконец-то в наборе окон браузера появится структура. ранее похожая возможность уже была в других браузерах, например в vivaldi, и теперь эта возможность приходит и в хром чаще всего в браузере открыто не так много вкладок: 10, ну может 20-30, но иногда требуется делать обширные исследования или работать над несколькими вещами одновременно; однажды у меня было открыто более восьмисот вкладок 😁 и в такие моменты очень помогает возможность объединить вкладки визуально в группу вообще, эта функциональность не самая простая в реализации, к примеру в телеграме папки для чатов пришлось ждать несколько лет, а в случае с хромом особых надежд даже и не было: слишком велик риск сделать слишком сложно и запутанно, и тем неожиданнее было увидеть такой анонс. уже доступно в chrome beta и под флагом если интересно как можно открыть 800 вкладок: для оптимизации работы используется расширение the great suspender, выгружающее из памяти неактивные вкладки, а сами вкладки распределяются по окнам, объединённым по темам, разнесённые на разные рабочие столы macos/windows, и управляются через session buddy https://www.blog.google/products/chrome/manage-tabs-with-google-chrome/
инженеры, работающие над Flow поразительным образом умудрились в совершенстве освоить навык ничегонеделания будучи в open source: так называемую «архитектуру type first» они анонсируют уже в третий раз за два года 🌚 https://t.me/juliarderity/1384