«Я просто энтузиаст проекта и пользователь языка Dart» — интервью с Ari Lerner, автором знаменитой n
- вторник, 13 ноября 2018 г. в 00:21:32
habrahabr
https://habr.com/company/jugru/blog/429564/
Как написать девять книг по совершенно разным технологиям, включая Angular, Vue, React, React Native и другим? Что самое важное в обучении, что такое «hallway chat» и вообще, при чём тут Dart и Flutter?
Сегодня у нас в гостях автор множества книг и статей по программированию, включая ng-book — Ari Lerner. Какой будет дальнейшая книга, что автор думает о таком… противоречивом языке, как Dart, и почему на конференциях так важно общаться, спрашивают ребята из программного комитета конференции HolyJS (Дмитрий DmitryMakhnev Махнёв и Евгений bunopus Кот).
— Здравствуйте. В нашем интервью будет три раздела, в первом мы поговорим о вас, во втором о Flutter, и третий будет заключительный. Давайте для начала вы расскажете немного о себе?
— Для начала я хотел бы поблагодарить вас за приглашение — я очень рад возможности выступить на HolyJS. Что касается меня, я живу в Бруклине в Нью-Йорке и программирую столько, сколько себя помню — моим первым языком был ассемблер в начале 1990-х. В данный момент я занимаюсь блокчейнами и глубоким обучением, пока что по отдельности. По большей части я работаю с клиентами, помогаю им выходить на ICO (Initial Coin Offerings), помогаю им работать с «token economics». А ещё со мной живет восхитительная собачка Джинджер, помесь чихуахуа и корги — о ней я могу говорить бесконечно.
— А как она выглядит? Размером с чихуахуа, но лохматая, как корги?
— Да, это уменьшенная корги с мордочкой чихуахуа. Очень милая.
— Чем вы зарабатываете сейчас? Пишете книги, или работаете в компании?
— И то, и другое. Я пишу книгу, но это уже не занимает всё моё время. Пока я не решил, что делать дальше, работаю на себя.
— Насколько я понимаю, 5 или 6 лет назад вы основали Fullstack.io?
— Да, это было в 2012 году.
— Расскажите о нём.
— Fullstack состоит из двух частей, это издательство учебников по программированию, а также образовательная платформа. Что касается издания учебников, наша основная аудитория — профессиональные разработчики, но мы также предоставляем учебники университетам, школам и программам повышения квалификации. Помимо этого, мы проводим тренинги в онлайне и вживую, как правило в рамках повышения квалификации. Мы работаем с компаниями вроде General Electric, Walmart, с вооружёнными силами и так далее.
— Здорово. Конкурируете ли вы с O’Reilly, или у вас совсем другая область?
— Мы занимаемся вещами, во многом похожими на то, что делает O’Reilly, но напрямую мы с ними не соперничаем, потому что у нас совсем другой масштаб — мы не представляем угрозы мировому господству O’Reilly над книгами по программированию. Кроме того, у нас немного другой подход. Обычно книги после издания не обновляются, так что как только вы её прочитали, она уже устарела. Если же вы покупаете книгу у нас, мы предоставляем вместе с ней постоянные обновления.
— Издаёте ли вы бумажные книги, или только электронные?
— И те, и другие. Мы продаём бумажные книги через Amazon, но их обновить невозможно. Электронные же книги, купленные на Fullstack, обновляются автоматически. Через Amazon обновлять нельзя — у них слишком жёсткий контроль.
— Насколько я понимаю, вы являетесь соавтором множества книг на Fullstack.io — Fullstack React, Fullstack React Native и, конечно же, знаменитая ng-book. Чтобы написать книгу, нужно быть очень хорошо знакомым с предметной областью, о которой вы пишете — будь то Angular, React, Vue или что-либо иное. Как выглядит ваша подготовка к написанию книги?
— Хороший вопрос. Давайте я вначале расскажу вам, как я вообще начал писать книги, и почему мне нравится это занятие? А потом перейдём к тому, как идёт работа над каждой отдельной книгой.
— Да, конечно.
— В 2012 году я достиг потолка в той компании, где я работал, и решил, что настало время уходить. Я создал свой стартап — хотите верьте, хотите нет, но это была компания, занимающаяся планированием (scheduling company). Для неё я написал элегантнейший бэкенд на Erlang и Python, кажется, с примесью Ruby. Но хорошего фронтенда не было, поэтому я начал исследовать различные фреймворки и наткнулся на Angular. Это было очень давно, до версии 1.0. Я начал писать фронтенд для своего стартапа, и Angular мне очень понравился, но документация к нему была просто ужасная. Чтобы разобраться в том, как работает этот фреймворк, я начал читать исходники и разбираться в том, как он устроен — так произошло моё близкое знакомство с Angular.
Примерно тогда же меня попросили выступить с докладом про JavaScript в учебном лагере для разработчиков в Сан-Франциско, и тогда я понял, что мне очень нравится преподавать. Поэтому я решил объединить эти два интереса и стал писать мини-руководство по Angular для начинающих. Поначалу я думал, что это будет две или три страницы текста, но в итоге вышло 650 страниц, которые я с годами продолжал обновлять. В конечном итоге я стал автором или соавтором девяти книг. Я преподавал в качестве добровольца на каждом крупном учебном лагере для разработчиков в Сан-Франциско. Я также участвую на добровольческих началах в организациях вроде Women Who Code и проектах Bridge Foundry, и преподаю ElixirBridge. Я даже давал занятия в тюрьме общего режима в области залива Сан-Франциско, и по-прежнему преподаю здесь, в Нью-Йорке.
Преподавание для меня очень важно, оно мотивирует меня больше учиться самому. Преподавая, я не только помогаю другим, я заставляю себя подниматься на новый уровень, чтобы уметь объяснить, как работает та или иная технология. Обычно я готовлюсь, читая исходники, особенно это касается JavaScript. Год или полтора тому назад мы познакомились с Vue, и просто начали изучать исходники, наша работа с Vue принесла нам большое удовольствие. По мере работы я записываю все проблемы, с которыми встречаюсь, все поисковые запросы в Google, все вопросы по документации. В результате мы компилируем огромное и очень подробное оглавление, которое затем при любых изменениях мы обновляем вместе со всей книгой.
— Это происходит автоматически, при помощи обработчиков, которые следят за всей этой информацией в документации?
— У нас есть обработчики, которые отслеживают циклы релиза, но, к сожалению, почти всё остальное — редактирование содержания и изображений — выполняется вручную. У нас есть хуки на Реакт, и у нас выполняются автоматические обновления кода, но содержание приходится обновлять вручную.
— Понятно. Насколько мне известно, вы являетесь соавтором множества книг. Сложнее ли писать книгу одному или вместе с кем-то? Как вы организуете свою работу, как синхронизируете главы?
— Так же, как при совместной разработке приложения, мы используем Git для унификации содержания, так что у нас есть версии и ветки. Написать книгу в соавторстве может быть тяжело, хотя, я думаю, несколько проще в случае с книгами по техническим специальностям, чем по нетехническим. Думаю, сложнее всего обеспечить единый тон для всех разделов, и определить, какие использовать демки. Но, в целом, это не слишком трудная задача. Всё внимание поглощает написание и редактирование, и мы постоянно находимся на связи друг с другом, что существенно упрощает процесс. С годами мы наработали шаблоны письма, которые обеспечивают единство стиля всем нашим многочисленным авторам. И мы всячески стараемся, чтобы наши соавторы писали с нами, а не для нас. Мы позиционируем себя как команду, в которой все работают друг с другом, а не как издательскую компанию, на которую работают авторы. Кроме того, мы все являемся соредакторами для тех книг, которые пишем. Наличие редактора или редакторов помогает обеспечить однородный стиль на протяжении всей книги. Каждый автор редактирует раздел, написанный другим автором.
Что касается инструментов, то мы пользуемся Git, а также простыми текстовыми редакторами и Markdown. Я обычно работаю в Visual Studio Code или Spacemacs — сочетание Emacs и Vim, очень рекомендую, если вы его ещё не пробовали. Кроме того, у нас много собственного софта, который мы написали для компиляции, работы со стилем и предпросмотра книг в реальном времени. Его мы используем прежде, чем публиковать новый релиз или обновление книги. Большая часть наших инструментов написана на JavaScript, TypeScript или Python.
— Пользуетесь ли вы гибкими методологиями наподобие Scrum при написании книг?
— Да, но не слишком активно. Мы проводим своего рода модифицированные stand-up-встречи, но не каждый день, а каждую неделю, или через неделю, в зависимости от темпа работы над книгой. Если я работаю один, то весь мой stand-up заключается в том, что я открываю мой текстовый редактор, но если я работаю с кем-то, то мы постоянно на связи друг с другом через Slack и Google Hangouts.
— А сколько времени у вас занимает написание книги?
— Зависит от того, какая это книга, работаю ли я с соавторами, от скорости фреймворка. Скажем, ng-book я написал за четыре месяца, работая по вечерам и по выходным. Но для меня это совершенно невообразимая скорость, я до сих пор не понимаю, как успел так много сделать. Обычно на одну книгу уходит от шести до двенадцати месяцев.
— Интересно. Вы тратите много времени, работаете с интересными инструментами и процессами, возможно, в соавторстве с кем-либо ещё, затем отдаёте книгу в издание. Когда плод ваших трудов издатель пытается перевести на другой язык, как вы проверяете качество перевода? Я спрашиваю, потому что когда я начинал программировать, я не мог читать техническую документацию по-английски, поэтому я читал много книг на русском — например, перевод Good Parts of JavaScript и самых известных книг O’Reilly. Насколько мне известно, эти переводы были ужасными. Я думаю о том, как к этому должны были отнестись авторы книг, и какой у них мог бы быть способ проверить переводы. Какое в целом ваше мнение о переводах?
— Здесь я могу говорить только о своём личном опыте и о том, как работает Fullstack. У нас много ситуаций, когда мы не владеем языком, на который переводится книга — например, большинство наших книг переводится на китайский, а я по-китайски не говорю. Правда, со временем я научился нескольким словам, у меня для этого специальное приложение, Babbel, при помощи которого я учу иностранные языки. Но в случае с китайским лучше всего переводы у нас получались тогда, когда наш переводчик одновременно был программистом. Благодаря этому при всяких вопросах переводчику проще было задать вопрос нам на английском, и затем правильно перевести ответ на китайский. По-русски я, к сожалению, тоже не говорю. Могу сказать «велосипед» — хотя нет, как слышите, даже этого я сказать не могу. Безусловно, тяжело не знать языка, на котором написан софт. Я это особенно хорошо понимаю, когда смотрю документацию опенсорсных китайских проектов — чтобы хоть что-либо понять, мне приходится копаться в исходниках.
— Похожая ситуация была со Vue. Насколько я знаю, у первых его релизов была довольно плохая документация, а многие issues были описаны на китайском. Насколько мне известно, сейчас обязательным требованием является английский язык.
— Да, это так. Мне повезло, что английский у меня родной язык. Хоть я и не безупречно на нём говорю, с документацией у меня проблем не возникает. Я считаю, что переводы очень важны. Кроме того, мы живём в такое время, когда машинный перевод становится всё более качественным, в особенности благодаря глубокому обучению — это одна из причин, по которым я заинтересовался глубоким обучением. Тем не менее, я не думаю, что для всех этих проблем есть одна панацея.
— Недавно я наткнулся на бурную дискуссию в русскоязычной части Twitter. Одна сторона в споре утверждала, что переводы по определению — зло, потому что программисты обязаны знать английский язык, он — международный язык для всех. Другие говорили, что для джуниоров и тех, кто не очень хорошо говорит по-английски, документацию переводить надо. Есть ли у вас мнение по этому спорному вопросу?
— Мне близки аргументы обеих сторон. То, что я сейчас скажу — это всего лишь моя первоначальная реакция, долго я эту проблему не обдумывал. Возможно, при личной встрече мы сможем более глубоко обсудить эту тему. Мне кажется, что сейчас настолько много кода написано на английском, что избавиться от английского языка было бы крайне сложно. Существуют интернациональные языки — например, JavaScript является интернациональным языком, если вы говорите на нём, то вы можете общаться с любым человеком в любой точке земного шара. Наличие интернационального языка — английского — упрощает нам общение и сотрудничество с разработчиками во всём мире; например, я общался с разработчиками в Индии, Франции, Англии, Китае, Австралии. Конечно, это не вполне справедливо по отношению к людям, которые по-английски не говорят — уверен, если бы я не говорил по-английски, у меня по этому вопросу было бы другое мнение. Кроме того, как я уже сказал — это всего лишь мои первичные размышления, долго эту проблему я не обдумывал и, возможно, завтра моё мнение изменится.
— Да, мы можем обсудить это при личной встрече. Сейчас же давайте поговорим о книгах — они становятся менее популярными, чем раньше, из-за появления таких платформ, как Media, Twitter и так далее. Считаете ли вы, что книги исчезают?
— Я не убеждён, что книги становятся менее популярными. Я считаю, что все работают и учатся по-разному. Онлайн-сервисы по своей функции похожи на занятия в классах. И мне кажется, что онлайн-обучение подходит для разработчиков, которые хотят выучить различные языки и фреймворки по-другому. Некоторым проще работать с документацией, другим — с исходниками, некоторые лучше работают в группах, другие — в одиночку, путём проб и ошибок, или читая книги на поездах и самолётах и затем реализуя прочитанное на практике. С другой стороны, я преподавал в классах, где всё было ровно наоборот и где ученики просто не могли сесть за книгу, это им ничего не давало. Не то, чтобы они вовсе не умели читать, просто они меньше получают от чтения, чем от работы с другими людьми. Думаю, одно из очень важных достижений интернета для программистского сообщества заключается в том, что он сделал обучение более доступным, а успех — более достижимым. Сайты и сервисы вроде Medium или Coursera помогают распространению знаний и делают возможными разнообразные способы обучения. Я горжусь тем, что могу быть причастным к этой эволюции образования. Возможно, в будущем наши книги станут интерактивными, и мы сможем объединить их с онлайн курсами.
— Я помню, что когда-то книги продавали с CD или DVD-диском с примерами. Сейчас такой формат вышел из моды.
— Да, сейчас всё предпочитают отправлять zip-архивами — например, мы объединяем все наши демки в один zip-архив. Один из наиболее полезных разработанных нами инструментов позволяет записать в одном месте весь исходный код, который используется в книге, и затем у нас есть инструменты, которые автоматически обновляют его из оригинальных исходников. Предположим, нам необходимо выделить строку, класс, объект или функцию, которую мы обсуждаем в книге. У нас есть инструменты, благодаря которым можно делать прямые ссылки на исходный код. Это полезно в том числе и потому, что каждый раз, когда вы скачиваете книгу, происходит обновление исходников. Так что мы записываем исходники не прямо в текст, а в отдельный файл.
— Мой следующий вопрос будет связан с предыдущим. Вы сказали, что все учатся по-разному и я, как разработчик, могу для обучения читать книги, смотреть видео на YouTube, читать статьи на какой-нибудь платформе. А вот зачем мне посещать конференции?
— Это хороший вопрос. Навскидку я могу назвать две причины, по которым это стоит делать. Первая — наиболее очевидная: презентации и доклады на конференциях обычно хорошо продуманы и специально предназначены для просмотра. Как правило, такой доклад посвящён чётко определённой проблеме — например, рефакторингу. Когда сидишь в аудитории, где идёт хороший доклад по рефакторингу, то как будто бы проводишь рефакторинг сам, оказываешься включён в презентацию, в процесс. Ну и для меня всегда интересна личность докладчика, его эмоции.
Вторая причина менее очевидная. Я это называю «hallway chat» — помимо собственно докладов вы встречаетесь и общаетесь с людьми, которые занимаются тем же, что и вы. Наша деятельность как разработчиков по определению индивидуальная — но когда вы начинаете общаться со множеством других людей, которые находятся в том же пространстве, что и вы, и занимаются тем же, что и вы, эта деятельность автоматически становится социальной. Другая польза от «общения в холле» заключается в том, что вы встречаете людей, которым нужны ваши услуги, ваши технические знания или преподавательский опыт. По моему опыту, мы находим больше клиентов, чем где-либо ещё — и это касается даже наших книг и наших видео.
— Вы уже написали много книг — скажите, над чем вы работаете сейчас? Может, немного спойлеров?
— Сейчас я в основном занимаюсь блокчейнами. Если говорить о блокчейнах, дополненной реальности, глубоком обучении, то в этих областях здорово то, что они сейчас очень популярны, так что практически на каждой конференции, которую я посещал за последние несколько лет, я вступал в очень оживлённые дискуссии с людьми, заинтересованными этими предметами. Причём зачастую это мог быть разработчик фронтенда в Google, который в своё свободное время занимается другими темами.
Что касается меня лично, то проекты, которыми я занимаюсь, в основном связаны с экономикой — и самое удивительное, что это весьма занимательный предмет. Кроме того, я сейчас работаю над книгой под названием «C++ for JavaScript developers», пока что она находится на ранней стадии написания. Я очень рад буду обсудить эту тему, если встречу на конференции по JavaScript кого-либо, кто работал с С++.
— Эта книга будет как-то связана с WebAssembly? Сами понимаете, С++ и JavaScript…
— Книга в основном посвящена EOS — это довольно новый блокчейн. Он похож на Etherium, но создан при помощи LLVM, а это позволяет писать контракт на чём угодно, что компилируется в LLVM, в том числе на С++.
— Здорово. Давайте перейдём к следующему разделу, он будет более тесно связан с вашим докладом на HolyJS. Вы раньше работали с Angular, Vue, React, JavaScript — а сейчас делаете доклад о Flutter, мобильной платформе от Google, написанной на Dart. Что вас подтолкнуло к этому?
— В такой формулировке это действительно звучит забавно. Здесь похожая история на то, как я пришёл к Angular, о чём я уже говорил выше. Я хотел написать несколько приложений для себя и своих друзей, которые пользуются кто Android, кто iPhone. Мы уже издавали книгу про ReactNative, и у меня был опыт с этой платформой, но хотелось попробовать чего-то другого. Я умею писать на Java, Kotlin и Swift, поэтому я начал писать приложение на Swift. Насколько мне известно, сейчас делаются попытки приспособить Swift для Android, но те, с которыми я знаком, находятся ещё на очень ранних стадиях, рассчитывать на них нельзя. Кроме того, мне кажется, что многие из них — хаки. То есть разработчик привык к iOS и пытается просто перенести свой опыт на Java, или, наоборот, очень хорошо знаком с Java и лезет с ней в iOS. Кроме того, я не хотел расставаться с сообществом JavaScript — у меня с ним наладились очень тесные связи, я мог пользоваться замечательными инструментами вроде Redux, было множество библиотек, при отсутствии которых пришлось бы изобретать велосипед. В результате я решил поискать другой кросс-компилируемый фреймворк и нашёл Flutter.
Flutter написан на Dart, это компилируемый язык, во многом похожий на TypeScript. Он обеспечивает лёгкую интеграцию с библиотеками JavaScript, так что я мог опираться на свой опыт, скажем, с Redux. Другое преимущество Flutter в том, что в нём всё является виджетом, благодаря чему процесс написания приложений становится более быстрым и понятным. А иммутабельность данных делает приложения более безопасными, ошибки обнаруживаются очень быстро. Кроме того, во Flutter есть AOT-компиляция и JIT-компиляция, а множество встроенных виджетов позволяют очень легко создать приложение, пользуясь знакомым UI. Благодаря тому, что вам видно, как работают виджеты во Flutter, вы начинаете лучше понимать, как Flutter устроен.
У Flutter много и других сильных сторон — тестирование, управление пакетами, распределение, компилирование. Одна из самых крутых особенностей Flutter — это hot reload, к которому мы так привыкли в web. Например, когда вы собираете приложение на Swift, вы компилируете, затем запускаете приложение, затем вам, возможно, нужно нажать несколько клавиш, чтобы вернуться к экрану, на котором вы работали, решить возникшие проблемы, после чего весь цикл повторяется. Далее, с Flutter ваш UI всегда будет локализован на том же языке, на каком написана ваша бизнес-логика. Что касается моего опыта с Flutter, то я на нём написал несколько приложений, и я просто в восторге от этого процесса. Ещё нужно сказать, что Dart достаточно похож на TypeScript, который, в свою очередь, похож на JavaScript, так что весь мой опыт с JavaScript напрямую пригодился мне в работе с Dart.
— Но Dart — язык с сильной типизацией, поэтому писать программы на нём так же, как вы пишете на JavaScript, не получится. Что вы думаете о Dart в целом, как о языке? Какие у него преимущества?
— Если быть абсолютно честным, то я считаю, что Dart прекрасен. Мне нравятся языки со статической типизацией — хотя я ничего не имею против динамических языков, из них мне больше всего нравится Clojure. Но у статической типизации много преимуществ, и, мне кажется, из-за них многие разработчики стали переходить с JavaScript на TypeScript — правда, у последнего есть возможность убрать типизацию и позволить компилятору определить типы самостоятельно. У Dart также есть нечто подобное, он выполняет вывод типов, так что в нём не строгая типизация. Тем не менее, преимущество языков со статической типизацией, даже с выводом типов, заключается в том, что их очень быстро можно переводить на другие языки, и ошибки можно обнаружить до запуска приложения. Как я уже говорил, это всё есть у TypeScript и Flow. Компиляция обеспечивает предсказуемость и скорость, во Flutter она происходит в нативный код. Кроме того, как я уже говорил, у Flutter есть JIT-компиляция, что делает цикл разработки значительно более быстрым и простым, и благодаря ней у вас есть очень быстрый перезапуск при разработки приложения на Flutter.
В Dart много других привлекательных вещей — например, область видимости работает значительно проще, чем в JavaScript, вам не нужно “байндить” функции. Классы являются объектами первого порядка, у них эксплицитные интерфейсы, конструкторы именованные — если вы работали на Java, они вам, скорее всего, нравятся. Мне кажется это супер круто, это позволяет нам проще писать на Dart, и потом компилировать его в JavaScript и потом использовать этот JavaScript. Кстати, я вроде бы не упоминал, да, Dart компилируется в JS. Isolates внутри Dart позволяют использовать Web workers вместе с Dart. По-моему, Dart существенно облегчает наиболее тяжёлые аспекты разработки. Помимо этого, у Dart много прекрасных инструментов, замечательные библиотеки для Flutter, время запуска очень небольшое, поскольку код на Dart компилируется напрямую в нативный код, а не как в React Native, где создаётся дополнительная прослойка из JavaScript.
— Десериализация и тому подобное.
— Да. На мой взгляд, сообщество React Native создало много хороших библиотек, но по-прежнему остаётся много трудностей — например, нельзя передавать объекты JavaString, их надо сериализовать в строковые объекты. С Flutter ничем таким заниматься не нужно, потому что компиляция происходит напрямую в нативный код. Наконец, поскольку Dart похож на Java, C#, ActionScript и JavaScript, обстановка, в которой вы пишете, в общем-то знакомая, и вы можете опереться на весь ваш опыт с этими языками.
— В то время как Clojure, например — это нечто совершенно иное. А с Dart уютно, как под одеялком.
— Да, я писал на Clojure — там всё вверх ногами.
— Какие приложения, по-вашему, можно — или нужно — писать на Flutter? Можно ли написать банковский клиент, финансовое приложение или приложение, требующее многих экранов? Или он годится только для того, чтобы написать на нём «Hello World»?
— Пока что меня весьма впечатляет и скорость разработки, и скорость созданных мной на Flutter интерфейсов. Если вы выбираете между нативной разработкой или кросс-компилируемым фреймворком наподобие Flutter или React Native, многое зависит от вашей команды. В правильно спроектированном приложении, я думаю, нет ограничения на количество экранов, которое можно написать — здесь Flutter не уступает другим вариантам. Если у вас небольшая команда, и вам нужно довести ваше приложение до как можно большего числа пользователей независимо от платформы, при этом не жертвуя производительностью вашего приложения в рантайме — однозначно используйте Flutter. Если же у вас много сотрудников, и есть разработчики с большим опытом написания нативного кода, то скорее встаёт вопрос того, как вы будете набирать вашу команду — будете ли вы набирать людей, прекрасно пишущих именно на Java или на Swift, или людей, которые могут написать код и для фронтенда вашего веб-приложения, и для бэкенда на сервере, и для мобильного приложения. И тут, повторюсь, преимущество Flutter для меня в том, что он позволяет писать на языке, с которым я хорошо знаком.
Если отвечать на ваш вопрос более прямо, Flutter прекрасно подходит для приложений, которые отображают некоторое содержание — например, он подошёл бы для Twitter. Иначе обстоит дело, когда вам нужна производительность, которую может дать только нативное приложение, например, в случае с приложениями AR и VR. Единственное моё AR-приложение написано на Swift, и на Flutter я его пока не перевёл. Отчасти это потому, что и на iOS, и на Android очень удобные фреймворки для виртуальной реальности и дополненной реальности.
— Вы упоминали, что Flutter подошёл бы для написания Twitter — но Twitter сейчас написан на PWA. Можно ли сравнивать Flutter с приложениями на PWA? Они тоже кросс-платформенные, и у них много других сходств.
— Насколько я знаю, в будущем можно будет компилировать приложения на Flutter в веб-приложения, пока что этого делать нельзя. Но если вы написали бизнес-логику вашего веб-приложения на Dart, то вы вполне можете использовать её в мобильном приложении. И Dart очень быстрый. Зачастую скомпилированный Dart JavaScript-код будет быстрее, чем код, написанный напрямую в JavaScript.
— Думаю, это несколько спорное утверждение.
— Хорошо, сформулирую это иначе. Довольно часто компиляция кода на Flutter происходит быстрее, чем кода, который вы написали бы напрямую в JavaScript.
— Понятно. Если мы говорим о языках вообще, то существует множество таких, которые можно компилировать в языки на других платформах. Одним из них, конечно, является JavaScript — сейчас можно всё что угодно и для любой платформы написать на JavaScript. Есть и фреймворки такого рода — для Angular это Ionic, для кроссплатформенной мобильной разработки — Cordova PhoneGap. Существует ли один язык, способный удовлетворить все нужды? Возможно, это JavaScript?
— Интересный вопрос. Думаю, дело в том, что JavaScript прост в обучении, поэтому его сообщество быстро растёт, что позволяет генерировать много идей— благодаря этому возникли React Native, Node.js и, отчасти, Dart. Из всех существующих языков JavaScript, по-моему, ближе всего к модели универсального языка для всех платформ. Но лично меня тянет к языкам, созданным на основе определённой идеи — например, мне очень нравятся функциональные языки. Не думаю, что они когда-либо выйдут из употребления. Тем не менее, если вы в 2018 году решили научиться писать на каком-нибудь языке, и не знаете ещё, чем будете заниматься — вебом, мобильными приложениями, бэкендом — то не пожалеете, выбрав JavaScript.
— Но если JavaScript такой замечательный, то почему сейчас возникают новые языки — Go, ClojureScript, Dart? Зачем нужны другие языки, если есть JavaScript?
— А если мне нравятся яблоки, зачем есть другие фрукты? Я сейчас скажу фразу, которую очень часто повторяют в тренировочных лагерях, да и не только там — очень важно, чтобы инструмент соответствовал выполняемой работе. Я пишу много кода на Go, потому что всё, что связано с блокчейнами, я делаю на Go или C++ — там очень важна скорость. А все интерфейсы я пишу на JavaScript или Dart, и иногда я использую ClojureScript. Суть в том, что C в ближайшем будущем никуда не денется, хоть он и довольно старый. Он приспособлен для приложений, которым особенно нужна скорость и хорошее управление памятью. Так или иначе вам придётся мириться с особенностями того языка, на котором вы работаете. Например, сборка мусора всегда будет проблемой для JavaScript, и при написании крупных приложений вам всегда придётся разбираться с ней. Неизбежно приходится жертвовать производительностью в рантайме ради простоты цикла разработки. Мой доклад ни в коем случае не направлен против Swift или Java — как я уже говорил, моё приложение с AR написано именно на Swift, поскольку, с одной стороны, я ещё не портировал его на Flutter, но, с другой, Swift прекрасно подходит для этой задачи.
— Кажется, в 2013 году, когда объявили о создании Dart, вокруг него было много ажиотажа, но потом о нём многие забыли, и сейчас во многих сообществах можно услышать, что Dart умер и больше от него ждать нечего. Что вы думаете о будущем Dart и Flutter, и о будущем Dart отдельно от Flutter? Ведь есть и AngularDart, и Dart для бэкенда.
— Хороший вопрос. Если бы я знал ответ на него, то я сидел бы где-нибудь на тёплом пляже, или на собственной яхте с вертолётной площадкой. Если делать какие-либо предположения, то вначале нужно сказать, что я не вхожу в команду Flutter — я просто энтузиаст проекта и пользователь языка Dart. Думаю, библиотека Cupertino — интерфейс Flutter для iOS — будет расти. И, кажется, команда Flutter хочет добавить возможность писать нативные десктопные приложения на Flutter — но точно я в этом не уверен.
Что касается создания Dart, то, на мой взгляд, о нём объявили слишком рано, и это привело к излишнему воодушевлению и преждевременным надеждам. В 2013 это был год EcmaScript и, я считаю, это был явный перебор со стороны Google, пытаться повлиять на команду ECMAScript. И к тому же Flow и TypeScript с точки зрения типизации в языке, стали более популярны. Я желаю Dart и Flutter всего самого лучшего, в особенности с предстоящим выходом версии 1.0 у Flutter.
Есть проект, который работает так же, как и Flutter, называется Fuse, но он основан на C#. Вот насчёт его будущего у меня действительно есть сомнения. В то же время сообщество JavaScript растёт очень быстро, и, поскольку Dart близок к JavaScript, это будет способствовать интересу разработчиков к Dart и Flutter.
— Здорово, спасибо. Хотелось бы еще поговорить о конференциях. Что в них самое важное для вас?
— Как я уже упоминал, для меня в конференциях самым ценным является «hallway chat». И здесь очень многое зависит от самих участников конференции. Интересное содержание, запоминающиеся докладчики и мероприятия, связанные с конференцией, помогают создать и укрепить сообщество единомышленников. Важно всё, что помогает этому сообществу процветать. И, как я уже сказал, мне нравится ходить на конференции, поскольку они делают мой труд социальным, а не индивидуальным.
— Насколько я знаю, это будет ваша первая поездка в Россию?
— Да.
— Какие ваши ожидания от России, от Москвы и от HolyJS?
— Поскольку кроме Москвы я ничего в России не увижу, первые две части вопроса будут, в сущности, одним и тем же. Как уже было сказано, я никогда не был в России — я в основном ездил в Китай и страны того региона, то есть в Тайвань, Южную Корею. Как я понял из того, что я читал о России, у вас другая культура, вы всё делаете несколько иначе, чем мы, и мне очень интересно будет узнать, как это выглядит на практике. Это одна из причин, по которым мне нравится путешествовать — мне всегда любопытно, как живут другие люди, какие у них приоритеты. В Нью-Йорке своя культура, и всё моё знакомство с российской культурой сводится к получению визы и визитам в местный ресторан. Так что меня ожидает новый и увлекательный опыт, каким именно он будет — я предсказать не могу.
Что же касается HolyJS, то, насколько я знаю, разработчики в России очень целеустремлённые, умные и точные. Я не хочу обидеть кого-либо во Франции или в Англии, но там строгость скорее можно найти в общении, так что я с нетерпением жду серьёзных технических разговоров с серьёзными технарями. Разработчики в России, по-моему, очень крутые, и мне очень хотелось бы поговорить и с вами лично, и с вашим сообществом.
Ну и, конечно, я ожидаю холода в Москве.
— Да что вы, какой холод, -10 или -15 по Цельсию, сущие пустяки.
— Всего-то? Тогда я буду в шортах.
— И в солнечных очках. Если серьёзно, то у нас классные сообщества Dart и Flutter — хотя, конечно, им далеко до сообщества JavaScript. И в обоих случаях скоро заметные мероприятия: HolyJS пройдёт 24-25 ноября, а 1 декабря будет конференция по Dart и Flutter.
— Здорово. К этому времени Flutter выйдет из бета-версии.
- Блог компании JUG.ru Group
- Dart
- JavaScript
- Конференции
Как написать девять книг по совершенно разным технологиям, включая Angular, Vue, React, React Native и другим? Что самое важное в обучении, что такое «hallway chat» и вообще, при чём тут Dart и Flutter?
Сегодня у нас в гостях автор множества книг и статей по программированию, включая ng-book — Ari Lerner. Какой будет дальнейшая книга, что автор думает о таком… противоречивом языке, как Dart, и почему на конференциях так важно общаться, спрашивают ребята из программного комитета конференции HolyJS (Дмитрий DmitryMakhnev Махнёв и Евгений bunopus Кот).
— Здравствуйте. В нашем интервью будет три раздела, в первом мы поговорим о вас, во втором о Flutter, и третий будет заключительный. Давайте для начала вы расскажете немного о себе?
— Для начала я хотел бы поблагодарить вас за приглашение — я очень рад возможности выступить на HolyJS. Что касается меня, я живу в Бруклине в Нью-Йорке и программирую столько, сколько себя помню — моим первым языком был ассемблер в начале 1990-х. В данный момент я занимаюсь блокчейнами и глубоким обучением, пока что по отдельности. По большей части я работаю с клиентами, помогаю им выходить на ICO (Initial Coin Offerings), помогаю им работать с «token economics». А ещё со мной живет восхитительная собачка Джинджер, помесь чихуахуа и корги — о ней я могу говорить бесконечно.
— А как она выглядит? Размером с чихуахуа, но лохматая, как корги?
— Да, это уменьшенная корги с мордочкой чихуахуа. Очень милая.
— Чем вы зарабатываете сейчас? Пишете книги, или работаете в компании?
— И то, и другое. Я пишу книгу, но это уже не занимает всё моё время. Пока я не решил, что делать дальше, работаю на себя.
— Насколько я понимаю, 5 или 6 лет назад вы основали Fullstack.io?
— Да, это было в 2012 году.
— Расскажите о нём.
— Fullstack состоит из двух частей, это издательство учебников по программированию, а также образовательная платформа. Что касается издания учебников, наша основная аудитория — профессиональные разработчики, но мы также предоставляем учебники университетам, школам и программам повышения квалификации. Помимо этого, мы проводим тренинги в онлайне и вживую, как правило в рамках повышения квалификации. Мы работаем с компаниями вроде General Electric, Walmart, с вооружёнными силами и так далее.
— Здорово. Конкурируете ли вы с O’Reilly, или у вас совсем другая область?
— Мы занимаемся вещами, во многом похожими на то, что делает O’Reilly, но напрямую мы с ними не соперничаем, потому что у нас совсем другой масштаб — мы не представляем угрозы мировому господству O’Reilly над книгами по программированию. Кроме того, у нас немного другой подход. Обычно книги после издания не обновляются, так что как только вы её прочитали, она уже устарела. Если же вы покупаете книгу у нас, мы предоставляем вместе с ней постоянные обновления.
— Издаёте ли вы бумажные книги, или только электронные?
— И те, и другие. Мы продаём бумажные книги через Amazon, но их обновить невозможно. Электронные же книги, купленные на Fullstack, обновляются автоматически. Через Amazon обновлять нельзя — у них слишком жёсткий контроль.
— Насколько я понимаю, вы являетесь соавтором множества книг на Fullstack.io — Fullstack React, Fullstack React Native и, конечно же, знаменитая ng-book. Чтобы написать книгу, нужно быть очень хорошо знакомым с предметной областью, о которой вы пишете — будь то Angular, React, Vue или что-либо иное. Как выглядит ваша подготовка к написанию книги?
— Хороший вопрос. Давайте я вначале расскажу вам, как я вообще начал писать книги, и почему мне нравится это занятие? А потом перейдём к тому, как идёт работа над каждой отдельной книгой.
— Да, конечно.
— В 2012 году я достиг потолка в той компании, где я работал, и решил, что настало время уходить. Я создал свой стартап — хотите верьте, хотите нет, но это была компания, занимающаяся планированием (scheduling company). Для неё я написал элегантнейший бэкенд на Erlang и Python, кажется, с примесью Ruby. Но хорошего фронтенда не было, поэтому я начал исследовать различные фреймворки и наткнулся на Angular. Это было очень давно, до версии 1.0. Я начал писать фронтенд для своего стартапа, и Angular мне очень понравился, но документация к нему была просто ужасная. Чтобы разобраться в том, как работает этот фреймворк, я начал читать исходники и разбираться в том, как он устроен — так произошло моё близкое знакомство с Angular.
Примерно тогда же меня попросили выступить с докладом про JavaScript в учебном лагере для разработчиков в Сан-Франциско, и тогда я понял, что мне очень нравится преподавать. Поэтому я решил объединить эти два интереса и стал писать мини-руководство по Angular для начинающих. Поначалу я думал, что это будет две или три страницы текста, но в итоге вышло 650 страниц, которые я с годами продолжал обновлять. В конечном итоге я стал автором или соавтором девяти книг. Я преподавал в качестве добровольца на каждом крупном учебном лагере для разработчиков в Сан-Франциско. Я также участвую на добровольческих началах в организациях вроде Women Who Code и проектах Bridge Foundry, и преподаю ElixirBridge. Я даже давал занятия в тюрьме общего режима в области залива Сан-Франциско, и по-прежнему преподаю здесь, в Нью-Йорке.
Преподавание для меня очень важно, оно мотивирует меня больше учиться самому. Преподавая, я не только помогаю другим, я заставляю себя подниматься на новый уровень, чтобы уметь объяснить, как работает та или иная технология. Обычно я готовлюсь, читая исходники, особенно это касается JavaScript. Год или полтора тому назад мы познакомились с Vue, и просто начали изучать исходники, наша работа с Vue принесла нам большое удовольствие. По мере работы я записываю все проблемы, с которыми встречаюсь, все поисковые запросы в Google, все вопросы по документации. В результате мы компилируем огромное и очень подробное оглавление, которое затем при любых изменениях мы обновляем вместе со всей книгой.
— Это происходит автоматически, при помощи обработчиков, которые следят за всей этой информацией в документации?
— У нас есть обработчики, которые отслеживают циклы релиза, но, к сожалению, почти всё остальное — редактирование содержания и изображений — выполняется вручную. У нас есть хуки на Реакт, и у нас выполняются автоматические обновления кода, но содержание приходится обновлять вручную.
— Понятно. Насколько мне известно, вы являетесь соавтором множества книг. Сложнее ли писать книгу одному или вместе с кем-то? Как вы организуете свою работу, как синхронизируете главы?
— Так же, как при совместной разработке приложения, мы используем Git для унификации содержания, так что у нас есть версии и ветки. Написать книгу в соавторстве может быть тяжело, хотя, я думаю, несколько проще в случае с книгами по техническим специальностям, чем по нетехническим. Думаю, сложнее всего обеспечить единый тон для всех разделов, и определить, какие использовать демки. Но, в целом, это не слишком трудная задача. Всё внимание поглощает написание и редактирование, и мы постоянно находимся на связи друг с другом, что существенно упрощает процесс. С годами мы наработали шаблоны письма, которые обеспечивают единство стиля всем нашим многочисленным авторам. И мы всячески стараемся, чтобы наши соавторы писали с нами, а не для нас. Мы позиционируем себя как команду, в которой все работают друг с другом, а не как издательскую компанию, на которую работают авторы. Кроме того, мы все являемся соредакторами для тех книг, которые пишем. Наличие редактора или редакторов помогает обеспечить однородный стиль на протяжении всей книги. Каждый автор редактирует раздел, написанный другим автором.
Что касается инструментов, то мы пользуемся Git, а также простыми текстовыми редакторами и Markdown. Я обычно работаю в Visual Studio Code или Spacemacs — сочетание Emacs и Vim, очень рекомендую, если вы его ещё не пробовали. Кроме того, у нас много собственного софта, который мы написали для компиляции, работы со стилем и предпросмотра книг в реальном времени. Его мы используем прежде, чем публиковать новый релиз или обновление книги. Большая часть наших инструментов написана на JavaScript, TypeScript или Python.
— Пользуетесь ли вы гибкими методологиями наподобие Scrum при написании книг?
— Да, но не слишком активно. Мы проводим своего рода модифицированные stand-up-встречи, но не каждый день, а каждую неделю, или через неделю, в зависимости от темпа работы над книгой. Если я работаю один, то весь мой stand-up заключается в том, что я открываю мой текстовый редактор, но если я работаю с кем-то, то мы постоянно на связи друг с другом через Slack и Google Hangouts.
— А сколько времени у вас занимает написание книги?
— Зависит от того, какая это книга, работаю ли я с соавторами, от скорости фреймворка. Скажем, ng-book я написал за четыре месяца, работая по вечерам и по выходным. Но для меня это совершенно невообразимая скорость, я до сих пор не понимаю, как успел так много сделать. Обычно на одну книгу уходит от шести до двенадцати месяцев.
— Интересно. Вы тратите много времени, работаете с интересными инструментами и процессами, возможно, в соавторстве с кем-либо ещё, затем отдаёте книгу в издание. Когда плод ваших трудов издатель пытается перевести на другой язык, как вы проверяете качество перевода? Я спрашиваю, потому что когда я начинал программировать, я не мог читать техническую документацию по-английски, поэтому я читал много книг на русском — например, перевод Good Parts of JavaScript и самых известных книг O’Reilly. Насколько мне известно, эти переводы были ужасными. Я думаю о том, как к этому должны были отнестись авторы книг, и какой у них мог бы быть способ проверить переводы. Какое в целом ваше мнение о переводах?
— Здесь я могу говорить только о своём личном опыте и о том, как работает Fullstack. У нас много ситуаций, когда мы не владеем языком, на который переводится книга — например, большинство наших книг переводится на китайский, а я по-китайски не говорю. Правда, со временем я научился нескольким словам, у меня для этого специальное приложение, Babbel, при помощи которого я учу иностранные языки. Но в случае с китайским лучше всего переводы у нас получались тогда, когда наш переводчик одновременно был программистом. Благодаря этому при всяких вопросах переводчику проще было задать вопрос нам на английском, и затем правильно перевести ответ на китайский. По-русски я, к сожалению, тоже не говорю. Могу сказать «велосипед» — хотя нет, как слышите, даже этого я сказать не могу. Безусловно, тяжело не знать языка, на котором написан софт. Я это особенно хорошо понимаю, когда смотрю документацию опенсорсных китайских проектов — чтобы хоть что-либо понять, мне приходится копаться в исходниках.
— Похожая ситуация была со Vue. Насколько я знаю, у первых его релизов была довольно плохая документация, а многие issues были описаны на китайском. Насколько мне известно, сейчас обязательным требованием является английский язык.
— Да, это так. Мне повезло, что английский у меня родной язык. Хоть я и не безупречно на нём говорю, с документацией у меня проблем не возникает. Я считаю, что переводы очень важны. Кроме того, мы живём в такое время, когда машинный перевод становится всё более качественным, в особенности благодаря глубокому обучению — это одна из причин, по которым я заинтересовался глубоким обучением. Тем не менее, я не думаю, что для всех этих проблем есть одна панацея.
— Недавно я наткнулся на бурную дискуссию в русскоязычной части Twitter. Одна сторона в споре утверждала, что переводы по определению — зло, потому что программисты обязаны знать английский язык, он — международный язык для всех. Другие говорили, что для джуниоров и тех, кто не очень хорошо говорит по-английски, документацию переводить надо. Есть ли у вас мнение по этому спорному вопросу?
— Мне близки аргументы обеих сторон. То, что я сейчас скажу — это всего лишь моя первоначальная реакция, долго я эту проблему не обдумывал. Возможно, при личной встрече мы сможем более глубоко обсудить эту тему. Мне кажется, что сейчас настолько много кода написано на английском, что избавиться от английского языка было бы крайне сложно. Существуют интернациональные языки — например, JavaScript является интернациональным языком, если вы говорите на нём, то вы можете общаться с любым человеком в любой точке земного шара. Наличие интернационального языка — английского — упрощает нам общение и сотрудничество с разработчиками во всём мире; например, я общался с разработчиками в Индии, Франции, Англии, Китае, Австралии. Конечно, это не вполне справедливо по отношению к людям, которые по-английски не говорят — уверен, если бы я не говорил по-английски, у меня по этому вопросу было бы другое мнение. Кроме того, как я уже сказал — это всего лишь мои первичные размышления, долго эту проблему я не обдумывал и, возможно, завтра моё мнение изменится.
— Да, мы можем обсудить это при личной встрече. Сейчас же давайте поговорим о книгах — они становятся менее популярными, чем раньше, из-за появления таких платформ, как Media, Twitter и так далее. Считаете ли вы, что книги исчезают?
— Я не убеждён, что книги становятся менее популярными. Я считаю, что все работают и учатся по-разному. Онлайн-сервисы по своей функции похожи на занятия в классах. И мне кажется, что онлайн-обучение подходит для разработчиков, которые хотят выучить различные языки и фреймворки по-другому. Некоторым проще работать с документацией, другим — с исходниками, некоторые лучше работают в группах, другие — в одиночку, путём проб и ошибок, или читая книги на поездах и самолётах и затем реализуя прочитанное на практике. С другой стороны, я преподавал в классах, где всё было ровно наоборот и где ученики просто не могли сесть за книгу, это им ничего не давало. Не то, чтобы они вовсе не умели читать, просто они меньше получают от чтения, чем от работы с другими людьми. Думаю, одно из очень важных достижений интернета для программистского сообщества заключается в том, что он сделал обучение более доступным, а успех — более достижимым. Сайты и сервисы вроде Medium или Coursera помогают распространению знаний и делают возможными разнообразные способы обучения. Я горжусь тем, что могу быть причастным к этой эволюции образования. Возможно, в будущем наши книги станут интерактивными, и мы сможем объединить их с онлайн курсами.
— Я помню, что когда-то книги продавали с CD или DVD-диском с примерами. Сейчас такой формат вышел из моды.
— Да, сейчас всё предпочитают отправлять zip-архивами — например, мы объединяем все наши демки в один zip-архив. Один из наиболее полезных разработанных нами инструментов позволяет записать в одном месте весь исходный код, который используется в книге, и затем у нас есть инструменты, которые автоматически обновляют его из оригинальных исходников. Предположим, нам необходимо выделить строку, класс, объект или функцию, которую мы обсуждаем в книге. У нас есть инструменты, благодаря которым можно делать прямые ссылки на исходный код. Это полезно в том числе и потому, что каждый раз, когда вы скачиваете книгу, происходит обновление исходников. Так что мы записываем исходники не прямо в текст, а в отдельный файл.
— Мой следующий вопрос будет связан с предыдущим. Вы сказали, что все учатся по-разному и я, как разработчик, могу для обучения читать книги, смотреть видео на YouTube, читать статьи на какой-нибудь платформе. А вот зачем мне посещать конференции?
— Это хороший вопрос. Навскидку я могу назвать две причины, по которым это стоит делать. Первая — наиболее очевидная: презентации и доклады на конференциях обычно хорошо продуманы и специально предназначены для просмотра. Как правило, такой доклад посвящён чётко определённой проблеме — например, рефакторингу. Когда сидишь в аудитории, где идёт хороший доклад по рефакторингу, то как будто бы проводишь рефакторинг сам, оказываешься включён в презентацию, в процесс. Ну и для меня всегда интересна личность докладчика, его эмоции.
Вторая причина менее очевидная. Я это называю «hallway chat» — помимо собственно докладов вы встречаетесь и общаетесь с людьми, которые занимаются тем же, что и вы. Наша деятельность как разработчиков по определению индивидуальная — но когда вы начинаете общаться со множеством других людей, которые находятся в том же пространстве, что и вы, и занимаются тем же, что и вы, эта деятельность автоматически становится социальной. Другая польза от «общения в холле» заключается в том, что вы встречаете людей, которым нужны ваши услуги, ваши технические знания или преподавательский опыт. По моему опыту, мы находим больше клиентов, чем где-либо ещё — и это касается даже наших книг и наших видео.
— Вы уже написали много книг — скажите, над чем вы работаете сейчас? Может, немного спойлеров?
— Сейчас я в основном занимаюсь блокчейнами. Если говорить о блокчейнах, дополненной реальности, глубоком обучении, то в этих областях здорово то, что они сейчас очень популярны, так что практически на каждой конференции, которую я посещал за последние несколько лет, я вступал в очень оживлённые дискуссии с людьми, заинтересованными этими предметами. Причём зачастую это мог быть разработчик фронтенда в Google, который в своё свободное время занимается другими темами.
Что касается меня лично, то проекты, которыми я занимаюсь, в основном связаны с экономикой — и самое удивительное, что это весьма занимательный предмет. Кроме того, я сейчас работаю над книгой под названием «C++ for JavaScript developers», пока что она находится на ранней стадии написания. Я очень рад буду обсудить эту тему, если встречу на конференции по JavaScript кого-либо, кто работал с С++.
— Эта книга будет как-то связана с WebAssembly? Сами понимаете, С++ и JavaScript…
— Книга в основном посвящена EOS — это довольно новый блокчейн. Он похож на Etherium, но создан при помощи LLVM, а это позволяет писать контракт на чём угодно, что компилируется в LLVM, в том числе на С++.
— Здорово. Давайте перейдём к следующему разделу, он будет более тесно связан с вашим докладом на HolyJS. Вы раньше работали с Angular, Vue, React, JavaScript — а сейчас делаете доклад о Flutter, мобильной платформе от Google, написанной на Dart. Что вас подтолкнуло к этому?
— В такой формулировке это действительно звучит забавно. Здесь похожая история на то, как я пришёл к Angular, о чём я уже говорил выше. Я хотел написать несколько приложений для себя и своих друзей, которые пользуются кто Android, кто iPhone. Мы уже издавали книгу про ReactNative, и у меня был опыт с этой платформой, но хотелось попробовать чего-то другого. Я умею писать на Java, Kotlin и Swift, поэтому я начал писать приложение на Swift. Насколько мне известно, сейчас делаются попытки приспособить Swift для Android, но те, с которыми я знаком, находятся ещё на очень ранних стадиях, рассчитывать на них нельзя. Кроме того, мне кажется, что многие из них — хаки. То есть разработчик привык к iOS и пытается просто перенести свой опыт на Java, или, наоборот, очень хорошо знаком с Java и лезет с ней в iOS. Кроме того, я не хотел расставаться с сообществом JavaScript — у меня с ним наладились очень тесные связи, я мог пользоваться замечательными инструментами вроде Redux, было множество библиотек, при отсутствии которых пришлось бы изобретать велосипед. В результате я решил поискать другой кросс-компилируемый фреймворк и нашёл Flutter.
Flutter написан на Dart, это компилируемый язык, во многом похожий на TypeScript. Он обеспечивает лёгкую интеграцию с библиотеками JavaScript, так что я мог опираться на свой опыт, скажем, с Redux. Другое преимущество Flutter в том, что в нём всё является виджетом, благодаря чему процесс написания приложений становится более быстрым и понятным. А иммутабельность данных делает приложения более безопасными, ошибки обнаруживаются очень быстро. Кроме того, во Flutter есть AOT-компиляция и JIT-компиляция, а множество встроенных виджетов позволяют очень легко создать приложение, пользуясь знакомым UI. Благодаря тому, что вам видно, как работают виджеты во Flutter, вы начинаете лучше понимать, как Flutter устроен.
У Flutter много и других сильных сторон — тестирование, управление пакетами, распределение, компилирование. Одна из самых крутых особенностей Flutter — это hot reload, к которому мы так привыкли в web. Например, когда вы собираете приложение на Swift, вы компилируете, затем запускаете приложение, затем вам, возможно, нужно нажать несколько клавиш, чтобы вернуться к экрану, на котором вы работали, решить возникшие проблемы, после чего весь цикл повторяется. Далее, с Flutter ваш UI всегда будет локализован на том же языке, на каком написана ваша бизнес-логика. Что касается моего опыта с Flutter, то я на нём написал несколько приложений, и я просто в восторге от этого процесса. Ещё нужно сказать, что Dart достаточно похож на TypeScript, который, в свою очередь, похож на JavaScript, так что весь мой опыт с JavaScript напрямую пригодился мне в работе с Dart.
— Но Dart — язык с сильной типизацией, поэтому писать программы на нём так же, как вы пишете на JavaScript, не получится. Что вы думаете о Dart в целом, как о языке? Какие у него преимущества?
— Если быть абсолютно честным, то я считаю, что Dart прекрасен. Мне нравятся языки со статической типизацией — хотя я ничего не имею против динамических языков, из них мне больше всего нравится Clojure. Но у статической типизации много преимуществ, и, мне кажется, из-за них многие разработчики стали переходить с JavaScript на TypeScript — правда, у последнего есть возможность убрать типизацию и позволить компилятору определить типы самостоятельно. У Dart также есть нечто подобное, он выполняет вывод типов, так что в нём не строгая типизация. Тем не менее, преимущество языков со статической типизацией, даже с выводом типов, заключается в том, что их очень быстро можно переводить на другие языки, и ошибки можно обнаружить до запуска приложения. Как я уже говорил, это всё есть у TypeScript и Flow. Компиляция обеспечивает предсказуемость и скорость, во Flutter она происходит в нативный код. Кроме того, как я уже говорил, у Flutter есть JIT-компиляция, что делает цикл разработки значительно более быстрым и простым, и благодаря ней у вас есть очень быстрый перезапуск при разработки приложения на Flutter.
В Dart много других привлекательных вещей — например, область видимости работает значительно проще, чем в JavaScript, вам не нужно “байндить” функции. Классы являются объектами первого порядка, у них эксплицитные интерфейсы, конструкторы именованные — если вы работали на Java, они вам, скорее всего, нравятся. Мне кажется это супер круто, это позволяет нам проще писать на Dart, и потом компилировать его в JavaScript и потом использовать этот JavaScript. Кстати, я вроде бы не упоминал, да, Dart компилируется в JS. Isolates внутри Dart позволяют использовать Web workers вместе с Dart. По-моему, Dart существенно облегчает наиболее тяжёлые аспекты разработки. Помимо этого, у Dart много прекрасных инструментов, замечательные библиотеки для Flutter, время запуска очень небольшое, поскольку код на Dart компилируется напрямую в нативный код, а не как в React Native, где создаётся дополнительная прослойка из JavaScript.
— Десериализация и тому подобное.
— Да. На мой взгляд, сообщество React Native создало много хороших библиотек, но по-прежнему остаётся много трудностей — например, нельзя передавать объекты JavaString, их надо сериализовать в строковые объекты. С Flutter ничем таким заниматься не нужно, потому что компиляция происходит напрямую в нативный код. Наконец, поскольку Dart похож на Java, C#, ActionScript и JavaScript, обстановка, в которой вы пишете, в общем-то знакомая, и вы можете опереться на весь ваш опыт с этими языками.
— В то время как Clojure, например — это нечто совершенно иное. А с Dart уютно, как под одеялком.
— Да, я писал на Clojure — там всё вверх ногами.
— Какие приложения, по-вашему, можно — или нужно — писать на Flutter? Можно ли написать банковский клиент, финансовое приложение или приложение, требующее многих экранов? Или он годится только для того, чтобы написать на нём «Hello World»?
— Пока что меня весьма впечатляет и скорость разработки, и скорость созданных мной на Flutter интерфейсов. Если вы выбираете между нативной разработкой или кросс-компилируемым фреймворком наподобие Flutter или React Native, многое зависит от вашей команды. В правильно спроектированном приложении, я думаю, нет ограничения на количество экранов, которое можно написать — здесь Flutter не уступает другим вариантам. Если у вас небольшая команда, и вам нужно довести ваше приложение до как можно большего числа пользователей независимо от платформы, при этом не жертвуя производительностью вашего приложения в рантайме — однозначно используйте Flutter. Если же у вас много сотрудников, и есть разработчики с большим опытом написания нативного кода, то скорее встаёт вопрос того, как вы будете набирать вашу команду — будете ли вы набирать людей, прекрасно пишущих именно на Java или на Swift, или людей, которые могут написать код и для фронтенда вашего веб-приложения, и для бэкенда на сервере, и для мобильного приложения. И тут, повторюсь, преимущество Flutter для меня в том, что он позволяет писать на языке, с которым я хорошо знаком.
Если отвечать на ваш вопрос более прямо, Flutter прекрасно подходит для приложений, которые отображают некоторое содержание — например, он подошёл бы для Twitter. Иначе обстоит дело, когда вам нужна производительность, которую может дать только нативное приложение, например, в случае с приложениями AR и VR. Единственное моё AR-приложение написано на Swift, и на Flutter я его пока не перевёл. Отчасти это потому, что и на iOS, и на Android очень удобные фреймворки для виртуальной реальности и дополненной реальности.
— Вы упоминали, что Flutter подошёл бы для написания Twitter — но Twitter сейчас написан на PWA. Можно ли сравнивать Flutter с приложениями на PWA? Они тоже кросс-платформенные, и у них много других сходств.
— Насколько я знаю, в будущем можно будет компилировать приложения на Flutter в веб-приложения, пока что этого делать нельзя. Но если вы написали бизнес-логику вашего веб-приложения на Dart, то вы вполне можете использовать её в мобильном приложении. И Dart очень быстрый. Зачастую скомпилированный Dart JavaScript-код будет быстрее, чем код, написанный напрямую в JavaScript.
— Думаю, это несколько спорное утверждение.
— Хорошо, сформулирую это иначе. Довольно часто компиляция кода на Flutter происходит быстрее, чем кода, который вы написали бы напрямую в JavaScript.
— Понятно. Если мы говорим о языках вообще, то существует множество таких, которые можно компилировать в языки на других платформах. Одним из них, конечно, является JavaScript — сейчас можно всё что угодно и для любой платформы написать на JavaScript. Есть и фреймворки такого рода — для Angular это Ionic, для кроссплатформенной мобильной разработки — Cordova PhoneGap. Существует ли один язык, способный удовлетворить все нужды? Возможно, это JavaScript?
— Интересный вопрос. Думаю, дело в том, что JavaScript прост в обучении, поэтому его сообщество быстро растёт, что позволяет генерировать много идей— благодаря этому возникли React Native, Node.js и, отчасти, Dart. Из всех существующих языков JavaScript, по-моему, ближе всего к модели универсального языка для всех платформ. Но лично меня тянет к языкам, созданным на основе определённой идеи — например, мне очень нравятся функциональные языки. Не думаю, что они когда-либо выйдут из употребления. Тем не менее, если вы в 2018 году решили научиться писать на каком-нибудь языке, и не знаете ещё, чем будете заниматься — вебом, мобильными приложениями, бэкендом — то не пожалеете, выбрав JavaScript.
— Но если JavaScript такой замечательный, то почему сейчас возникают новые языки — Go, ClojureScript, Dart? Зачем нужны другие языки, если есть JavaScript?
— А если мне нравятся яблоки, зачем есть другие фрукты? Я сейчас скажу фразу, которую очень часто повторяют в тренировочных лагерях, да и не только там — очень важно, чтобы инструмент соответствовал выполняемой работе. Я пишу много кода на Go, потому что всё, что связано с блокчейнами, я делаю на Go или C++ — там очень важна скорость. А все интерфейсы я пишу на JavaScript или Dart, и иногда я использую ClojureScript. Суть в том, что C в ближайшем будущем никуда не денется, хоть он и довольно старый. Он приспособлен для приложений, которым особенно нужна скорость и хорошее управление памятью. Так или иначе вам придётся мириться с особенностями того языка, на котором вы работаете. Например, сборка мусора всегда будет проблемой для JavaScript, и при написании крупных приложений вам всегда придётся разбираться с ней. Неизбежно приходится жертвовать производительностью в рантайме ради простоты цикла разработки. Мой доклад ни в коем случае не направлен против Swift или Java — как я уже говорил, моё приложение с AR написано именно на Swift, поскольку, с одной стороны, я ещё не портировал его на Flutter, но, с другой, Swift прекрасно подходит для этой задачи.
— Кажется, в 2013 году, когда объявили о создании Dart, вокруг него было много ажиотажа, но потом о нём многие забыли, и сейчас во многих сообществах можно услышать, что Dart умер и больше от него ждать нечего. Что вы думаете о будущем Dart и Flutter, и о будущем Dart отдельно от Flutter? Ведь есть и AngularDart, и Dart для бэкенда.
— Хороший вопрос. Если бы я знал ответ на него, то я сидел бы где-нибудь на тёплом пляже, или на собственной яхте с вертолётной площадкой. Если делать какие-либо предположения, то вначале нужно сказать, что я не вхожу в команду Flutter — я просто энтузиаст проекта и пользователь языка Dart. Думаю, библиотека Cupertino — интерфейс Flutter для iOS — будет расти. И, кажется, команда Flutter хочет добавить возможность писать нативные десктопные приложения на Flutter — но точно я в этом не уверен.
Что касается создания Dart, то, на мой взгляд, о нём объявили слишком рано, и это привело к излишнему воодушевлению и преждевременным надеждам. В 2013 это был год EcmaScript и, я считаю, это был явный перебор со стороны Google, пытаться повлиять на команду ECMAScript. И к тому же Flow и TypeScript с точки зрения типизации в языке, стали более популярны. Я желаю Dart и Flutter всего самого лучшего, в особенности с предстоящим выходом версии 1.0 у Flutter.
Есть проект, который работает так же, как и Flutter, называется Fuse, но он основан на C#. Вот насчёт его будущего у меня действительно есть сомнения. В то же время сообщество JavaScript растёт очень быстро, и, поскольку Dart близок к JavaScript, это будет способствовать интересу разработчиков к Dart и Flutter.
— Здорово, спасибо. Хотелось бы еще поговорить о конференциях. Что в них самое важное для вас?
— Как я уже упоминал, для меня в конференциях самым ценным является «hallway chat». И здесь очень многое зависит от самих участников конференции. Интересное содержание, запоминающиеся докладчики и мероприятия, связанные с конференцией, помогают создать и укрепить сообщество единомышленников. Важно всё, что помогает этому сообществу процветать. И, как я уже сказал, мне нравится ходить на конференции, поскольку они делают мой труд социальным, а не индивидуальным.
— Насколько я знаю, это будет ваша первая поездка в Россию?
— Да.
— Какие ваши ожидания от России, от Москвы и от HolyJS?
— Поскольку кроме Москвы я ничего в России не увижу, первые две части вопроса будут, в сущности, одним и тем же. Как уже было сказано, я никогда не был в России — я в основном ездил в Китай и страны того региона, то есть в Тайвань, Южную Корею. Как я понял из того, что я читал о России, у вас другая культура, вы всё делаете несколько иначе, чем мы, и мне очень интересно будет узнать, как это выглядит на практике. Это одна из причин, по которым мне нравится путешествовать — мне всегда любопытно, как живут другие люди, какие у них приоритеты. В Нью-Йорке своя культура, и всё моё знакомство с российской культурой сводится к получению визы и визитам в местный ресторан. Так что меня ожидает новый и увлекательный опыт, каким именно он будет — я предсказать не могу.
Что же касается HolyJS, то, насколько я знаю, разработчики в России очень целеустремлённые, умные и точные. Я не хочу обидеть кого-либо во Франции или в Англии, но там строгость скорее можно найти в общении, так что я с нетерпением жду серьёзных технических разговоров с серьёзными технарями. Разработчики в России, по-моему, очень крутые, и мне очень хотелось бы поговорить и с вами лично, и с вашим сообществом.
Ну и, конечно, я ожидаю холода в Москве.
— Да что вы, какой холод, -10 или -15 по Цельсию, сущие пустяки.
— Всего-то? Тогда я буду в шортах.
— И в солнечных очках. Если серьёзно, то у нас классные сообщества Dart и Flutter — хотя, конечно, им далеко до сообщества JavaScript. И в обоих случаях скоро заметные мероприятия: HolyJS пройдёт 24-25 ноября, а 1 декабря будет конференция по Dart и Flutter.
— Здорово. К этому времени Flutter выйдет из бета-версии.
Хотя в случае с Flutter код и пишут на Dart, доклад Ари на HolyJS будет рассчитан на людей с опытом в JavaScript: предварительное знакомство с Dart не потребуется. А дискуссионные зоны на конференции означают, что после доклада будет возможность обсудить с Ари всё интересующее: хоть задать вопрос по Angular, хоть дать ему ng-book на подпись. В общем, увидимся 24-25 ноября на Холи!