Современные приложения

  • Статья

Выбор языка для разработки современных приложений

Рэчел Аппель

Рэчел АппельРазработки современных приложений на одном языке в наши дни просто не бывает. Программирование эволюционировало до многоязыковой модели с языками, специфичными для предметной области (domain-specific languages, DSL), на каждом уровне разработки. Например, один из самых распространенных сценариев — применение SQL и C# на серверной стороне и HTML, JavaScript и CSS как языков для создания UI. Вы хотите иметь возможность расширять свои навыки, но попытки работать со слишком большим количеством языков приводят к распылению этих навыков тонким слоем в области каждого языка. Кроме того, вам нужно быстро выводить продукты на рынок, что нередко оставляет мало времени на изучение нового языка и всех его тонкостей, поэтому вполне естественно желание опираться на уже имеющиеся навыки. Создавая приложения Windows Store и Windows Phone, вы можете выбирать из широкого спектра языков для каждого сценария, и хотя бы один из них отлично дополнит ваш багаж. В этой статье я покажу, какие языки подходят в различных сценариях разработки. В дополнение мы рассмотрим варианты, которые нужно оценить и взвесить, и то, как некоторые факторы вроде необходимости доступа к данным или портирования приложения влияют на выбор языка.

Ландшафт языков программирования современных приложений

Вот доступные наборы языков для разработки приложений Windows Store:

  • HTML, JavaScript и CSS;
  • XAML и C# или XAML и Visual Basic .NET;
  • XAML и C++ или DirectX и C++.

Если вы ведете разработки на основе стека технологий Microsoft, то, как минимум, некоторые из этих языков должны быть знакомы вам, и, конечно же, веб-разработчики прекрасно знают HTML и ему подобные языки. Многие из тех же наборов языков годятся и для разработки приложений Windows Phone: XAML с C#, Visual Basic .NET и C++.

Как насчет HTML, JavaScript и CSS для Windows Phone? На момент написания этой статьи единственный способ, с помощью которого вы можете писать HTML в приложении Windows Phone, — использование элемента управления WebView; такой прием обычно можно применяется в гибридных приложениях (мутантах, которые наполовину являются веб-приложениями и наполовину — «родными» для устройства).

Если вы создаете кросс-платформенное «родное» приложение (не веб-сайт) вне экосистемы Microsoft, то языковой ландшафт меняется и сводится к двум вариантам:

  • Java for Android;
  • Objective-C for iOS (с технической точки зрения, вариантов больше, но здесь я рассмотрю только Objective-C).

К счастью, на помощь .NET- и Windows-разработчикам, желающим писать кросс-платформенные приложения, пришла инфраструктура Xamarin. Больше нет нужды в изучении Java (хотя он весьма похож на C#) или Objective-C, язык для разработки под iOS (подробности позже).

Теперь, когда вы четко представляете, какие языки доступны для использования, я рассмотрю, насколько каждый из этих языков легок или труден в освоении.

Обучение новым языкам

Зачастую путь наименьшего сопротивления является лучшим и уж точно самым быстрым. При освоении новых территорий языки, с которыми знакомы вы и ваша группа, — очень важный фактор. Не каждому удается без проблем перейти с одного языка на другой, особенно в случае языков с совершенно иным поведением. Труднее всего начинающим разработчикам, потому что у них обычно не хватает опыта в работе с разными языковыми парадигмами, а значит, они чаще допускают ошибки или просто не знают о распространенных подвохах. Даже опытные разработчики, переходящие с компилируемого языка вроде C# на интерпретируемый JavaScript, могут попадать впросак, не подозревая о каких-то тонкостях нового для них языка, например о другом поведении ключевого слова this или о мириадах прочих странностей JavaScript.

К счастью, веб-разработчики по-прежнему имеют дело с теми же HTML, CSS и JavaScript, как и в любых клиентских веб-проектах, но разница проявляется при написании программ для Windows 8 из-за дополнения в виде Windows Library for JavaScript (WinJS). WinJS упрощает создание «родных» приложений на веб-языках для Windows 8. Продолжая использовать те же открытые стандартные API, как и в обычной веб-разработке, вы работаете и со специфическими для Windows библиотеками для доступа к «родной» функциональности.

Разработчики, привыкшие к веб-языкам, обнаружат, что HTML-элементы управления в приложениях Windows Store являются просто элементами, помеченными атрибутами data-win*. Использование этих атрибутов позволяет с помощью WinJS-кода и CSS превратить такие элементы в красивые UI-виджеты, обеспечивающие полноценную пользовательскую среду, родную для устройств. WinJS-код, который визуализирует элементы управления, содержит CSS-правила, определяющие «буквы и дух» современного UI в Windows 8. Базовый WinJS-код также создает более сложные элементы управления вроде средств выбора дат и сеток в период выполнения и позволяет добавлять HTML-элементы, связываемые с JavaScript-массивами или объектами.

XAML-разработчики из обоих лагерей — Windows Presentation Foundation (WPF) и Silverlight — по-прежнему будут писать тот же декларативный XAML для разметки UI наряду с сопутствующим компилируемым кодом на C#, Visual Basic .NET или C++. Как и следовало ожидать, в XAML появились новые библиотеки и пространства имен, созданные специально для поддержки современной функциональности Windows 8.

Между декларативными языками (т. е. любым «ML»-языком) в значительной мере существует паритет в отношении количества и качества UI-элементов управления. В целом, если вы видите какой-то элемент управления в XAML, то скорее всего он есть в HTML или в библиотеке WinJS и наоборот; однако между ними найдется одно-два различия.

XAML-разработчики едва ли заметят особые отличия за исключением некоторых пространств имен и других тривиальных изменений. Expression Blend по-прежнему является отличным инструментом для дизайна UI в XAML, тогда как Visual Studio лучше всего подходит для языков, компилируемых «за кулисами». Вокруг XAML-элементов управления UI существует обширная сторонняя экосистема, например сетки для XAML на платформе WPF, и многие из этих элементов управления работают одинаково или сходным образом в приложениях Windows Store и Windows Phone.

Наконец, если вы используете Windows Forms, пора осваивать XAML, так как у вас практически нет другого выбора. Сравнимого UI-языка, который вы могли бы задействовать, нет, потому что дизайнер Windows Forms полностью опирается на C# или Visual Basic .NET. Хотя можно расширить общие навыки в области .NET и ее языков, вы должны изучить DSL для UI: XAML. Вы могли бы освоить HTML, но этот мир требует добавления CSS и JavaScript, поэтому в таком случае вам пришлось бы изучать целых три языка, а это грандиозная задача.

На выбор языка влияет необходимость доступа к данным

В разных языках вы по-разному обращаетесь к данным (отличия иногда очень значительны), и вид данных, с которыми вы имеете дело, определяет и то, как осуществляется доступ к ним. Начнем с того, что некоторые методики доступны только в одном или другом наборе технологий, как в случае с Web Storage (также известным под названием «DOM Storage», о котором вы можете узнать больше в моем блоге в статье «Managing Data in Web Applications with HTML5 Web Storage» по ссылке bit.ly/lml0Ul) и IndexedDB — обе эти технологии можно применять лишь в языках на основе браузеров, например в JavaScript.

Microsoft Azure Mobile Services (о ней можно подробнее узнать в другой статьей из моего блога — «Use Microsoft Azure Mobile Services to Power Windows Store and Windows Phone Apps» по ссылке bit.ly/15nhO8d) и платформа Microsoft Azure предлагают несколько «родных» API для всех популярных платформ, а также REST API, который изначально является кросс-платформенным. Поскольку REST — открытый стандарт, вы можете обращаться к его данным из любого языка, откуда угодно и в любое время через единообразный интерфейс. REST-интерфейсы упрощают кросс-платформенную разработку, так как, несмотря на синтаксис и некоторые языковые выверты, соответствующий код получается в целом согласованным. Такие открытые API, как предоставляемые Twitter, Facebook, метеорологическими сервисами и др., обычно возвращают JSON или XML (или и то, и другое), которые можно использовать через REST или XMLHttpRequest (XHR).

SQLite — вариант с локальной базой данных, доступный на всех платформах и в любых языках. SQLite устанавливается в Visual Studio 2012 как NuGet-пакет для приложений Windows Store и Windows Phone. Вы также можете получить доступ к этому пакету через инструментарий Xamarin и использовать его библиотеки для обращения к базам данных SQLite в iOS и Android. SQLite проще использовать с XAML-приложениями, чем с HTML.

Доступ к файлам и файловый ввод-вывод на платформе Windows полностью эквивалентен в приложениях Windows Store на основе XAML и HTML, поэтому конкретный язык на самом деле не имеет значения, когда вашему приложению требуется чтение и запись в файловой системе. Хотя обычный HTML и JavaScript в браузере имеют много ограничений на операции файлового ввода-вывода и обращения к системным ресурсам, модель разработки приложений Windows Store обеспечивает более чем достаточный доступ к файловой системе, не нарушая безопасность.

Полное описание технологий доступа к данным в приложениях Windows Store и Windows Phone см. в моей рубрике за март 2013 года «Data Access and Storage Options in Windows Store Apps» (msdn.microsoft.com/magazine/jj991982).

Соображения по кросс-платформенным приложениям

Objective-C синтаксически отличается от других языков да и работает иначе, тогда как Java и C# ведут себя аналогично, поскольку это управляемые языки. Однако, если вы пишете кросс-платформенные приложения, вы вовсе не обречены на создание раздельных кодовых баз, например с кодом на Objective-C для iOS, Java для Android и C# для платформ Windows, потому что ранее упомянутый инструментарий Xamarin позволяет легко писать код на C#, а потом генерировать на его основе код на Java и Objective-C. Xamarin предоставляет набор средств для генерации «родного» кода при разработке для разных аппаратных платформ (т. е. мобильных устройств и планшетов), и это лучшая инфраструктура для кросс-платформенной разработки с использованием специфичной для устройств функциональности. В итоге разработчики практически с любой платформы могут легко задействовать свои навыки на платформе Windows или воспользоваться Xamarin и C#. Разработчики на платформах iOS и Android без проблем перейдут на C#, если захотят публиковать свои приложения и на платформе Windows. Но заметьте, что некоторые разработчики в Редмонде с этим не согласны, заявляя, что создавать библиотеки удобнее на C++ и C, так как они доступны в приложениях iOS (напрямую) и Windows (через компоненты Windows Runtime, или WinRT). Они обращают внимание на то, что такой подход не требует дополнительных расходов (большинство инструментов Xamarin стоят денег) и более производителен, чем сторонние средства. Я предпочитаю просто создавать компоненты Xamarin, потому что время выхода на рынок важнее, чем пренебрежимо малый выигрыш в производительности; к тому же я не люблю C++.

На выбор языка влияет необходимость портирования кода из унаследованных кодовых баз

Не все приложения создаются с нуля или полностью переписываются. По сути, чаще всего мы имеем дело с унаследованными программами, особенно если код пишется для корпоративных приложений. Многие приложение на самом деле являются частью более крупной экосистемы программного обеспечения, состоящего из множества приложений и UI, взаимодействующих с бизнес-логикой, уровнями сервисов, открытыми API или библиотеками.

Перенос веб-приложений может оказаться особенно сложным, так как зачастую нужно сохранить нетронутым контент существующего веб-сайта, параллельно интегрировать тот же контент в клиентское приложение и придать ему внешний вид, соответствующий принятому на данной аппаратной платформе. Дело в том, что требования бизнеса очень часто диктуют, что исходный веб-сайт и/или архитектура системы должны остаться неизмененными. Это может привести к тому, что «буква и дух» приложения будет отличаться от таковых в операционной системе, ухудшая удобство в использовании и даже блокируя естественный рабочий процесс, выполняемый пользователем. К счастью, если вы переносите существующий веб-сайт или приложение, у вас нередко имеется вариант с интеграцией. Если это так, вам может помочь инфраструктура Apache Cordova (ранее называлась PhoneGap). Cordova позволяет создавать гибридные веб-приложения с родным для конкретной платформы UI за счет интеграции веб-контента и «родных» UI-компонентов и последующей публикации на разных платформах. В противоположность этому интеграция веб-контента с «родным» приложением Windows Store на основе WinJS не составляет трудностей. «Родные» приложения более тесно интегрируются с ОС, чем клиентские веб-приложения, поскольку у первых есть доступ к ресурсам современного аппаратного обеспечения, например к камерам, микрофону, аппаратным настройкам, акселерометрам, средствам геопозиционирования и т. д. В дополнение к этому у «родных» приложений другой жизненный цикл, и они содержат состояние, тогда как веб-приложения не поддерживают состояние и обладают меньшей функциональностью.

Область применения приложений — один из важных факторов

Тип и область применения вашего приложения в какой-то мере определяют выбор языка. Сильно нагружающие устройство игры и графические приложения просто требуют применения высокоэффективных языков вроде C++ и использования DirectX (который теперь является частью Windows SDK), поскольку только они приближают вас к аппаратному обеспечению, выжимая из него максимальное быстродействие и обеспечивая более эффективное управление ресурсами устройства. DirectX — это полный набор близких к «железу» API, к которым можно обращаться через C++ для создания впечатляющих игр и приложений. Недостаток C++/DirectX — сложный код, в котором легко насажать ошибок и создать кучу проблем. Однако C++ — не единственный выбор для программирования игр. Для многих игр, особенно на холсте, прекрасно подходит JavaScript (да, JavaScript). Исполняющий контейнер приложения Windows Store переносит нагрузку по обработке скриптов на графический процессор, поэтому JavaScript может выполняться параллельно и независимо от разметки, сделанной механизмом Trident. Эта концепция делает JavaScript по настоящему быстрым языком, который может работать не медленнее «родного» кода. Если вам крайне важна производительность, но вы не хотите изучать C++, используйте HTML-холст и программируйте на JavaScript.

Если вы пишете бизнес- и офисные приложения, то обычно можете выбирать любой подходящий язык. Такие приложения, как правило, по большей части требуют заполнения форм и работы с данными.

Как насчет F#?

Удивляетесь, что случилось с F#? Хотя F# не является одним из основных языков в разработке приложений Windows Store и Windows Phone, вы можете ссылаться на компоненты, созданные на F#, и эффективно использовать их. Кроме того, это превосходный язык для аналитики и выполнения кода на серверной стороне, которая нужна очень многим приложениям.

Веб-разработчики часть используют смесь CSS для применения стилей к HTML и JavaScript, на основе которых строятся современные UI. Разработчики «родных» приложений имеют эквивалентный набор языков для тех же целей, так что выбор языка остается за вами — важно учесть все факторы, которые могут повлиять на этот выбор.

Рэчел Аппель (Rachel Appel) — консультант, автор, преподаватель и бывший сотрудник Microsoft более чем с 20-летним опытом работы в ИТ-индустрии. Она выступает на важнейших отраслевых конференциях, в частности Visual Studio Live!, DevConnections, MIX и др. Эксперт в области разработки приложений для бизнеса на основе стека технологий Microsoft и открытых стандартов Web. Если вы хотите узнать о ней больше, посетите ее сайт rachelappel.com.

Выражаю благодарность за рецензирование статьи экспертам Эрику Шмидту (erschmid@microsoft.com) и Джону Кеннеди (jken@microsoft.com)