Простой код. Архитектура.
Что такое простота? Это отсутствие сложности. Что такое сложность? Любое дополнительное знание (абстракции), которого нет по умолчанию. Дополнительное от чего и что есть по умолчанию? Вот здесь и возникают преткновения, потому что это область на которую разработчик может влиять при сетапе проекта и выбора архитектуры.
Обычно, за базовый тулинг мы берем наш основной ЯП и платформу на которой он запускается. От платформы зависит std (стандартная библиотека). Для ноды это модули fs и тп, для браузера DOM и остальное. Это базовые примитивы, на которых строится остальной тулинг и вот вопрос, нужны ли нам лишние абстракции, сокращающие код, но имеющие свою семантику и сложность, или мы можем эффективно (выразительно и коротко) решать наши задачи базовыми примитивами?
Простота - близость к платформе.
Тут важно заметить, что говоря о базовых примитивах мы предполагаем что разработчик хорошо с ними знаком и досконально знает. Что, на самом деле, не всегда так, потому что это довольно большой объем знаний, который, как показывает практика, современный разработчик за время своего обучения запихнуть в себя не успевает.
И что делать? Когда платформа становится слишком большим порогом входа - нужно менять платформу! Так мы приходим к реакт / vue разработчикам, которые в начале своего пути ничего другого не знают. И это нормально, потому что ограниченными знаниями можно просто решать большую часть проблем (ради которых используемая платформа создавалась).
Платформа - то что мы знаем.
Если же у вас какие-то не обычные требования, особенно по не функциональным требованиям, вам нужно выбирать соответствующую платформу, но главное помните - простые вещи те, которые вы (и ваша команда) хорошо знает. Поэтому разработку нужно начинать с оценки способностей команды и обучения необходимому тулингу или ограничениям по использованию неизвестного.
Что такое простота? Это отсутствие сложности. Что такое сложность? Любое дополнительное знание (абстракции), которого нет по умолчанию. Дополнительное от чего и что есть по умолчанию? Вот здесь и возникают преткновения, потому что это область на которую разработчик может влиять при сетапе проекта и выбора архитектуры.
Обычно, за базовый тулинг мы берем наш основной ЯП и платформу на которой он запускается. От платформы зависит std (стандартная библиотека). Для ноды это модули fs и тп, для браузера DOM и остальное. Это базовые примитивы, на которых строится остальной тулинг и вот вопрос, нужны ли нам лишние абстракции, сокращающие код, но имеющие свою семантику и сложность, или мы можем эффективно (выразительно и коротко) решать наши задачи базовыми примитивами?
Простота - близость к платформе.
Тут важно заметить, что говоря о базовых примитивах мы предполагаем что разработчик хорошо с ними знаком и досконально знает. Что, на самом деле, не всегда так, потому что это довольно большой объем знаний, который, как показывает практика, современный разработчик за время своего обучения запихнуть в себя не успевает.
И что делать? Когда платформа становится слишком большим порогом входа - нужно менять платформу! Так мы приходим к реакт / vue разработчикам, которые в начале своего пути ничего другого не знают. И это нормально, потому что ограниченными знаниями можно просто решать большую часть проблем (ради которых используемая платформа создавалась).
Платформа - то что мы знаем.
Если же у вас какие-то не обычные требования, особенно по не функциональным требованиям, вам нужно выбирать соответствующую платформу, но главное помните - простые вещи те, которые вы (и ваша команда) хорошо знает. Поэтому разработку нужно начинать с оценки способностей команды и обучения необходимому тулингу или ограничениям по использованию неизвестного.
👍23
This media is not supported in your browser
VIEW IN TELEGRAM
Вот вам максимально наглядный пример почему не нужно использовать реактовский контекст для часто обновляемого стейта: https://codesandbox.io/s/clever-fire-dqc0my
Под капотом, при обновлении значения в провайдере реакт проходится по всем дочерним виртуальным нодам в поисках подписчиков - только если подписчик найден будет ререндер, но, повторюсь, сначала нужно его найти а для этого обойти весь нижележащий VDOM. И эта работа может занимать ОЧЕНЬ много времени на большом количестве виртуальных нод, в примере компонент списка слишком простой и стейтлес, так же я провожу эксперимент на apple m1. У пользователя реального приложения цифры могут быть значительно хуже.
Под капотом, при обновлении значения в провайдере реакт проходится по всем дочерним виртуальным нодам в поисках подписчиков - только если подписчик найден будет ререндер, но, повторюсь, сначала нужно его найти а для этого обойти весь нижележащий VDOM. И эта работа может занимать ОЧЕНЬ много времени на большом количестве виртуальных нод, в примере компонент списка слишком простой и стейтлес, так же я провожу эксперимент на apple m1. У пользователя реального приложения цифры могут быть значительно хуже.
👍11🤯5
Популярный софт, без особых изменений по сути и в апи, должен в течении лет накапливать или уменьшать количество багов? Шесть лет прошло, откуда их там тонна?
💩1
Ну вы же знаете какие видосики я вам порекомендую в эту пятницу? 😃
Плейлист с ЯЛФ, там много крутого и помимо моего доклада. У меня первые в очереди на просмотр доклады про Web Vitals и Node.js.
Плейлист с ЯЛФ, там много крутого и помимо моего доклада. У меня первые в очереди на просмотр доклады про Web Vitals и Node.js.
YouTube
Я 💛 Фронтенд 2022
Share your videos with friends, family, and the world
🔥5
Было бы круто в будущем не иметь языков программирования вовсе. Загружаешь блок-схему, а нанопринтер печатает в твоем устройстве новую схему. Программы бы выполнялись в тысячи раз быстрее.
Нет, а правда, на сколько можно поднять тех процесс, с учетом получившейся оптимизации? И возможно ли уже печать такого тех процесса запихнуть в стандартный full-tower пк?
Производительность и объем устройства зависили бы от серого вещества. Что-то напоминает 🤔
А мозг - это скорее степпер или плис?
Нет, а правда, на сколько можно поднять тех процесс, с учетом получившейся оптимизации? И возможно ли уже печать такого тех процесса запихнуть в стандартный full-tower пк?
Производительность и объем устройства зависили бы от серого вещества. Что-то напоминает 🤔
А мозг - это скорее степпер или плис?
👍2👎1
Запилил компатибл пакет для первой версии реатома (работает на третьей).
Демо (см. package.json).
Тесты вместо доки (пока что).
Демо (см. package.json).
Тесты вместо доки (пока что).
CodeSandbox
Reatom Todo App (v3-v1) - CodeSandbox
A todo list app with React-Redux and redux-steroid (with normalized store shape).
У нас есть страница со списком и фильтрами и раньше элемент списка редактировался в модалке. Ну мы же знаем что модалки зло? Конечно, конечно. Ну я переделал редактирование элемента на отдельную страницу (в рамках параллельной задачи).
И тут прилетает фичареквест от бизнеса - а можно что бы фильтры не сбрасывались при возвращении со страницы редактирования обратно на список элементов?
Прикииньте как модалка решает такие юзкейсы вообще без доп кода, а мне сейчас придется городить персистанс куда-то.
И я вот подумал, как бы еще можно решить такой кейс без доп кода, а что бы оно просто работало. Что если страницы рисовать не одна вместо другой, сбрасывая стейт, а визуально перекрывая (накладывая) их?
Нужен умный стек, с лимитом и автоматическим сбросом части истории при попытки перейти на уже лежащую в стеке страницу или еще какие правила. Но это все утилита строк на 50-100, а код страниц и компонентов сократился бы заметно.
Кто-то делал такое? Поделитесь в коментариях.
Кмк это хороший паттерн и он может показать силу SPA. Интересно что обычно мы используем классический MPA роутинг и он нас часто тормозит ментально.
P.S. и анимации переходов было бы делать таким образом заметно проще.
И тут прилетает фичареквест от бизнеса - а можно что бы фильтры не сбрасывались при возвращении со страницы редактирования обратно на список элементов?
Прикииньте как модалка решает такие юзкейсы вообще без доп кода, а мне сейчас придется городить персистанс куда-то.
И я вот подумал, как бы еще можно решить такой кейс без доп кода, а что бы оно просто работало. Что если страницы рисовать не одна вместо другой, сбрасывая стейт, а визуально перекрывая (накладывая) их?
Нужен умный стек, с лимитом и автоматическим сбросом части истории при попытки перейти на уже лежащую в стеке страницу или еще какие правила. Но это все утилита строк на 50-100, а код страниц и компонентов сократился бы заметно.
Кто-то делал такое? Поделитесь в коментариях.
Кмк это хороший паттерн и он может показать силу SPA. Интересно что обычно мы используем классический MPA роутинг и он нас часто тормозит ментально.
P.S. и анимации переходов было бы делать таким образом заметно проще.
👍3
artalog
Пробуем наноизировать goober
Результат вчерашней наноизации библиотеки goober на скриншотах. Подробности в ПРе, все оптимизации разбиты на отдельные комиты.
Я говорил на стриме, там можно заметно сократить бандлсайз с помощью optional chaing и
Напомню, они выплачивают деньги за урезание байт.
Я говорил на стриме, там можно заметно сократить бандлсайз с помощью optional chaing и
||= / ??= / ??, но для этого нужно правильно подправить сетап билда. Мне этим заниматься сейчас времени нет - можете подхватить 🙂Напомню, они выплачивают деньги за урезание байт.
Introducing Signals
Преактовцы выпустили пакет, который заимствует некоторые идеи из Solid.js.
И у него есть частичная совместимость с реактом
Для 2022 там используются достаточно стандартные решения в плане реактивщины, но…
С точки зрения вью либы они сделали то чего давно не хватало во всех этих реактах - нативные реактивные биндинги!
Что это? Я уже как-то предлагал реализовать нечто подобно на Jotai (тогда это посчитали неважной утилитой). Оно позволяет вставлять в JSX реактивные юниты без использования хуков! Трюк прост - давайте вставлять компонент-обертку, который в себе просто вызывает хук и возвращает его значение. Таким образом мы избавляемся от пачки правил использования хуков в одном рендере.
Хотя уже давным давно существует github.com/grammarly/focal, который делает нечто подобное, но преактовцы сделали интеграцию максимально прозрачной и лёгкой как с точки зрения юзер кода, так и по технической реализации (ну это они так говорят).
И, наконец, получили vue.js.
И важно тут вот что, реактивный юнит в преакте можно не просто вставлять в JSX, но и передавать в атрибуты DOM элементов - и это гейм-ченджер который позволяет практически полностью убрать ререндеры.
Интересно, конечно, что там по памяти и скорости инициализации. Ждем еще независимые перфтесты.
P.S. пакет весит как третий реатом, который еще более фичастый и универсальный 😉
Преактовцы выпустили пакет, который заимствует некоторые идеи из Solid.js.
И у него есть частичная совместимость с реактом
Для 2022 там используются достаточно стандартные решения в плане реактивщины, но…
С точки зрения вью либы они сделали то чего давно не хватало во всех этих реактах - нативные реактивные биндинги!
Что это? Я уже как-то предлагал реализовать нечто подобно на Jotai (тогда это посчитали неважной утилитой). Оно позволяет вставлять в JSX реактивные юниты без использования хуков! Трюк прост - давайте вставлять компонент-обертку, который в себе просто вызывает хук и возвращает его значение. Таким образом мы избавляемся от пачки правил использования хуков в одном рендере.
Хотя уже давным давно существует github.com/grammarly/focal, который делает нечто подобное, но преактовцы сделали интеграцию максимально прозрачной и лёгкой как с точки зрения юзер кода, так и по технической реализации (ну это они так говорят).
И важно тут вот что, реактивный юнит в преакте можно не просто вставлять в JSX, но и передавать в атрибуты DOM элементов - и это гейм-ченджер который позволяет практически полностью убрать ререндеры.
Интересно, конечно, что там по памяти и скорости инициализации. Ждем еще независимые перфтесты.
P.S. пакет весит как третий реатом, который еще более фичастый и универсальный 😉
Preactjs
Introducing Signals – Preact
👍7🤯3❤1
Forwarded from UfoStation
Опубликовали доклад с Ural Digital Weekend 2022:
«Медленная веб-страница. Что делать?»
Видео: https://www.youtube.com/watch?v=ow3eE1LokQ0
Слайды: https://bit.ly/slow_webpage
«Медленная веб-страница. Что делать?»
Видео: https://www.youtube.com/watch?v=ow3eE1LokQ0
Слайды: https://bit.ly/slow_webpage
👍3❤2