Харесвам здравината, която идва с декларативните езици. Харесвам и силата, която идва с императивните езици. Най-хубавото от всичко е, че ми харесва да имам избор.
Вземете например елементите video и audio. Ако искате, можете да вградите видео или аудио файл в уеб страница, като използвате ясна декларация в HTML.
<audio src="..." controls><!-- fallback goes here --></audio>Веднага, това покрива 80%-90% от случаите на употреба. Но ако трябва да направите повече — например да предоставите свои персонализирани контроли — има съответен API, който е изложен в JavaScript. Използвайки този API, можете да правите всичко, което можете да правите с HTML елемента, и много повече освен това.
Подобна е и историята с анимацията. CSS предоставя изобилие от анимационни възможности, но е ограничен в събитията, които могат да задействат анимациите. Това е добре. Има съответен JavaScript API, който ви дава повече мощност. Отново, CSS декларациите покриват 80%-90% от случаите на употреба, но за всеки в тези 10%-20%, API за уеб анимация е там, за да помогне.
Валидирането на формуляр от страна на клиента е друг добър пример. За повечето нас HTML атрибутите — required, type и т.н. — вероятно са достатъчни през повечето време.
<input type="email" required />Когато се нуждаем от по-прецизен контрол, в JavaScript има наличен API за валидиране (да, да, знам, че самият API е проблематичен, но схващате смисъла).
Наистина харесвам този дизайн модел. Покрийте 80% от случаите на използване с декларативно решение в HTML, но също така осигурете наложителна алтернатива в JavaScript, която дава повече мощност. HTML5 има много примери за този модел. Но чувствам, че историята на уеб стандартите има и няколко пропуснати възможности.
Геолокацията е добър пример за небалансирана функция. Ако искате да го използвате, трябва да използвате JavaScript. Няма декларативна алтернатива. Това не съществува:
<input type="geolocation" />Това е срамота. Всеки, който пише формуляр, който пита за местоположението на потребителя - за да изпрати тази информация на сървър за обработка - трябва да напише малко JavaScript. Това е добре, предполагам, но винаги ще бъде малко по-крехко и податливо на грешки в сравнение с маркирането.
(И само в случай, че мислите за резервния вариант — което би било елементът input да бъде изобразен така, сякаш стойността му type е text — и смятате, че е абсурдно да очаквате потребители с неподдържащи браузъри да въвеждат координати за географска ширина и дължина на ръка, насочвам вниманието ви към input type="color": в неподдържащи браузъри се изобразява като input type="text" и от потребителите се очаква да въвеждат цветови стойности на ръка.)
Геолокацията е интересен случай на използване, защото работи само на HTTPS. Има доста приложни програмни интерфейси (API) на JavaScript, които с право изискват защитен контекст — като „работници за услуги“ – но не мога да се сетя за нито един HTML елемент или атрибут, който да изисква HTTPS (въпреки че „това скоро ще се промени“, ако не го направим действайте, за да спрете „плановете за създаване на двустепенна мрежа“). Но това не може да е било мисленето зад геолокацията да е само JavaScript; когато геолокацията беше доставена за първи път, тя беше достъпна и през HTTP връзки.
Както и да е, това е само един пример. Както казах, не че подкрепям декларативните решения вместо императивните; Силно подкрепям предлагания избор чрез предоставяне на декларативни решения, както и наложителни.
През последните години имаше натиск за излагане на разработчиците на функции на браузъра от ниско ниво. Те неизбежно се показват като API на JavaScript. В повечето случаи това има пълен смисъл. Наистина не мога да си представя декларативен начин за достъп до fetch или cache API, например. Но мисля, че трябва да внимаваме това да не стане единственият начин за излагане на нови функции на браузъра. Мисля, че когато е възможно, моделът на проектиране на излагане на нови функции декларативно и императивно предлага най-доброто от двата свята – лекота на използване за прости случаи на употреба и мощност за по-сложни случаи на употреба.
Преди създателите на браузъри трябваше да мислят за тези неща. Но сега, с навлизането на уеб компонентите, ние, разработчиците, придобиваме същото ниво на власт и отговорност. Така че, ако правите уеб компонент, който се надявате и други хора да използват, може би си струва да имате предвид този модел на проектиране: позволете на авторите да конфигурират функционалността на компонента с помощта на HTML атрибути и JavaScript методи.
Това първоначално беше публикувано на моя собствен сайт.
