[Из песочницы] Натив умер. Да здравствует натив!
1. Вместо предисловия «Король умер. Да здравствует король!» — все мы слышали эту французскую фразу, которая как бы разделяет эпохи правления монархов. Все! — кажется нам, — со старым покончено, теперь все будет по-новому, по-другому. Но так ли это? В этой статье я затрону тему нативных приложений, точнее их вымирания… или, быть может, просто их перевоплощения? Решать только Вам. Да-да, я знаю, что рискую выглядеть ретроградом, занимая непопулярную точку зрения. Тем не менее, мне хочется найти хотя бы немного единомышленников, которые согласятся с моими рассуждениями, ну и, конечно же, получить обоснованную критику.
Итак, нативные или как их еще называют, десктопные приложения — это особые программы, которые были разработаны под конкретную ОС (операционную систему) и имеют такое свойство, как «совместимость». Признаюсь сразу: да, я разработчик подобных приложений. Впрочем, специфика моей деятельности (разработка CMS для интернет-магазинов) требует также отличных знаний и веб-технологий.
Как по мне, то значительную часть рабочего времени программиста можно разделить на две оставляющие: поиск решения и поиск инструмента. Думаю, многие заметили и знают, что чем лучше инструмент пригоден для выполнения какой-то задачи, тем менее он универсален для решения широкого спектра задач. То есть, нет идеального языка, технологии и т.п., и поэтому мне, как и многим из Вас, приходится периодически отвлекаться от насущных проектов; изучать, какие появились новые инструменты на рынке; принимать стратегическое решение о том, что я буду изучать завтра. К примеру, ведь может уже давным-давно никто не пользуется отверткой для закручивания шурупов, а использует шуроповерт, или вовсе перешел на новую технологию «дюбель-гвоздь».
В этом то и заключается моя личная дилемма: вроде как пора переходить на полноценную HTML-разработку, но, увы — нет, я все еще крепко стою одной ногой на нативе. Нерешительный? А может, я просто уже не настолько молод, чтобы опрометчиво кидаться на амбразуру трудностей? Проверено — с возрастом человек становится более прагматичным. Вот и мне уже плевать на то, что просто модно, плевать мне и на мейнстрим, я никогда и ни за что не хочу делать «потому что так делают многие», успехов им, но если они не привели толковых убеждений, то фактор количества просто нивелируется мною.
Как программист и предприниматель я хочу выполнить свою задачу, причем хочу сделать это результативно, быстро и практично. Однако, очень многие компании хотят, чтобы я это сделал с помощью их инструмента. Это бизнес, ничего личного, я и сам такой: хочу, чтобы сайты делались на моей CMS, а Вы наверняка хотите, чтобы только на Вашей. Обратите внимание на суть: идея продвижения своего бренда как средства достижения цели очень интересна и выгодна. Такие компании-разработчики технологий-стандартов получают «карт-бланш» — право на удачные и неудачные решения, ошибки больше не убивают в одночасье всю технологию или программный комплекс, а позволяют сохранить коллектив разработчиков до лучших времен. А что касается текущих просчетов, то их можно компенсировать за счет своих постоянных потребителей: ну подумаешь, новый шуруповерт тяжелый, следующая модель будет легкой!
Вобщем, я закончу эту мысль, подытожив: очень мало кто из нас пишет на машинном коде, так что смиритесь, все мы управляемые, и нами давно манипулируют (если задето самолюбие, то читай: за нас борются, нас завлекают). Это я к тому, чтобы у Вас не было иллюзий типа «я пишу на самом правильном языке или использую самую оптимальную технологию». И как на любом рынке, здесь действуют обычные правила: побеждает тот, кто имеет наилучшее сочетание — возможности продукта + убедительность продавца. Однако, в отличие от обычного потребителя, который покупает планшет или автомобиль, мы с Вами в случае совершения ошибки (неоптимального выбора) понесем очень существенные потери — годы жизни, а годы жизни в программировании стоят очень дорого! Именно поэтому критически важно разделять эти два фактора, чтобы уверенно следовать своим курсом, а не болтаться, как маркитантская лодка, подгоняемая переменчивыми ветрами маркетинга, на волнах мейнстрима.
2. Дилемма Итак, передо мной стояла задача: сделать CMS для управления интернет-магазином. Я решил трезво составить список всех «за» и «против» нативных и веб-приложений, который и выношу на Ваше рассмотрение. Единственное, что перед этим будет правильно оговорить, что я конкретно подразумеваю под «нативом» и «веб-приложением».Нативное приложение
Бинарное, скомпилированное приложение, написанное на языке высокого уровня, который был разработан под конкретную ОС. Использует интерфейсные объекты ОС для взаимодействия с пользователем. Инкапсулирует в себя возможности других нативных приложений работающих под этой ОС. Приложение является клиентским, то есть, производит лишь часть работы, обмениваясь данными с другим приложением на другой ОС посредством сети Интернет. Пример языков разработки: С++, Java, C#, Delphi, Visual Basic Веб-приложение
Интерпретируемый код, который выполняется «на лету» бинарным, скомпилированным приложением (написанным на языке высокого уровня, который был разработан под конкретную ОС). Это приложение называется браузер. Использует интерфейсные объекты браузера для взаимодействия с пользователем. Имеет доступ к специальным функциям браузера, обеспечивающим динамическую работу страницы. Приложение является клиентским, то есть производит лишь часть работы, обмениваясь данными с другим приложением на другой ОС посредством сети Интернет. Пример языков разработки: HTML (XML, XHTML), CSS, JavaScript Показатель Нативное приложение Веб-приложение Универсальность Не универсально. Не подходит для продукта массового пользования, который должен использоваться на как можно большем числе устройств, работающих под разными ОС. Универсально (относительно). Хотя браузеры и имеют свои особенности, тем не менее в большинстве случаев приложение будет выполняться на большинстве устройств работающих под управлением различных ОС. Интерфейс Стандартизирован. Основан на объектах ОС (кнопка, поле ввода, дерево, таблица и т.п.), которые применялись не один десяток лет и привычны пользователю. Не стандартизирован. Есть аналогичные объекты (кнопка, поле ввода и т.п.), но это не объекты ОС, а схожие объекты браузера и их значительно меньше. Большая часть объектов реализуется разработчиком самостоятельно. Производительность (интерфейс) Максимальная. Компилируемый код, оперирующий с объектами ОС. Приложение получает доступ ко всем ресурсам ОС, может использовать высокопроизводительные библиотеки-модули, разработанные на языках низкого уровня. Средняя или низкая. Приложение интерпретируемое и работает в бразуере — надстройке в ОС, поэтому имеет доступ только к ресурсам браузера. Ключевым показателем при выборе браузера до сих пор является его скорость работы, что подтверждает актуальность вопроса. Производительность (данные) От высокой до низкой — зависит от реализации. Если приложение небольшое и оперирует с малым количеством данных, то скорость работы становится неотличимой от веб-приложения. Однако, если объем данных большой, то реализуется пакетная работа с данными. Для этого используются ресурсы ОС, позволяющие организовать локальную базу данных. Правильно спроектированное приложение с лихвой компенсирует затраты времени на загрузку пусть даже избыточного количества данных за счет более редких сеансов связи с сервером. Средняя или низкая. Приложение проектируется так, чтобы работать с минимальным количеством данных, чтобы не перегружать ресурсы браузера. Из этого вытекает необходимость частой работы с данными (прием/передача). Это приводит к повышенным требованиям к каналу связи: скорости и стабильности соединения. Если скорость современного Интернета высокая, то стабильность канала, плюс потери времени на соединение (перед отправкой каждого пакета данных) остаются по-прежнему на среднем, а в регионах на низком уровне. Комфортность разработки Высокая. Основные ОС далеко не молодые, они имеют ряд мощных SDK, позволяющих комфортно программировать на языках высокого уровня. Многие языки писались основательно, их ООП-модель заложена с самого их рождения. Очень важна возможность использования большого ассортимента библиотек-модулей, которые могут быть реализованы на других языках в том числе и низкого уровня, обеспечивая таким образом наиболее практичное (читай менее «глючное») решение своей узкой задачи. Средняя. В основе веб-приложений лежит сразу несколько языков: HTML+CSS, JavaScript. И тут есть проблемы. Первая (более-менее решенная) состоит в том, что серверным скриптам долгое время вменялось генерировать HTML-код который визуализируют браузеры. Это оказалось очень неудобно, поэтому сейчас все стараются передавать только данные (XML, JSON). Но тут есть следующая проблема: ни HTML с его CSS, ни JavaScript не были для этого созданы. На сегодняшний день нет единой признанной среды в которой можно легко и просто разрабатывать веб-приложение. А теперь посмотрите, как интересно получается: разработка серверных скриптов, отвечающих за подготовку данных, по сути ничем не отличается как для нативных приложений, так и для веб-приложений. Ведь, как я уже упомянул в таблице, общая тенденция такова: вынести HTML-код за рамки скриптов и передавать\принимать данные в формате XML или JSON. Таким образом, задача клиентских приложений — принять данные, визуализировать их, получить новые данные и передать их на сервер. И здесь я хотел бы поделиться с Вами своими наблюдениями. Поскольку я свободно разрабатываю оба типа приложений, то я увидел определенную аналогию. Посмотрите внимательно на несколько файлов, приведенных ниже:
Нативное приложение (файл описания формы) Веб-приложение (файл описания страницы) object Form1: TForm1 Left = 592 Top = 128 Width = 336 Height = 260 Caption = 'Заголовок' object BSubmit: TButton Left = 92 Top = 140 Width = 75 Height = 25 Caption = 'Submit' TabOrder = 0 end object EName: TEdit Left = 72 Top = 76 Width = 121 Height = 21 TabOrder = 1 Text = 'Ваше Имя' end end
Заголовок
Нативное приложение (файл с программой) Веб-приложение (файл с программой) procedure TForm1.BSubmitClick (Sender: TObject); begin Application.MessageBox ('hello', 'Sample'); end; $(document).ready (function (){ $(»#submit»).click (function () { alert («Hello world!»); }); }); Сравнивая их, Вы увидите, что современное веб-приложение есть не что иное, как старый добрый натив, а веб-браузер в этом случае выступает как ОС. На эту тему есть хорошо известная среди пользователей ОС Windows шутка (а может и не шутка): «Последняя версия браузера Google Chrome обновится до Google Chrome OS». Именно поэтому, я и назвал статью «Натив умер. Да здравствует натив!» Как оказывается все новое, это хорошо забытое старое. Единственное, что старое мне хорошо известно и имеет ряд преимуществ, так почему же я должен безоговорочно поверить в новое?3. В остатке Что же из всего этого следует? Если Вы разрабатываете массовое приложение для широкого потребления, то Вам, конечно же, лучше использовать веб-приложение. Только не забудьте построить его работу таким образом, чтобы одновременно работа осуществлялась с достаточно небольшой порцией данных. Это позволит Вашему приложению работать достаточно быстро.Если Вы разрабатываете специализированное приложение (например, как я — CMS для интернет-магазина), то задумайтесь, возможно, нативное приложение будет более эффективным решением. Во-первых, Вы пишите специализированный продукт, а это значит, что для работы с ним пользователю придется подстраиваться в любом случае: производительный ПК, хороший монитор, нужная ОС и, конечно, производительная программа. И он готов это сделать без проблем, так как понимает, что вкладывается в технологию, чтобы опередить конкурентов. Во-вторых, интерфейс все-таки достаточно привычен и ускорит процесс знакомства с приложением. В-третьих, у Вас как у разработчика больше возможностей. Такие ОС, как *nix, Windows, MacOS существуют продолжительное время, и очень много программистов разработали и довели до совершенства свои программные продукты — отдельные библиотеки.
Поэтому на сегодняшний день, я подчеркиваю, на сегодняшний день, я вижу, что у меня и у Вас значительно больше возможностей при реализации нативного приложения. Да, конечно же, нельзя забывать про перспективу, но лично я не готов тратить свое время, чтобы продвигать сырые технологии, или же, во всяком случае, мне за это должны хорошо платить. Если у Вас (у Вашей компании), есть инвестор, и он сказал, что слышал «голос свыше», и надо разрабатывать на том и том, то да, зачем ему перечить? А вот если Вы делаете проект, вкладывая свои кровные и свое время, в проект, который должен быть завершен как можно быстрее и нацелен на максимальную конкурентоспособность, то задумайтесь!
Вот я и подошел к тому моменту, чтобы обсудить то, что, по-моему мнению, будет справедливым и честным по отношению ко мне, как разработчику. Хоть я и достаточно сурово пишу здесь про веб-приложения, тем не менее, я не отвергаю их. И это очень важно, я хотел бы акцентировать внимание на этом. Это не просто слова, в своих продуктах я использую и веб-приложения, совмещая их с нативными, но это уже тема отдельной статьи. Сейчас же я хочу остановиться на том, что мешает мне уверенно стать на путь технологий веб-приложений:
Прежде всего, браузер — это не ОС. Того богатства приложений-библиотек, которые могут работать под ОС, браузерам не реализовать еще долго, очень долго. Конечно, возможно, некоторые из этих программ отомрут со временем за ненадобностью, но, с другой стороны, есть такие программные средства как СУБД, которые разрабатываются и совершенствуются не одно десятилетие и продолжают активно развиваться. Да, конечно, все возможные апплеты, помогают расширить функции браузера, но они просто несопоставимы по своим возможностям и стабильности работы. До сих пор многие ведущие IT-компании, в том числе и ярко выраженные интернет-компании Yandex, Google, имеющие и продвигающие собственные браузеры, разрабатывают нативные приложения которые используют локальную СУБД, чтобы ускорить работу с большим массивом данных. Странновато как-то, по всей видимости SQLite или Web SQL Database — не для них… Мне необходима быстрая, удобная и стабильная среда для разработки web-приложения. Да, есть попытки создания редакторов, но все они пока в зачаточном состоянии. По сути, разработка HTML-кода и JavaScript-кода происходит раздельно и не согласованно, отладка их очень затруднительна. Здесь тоже есть выход, и, по-моему, мнению, он будет заключаться в том, что браузер должен будет при нажатии кнопки F12 становиться не только отладчиком, но и полноценной средой для визуальной разработки. 4. Немного философии Есть такой закон природы, некий «инстинкт самосохранения»: пока Вы добиваетесь успеха, Вы готовы сломать любые правила, но когда Вы добились успеха, то Вы устанавливаете правила и следите за тем, чтобы другие (проигравшие) выполняли их. Поэтому компания, которая выиграла долю рынка за счет какой-либо инновационной технологии, будет всячески стремиться монополизировать ее и пытаться сделать ее общим стандартом (законом, который будет подчинять других). Мощнейшее средство в этом процессе — маркетинг.Кстати, многие думают, что искусный продавец, это человек или компания, который (ая) пытается продать Вам что либо, рассказывая о достоинствах продукта. Ребята, такой стиль это прошлый век, и удел восточного базара. В современном мире продавцы очень сильно эволюционировали, во многих случаях Вы даже не знаете кто является продавцом, Вы вообще не осознаете, что происходит процесс покупки, принимаемое Вами решение кажется Вам абсолютно логичным и последовательным, а расходы, связанные с ним просто неизбежными.
Таким образом, в ИТ-сфере, для контроля ситуации лучше всего подходит именно своя платформа с нативными приложениями, которые тем самым продвигают и саму платформу. «Стоп. А как же тогда с HTML? Ведь его все стараются поддерживать и развивать!», — скажите Вы. HTML — это «мир сквозь зубы» для крупных ИТ-компаний и замечательный бизнес-инкубатор для начинающих компаний. Сравните стоимости затрат на разработку веб- и натив- приложений, вот это и есть те самые риски. Таким образом, маленькая компания может пытаться осуществить свою идею, ну, а крупные компании готовы бесплатно разработать браузер поддерживающий Ваше веб-приложение.
Но, как только какая-либо идея оказывается перспективной, то в нее тут же вкладываются средства для разработки мощного нативного приложения. Причем настолько мощного, что оно просто начинает ассоциироваться с самой ОС, а ОС в свою очередь с брендом. Например — геокарты, разработанные вначале для веба, а потом появившиеся как нативные приложения для каждого устройства на базе MacOs, Windows, Android. Эти приложения, а также несколько других (почтовые клиенты, мессенджеры, маркеты) достаточно важны для мобильных устройств, являясь их «визитной карточкой». Задумайтесь сами: выбирая то или иное устройство (мобилку, планшет, ноутбук, рабочую станцию), Вы задаете себе вопрос касательно того насколько это устройство хорошо работает с HTML, или все же какие приложения на него можно поставить и насколько хорошо они буду работать?
Ссылки goosly.com/1/esli-html5-eto-priblijaushiysa-poezd-to/habrahabr.ru/post/155325/inet777.ru/buduschee-mobilmznyih-prilozheniy-nativnyie-ili-html/8401
