Насколько преждевременная оптимизация - плохая идея.

https://twitter.com/BrendanEich/status/1271954691421691905?s=20

Планировали похожесть на джаву, а в итоге потомки мучаются с null и undefined.

Пысы: это автор js.

А вот и новый ts5.3. Хоть это и проходняк. Особо вкусных вещей нет
https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-3/

W3C и все-все-все

Давай я тебя ошарашу: стандарт стандарту рознь и то, что если что-то есть в стандарте, не значит что люди делали это с умом.

Возьму такую популярную вещь: стримы в ноде. Пакет 'node:streams'. Эта штука существует уже кучу лет и вроде как должна быть отработана временем и иметь решения всех проблем. И даже больше, у неё есть какой-то стандарт: https://streams.spec.whatwg.org. Вообще люди красавчики. Не только сделали удобный инструмент, но и сделали его полное описание, чтобы людям было проще жить. Или нет?

Простая задача: напишите функцию isReadableStream. А зачем её писать? Это же должно быть в стандартной библиотеке. Правда? Ага, щщщас. Дайте 2. Нет такой функции. Воспользуйтесь пакетом: https://www.npmjs.com/package/is-stream (Если ты сидишь на ESM, sindresorhus привет, ага). А на внутренности пакета лучше даже не смотреть

Продолжение в комментах(спасибо tg за удобство работы со скриншотами)

useless packages

Структурная типизация в js - это огромная удача для всего мира, так как мы можем использовать стандартные апи даже тогда когда их поддержки нет в рантайме в помощью полифиллов. Я считаю неплохой практикой поднимать у себя локальную копию https://polyfill.io, но много кто бандлит все полифилы к себе. Но есть проблема: если ты забандлил что-то, то иногда стоит удалять это из бандла, так как это уже не надо.

И вот тут начинаются проблемы: полифилы обычно не помечаются в npm как deprecated, из-за чего всякие outdated не будут вижжать, что надо выпилить пакет. Самый простой пример https://www.npmjs.com/package/object-assign. Эта штука уже давно существует у нас во ВСЕХ рантаймах, но 25 лямов скачиваний в неделю - это 25 лямов.

Я не видел решений, которые позволяют нам контролировать зависимости в этой части, так что решил сделать это сам:

npx cleanup-deps

@latest

Пакет, который покажет какие пакеты можно спокойно выпилить. Пример для моего текущего проекта на скриншоте в комментариях.

Из того что в планах сделать в ближайшее время:
- Оформить как нормальный опенсорс проект. Пока для MVP это делать лень
- Добавить как можно больше пакетов в https://github.com/XaveScor/cleanup-deps/blob/70e18fb0765206bac028beaa30664aea81b04971/src/deps.ts
- Добавить работу не только с нодой, но и с browserslist

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

К результатам о том кто мы такие подоспели результаты отпроса от jetBrains: https://www.jetbrains.com/lp/devecosystem-2023

А так же появился новая итерация State of JS:
https://survey.devographics.com/en-US/survey/state-of-js/2023

И если первое - это "о, наконец-то, задолбал этот фронт. Можно перекататься в <langName>" или просто подборка прикольных фактов о нашей жизни, то второе - способ за 10 минут понять что волнует индустрию, и возможно, записать пару вещей, которые стоит изучить на будущее.

search everywhere

Где-то в 2020 году моя жизнь в каком-то смысле разделилась на до и после. Как минимум в том как я стараюсь взаимодействовать с интерфейсами.

Всё началось с этой статьи https://blog.jetbrains.com/idea/2020/05/when-the-shift-hits-the-fan-search-everywhere/.
JetBrains сделали удобный способ искать. Тебе не нужно думать что тебе нужно искать: строку, символ, имя файла или даже настройки. Просто вводи текст и иснтрумент сам тебе подскажет всё что он найдёт.

Это оказалось настолько сверхудобно, что со временем невольно я начал переходить на search-first жизнь везде где мог дотянуться:
- Что-то надо на веб странице? cmd+F
- Что-то надо запустить на телефоне или кому-то позвонить? Открываю строку поиска и ввожу туда имя контакта или же название приложения
- Что-то надо запустить на ноутбуке? Открываю spotlight(Mac) или Пуск(Win) и ввожу имя программы
- Нужна справочная информация? Спрашиваю у колонки или же просто иду в duckduckgo. По стандартным запросам они отвечают вполне легко
- Телеграм? Поиск по контактам
- Нужно установить программу? Иду на brew.sh или winstall.app и ищу там

С появлением chatgpt стало всё вообще прекрасно. БЕСПЛАТНО ты можешь получить даже ответ на вопрос, на который ты не можешь задать нормально вопрос.

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

И да, великолепный всемилюбимый браузер arc решил отказаться от поиска в настройках(как это есть во всех хромиумах) и заслужил от меня лучи поноса. Ну и сподвиг написать этот текст.

Да прибудет с вами строка поиска

Стринги

Что может быть проще чем строка? Наверно только число или булеан. Наверно по этой причине люди любят строить апи на основе этого примитива. Потому что "проще === лучше" же?

Вот есть redux: вот у нас там экшены на строках, и когда их миллиард в приложении, то очень удобно(нет) делать так, чтобы они не пересекались. И мы даже решение, чтобы решить эту(в том числе) проблему придумаем: RTK. Хотя нет, лол. Не решает. Всё равно надо следить за строками.

Роутер? react-router супер! Все урлы - это строки. Поэтому смена урлов - это очень удобный процесс. Нужно всего лишь пройтись по всей кодовой базе и поменять все ссылки руками. Этож так удобно.

lodash.set? Вау, этож так удобно! Не нужно думать что у тебя в объекте. Просто установил путь, значение, а оно само там разрулит. Изменилась структура объекта и у тебя тайпчек не нашёл ошибок? Ну, зато писать код удобно

And more
And more
And more

Не используйте строки для бизнес логики. Это хороший тип, чтобы хранить данные. Но строки не строят связи между сущностями в проекте. Если вы решили построить апи на строках, то вы уже построили плохой апи. Потому что пользователю придётся крутить костыли вокруг этой либы, или писать малосвязный код.

Welcome to FAANG

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

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

Мы решаем литкод месяцами, изучаем новые технологии и всё только для того, чтобы потом при работе красить кнопки.

Так у меня всё время возникает вопрос к сообществу: почему враньё в резюме по поводу опыта осуждается? Люди врут в CV о своих достижениях, о технологиях, которые знают, завышают значимость своих задач. Но прохождение HR фильтра по критерию опыта - это прямо плохо. Только в этом врать нельзя. Но то, что полученный опыт в rs.school(не перестану их рекламировать) чаще всего будет ценнее 2хлетнего чувака, который ничего не делал и просто штаны просиживал, это опустим.

Люди всегда стараются казаться лучше чем они есть. Просто сейчас это стало массовым. И нужно адаптироваться.
К примеру, те же чатгпт не могут отвечать нормально на вопрос "зачем?", к примеру "зачем в рантайм добавили микротаски?". Тулы знают определения, но не понимают зачем они нужны.

В волчарах нет ничего плохого. Просто вы вместо понимания технологий проверяли знание кейвордов.

Поэтому так и больно, ауф.

С новым кодом

Новый год прошёл, а значит время нести базу в этот грустный мир.
И вот база намбер ван: решение А является плохим, если существует решение Б, которое решает проблемы А лучше чем А. Причём желательно чтобы у Б проблем было или меньше, или они меньше мешались.
База намбер ту: редакс говно, как раз по причине намбер ван. Как минимум потому что существуют reatom.dev и effector.dev

Какие же вещи редакс делает плохо:
- Подписки. Напомню для тех кто не знает: редакс - это огромный обзёрвер, который с помощью метода subscribe уведомляет ВСЕХ подписчиков, что состояние внутри изменилось. И "всех" - это ключевое слово. Редакс спроектирован так, что на любой чих ты вызываешь все подписки. Ты не можешь подписаться на конкретную часть стейта. Да, есть всякие мемоизации и подобное. Но ты всё равно будешь вызывать разные внутренние проверки на "а изменилась ли та или иная ветка стейта". Реатом и эффектор лишены этого недостатка: все связи строятся при инициализации стейта, а не при его изменении.

- Экшены. Эту проблему можно описать одним словом: строка. Да, это может показаться не проблемой, так как мы можем использовать енамы, объекты, символы или любые другие инструменты языка, которые позволяют контролировать уникальность сущностей. Но зачем? Пока мы один костыль полируем другим, у конкурентов этой проблемы в принципе нет.

- mapped состояния. Типичный код выглядит как-то так:

const value = useValue() // подписка на стор
const modifiedValue = compute(value)

return <button onClick={() => dispatch('modify', modifiedValue + 1)} /> 

А теперь подумайте как бы вы сделали эту штуку с помощью редакса? Вы НИКАК НЕ МОЖЕТЕ поместить логику, связанную с modifiedValue рядом со стором. Да, вы можете вынести эту логику в какой-нибудь хук и вызывать его в каждом компоненте. Но(!) вы тут сразу бьёте по перфу, так как перевычисляете одну и ту же логику множество раз. У конкурентов же этой проблемы нет. А подобный код мы пишем каждую минуту.


И тут возникает вопрос: а почему если редакс так плох, им продолжают пользоваться, а конкурентами - нет? Хорошая мысля, но это совершенно уже другая тема.

#база

Уродливое, но родное

В прошлой заметке я попытался показать почему редакс, по-моему мнению, плох. Существуют даже конкуренты. И их много. И они неплохи на фоне редакса.
Конкуренты:
- jotai
- zustand
- mobx
- effector
- reatom

Эти все инструменты как минимум не хуже чем редакс. Некоторые из них даже становятся популярными и растут как ни в себя по скачиваниям, но от редакса люди не отказываются. Почему?

Под предыдущим постом люди написали и про привычки, и про рекламу от Абрамова, и про "работает - не трож". Но основная проблема, как мне кажется, абсолютно в другом: Разрабы библиотек не умеют в маркетинг. Совсем не умеют. Каждый из разрабов думает "ой какой красивый, быстрый и лакончиный код позволяет писать моё решение". Но никто не думает "как интегрировать мою либу в текущие решения?". Ведь каждый из нас каждый день начинает новый проект, который будет отличаться предыдущих. Как по методологиям, так и по практикам. Верно же?

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

И это касается не только стейт менеджеров. Это касается всей индустрии. Никто не делает адаптеры со старых решений на новые. Возьмём, к примеру, библиотеки для запросов. axios и got - это сверхпопулярные библиотеки, чтобы сделать простую вещь - отправить запрос в сеть. С 18 версии в ноде появилась нативная поддержка fetch, которая позволяет сделать куда меньшие и более мощные библиотеки. Но что мы видим? Никто не делает какой-нибудь fetchios, который имеет тот же API, но fetch под капотом. Этим махом можно спокойно срезать половину размера. Но нафига козе баян? Мы лучше сделаем ky, который ни с кем выше не совместим.

Так и живём...

https://nodejs.org/api/esm.html#importmetadirname

Славься мир. Больше никаких

import { dirname } from 'path';
import { fileURLToPath } from 'url';

const __dirname = dirname(fileURLToPath(import.meta.url));

Ограничения - цэ добро

После https://news.1rj.ru/str/xavescor_code/77 я решил доказать это на практике, заменив xhr внутри axios на fetch. Это позволило бы и уменьшить размер аксиоса и позволить людям перейти на более простое, вебосовместимое решение.

Но я столкнулся с проблемами, о которых должен думать разраб библиотеки, но о которых не подумали разработчики аксиоса:
Целковый. Каждая новая перегрузка апи должна решать новый спектр задач. К примеру, у реатома хук useAtom может принимать как атом, так и функцию, которая возвращает значение. Эти перегрузки не взаимозаменяемы. AxiosHeaders же может принимать в себя кучу разных типов, которые потом очень хитро превращаются в строку при превращении в хедеры. И эта хитрость очень сильно мешает как во внутренней реализации, так и при написании адаптеров. Но если бы AxiosHeaders принимал только строки, то и реализация была бы проще, и клиентам было бы не особо сложнее.
Приведу другой пример: Куча либ позволяет принимать в себя как тип T, так и Array<T>, а внутри уже T приводится к [T]. Даже если специальная функция в npm: arraify. Но, заставив пользователя писать не foo(x), а foo([x]) мы бы сэкономили и на размере либы, и на упрощении контракта.
Вывод: все приведения типов должны быть снаружи библиотеки, а не внутри. Делайте апи максимально скудным. Это очень упрощает жизнь и в тестах, и в реальной жизни

Полушка. Обновляйте библиотеки и меняйте устаревшие решения на современные. Аксиос для тестирования в браузере использует karma + jasmine. А для того чтобы отслеживать запросы, они мокают xmr. Ну, это хорошее решение, пока у нас не появился второй примитив для отправки запросов. А сейчас нормальным решением является какой-нибудь playwright, который через вебдрайвер уже получает информацию о запросах от браузера, а не с помощью моков конкретной стуруктуры. В итоге из-за кривых тестов мне для проверки своей реализации нужно ещё переписать тесты

Четвертушка. РАЗНЫЕ ТЕСТЫ НА РАЗНЫЕ ОКРУЖЕНИЯ. axios - делаем запросы по-разному. Я не знаю что в голове у людей, которые пилят аксиос, но у них 2 набора тестов: для ноды и не для ноды. Причём это РАЗНЫЕ ТЕСТЫ. Они не пересекаются. И дело не в моках. Я проверял. Тесты реально разные и проверяют разную логику. Axios - библиотека, которая работает по-разному в разных окружениях. Велкоме.

Так и живём...

Ожидания == реальность

Часто данный тезис неверен, но если много людей верят во что-то, то это вполне может стать правдой. Например, фондовый рынок: что-то дорожает или дешевеет, потому что люди верят, что что-то должно быть дороже или дешевле. Или люди торгуют между собой в долларах, потому что верят, что через месяц их бумажки будут что-то стоят. Поэтому будущее или ближайшее настоящее в некоторых вещах можно вполне прогнозировать по ожиданию людей, если этих людей много.

Так вот. FF мёртв, как минимум по ожиданиям разрабов. Потому что у меня нет обоснования как можно было допустить багу в такой базовой вещи как AbortController.
https://github.com/microsoft/playwright/issues/29101

Буду благодарен, если вы тоже проверите у себя эту багу, так как у меня сейчас только 1 ноут под рукой. Проверка отнимет от силы 2-3 минуты вашего времени.

https://9to5mac.com/2024/01/25/third-party-default-browsers-engines/

Раз в 10 лет ЕС кардинально меняет рынок браузеров. В 2012 ЕС убил десктопный IE, а в 2024 походу он пришёл за мобильным сафари. Тестеры поздравляю, вам чуток работы подъехало.

Недавно эпол частично прогнулась под ЕС в рамках сайдлоадинга https://www.macrumors.com/2024/01/25/ios-17-4-alternative-app-marketplaces-eu/ и люди опять оказались людьми:
"Почему государство указывает компаниям как вести свой бизнес? Если я захочу устанавливать приложения откуда-то снаружи, то я могу пойти на Android".
Это забавно, так как почему-то люди думают, что мир крутится вокруг них. Хотя это не так. В данном случае, почему-то никто не думает о разработчиках сервисов, которые для успеха должны иметь приложение и там, и сям. Без исключений. Но нет, второй стороны не существует, а мир крутится вокруг меня.

Эта же история напомнило мне что компании перестают быть плохими, когда достигают целей(Так как можно просто не видеть неудобную информацию). Пример прост: Амиго, Яндекс.Браузер и прочие. Де кась "эти продукты плохие, так как распространяюлись предустановками или же параллельными установками вместе с другим софтом". Возможно, открою Америку части людей: Google Chrome распространялся точно такими же методами. В 2012 году существовал сверхпопулярный продукт, которым пользовался практически каждый пользователь интернета - Abode Flash. И, не поверите, флеш устанавливал хром, если ты забывал снять галочку. Огромное количество миллионов инсталяций принесла эта "плохая" практика. И я даже не вспоминаю истории про гугл.тулбар, который устанавливался в IE вообще при любом чихе.

Эпол и Гугл вообще, кмк, стоит поставить на уровень естественных монополий, так как Android и iOS - это вещи, которые настолько сильно интегрированы в нашу жизнь, что без них жить уже невозможно. А вот пытаться их защищать, что против них делают что-то несправедливо - это уж точно.

А так же всем людям советую искать в первую очередь факты, которые не подтверждают вашу точку зрения, а опровергают. Так куда проще добраться до истины.

Interop 2024

В девяностые и нулевые были войны браузеров, когда каждый придумывал свои стандарты, который позволяли делать веб лучше, функциональнее, удобнее. Но это привело к огромной проблеме: такое понятие как кроссбраузерность было редкостью. В десятые ситуация стала куда лучше, так как разработчики браузеров стали общаться и несовместимости почти пропали. Но почти - это не полностью.
Веб стал настолько огромным, что невозможно уследить за всем, чтобы всё было одинаково. Но мы живём уже в двадцатых. И появился новый проект: Interop xxxx. И уже было 3 итерации 2021, 2022, 2023. И каждый год браузеры выбирают сферу, в которой они унифицируют своё поведение. И самое клёвое в этом проекте, что это не какой-то caniuse с просто написанной статистикой. Это набор тестов, которые непредвзяты и каждый может проверить работает ли та или иная штука в браузере и появилась ли деградация.

И вот настал 2024, а значит пора ставить новые цели. И цели были поставлены: https://hacks.mozilla.org/2024/02/announcing-interop-2024/. Так же в конце статьи вы можете увидеть ссылки на других вендоров, которые описали собственный взгляд на этот проект.

Самое удивительное для меня в Interop XXXX то, что в него вписалась Apple. А значит жить нам будет куда проще.

Текущую статистику вы можете увидеть тут: https://wpt.fyi/interop-2024?stable

https://twitter.com/Hinkali4/status/1753172405260812770

Почему-то в 2024 году люди всё ещё не научились в цифровую гигиену.
Делюсь великим секретом: не смешивайте работу и личную жизнь. Максимально разграничивайте их. На работе старайтесь пользоваться исключительно рабочими мессенджерами(Slack, MS Teams, etc.). Если работа лезет в телегу(привет, Яндекс!), то не поленитесь и заведите отдельный рабочий аккаунт. К примеру, у меня это @XaveScorWork.

И в таком случае у вас не будет никаких проблем в коммуникации. У вас будет возможность просто взять и отключить во внерабочее время все способы связи.
Но если и после подобных вещей вам будут пытаться долбиться по личным контактам по несрочным вопросам, то только в таком случае я могу присоединиться к вашему негодованию.

Если опустить вопрос коммуникации, то я так же советую вам обзавестись отдельным рабочим оборудованием, отдельным календарём, отдельной почтой и отдельным всем-всем-всем. Не надо работать с устройств и аккаунтов, где вы держите личные данные. Смешивание работы и личной жизни - цэ мэрзость. Цэ рэально мэрзость. Чем дальше будет ваша работа от вашей личной жизни, тем лучше вы будете себя чувствовать.

Ну, время написать что-нибудь и о программировании. Сейчас я занимаюсь рефакторингом одной нашей внутренней библиотеки, вторая версия которой будет иметь куда более удобный, как нам кажется, интерфейс.
Но есть 2 важных НО:
1) нужна совместимость со старым контрактом
2) либа принимает на вход функции из кодгена, и для комфорта разрабов кодген должен корректно приниматься как старой версией либы(для обратной совместимости), так и новой(для нового кода).

И из второго пункта появляется очень большая засада: нам нужно сохранить как-то типы, которые либа выводит из кодгена, а TS не имеет механизмов сохранения одного типа внутри другого.
Другими словами:

type Attach1<P, X> = P
type Extract1<A> = A extends Attach1<any, infer X> ? X : never;


type Attached1 = Attach1<{a: number}, string>;
type Extracted1 = Extract1<Attached1>; // unknown

https://www.typenoscriptlang.org/play?#code/C4TwDgpgBAgswEMDGALAjAHgAoBooA0A+KAXiiwChRIoBRAD2ACdlhMZiyYoJGIA7ACYBnWPGToMCfiDwBLfgDMITAsQD8BKAC4o-CADcVAbgpnq0OIlQRBaUmOuSA3gl38ArgFsARioC+eMLMCgDmhKYWdIwsSMC29mQMzKzs4jZ2EVAA9NlQHvwA1vwA9gDu-BRAA

Но если добавить ограничения, что тип P - это всегда объект, то можно сделать костыль:

type Attach2<P extends object, X> = P & {___private?: X}
type Extract2<A> = A extends Attach2<object, infer X> ? X : never;


type Attached2 = Attach2<{a: number}, string>;
type Extracted2 = Extract2<Attached2>; // string

https://www.typenoscriptlang.org/play?#code/C4TwDgpgBAgswEMDGALATAHgApQgD2AgDsATAZygHsAjAKwiWABooANAPigF4ocAyKAG8A+qLAAnAJYA3BIQD8ALjYBfAFChIUAKIFxyYJhiceMXAWLlY8ZOgw16jFpKIAzCOLad5bKMqIQ0h4A3GphmtBwiKgQJGjc1tF2ggj+AK4AttQeKixkwFJEAObsoRE6egax8Ty6BQZGNjFxpVAA9G1Q+YVFakA

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

Даже jquery выпускает новые релизы https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/

А реакт все сидит на версии 18.2.0