Node.js CLI Apps Best Practices

Список бест-практисов для CLI приложения на node.js. Разделены на группы:
- Опыт использования
- Публикация
- Встраиваемость (Interoperability)
- Доступность
- Тестирования
- Работа с ошибками
- Разработка
- Аналитика
- Версионирование

https://github.com/lirantal/nodejs-cli-apps-best-practices

#development #nodejs #cli #recommended

Secure Code Review Tips to Defend Against Vulnerable Node.js Code

Короткая статья про обеспечение безопасности в node.js приложениях. Данная статья, я так понял, является первой в цикле и рассказывает о небезопасных паттернах кода (на самом деле паттерн 1, но почему-то разбит на 4 части).

В целом, один из способов уменьшения риска получить проблемы из-за недостаточной безопасности - это качественное проведение Code Review.

Паттерн, рассматриваемый в данной статье в разных вариациях - это склеивание строк для вызова команд без предварительной валидации

const userInput = req.query.input;
const command = `echo ${userInput}`;
exec(command, (error, stdout, stderr) => {
  // Handle the command execution
});

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

https://www.nodejs-security.com/blog/secure-code-review-tips-to-defend-against-vulnerable-nodejs-code

#development #nodejs #security

Event Loop в деталях

Неплохая статья, объясняющая для новичков, как работает Event Loop в Javascript. Статья делает это не совсем точно (собственно один из комментариев на хабре посвящен именно этому аспекту статьи), но достаточно доступно и понятно для тех, кто не знает как работает Event Loop. В целом, как начальная статья для джунов вполне ок.


https://habr.com/ru/articles/762618/

#development #javascript #eventLoop #tutorial

Leading Successful Product Teams

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

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

- Избегайте встреч и созвонов. Вместо этого используйте асинхронные коммуникации (чаты, рабочие инструменты и тд)
- Предоставьте по-крайней мере 3 дня фокусированный работы в неделю для дизайнеров и разработчиков.
- Доверяйте команде самой принимать решения. Ваша задача, чтобы команда понимала, что делает, устранять препятствия и защищать от внешних воздействий.
- Будьте открытыми. Команда должна создавать продукт, не закрываясь от других команд и людей. Это неизбежно повысит качество создаваемого продукта
- Держите количество процессных активностей (дейли, груминги и тд) в таком количестве, чтобы это уже помогало работать, но еще не мешало
- Не проводите синки по задачам на всю команду ежедневно, достаточно собраться раз в неделю, замотивировать команду и подсветить блокеры
- Используйте как можно меньше инструментов для реализации задачи
- Автоматизируйте все, что возможно автоматизировать. Команда должна проводить ценное время с коллегами, пользователями, а не заниматься рутиной
- Заботьтесь о своих пользователях.
- Большинство актов общения и совместной работы должны быть асинхронными.
- Позвольте участникам команды решать проблемы сообща, если это полезно. Но не забудьте задокументировать все принятые решения.
- Предоставляйте еженедельные отчеты для всех заинтересованных о прогрессе в работе
- Создайте публичный родмап
- Сфокусируйтесь на регулярных итерациях вместо ярких запусков
- Не бойтесь выбрасывать сделанную работу
- Поставленное пользователю лучше, чем идеальное, но не поставленное
- Будьте добрыми

https://arie.ls/2023/leading-successful-product-teams/

#managment #team

Дайджест за 2023-12-04- 2023-12-08

⭐67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
Список из 67 трюков для дебага кода в браузере. Причем, это не те простые трюки, которые часто описывают в туториалах, здесь описаны прям хорошие приёмы. Описаны применение API-браузеров и продвинутой использование breakpoint'ов с условием по выражению.


⭐Node.js CLI Apps Best Practices
Список бест-практисов для CLI приложения на node.js. Разделены на группы:
- Опыт использования
- Публикация

Secure Code Review Tips to Defend Against Vulnerable Node.js Code
Короткая статья про обеспечение безопасности в node.js приложениях. Данная статья, я так понял, является первой в цикле и рассказывает о небезопасных паттернах кода (на самом деле паттерн 1, но почему-то разбит на 4 части).

В целом, один из способов уменьшения риска получить проблемы из-за недостаточной безопасности - это качественное проведение Code Review.

Event Loop в деталях
Неплохая статья, объясняющая для новичков, как работает Event Loop в Javascript. Статья делает это не совсем точно (собственно один из комментариев на хабре посвящен именно этому аспекту статьи), но достаточно доступно и понятно для тех, кто не знает как работает Event Loop. В целом, как начальная статья для джунов вполне ок.



Leading Successful Product Teams
Набор правил успешной команды от лида команд дизайн-систем. Дизайн-системы отличаются от традиционных продуктовых команд, но, тем не менее, имеют много пересечений.

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

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Web Components Eliminate JavaScript Framework Lock-in

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

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

Автор делает TodoList с использованием React, Vue, Svelte и Solid. Все созданные компоненты оборачиваются в кастомные элементы и используют друг друга как кастомные элементы. При этом автор также обращает внимание на гибкость веб-компонентов, организации взаимодействия и хранении стейта.

Если у вас есть подобная задача, ну, например, у вас есть система на каком-нибудь старом angular, а вам надо поставлять туда фичи, а вы - React-разработчиков, то вам может подойти подобный подход с интеграцией через веб-компоненты

https://jakelazaroff.com/words/web-components-eliminate-javascript-framework-lock-in/

#development #javascript #webcomponents

Track Frontend JavaScript exceptions with Playwright fixtures

Достаточно интересная статья про использование API playwright для расширения функционала тестов на примере слежения за неперехваченными глобальными ошибками.

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

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

test("Checkly blog lazy loading", async ({ page }) => {
  // set up a new Array to collect thrown errors
  const errors: Array<Error> = []

  // listen to exceptions during the test sessions
  page.on("pageerror", (error) => {
    errors.push(error)
  })
  
  // All your test code…
  // …

  // assert that there haven’t been any errors
  expect(errors).toHaveLength(0)
})

Но писать такое в каждом тесте непродуктивно. У Playwright есть API для расширения метода test - фикстуры. Фикстуры это такие объекты или функции, которые доступны в тесте и они создаются новые для каждого теста.

const myTest = test.extend<{
 testUser: { name: String }
 loggedInPage: Page
}>({
  testUser: {
    name: "Jenny Fish",
  },
  async loggedInPage({ page }, use) {
    await page.goto("/login")
    /* code */
    await use(page)
    // clean up steps after the test
  },
})

// Теперь testUser и loggedInPage доступы в тесте
myTest("Your custom Playwright setup", async ({ testUser, loggedInPage }) => {
  // …
})

Фикстуры устроены так, что у них есть 3 этапа:
- подготовка
- передача в тест - await use(fixture) передает фикстуру в тест и дожидается завершения теста
- действия после завершения теста

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

// extend the test object and assign it to a new `myTest` variable
const myTest = test.extend<{ page: void }>({
  // override and use Playwright’s base `page` fixture 
  page: async ({ page }, use) => {
    const errors: Array<Error> = []

    page.addListener("pageerror", (error) => {
      errors.push(error)
    })

    // pass the `page` object to tests using it
    await use(page)

    expect(errors).toHaveLength(0)
  },
})

Чтобы не использовать во всех тестах myTest, можно создать свои модуль с экспортируемым test и использовать его во всех тестах.

Лично я бы не стал использовать слежение за неперехваченными ошибками в автотестах (по-крайней мере в блокирующей манере), но подход достаточно интересный, а статья хорошо объясняет на практике, как использовать фикстуры в playwright

https://www.checklyhq.com/blog/track-frontend-javascript-exceptions-with-playwright/

#development #javascript #playwright #testing

console ninja: console log output right next to your code

Интересный тулинг по типу wallaby и quokka, который связывает код в IDE и консоль в приложении. Т.е. например, вы поставили console.log(myVariable) и вывод консоли отобразится у вас прямо в IDE. Кроме этого инструмент умеет связывать ошибки с кодом, создавать лог-поинты (это как брекпоинты, только вместо остановки мы просим вывести значение переменной в лог) и еще всякое.

Есть платная и бесплатная версии. Посмотрите, возможно вам понравится.

https://console-ninja.com

#development #javascript #tool

Keep that cursor still!

Веб-разработчики делятся на 2 типа - познавшие боль от работы с курсором в input'ах и тех, кому это только предстоит.

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

В статье разбирается, почему оно так работает. Если коротко, то в спеке HTML четко написано, что если значение инпута программно изменяется и новое значение отличается от того, что было до этого - то курсор перемещается в конец.

В целом, это поведение мы можем видеть в двух кейсах:
- Преобразование значения в onChange
- Асинхронный обработчик. Здесь не обойтись без примера: в инпуте было значение авг, пользователь вводит б между а и в. Но у нас так устроена архитектура, что значение в инпут ставится из какого-нибудь redux, а туда новое значение попадает через несколько тиков в эвент-лупе. С точки зрения браузера это означает, что мы сначала поменяли значение абвг на авг, а через пару тиков на абвг. Оба раза курсор улетел в конец

По второму кейсу статья не дает подробных советов т.к. это вопрос архитектуры решения.
По первому же кейсу решение следующее - браузер предоставляет нам позицию курсора на момент обработки события и API для установки курсора. С помощью этих данных мы можем синхронизировать новое значение и положение курсора. Для реализации автор предлагает 2 решения:

Первое: устанавливать положение курсора сразу после рендера с помощью useLayoutEffect

export default function App() {
 const position = useRef({
  beforeStart: 0,
  beforeEnd: 0
 });

 const [val, setVal] = useState("hello");
 const inputRef = useRef<HTMLInputElement>(null);
 useLayoutEffect(() => {
  inputRef.current.setSelectionRange(
   position.current.beforeStart,
   position.current.beforeEnd
  )
 }, [val]);

 const onChange = (e: ChangeEvent<HTMLInputElement>) => {
  const beforeStart = e.target.selectionStart;
  const beforeEnd = e.target.selectionEnd;
  position.current = {
   beforeStart,
   beforeEnd
  };

  setVal(e.currentTarget.value.toUpperCase());
 };
 return (
  <input ref={inputRef} value={val} onChange={onChange} />
 );
}

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

export default function App() {
  const position = useRef({
    beforeStart: 0,
    beforeEnd: 0
  });

  const [val, setVal] = useState("hello");

  const inputRef = useRef<HTMLInputElement>(null);

  const onChange = (e: ChangeEvent<HTMLInputElement>) => {
    const beforeStart = e.target.selectionStart;
    const beforeEnd = e.target.selectionEnd;

    position.current = {
      beforeStart,
      beforeEnd
    };

    flushSync(() => {
      setVal(e.currentTarget.value.toUpperCase());
    });

    inputRef.current.setSelectionRange(beforeStart, beforeEnd);
  };

  return <input ref={inputRef} onChange={onChange} value={val} />
}

В общем, очень крутая статья, в ней крутые sandbox'ы с примерами проблемы и примерами решений, в которой очень подробно разбирается почему происходит эта проблема (включая разбор внутренностей React). Рекомендую к прочтению

https://giacomocerquone.com/keep-input-cursor-still/

#development #javascript #react #input #cursor #recommended

Хороший обзор погружения в solid - борьба со сборщиком и реактивностью. У меня всплывают воспоминания об использовании Vue когда еще весь тулинг необходимо было настраивать руками 🙃

Я уже написал на solid.js аж целых два маленьких приложения.
Поделюсь опытом в сравнении с реактом, раз уж они под реакт мимикрируют.

День первый.
Я полистал документацию, посмотрел ролики, впечатлился качеством материалов.
Нашел необходимый плагин для vite, шаблон конфгиа по ts, запилил hello world, все круто!
Надо было сразу выбросить реакт и взять солид, чего ждал - не понятно. Счас хуяк хуяк и в продакшен супер быстрый апп, с маленьким бандлом, бешеным перфом, гранулярными апдейтами, ууухххх

День второй.
Плагин оказался со странностями. Почему он перетирает часть конфига моего vite, и принудительно заменет happydom на jsdom???

pnpm орет на меня что у меня vite 4, а плагин только до 3 ей версии. К тому же после изменений в стилях у меня появляется копия всего приложения на странице. Одна по другой. +1 копия приложения после каждого обновления.
Потратил время на изучение проблемы
- нашел ишьюс в котором проблемы с happydom известна пол года. И даже вроде мр есть. Но всем плеват. Решается откатом на старую версию. Наконец замерижили фикс.
- по поводу дублирования приложения - оказывается надо плагину hrm комментариями подсказать что index.tsx где я маунчу апп в дом дерево перевызывать не надо /* @refresh skip */
в целом очень странно видеть что фреймворк так сильно завязаный на сбороку - так слабо поддерживает единственный официальнаый плагин для vite который счас мейнстрим сборщик.

День третий.
Два часа пытался понять почему у меня не ренедериться вьюшка.
Если на реакте заработает почти любой говнокод, ужасно, с кучей лишних перерендоров - но заработает, то в solid - малейшая оплошность приводит к тому что рендера не будет.
Без ошибок в рантайме или иде. Я просто смотрю в дэбагере как мой ресурс скачался, обновитлся сигнал, но ничего не происходит - в вьюшке все так же висит ...loading
дэбагер не помогает - надо слишком много знать о внутрянке солида чтоб в этом был толк.
В итоге оказалось что дело в тернарке.
Тернарки в jsx использовать можно, но только один раз. Как с ядовитыми грибами, ага.
Только специальный компонент <Show>, запомните.
про Optional chaining тоже лучше забыть. Один раз ваше выражение foo?.bar() вернет undefined вместо сигнала и больше вы ререндеров не увидите здесь.

День четвертый.
ClassList как будто бы должен был заменить clsx но на самом деле это пятая нога. Не заменяет, а только лишная апи мешается и создает избыточность.
Typescript, и так бывает больно писать, а с solid это будет еще веселее.
Подводных камней столько что есть отдельный раздел документации который я почему-то не замeтил когда знакомился с солидом первый раз

Вобщем итого -
если ваше приложение на солиде работает - оно будет работать быстро. Это в реакте можно открыть код и сказать "божеш ты, как это го-но работает то, кто это, какой return первой строкой, кто правила хуков будет соблюдать - и тп"
реакт приложение как то накоряканое будет работать хоть и плохо.
В солиде готовтесь превозмогать, без ошибок и подсказок, девтулзов и т.п. выезжать на опыте, внимательном прочтении доки, знать где тонко и писать jsx с минимум логики.
Я вам вобще не рекомендую по началу в солидовском jsx писать выражения js как бы абсурдно это не звучало.
Но, если вам нужен перф, у вас все обновляется например по сокетам и мигает как новгодняя елка каждая панелкьа отдельно - да, это для солида.
Касательно похожести на реакт - ваш код смогут читать (но не писать) реактеры, на этом все

Как появились веб-пуши Apple в Тинькофф

Возможность использовать пуши в браузерах появилась довольно давно, но в safari с этим были сложности, что останавливало внедрение этой технологии. Но, начиная с ios 16.4 safari поддерживает веб-пуши. Статья рассказывает, как в компании Тинькофф начали применять веб-пуши, с какими проблемами столкнулись и как их решали. Также вкратце рассказывается про особенности работы пушей: необходимость шлюза, 2 варианта использования, проблемы с отписками и переподписками и доставляемостью.

Хорошая ознакомительная статья про возможность веб-платформы и её практическое применение большой компанией.

https://habr.com/ru/companies/tinkoff/articles/776658/

#development #javascript #habr #webPush #pwa

Дайджест за 2023-12-11 - 2023-12-15

Web Components Eliminate JavaScript Framework Lock-in
Очередная статья про то, что веб-компоненты позволят нам создавать сайты, используя разные технологии. Сами же веб-компоненты могут использоваться как клей между этими технологиями.

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

Track Frontend JavaScript exceptions with Playwright fixtures
Достаточно интересная статья про использование API playwright для расширения функционала тестов на примере слежения за неперехваченными глобальными ошибками.

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

console ninja: console log output right next to your code
Интересный тулинг по типу wallaby и quokka, который связывает код в IDE и консоль в приложении. Т.е. например, вы поставили console.log(myVariable) и вывод консоли отобразится у вас прямо в IDE. Кроме этого инструмент умеет связывать ошибки с кодом, создавать лог-поинты (это как брекпоинты, только вместо остановки мы просим вывести значение переменной в лог) и еще всякое.

Есть платная и бесплатная версии. Посмотрите, возможно вам понравится.

⭐Keep that cursor still!
Веб-разработчики делятся на 2 типа - познавшие боль от работы с курсором в input'ах и тех, кому это только предстоит.

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

Как появились веб-пуши Apple в Тинькофф
Возможность использовать пуши в браузерах появилась довольно давно, но в safari с этим были сложности, что останавливало внедрение этой технологии. Но, начиная с ios 16.4 safari поддерживает веб-пуши. Статья рассказывает, как в компании Тинькофф начали применять веб-пуши, с какими проблемами столкнулись и как их решали. Также вкратце рассказывается про особенности работы пушей: необходимость шлюза, 2 варианта использования, проблемы с отписками и переподписками и доставляемостью.

Хорошая ознакомительная статья про возможность веб-платформы и её практическое применение большой компанией.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Доклады секции Frontend на Codefest13

В открытом доступе появились записи доклады с секции Frontend на Codefest13. Лично я посмотрел не все доклады с этой секции прошедшего Codefest, но горячо рекомендую, конечно же, свой доклад про использование ChatGPT и доклад Никиты Сидорова про прогрессивный рендеринг (или что-то в этом роде) в Яндекс.Маркете.


https://www.youtube.com/playlist?list=PL8761XQAJnrZtx3JvX50duslRe_mU7_Zl

#development #youtube #codefest

UX Core - Cognitive biases in product management and HR

Каталог из 210 когнитивных искажений, которые сгруппированы по типам и имеют хорошее описания действия этих искажений в разработке продукта и HR-вопросах, а также как с ними работать. Доступно на русском и английском языке.

Рекомендую к изучению или хотя бы к беглому просмотру

https://keepsimple.io/uxcore

#managment #cognitiveBiases #product #recommended

Oxlint General Availability | The JavaScript Oxidation Compiler

Публичный релиз нового линтера - oxlint. Если коротко, он в разы быстрее, чем eslint. И в разы же менее функциональный.

Основные поинты:
- в 10-100 раз быстрее eslint. В посте приведен пример shopify, которые запускали eslint в 40 воркеров в CI и это занимало 75 минут (я так понял суммарно). Теперь же проверка занимает 10 секунд, а ошибки намного понятнее. Кейс максимально странный, как будто в shopify просто решили забить на инженерные практики - сначала завалили проблему железом, а потом перешли на более быстрый, но менее функциональный, новый тул. Повезло, что линтер - это не критичный инструмент и миграция не может сломать прод
- Вывод ошибок намного лучше
- Системы плагинов нет, но команда переносит лучшие правила в oxlint
- По-умолчанию включены только важные правила, которые влияют на корректность работы кода. Всякое про стиль, производительность, субъективность - отключено по-умолчанию

https://oxc-project.github.io/blog/2023-12-12-announcing-oxlint.html

#development #javascript #linter #oxlint

The await event horizon in JavaScript

Небольшая статья про родовую травму JS - неотменяемые Promise'ы. Автор сравнивает ожидание промиса через await someCall() с горизонтом событий черной дыры. Это очень интригующее, и немного странное, сравнение. Все что попадает за горизонт событий черной дыры - это граница, за которой ничего не видно т.к. даже свет не может вырваться оттуда. Мы можем только ждать, вырвется что-то оттуда или нет. Также и с await - однажды поставив его в коде, мы не можем быть уверены, что управление когда-нибудь вернется.

Автор объясняет, что это давняя проблема (ей около 10 лет) и комитет стандартизации решил её не решать. Эта проблема может приводить к утечкам памяти. Как возможное решение автор описывает использование abortController (или других аналогичных способов) во всех асинхронных функциях. Но это не общепринятый паттерн и мы не можем быть уверены, что весь код приложения (в том числе код node_modules) будет использовать этот паттерн.

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

Поэтому, пока вы используете await, вы неизбежно будете сталкиваться с проблемой горизонта событий.

https://frontside.com/blog/2023-12-11-await-event-horizon/

#development #javascript #async/await #Promise #generators

Web Performance Calendar » Benchmarking, Profiling, and Optimizing JavaScript libraries

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

Автор замерил скорость работы своей либы и в профайлере нашел самую медленную часть - plural (функция которая склоняет слова - 1 книга, 2 книги, 5 книг). Замена реализации на Intl.PluralRules дала ускорение в 3 раза

Дальше автор столкнулся с проблемой замеров скорости работы функции. Оказывается, профайлер в node.js - сэмплирующий. Т.е. каждые несколько милисекунд профайлер собирает информацию, какие функции сейчас работают. Если функция работала в sample1 и в sample2 - то считается, что она работала все время между sample1 и sample2. Как следствие, если функция выполнилась между sample1 и sample2, то её вообще не будет в профайлере. Автор просто не видел некоторых функций в профайлере.

Интересно, что профайлер в Google Chrome может собрать более детальную информацию. Но новой информации о том, что стоит ускорять это не дало.

Однако, автор знал о паттерне "плоское AST". Казалось бы, причем тут AST и локализация текста? Я просто не приводил пример использования кода приложения. Вот он:

const message = `You have {numBooks, number} {numBooks, plural, one {book} other {books}}.`;

Чтобы разобрать такую конструкцию, необходимо построить AST. А если мы строим AST - то оно иерархическое. Но есть концепция плоского AST, которая позволяет вместо рекурсивных вызовов обходить его в цикле.

Автор делает правку работу парсера и компилятора и ускоряется еще на 20% (если я правильно понял).

Статья немного странная, но достаточно интересная.

https://calendar.perfplanet.com/2023/benchmarking-profiling-and-optimizing-javascript-libraries/

#development #javascript #performance

Дайджест за 2023-12-18 - 2023-12-22

Доклады секции Frontend на Codefest13
В открытом доступе появились записи доклады с секции Frontend на Codefest13. Лично я посмотрел не все доклады с этой секции прошедшего Codefest, но горячо рекомендую, конечно же, свой доклад про использование ChatGPT и доклад Никиты Сидорова про прогрессивный рендеринг (или что-то в этом роде) в Яндекс.Маркете.



⭐UX Core - Cognitive biases in product management and HR
Каталог из 210 когнитивных искажений, которые сгруппированы по типам и имеют хорошее описания действия этих искажений в разработке продукта и HR-вопросах, а также как с ними работать. Доступно на русском и английском языке.

Рекомендую к изучению или хотя бы к беглому просмотру

Oxlint General Availability | The JavaScript Oxidation Compiler
Публичный релиз нового линтера - oxlint. Если коротко, он в разы быстрее, чем eslint. И в разы же менее функциональный.


The await event horizon in JavaScript
Небольшая статья про родовую травму JS - неотменяемые Promise'ы. Автор сравнивает ожидание промиса через await someCall() с горизонтом событий черной дыры. Это очень интригующее, и немного странное, сравнение. Все что попадает за горизонт событий черной дыры - это граница, за которой ничего не видно т.к. даже свет не может вырваться оттуда. Мы можем только ждать, вырвется что-то оттуда или нет. Также и с await - однажды поставив его в коде, мы не можем быть уверены, что управление когда-нибудь вернется.

Автор объясняет, что это давняя проблема (ей около 10 лет) и комитет стандартизации решил её не решать. Эта проблема может приводить к утечкам памяти. Как возможное решение автор описывает использование abortController (или других аналогичных способов) во всех асинхронных функциях. Но это не общепринятый паттерн и мы не можем быть уверены, что весь код приложения (в том числе код node_modules) будет использовать этот паттерн.

Web Performance Calendar » Benchmarking, Profiling, and Optimizing JavaScript libraries
Статья про оптимизацию перформанса библиотек. Автор разрабатывает приложение, в котором необходимо локализовывать контент на много разных языков. Но используемая библиотека была слишком громоздкой, поэтому он решил сделать свою (на основе существующего кода, как я понял) и заодно сделать её очень быстрой

Автор замерил скорость работы своей либы и в профайлере нашел самую медленную часть - plural (функция которая склоняет слова - 1 книга, 2 книги, 5 книг). Замена реализации на Intl.PluralRules дала ускорение в 3 раза

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

You don't need JavaScript for that

Небольшая статья про вещи, которые в UI можно реализовать вообще без JS. Автор показывает по шагам, по-немногу усложняя примеры, как с помощью базовых HTML и CSS можно создавать достаточно удобные базовые элементы

Автор разбирает реализацию следующих элементов:
- Кастомизируемый чекбокс
- Инпут с автосаджестом
- Color picker
- Accordion
- Модалка


https://www.htmhell.dev/adventcalendar/2023/2/

#development #javascript #html #css #nativeDom