Хватит сжимать изображения руками

Сейчас я чуток начал торговать своей задницей(https://news.1rj.ru/str/xavescor_meetings_logs/6) и занимаюсь, в том числе, созданием рекламных материалов, чтобы привлечь людей.
Одним из способов доказать свою квалификацию я решил пробежаться по крупным казахстанским(и не очень) сайтам и провести онолитегу как их можно изменить минимальными телодвижениями, чтобы они работали шустрее.

И, к сожалению, я вижу, что у 99% ресурсов нет такой штуки как сжатие изображений. Как менеджер запихнул фото на лендинг, так оно и отдаётся. Не делайте так. Да, я не говорю что надо погружаться в теорию отдачи изображений(но ознакомиться стоит https://evilmartians.com/chronicles/images-done-right-web-graphics-good-to-the-last-byte-optimization-techniques). Хотя бы жмите изображения автоматом. Те же марсиане давно сделали прекрасный imgproxy(https://evilmartians.com/products/imgproxy), который сам сожмёт изображение в наилучший формат для каждого клиента.

Не позволяйте своей лени ухудшать пользовательский интерфейс. А то получится как у jusan.kz, у которого на главной находится 5 огроменных картинки, под 1 мб каждая.

А конкуренция, все-таки чуток, но работает

https://github.com/nodejs/node/issues/52134

TTI всё

Вышел наконец-то https://developer.chrome.com/blog/lighthouse-10-0, где основным изменением стало как раз удаление TTI из метрик.

TTI(time to interactive) - одна из метрик, которая показывала время от момента открытия страницы до момента, когда пользователь может взаимодействовать со страницей.
TBT(total blocking time) - сколько времени выполняются таски до статуса IDLE эвент лупа
CLS(cumulative layout shift) - насколько сильно ваша вёрстка "дергается" в процессе загрузки

Гугл считает, что мерять TTI не имеет смысла, так как эта метрика очень хорошо кореллирует с TBT. И по этой причине 10% оценки лайтхауса теперь уходит в сторону CLS. Теперь корпеть над рендерингом и структурой страницы стоит побольше времени, если хочется иметь хорошую оценку от гугла. А её хочется иметь, так как относительно этих метрик гугл, в том числе, ранжирует свою выдачу. Поэтому если вы хоитте иметь хорошее SEO, то стоит выбивать около сотни в лайтхаусе.

Так же добавили несколько новых эвристик. Но на них смотреть не так важно: просто запустите новый лайтхаус у себя на сайте и постарайтесь всё исправить о чём он говорит. Он весьма подробно рассказывает в чём может быть проблема.

В поездках айпад как возможность дополнительно вывести информацию на экран - просто незаменимая штука. Если у вас мак, то прямо советую купить какой-нибудь экран на барахолке.

Как минимум для того чтобы девтулзы вывести туда, так как мне даже на 16дюймовом маке не хватает места для браузера + девтулов

#база про технические собеседования.

Новый месяц, и мне пришла идея, что надо как-то монетизировать этот канал. Поэтому порекламлю себя же: https://news.1rj.ru/str/xavescor_meetings_logs/6

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

Намбер ван: люди не умеют говорить "не знаю".
На любой вопрос у тебя должно быть всегда 2 варианта ответа:
- Я знаю и чётко отвечаю на вопрос
- Я не знаю, ПОТОМУ ЧТО <причина>(к примеру "в работе это не нужно было" или "нагуглю, поэтому не запоминаю"), но могу предположить что ответ такой-то, так как бла-бла

Всё! Не нужно молчать, не нужно пугаться. Если ты что-то не знаешь, то значит это не было у тебя в работе. И это нормально. Не стесняйся сказать "чувак, ну ты дичь спрашиваешь. Кому это надо?".

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

{a: 1} === {a: 1} // false
'abc' === 'abc' // true

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

Набер три: Расскажи о <какая-нибудь фигня>. Этот вопрос нужно интерпретировать как "какую задачу решает эта фигня?". Тут, к сожалению, только заниматься подготовкой.
1) Если говорится о части стдлибы или js, то хороший способ зачем нужна та или иная штука - глянуть пропозалы. Например, https://github.com/tc39/proposal-promise-with-resolvers. Тут прекрасно объясняется зачем был добавлен Promise.withResolvers. И такой документ есть на каждый кусок языка за последние лет 10, если не больше.
2) Если это библиотека, то рекомендую поискать сравнения её с конкурентами, к примеру, реатом: https://www.reatom.dev/recipes/atomization/#reducing-computational-complexity.
Не забывай, каждая мелочь имеет причину в этом мире. Ничего не появляется просто так, поэтому надо искать преимущества.

Намбер фор: волнение, эканье и прочая неуверенность.
Подобная штука исправляется просто: нужно быть готовым. Как готовиться?
1) Берёшь, ищешь в гугле "50 вопросов на js интервью". И расписываешь ответ на каждый вопрос. Самостоятельно. При ответе твой мозг будет структурировать информацию и запоминать план ответа. И это самое главное. Тебе нужно понимать структуру ответа, а остальное ты сам расскажешь на собеседовании. А вот без плана ты будешь просто хлопать глазами и молчать.
2) После написания ответа идёшь в ЧатГПТ или в Genimi и узнаёшь норм ли ты написал ответ или нет. Если же нет, то переписываешь по памяти. Опять же самостоятельно. Если LLMка говорит что ты красаучег, то
3) Идёшь в чат и спрашиваешь корректно ли ты ответил на вопрос. Да, возможно люди назовут тебя дебилом или как-нибудь ещё, но это нормально. Ответ ты получишь. Но до пункта 2 не ходи в чат, так как не нужно напрягать людей там где людей можно не напрягать.
4) Ты великолепен и готов к интервью.

Намбер файв: Если хочешь узнать ещё какие минусы, то всё просто, идёшь сюды https://news.1rj.ru/str/xavescor_meetings_logs/6.

https://github.com/tc39/proposal-iterator-helpers

Вот такая штука недавно появилась. И самое прекрасное, что оно уже есть в core-js(https://github.com/zloirock/core-js?tab=readme-ov-file#iterator-helpers) и вскоре появится в хроме(https://v8.dev/features/iterator-helpers).

Array.from прощай, ты теперь не нужен(почти).

Немного о том почему отсуствие базовых знаний в SEO со стороны фронтенд разраба могут поделить на ноль большой продукт. LinkedIn

https://www.jetbrains.com/webstorm/whatsnew/

Вот и новая версия WS, в которой jB всё-таки сдались в том чтобы поддерживать TS. Теперь мы окончательно живём в мире, где lang_server > spec.

https://9to5mac.com/2024/04/10/alternative-iphone-web-browsers/

А вот и плюсы нагиба монополистов. Рынок становится чуток конкурентнее. Хотя интересно к чему в итоге это приведёт, так как запрет альтернативных браузеров на ios было единственной причинай почему Chrome не захватил весь мир. А теперь, возможно, захватит. А может и нет.

Где-то полгода назад я ввёл привычку для себя, понемногу работать на д техническим долгом https://news.1rj.ru/str/xavescor_code/14

Но в какой-то момент я разгрёб почти всё и плюнул на это, так как стало лень этим заниматься. Это произошло этим январём. И вот прошло 4 месяца. И у нас опять 2/3 зависимостей выпустили свои мажоры и небольшая попытка поставить новую зависимость взрывает сборку, так как сборщик резолвит не ту версию зависимости из-за дубликата их в node_modules.

Вывод: не плюйте на необходимые привычке в работе. И слежка за актуальностью зависимостей - одна из них

Не так давно я описывал, что понимание реактивности и описания логики в реактивном стиле очень важно для роста фронтенд разработчика. https://news.1rj.ru/str/xavescor_code/101

Но важность вскоре превратится в необходимость, так как в стандарт хотят затащить реактивные примитивы https://github.com/tc39/proposal-signals/issues/178. И это будет, как сказал автор @effector_news в одной из бесед, «сродни переноса jQuery в стандарт. Мы перестанем заниматься изобретанием велосипедов и будем заниматься реально значимыми вещами»

У вас есть год-два чтобы подготовиться к этому, если вы всё ещё не осилили как выглядит реактивное программирование)

Если вы хотите реально знать свои инструменты, но надо знать не только преимущества, но и недостатки. Одним из недостатков тайпскрипта на этой неделе для меня оказалось отсутствие Exact типа.

Мы используем кодген для слоя связи с бекендом и у нас огромное количество функций в стиле getPosts({param1: value1, …}).
И вот тут нас ждала засада.
Представьте: бекенд меняет контракт, переименовывая один параметр. И, спасибо монорепе, мы сломаем CI, если типы не будут совпадать с логикой.
Но есть один нюанс. У нас могут быть Optional поля. И вот тут в колено во всю силу стреляет дак-тайпинг, потому что {aba: 1} является подтипом {aaa?: 1}. И ты никак переименование aaa в aba не отловишь.

В итоге придётся кодгенить зод схему, чтобы отловить изменения контрактов в рантайме. Так что теперь нужно писать валидаторы схем не только при получении данных, но и при их отправке(

https://nodejs.org/en/blog/announcements/v22-release-announce

Главная фича:

This release adds require() support for synchronous ESM graphs under the flag --experimental-require-module.

Спасибо, bun

Ну и другой релиз

https://react.dev/blog/2024/04/25/react-19

2 года чуваки работали над тем как решить проблемы ререндера. В итоге решили оставить саму концепцию, но поправить часть кривостей, которая она вызывает.

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

На этой неделе подвалило ещё 2 важных релиза:
https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-5-beta/
TS научится выводить тайпгарды самостоятельно, без явного описания.

https://module-federation.io/
Теперь эта технология стала бандлер-независимой. Теперь мы сможем шарить модули между проектами с разными бандлерами. Большое событие, кмк.

Ну и важная статья о том насколько важно крупным проектам быть early-adopters в новых технологиях. А так же как менеджить большие изменения в опенсорсе:
https://astro.build/blog/node-test-migration/

Как подготовить публичное выступление

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

Спешу поделиться и с вами

Не так давно мы решили к PR'ам выводить в статистику не только отчёт по увеличению бандла, но и по уменьшению. Всё-таки ощущать себя молодцом всегда приятно.

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

Так что собирайте статистику. Она лишней не бывает. Странности в ней могут показать неочевидные проблемы в проектах.

Чат, что вы думаете о «тупых» продуктах по типу https://remarkable.com/store/remarkable-2?

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

А вы как думаете? Пробовали ли что-то подобное?