Давайте признаем: HTML5 — не панацея для разработки приложений

Ничто не расстраивает профессионального разработчика больше, чем кто-то, называющий себя HTML-программистом. Кодирование веб-страниц имеет столько же общего с реальным программированием, как оформление меню с приготовлением пищи. Но вы можете начать сомневаться в этом, если послушаете производителей платформ. Недавно HTML был назначен инструментом разработки для всего, начиная от приложений для смартфонов и планшетов и заканчивая масштабными дескопными приложениями. Palm запустил платформу WebOS, утверждая, что разработчикам для создания приложений не нужно ничего более, чем простые веб-стандарты. Microsoft сказал то же самое про WP7. У браузера от Google есть Web store, который позволяет вам покупать настольные веб-приложения. Но моя челюсть окончательно упала на стол, когда я увидел недавнее демо, показывающее, как разработчики могут использовать HTML5 для создания приложений для Windows 8. Windows-разработчики запаниковали, предположив, что Microsoft планирует отказаться от Silverlight и даже самого .NET. Святые угодники! Неужели мы настолько ослеплены шумихой вокруг HTML5, что готовы поверить в то, что Microsoft может потопить Windows API в угоду веб-стандартам? Это бессмысленно. HTML5 – прекрасный инструмент, и он сделает много полезного для веба, но в последнее время его вознесли до таких высот, что это уже просто смешно. При всей общей благосклонности к HTML5, есть куча причин, по которым не стоит считать HTML5 универсальным средством разработки. И вот несколько возражений, которые нужно принять во внимание.

1. Создать что-нибудь используя только HTML? Удачи!

Любой, кто утверждает, что вы можете создавать веб приложения на HTML, говорит вам только свои фантазии. Что они действительно имеют в виду, так это то, что вы можете создавать приложения с использованием HTML и JavaScript – но даже это не даст вам полной картины происходящего. Минимум для любого серьезного веб-приложения – это HTML, JavaScript и CSS – три разных языка, все вместе. Нововведения W3C для HTML5 добавили в эту кучу веб-стандартов еще больше API, таких как многопоточность и локальное хранилище данных. Это все подразумевает, что ваше приложение не будет обращаться к серверу – например, для параллельных вычислений или хранения данных – и вынуждено будет использовать все эти дополнительные языки программирования, API и стандарты. Когда кто-то утверждает, что создание приложений «так же просто, как и создание веб-приложений». Что они действительно имеют в виду? Веб-разработка развилась в сложную многоязычную и многослойную дисциплину. Часто это совсем не прогулка по парку. Действительно ли эта та модешь, которую мы хотим навязать следующему поколению разработчиков?

2. HTML не был предназначен для разработки приложений

Все возлагаемые на HTML5 надежды основываются на том, что это обычный HTML, приправленный улучшениями для разработки веб-приложений. Но улучшенная поддержка приложений не всегда была направлением HTML стандарта. Изначально преемником XHTML 1.1 должен был стать XHTML2 со своим акцентом на семантику разметки и интеграцию с XML. Как и свои предшественники, XHTML2 должен был стать документо-ориентированным языком разметки. Однако усилия по разработке XHTML2 свернули, а на его останках появилась группа Web Hypertext Application Technology Working Group (WHATWG), которая отклонилась от изначальной модели HTML, разработанной в W3C. Новый черновик стандарта был больше ориентирован на разработку веб-приложений – именно эта работа стала основой того, что мы знаем сейчас как HTML5. Но был ли HTML5 лучшим направлением развития? Например, напыщенный тег из HTML5 по своей сути означает «вставка кучи программного генерируемого графического контента, который нельзя описать разметкой». Достаточно странное использование языка разметки, не так ли? Если мы и дальше пойдем этой дорогой, не начнем ли мы использовать веб-стандарты совсем не для того, для чего они предназначались изначально? Возможно, это необходимо для веба, но действительно ли это в итоге будет «веб»?

3. HTML убог в создании пользовательских интерфейсов

Одной из самых значительных инноваций Apple при выпуске первого Mac компьютера была публикация подробного руководства по разработке пользовательских интерфейсов для разработчиков. Как результат, в отличие от DOS приложений, приложения под Mac выглядели и вели себя похоже. Они все использовали одинаковые меню, одинаковые диалоговые окна и одинаковые окна предупреждений. Итоговое ощущение связанности и единства было одной из тех важных причин, почему Mac OS пользовалась таким успехом – в условиях, когда сами графические оболочки были новы и непривычны. С веб-приложениями мы же опять вернулись в дни DOS. Разработчики интерфейсов свободны создавать любые типы кнопок по своему желанию, оформлять выезжающие или выпрыгивающие откуда-нибудь меню и, в общем случае, разукрашивать все окно браузера так, как им хочется. Без стандартного набора виджетов, приложения, построенные с помощью веб-технологий, выглядят неединообразно и, местами, даже чужеродно. Даже если вы будете ориентироваться на дизайн iPhone-приложений, ваше веб-приложение совсем не будет смотреться на телефоне с Android OS. И кто же собирается создавать «родные» интерфейсы для каждой отдельной мобильной платформы? Да никто, вот кто. (И это мы еще не затронули тему размеров экранов).

4. Создание HTML приложений, ориентированных на отдельную платформу

Хорошо, давайте предположим, что вы не хотите ориентироваться на все устройства и платформы. Допустим, вы просто хотите создать приложение под iOS или Windows 8 – хорошо. Но какого лешего вы вообще выбрали HTML для создания такого типа приложения? Сама суть HTML и связанных с ним платформ в том, что это открытые, кроссплатформенные стандарты. Более того, и iOS, и Windows уже содержат SDK, которые справляются с большинством недостатков, выползающих при разработке HTML приложений. Эти SDK как раз и предоставляют наборы виджетов для построения единообразных пользовательских интерфейсов. Они дают вам доступ к API, которые позволяют высокопроизводительно выполнять ваш код фактически напрямую через процессор. Они позволяют интегрировать приложение с основными функциями операционной системы, недоступными на других платформах. И вы бы отказались от всего этого? Просто потому что создавать веб-приложения «проще»? Даже если бы это было правдой, попробуйте упомянуть это в своем резюме.

5. Неправильно ограничивать разработчика веб-технологиями

Лучший способ устроить бурю в стакане воды – это спросить на форуме для веб-разработчиков, какой язык программирования самый лучший. Разработчики могут очень страстно относиться к своим инструментам – тем более, когда диапазон выбора очень широк, и каждый может подобрать что-то именно по собственному вкусу. Однако, ограничения, наложенные спецификой веб-программирования, сужают этот диапазон. Создание веб-приложений подразумевает работу на HTML, CSS и JavaScript. Мы все изучили их, потому что мы должны были сделать это – но это вовсе не означает, что мы должны любить их. На этих языках работает основная масса разработчиков. И именно этот факт стал реальной причиной того, почему вендоры платформ так легко заявляют, что разработка под их платформу «так же легка, как написание HTML5 кода». Под этими словами автоматически предполагается, что есть миллионы разработчиков, которые уже знают, как разрабатывать под их платформу – хотя это не всегда правда, так как у каждой операционной системы и платформы есть свои особенности. Итак, вендоры будут по-прежнему разглагольствовать о том, как многого вы можете достичь, используя веб-технологии. Они будут продолжать создавать HTML и JavaScript SDK к своим существующим операционным системам – потому что это хороший маркетинг. Я просто хотел бы, чтобы они остановились. Такие инструменты почти никогда не обладают той мощью, которую им приписывают, и они никогда по-настоящему не популярны у профессиональных разработчиков (в противовес простым «HTML-программистам»). В конце концов, голова и так идет кругом от громадного количества технологий, которые могут быть более мощными, более элегантными или просто лучше подходящими к текущей задаче.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.