Синдерхорнус продолжает ультовать.
https://sindresorhus.com/blog/goodbye-nodejs-buffer

95% статьи я поддерживаю. Там описаны супер граммотные идеи. К примеру: в еслинте запрещаем использование нодового Buffer, чтобы потом постепенно переписать на стандарт. Но блин, его кардинальность "ломаем обратку в либах" - это нечто.

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

https://dev.to/muhammadazfaraslam/highlight-on-the-new-features-of-next-js-14-config-2023-4lbe

Главное впечатление от прошедшей конфы некста на фото.

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

Для меня, как для фронтенд разработчика, очень просто воспринимать компании на рынке:
- Apple - делает отличные ноутбуки для моей работы. Но ужастные для домашнего использования
- Google - прекрасный ютуб, который мне помог своими видео в начале моей карьеры. Остальными сервисами не пользуюсь
- JetBrains - отличные IDE на любой вкус
и так далее.

Но в этом списке есть одна компания, которая одновременно несёт добро в этот мир, которое сделано максимально через задницу.
Это компания Microsoft. По какой-то непонятной причине сотрудники этой компании живут так, как будто завтра апокалипсис.

1. Давай глянем как MS покупает компании. Например: В 2020 году купила npmjs.com. Хорошая новость? Да, npm начал конкурировать с ярном и, сейчас, с pnpm. Одни плюсы. Но публичную деятельность npm решили вести максимально дибильно. После покупки все анонсы(blog.npmjs.org) падают в блог гитхаба. Пробовали ли вы что-то искать в блоге гитхаба? Это просто неиндексируемая помойка из всего что принадлежит MS. Пользоваться этим стало на порядок менее удобно. Аналогично произошло с Mono(опенсорс рантайм для дотнета).
2. Давай посмотрим как MS ведёт разработку своих языков: C#, F#, TypeScript. Знаете что у них общего? У них нет общей спецификации. И если у C# есть хотя бы дельты, благодаря которым можно жить, то у остальной двойки полная задница - ты не можешь просто реализовать компилятор этих языков. До войны JetBrains делилась какой ад им приходится проходить, чтобы понять что есть в тайпскипте: https://www.youtube.com/watch?v=qddYQL5-rZY. Спойлер: они читают все исходники, потому что других мест для получения информации нет.
3. MS и опенсорс = ❤. Ну, вроде и так. Начиная с .Net Core Майки очень много вещей вынесли на общее обозрение. Но в чём может быть тут косяк? Ну... К примеру, если ты запрещаешь использовать опенсорсный дебаггер к дотнету вне своих продуктов. https://github.com/dotnet/core/issues/505

Так чего же я пригорел? Да от пункта #2. Typenoscript прекрасный язык, которым невозможно пользоваться полноценно, так как весь опыт передаётся только из уст в уста. Так же как и 20тыс. лет до нашей эры.


Простая задача: нужно затипизировать обёртку над либой отправки запросов: https://www.typenoscriptlang.org/play?#code/C4TwDgpgBACghgJzgWwM5QLxQN4CgoFQISpgD2AdqhACrgQBcUA5AFaqXNQA+LARgBsyfZgG5cAX1y5QkKAFk4AawgAlCAEcAriWDrgWhBTqQAPOtKVqJiAD5MUC+Sq16UCAA9gECgBN0bBwUzPiEAPxQqMAIAJYUAOahBExOVq5ynt5+AYLCXEmEBBEAQkJ8UAWFTBQQAG4QCOK4vhAAxgKI0ABmWhStwDGUUMjKapo6UQAUYEzwSGgAlEyKKurauvqGxvSmcyioANrMxJYuNswAurZNrVbAUB4OI6vjupPYJ87W9EyBnBILURQAD0wMi0TiiVuVHuICeozWE2A70+aRsv1yIgBQNBUFKwiAA

Как исправить, чтобы вывод типов работал верно? Для этого тебе надо знать, что нужно зафиксировать тип аргумента с помощью дженерика `foo<T extends Params>(arg: T)` и тогда можно будет работать с конкретным типом, а не с его общим описанием. https://www.typenoscriptlang.org/play?#code/C4TwDgpgBACghgJzgWwM5QLxQN4CgoFQISpgD2AdqhACrgQBcUA5AFaqXNQA+LARgBsyfZgG5cAX1y5QkKAFk4AawgAlCAEcAriWDrgWhBTqQAPOtKVqJiAD5MUC+Sq16UCAA9gECgBN0bBwUzPiEAPxQqMAIAJYUAOahBExOVq5ynt5+AYLCXEmEBBEAQkJ8UAWFTBQQAG4QCOK4vhAAxgKI0ABmWhStwDGUUMjKapo6UaYw7l4+-rCIKKi2ABRgTDAAlEyKKurauvqGxvRTANrMxJYuNswAurZNrVbAUB4OI3vjuivYV87WehMQKcCSbURQAD0kMi0TiiWeVFeIA+o32E2Av3+aRswNyIjBEOhUFKwiAA

Откуда это узнать? Ну, поспрашивай. Чо, впервые что ли? Может система типов и мощная, но черезчур черезжопная.

Новый State of React: https://stateofreact.com/en-US

Подобный опрос маловероятно что поможет авторам реакта, в отличии от state of js или state of css, на которые смотрят разработчики спек, так как реакт что-то и пилит внутри, но версия 18.2.0 уже почти полтора-два года с нами без изменений.

Но все state of * - прекрасный способ держать руку на пульсе того, что происходит в тусовке той или иной технологии. Так что даже если разрабы реакта не смотрят на результаты, то всё равно этот опрос стоит пройти. Как минимум чтобы не пропустить что-то мимо себя.

https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/

Тут тихой сапой мистер Интернет показал классику: ты можешь быть самым-самым крутым, но уборщица, нанятая за копейки, порушит всю инфраструктуру.
Из хорошего: ребята не скрываются и публично показывают в чём не правы.
Из идиотизма:
- О, у нас 3 ДЦ, но мы тестить на оффлайн будем только 2 из них. А один - ну и тестировать смысла нет. Всё равно всё ляжет.
- Они как-то смогли получить Tier III сертификацию на этот сервак
- Почти половина статьи является обсасыванием какие поставщики электичества идиоты, а не CF построили кривую архитектуру.

До потери Яндексом дата центра в Финляндии, Яша каждую неделю устраивали учения по отстреливанию одного ДЦ, при котором для пользователя должно измениться НИЧЕГО. Весь Яндекс должен иметь возможность жить на 3х датацентах из четырёх. И каждое учение было неплохим таким стрессом. Не особо помню, но вроде как они проводились все по вторникам(не уверен в корректности памяти) каждую неделю, поэтому можете не удивляться, что сервисы Яндекса в основном падали в эту дату. Можете проверить новости)
Но только где Яндекс и где Cloudflare?

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

https://blog.angular.io/announcing-angular-dev-1e1205fa3039

Пока реакт спит, враг качается.

Страшно, очень страшно мы не знаем что это такое

Самая страшная штука для джунских собесов - это попытка узнать "зачем та или иная щтука нужна". К примеру, "зачем нужен О(N)?"(Поклонники Демидовича, сорян, не про вас. Вам респект).
Я уверен что вы спокойно скажете сколько времени будет выполняться new Map().set(), Array.prototype.filter, Array.prototype.sort. И это правильно, потому что надо понимать как работает твоя платформа, чтобы писать простой и предсказуемый код.

Чуток отвечёмся: какого кода вы практически никогда не видите в своих редакторах? Что 99% времени свёрнуто и зачастую никто руками не пишет? Верно, импорты.
И как люди спрашивают на собесах "что происходит когда ты вводишь урл в браузере и нажимаешь Enter?", я так же спрошу: "Что происходит в программе, когда вы пишете import или require?"

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

По этой причине реэкспорты внутри приложений - это зло. По этой причине написание юнит тестов поверх тяжёлых штук - это зло. По этой же причине забивать на граф зависимостей в приложении - это зло. Потому что внезапно может оказаться, что из-за одного криво написанного импорта все тесты в приложении начинают работать не 10s на всё, 250s на всё после чего жить становится невозможно.

Поэтому в PR'ах не стоит забивать на безобидный import {} from 'large_module'. Возможно, эта строка в случайном месте сломает вам весь CI лучшем случае, и продакшен в худшем.

https://eslint.org/blog/2023/10/deprecating-formatting-rules/

Ещё чуть-чуть и вопрос автоформатирования кода будет решён. Ну, я надеюсь на это.

https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/xMSdsEAzBwAJ

Third-party куки уже почти-почти всё. В 2024 году будет веселье.

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

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 рядом со стором. Да, вы можете вынести эту логику в какой-нибудь хук и вызывать его в каждом компоненте. Но(!) вы тут сразу бьёте по перфу, так как перевычисляете одну и ту же логику множество раз. У конкурентов же этой проблемы нет. А подобный код мы пишем каждую минуту.


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

#база