Яков Файн — организатор Princeton Java Users Group, является автором и соавтором большого числа технических книг по программированию, например Enterprise Web Development, (O’Reilly, 2014), Java 24-Hour Trainer (Wrox, 2011).

Специалист Luxoft Training в области Web-, XML- и Java-технологий Вячеслав Лапин (В. Л.) взял интервью у одного из основателей двух стартапов — IT-консалтинговой компании Farata Systems и компании по разработке ПО SuranceBay, Java Champion Якова Файна (Я. Ф.).

В. Л.: Здравствуйте!

Я. Ф.: Добрый день.

В. Л.: Начать хотелось бы вот с чего: в последнее время появляется все больше инструментов в области клиентского программирования. Вы знаете, что чуть ли не каждый день выходит новая библиотека, фреймворк, стандарт…

Я.Ф.: Но я бы обобщил, что есть несколько основных направлений:

Подход «Native JavaScript» — попытки максимизировать использование потенциала, заложенного стандартами от ECMA  и W3C-консорциума . Вы знаете, что время от времени выходят новые версии этих стандартов, появляются новые features, и есть проекты типа JavaScript 6 Shim  и Traceur , которые вкупе с современными средствами разработки, такими как WebStorm, еще до официального выхода стандартов и их реализации в браузерах позволяют пользоваться этим инструментарием. Соответственно, подход состоит в том, чтобы решать задачи в основном с опорой на эти инструменты .

Это было бы очень даже удивительно. Я в 2005 году попал в такую финансовую компанию и был очень удивлен, что один человек сидел за большим белым компьютером Apple, когда все остальные работали на стандартных Windows-машинах. Тогда это было очень странно. А сегодня есть целая политика, есть целая стратегия, какие устройства можно разрешать брать внутренним юзерам, а какие — нет.

Иными словами, я уже говорил, если мы находимся внутри стен одной организации, знаем environment (окружение), то мы можем выбрать один подход. Но даже это, так сказать, не «written stone» (высечено в камне), так как эта политика BYOD тоже может разрешить им приносить свои iPad’ы или Android’ы.

Вторая категория — есть Consumer Facing Applications, то есть приложения, где пользователями являются люди, не находящиеся внутри организации. У них могут быть совершенно любые устройства. И вот тут перед разработчиками уже встает другая проблема — как сделать так, чтобы то, что я напишу, выглядело нормально на всех устройствах, о части которых я сегодня еще даже не знаю. Завтра выйдет iPhone 6 или какое-то небольшое китайское приложение. Подходы совершенно разные.

Ну а теперь, возвращаясь, дам короткий ответ. Вот эти подходы, которые вы обозначили, брать ли обыкновенный JavaScript? Новый стандарт JavaScript 6  — на него можно пока не смотреть, потому что в ближайшие пару лет он не выйдет, а когда он выйдет, браузерам понадобится какое-то время, чтобы его имплементировать. Но уже сегодня ECMAScript 5  поддерживается практически всеми современными браузерами. Под современными я подразумеваю браузеры, которые не старше двух лет. На самом деле в разработке сегодня мы стараемся не принимать во внимание старые браузеры. Например, все, что ниже IE 9, мы даже не рассматриваем, то есть если не будет работать — ну извините, пора бы уже и подтянуться! С другой стороны, что касается фреймворков, о которых вы сказали (jQuery, AngularJS, Ext JS, Backbon.JS), их тоже можно разделить на разные группы. А именно:

Тяжеловесы, такие как Ext JS или Yahoo YUI , который уже прекратили поддерживать, сказали: «все — мы поняли, что это тупик». Тяжеловесные фреймворки годятся для Enterprise-приложений, приложений корпоративных. Ext JS — есть хорошие контроллеры, очень сильные Data Grid, можно формы делать, там есть Charting хороший, то есть можно делать так, чтобы одни и те же данные показывались как pie diagram либо bar diagram. Тут же click on the button, и это уже таблица с циферками. Вот эти все вещи для приложений для корпораций хороши. Минусом же является то, что фреймворк тяжелый. То есть само приложение будет весить много: ваш код + мегабайт. Это много, если это Consumer facing application. Если человек стоит на какой-то медленной сети с мобильником в руках и ему приходит больше 1,5 Мб только, чтобы загрузиться, то это минус. Хотя это rich library — богатая библиотека, в которой есть куча консолей. И если вам это действительно важно — нужно сделать солидное красивое приложение для внутреннего использования в компании. Или так называемое back office operations, то есть для своих юзеров. Да, можно рассматривать эту библиотеку.

В большей части признают легкие. Для легкости используют все-таки другие фреймворки. Для чего пользоваться такими фреймворками, как Angular или jQuery? Во-первых, чтобы упростить себе создание каких-то мелких компонентов, чтобы использовать заготовки, которые уже есть в мире. А во-вторых, чтобы спрятать зависимость от браузеров. Скажем, разные браузеры, может быть, еще не все имплементировали последние feature’и ECMAScript 5, то есть браузер c неполной поддержкой этого стандарта. Эти библиотеки говорят: «Мы от вас спрячем это. Будете работать с нашей библиотекой и не волнуйтесь — поддерживает браузер или нет, — мы будем пользоваться этими feature’ами, ставить специальной загрузкой или еще как-то…»
Вот такой ответ. Я могу еще говорить на эту тему. Но давайте уже перейдем к другим вопросам.

В. Л.: По компилируемым в JavaScript языкам скажите еще пару слов — TypeScript, Dart, другие?

Я. Ф.: Ах да, по языкам. Главный язык — JavaScript. Есть один человек, которого зовут Джефф Этвуд (Jeff Atwood), вместе с Джоэлом Спольски (Joel Spolsky) он создал Stack Overflow. Это популярное место, где программисты собираются и задают друг другу вопросы. И он сказал фразу, которая звучит примерно так: «Все, что может быть написано на JavaScript, — будет написано на JavaScript!»

В принципе, это, конечно, шутка. Но в этой шутке есть доля шутки. Да, действительно, о JavaScript можно говорить все что угодно. Он очень странный, показывает всякие глупости , непредсказуемость неких конструкций. Но «As is what it is» — у нас это есть сегодня, это то, что мы имеем, и это наименьший общий знаменатель для всех приложений. Минусом является что? Резкое снижение продуктивности программистов.

В нашей компании Farata Systems  мы делаем разработку на разных языках, на сервере — Java (базовый, никогда ничего не меняем), на фронтенде мы использовали разные языки, в частности, много лет использовали чудную библиотеку от Adobe — Flex . Компилирующий язык, public client и так далее. Удобно. Хорошо. Наши разработчики были продуктивны. Потом по разным причинам Adobe отказалась от Flex, Apple не хочет поддерживать плагины и браузер-компилятор. Эта технология уходит. И мы стали пересаживать программистов на JavaScript. И сразу увидели резкое падение продуктивности. А у нас работают только Senior-программисты, нет Junior или только начинающих. Мы сразу увидели, что нашим ребятам нужно намного больше времени, чтобы сделать то же самое. Это — большой минус JS.

Конечно, нужно пользоваться фреймворками, чтобы превратить в плюс. Но последний год мы работаем на языке Google Dart. Опять же Dart — очень красивый язык, удобный. Это как бы более умная Java, если можно так выразиться. То есть они смотрели на Java, применили ее, исправили очень много ошибок, сделали все удобно, симпатично. Начали работать на реальном проекте — у нас есть продукт, который мы делаем для страховой компании.

Но когда мы говорим слово Dart, мы должны разделять разработку и production (deployment). Сегодня и еще многие годы это не изменится: на Dart вы разрабатываете, а из Dart генерируется все равно JavaScript, и он запускается в production. Почему? Потому что никакие основные браузеры не собираются поддерживать пока DartVM. У Google есть специальный браузер Chrome , вероятно, скоро и сам Chrome будет идти с DartVM. Другие браузеры не собираются пока его поддерживать и не соберутся. Google это понимает, поэтому генерирует очень хороший JavaScript. Dart — это, по моему мнению и по мнению нашей компании, хорошее направление, куда идти, чтобы сделать разработку на JavaScript более продуктивной.

Некоторые пробовали TypeScript. Но TypeScript — это такое промежуточное решение, которое чуть-чуть лучше, чем JavaScript. А Dart — серьезно лучше! Минус использования Dart — пока еще недостаточная база компонентов UI, которая может быть использована в вашем Dart-приложении. Положительной стороной является то, что в Dart есть библиотека AngularJS, которая на JS написана. Легкая библиотека, MVC и т. д.

А есть уже и AngularDart , во-первых, пишем на Dart, используем AngularDart, и там было мало компонентов. Есть еще такая библиотека Polymer , где все основано на том, что можно создавать компоненты на HTML, то есть из тега можно сделать компоненты, которые потом можно взять, drop’нуть на другой экран и пользоваться там. Это правильное направление, по нашему мнению, и мы идем в эту сторону. Если писать для HTML5 для браузеров, для разных устройств, я бы посоветовал сегодня выбрать Dart с генерацией JavaScript и деплоить в JavaScript.

В. Л.: Спасибо. Тогда следующий вопрос — как раз касательно этой разницы. Как вы оцениваете такой вопрос, который раньше не стоял и появился в связи с ростом популярности JavaScript: строгая типизация — это плюс или минус? И как он влияет на производительность труда программиста? Будущие языки — как они будут разрабатываться — со строгой типизацией или это будут переменные, которым можно будет присваивать любой объект?

Я. Ф.: Ну, этот вопрос можно перефразировать так: «как вы относитесь к острым ножам?» Хорошо иметь на кухне острый нож? Наверно, хорошо. Но вы понимаете, что человек, который только начинает «куховарить», может порезать себе палец? Кого будем винить? Будем винить нож! Правда? Или не нож винить? В этом плане нестрогая типизация — это нож, которым можно порезаться.

Главный минус — программа становится менее читаемой. Конечно, вы можете сказать: «Ну а мне какая разница? Я-то понимаю, я сам написал». Да, но многие могут сказать, что больше времени требуется, чтобы читать чьи-то программы, чей-то код, чем писать свой. Поэтому если Вася Форточкин придет читать программу, которую я писал (а я уже уволился из компании, и это было написано на нетипизированном языке), то Вася очень зависит от меня — от моей доброй воли, от того, насколько я хороший программист, насколько я правильно называл переменные, потому что типов нет. Более того, динамические языки программирования, такие как JS, позволяют на ходу менять структуру объектов. Вот у вас есть какой-то объект, допустим Customer. У него несколько полей: имя, фамилия, адрес и т. д. И никогда там не было поля «Номер телефона». На ходу в программе взяли и прикрепили динамически новое поле и пользуемся. А Вася Форточкин откуда это знает? Он, конечно, разберется, но на это уйдет время. Если вас интересует продуктивность, то строгая типизация намного удобнее.

Так как сегодня большинство программистов — это массовые отряды, батальоны, дивизионы, которые слегка где-то подучились и программируют массовые приложения, т. е. ты не можешь ожидать от них суперэкспертности и большой порядочности в написании кода, для них нестрогая типизация — это вредно. А строгая типизация — это плюс, так как компилятор помогает тебе. Он не дает упасть. Ты написал что-то не то, а он подсказывает, не дает это сделать. Скажем, в нестрогой типизации ты сделал опечатку в названии Property (например, был объект клиент Customer, ты написал Customer.adress с одной буквой d равняется чему-то). Если в строгих языках типа Java тебе бы сказали: «нет такого address с одной d», то в нестрогих — промолчит, создаст новое Property «adress», программа будет как-то работать, а результат не тот, что ты ожидал. Поэтому нестрогая типизация, я считаю, не зло. Но требования к уровню программистов выше, чем к тем, кто пользуется языками со строгой типизацией.

Об этом я всегда говорю (мы читаем разные тренинги). В частности, когда мы обучаем Java-программистов, которые считают себя крутыми («мы знаем Java, multithreading, оптимизированные серверы, параллельные обработки и т. д. JavaScript — это бирюльки…»), на наших тренингах у них, наверно, сначала волосы дыбом встают, насколько сложно писать правильный код на JavaScript. Поэтому на месте программистов со строго типизированным языком я бы не смотрел свысока на программистов с нестрого типизированным языком: им тяжелее, чем вам. Это мое обращение к Java’истам.

В. Л.: Большое спасибо. Вам как эксперту не только по JavaScript, но и по Java должна быть знакома ситуация, когда появился Spring, — он изменил все. Это была революция в Java. Последние лет пять я даже не видел проектов на Java, которые бы не использовали Spring (реализация IoC, AOP). Недавно, когда я познакомился с AngularJS , там я увидел похожие подходы, тоже реализован IoC, некоторые конструкции с аспектно-ориентированным программированием. Я подумал, может, это тоже революция и через пару лет мы не будем видеть ни одного клиентского приложения без использования AngularJS? Как вы считаете?

Я. Ф.: Ну, во-первых, почему выделена именно AngularJS? AngularJS — да, хорошая библиотека. Да, она легкая. Да, она имплементирует паттерн MVC (model — view — control). Да, она позволяет разделить код более удобно на слои — там, где отдельно модели, — там, где данные, отдельно вьюшки, отдельно контроллеры. Да, это хорошая вещь. Да, там имплементировано Dependence Injection и IoC (Inversion of Control), то, что вы говорите, т. е. туда применен голливудский принцип «ты мне не звони, я тебе позвоню». Знаете, когда начинающие артисты в Голливуде ищут работу и обивают пороги агентств, после очередного прослушивания им говорят: «Когда тебе позвонить?» Они отвечают: «Ты мне не звони, я тебе позвоню». Это Inversional Control, т. е. не ты создаешь объект, а тебе он будет дан.

В Spring было сделано то же самое. Сегодня Spring популярен. И популярность его в мире Java часто определяется тем, что в то время (в начале 2000-х годов), к сожалению, Java EE архитектура была сложной. И Род Джонсон (Rod Johnson) создал Spring и имплементацию Dependence Injection. Я бы не сказал, что сегодня нет проектов, которые бы не делались на Java EE. Java EE намного проще. Но, к сожалению, они в свое время испортили о себе впечатление из-за сложности.

Сейчас и Enterprise Java Beans, и Managed Objects Injections, и CDI Dependence Injection — все это очень красиво, удобно. Но люди, которые уже сели на Spring, не видят причин пересаживаться на контейнеры JavaApplication-серверов. Параллель между Spring и AngularJS, наверно, только в том, что и там, и там имплементирован механизм Injections. В Java’вских проектах используется Spring, может не весь, а отдельный модуль, например Spring Security — он добавляется в любой проект, даже если это Java EE проект.

AngularJS тоже хороший фреймворк, но это MVC. Для того чтобы иметь full feature с полным набором фреймворков, нужно не только иметь возможность правильно структурировать приложение с распределением на слои. Там нужны некие компоненты, нужны удобства. Поэтому просто использовать AngularJS не очень хорошо, не мешало бы использовать какую-нибудь библиотеку кнопочек с круглыми краями. Какой-нибудь Goodstrap или еще что-нибудь. Я не хочу сказать, что фреймворк типа AngularJS просто возьмет и будет впереди планеты всей. Я так не считаю. Может быть, он будет один из лидеров, он и сегодня — один из лидеров, но не думаю, что это наше будущее. На сегодня он популярен, сегодня очень много проектов на нем делается. Когда будет полностью чисто сделан проект AngularDart, будет еще лучше. Но это — один из самых популярных фреймворков, и он будет жить и процветать какое-то время. И его изучать полезно сегодня, на ближайшие несколько лет это полезное знание. Но это — не революция.

В. Л.: Да, спасибо. Я хотел поговорить о том, что несколько лет назад появился сервер Node.js. Как вы оцениваете его потенциал с точки зрения рынка интернет-проектов и рынка корпоративных приложений: может ли он в перспективе привести к замене Java-, .NET-языков языком JavaScript на сервере? И как вы прогнозируете его дальнейшую судьбу?

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

Я не считаю, что это правильный подход. Почему? Потому что главная задача при выборе языков программирования — чтобы конечный результат и конечный продукт был оптимальным и лучшим и пользователи его любили. Пользователям все равно, на чем написан продукт. Есть там Java, или JavaScript, или .NET — им абсолютно неважно. Им важно — удобно им или неудобно. Разве, когда вы берете в руки свой Android-телефон или iPhone, у вас есть мысль, на чем было написано это приложение? Нет! Вам оно или нравится, или не нравится. Это самое важное для вас. Это должно быть определяющим критерием. А сказать, что надо пользоваться Node.js только потому, что вы сможете пользоваться JS и здесь, и там, — это все равно, что сказать слесарю: мы придумали вариант, чтоб ты пользовался только отверткой. Другие инструменты тебе не нужны. Ты сможешь отверткой делать все: ты можешь выпиливать, не нужен лобзик тебе, отверткой можно выковырять все, в принципе, тоже. Поэтому я считаю, что программист должен быть сегодня полиглотом и знать несколько языков. И если перед вами стоит задача — ваша задача сделать пользователя HAPPY — СЧАСТЛИВЫМ! А не сделать свою среду удобной: я не хочу ничего изучать, кроме JS, поэтому мне удобно.

Что касается перспектив. Во-первых, Node.js еще не был даже выпущен в продакшен. Весь этот шум, который последний год происходит, — это о каких-то версиях, которые еще не являются «продакшен грейн». Во-вторых, что касается «Node.js заменит Java». В каких-то маленьких проектиках — почему нет? Я видел разные Benchmark. Не разные, врать не буду. Но лучший Benchmark, который я видел, — это тот, где Node.js на сервере в определенных приложениях, которые пытались нагрузить, работал в шесть раз медленнее, чем версия Java этого же приложения. По производительности ему до Java как до неба, пока. Хотя в шесть раз — это уже не так плохо для продукта, который даже еще не вышел. Движок, который, в частности, делает Google , а кроме Google, еще Oracle выпустила JavaScript-движок в составе Java 8 (называется Nashorn)  — это тоже движок для JavaScript. Они довольно быстрые и, несомненно, будут ускоряться. Поэтому определенно будущее у Node.js есть, но это — не наше все. И я к этому отношусь совершенно спокойно — есть еще один язык для программирования на сервере.

Прекрасно!

В. Л.: Спасибо. Сейчас я бы хотел отойти от конкретики и задать более абстрактный вопрос по парадигме функционального программирования. Раньше были такие языки — главным образом Lisp , но потом интерес к ним угас. А сейчас мы видим, как они опять выходят на арену. Мы видим на платформе .NET язык F# , на платформе JVM — язык Clojure , да и в самом Java 8 много заимствований из функциональных языков. Как вы считаете — это просто мода или за этими решениями будущее?

Я. Ф.: Я бы не сказал, что это сиюминутная мода, потому что языки, такие как Lisp, уже очень старые. Не то чтобы он очень популярен, но прелесть функционального программирования заключена в том, что оно проще выглядит. Нет, неправильно. Можно короче написать то, на что нужно много кода в объектно-ориентированных языках программирования. Поэтому программисты опытные, грамотные, которые шикарно разбираются в программировании, считают программирование своей профессией, десятилетиями занимаются этим, любят ее, изучают эти языки, пробуют разные, как вы сказали, Clojure, Scala и другие.

Станет ли это массовым? Нет, не станет. Потому что эти языки сложны для изучения, а тем легионам программистов, которых сейчас производят, это сложно. Если в команде будет несколько человек, которые хотят программировать на Scala, это прекрасно. Они сделают отличный продукт, он будет элегантный и все такое.

Но давайте представим следующую ситуацию. Допустим, я менеджер команды на каком-то предприятии и мне нужно начинать разработку нового проекта. И скажем, есть такой крутой парень Джон Смит — эксперт в Scala. Он приходит ко мне в кабинет, здесь же присутствует вся команда. Он говорит: «Яков, давай делать на Scala, посмотри, ты технический человек, вот так я могу быстро, коротко и элегантно написать код». Я понимаю технические плюсы этого. Но с другой стороны, кроме Джона, у меня сидит Мэри, Маша, Ашот, еще и Шреневаз, еще и Петро. И я все думаю — что? Да, Джон крут. Да, Scala выглядит красиво. Но допустим, завтра Джон Смит уходит на другую работу. И я остаюсь с Петром, Машей, Шреневазом, Ашотом и Мэри. И я скажу: «Извини, Джон, может, классный язык Scala, но пока нет. Может, только отдельный модуль можно написать на Scala. Почему? Потому что мы JavaScript-цех. И твои модули могут исполняться на JavaScript-машине».

Большим плюсом, даже огромным плюсом я считаю тот факт, что в Java были введены эти конструкции для функционального программирования. В Java 8 так называемые Lambda Expressions используются в разных местах, они делают код действительно более элегантным. В чем прелесть функционального программирования? В том, что я тебе — объекту даю поведение, записанное как функция. Я тебе говорю: «Вот ты возьми этот код и его выполни». Это плюс.

Я написал несколько блогов, я работаю над вторым изданием своей книги по Java, которая скоро выйдет. Я написал несколько примеров, которые помогают упростить код. Допустим, в обыкновенном Java иерархия наследования — несколько слоев. А с помощью вот этих лямбд я могу убрать эти слои, я могу брать разные кусочки функционала и передавать их одному и тому же объекту. И он послушно это выполнит. В этом плане функциональное программирование — это шикарно. Я считаю, что это полезно знать, но не думаю, что если ты Java-программист, тебе нужно взять и переучиться на другой язык. Хорошо разберись с Java 8, и будет очень красиво! Ну а если ты чувствуешь в себе больший потенциал — изучай больше. То есть функциональные языки — это плюс, но опять же я не думаю, что это наше все. JavaScript, кстати, тоже функциональный язык.

В. Л.: Да, спасибо. Сейчас в мире приложений для мобильных устройств мы наблюдаем картину, к которой не привыкли в области ПК, когда есть две флагманские платформы Apple и Android и под них нет решений, чтобы писать код универсально. Понятно, что есть PhoneGap , есть jQuery Mobile . Но по факту мы видим большинство приложений, которые написаны на Dalvik или Objective-C. Как вы считаете, почему до сих пор не создано настолько же зрелой универсальной платформы разработки, каковой является Java для персональных компьютеров и серверов, чтобы четко соблюдался принцип WORA  и при этом не страдала производительность? Насколько это следствие технической несовместимости этих платформ и насколько — следствие политики конкуренции Google и Apple?

Я. Ф.: Я бы не назвал это политикой. Ну как можно обвинить Google или Apple в том, что они хотят, чтобы был определенный строгий процесс деплоймента на их платформе, чтобы их приложение продавалось в их магазине? В свое время Apple сказали: «…не пустим Flash». ОК, нехорошо ругались, плакали, нашли решение. Даже на Action-скрипте, который используют флешевики, можно писать приложение, которое потом перекомпилируется специальным компилятором, и его можно продавать в том же самом Apple Store. Разве это плохо? Почему Apple? Не знаю, как у вас, но в Штатах я хожу по улицам и вижу, мне кажется, больше людей с Apple-устройствами, чем с Android. Хотя мировая статистика показывает уже, наверно, другое. Почему? Потому что Apple очень жестко следит за процессом того, что попадает в продакшен, как выглядит приложение. Google, кстати, меньше следит, поэтому там, конечно, полная анархия. Я не считаю это политикой, но, скажем так, куда бедному крестьянину податься? Нативные приложения, которые написаны отдельно на Dalvik, отдельно на чем-нибудь для Apple, — это правильный подход, если вы себе его можете позволить. Например, если вы одиночка, который пишет какую-нибудь игру, вы считаете: это мой продукт, я сам решаю все, сам имплементирую, сам знаю и тот язык, и другой. Шикарно! Пишите нативно! Нативные приложения, как правило, будут всегда выигрывать по сравнению с приложениями общего плана, написанными на одном и том же языке и портированными как-то. Даже если это HTML и JavaScript. То есть вы сможете делать абсолютно точные компоненты, которые будут выглядеть нативно. Которые будут выглядеть так же, как все остальное на этом устройстве. Если вы себе это можете позволить.

Вернемся в корпоративный мир. Я — менеджер проекта. Мне сказали: начинаем внедряться на мобильники. Обычно выбирается какая-то пилотная платформа. Как правило, начинается или с iOS, или с Android. Мы выбрали какую-то, но я всегда думаю о следующем. Хорошо. Вот у меня есть эти же люди (если вы помните их имена: Ашот, Шреневаз, Петро). Я могу их послать на курсы, они выучат Objective-C или что-то такое. Хорошо. Вот мы задеплоимся, пойдем в продакшен. А мне через шесть месяцев нужно делать то же самое приложение на Android. Что, опять их брать тренировать? А они junior. Скажем так, сколько у меня денег в кармане? Сколько я могу нанять программистов, которые будут работать? Есть ли у меня бюджет на то, чтобы сделать две параллельные команды, которые будут делать параллельно и то и другое: одни — нативно для iOS, другие — нативно для Android? Если да — шикарно! Но тоже не очень шикарно. Это значит, у меня будет две базы кода, это значит, что багов у меня будет два набора, а не один. Релизы нужно будет делать, учитывая, что и там и здесь что-то поломалось.

Но крупные компании, которые могут себе это позволить, будут это делать! Наверно, это правильно. Что касается PhoneGap — это так называемые гибридные приложения. Они говорят: «пиши на HTML и JavaScript, есть у вас везде». На самом деле PhoneGap — это такое commercial, т. е. то, на чем Adobe хочет делать деньги. А на самом деле это все базировано на библиотеке, которая называется Cardolla. В свое время Adobe купила разработчиков Cardolla. То есть можно open source написать с использованием Cardolla-библиотеки, а можно использовать PhoneGap и их сервер для того, чтобы написать на JavaScript и HTML5, а потом отгрузить этот код к ним на сервер, и их сервер запакует ваше приложение, написанное на HTML и JS, под несколько платформ (не только iOS и Android) автоматически.

Но недостатками такого подхода является то, что люди говорят, что оно чуть-чуть медленнее, скроллинг будет работать не так, как нативно. То есть все-таки есть разница. Хотя это некое решение. Тот, кто не может себе позволить две отдельные команды, должен писать на одном языке, например на JS или HTML5 с какими-то библиотеками — с любыми. А потом отгрузить все на этот PhoneGap-сервер, сделать Build и отправить. Такое тоже возможно. А некоторые просто сидят, делают одно приложение и запускают у себя на устройстве с использованием… Но опять же здесь развилка. Либо я буду пользоваться отдельными фреймворками для мобильных, как вы сказали, jQuery mobile или Sencha touch например. Но тогда опять будет две версии приложений — одно для десктопов, второе — для мобильников. И надо определять, что человек зашел с мобильника. И есть там такое понятие User screen в HTML header и т. д., а их очень много. Или лучше выбрать другой подход — не пользоваться мобильными фреймворками, а писать все — писать одну базу кода HTML5 и JavaScript. Но есть такая техника — Responsible Design. То есть можно сделать так, что одно приложение будет написано и оно будет грузиться на разные экраны, будет хорошо работать, хорошо выглядеть. Там тоже есть какие-то нюансы. В общем, есть много подходов. Я не думаю, что какой-то выиграет. Если можете писать нативные приложения, пишите для каждой платформы. Не можете — извините!

В. Л.: Спасибо. Следующий вопрос в сторону бэкенда — базы данных NoSQL . Это новая тенденция, которая появилась. Сейчас все больше и больше о них слышно. Может, вы их тоже используете в своей компании? Как вы оцениваете их потенциал и если есть какие-то гибридные решения, то как их использовать?

Я. Ф.: Здесь я могу только одно. NoSQL базы данных занимают очень маленький сегмент у нас в Штатах. Может быть — 5%. Если взять все базы данных, которые используют, все-таки большая часть, подавляющая — это реляционные базы данных. И недостаток для предприятий, для приложений, типичных для Enterprise, — это то, что в них не поддерживается транзакционность, что часто нужно. С другой стороны, я лично ими не пользуюсь. Я смотрел несколько презентаций, читал о них, но не являюсь экспертом в этом деле совершенно. Поэтому мое мнение здесь не очень важное и весомое. У нас в компании есть парень (работает консультантом в крупнейшей финансовой компании), и он работает именно на MongoDB. Его взяли на проект, он ее изучил и пишет для них на MongoDB. Там приложение, где в основном отчеты — Reports. Они делают очень много отчетов. И вот там MongoDB показывает себя очень хорошо, хорошее быстродействие.

Здесь какая-то транзакционность особо не требуется. Опять же почему используется NoSQL? Можно хранить объекты в БД. Не требуется описание структур, как, например, в SQL требуется описание таблиц, колонок и т. д. И изменение структуры меняет все. Здесь этого не требуется. Поэтому я не могу сказать, что у меня есть хороший опыт с mixed solutions, когда используется и то и другое. Недавно был на презентации, где люди делают какие-то open source продукты, где они вообще пишут слой — ты пишешь SQL, язык запросов, но как движок они подставляют NoSQL. Ну OK, есть какие-то гибриды. Опять же я не могу много говорить об этом, так как я не специалист.

В. Л.: Хорошо, давайте в продолжение разговора о структурах данных поговорим о форматах их представления. Традиционный формат — это XML, но в последнее время XML стал постепенно вытесняться JSON . Как вы оцениваете перспективы этого противостояния?

Я. Ф.: Форматы данных. XML уходит, он тяжелый, нужно много писать тегов. И мы стремимся, чтобы количество байтов, которые бегут по проводам, было как можно меньше. Поэтому XML считаю уходящим, и писать приложение, где между клиентом и сервером будет бегать XML, непрактично. То есть его заменил JSON. JSON-формат заменил его почему? Потому что он не такой тяжелый, там нужно писать меньше тегов, а главное — он очень похож на формат написания JavaScript-объекта. Там почти все одинаково. То есть написать JS-объект и написать JSON. Поэтому сегодня на все браузеры (опять же говорю все, если этот браузер не старше двух лет) имеем парсинг JSON, ничего не нужно устанавливать. Поддерживается шикарно! Платформа, которая на backend, поддерживает генерацию и парсинг JSON! И .NET, и Java, и, скажем так, native Java — у них есть специальная поддержка JSON, там она уже внедрена. Не хочешь на этом — пожалуйста, Google сделала библиотеку JSON. JSON — самое популярное, и мы этого метода придерживаемся. Что касается того, чем люди пользуются.

Конечно, Google Protobuff  — это специальный формат, который компилируется, т. е. можно написать объекты на сервере и на клиенте, компилировать их в специальный формат и передавать данные с помощью этого protobuff. Но минусом является то, что нужно кое-что устанавливать для того, чтобы этот protobuff поддерживался на клиенте. Но мы остановились на JSON.

В. Л.: Насколько перспективным вы видите потенциал данного подхода?

Я. Ф.: Это было и в прошлом, и в настоящем — это так называемый Fatclient . Мы это используем постоянно внутри приложения, которое используется внутри Flash player. Написано на ActionSсript. То есть очень много бизнес-логики находится на клиенте. Что касается HTML- и JS- приложений — тут важную роль сыграл тот факт, что можно не перегружать всю страницу, — что называется AJAX. Позволяет больше иметь JavaScript-кода на клиенте, иметь логику там, не надо перегружать страницу, не надо перегружать state-состояние. При выполнении неких скриптов можно положить в какой-то объект промежуточные результаты, затем подтянуть новые данные; страница не перегружается, поэтому следующие скрипты могут использовать это state-состояние, что самое важное для таких rich frontend приложений. Это есть и будет. Вся бизнес-логика не уйдет на клиента. Это однозначно. Особенно на языках типа JS, где можно посмотреть исходники. А часть — да. Что касается еще одной предосторожности — валидация чего-то. Как правило, валидация в Java-приложениях, где есть HTML-код и JavaScript и что-то на backend, делается и там и здесь. Допустим, вы провалидировали данные на клиенте логикой на клиенте (форму заполнили, проверили), нажали кнопку Submit, и данные по проводам побежали на сервер. А может, их перехватили по дороге плохие дяди, плохие мальчики и девочки? Да, и на клиент уже пришло что-то другое. Все равно приходится писать валидацию на сервере тоже, чтобы обезопасить себя. То есть это будет существовать, я не хочу сказать, что это будет только так. Как раньше в 90-х годах самой популярной архитектурой была client-server. На клиенте все считалось, на сервере была база данных и все обрабатывалось. Не думаю, что это вернется в жесткой форме. Будет достаточное количество бизнес-логики на клиенте, но не вся.
Я желаю всего хорошего программистам из России, Украины, Белоруссии. Мы с ними хорошо работаем и дальше будем работать.

В. Л.: Спасибо вам за интервью.

8 декабря 2014 года Luxoft Training приглашает специалистов, пишущих на любых языках программирования, на онлайн-тренинг Якова Файна «Практическая разработка веб-приложений на JavaScript и AngularJS». Вы получите навыки разработки клиентских частей веб-приложений вне зависимости от используемой технологии серверной части. Обучение пройдет в среде, максимально приближенной к реальной.

 

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    5 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии