Разработка веб-сайтов

Есть много способов повышения веб-производительности. Один из них — предзагрузка контента, который понадобится позже. Префетчинг CSS, предварительный рендеринг полной страницы или резолвинг доменного имени. Делаем всё заранее, а потом мгновенно отображаем результат! Звучит круто.

Ещё круче, что это очень просто реализовано. Пять тегов <link rel> дают браузеру команду на предварительные действия:

<link rel="prefetch" href="/style.css" as="style" />
<link rel="preload" href="/style.css" as="style" />

<link rel="preconnect" href="https://example.com" />
<link rel="dns-prefetch" href="https://example.com" />

<link rel="prerender" href="https://example.com/about.html" />

Чем функциональные компоненты React отличаются от компонентов, основанных на классах? Уже довольно давно традиционный ответ на этот вопрос звучит так: «Применение классов позволяет пользоваться большим количеством возможностей компонентов, например — состоянием». Теперь, с появлением хуков, этот ответ больше не отражает истинное положение дел.

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



Я, в любом случае, не рекомендую переписывать существующие компоненты с применением новых технологий если на то нет веских причин, и если вы не против оказаться в числе тех, кто раньше всех начал этими технологиями пользоваться. Хуки — это всё ещё новая технология (такая же, какой была библиотека React в 2014 году), и в руководства по React ещё не попали некоторые «передовые методики» их применения.

Возможно многие из пользователей GNU/Linux в свете последних инициатив властей по созданию «суверенного» Интернета озадачились целью подстраховаться на случай недоступности репозиториев популярных дистрибутивов GNU/Linux.

Кто выкачивает репозитории CentOS, Ubuntu, Debian, кто-то собирает свои дистрибутивы на основе имеющихся дистрибутивов, а кто-то вооружившись книгами LFS (Linux From Scratch) и BLFS (Beyond Linux From Scratch) уже взялся за компиляцию своих дистрибутивов из исходников так как считает что в условиях «суверенного» Интернета обязательно будут происходить хакерские атаки, вирусные эпидемии, утечки данных, а бинарники просто устареют через некоторое время.

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

Дальше будет использоваться термин «глубинные ссылки», как наиболее близкий к англоязычному «deep links». Речь в данной статье пойдет про REST API, поэтому под глубинными ссылками будут подразумеваться ссылки на HTTP-ресурсы. Например, глубинная ссылка habr.com/ru/post/426691 указывает на конкретную статью на сайте habr.com.

HATEOAS – компонент REST-архитектуры, позволяющий предоставлять клиентам API информацию через гипермедиа. Клиенту известен единственный фиксированный адрес, точка входа API; все возможные действия он узнает из ресурсов, полученных от сервера. Представления ресурсов содержат ссылки на действия или другие ресурсы; клиент взаимодействует с API, динамически выбирая действие из доступных ссылок. Подробнее о HATEOAS можно прочитать на Википедии или в этой замечательной статье на Хабре.

HATEOAS – следующий уровень REST API. Благодаря использованию гипермедиа, он отвечает на многие вопросы, возникающие при разработке API: как управлять доступом к действиям на стороне сервера, как избавиться от жесткой связности между клиентом и сервером, как изменять адреса ресурсов в случае необходимости. Но он не дает ответа на вопрос о том, как должны выглядеть глубинные ссылки на ресурсы.

Свежая подборка со ссылками на новости и материалы. В выпуске: свежие RFC предложения и другие новости из PHP Internals, порция полезных инструментов, и много других материалов и новостей!

Приятного чтения!

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

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



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами

Технология GraphQL за последние несколько лет, после того, как компания Facebook перевела её в разряд опенсорсных, стала весьма популярной. Автор материала, перевод которого мы сегодня публикуем, говорит, что попробовал работать с GraphQL в среде Node.js и на собственном опыте убедился в том, что эта технология, благодаря её замечательным возможностям и простоте, неслучайно привлекает к себе столько внимания. Недавно он, занимаясь новым проектом, перешёл с Node.js на Golang. Тогда он и решил испытать совместную работу Golang и GraphQL.

19 апреля в Екатеринбурге пройдет конференция разработчиков DUMP. Традиционно мы публикуем обзоры секций от программных директоров.

Первый наш пост о секции Frontend. Программный директор секции Анастасия Катаева рассказала, что интересного будет в секции и зачем на нее идти.

Многие используют apache2 в качестве веб-сервера. Однако мало кто задумывается об оптимизации его производительности, что прямо пропорционально сказывается на скорости загрузки страниц сайта, скорости обработки скриптов (в частности php), а также на росте нагрузки на ЦП и увеличении объёма используемой ОЗУ.

Таким образом, следующий мануал, должен помочь начинающим (и не только) пользователям.
Все нижеприведённые примеры использовались на Raspberry PI 3, Debian 9, Apache 2.4.38, PHP 7.3.