Я давно уже занимаюсь разработкой web-приложений. Очень давно. Свои первые web-приложения в среде Lotus Domino я создавал в те времена, когда слово «google» ещё не было глаголом, а для поиска информации в интернете люди использовали Yahoo! и Rambler. Я же пользовался Infoseek‘ом — у них был сужающийся поиск и не такой безобразно перегруженный интерфейс, как у Yahoo!

Разработка приложений, любых приложений, не только для web’а — работа творческая. Вряд ли кто-то будет спорить с этим утверждением. А красота в творчестве, это как практика в научном познании — критерий истины. Но если научная практика объективна и базируется на измерениях, то красота — предмет субъективный, зависит от того, кто смотрит. Вот я и задался вопросом, а что для меня лично является красивым web-приложением?

(на КДПВ глаз не мой, глаз женский, но, IMHO, женский глаз на КДПВ более уместен, чем мужской, ведь это же — КДПВ!)

Под катом мои собственные критерии того, какое web-приложение на данный момент может считаться красивым. Очень субъективное изложение, обусловленное моим персональным опытом. Возможно кому-то мои критерии прекрасного покажутся критериями уродства. Не удивляйтесь, просто у вас другой опыт.

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

Среда Обитания

Протоколы

Не знаю даже, стоит ли отдельно выносить этот критерий. Web-приложения живут в Сети и вынуждены соответствовать Законам Сети (протоколам). Главные протоколы в Сети — TCP и IP. На них основывается множество других протоколов, но для web-приложений я считаю самым важным HTTP (вернее, его расширение HTTPS на базе TLS). Т.е., красивое web-приложение доступно по HTTPS/TLS (как вариант — по HTTP), а остальные протоколы (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) делают его менее красивым с каждым дополнительно поддерживаемым протоколом. Само же приложение может при помощи этих дополнительных протоколов использовать внешние ресурсы.

Что касается WebSocket, то у меня нет достаточного опыта использования этого протокола с web-приложениями. Выглядит красиво и перспективно, но насколько это стабильно и практично — сказать не могу.

Браузеры

Web-приложение только одной ногой стоит на серверной стороне, вторая — на клиентской стороне. Клиентская сторона — это браузер. Современный браузер предоставляет много чего, что современное web-приложение может и должно использовать в своих интересах. Красивое web-приложение использует современные возможности браузеров и не обязано работать в тех браузерах, которые современные возможности не предоставляют. Я понимаю, что полифилы — это вынужденная мера, но это некрасиво. В конце-концов, не только разрабы должны успевать за современными технологиями, пользователей и бизнес это тоже касается.

ЯП

С языками программирования, которые используются для создания web-приложений, всё очень запутано. Для клиентской части web-приложений есть масса технологий, позволяющих разработчику облегчить создание триады HTML/CSS/JS (то, что понимают все современные браузеры). Но я в своё время плотно соприкоснулся с GWT и считаю красивым, когда разработчик видит в браузере оригинальный код, а не результат компиляции или транспиляции. Поэтому использование webpack‘а и ему подобных продуктов для генерации клиентского кода, IMHO, некрасиво. Чем больше исполняемый в браузере код похож на исходный код, созданный разработчиком, тем лучше. Не верите? Попробуйте отдебажить в production’е код, созданный GWT.

На серверной стороне свободы больше (Java, PHP, perl, python, C#, Ruby, …), но мне кажется, что красиво, когда и на серверной стороне, и в браузере используется один язык программирования — JavaScript. Всё-таки язык определяет мышление, а команды единомышленников более продуктивны.

Человечность

Красивое web-приложение должно быть полезным. Полезным, в первую очередь, для человека, как конечного потребителя. Поэтому я не могу назвать красивым web-приложением web-сервисы. Обычному человеку (не web-девелоперу) с ними сложно. Web-сервисы красивы по-своему,

Красивое web-приложение должно иметь интуитивно понятный интерфейс. Можно спорить о UI‘е — это довольно субъективная вещь. Но с UX всё гораздо проще, если пользователь не может использовать приложение без заветного RTFM — плохой UX, некрасивое web-приложение. Самые красивые относительно этого критерия web-приложения могут с лёгкостью использоваться детьми, которые ещё не умеют читать.

Обратная Масштабируемость

Давным-давно программы можно было переносить на дискетах, сейчас — на флешках или сразу скачать из Сети. Скопировать обычное приложение и запустить его на другой машине — задача тривиальная. С web-приложениями ситуация несколько особая. Сеть представляет собой глобальную среду, в которой нет нужды иметь клоны одного и того же web-приложения. В Сети хватает одного Facebook’а, Twitter’а, Instagram’а, Mail.ru или Yandex’а. Можно иметь различные web-приложения в одной и той же тематической нише, но с разными аудиториями (как Facebook и Вконтакте, Mail.ru и Gmail, Google Maps и Azure Maps). Аппаратные ресурсы для обеспечения глобальной доступности таких web-приложений нужны, скажем так, нетривиальные.

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

Красивое web-приложение масштабируется не только вверх и вширь (для пользователей), но и вниз и вовнутрь (для разработчиков).

«Земноводность»

Для доступа к современным web-приложениям используются устройства двух типов:

• компьютеры (ноутбуки, десктопы);
• мобильные устройства (смартфоны и планшеты);

Где-то на горизонте маячит ещё «интернет вещей«, но пока так.

Компьютеры от мобильных устройств отличаются настолько же сильно, насколько сухопутные существа отличаются от водоплавающих. Это разные среды и они предъявляют разные требования к обитающим в них существам (программам). Красивые web-приложения не те, которые похожи на амфибий, а те, которые в воде — как рыбы, на суше — как звери, а в воздухе (SEO) — как птицы.

Я считаю некрасивым «земноводность«, это как попытка усидеть на двух (с SEO — трёх) стульях. Лучше уж как Фиона из Шрека — днём одна, а ночью другая. Да, дороже. Но лучше.

Cross-sharing

Я уже отмечал в пункте «Обратная Масштабируемость», что глобальность Сети даёт возможность иметь одно web-приложение на Планету. Поэтому каждое web-приложение должно хоть чем-то отличаться от других, чтобы обеспечить себе выживание. Тем не менее, мой многолетний опыт с Magento (каркас для построения магазинов e-commerce) говорит, что между отдельными web-приложениями общего может быть больше, чем различий. Красивое web-приложение не только должно быть модульным, оно также должно разделять свои модули с другими web-приложениями. В какой-то мере эта идея отражена в спецификациях JSR 168 и JSR 286 и таких framework’ах, как WordPress, Django и та же Magento. Чем большее количество модулей web-приложения используется другими web-приложениями, тем оно красивее с моей точки зрения. Cross-sharing позволяет создавать более качественные модули и, как следствие, более стабильные web-приложения.

Под модулем я не подразумеваю библиотеки типа jQuery или RequireJS — скорее более крупные образования, типа плагинов в WordPress и Django. Но для библиотек также справедлив тезис, что широкое распространение библиотеки позволяет сделать её более качественной и устойчивой.

Гарвардская архитектура

Гарвардская архитектура, в отличие от ныне правящей бал принстонской, подразумевает разделение кода и данных. Архитектура не взлетела, но сама идея лично мне кажется красивой. Особенно для web-приложений. Любая статика (HTML/CSS/JS/Images/…) — это код. Его можно и нужно кэшировать хоть на серверной стороне, хоть на клиентской. А данные — это REST/JSON (красиво) или SOAP/XML (чуть менее красиво). Или WebSockets/JSON (может быть наилучшим вариантом, но я не пробовал).

Локализация

Есть две вещи, которые меня особенно волнуют при разработке web-приложений — это мультиязычный интерфейс и часовые пояса. Я сам из Латвии, у нас в ходу три языка: LV, RU, EN. Красивое web-приложение должно давать возможность не только использовать несколько языков в самом приложении, но и позволять расширять количество используемых языков при помощи внешних ресурсов, типа Crowdin. Это же справедливо и для модулей, из которых собирается web-приложение.

С часовыми поясами всё просто, во всех случаях, когда непонятно, как обрабатывать дату-время, делайте так: всё, что лежит на сервере, уходит на сервер и приходит с сервера — UTC, всё, что отображается на клиенте — согласно часового пояса из профиля пользователя. Это красиво.

Кузницы вместо «Звезд Смерти»

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

А теперь посмотрите на такой сервис, как DNS. Когда ложатся корневые сервера, лихорадит весь мир.

На мой взгляд, красивое web-приложение не может быть такого размера, как Facebook или Mail.ru. Это уже ближе к «Звезде Смерти» и по ресурсам, необходимым для постройки, и по ресурсам, необходимым для поддержания работоспособности. Да, в случае уничтожения Facebook’а человечество не исчезнет, его функции достаточно быстро переймут другие приложения (тот же ВК на территории РФ и прилегающих, Instagram, Twitter, …). Тем не менее, замыкание значимой части населения Планеты на одно приложение — это некрасиво. Тем более, при наличии гораздо более устойчивых альтернатив (например, torrents).

Резюме

Если вы дочитали до конца и испытываете недоумение — «что это было?«, то выражаю вам своё искреннее сочувствие. Я не заставлял вас читать это. Я просто попытался облечь свои мысли в слова, чтобы найти тех, кто думает так же. Возможно, я смогу обсудить с ними некоторые аспекты создания красивых web-приложений и узнать ответы на свои вопросы. А их у меня много.

Спасибо за прочтение.

Источник: habr.com