Отдавна се занимавам с разработката на уеб приложения. Много отдавна. Първите си уеб приложения създавах в среда времена, когато думата „google“ все още не беше глагол, а за търсене на информация в интернет хората използваха Yahoo! и Rambler. Аз ползвах — при тях имаше свиващо се търсене и интерфейс, който не беше толкова натоварен, колкото при Yahoo!
Разработването на приложения, всякакви приложения, не само за уеб, е творческа работа. Мисля, че никой не би оспорил това твърдение. А красотата в творчеството е като практиката в научното познание — критерий за истина. Но ако научната практика е обективна и се основава на измервания, то красотата е субективен предмет, зависи от това, кой гледа. И така, се запитах какво за мен лично представлява красиво уеб приложение?
(не е мой поглед, а женски, но, IMHO, женският поглед на КДПВ е по-уместен от мъжкия, все пак — !)
Под катът са собствените ми критерии за това, кое уеб приложение в момента може да се счита за красиво. Много субективно изложение, обусловено от личния ми опит. Възможно е моите критерии за красота да се сторят на някого критерии за уродливост. Не се учудвайте, просто имате различен опит.
И тъй като сте влезли под кат, бъдете моля внимателни в коментарите. Наистина, ако можете да спрете да четете статията, когато изложеното в нея ви се стори некрасиво или дори уродливо, аз, като автор, съм принуден да чета всички коментари.
Среда Обитаване
Протоколи
Не знам дали е нужно да отделям този критерий. Уеб приложенията живеят в мрежата и са задължени да отговарят на законите на мрежата (протоколите). Основните протоколи в мрежата — и . Върху тях се основават много други протоколи, но за уеб приложенията считам, че най-важен е (по-скоро, неговото разширение на базата на ). Т.е., красиво уеб приложение е достъпно по HTTPS/TLS (както вариант — по HTTP), а другите протоколи (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) го правят по-малко красиво с всеки допълнително поддържан протокол. Самото приложение може да използва външни ресурси чрез тези допълнителни протоколи.
Що се отнася до , то нямам достатъчно опит с използването на този протокол с уеб приложения. Изглежда красиво и перспективно, но колко стабилно и практично е — не мога да кажа.
Браузери
Уеб-приложението стои с единия крак на сървърната страна, а с другия — на клиентската страна. Клиентската страна е браузърът. Съвременният браузър предоставя , които съвременното уеб-приложение може и трябва да използва в своя полза. Красивото уеб-приложение използва съвременните възможности на браузърите и не е задължено да работи в браузъри, които не предлагат съвременни функции. Разбирам, че са принудителна мярка, но това е неестетично. В края на краищата, не само разработчиците трябва да се справят с модерните технологии, но и потребителите и бизнесът също.
ЕЗ
С езиците за програмиране, които се използват за създаване на уеб-приложения, всичко е много объркващо. За клиентската част на уеб-приложенията съществуват много технологии, които улесняват разработчика в написването на триадата HTML/CSS/JS (нещата, които разбират всички съвременни браузъри). Но аз по време на развитието си дълбоко се запознах с и смятам за красиво, когато разработчикът вижда оригиналния код в браузъра, а не резултата от компилацията или транспилацията. Следователно, използването на ‘а и подобни продукти за генериране на клиентски код, по мое мнение, е неестетично. Колкото по-близък е изпълняемият в браузъра код до изходния код, създаден от разработчика, толкова по-добре. Не вярвате? Опитайте да дебъгнете в продукция код, генериран от GWT.
На сървърната страна свободата е по-голяма (Java, PHP, Perl, Python, C#, Ruby, …), но ми се струва, че е красиво, когато и на сървърната страна, и в браузъра се използва един и същ език за програмиране — JavaScript. Все пак , а отборите от съмишленици са по-продуктивни.
Човечност
Красивото уеб-приложение трябва да бъде полезно. Полезно преди всичко за човека, като крайния потребител. Затова не мога да нарека красиво уеб-приложение . На обикновения човек (не уеб-разработчик) е трудно да се справи с тях. Уеб-сервизите са красиви по свой начин,
Красивото уеб-приложение трябва да има интуитивно разбираем интерфейс. Може да се спори за ‘е — това е доста субективна работа. Но с всичко е много по-просто, ако потребителят не може да използва приложението без заветното — лош UX, грозно уеб приложение. Най-красивите спрямо този критерий уеб приложения лесно могат да се използват от деца, които все още не умеят да четат.
Обратна мащабируемост
Отдавна програмите се пренасяха на флопи дискове, сега – на флашки или директно за изтегляне от интернет. Копирането на обикновено приложение и стартирането му на друга машина е тривиално. С уеб приложенията ситуацията е малко по-особена. Мрежата представлява глобална среда, в която не е нужно да имате клони на едно и също уеб приложение. В мрежата е достатъчен един Facebook, Twitter, Instagram, Mail.ru или Yandex. Можете да имате различни уеб приложения в една и съща ниша, но с различни аудитории (като Facebook и ВКонтакте, Mail.ru и Gmail, Google Maps и Azure Maps). За осигуряване на глобалната достъпност на такива уеб приложения са необходими, да кажем, .
Никога не съм работил с уеб приложения на такова ниво като разработчик и не си представям как те функционират отвътре. За осигуряване на работоспособността на такива уеб приложения са необходими екипи от съответни специалисти и отделни дата центрове. Възхищавам се на способността на хората да си сътрудничат в такива мащаби и да създават подобни продукти, но моят идеал за красота е уеб приложение, което може да бъде стартирано на отделен лаптоп.
Красивото уеб приложение се мащабира не само нагоре и навън (за потребители), но и надолу и навътре (за разработчици).
«Земноводност»
За достъп до съвременни уеб приложения се използват устройства от два типа:
- компютри (лаптопи, десктопи);
- мобилни устройства (смартфони и таблети);
Някъде на хоризонта се задава още „“, но за момента е така.
Компютрите се различават от мобилните устройства толкова, колкото сухопътните същества се различават от водоплаващите. Това са различни среди и те поставят различни изисквания към обитаващите ги същества (програми). Красивите уеб приложения не са тези, които приличат на , а тези, които във вода — като риби, на суша — като зверове, а във въздуха () — като птици.
Смятам, че „“ не е красиво, това е като опит да седиш на два (с SEO — три) стола. По-добре е като Фиона от Шрек — през деня една, а през нощта друга. Да, по-скъпо. Но по-добре.
Крос-споделяне
Вече споменах в точка „Обратна Масштабируемост“ , че глобалността на Мрежата дава възможност да имаме едно web-приложение на Планетата. Затова всяко web-приложение трябва да се различава от другите по някакъв начин, за да осигури своето оцеляване. Въпреки това, моята многогодишна опитност с (рамка за изграждане на e-commerce магазини) казва, че между отделните web-приложения може да има повече общо, отколкото различия. Красивото web-приложение не само трябва да бъде модулно, но и трябва да споделя своите модули с други web-приложения. В известен смисъл, тази идея е отразена в JSR 168 и JSR 286 и такива framework-и като , и същата Magento. Колкото повече модули на web-приложението се използват от други web-приложения, толкова по-красиво е то от моята гледна точка. Cross-sharing позволява създаването на по-качествени модули и, като следствие, по-стабилни web-приложения.
Под модул не разбирам библиотеки като jQuery или RequireJS — по-скоро по-големи образувания, като плъгини в и . Но и за библиотеките е валидно, че широкото разпространение на библиотека позволява да я направи по-качествена и устойчива.
Харвардската архитектура
, в противовес на в момента надмощната бал , предполага разделение на код и данни. Архитектурата не се е утвърдила, но самата идея на мен лично изглежда красива. Особено за web-приложения. Всяка статичност (HTML/CSS/JS/Images/…) — това е код. Може и трябва да бъде кеширан както на сървърната страна, така и на клиентската. А данните — това са / (красиво) или / (малко по-малко красиво). Или WebSockets/JSON (може би най-добрият вариант, но не съм пробвал).
Локализация
Има две неща, които особено ме вълнуват при разработката на web-приложения — това е многоезичният интерфейс и часовите зони. Аз самият съм от Латвия, при нас се използват три езика: LV, RU, EN. Красивото web-приложение трябва да дава възможност не само да се използват няколко езика в самото приложение, но и да позволява разширяване на броя на използваните езици чрез външни ресурси, като . Това е валидно и за модулите, от които се сглобява web-приложението.
С часовите зони са лесни, в всички случаи, когато не е ясно как да се обработва дата-час, правете така: всичко, което е на сървъра, отива на сървъра и идва от сървъра — UTC, всичко, което се показва на клиента — според часовата зона в профила на потребителя. Това е красиво.
Кузници вместо «Звезди на смъртта»
Отдавна, във всеки по-голям град имаше своя кузница. Може би не една. Някои бяха по-добри, други по-лоши. Имаше ковачи, известни в целия свят, а имаше и такива, при които се ходеше от безалтернатива. Преминаваха войни, епидемии, природни бедствия. Някои градове изчезваха заедно с населението си. Но кузническото занаятчийство продължаваше да живее. Вместо изчезналите градове се изграждаха нови и в тях също се появяваха кузници.
А сега погледнете на такъв сервис като . Когато паднат кореновите сървъри, .
На мен ми се струва, че красиво уеб приложение не може да бъде с размерите на Facebook или Mail.ru. Това вече е по-близо до «» и по ресурси, необходими за построяване, и по ресурси, необходими за поддържане на функционалността. Да, в случай на унищожение на Facebook, човечеството няма да изчезне, функциите му бързо ще бъдат поети от други приложения (същият на територията на РФ и съседните, Instagram, Twitter, …). Въпреки това, ограничаването на значителна част от населението на Планетата до едно приложение — не е красиво. Тем повече, при наличието на много по-устойчиви алтернативи (например, ).
Резюме
Ако сте прочели до края и изпитвате недоумение — «какво беше това?«, изразявам искреното си съчувствие. Не ви карах да четете това. Просто опитах да облека мислите си в думи, за да намеря тези, които мислят по същия начин. Може би ще мога да обсъдя с тях някои аспекти на създаването на красиви уеб приложения и да науча отговори на своите въпроси. А въпросите ми са много.
Благодаря за прочитането.
Източник: habr.com
