Улучшаем JavaScript-код с помощью стрелочных функций

Громкий заголовок. Посредственный текст, вообще заголовку не соответствующий. Десятки плюсов в первые же минуты публикации. Для чего вы писали, что за парад тщеславия?

Давно у нас не было игрушек на $mol... Встречайте Гипер...

Вот эту еще надо))

Реакт уже никогда в жизни не догонит angular по...

Твой фреймворк самый быстрый, даже быстрее ванильного HTML/JS.
Правда ломает поиск по странице, режим для чтения и кто его знает что еще. Но самый лучший.

К этому самому лучшему фреймворку мне нужно дополнительно прикрутить то, что не должно было сломаться – поиск. Поиск, который доступен в браузере по умолчанию.

Этот прикрученный сбоку поиск лучше чем, встроенный в браузер.

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

Но это мы отвлеклись. Я лишь хотел сказать, что если гонка на 1 круг, и все его честно бегают, а ты пересекаешь стадион и приходишь к финишу первым, то пришел ты конечно первым, но не победил.

Реакт уже никогда в жизни не догонит angular по...

Ну если чисто чтобы ачивку «я первый» получить, то да, это победа. С другой стороны, у других решений в этом списке работает, например, CTRL + F по странице, а режим чтения не выдает какие-то иероглифы. Я такой победой был бы неудовлетворен ¯\_(ツ)_/¯

Реакт уже никогда в жизни не догонит angular по...

А если играть по честному, без виртуализации?

Реакт уже никогда в жизни не догонит angular по...

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

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

Можно и так

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

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

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

Да.

Было

Стало

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

Если интерфейс похож на «пульт управления космическим кораблём», значит, задачи действительно сложнее стандартного отчёта или формулы в Excel 

Вы эти клише заказчикам оставьте.

Если опыт вашего бизнеса...
...но в большинстве B2B и корпоративных проектов

Как изящно вы завуалировали то, что на самом деле хотели сказать. Что-то вроде – «Да ты просто над сложными проектами не работал!».

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma

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

Все эти «сложные интерфейсы» не более чем пародия на эксель, а зачем он пользователю? Дайте ему уже сформированные отчеты/почитанные результаты, а не калькулятор. Тогда выяснится, что интерфейс может быть простой.

Throw — это новый goto

Ну ну знаю...

Вот у нас в JavaScript, а точнее в браузерном API есть fetch – API которого выделяется на фоне других браузерных API как раз использованием result вместо throw. И как по мне, это неудобно:

const result = await fetch('https://habr.com/');

Во первых, нам все равно здесь нужен try/catch, потому что может произойти ошибка при отправке запроса:

try {
  const result = await fetch('https://habr.com/');
} catch(error) {
  // ...
}

А потом еще проверят result:

try {
  const result = await fetch('https://habr.com/');
  if (result.ok) {
    // ... все хорошо
  } else {
    // все плохо
  }
} catch(error) {
  // ...
}

Хотя на мой взгляд, было бы лучше так:

try {
  const result = await fetch('https://habr.com/');
} catch(error: RequestError | ResponseError) {
  // ...
}

Да и в целом try/catch лаконичнее:

class Foo {
  data: JSON;
  
  async doWork() {
    try {
      // можно обойтись без локальных переменных в замыкании
      this.data = await HttpClient.get();
    } catch(error) {
      // ...
    }
  }
}

class Foo {
  data: JSON;
  
  async doWork() {
    // лишняя переменная
    const result = await HttpClient.get();
    // ложно-положительный результат
    if (result.ok) {
      this.data = result;
    } else {
      // ...
    }
  }
}

Сравнение производительности React-компонентов: Gravity UI...

@gravity‑ui/uikit показывает конкурентоспособные результаты:

Но показывать мы их не будем.

Сравнение производительности React-компонентов: Gravity UI...

Так ты в код полезь, мильонтыщ юзефектов чтобы кнопку перекрасить))

«Мой код не работает!» или как я превратила баг в фичу (почти случайно)

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

От React всё так же веет безумием, но все об этом молчат

Мой любимый прием)

Я всегда видя в резюме список технологий, прошу рассказать о недостатках пары представленных. Работает безотказно! Например, самый частый случай — module federation, только попросишь рассказать, так сразу — нууу, настраивал не я, там целая команда, бла, бла, бла…

От React всё так же веет безумием, но все об этом молчат

Какая-то безусловно, вопрос в количестве. Понятно, что из-за того как Map устроен, когда мы что-то в неё кладем, как минимум создается один объект типа { key: , value: }, и под него выделяется память. Я это имел ввиду.

От React всё так же веет безумием, но все об этом молчат

Не знаю, что я из этого должен понять.

<!doctype HTML>
<html lang="en">
  <head>
    <script type="module">
      class MyCoolMap extends Map {}
      const a = new MyCoolMap;
      const b = new MyCoolMap;

      const fill = document.getElementById('fill')
      fill.addEventListener('click', () => {
          for (let i = 0; i < 100; i++) {
              a.set(Math.random(), Math.random());
              b.set(Math.random(), Math.random());
          }
      })

      const clear = document.getElementById('clear')
      clear.addEventListener('click', () => {
          a.clear()
      })
    </script>
  </head>

  <body>
    <button id="fill">fill</button>
    <button id="clear">clear</button>
  </body>
</html>

загрузка страницы

после нажатия на fill

после нажатия на clear

MyCoolMap использовал чтобы удобнее было фильтровать по классу.

Что именно мы пытаемся проверить?

CreateObservableStore: реактивный store с гранулярными подписками и идеальной интеграцией с React

store.$.user.age = 5

Напрямую это так: store.user.age = 5

store.update('user.age', 5)

Лишний вызов функции + непривычный способ обращения к свойству + высокая вероятность опечататься.

sotre.update(() => store.$.user.age, 4)

Лишний вызов уже двух функций + лишний чужеродный $.

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