Кодекс за компромиси, шибан

Нашата работа включва арбитриране на така наречените компромиси. Въпросът е да се определят положителните и отрицателните точки на решението и да се изчисли баланса. Ние избираме решението, което най-добре отговаря (поне в нашите очи) на нашите нужди по този начин.

компромиси

В нашата индустрия обаче съществува система от догми. Вече не се стремим да поставяме компромисите в перспектива и да ги сравняваме, а да се борим срещу „школи на мисълта“, всяка от които е разработила аксиоми (принципът не се демонстрира, но се използва като основа за разсъждения).

След поредния дебат за съвременните технологии, използвани отпред, опроверган от защитниците на някои от тези аксиоми, ще се опитам да рационализирам нашия подход и да обясня компромисите му.

Идеята тук е да се направи разбирам защо използваме тези подходи и технологии, в какъв контекст, и да не ги налага на никого. С малко късмет тази статия ще промени някои речи от „nimportawak (sic)“ на „не е за моя тип проект“.

Първоначално мрежата е проектирана като набор от документи: всяка страница е една. С всяка навигация задействаме нов цикъл на живота на страница: завършваме текущата страница, инициализираме следващата.

Този модел е много опростен и позволява много правилно изживяване за предимно статични страници.

Имаме страница, обслужвана в HTML, таблица със стилове, обслужвана в CSS. И това е. Научаваме, че трябва да ги разделяме добре (в името на принципа на разделяне на проблемите, в случай че има такъв, който се обърка, трябва да се предложи деградирал опит.

С течение на годините изискванията на потребителите стават по-високи: трябва да им се отговаря със страници по-интерактивни и техники на частични презареждания страница (жизненият цикъл на страницата е доста скъп). Затова започнахме да добавяме ограничен интелигентност с малко JS, по-специално някои интерактивни тухли, зареждаме края на страницата с AJAX.

Тези техники направиха възможно драстично подобряване на сърфирането потребители: имаме по-малко данни за зареждане, показваме това, което хората искат да видят по-бързо (все пак би било малко досадно да заредите нова страница веднага щом увеличите мащаба на Google Maps). И е тук първият компромис:

  • заредете повече данни при първоначално зареждане на страницата (JS),
  • Но това ни позволява да зареждаме по-малко данни за последователни зареждания.

След това идва разпространението на мобилни платформи. За да достигне до потребителите, мрежата вече не съществува НА платформа, но A платформа наред с други. След това става стратегически интересно за компаниите да започнат да разработват общи бази под формата наAPI, за които ще се абонират множество клиенти на различни платформи.

По това време предният край преживя безпрецедентна промяна: започнахме да творим реални приложения, вече не са документи, към които се присаждат произволно някои функции. След това придобиваме по-усъвършенствани инструменти, базирани на модели, вече доказани в други области на софтуера (като MVC). Отминаха дните на JS файла, който инициализира 3 плъгина jQuery, за да направи въртележки.

След това започваме да мислим по отношение на мнения. Също така получаваме известна независимост от задния край, можем да генерираме нашия интерфейс директно от JS.

Вече не е задължително да научаваме как работи back stack стека, неговата организация, езика на шаблоните: ние ставаме майстори на нашите стекове.

Ние обхващаме нови въпроси като маршрутизиране, извличане на данни и създаване на интелигентни клиентски кешове. След това се появяват рамки, предлагащи решения за тях (Angular, Ember и Backbone, за да назовем само няколко).

Тогава React пристига с уникален подход към своите конкуренти: компоненти. Създаваме по един за всеки блок за многократна употреба на приложението.

Компонентът е черна кутия, която приема параметри (подпори), може да има локално състояние и която ще описва интерфейса във всеки момент от времето.

React идва и с JSX, разширение на JS, което позволява неговият интерфейс да бъде описан във форма, наподобяваща HTML (XML), но без ограничения (като необходимостта от сериализиране на атрибути). Докато запазва познаваемостта на HTML (и уместността на такъв синтаксис за представяне на дърво от елементи), JSX реагира на нарастващо разочарование с шаблони без логика, които принудиха създаването на помощници и трансформацията на данни нагоре.

Като се абстрахира напълно от DOM и ни предлага прост концептуален модел ((props, state) => UI), React прави възможно създаването на по-богати интерфейси, по-просто и преди всичко по поддържаем начин: поведението на даден компонент е в комбинация с неговата маркировка, вече не се налага да навигираме между HTML файл и JS, за да ги синхронизираме. Изолацията на компонентите помага да се предотвратят нежелани ефекти на ръба.

Следователно HTML и JS се събират, редактирането им се обединява. Изненада: осъзнахме, че това е по-продуктивен начин за правене на нещата и че е по-малко вероятно да оставим стария код да гние в нашия ъгъл.

Този проблем остава при CSS: все още е възможно да се напише CSS код с нежелано въздействие върху компонент, различен от целевия. Има войни за специфичност, визуални регресии и липса на видимост върху въздействието на промяната. Ако наследявате код, който не сте или не сте по-запознати, риск от счупване на нещо висок е.

Техниките наизолация „ръчни“ като BEM набират популярност. След това избягваме езотеричните селектори и го улесняваме, като методологията за разделяне се извършва успоредно с нашите компоненти (имената на класа на моя компонент Button ще бъдат с префикс от Button), което е по-поддържаемо. По преценка на разработчиците, тази методология остава обект на грешки, необходимо е да се провери дали човек не използва и не нарушава съществуващо пространство от имена.

След това идват решенията, автоматизиращи тази изолация, делегиращи задачата на машината, а не на човека: CSS модули и CSS-в-JS. С тези техники, грешка вече не може да надвишава обхвата на своя компонент. CSS, който не се използва по даден маршрут, никога не се инжектира: мъртвият CSS се елиминира по подразбиране (практически невъзможен и поне не автоматизиран проблем с традиционния стил).

CSS-в-JS върнете стила обратно към компонента, в неговия обхват. Нашият компонент вече съдържа своята маркировка, стил и поведение.

Казано е, че този подход нарушава разделението на проблемите, но тази визия изхожда от постулата, че трябва императивно да се кодират документи и да се забрави компонентният подход. Постулат, който забравихме да преоценим с перспективата на развитието, както е направено. В контекст на приложение, разделянето на маркировка, стил и поведение се свежда до налагане на ненужно технологично разделяне, което може в името на „добрата практика“ да повлияе негативно на опита на разработчиците и потребителите.

Вече няма друга причина освен „носталгия по добрите стари времена“ да се направи това, става дума за рефлекси, придобити по онова време, но никога не поставяни в перспектива. Попитайте някого защо не е наред, той ще каже „РАЗДЕЛЯНЕ НА ОТНОШЕНИЯТА!“ Попитайте го защо, едва ли ще излезе с нещо осезаемо.

Подходът CSS-in-JS не създава проблем, когато приложението се управлява изцяло от страна на клиента. Но това може да бъде досадно за приложения, изведени на сървърната страна: CSS ще липсва в HTML страницата, заредена първоначално и ще имате FOUC (Flash Of Unstyled Content). За щастие, по-голямата част от CSS-in-JS решенията предлагат извличане на стил по време на сървърно изобразяване. Той извлича критичните стилове от страницата и ги прикачва към изобразяването на генерираното приложение. Зареждате по-малко CSS и приложението от страна на клиента ще поеме да зарежда и инжектира правилата, ако е необходимо.

Всяко решение има своите компромиси. Вземете времената за зареждане на различните подходи като примери и ги запишете с букви от A до F (A най-бързо, F най-малко):

Всяко от тези решения може да отговаря на вашите нужди. Документът ще привилегирова първоначалното зареждане, а приложението - навигациите в него. Нищо не е перфектно, той (и вероятно ще бъде за дълго време) решава какъв компромис сте готови да направите.

Днес пишем приложения с технология в пълна еволюция, първоначално предназначена само за създаване на документи.

Изправяме се срещу консерватизма на някои, които отказват да видят модела „отклонен“ от употреба, както беше планирано преди 20 години. Но трябва да им напомним, че искаме да правим приложения, които са полезни за нашите потребители, по-леки, по-бързи, които излизат извън рамките, първоначално планирани от документния подход, и че искаме да можем да ги правим сега, защото нашите потребители нямат много общо с факта, че дадена функция трябва да съществува в стандартите, за да могат разработчиците да я използват. Ако Dulux Valentine продава само основни цветове, ще помислите да извикате на хора, които правят стените си зелени, като смесват жълто и синьо ?

Затова експериментираме, пренасочваме употреби, създаваме неща, възползваме се от API, които първоначално не са били предназначени за това, доставяме приложения, способни на неща, които не сме си представяли възможни в мрежата преди няколко години. Благодарение на всички тези подходи и премахвайки тежестта на остарелите правила, ние го правим по-бързо, правим го по-добре, правим го по-чисто.

И знаете ли какво? Не разбива мрежата. Това не нарушава вашите страници. Той е не по-малко достъпен. Той просто използва стандартните уеб инструменти, с които разполагаме, за да направи повече. Освен това помага за насочването на W3C, като им показва, че определени решения се използват за разрешаване на определени проблеми, които не са директно адресирани от стандартите.

Вие лично не се нуждаете от тези подходи? В деня, в който се появят тези нужди, ще разберете, че съществуват, просто разберете Защо те са поставени на място, какви проблеми решават, какви са техните компромиси. Все още може да не ви харесват, но поне ще сте ги разбрали и те ще бъдат допълнителна алтернатива за съдбоносния ден. Когато имате достатъчно струни на лъка си, можете да свирите на арфа.