Html5

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

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

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

1. Ленивая загрузка изображения

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

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

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

Этого легко добиться с помощью обычного HTML.

Всё, что вам нужно сделать, это добавить свойство loading=lazy у тега img.

После добавления свойства ваш элемент должен выглядеть примерно так:

<img src="image.png" loading="lazy" alt="" width="200" height="200">

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

2. Автокомплит

Получение подсказок прямо в строке, когда вы пытаетесь что-то найти, действительно крутая фишка.

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

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

Однако HTML также позволяет отображать набор предопределённых вариантов, используя тег <datalist>.

Помните, что атрибут ID этого тега должен совпадать с атрибутом list тега input.

<label for="country">Choose your country from the list:</label><input list="countries" name="country" id="country"><datalist id="countries">  <option value="UK">  <option value="Germany">  <option value="USA">  <option value="Japan">  <option value="India"></datalist>

3. Picture

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

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

При изменении ширины viewporta вы можете заметить, что некоторые изображения не масштабируются вверх и вниз, как ожидалось.

К счастью, HTML даёт разработчикам возможность довольно легко исправить это, используя тег <picture>, позволяющий добавлять несколько изображений, соответствующих разной ширине.

Ваш код будет выглядеть примерно так:

<picture>  <source media="(min-width:768px)" srcset="med_flag.jpg">  <source media="(min-width:495px)" srcset="small_flower.jpg">  <img src="high_flag.jpg" alt="Flags" style="width:auto;"></picture>

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

Этот тег очень похож на теги <audio> и <video>.

4. Базовый URL

Это один из моих любимых тегов при создании карты сайта.

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

Например, если я хочу указать URL-адрес на Twitter Илона Маска и Билла Гейтса, начало URL-адреса (домена) будет таким же, а то, что следует за ним, будет их соответствующими идентификаторами.

Обычно мне приходится дважды вставлять ссылку с одним и тем же доменным именем.

Однако в HTML есть тег <base>, который позволяет вам установить базовый URL-адрес, как показано ниже:

<head><base href="http://personeltest.ru/aways/www.twitter.com/" target="_blank"></head><body><img src="elonmusk" alt="Elon Musk"><a href="BillGates">Bill Gate</a></body>

Приведённый выше код сгенерирует изображение с ссылкой на https://www.twitter.com/elonmusk и ссылочный тег, перенаправляющий на https://www.twitter.com/billgates".

Тег <base> должен иметь либо href, либо target-атрибуты.

5. Обновление документа

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

Вы могли заметить эту фичу, когда открывали определённые сайты и видели что-то вроде Вы будете перенаправлены через 5 секунд.

Это поведение встроено в HTML, и вы можете использовать его с помощью тега <meta> и установки http-Equiv=refresh в него:

<meta http-Equiv="refresh" content="4; URL='https://google.com'/>

Здесь свойство content указывает время в секундах, после которого должно произойти перенаправление.

Стоит отметить, что, хотя Google утверждает, что относится к этой форме редиректа так же, как и к другим редиректам, использовать этот тип редиректов неразумно, если только это действительно не нужно.

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

Заключение

HTML и CSS довольно мощные инструменты, и вы можете создавать фантастические веб-сайты, используя их.

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

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

Если вы планируете использовать JavaScript, обязательно ознакомьтесь с моим недавним постом, где обсуждаются некоторые советы, которые могут сэкономить ваше время.

5 современных советов и приёмов JavaScript для экономии времени. Снизьте рабочую нагрузку и напишите чистый код с помощью этих советов по JavaScript.

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

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Другие профессии и курсы

Привет. Меня зовут Александр Птичкин. Вот уже 8 лет я обучаю созданию мультфильмов и анимации; 3 года из них я посвятил разработке своего игрового 2.5D HTML5 движка под названием PointJS. За 8 лет вращения в этой индустрии я наработал много материала, которым хочу поделиться тут с вами в блоге. Это мой первый пост на Хабр. Судите строго :) Ваши предложения по улучшению дальнейших статьей пишите в комментариях. Поехали!

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

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

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

Перерисовывать часть CANVAS мы можем только при выполнении двух условий:

1. Игровой фон должен быть разбит на части и не являться целым изображением. Судите сами: если фон - целое изображение, то его все равно придется где-то перерисовать. И раз оно цельное, то перерисовать придется полностью, а значит, ни о какой перерисовке отдельной части CANVAS речи быть не может. Дальше в статье вы поймете, что я имею в виду и почему так

2. Камера в игре должна стоять. Потому что если камера движется, то и вся сцена движется, а значит, всю ее и надо перерисовать

Уже два этих условия выше отсекают уйму игр и механик. А мы еще даже не начали разбираться.

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

Я беру готовую сцену из Maya (персонажей, фоны и анимацию я создаю в программе Autodesk Maya, а потом рендерю в формате 2D). Это облегчает дальнейшую работу со сценой и смену ракурса. Но об этом в другом посте.

Затем отключаю все элементы сцены, кроме земли, и вывожу ее изображение. Рендерю с разрешением 3000 на 3000px.

Но на изображении также есть пустые png-области, которые не нужны. Можно было, конечно, поправить в Maya, но мне лень. Я удаляю их с помощью скрипта на php. Таким образом на выходе у меня ровное изображение размером 2786 на 1998. Да, кстати, я написал уйму полезных скриптов для ускорения работы и для того, чтобы не использовать Photoshop, а делать все быстрее и проще. Получился такой собственный Photoshop, но на php :)

Вообще идея разбить фоновое изображение и другие большие объекты на части уже давно используется в играх (и не только). Например, разработчики Diablo 2 делали то же самое. Ведь у них все было растровое (спрайты), и была создана лишь иллюзия 3D. А идея в следующем. Фоновое изображение может быть 10000px на 10000px, экраны же пользователей чаще всего 1920 на 1080px (мобильные и того меньше). Т.е. за пределами экрана, где мы ничего не видим, все равно будет происходить перерисовка фона. На рисунке СИНЕЕ - это рамка камеры в игре (рамка камеры равна размеру экрана монитора пользователя). Все, что за рамкой, мы видеть не должны.

Нам надо от этого избавляться, ведь лишняя перерисовка - лишняя нагрузка. Даже программа анимации Anime Studio Pro (Moho) начинает висеть, если части тела персонажа состоят из картинок 1920 на 1080 (в программе мы их, конечно, уменьшим, но оригиналы-то никуда не денутся и вес файла тоже). Для человеческой руки достаточно иметь изображение 300 на 300px. Что уж говорить о браузерной игре...

Давайте большое изображение разобьем в Photoshop на равные квадраты или прямоугольники (равные, чтобы потом при сборке не устраивать себе танцы с бубном). Например, разобьем на 8 строк и 8 столбиков. Так мы получили 8*8 = 64 прямоугольника размером 348 на 250px. Как разбить изображение в Photoshop, у меня рассказано в этом уроке.

Теперь у нас есть много картинок gif, из которых можно воссоздать, как пазл, изображение фона. Теперь давайте соберем этот пазл на javascript в нашей игре.

Для этого переименуем все файлы в папке, присвоив им числовые названия, начиная с 1 или 0 (как вам удобно.) Я бы делал с 1, так как потом надо будет делать цикл, начиная с 0, и сам 0 выпадет, потому что к переменной при первой итерации добавится 1. Руками переименовывать бессмысленно и долго, а у нас все-таки 21 век на дворе. На MAC Book я это делаю за один клик в программе Name Manager. Например, есть папка с фотографиями под именем img. Я просто перетаскиваю эту папку на экран программы, указываю номер первой фотографии и жму Rename.

Если будете делать руками, не перепутайте порядок! Когда Photoshop рендерил нам разбитый фон, он делал это тоже в определенном порядке, последовательно проходя циклом строки, а потом столбцы. И если вы будете ставить нумерацию кое-как, то потом нужные куски пазла могут оказаться где угодно. Кстати это неплохой способ зашифровать игру (или усложнить ее чтение), создав свой порядок сборки фоток из папки. Языку Javascript без разницы, в каком порядке пробегать столбики и строки, так что лишней нагрузки вы не добавите. Вернемся к примеру: у нас есть последовательность от 0 до 64 следовательно, 64 кусочка.

Далее пишем на javascript простой код, который соберет все это в единое изображение.

Для этого стоит создать массив под названием fon = [], в который впоследствии поместить все изображения в нужном порядке, и создать переменную xy, которая в будущем станет номером фотографии (xy будет принимать участие в формировании ссылки на путь к файлу).

var xy = 0, fon = [];

Затем создаем два цикла, один из которых будет идти по X и добавлять фотографии по горизонтали, а другой - по Y, переходить на новую строку и тем самым добавлять фотографии по вертикали.

for (var x=0; x<8; x++) {for (var y=0; y<8; y++) {  }}

Цикл по x<8 говорит о том, что изображение было разбито на 8 строк. А цикл по y - что было 8 столбиков. Умножив 8 на 8, мы должны точно получить количество картинок в папке img. А их напомню 64.

При каждой итерации этих циклов мы будем прибавлять единичку к xy и добавлять в массив fon выбранное определенным образом изображение.

xy++;fon.push(изображение1);

В игровом движке PointJS есть метод, который добавляет в игру изображение game.newImageObject({ });. Отмечу, что подробнее о том, как устроен движок, о его командах и уроки по нему вы можете посмотреть в соответствующем плей листе. Итак, теперь мы будем каждый раз добавлять в массив fon новый game.newImageObject.

Давайте посмотрим на код целиком:

var xy = 0, fon = []; for (var x=0; x<8; x++) {for (var y=0; y<8; y++) {  xy++;    fon.push(      game.newImageObject({         file : "img/" + xy + ".gif", // путь к файлу         x : 0 + 348*y, // y это шаг. сначала изобаржени будет по x на 400, потом на 400*2 потом н 400*3         y : 0 + 250*x, // тоже смое и по оси y         w : 348,          h : 250      })    )  }};

Давайте посмотрим на строку file : "img/" + xy + ".gif". Благодаря конкатенации строк и тому, что xy у нас переменная, которая всегда увеличивается на 1, мы формируем в ней динамический путь к изображениям:

file : "img/" + xy + ".gif", // путь к файлу // оригинал// то что вышлоfile : "img/" + 1 + ".gif"// img/1.gif file : "img/" + 2 + ".gif"// img/2.giffile : "img/" + 3 + ".gif"// img/3.giffile : "img/" + 4 + ".gif"// img/4.gif//и так далее...

Получили следующее. Это уже мы смотрим в окне браузера

Теперь я предлагаю вам для наглядности чуть подпортить фон и сделать в формуле выше w=346, а h=248. Это нужно, чтобы между клетками появился зазор 2px, и мы смогли увидеть, из чего все же этот фон состоит.

var xy = 0, fon = []; for (var x=0; x<8; x++) {for (var y=0; y<8; y++) {  xy++;    fon.push(      game.newImageObject({         file : "img/" + xy + ".gif", // путь к файлу         x : 0 + 348*y, // y это шаг. сначала изобаржени будет по x на 400, потом на 400*2 потом н 400*3         y : 0 + 250*x, // тоже смое и по оси y         w : 346,          h : 248      })    )  }};

Это, разумеется, еще не все. Пока мы никак не оптимизировали игру - мы лишь расчленили и заново собрали одно изображение. И даже наоборот: еще больше нагрузили компьютер циклами. А теперь сделаем интересную операцию - будем рисовать только те квадраты, которые видим на экране (т.е. которые попадают в рамку камеры в движке). Для тех, кто не знает, за отрисовку всего, что есть в движке, отвечает команда draw();. Напишем условие:

for (var i in fon) {if (fon[i].isInCamera()) fon[i].draw();}

Смотрим, что получилось. Все блоки, что не попали в камеру (на рисунке они прозрачные), больше не рисуются. Вот это и есть первая оптимизация фонового изображения. Дальнейшие изображения я не смогу показать из окна браузера, так как рамка камеры - это и есть размер экрана, а я физически не могу показать то, что находится за экраном. Но я могу нарисовать это, например, в After Effects. Еще одна полезнейшая программа для жизни аниматора и монтажа.

Однако, если вы помните, мы говорили о другом - как очищать CANVAS? Целиком или кусочком?. Сейчас мы провернули хорошую подготовительную работу, чтобы четко ответить на этот вопрос. Потому что предварительный ответ мы получили в начале статьи: если камера движется, то картинка сменяется полностью и тогда придется рисовать все без исключения.

Приступим. Я предлагаю разместить на нашем верно отрисованном фоне несколько объектов: персонажей, дома и деревья. Теперь представим ситуацию: мы пьем чай и не играем, следовательно, наш персонаж не двигается. Однако вокруг него бегает другой персонаж (наверняка с дурными намерениями). Вот я нарисовал траекторию, по которой он пробежал (сделал за ним шлейф):

Посмотрим, какие блоки он задел и что надо перерисовать на сцене. Эти участки я выделил красным.

По рисунку видно, какую область надо перерисовать (она красная). Все остальное можно не трогать, так как оно не изменилось. Как бы теперь я построил алгоритм, который смог бы определить затронутые блоки и участки, нуждающиеся в перерисовке?

Обсудим на уровне идеи. Допустим, мы создадим квадрат/прямоугольник по размеру бегущего персонажа. Хотя нет, даже не так. Зачем создавать, когда можно просто вызывать StaticBox() этого объекта? Да, в движке есть команда getStaticBox(); - область загруженного изображения, равная размерам этого изображения. Теперь напишем простое условие, в котором будем проверять, каких объектов сцены коснулся этот StaticBox();. Вы помните, что у нас уже был массив fon = [];? А помните, мы загружали деревья и дома? Их нельзя разместить в массиве fon. Значит, для них создадим отдельный массив obj, и будем проверять сразу оба массива. Итак, пишем код:

var collisionFon = []; // создали массив в котором будем хранить всех с кем столкнулись из фонаvar collisionObj = []; // создали массив в котором будем хранить всех с кем столкнулись из obj for (var i in fon) {if (player2.isStaticIntersect(fon[i].getStaticBox())) {collisionFon.push(fon[i])  }}for (var i in obj) {if (player2.isStaticIntersect(obj[i].getStaticBox())) {collisionObj.push(obj[i])  }}

Уже на этой стадии обработка циклов может отнять у компьютера много ресурсов. Однако мы двигаемся дальше. Я специально на картинке выше провел персонажа так, чтобы он не коснулся дома, но коснулся клетки фона. Зачем? Все просто: если перерисовать в этом месте фон, а потом персонажа, не тронув дома, то фон окажется выше этого дома

И вот главный вывод статьи:

Значит нам нужно проверять еще и родительские связи!

Перерисовав фон и персонажа, нам следует узнать, а не перекроет ли этот фон еще что-нибудь. Т.е. необходимо пробежаться циклом по всем элементам, что попали в массивы collisionFon и collisionObj, и посмотреть, каких еще объектов они касаются на сцене, а точнее - какие объекты находятся над ними. В моем движке есть функция проверки оси Z. По сути там реализована эмуляция оси Z через сравнение осей Y, но сейчас это не столь важно. Самое главное, что это большой блок, который тоже будет поглощать ресурсы. Ведь теперь все блоки, которые предполагается перерисовать, нужно собрать в общий массив, чтобы сравнить их оси Y, чтобы выяснить, кто из них выше, а кто ниже. Короче, я даже формулы писать не буду. Думаю, вы поняли: расчеты будут громоздкими и нагрузят компьютер больше, чем если бы мы просто стерли весь CANVAS и нарисовали его заново. Я даже сомневаюсь, что смогу их провести, а в том, что это безотказно отработает в MMORPG-играх, вообще не уверен. С учетом всех наложений и косвенных (не на прямую) попаданий на здания, к красной зоне я добавил и зеленю область которую тоже нужно перерисовать.

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

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

Автор текста и всех материалов статьи: Александр Птичкин, основатель образовательного проекта Mult-uroki. Написано специально для habr.com. Копирование или иное использование материала без письменного разрешения автора запрещено.

Мы привыкли создавать некоторые элементы пользовательского интерфейса с помощью JavaScript, например аккордеоны, всплывающие подсказки (тултипы), усечение текста и т. д. Но, поскольку HTML и CSS постоянно получают новые функции, а старые браузеры больше не нужно поддерживать, мы можем использовать намного меньше JavaScript-кода для создания элементов пользовательского интерфейса и больше фокусироваться на логической части (проверки, обработка данных и т. д.).

---

Некоторые решения по-прежнему кажутся хакерскими и негибкими, но они полезны в небольших проектах и если это элементы для разового использования. Зачем писать JavaScript-функцию (или использовать jQuery, если вы ещё помните) для одного-единственного аккордеона на вашем веб-сайте? Это была моя мысль, когда я добавлял аккордеон в нижний колонтитул для мобильных устройств на моём личном веб-сайте.

Аккордеон без использования JavaScript!

Вот несколько примеров создания элементов без JavaScript.

Адаптивное усечение текста

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

Компонент рейтинга

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

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

Эта реализация очень гибкая и может быть легко кастомизирована.

Всплывающая подсказка (тултип) / раскрывающееся меню (dropdown меню)

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

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

Модальные окна

Это немного хакерская реализация, которая полностью полагается на URL-адрес. Идентификатор в URL-адресе должен соответствовать модальному элементу, который нам нужно открыть.

Плавающий лейбл

Я рассмотрел реализацию инпутов с плавающим лейблом в отдельной статье, поскольку эта реализация немного сложнее.

Тоггл / Аккордеон

Недавно в HTML появился нативный элемент аккордеон (тоггл) с элементами <details> и <summary>, но недостатком использования этих элементов является то, что у них не так много вариантов стилизации, поэтому разработчики по-прежнему продолжают использовать свои собственные реализации. К счастью, с помощью логики чекбокса или радиокнопки мы можем создавать тогллы и аккордеоны, не полагаясь на JavaScript.

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

Заключение

Как видите, эти реализации полагаются на логику селектора CSS, например :focus и :placeholder-shown, чтобы заменить логику JavaScript. Некоторые из этих решений можно считать хакерскими, но они быстрые, гибкие и не полагаются на JavaScript.

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

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

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Другие профессии и курсы

Кроссплатформенный фреймворк дает самый привлекательный опыт для веб-разработки.

Изображение автора статьи.

Современные Web-сайты пишутся на HTML, JavaScript и CSS (и этот сайт в том числе). Наверно, вы сейчас прочитали это и подумали да это же очевидно. А если я вам скажу, что можно написать сайт без использования этих трех технологий, у вас наверняка возникнут вопросы

На протяжении истории на этом поле побывали разные игроки. Был Flash, был Silverlight - конкурирующие технологии, которые пытались отобрать кусок рынка у браузеров и не дать разработчику использовать другие технологии для создания сайта. Правда ни одна из них по-настоящему так и не взлетела. А что, если я вам скажу, что в этой сфере снова может появиться конкурент? И это несмотря на то, что буквально никто из других игроков так и не смог сдвинуться с места, невзирая на годы усилий.

Но давайте сначала отвлечемся чтобы понять, что общего было у всех этих попыток:

1. Для запуска нужен был плагин браузера. Обычно нужен был плагин браузера для запуска на соответствующей платформе. Хороший пример Silverlight. В то время те, кто использовал Linux, не могли смотреть Netflix, так как сайту нужен был плагин Silverlight (который не был доступен для Linux). Конечно, были альтернативные, open source варианты, но среди них не было ничего стоящего.

2. Они представляли угрозу для системы безопасности. Flash был печально известен этим (более 1000 известных уязвимостей). Браузер обязательно должен был загрузить плагин для отображения содержимого, и в этот самый момент ни одна из гарантий безопасности браузера уже не имела значения, так как плагин имел полный доступ к хосту.

3. Производительность была не так хороша, как у чистового HTML. Зачем грузить плагин, чтобы отобразить в нем некоторый текст, если можно использовать чистый HTML и CSS, которые гораздо быстрее?

4. Появился HTML5, и CSS стал лучше. Внезапно создание чего-то прекрасного и захватывающего перестало быть невозможным. И, что еще лучше, браузеры, которые ненавидели стандарты, использовали странные хаки или специфичные для конкретного браузера реализации, вместо их CSS-эквивалентов (как например, Internet Explorer) были попросту уничтожены.

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

Но как мы пришли к этому? Как HTML стал основой веб-разработки в сегодняшнем процветающем веб-пространстве?

Изображение Joshua Sortino с Unsplash (http://personeltest.ru/aways/unsplash.com/@sortino)

Рассвет новой эры

6 августа 1991 годаИнтернет стал доступен всему миру. Затем, пришел и ушел так называемый пузырь доткомов,Представьте себе, что Интернет для общего пользования появился только в 1991 году, а девять лет спустя лопнул пузырь доткомов, стоивший1,7 триллиона долларов (это примерно 15% ВВП США на тот момент)!

Это было время, когда веб начинал становиться все более и более организованным, и способ, которым мы писали веб-сайты, становился все более стандартизированным.Со временем мы выработали стандарты, такие как HTML4, и эти стандарты гарантировали, что HTML, который вы пишете в одной части мира, будет работать для большинства, если не для всех, интерпретаторов HTML.Каскадные таблицы стилей (CSS) вошли в обращение в 1996 году, а годом ранее появился JavaScript.Можете ли вы представить себе, что видите или используете веб-сайт без JavaScript или CSS? Боюсь это произвело бы на вас не лучшее впечатление.

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

Документ

Когда Интернет только появился на свет, люди не использовали приложения, как это делают сегодня. Кто-то из вас, возможно, помнит программы-терминалы, которые, обеспечивали вам физическое соединение с сервером на другом конце. Эти приложения (если их можно так назвать) были лишь немного больше, чем просто строчками текста на экране (прим. переводчика: автор тут видимо имеет ввиду BBS доски и их аналоги). А так как люди привыкли иметь дело с документами, с реальными кусками бумаги в руках, которые они могут листать - неудивительно, что основой HTML-страниц является работа с HTML-документом. Если вы когда-либо использовали JavaScript, вы конечно знакомы с такими функциями, как document.getElementById(). Все, что вы делаете на веб-странице, заключается в создании, а затем преобразовании документа.

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

Если же вы хотите, чтобы определенные части вашей веб-страницы оставались в нужном положении или выравнивались определенным образом, вы используете вещи типа position в CSS, чтобы контролировать расположение элементов. Существует множество свойств CSS (520, если точнее), и, как следует из названия, эти стили каскадируются в свои дочерние элементы. Когда вы попытаетесь заставить определенную часть вашего документа выглядеть так как вам нужно, высока вероятность того, что они станут довольно хаотичными. Если вы используете готовый CSS фреймворк, например, Angular Material, и начинаете переопределять встроенный CSS для достижения нужного вам внешнего вида, это тоже становится довольно пикантным занятием. CSS позволяет вам выполнить переопределение при помощи !override, однако, как только вы начнете это делать, вы уже практически проиграли битву. Если вы читаете это и думаете про себя: Что? Да этот парень совершенно безнадежен в CSS: ОК, я не буду с вами спорить. Но как только ваши дизайнеры начиняют гнаться за определенным внешним видом, ваш CSS может стать довольно сложным в понимании.

Изображение Pankaj Patel on Unsplash (http://personeltest.ru/aways/unsplash.com/@pankajpatel)

Изучение языков

Чтобы создать простой веб-сайт, вам необходимы три разных языка, и это только для самого сайта. Это HTML, JavaScript и CSS. А так как ваш сайт должен быть удобным и отлично выглядеть, этого не произойдет, если вы не знаете, как писать эффективный JavaScript или если ваши навыки в CSS оставляют желать лучшего.

Если вы действительно хотите, чтобы ваш сайт мог делать что угодно, вы можете использовать фреймворк типа Angular или React. Когда вы начнете добавлять пакеты через npm, размер вашего приложения начнет расти. Поэтому вы будете использовать сборщик, такой как webpack, чтобы связать все ваши пакеты вместе и соответствующим образом их минимизировать. Webpack сам по себе отдельная тема (при том огромная), но ее тоже стоит рассматривать, т.к. она играет свою не маловажную роль в создании веб-приложений.

Бандлинг и транспиляция

У вас есть веб-сайт и ваши пакеты, теперь вам нужно использовать bundler для объединения вашего приложения, а затем еще убедиться, что оно работает в нужных браузерах. В зависимости от того, какой браузер использует пользователь, вам потребуется прокладка для определенных функций, чтобы браузер пользователя мог отображать ваш сайт. Если вы используете такой язык, как TypeScript, webpack также преобразует его в JavaScript. В этом нет ничего плохого, но это все еще больше усложняет. Если ваш сайт ломается, возможно это вы накосячили в коде, минификация сломала его, webpack не собрал все должным образом или процесс транспиляции привел к проблеме? Все эти сложные конвейеры могут создать трудности при отладке или поиске основной причины проблем в вашем приложении.

Чем лучше Flutter?

Если вы слышали о Flutter, то, скорее всего, слышали о нем в контексте разработки мобильных приложений. Так какое отношение он имеет к веб-сайтам? С обычной HTML-страницей вы работаете как с документом. Во Flutter страница (или то, с чем взаимодействует пользователь) фактически рисуется на канве (canvas) HTML. Flutter фактически контролирует каждый пиксель, который рисуется на экране, и не использует HTML, JavaScript или CSS для определения его внешнего вида или логики. (Технически говоря, родной код Dart переносится на JavaScript через dart2js, но на самом деле никакая бизнес-логика не пишется на JavaScript.)

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

Изображение Keila Htzel с Unsplash (http://personeltest.ru/aways/unsplash.com/@keilahoetzel)

Рисование на канве вместо работы с документом

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

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

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

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

Использование одного языка

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

Flutter использует Dart в качестве языка. Весь внешний вид приложения и бизнес-логика написаны на нем. Dart поставляется со статической проверкой типов данных, и скоро появится null safety (прим. переводчика: уже появился), поэтому каждая строка кода в вашем приложении, будь то визуальное описание вашего приложения, придание ему стиля или управление бизнес-логикой вашего приложения, полностью типобезопасна.

Простая компоновка вашего приложения

Обычно мы используем наши веб-сайты для отображения данных из какого-то источника: база данных, API или что-то еще, от куда мы получаем данные, которые хотели бы отобразить. Представьте, что у нас есть массив объектов, которые возвращаются из нашего API, и вы используете, например, Angular для их отображения. Вы загружаете эти объекты во вспомогательный компонент, затем используете *ngFor для их итерации и вы скорее всего положите его в div. Но из коробки, для нестилизованного div, это будет выглядеть совсем просто. Вероятно, вы хотите, чтобы ваши элементы в этом списке отображались в столбце или строке, поэтому вам еще придется задействовать некоторые CSS или flexbox для этого.

С Flutter наоборот, вы размещаете дочерние элементы с помощью Column или Row, которые имеют свойство children, которое принимает массив объектов. При использовании этого свойства, вы можете записать ваши массивы в строку (элементы друг за другом) или в столбец (элементы друг под другом). С Flutter, вы можете быстрее получить визуальный макет, который вы хотите, прежде чем перейти к стилизации отдельных элементов в списке. По моему опыту это приводит к более быстрому скаффолдингу и прототипированию сайта без ущерба для конечного результата.

Контроль над каждым пикселем в области просмотра

Поскольку Flutter визуализирует каждый пиксель на экране, это дает дизайнерам и разработчикам большой контроль над тем, что именно они хотят видеть в приложении. Но рендеринг каждого пикселя на экране звучит как нечто, что будет сопровождаться большим ударом по производительности, и да, в наши дни это, конечно, не так быстро, как рендеринг чистого HTML, но такие вещи, как канва с аппаратным (за счет GPU) ускорением, значительно повышают производительность в этой области. Традиционно проектируя веб-страницу в HTML, нужно учитывать различные браузеры, на которые вы ориентируетесь. Однако в случае с Flutter, если вы размещаете виджет Text с определенным шрифтом, он будет выглядеть одинаково, независимо от того, где он отображается, потому что Flutter контролирует, как этот конкретный виджет будет выглядеть на основе каждого пикселя.

Прощай, webpack!

Flutter использует Dart, поэтому приложение компилируется для своей целевой платформы, оно также переносит все зависимые пакеты (также написанные на Dart) в JavaScript. Dart типобезопасный язык, который не поддерживает рефлексию, поэтому компилятор лучше понимает, что ваше приложение вызывает, а что нет. Это способствует лучшему tree-shaking (избавление от неиспользованного кода) и минификации вашего приложения. Flutter не нужен webpack для сборки приложения, что само по себе является довольно сильным аргументом в пользу Flutter (по крайней мере, на мой взгляд). В webpack нет ничего плохого; это высококачественный софт. Но это сложный инструмент и без того в сложном конвейере.

. . .

Но пока это все лишь теория

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

Рисование всего на канве также имеет свои последствия для производительности, но они не так плохи, как вы предполагаете. Я сделал тестовое приложение, которое интенсивно использует визуальные эффекты, и оно работает на моем MacBook со скоростью около 60 кадров в секунду. Даже когда вы тащите лист по экрану, оно все равно работает нормально, постепенно увеличивая размытие на изображении позади. Я ни в коем случае не специалист в Dart, так что, без сомнения, этот процесс можно было бы оптимизировать еще больше.

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

Представьте, если бы вы могли сделать веб-сайт, который работает быстро, и вы бы могли использовать один язык для разработки, стилей и написания бизнес-логики для вашего веб-приложения? Если бы webpack стал не нужен для вашего конвейера разработки? А если бы со временем у вас был серверный рендеринг и все те SEO-блага, которые есть сегодня у традиционных HTML-сайтов?

Если бы Flutter уже обладал всем этим, он мог бы стать непобедимым в вебе.

От переводчика:

Совсем недавно (03.03.2021) Flutter web перешёл в stable ветку! В своем первом релизе Google в первую очередь сосредоточился на вопросах производительности и улучшении точности рендеринга. Более подробно о нововведениях и изменениях можно почитать тут

P.S. Догадываюсь, что эта статья может вызвать много споров и критики, особенно у web разработчиков. Действительно есть много подходов и готовых библиотек для решения описанных выше сложностей. Но я не могу не разделить с автором всех плюсов, которые потенциально дает Flutter, да и впечатляющая скорость, с которой он развивается и завоевывает рынок мобильной разработки тоже вселяет определенную уверенность в успехе его Web составляющей.