Многие здесь уже знакомы со Smashing Magazine — сайтом для веб-дизайнеров и веб-разработчиков. А ещё они издают книги и проводят конференции Smashing Conference.  С посещаемостью около 5 миллионов в месяц (раз в 10 раз меньше, чем у Хабра, но тем не менее), он является одним из ведущих интернет-изданий по веб-дизайну. Интересная особенность — если зайти на главную страницу сайта, он определяет включенный AdBlock, но не запрещает просматривать страницы — вместо этого скромно намекает, что неплохо бы купить какую-нибудь книгу. Все, кто пропагандировал идею, что популярному сайту не выжить без кучи рекламы, сейчас напряглись :-)  Мы взяли интервью у одного из основателей сайта (и спикера на HolyJS) — Виталия Фридмана. Мы поговорим о предыстории создания сайта, его технологическом стеке и процессе разработки, о чудесах с возможностью невозбранно использовать AdBlock, а также планах на будущее. — Виталий, приветствую! Вы — главный редактор и основатель довольно известного журнала Smashing Magazine. Можете вкратце рассказать, как Вы дошли до такой жизни? Как оказались в вебе, почему решили начать свой проект и было ли что-то своё до Smashing Magazine? Виталий: История довольно простая, в ней нет ничего особенного. Я просто всё время много работал. Я родился в Минске, а когда мне было 16 лет, родители переехали в Германию. Ещё в Минске я начал писать маленькие статьи, экспериментировать, крутить, смотреть, что можно сделать с Flash, HTML и так далее. А когда мы переехали в Германию, всё было очень просто: мне нужны были деньги. Я учился на Computer Science and Mathematics, и у нас в университете был один проект, где требовался вебмастер. И, так как деньги были нужны, я решил, почему бы и не поучаствовать. В итоге я начал крутиться, вертеться, ещё глубже занялся веб-дизайном. А потом, как закончил университет, несмотря на то, что всегда хотел был бэкенд-разработчиком, понял, что это не совсем моё, потому что PHP-код, который я писал, был, скажем, совсем нехорошим. И я решил быстро переориентироваться и пойти в область, которая меня больше всего интересовала. Пошёл в CSS, во фронтенд, шесть-семь лет был фрилансером. Потом мы создали журнал, потому что мне нужен был какой-то ресурс для нахождения техники, инструментов, которые я бы мог использовать в работе. Очень быстро мы обнаружили, что я не один такой, было много людей, которые крутились в этой области, тоже пытались найти что-то и не могли. Тогда я тратил безумное количество времени, чтобы писать статьи. Самый главный принцип заключался в том, что мы решили публиковать минимум две статьи в неделю на протяжении одного года. Это было такое обязательство. В то время я ещё учился в университете, так что это было тяжело. Статьи часто писал в кафе, ночью, в перерывах между экзаменами. Но всё это было серьёзно, и так появился Smashing Magazine. — Как в первый раз выбирался технологический стек платформы Smashing Magazine? Виталий: Изначально он вообще не выбирался. Я работал с коллегой, у которого уже был журнал на немецком языке, он использовал WordPress на протяжении нескольких лет, поэтому мы просто взяли эту платформу не задумываясь. Мы выбрали случайную тему, там не было никакого лого, мы просто начали публиковать статьи. То есть не сидели и не думали, выбрать ли WordPress или что-то ещё, просто так исторически сложилось. — Новый Smashing Magazine — он ещё на стадии обкатки. Виталий: Он уже почти готов, мы должны запуститься в ближайшее время. У нас будет slow rollout, это значит, что мы будем постепенно открывать доступ к всё большему количеству разных рубрик на сайте. Сейчас у нас есть стабильная, хорошая, работающая версия, есть несколько багов, которые надо исправить или прикрыть, их не так много, поэтому уже скоро хотим всё запустить. Посмотрим, что будет потом. — У вас довольно крупный портал, это не переезд на какой-то новый движок или какое-то банальное обновление. Вы делаете полностью новый дизайн, новую архитектуру, новый UX, новый workflow. Что стало причиной для столь глобальных перемен? Кто инициировал — менеджеры, технари или маркетологи? Виталий: Это очень хороший вопрос. Обычно я большой противник «big bang redesign» в дизайне, всегда этому противился и хотел скорее развивать проекты маленькими шагами. В данном случае нам пришлось так поступить, потому что на то были финансовые причины. Не потому, что мы — банкроты и так далее. Но если сравнить количество людей, которые используют AdBlock, как это было в 2012, когда мы предыдущий редизайн выложили, и как всё со временем развивалось… От рекламы мы получаем 1/16 дохода по сравнению с тем, что мы зарабатывали в 2012-2013 году. Опять-таки, это нормально, потому что около 60-65% наших читателей используют AdBlock. Я сам не верю в рекламу и использую AdBlock. Для этого есть причины, но, думаю, не стоит вдаваться в подробности, это и так все знают. Но для нас это значило, что так как большинство людей не видят рекламу, нам нужно было придумать, как можно по-другому спонсировать сайт. У нас есть несколько принципов, один из них — все люди, которые работают над сайтом, должны получать зарплату: каждый редактор, автор — все должны получать что-то за свою работу.  И мы начали над этим думать. Это не было глобальной проблемой. В нашем случае, довольно рано, ещё в 2013, мы начали думать, какие альтернативные способы заработка у нас есть или могут быть. Например, создали конференцию, воркшопы, тренинги, сonsultancy, книги, электронные книги, доску вакансий и так далее, это всё в процессе было. Но это было не совсем то, чего бы нам хотелось. Мы хотели построить какой-то стабильный фундамент. Одной из идей была подписка. Подписка, по которой люди получают какие-то плюшки за 2, 5, может, 7 долларов в месяц. Я не верю в донат, в то, что пожертвования могут давать стабильную прибыль в долгосрочной перспективе, и не хочу на это полагаться. Мне важно представить продукт, в котором люди видят для себя какую-то выгоду, поэтому не вводить эти членские взносы, говорить, какие мы хорошие, как мы хорошо работали всё это время, а потом требовать от вас деньги — такую возможность я даже не рассматривал. Поэтому мы решили создать новый продукт, который был бы, по сути, подпиской, в который были бы включены разные полезные вещи, например, вебинары, скидки на продукты, MailChimp, на вещи, которые люди и так используют. Кроме того, Smashing TV — это видеотрансляции конференций или интервью, сессий «Ask me anything», довольно большой набор. Smashing Magazine Print — это печатные издания, Smashing Books. Как мини-книга, которая будет выходить три-четыре раза в год. В этом проекте есть много разных вещей, которые его делают, я надеюсь, интересным, прекрасным продуктом. Что поменяется? В старом дизайне у нас толком не было возможности показать этот продукт, старая версия сайта выглядит как блог. Единственное, что мы могли сделать — это поставить какой-то рекламный блок, и будет у нас membership. Но в нашем случае это также включает в себя панель Options and Features. Это связано со всем, что мы делаем. То есть если у тебя есть membership, ты получаешь скидки на конференции, воркшопы, вебинары, объявления о работе, электронные книги. Интегрировать membership в каждую из этих систем было очень-очень сложно. К тому моменту у нас объявления о работе разместились на Ruby, довольно старой специально построенной для нас платформе, журнал был на WordPress, Shop был на Magento, потом переехал на Shopify. Всё это сложно интегрировать. Пришлось бы создавать систему, где нужно было бы интегрировать подписку и в Job Board, и в Shop, и в Magazine. Если, конечно, у тебя будет возможность оставлять какие-то комментарии, получается highlighting, когда ты покупаешь электронную книгу, у тебя должна появляться другая цена, потому что у тебя есть membership, это всё очень муторно и сложно.  Мы решили, почему бы нам не попробовать взглянуть на эту проблему с другой стороны. Почему бы не использовать эту возможность, чтобы продумать, что значит «smashing», Smashing experience, создать membership с интеллектуальным продуктом во всём этом новом редизайне. И поэтому мы решили продумать, как можно сделать новую платформу, новую систему, новый единый технический стек, чтобы, во-первых, узнать, что такое «smashing», а, во-вторых, построить единообразный UX, где ты начинаешь свой user journey, где заканчиваешь, то есть чтобы всегда всё просто проходило. Я понимаю, что это очень длинный ответ на твой вопрос, но это казалось разумной опцией: давайте сядем, продумаем, что значит «smashing» и как всё это дело можно построить, что для этого нужно, и в итоге построим. Мы, конечно, думали, что справимся к 10-летнему юбилею, но мы не успели даже к 11-летнему юбилею. И вот сейчас, спустя 16-17 месяцев разработки, дизайна и тестов, мы наконец-то в состоянии это запустить. — Если вернуться к самому началу, к процессу выбора, я бы хотел уточнить: с точки зрения продукта всё понятно и прозрачно, а вот с точки зрения технологий, как вы выбирали новый стек? Понятно, что это был JS, но внутри JS тоже есть большой фреймворк-зоопарк: по каким критериям вы выбирали, что вы смотрели, от чего отказались? Как вы к этому стеку пришли? Виталий: Я бы не сказал, что это был долгий процесс. В 2012 году я познакомился с Мэттом, который работал тогда в Испании. Он занимался разными вещами, в том числе разными коммерческими проектами, порталами, имея собственное Web Design Agency. В какой-то момент, спустя три года, он приехал из Сан-Франциско, открыл свою фирму-стартап Netlify. Челлендж заключался в том, что было бы, если бы мы вернулись, с точки зрения философии в архитектуре, к тому, с чего мы начали. Изначально у нас был просто сервер, у нас был браузер, там ты получаешь страницы с сервера, и всё готово. И мы подумали, почему тогда просто не создавать «готовые» страницы, с HTML/JavaScript, мы их просто откладываем в CDN, инвестируем много ресурсов, чтобы сделать хороший, шустрый CDN, использовать все современные технологии, чтобы ускорить отдачу данных с CDN (HTTP/2, server push и так далее). И раздавать его юзерам, которые находятся рядом, и потом уже, вторым шагом, подавлять JavaScript для интерактивных элементов, вроде комментариев, уведомлений, shop, check out. Через Stripe API, через свои API или через third-party APIs. Основной принцип заключается в том, чтобы пойти в serverless и не использовать сервер вообще, потому что каждый, наверное, в своей жизни встречался с такой проблемой, как Error Establishing Database Connection. Меня эта идея заинтриговала, когда я о ней услышал, и ещё до начала редизайна мы начали думать, могли бы мы как-то это осуществить, можно ли вообще что-то сделать. Это звучало довольно круто. Мэтт сделал пару демок, взял пару статей и запустил их через свой CDN, через Netlify, и мы обнаружили, что страницы загружаются в шесть раз быстрее. Это было для меня очень удивительно. То есть время отрисовки (у нас и так все довольно оптимизировано, я бы сказал, мы пытаемся делать всё, как нужно), но я был просто в шоке, потому что у нас в среднем результаты доходили до 400-500 миллисекунд в start render time. Конечно, понятно, почему: весь HTML, всё генерируется статически, и потом данные уходят в CDN, потом ещё получаешь данные CDN, потом добавляешь немного JavaScript, звучало довольно просто, и мы решили: «Почему бы нам не попробовать?». Честно говоря, все решения о том, какой фреймворк использовать или не использовать, были связаны скорее с тем, с чем знакома команда Netlify и наша команда. В тот момент Preact казался довольно удобной архитектурой, потому что все, кто работал над этим проектом, кто работал в Netlify, с нами, знали эту архитектуру, Redux, React и все дела. Мы просто решили попробовать её, протестировать и посмотреть, что получится. Вот так всё и получилось. То есть мы не принимали решения не использовать Angular или что-то другое. Просто команда знала React, и мы решили, почему бы не попробовать. — В базе лежит React, но есть же куча всяких технологий, которые вы взяли себе, чтобы сделать всё «smashing». А есть понимание, на сколько этого хватит? Как считаете, когда вы будете делать следующий редизайн? Виталий: Я надеюсь, что не скоро, потому что я эту страницу уже видеть не могу. В целом, я думаю, что система довольно стабильна, в ней много чего можно построить. Мы используем Preact, а не React. Возможно, такой выбор был ошибкой. На Preact многие вещи, которые на React можно было бы сделать довольно шустро, нам приходится частично переписывать вручную. В зависимости от того, как развивается сайт, как будет развиваться Preact, мы, возможно, будем переписывать для React, хотя это не такой уж и большой шаг, как я понял. Я сам не пишу JavaScript, честно говоря. И так даже и лучше. Насколько я понимаю, переход займёт какое-то время, но это не ужасно сложно. С другой стороны, я надеюсь, что то, что мы построили, имеет довольно приличную архитектуру. Там есть какие-то баги, которые надо зарефакторить или исправить, проблемы, которые нужно решить. В целом, мы построили довольно сложные вещи, которые мы не смогли бы сделать на основе того, что было. Я надеюсь, что через пару лет редизайн делать не придётся. Надеюсь, лет на 5-7 хватит. — Как раз нормальный жизненный цикл. По поводу времени процесса Вы уже говорили, что всё затянулось на 17 месяцев. Можете сориентировать по команде — сколько людей этим занимается? Дизайнеры, разработчики, менеджеры? Виталий: Хочу объяснить, почему это заняло так много времени. Мы хотели запустить в сентябре 2016, интенсивно работали, чтобы это получилось. Мы пропустили этот дедлайн, потому что у нас было много других, более приоритетных проектов, которым нужно было заниматься. Команда была очень маленькой, поэтому такие проекты, как, например, конференции и выпуск книг, занимали очень много времени. В целом, в начале проекта было человек 10 с самыми разнообразными обязанностями: от анимации до перформанса и React. Большую часть всего проекта работали ребята из Netlify: Мэтт и его команда. Этот проект позволил им показать, на что они способны. В нашей команде был Дэн Молл (Dan Mall) — главный visual-дизайнер, Сара Суидан (Sarah Soueidan) — главный фронтенд-разработчик, но она работала только до февраля, у неё были другие проекты, после этого мы работали с Ильей Пyхальским из Минска, знаем друг друга давным-давно, познакомились, кажется, на конференции в Уфе. Он работает (или работал) в EPAM и занимается также другими проектами. Не знаю, что именно для него хобби — EPAM или Smashing, но он классный JavaScript-разработчик и занимается в том числе и React. Честно говоря, большую часть CSS за последнее время написал я сам. Есть интересный CSS, но я стараюсь, конечно, следовать тому, что много кода было написано уже 16 месяцев назад, многое изменилось, вышел CSS Grid Layout, изменился Payment request API, и поэтому каждый раз — это как гонка против мельниц, постоянно приходится что-то обновлять и менять. На самом деле, мне в прошлом нужно было бы делать CSS-рефакторинг. Надо будет заняться этим на следующей неделе. Вообще у нас очень маленькая команда, два с половиной человека, которые постоянно этим занимаются, менеджер проекта Маркус занимается у нас SEO и кучей других вещей, включая финансы. Я бы не сказал, что это большая команда, которая 18 месяцев занималась проектом. Это маленькая команда, которая этим проектом занималась отрывисто. — Что за эти 18 месяцев получилось сделать относительно легко, а с чем были проблемы? Виталий: Я не ожидал, что возникнет столько проблем с accessibility. Сначала в CSS всё было очень чётко, классно, как нужно. Но когда мы начали добавлять все React-фишки, когда мы обнаружили, что есть states, нужно размещать контент туда-сюда, изменить тут и т.д., пришлось писать очень много JavaScript’a для accessibility. Сейчас я бы сказал, что у нас вообще не работает checkout script, также есть ещё моменты, которые мне нужно зарефакторить. Я бы не сказал, что проблемы с CSS были сложными, мы их легко решили. Layout сам по себе довольно сложный, но, поскольку мы решили эту проблему, всё остальное было просто. Даже не было сложностей в JavaScript. Единственная проблема, которую мы не ожидали и на решение которой ушло очень много времени, — это то, что membership — центральный элемент всего. Нам нужно смотреть, логинить человека, делать ему аккаунт. Аутентификация без сервера — это нужно сделать кучу API: authentication, commands, job board, потому что всё идёт через JavaScript. Также мы отдельно используем Go для management, admin, orders и так далее. Эти вещи заняли больше времени, чем мы думали. Я бы не сказал, что это проект был чудовищно сложным с архитектурной точки зрения. Нужно было решить пару сложных моментов, а это было, скорее, после нахождения багов. — То есть нормальный процесс разработки. Что дальше будет с проектом? Концепция membership и дальше будет развиваться? Классический вопрос для собеседования: какими вы видите себя через пять лет? Виталий: Ответить точно не могу, потому что не знаю, что будет через полгода. Всё зависит от того, как пойдёт проект. Мы сделали full membership, с этим много всего связано — вебинары, различного рода акции, campaigns, content campaigns, конференции и т.д. Я надеюсь, что всё пойдёт хорошо, и тогда у нас будет хороший фундамент, на котором мы можем построить всё, что угодно. В техническом плане, если мы сможем осилить, есть очень много разных идей, которые я ещё только ищу, над чем мы работаем. Особенно в плане образования. Это не то, что создать Treehouse или lynda.com. Я считаю, что важно иметь возможность, физическое место, куда можно впихнуть людей, занимающихся образованием. Людей, которые занимаются CSS, JavaScript, фронтендом, бэкендом, которые могут преподавать студентам то, что они решают на практике. Нужно физическое место, где это можно было бы осуществить, вроде Smashing University, может быть. Что-то в этом роде. Традиционное образование, к сожалению, далеко не оптимально в этом плане. Membership для нас крутится вокруг комьюнити, поэтому, я считаю, сделать нечто вроде Smashing School в плане образования было бы очень хорошо. Многим фирмам нужны фронтенд-разработчики и дизайнеры, а многие студенты хотят пойти в эту область, поэтому это было бы очень здорово. — Прекрасный план! Надеюсь, всё получится с membership и школой. Спасибо большое! Деврел Axiom JDK, продюсер в Failover Bar