Недавно ко мне обратился мой коллега со следующим вопросом: «Каковы доступные альтернативы для снижения текущей сложности разработки для нескольких каналов?». Короче говоря, он искал способы максимизировать объем клиентского кода, совместно используемого между iOS, Android и веб-каналами, при этом имея возможность использовать собственные мобильные функции, если/когда это необходимо. Итак, вот ответ, которым я поделился с ним, который, как я думал, будет полезен для более широкого сообщества (не говоря уже о том, что мы любим открывать исходный код здесь, в Microsoft, в эти дни, включая наши внутренние обсуждения).

Первый вопрос, с которого я обычно начинаю: «Что они пытаются построить»? Например, если они требуют выжимания каждого бита производительности, то нативные всегда будут на первом месте.

Второй вопрос, который я задаю: «Каков набор навыков их разработчиков»? Теперь в этом случае они исходят из собственной разработки, поэтому они могут быть открыты либо для C#/XAML, либо для JavaScript (или TypeScript)/CSS/html.

Тот факт, что он добавил слово веб-присутствие, смешанное с требованием консолидированной кодовой базы, делает веб-сайт жизнеспособным вариантом (нам все еще нужно ответить на два вышеупомянутых вопроса). Сегодня в Интернете есть много вариантов (это может быть хорошо или плохо, в зависимости от того, как вы на это смотрите). Итак, давайте обсудим некоторые варианты здесь:

Решения на основе браузера/веб-представления

Фреймворки на основе SPA, такие как Angular 5 (вероятно, это будет Angular 6 к тому времени, когда вы читаете этот пост), ReactJS или даже VueJS, который в последнее время набирает обороты, являются отличными вариантами, поскольку та же самая база кода, используемая для Интернета, может быть интегрированным в собственные оболочки платформы, такие как Cordova и Electron. Cordova включает в себя систему плагинов, которая позволяет вам использовать собственные возможности iOS и Android (вместе с мини-веб-сервером, на котором размещаются файлы внутри оболочки), и электронную систему, которая позволяет вам использовать собственные возможности рабочего стола в Windows/Mac/Linux. Загвоздка здесь в том, что вы все еще используете WebView (причудливое слово для плагина браузера в вашем родном приложении).

PWA — это не фреймворк, а расширение веб-стандартов. Думайте об этом как о расширении HTML5 JavaScript Api. По сути, это дополнение к веб-API под названием Service Workers, которое обеспечивает автономную поддержку, push-уведомления, а также создает собственную оболочку для веб-приложения. Сегодня это сложный бизнес, поскольку разные браузеры находятся на разных этапах своего пути к PWA. Например, PWA под chrome готов к работе в прайм-тайм, как показано в моем недавнем посте в блоге здесь. С другой стороны, Microsoft Edge не будет поддерживаться до тех пор, пока Spring Creators Update и Safari еще не добавили поддержку, и в настоящее время он доступен только в технической предварительной версии Safari для Mac (я полагаю, что они недавно активировали его для своей iOS). Таким образом, стоимость может варьироваться в зависимости от платформы, на которую вы ориентируетесь, но поддержка улучшается с каждым днем, поэтому мы должны ожидать, что к концу года у нас будет солидная история PWA.

WebAssmebly — это опять же не фреймворк, а скорее расширение сети. Он будет сосуществовать с JavaScript и НЕ ЗАМЕНИТ его. Идея заключается в том, что веб-платформа получает новый низкоуровневый формат двоичной компиляции (представьте себе, что это эквивалент сборки для Интернета. Отсюда и название WebAssembly), который лучше справляется с задачами компилятора, чем JavaScript. В качестве дополнительного бонуса вы можете выбрать исходный язык для программирования и преобразовать его в двоичный формат. Так что подумайте о программировании на языках высокого уровня, таких как C++ или C#, которые будут преобразованы в WebAssembly, которые вы сможете загрузить вместе со своим JS-кодом. Вы даже можете взаимодействовать со своим JS-кодом и наоборот. Сегодня его поддерживают большинство основных браузеров.

Таким образом, в целом этот вариант фокусируется на выборе платформы SPA, дополняя ее замечательными новыми возможностями Интернета, такими как WebAssembly и PWA, с дополнительным бонусом интеграции всего этого в родную оболочку, такую ​​как Cordova/Ionic и Electron. Здесь важно помнить, что эти решения позволяют вам написать один раз и развертывать везде (в Интернете, на мобильных устройствах и на настольных компьютерах), но они унаследуют присущие сети ограничения и будут ограничены работой внутри браузера.

Собственные веб-решения (также известные как скомпилированные приложения)

Скомпилированные веб-приложения — это приложения, в которых пользовательский интерфейс и стиль скомпилированы в собственный код. Обычно вы не используете CSS и HTML для пользовательского интерфейса, а вместо этого используете язык разметки, который транслируется в собственный код устройства (в Java и Swift/Objective C). Таким образом, вам будет предоставлен набор компонентов, которые вы можете использовать и которые будут преобразованы в собственные компоненты пользовательского интерфейса. Здесь вы получите доступ к ограниченному набору функций, подобных CSS, чтобы сохранить синтаксис, который вы уже знаете, но за кулисами они предоставляют вам абстракцию, поскольку CSS не используется, а просто предоставляется, чтобы веб-разработчику было проще начать создавать компоненты пользовательского интерфейса. Вы также используете JavaScript для бизнес-логики, которая будет выполняться отдельным потоком, развернутым в скомпилированном приложении.

Первый вариант — это NativeScript, который можно описать как среду выполнения для создания и запуска «нативных» приложений для iOS и Android из единой кодовой базы JavaScript (вы можете использовать Angular или VueJS). Это не Cordova/Ionic и нет WebView. Мы говорим о настоящих нативных компонентах, а не о компонентах на основе Html/CSS/JS. Таким образом, вы не будете писать код, который будет манипулировать элементами DOM, а вместо этого будете использовать XML. Этот вариант требует, чтобы вы изучали XML и JavaScript одновременно, что может быть не для всех. Он изначально работает в ОС, поэтому у вас есть доступ ко всем собственным API. Вы можете вызывать что угодно на устройстве из JavaScript. Вы можете думать об этом как о NodeJS для мобильных устройств. По сути, это движок V8 JS для Android или JavaScriptCore WebKit для iOS, который находится на мобильном устройстве, запускается там и позволяет создавать нативные приложения. Это не кросс-компиляция Xamarin. В NativeScript нет кросс-компиляции. Код, который вы пишете, в конечном итоге работает на устройстве, и у вас есть 100% прямой доступ к Native API. Еще одним преимуществом NativeScript является то, что его можно встроить в любое существующее приложение для iOS или Android, что может быть полезно, если вы уже вложили средства в существующий код, который не хотите переписывать, а вместо этого хотели бы начать разработку новых функций в NativeScript и постепенно мигрировать.

Второй вариант — это React Native, который очень похож на NativeScript, но вместо использования XML для создания компонентов пользовательского интерфейса вы используете формат под названием JSX, который представляет собой смесь JavaScript и XML. Это привлекательный вариант для тех, у кого уже есть опыт работы с ReactJS, так как компоненты будут одинаковыми с одним основным отличием, которое заключается в рендерере (часть, отвечающая за рендеринг пользовательского интерфейса), поскольку вы снова не будете работать с HTML/CSS. Таким образом, вы не будете использовать что-то вроде ‹div› или ‹p›, вместо этого вы будете использовать такие вещи, как ‹view› или ‹text›, которые сопоставляются с реальными компонентами в нативной разработке. Еще одно преимущество React Native заключается в том, что он поддерживает извлечение, которое генерирует проект Xcode и проект Android Studio, что может быть полезно, если вы решите, что собственные веб-решения не для вас, и хотели бы снова вернуться к собственной разработке. Наконец, React Native недавно представил проект под названием React Native for Web, который в основном позволяет вам создавать рендерер, не зависящий от платформы, и, таким образом, позволяет вам использовать ту же кодовую базу для запуска вашего приложения в Интернете, что имеет большое значение, когда дело доходит до писать один раз развертывая везде.

Таким образом, этот вариант фокусируется на использовании ваших веб-навыков для создания собственных приложений со специальными языками разметки для работы с собственным пользовательским интерфейсом. Преимущество здесь в том, что вы получаете доступ ко всем встроенным компонентам устройства, что также означает собственную производительность. Но за это приходится платить, поскольку вы не можете повторно использовать одну и ту же кодовую базу для доставки одного и того же приложения через браузер или рабочий стол. React Native for Web обещает позволить вам повторно использовать одну и ту же кодовую базу для присутствия в Интернете, но на момент написания этого поста он все еще находится на ранних стадиях. На этом этапе вы можете возразить, что собственные веб-решения не так уж отличаются от Xamarin Forms. Это верный аргумент, особенно если учесть тот факт, что вам нужно изучать XML (это другой XML, чем XAML), но главное отличие состоит в том, что вы будете использовать JavaScript вместо C#, что означает, что он более доступен для кого-то. кто более привык использовать веб-технологии, и теоретически вы можете повторно использовать часть этого кода для создания присутствия в Интернете / на рабочем столе.

Резюме

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

* В зависимости от характера приложения, которое вы создаете, это может не иметь для вас значения. Но вы можете почувствовать медлительность в некоторых приложениях.

Первоначально опубликовано на сайте blogs.msdn.microsoft.com 5 апреля 2018 г.