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

Иначе картина может быть такой (сайт после переноса на React JS):

Привет! Меня зовут Айнур, и я frontend-разработчик SimbirSoft. Более 6 лет я работаю над коммерческими проектами, создаю и улучшаю интерфейсы, поэтому в работе достаточно часто использую паттерны проектирования. Неоднократно я обращался за идеями и лайфхаками к книге Patterns.dev, которая содержит очень современный взгляд на шаблоны проектирования, рендеринга и производительности JavaScript.

Авторы Patterns.dev:

Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.

Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

Материал книги будет полезен не только React-разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend-разработкой.

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

Источник: https://www.patterns.dev/
Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

И снова всем привет! Судя по реакциям и количеству закладок к переводу первой части книги Patterns.dev, этот материал оказался для вас полезен. Поэтому я решил поделиться переводом второй части.

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

Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей второй части учебника можно найти здесь.

P. S.: На данный момент выложено в виде pdf, в дальнейшем планируется полноценная публикация на github для удобства изучения.

P. P. S.: Вторая часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0

Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

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

Одна из самых старых и самых популярных площадок с деревьями комментариев — это Reddit. Правда, большая часть его пользователей едина в одном: его интерфейс ужасен. Но его API открыто, поэтому на выбор есть множество клиентских приложений, особенно для мобильных телефонов — Joey, Relay, Slide и Boost и другие. Их авторы — как правило, и сами недовольные стандартным интерфейсом Реддита — потратили много времени и сил на поиск удобного интерфейса для комментариев. И большая их часть пришла к очень похожим вариантам дизайна.

В этой статье я хочу разобрать, чем мне так нравится такой дизайн деревьев комментариев, сравнить его с деревьями комментариев Хабра, и попробовать пофантазировать, как бы могли выглядеть комменты Хабра в интерфейсе клиентов для Reddit.

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

Раньше я сам был таким человеком.

И не мудрено - никто не рождается с навыком идеально точного планирования.

Сейчас я довольно точно, в некоторых случаях даже до минуты, могу оценить сколько времени займёт у меня выполнение той или иной задачи, что при прежних попытках планирования казалось чем то невозможным. Как мне это удалось? Делюсь в статье.

Большие языковые модели, такие как GPT-4, с угрожающей скоростью становятся все более эффективными. Через пару лет нам больше не понадобятся разработчики!
...Или, по крайней мере, такая позиция становится вирусной в Твиттере. Я гораздо более оптимистично смотрю на то, что эти достижения ИИ означают для будущего разработки программного обеспечения.

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

В статье на примере простого сайта, постараюсь описать три способа рендеринга приложений, раскрыть их плюсы и минусы, и на практических примерах провести сравнение производительности и размеров приложения. Материал больше подойдёт начинающим фронтенд-разработчикам, или тем, кто хочет познакомиться c CSR, SSG и SSR. Для лучшего понимания от вас потребуются начальные знания React, менеджеров пакетов npm или yarn.

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

Теперь же веб-страница может быть полноценным приложением, которое получает данные из различных источников, выполняет манипуляции «на лету» и предоставляет полную интерактивность. Это значительно повысило полезность интернета, но ценой размера, пропускной способности и скорости. За последние 10 лет средний размер веб-страниц для десктопа увеличился с 468 КБ до 2284 КБ, что составляет рост на 388,3%. У мобильных устройств скачок еще более впечатляющий — от 145 КБ до 2010 КБ, то есть больше на 1288,1%.

Всем привет! На связи Spectr.

В феврале мы провели митап #DevTalks, посвященный фронтенду, и сейчас хотим подробно о нем рассказать: поделимся докладами спикеров, материалами выступлений, отзывами участников и немного расскажем о внутренней кухне организации таких ивентов. 

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

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

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

Технология css-in-js существует уже довольно давно. Ещё в начале своего профессионального опыта я встречал подходы, в которых стайлинг локальных частей интерфейса пробрасывался в html через javascript в виде css директив. Иногда это необходимая мера, хотя необходимой она случается изредка, но раз в год, как говорится, и палка стреляет. У меня на опыте был пример построения раздела интерфейса, в котором устанавливаемое на сайт пользователя модальное окно можно рестайлить через кодовый редактор с live preview. css-in-js бывает оправдан, поэтому хочу сразу оговориться - хоронить никакой подход не стоит. Но и идеализировать его как универсальную пилюлю тоже не надо. Рендер стилей, привязанный к логике рендера компонентов в контексте всего проекта - это просто свой путь со своими приключениями, появившийся на мой взгляд в общей психопатии привязывать к state всё что только можно. Что если посмотреть - откуда взялась эта техногогия? На сегодняшний день на рынке проектирования интерфейсов сложился монополист react, диктующий программистам свои правила игры, и который даже без использования styled модуля имеет в себе простейщую инверсию управления cssInJs.
React - важный персонаж в этой теме. Он, словно useEffect всего современного front-end - стал центром силы, средоточием зла в виде голого state management, не предусматривающего из коробки ничего иного.

Всем привет! Меня зовут Аня Ланда, я фронтенд-разработчик в Самокате. В компании я больше двух лет, общий стаж во фронтенде – 6 лет и всё это время я делаю таблицы. В этом посте расскажу про эволюцию подходов к работе с ними, что меняется на пути от нескольких сотен до сотен тысяч элементов в таблице.

Распространенная проблема, которую я вижу в объектно-ориентированном проектировании:

* Волшебник — это разновидность игрока.
* Воин — это разновидность игрока.
* У игрока есть оружие.
* Посох — это разновидность оружия.
* Меч — это разновидность оружия.

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

PHP - едва ли первое, что придет в голову, когда стоит задача поднять сервер веб-сокетов. Практически каждая статья в интернете будет пестрить предложениями использовать для этого NodeJS, Python или Go. Но поскольку PHP - это однозначно первое, что приходит в голову, когда речь идет о веб-приложениях, почему бы не попробовать?

На самом деле, запуск сервера веб-сокетов на PHP довольно прост. Существует превосходная библиотека Ratchet, позволяющая работать на любом фреймворке (или вовсе без него) полноценно и легко.

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

Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.

При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные стандарты. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.

Попытка сделать весь API максимально RESTful страшно раздувает код и грузит сеть. Потому что остальные две трети запросов - в форме команд на бэкенд проделать какие-то действия, слабо отображающиеся на CRUD над некими ресурсами. И вариантов послать такие запросы достаточно много. Даже, чересчур.

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

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

Vuetify - один из самых популярных Material Design фреймворков для Vue, которому недавно исполнилось 6 лет. И 6 января 2023 года его основатель заявил, что проект Vuetify перестал окупаться и он ищет работу. Отсюда - некролог в названии статьи.

Статья состоит из шести небольших частей, в которых мы пробежимся от первой версии до третьей, посередине разобрав, как фреймворк обновлялся до Vue 3, будем вместе смотреть за поведением основателя движка, а также тем, как можно справиться с переходом на Vue 3, пожалуй, хуже, чем кто-либо еще, включая команду Nuxt.

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