Ботаню реактушку. Написал на React один небольшой проект в прошлом году, но сейчас хочу углубиться. Как изучаю?

1. Читаю книгу. Книга хорошая, хотя перевод неидеальный и в паре мест вижу ошибки/опечатки, но они очевидны и не вводят в заблуждение. Понравилось, что в начале книги есть глава про то, что появилось в ES6. Так-то на JS я и в древнем году 2009м вполне программил, но за новшествами с ES2015=ES6 плотно не следил. Освежить было полезно. Про функциональное программирование, чистые функции, императивный и декларативный подход — написано хорошо.

Принцип выбора книги — ищу то, что есть, смотрю отзывы, смотрю оглавление. В идеале мне нравится поехать в большой книжный и там полистать книгу перед покупкой, чтобы купить то, что понравилось. Эта книга у меня есть в бумаге и я листал её перед покупкой, хотя сейчас читаю с цифры, так как бумажная версия не со мной. Читать с айпада — ок. Но интернет на планшете может отвлекать, иногда стоит отключить.
#IT #frontend #books #javascript #interesting

2. Использую на айпаде приложение GoodNotes для заметок по ходу чтения. PDF с книгой там же подгружен. Удобно. Хотя он по-моему платный и возможно сейчас с продлением будут проблемы, не знаю. Можно писать и на бумаге в блокноте, важно, чтобы самому было приятно вести этот процесс, пусть это будет хороший блокнот или тетрадь и удобная ручка.

Почему пишу от руки, а не набиваю? Есть мнение, что так запоминается лучше, когда ручкой/стилусом пишешь, это как-то иначе воздействует на мозг. Когда изучал Python, вел заметку в Evernote, выписывая основные структуры данных и языковые конструкции.

3. Читаю официальную документацию. У реакта она сейчас а) хороша б) переведена на много языков, в том числе на русский. Действительно отличная документация, во всяком случае для изучения библиотеки.

Скажем, документация у Python мне не нравится. Использовать как справочник её можно, но, кажется, не более того, изучать гораздо приятнее по книге.

Документация по Rust отличная — там полноценная структурированная книга, заходишь и сразу понятно, что куда идти читать.

По PHP неплохая дока была благодоря тому, что по любой функции можно получить доступ сразу по урлу — например, хочешь посмотреть доку/примеры по функции strip_tags, пишешь php.net/strip_tags и попадаешь сразу на доку по этой функции. Не надо гуглить или пользоваться поиском по сайту. И помимо доки внизу комменты с рейтингом, там многое можно было почерпнуть. Хорошая дока.

И вот по React хорошая дока с точки зрения изучения библиотеки, стоит почитать.

4. Смотрю большой материал на freeCodeCamp. Не уверен, что посмотрю его весь, но смотрю по наличию времени в отрыве от книги и доки, где-то на нормальной скорости, где-то на 2x. Вообще ютуб на 1.5-2x это отличное изобретение.

5. Буду читать чужой код и общаться с коллегами.

Резюмирую — использую все возможные каналы получения информации. Кто-то говорит, что изучить новую технологию это просто вот тут что-то в одном месте почитать и сразу молодец. Я так не думаю. Надо посмотреть/почитать много где, сопоставить полученную информацию, уложить её в голове и на практике. Тогда всё устаканится хорошо и важное отфильтруется от менее важного.
#IT #frontend #books #javascript #interesting #rust

Решали сейчас с коллегой вопрос по интеграции кода в Тильду. Кто не в курсе — это такой SaaS конструктор сайтов, приятный в простом использовании, но в вопросах интеграции чего-то на фронтенде не всегда очевидный. Детали реализации фронта не документированы, сервис не расчитан, что кто-то будет на фронтенде его логику с JS дорабатывать.

Задача была навесить свою JS логику сразу после отправки данных на сервер и отображения некоторого div'а. Этого div'а в момент начальной отрисовки страницы в дереве нет. Когда и кто его добавляет в DOM? Надо изучать их код, чтобы ответить.

Но в качестве быстрого решения можно воспользоваться хаком с MutationObserver. Это способ отслеживать все изменения DOM элементов внутри указанного элемента, которым может быть и body. Когда происходят изменения внутри отслеживаемого элемента — вызывается твоя функция и ты проверяешь в ней, показан ли сейчас нужный тебе элемент. И не надо разбираться с деталями реализации кода сайта, в который ты интегрируешься. Удобно. Минус — на каждое изменение отслеживаемого элемента вызывается твой код. Не стоит отслеживать так изменения больших и часто меняющихся узлов DOM дерева.

Накидал демку

#frontend #javascript #IT

Пришлось поковырять Тильду еще сейчас. Выяснили, что в процессе построения страницы они создают DOM элементы, потом подчистую их удаляют и создают снова.

Тильда, да ты ж моя няшечка, да кто ж тебя научил так делать-то:)

Удаление/добавление элементов в DOM — дорогие операции и современный веб (ну как современный, уже лет ~10 как, наверное) идет в сторону оптимизаций и уменьшения количества таких операций.

Мда. Технологически хороший продукт и коммерчески успешный продукт — это часто совсем не одно и то же. Не то чтобы Тильда технически плохой продукт, но есть куда стремиться. Сидят же там разработчики, денежку получают за JQuery лапшу свою в 2022м-то.
#frontend #IT #javascript #codebetter

Навигация по постам в канале

🍒 #IT — всё, касающееся айтишечки нашей
🍒 #backend — о бэкенде
🍒 #frontend — о фронтенде
🍒 #linux — о Linux, администрировании и смежных темах
🍒 #python — о языке Python
🍒 #javascript — о языке JavaScript
🍒 #typescript — о языке TypeScript
🍒 #css — о CSS
🍒 #rust— о языке Rust
🍒 #db— о СУБД
🍒 #codebetter — о хороших подходах в программировании
🍒 #tools — об инструментах
🍒 #tests — об тестировании ПО

⚡#LMS — о нашей LMS системе для образовательных программ

🌶 #youtube — мои видео на YouTube
🌶 #course — о моём курсе

🍉 #softskills — о софт-скиллах и личной эффективности
🍉 #books — о книгах

🍷 #interview — где-то что-то кому-то комментирую
🍷 #news — что-то касается новинок/новостей
🍷 #interesting — что-то интересное, не обязательно ИТ
🍷 #gg — гыгы

🍓 #management — о менеджменте
🍓 #marketing — о маркетинге

🥝 #soulful — душевное

Ы!

Попиваю свой ночной тегуаньинь и читаю по TypeScript. Понавыдумывали майкрософтовцы, конечно. Но в целом получилось мощно. Костыли, ну или ладно-ладно, особенности JS лезут, разумеется, но от них уже не избавиться, просто надо их иметь в виду. Null, undefined, NaN и прочее.

Что по своему опыту рекомендую прочесть по TS тем, кто хочет начать писать на нём.

Сначала это. Затем это. Затем это. И только потом это.

Прочел ещё треть этой книги. Шутеечки понравились, а по теме не очень. Автор русскоязычный, Борис «бритва» Чёрный:), но писал явно на английском, редактор и переводчик постарались: непереводимое переведено, щедро рассыпаны опечатки, несколько раз перечитываешь, смысл не проясняется. А может и исходник такой. Или, возможно, надо читать, уже поработав с TS, тогда будет понятнее и опечатки бросаться в глаза не будут.

TS хорош. Типизация рулит. Читая, ловил себя на мысли, что вот такое объяснение можно перенести и в мой материал по типизированному Python. Надо обновить:)

#it #backend #frontend #typescript #javascript #books

Господа фронтендеры, используете БЭМ в связке с CSS Modules?

С одной стороны, одной из решаемых БЭМ проблем была изоляция имён CSS-классов во избежание коллизий; и CSS Modules решает эту проблему по умолчанию, т. к. классы каждого компонента изолированы. В таком контексте БЭМ не нужен, если используешь CSS Modules.

К тому же блок в терминологии БЭМ это как правило и есть компонент, а всё, что внутри компонента это как правило элементы с редкими модификаторами. В итоге это приводит к тому, что просто все CSS-классы компонента начинаются с имени этого компонента, что кажется избыточным. Мы и так находимся в отдельном CSS этого компонента, нет смысла каждый его класс начинать с имени компонента, это едва ли положительно сказывается на читаемости CSS.

С другой стороны, в каких-это сценариях БЭМ и в связке с CSS Modules улучшает читаемость и структурированность кода. Модификаторы, например, в этом помогают. Или использование блока как элемента, когда блок=компонент переиспользуется в другом блоке=компоненте и ему задаются отступы и положение на странице как элементу. Улучшает читаемость, думаю.

Отказаться от Б в БЭМ?

А styled components (css in js) мне чёт не нравится. Давайте сюда ещё PHP добавим с SQL, чего по файлам прыгать:)

#IT #frontend #javascript #typescript #css

Понимаю, что здесь в основном backend спецы и вижу, что посты про frontend не заходят, но всё же буду писать и про frontend, потому что занимаюсь им сейчас, да и собственно почему бы и нет:)

Наткнулся на такой прекрасный бенчмарк frontend JS фреймворков. А ещё вот на такой ресурс, собирающий статистику по состоянию JS каждый год.

И вижу (неожиданно для меня) любовь сообщества к библиотекам Svelte и Solid, а также их эффективность. 90% удовлетворённость разработчиков по 2021му году у обоих, для сравнения React 84%, Vue 80%.

Svelte и Solid представляют собой исчезающие фреймворки, то есть в рантайме в браузере нет или почти нет кода самого фреймворка, нет виртуального DOM и вся работа ведётся с DOM реальным. Сколько бы React ни выпендривался этим своим чудодейственно эффективным обновлением DOM дерева и движком Fiber, подходы без виртуального DOM показывают, кто тут батя.

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

Доверять бенчмаркам дело, конечно, такое — но всё равно интересно.

Кстати, Solid — практически копия React с его JSX и хуками. Потому вероятно и заходит разработчикам, ибо знакомый и привычный подход, но зато маленький бандл, высокая скорость обновления UI и меньше жрёт RAM (приветы виртуальному DOM).

#IT #frontend #javascript #typescript

Читаю сижу про Solidjs. Бодрая штука. Разрабатываем тут одну хитрую большую систему, о которой расскажу вам позже, по фронтенду готовы несколько первых экранов — и, думаю, днём перетащу их с реакта на Solid🙄

Если всё пройдёт ок, сделаю материал по нему. Кажется, это реакт здорового человека.

#frontend #IT #javascript #typescript

Уууууу что я нашёл!

https://github.com/gothinkster/realworld

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

Например, интересно вам, как выглядит бэкенд такого проекта на Rust'овском Actix с Diesel ORM? Пожалуйста. Или на Rust'овском Rocket? Лови. Или на чистом Go? Есть и такое. FastAPI? Получай. На C++ (стрелять-колотить, почему нет) — на-ка!

Аналогично и по фронтенду. На Solidjs вот, например.

#it #backend #frontend #python #rust #javascript

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

Там готовы 5 первых экранов, которые я сделал на React, но затем решил переписать их на Solidjs. Просто попробовать, посмотреть, как пойдёт. Фреймворк понравился на первом знакомстве и решил оценить на практике.

Переписал.

В Google Chrome Developer Tools встроен Lighthouse — инструмент тестирования производительности фронтенда. Обобщённый показатель Performance для React версии приложения — 79 из 100, для Solid версии 97 из 100.

Трафик для загрузки всего приложения (html, css, js, images) для React-версии 884 kB, для Solid-версии 255 kB.

Функционал обеих версий полностью идентичен. Причём для React версии ещё не подключен внешний state менеджер, который будет нужен и с которым трафик и performance точно лучше не станут, а для Solid внешний state менеджер не является необходимостью благодаря иной модели реактивности.

С точки зрения удобства процесса разработки Solid это тот же React с почти тем же JSX, но более простой в работе из-за иной заложенной модели реактивности. И, как видим, с гораздо более высокой производительностью в частности за счёт отсутствия виртуального DOM.

Я доволен. Буду продолжать на Solid.

Рассказывать вам о ходе проекта:)? На бэкенде у нас FastAPI с SQLAlchemy и Postgres, планируем активно использовать Яндекс облако для всех задач, насколько сейчас видим, его возможностей будет достаточно.

#IT #backend #frontend #course #javascript #typescript #python #LMS

Awesome solid.js — большой набор ссылок по фронтенд фреймворку Solid: видео, подкасты, статьи, примеры приложений, стартер паки, библиотеки компонентов, инструменты... Бам!

#IT #frontend #javascript #typescript

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

Этот алгоритм, конечно, может быть перенесён и на поиск любой другой библиотеки.

Шаг 1

Ищем доступные варианты, из которых выбираем. Google, вопросы знакомым, опросы. Всё найденное сводим в табличку. По редактору я создал такую табличку с пока что одной вкладкой «Первичный отсев».

Шаг 2

Вырабатываем критерии первичного грубого отсева библиотек. Составляем перечень верхнеуровневых требований к библиотеке, добавляем соответствующие столбцы в таблицу. В моём случае этот перечень:

1. Есть ли большие внешние зависимости у редактора? Если есть — для меня это минус. Верю всей душой, что при должной сноровке, терпении и упорстве можно написать редактор на плюс-минус Vanilla JS и потому редакторы, тянущие мегабайты лишнего хлама, идут топ-топ лесом.
2. Современный ли UI у библиотеки. Субъективно. Современный UI как по мне в Notion.
3. Позволяет ли лицензия редактора мне использовать её в своём проекте. Если не позволяет — значит опять же топ-топ.
4. Количество звёздочек на GitHub. Много — хорошо, мало — возможно тоже хорошо:)

Шаг 3

Заполняем значения критериев по каждому из вариантов.

Анализ

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

У меня было 11 вариантов. Из них три отсеялись сразу (Draft.js, Outline editor, Thinkific — что-то не так с лицухой, зависимостями и тп). Осталось 8. Часть редакторов имеют субъективно не лучший для меня UI, их тоже отметаем. Допилить их наверняка можно, но не вижу смысла тратить на это время. Уходит Trix, Summernote, ProseMirror. Осталось 5.

Оставшиеся сортируем по какому-то количественному критерию — например, по GitHub-звездочкам. На крайняк по первичному личному впечатлению, завязанному на интуицию. Получаем: Quill, Slate, Editor.js, Tiptap, ToastUI Editor. Дальше будем смотреть их уже подробнее на предмет более конкретных параметров — документация, нужные в проекте технические особенности (возможность легкой интеграции syntax highlight в нашем случае) и тп. Пробуем подключить в проект, тестим нужные фичи. Изучаем именно в порядке выстроенного приоритета. Первое понравившееся и всем устроившее — берём.

Вжух!

#IT #frontend #javascript #typescript

Если вам вдруг интересно, как у нас продвигается разработка фронтенда не на попсовом React/Vue, а на новёхоньком SolidJS, то сообщаю — продвигается чётенько. SolidJS бодр и самодостаточен.

Роутер используем тоже родной. Всё на TS, с типами. Store без внешних библиотек благодаря модели реактивности солида. Проблем нет. Пишу в вимасе.

Всем доволен.

#IT #frontend #javascript #typescript #LMS

Надо делать хорошо, а нехорошо делать не надо!

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

Подтвердить что-то смс-кодом — проблемка. Код актуален 60 сек, за которые смс тупо не удаётся поймать иногда. И осложняется сиё мероприятие тем, что помимо смс надо ведь ещё и чтобы интернет как-то ловился, чтобы было куда этот код ввести.

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

Professional highly complex ultra-modern frontend

Для загрузки кабинета Selectel надо грузануть 4.2 мегабайта, из которых 3.5 мегабайта JS. Angular — привеееет, дружочек-пирожочек!

Там же highly complex frontend у селектела, там стартануть без 3.5 метров скриптов никак низя. Иначе ж оно как на первом сайте в Интернет получится, недостаточно professional, слишком не modern, и вообще developer experience без этого пострадает и фронтендеры будут плак-плак и хнык-хнык, ибо их розовые IDEшные жопки на такое не подписывались!

Уууу, и што делать?!

Любой добавляемый npm пакет нужно проверить на размер в сборке через bundlephobia.com или аналоги. На каждый чих-пых добавлять плюс несколько десятков, а то и сотен килобайт чужих скриптов в сборку — может, мммм, не надо? А то в глазик тук-тук да по макушечке хрясь-хрясь:)?

А ещёёёё есть lazу loading, чтобы скрипты грузить по мере необходимости. А ещё есть SSR. А ещё есть сильно более легковесные фреймворки, чем Angular. А ещё есть островная архитектура. И ещё много-много-много всякого хорошего.

NullPointerException

Ну и, конечно, забавно наблюдать, как начинают сыпаться мобильные приложения на таком интернете. Кто молодец, добавляет плашку — пропал доступ к интернет, и мягко её убирает затем. Кто немолодец, начинает сыпать java’вовские исключения в духе NullPointerException. Альфа-банк привееееет, как дела:)?

Пургу гонишь!

Стой там на своём пеньке и не возмущайся, у нас с нормальным интернетом всё работает чётенько.

Ну так-то да.

Всем пофик. Фреймворк на фреймворке фреймворком погоняет, смазанный сотнями жирных в пень ненужных npm зависимостей. Профессиональные девелОперы профессионально девелОпят.

Хорошооо!
#IT #frontend #codebetter #javascript #tools

Пока рендерится новый материал, поставил на фоне видос об истории JavaScript. Ооочень увлекательно, канал — красавцы!

https://www.youtube.com/watch?v=sgyoKkAfGpU

#javascript #IT #interesting