Не знаю, как вы, но я застал время, когда фронтенда еще не было. Большинство макетов программисты могли сверстать самостоятельно, ну что там сложного:
<table>, <table> и <table>Потом появилась блочная верстка, верстальщики выделились в отдельную профессию, но остались на второстепенных ролях. На команду из нескольких серверных программистов приходился один верстальщик, самый бесправный член коллектива — он иногда даже сам внедрить-то свой код не мог, обычно в шаблон HTML-верстку превращали программисты.
Прошло еще несколько лет, и ситуация изменилась в корне! Не каждый PHP-программист поймет, как устроен и работает Angular или React. Страницы стали интерактивными, в ходу концепции толстого клиента и Single Side Application, Игорь Сысоев выпускает nginScript – компилятор JavaScript для nginx, а профессия верстальщика конвертировалась в профессию фронтенд-разработчика. Кстати, как работодатель скажу, что фронтендеров гораздо тяжелее найти, чем бекендеров.
Посмотрите на современный фронтенд — это настоящая большая программа на JavaScript, со своей архитектурой, модульным разбиением, объектно-ориентированным программированием, кешированием и так далее. Зачастую это не менее, а более сложный код, чем серверный. На клиенте все больше бизнес-логики, а сервер превращается в простое хранилище данных.
Но браузер, который интерпретирует JavaScript на клиенте, это не сервер. У него меньше возможностей, скорости, памяти, у него, как правило, есть батарейка. Возникает целый пласт задач, связанных с производительностью фронтенда: как написать не тормозящий JS, как не сожрать всю память в ноутбуке клиента, как не посадить батарейку за час работы с вашим сайтом, как, в конце концов, обеспечить быструю загрузку страницы (или сделать вид, что она загружается быстро).
Решению именно этих задач посвящена новая секция ПРОИЗВОДИТЕЛЬНОСТЬ ФРОНТЕНДА. Что в ней будет, расскажет её куратор — представитель компании Opera в России, руководитель сообщества веб-стандартистов, Председатель Программного комитета конференции для фронтенд-разработчиков FrontendConf Вадим Макеев.
— Вадим, начиналось всё с таблиц, затем блочная вёрстка – что будет дальше?
Таблицы, флоаты и другие попытки приспособить для сложной вёрстки не предназначенные для этого возможности — это была довольно интересная эпоха — мы каждый день экспериментировали и придумывали новые трюки. Сегодня вёрстка повзрослела и обросла десятком новых спецификаций, которые позволяют делать те же раскладки страниц гораздо проще. Что самое интересное: спустя год после появления нового черновика в недрах Рабочей группы CSS, вечнозелёные браузеры уже начинают его поддерживать, и всё самое прогрессивное и новое уже сразу можно использовать.
С другой стороны, людей, которые хорошо разбираются во флексбоксе или начинают пробовать гриды — не так и много. И нет-нет, да включишь флоат, знакомый с детства, вместо того, чтобы разбираться в нюансах флексбокса, поэтому инерция сохраняется. Уж не говоря про ошибки реализации, которые записывает во [Flexbugs] Филип Уолтон.
Флексбокс, каким бы он ни был крутым, это всё та же коробочка, внутри которой просто появились новые удивительные возможности (боже, вертикальное выравнивание!), то грид — это штука в духе «забудьте всё, что вы знали». Она уже есть за флагами в большинстве последних браузеров, кроме Safari и не терпится уже прыгнуть с головой в эту новую эпоху вёрстки.
Дальше будет только круче, например, LG уже [работает над черновиком] адаптации блочной модели под круглые экраны.
— Какие новые технологии появились для увеличения производительности?
Я сейчас скажу крамольную вещь, но самый правильный способ улучшать производительность в вебе — это браузерам быстрее рендерить и выполнять. То есть, по сути, докупить серверов и обновить ПО — если говорить языком, понятным на конференции HighLoad. Всё потому, что веб — это самая гибкая и совместимая платформа из всех существующих. И поэтому веб состоит из кучи старого кода, который написан плохо, но от этого содержимое этого сайта не становится менее ценным.
Поэтому эта конференция совершенно бесполезная, расходимся по домам, да? Нет, конечно. Поскольку мы теряем пользователей, которые не дожидаются загрузки или пугаются тормозов, бизнес теряет покупателей и деньги — нужно бороться за быстродействие. Об этом и будем говорить. Но не стоит забывать про остальной веб и как он устроен.
Помимо инструментария, который позволяет правильно измерять эту производительность — не только браузерных отладчиков, но и API для доступа к такой информации — у нас появляется всё больше низкоуровневых API для доступа в те части браузера, куда нас раньше не пускали. Тот же requestAnimationFrame позволяет правильно планировать действия вместе с браузером, чтобы быть с ним на одной волне, сервис-воркеры позволяют прописываться в браузере и управлять кэшем и сетевыми запросами даже при закрытой странице.
Это вообще новая интересная тенденция — браузер для нас становится всё меньше просто чёрной коробкой, в которой происходит что-то неведомое. Мы всё больше получаем к ней доступ и начинаем управлять его поведением всё тоньше. Погуглите «CSS Houdini».
— Ты работаешь в Opera, Opera мониторит тренды? Как реагирует на них?
У нас появилась команда R&D (Research and Development), которая как раз и занимается сбором новинок и планами нашего развития в быстро меняющейся отрасли и экспериментирует с ними. До сих пор у нас получалось изобретать новое в браузерной отрасли, что теперь видно в интерфейсах всех браузеров. Шутка «Opera сделала это первой» до сих пор нет-нет, да всплывает. И мы продолжаем: недавно мы запустили [экспериментальную сборку Opera для Android] с поддержкой биконов — небольших маломощных устройств на местности, которые транслируют URL и позволяют взаимодействовать с физическим миром прямо из браузера. Такой вот интернет вещей: подходите к автобусной остановке — и видите уведомление в браузере с расписанием движения. И это не фантазии — это уже работает в Осло, [в статье] есть фотографии и подробности работы.
О докладах новой секции
Understanding Page Load
Маленький сайт грузится быстро, большой долго — так? Не так. Правильно сделанный сайт и грузится, и работает быстро. Чтобы сделать его правильно, нужно понимать, что на самом деле происходит с сетью и браузером на каждом их этапов, разобраться в «холодной» и «горячей» загрузке и научиться пользоваться инструментами. Опытом создания, профилирования и ускорения фронтенда для YouTube делится Зилин Жао из Google.
От Request до DOMContentLoaded на примере главной страницы Mail.ru
Можно сделать быстрый сервер, можно оптимизировать работу с сетью, а можно ускорить отрисовку в браузере — и каждый из вариантов добавит вам немного скорости. А если оптимизировать и объединить всю цепочку: от запроса на сервер до последнего события в браузере? C++, V8 и JS на сервере, отложенная загрузка и тонкая организация блоков на клиенте и Keep-Alive между ними — Павел Минеев расскажет о быстрой главной Mail.Ru.
From nothing to a video under 2 seconds
В тонкую психологическую разницу между «ещё грузится» и «всё зависло» важно попасть, чтобы пользователь не ушёл. Хороший способ — поставить бюджет времени и не выходить за его рамки. Как YouTube, одному из тройки самых больших сайтов в мире, удаётся показывать видео за 2 секунды и даже быстрее, какие бывают типы загрузки и что делать с каждым и как вообще устроена страница просмотра видео — Михаил Сычёв из команды YouTube Desktop.
Производительность WebGL-приложений
Даже быстрый WebGL на видеокарте можно нагрузить так, что станет медленно. Яндекс.Карты придумали хороший способ нагрузить WebGL с помощью интерактивных панорам. Какие проблемы вылезли и как от них получилось разгрузить движок панорам — в докладе Кирилла Дмитренко.
Скорость на клиенте
Записка «страничка сформирована за X секунд» с сервера не говорит вообще ни о чём — когда пользователь увидит это в браузере, вот что важно. Почему вообще бывает медленно, как с этим бороться и чем здесь поможет Navigation Timing API и HTTPS расскажет Анатолий Орлов, уже не из Яндекса.
Это ещё не всё!
Как видите, получилась очень представительная секция: Google, YouTube, Mail.ru, Яндекс. И это — только половина от всех докладов, представленных в новой секции «Производительность фронтенда».
Прошлые года
А вот здесь нам показать-то особенно нечего – секции-то такой не было ещё год назад. Но были доклады на других наших конференциях, в частности, на конференции «Российские интернет-технологии». Несколько докладов оттуда ниже. А с этой страницы можно скачать несколько книжек, в том числе с расшифровкой лучших докладов по клиентскому программированию с наших конференций.
И последнее: Для пользователей «Хабрахабра» конференция предлагает специальную скидку в 15%, всё что нужно сделать — это воспользоваться кодом "IAmHabr" при бронировании билетов.
И совсем последнее: Конференция уже на следующей неделе и мы станем писать реже — будем отсыпаться и отдыхать. Но потом мы вернёмся, новые публикации вы сможете найти в блоге на Хабре и в наших бесплатных рассылках. Будем рады оставаться на связи!
Комментарии (18)
TheRabbitFlash
25.10.2015 19:59+7Большинство макетов программисты могли сверстать самостоятельно, ну что там сложного: table, table и table
Это так и надо было оставить. Ибо сейчас настолько жирной стала клиентская часть, что ради одного JS метода фронтендеры берут по 25 фреймворков без малейшего представление как оно работает и для чего. В итоге сайты грузятся так же долго, как 20 лет назад. Чего стоит сайт твиттера с его JS кодом в более, чем 25 тыс строк. Уверен, что если 80% кода сломать — на работоспособности сайта это никак не скажется.stardust_kid
25.10.2015 20:55-2Жаль, что вас тогда не послушали. Немедленно звоните Тиму Бернерсу-Ли.
TheRabbitFlash
25.10.2015 21:08+3Юмор это хорошо, но я на полном серьезе. Мы на работу долго ищем фронтендера, который в JS шарит. Вроде как все кандидаты нормальные.
Но стоит на шаг в бок отойти от общеизвестных фреймворков и попросить написать что-то свое — все чешут затылок со словами «а зачем? Можно же 15 фреймворков подключить». А потом мы слушаем от наших клиентов, что у них сайты невероятно долго загружаются на мобиле. В итоге получаем использование фреймворка Г по той причине, что в нем есть методы из фреймворка А. Но Г без Б не работает, как и Б без В.
xamd
25.10.2015 21:51+3Под все задачи свои инструменты. Ведь чтобы развести костёр вы используете зажигалку, а не камни, верно? Но не поймите меня неправильно: подключать весь underscore ради _.debounce или jQuery из-за селекторов, разумеется глупо. Радует, что авторы библиотек, выходящих в наше время, думаю о гранулярности своих решений и не создают огромных монолитных монстров.
stardust_kid
25.10.2015 22:48+1Это битва брони и снаряда. В начале ты подключаешь либу для скорости, потом рефакторишь для производительности. Надо только правильно управлять зависимостями.
stardust_kid
25.10.2015 22:46+3Заложите в бюджет зп адекватную рынку и ищите человека с хорошим знанием js. Где-то такие водятся, я точно знаю.
Нынешнее состояние js таково, что для современных браузеров можно писать любую крутоту на ванильном языке.
stardust_kid
25.10.2015 22:55Пишите в скайп, если интересно, расскажу о современном состоянии html/css/js стека для разработки.
stychos
26.10.2015 01:49+2Возмите меня, я люблю ванильные велосипеды и ни капли не понимаю в js-фреймворках.
tamtakoe
31.10.2015 15:01Наконец-то адекватный человек на Хабре. А то смотришь вакансии, а там требуется человек со знанием нескольких фреймворков. Приходишь на собеседование — тебе в запой рассказывают о своих костылях: эта часть у нас на Angular, тут перешли на React и используем еще 100500 мелких библиотек. Да что там другие компании, от своих не могу добиться, чтобы выпилили lodash с фронтенда. Тащят 50 КБ ради трех методов. Ну хоть jQuery выпилили, уже прогресс.
velvetcat
Похоже на попытку возвыситься над бэкендом (употреблением слов, давно с ним ассоциирующимся) :) По существу же здесь ошибка — бизнес-логика не может не дублироваться на сервере из соображений безопасности.
P.S. Ну и поверьте, бэкенд-технологии тоже не стоят на месте, хотя лично я за мир-дружбу-жвачку, если что. Работы всем хватит.
xenohunter
Золотые слова! Все профессии важны.
xamd
Ну бросьте, мы скромные ребята, ни над кем возвышаться нам не надо. Понятное дело, без бэка нам никуда :) Но все же Вы не совсем точно заметили ошибку (имхо): бизнес логика будет дублироваться только для валидации данных. Логика процессинга этих данных никогда не перекочует на фронт и навсегда останется на бэке из соображений безопасности. Однако, во всех SPA на фронт выносится работа с роутингом, данными (агрегация и финальный процессинг), рендеринг (я имею ввиду механизм составления шаблона (и иногда кое-что ещё), так-то рендеринг всегда происходит в браузере), ну и всякие анимашки и прочее.
На мой взгляд, в данный момент бэк уходит больше в оптимизацию работы с данными (процессинг, хранение, выборка, анализ), оставляя на фронт построение GUI приложения.
И да, разумеется мы всегда будем не разлей вода, работы и правда всем хватит.
justmara
Удивительно!
nuit
>бизнес логика будет дублироваться только для валидации данных
В сложных UI приложениях уже давно повсюду optimistic updates.