Вопросы авторам курса «Фронтенд»

Авторы самых интересных технических вопросов получат скидку 5 000 рублей.

На страницу курса
Андрей Ситник
Андрей Ситник
Ведущий фронтенд‑разработчик Злых марсиан. Автор PostCSS, Logux и Автопрефиксера. Работал над Groupon, Рокетбанком и Амплифером. Постоянный спикер российских и западных фронтенд‑конференций.
Алексей Плуталов
Алексей Плуталов
Фронтенд‑разработчик Злых марсиан. Работал над eBay, Oh My Stats, Амплифером и Рокетбанком. Один из инициаторов и активистов питерского сообщества фронтэнд‑разработчиков.
Анна Селезнёва
Анна Селезнёва
Фронтенд‑разработчик Злых марсиан. Работала над eBay Social, Elementaree, Groupon. Спикер русскоязычных конференций, организатор митапов для фронтенд‑разработчиков MinskCSS и MinskJS.
Глеб Поспелов
Глеб Поспелов
Фронтенд‑разработчик Злых марсиан. Работал над Groupon, Fountain и Gett.
Алексей Иванов
Алексей Иванов
Фронтенд‑разработчик Злых марсиан на eBay Social и eBay for Sellers. Спикер русскоязычных коференций, один из организаторов и член программного коммитета конференции FrontTalks и секции фронтенда на DUMP.
Павел Гринченко
Павел Гринченко
Фронтенд‑разработчик Злых марсиан. Работает над Fountain.
Иногда слышу мнение: долой фреймворки, они тяжелые и неповоротливые, используйте чистый JavaScript, он многое умеет. Как вы думаете, к чему все в итоге придет?
Андрей Ситник
Андрей Ситник

Я считаю, что в основе фреймворка лежит не кодовая база, а идея. Например, Ruby on Rails появился, когда появилась идея Getting Real — на каком бы языке его потом не писали, у нас всё равно бы получился Rails. Если подходить к фреймворкам с точки зрения идей внутри них, то выбирать становится значительно легче.

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

Мнение о том, что фреймворки тяжелые и неповоротливые появилось в основном из‑за проблем сложности, которые рождает идея «2 way data binding». Но это не единственный подход к реализации фреймворка. Есть много очень маленьких фреймворков — Evil Blocks или Twitter Flight, которые реализуют только идею разрезания интерфейса на независимые блоки. Или, например, в Flux вопрос связывания модели и рендера решён по другому, и, по‑моему, гораздо лучше.

Периодически встречаюсь с тем, что одну и ту же задачу предлагают решать прямо противоположным образом: с одной стороны, всё-всё рендерить и держать бизнес‑логику на сервере, отдавая фронту минимальные декоративные функции, либо, наоборот, с сервера только получать данные, а всю остальную работу делать на фронте. (Как правило, на деле всё решается компромиссом и сочетанием обоих.) В каких случаях какому из подходов стоит отдать преимущество? И можно ли с ними добиться одинаковой скорости работы страницы?
Алексей Плуталов
Алексей Плуталов

Начнём с того, что современные веб‑сайты условно можно разделить на три типа: контентные сайты, веб‑приложения и гибрид (как правило, контентный сайт, содержащий в себе элементы полноценного веб‑приложения).

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

Примером контентного сайта можно назвать, например, интернет‑магазин, блоговую платформу, или wiki. Чтобы понять, какие подходы использовать — надо отталкиваться в первую очередь от целей и ожиданий пользователя. Пользователь приходит в поисковик с целью найти важную для него информацию, вбивает запрос, и кликает на нужную ссылку. Что он ожидает увидеть? Он ожидает увидеть интересующий его контент. И чем быстрее, тем лучше. При этом, его не волнует — будет там SPA, будет там красивый JS, или лапша из кода. Это для пользователя не первостепенно. Вторая ожидаемая вещь — хороший дизайн, так как он должен помогать проще усваивать тот контент, который мы хотим показать. В таких случаях — всё задачи лучше решать используя сервер, и максимально отказываясь от JS. Немного JS для того, чтобы слегка оживить интерфейс, легкий фреймворк (как пример Evil Blocks, или что‑нибудь похожее) — чтобы ваш код со временем не превратился в лапшу, и его просто было поддерживать.

Использование SPA для контентных проектов, типа интернет‑магазина может быть привлекательным, так как открывает пути улучшения пользовательского опыта, и разных дизайнерских решений. Но при этом, надо быть готовым, что придется решать проблемы индексации контента, и это уже будет выходить за пределы компетенции фронтенд‑разработчика, и ложиться на плечи системных администраторов (в случае, своей инфраструктуры на базе PhantomJS, например), или на плечи руководства (если мы хотим использовать внешний сервис и платить ему деньги).

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

Теперь о веб‑приложениях: они ориентированы на создание и обработку информации, идеально было бы, если бы они работали оффлайн, были бы SPA (чтобы улучшить UX опыт пользователей и в целом ускорить интерфейс), и как правило у таких приложений «тонкий сервер». Например, если посмотреть на Google Docs, не в разрезе всего набора Google Apps, то очевидно, что роль сервера сводится к банальным хранить и выдавать информацию — а львиная доля функционала приходится на клиент.

В условиях переноса бизнес логики на клиент, во многих случаях довольно сложно обойтись легковесным фреймворком. Нет сомнения, что написать приложение можно и без готового каркаса, а в некоторых случаях только так и получится. Но чаще, задача построения SPA приложения состоит на 20% непосредственно из бизнес логики. Все остальное приходится на рутинные, переходящие из проекта в проект, задачи. И в таких случаях, готовый фреймворк помогает сосредоточиться именно на бизнес логике приложения, беря на себя всю рутину.

Что касается гибридных типов приложений. Часто возникает ситуация, когда проект вроде контентный, но где‑то могут встречаться места, в которых требуется сложная логика именно на клиенте. Например, может быть какой‑то интернет‑магазин. Но чтобы продажи были лучше, руководство захотело, чтобы была возможность красиво компоновать страницы товаров. Скорее всего, для решения такой задачи потребуется WYSIWIG-редактор. В таких ситуациях, лучше всего придерживаться разработки веб‑сайта, а для тяжелых на фронт страниц — привлекать тяжелые инструменты (хотя, сейчас уже есть замечательный React, который может помочь обойтись без тяжелых Angular или Ember для одной страницы). Страницы, которые созданы для создания контента, как правило не индексируются, и они не доставят проблем в этом плане. При этом, логика остального сайта будет простой и максимально оптимизированной на предоставление контента. А если у вас появилась задача, сделать весьма хитрый виджет на контентной странице — его можно заключить в <noindex>, чтобы в поисковую выдачу случайно не попало нечто, вроде {{ search.results }}.

Подводя итог вышесказанному: ввиду существования разных типов сайтов, всегда будут требоваться разные подходы и поэтому серебряную пулю найти не получится. Единственное на данный момент идеальное решение — держать руку на пульсе и думать головой, правильно анализируя стоящую задачу, и выбирая правильные решения. Несмотря на то, что сейчас активно создаются проекты, которые призваны решить те или иные задачи — пока до конца не ясно, действительно ли они будут более универсальны, или со временем займут только свою нишу. Среди таких проектов нельзя не отметить шаблонизаторы, которые можно использовать и на клиентской и на серверной стороне (как например, React), и фулстек‑фреймворки (такие как MeteorJS).

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

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

Если же говорить о веб‑приложении, то здесь конечно, стоит думать под другим углом. Пользователь будет работать с приложением какое‑то количество времени, приложение будет обрабатывать большое количество данных. И в этих условиях, конечно надо подумать, как избежать больших утечек данных, как сделать так, чтобы при большом количестве данных, приложение не начало тормозить (держим в голове, что разрабатывая на Macbook Pro, у пользователя может быть ноутбук пятилетней давности, в котором и одна вкладка браузера может тормозить, а сидеть он будет в IE8). В таких ситуациях, лучше оптимизовать уже код, и думать над UX, чтобы можно было обойти узкие места, которые не получается решить технически.

Таким образом, отвечая на первоначально поставленный вопрос — используя VanillaJS, jQuery лапшу или <вставить название фреймворка>, при должной прямоте рук разработчика, дизайнера и UX-специалиста — можно создать действительно быстрый сайт, от работы с которым, пользователи будут в восторге.

В настоящий момент появилось множество языков, компилируемых в JS, начиная получившим широкое распространение СoffeScript и заканчивая достаточно экзотическими Elm и Amber Smalltalk. В каких случаях вы считаете оправданным использование таких языков?
Андрей Ситник
Андрей Ситник

Я считаю, что за такими языками будущее. Браузеры ещё могут добавлять новые CSS-свойства или JS API, но синтаксис давно находятся в стагнации, так как он часто обратно несовместим. Новый синтаксис очень долго внедрять — например, без препроцессоров мы сможем пользоваться ES6, только когда с рынка уйдут все старые браузеры. Разработчики браузеров просто боятся экспериментировать — так как неудачные эксперименты им придётся поддерживать годами.

В итоге только препроцессоры типа Sass или CoffeeScript позволяют нам экспериментировать и развивать Веб. А JS и CSS ждёт роль такого «ассемблера», который стабилен и гарантирует выполнение в разных браузерах. Временами самые лучшие идеи будут переходить из препроцессоров в JS и CSS — например, в ES6 очень много идей из CoffeeScript.

Правда сейчас не все инструменты пока хорошо поддерживают карты кода. Так что я пока предпочитаю те препроцессоры, которые только расширяют функционал JS — например, CoffeeScript, IcedCoffeeScript или Traceur (чтобы использовать ES6 уже сегодня).

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

Задайте свой вопрос

Мы бережно сохранили ваш вопрос, скоро мы на него ответим.