Кодекс за компромиси, шибан
Нашата работа включва арбитриране на така наречените компромиси. Въпросът е да се определят положителните и отрицателните точки на решението и да се изчисли баланса. Ние избираме решението, което най-добре отговаря (поне в нашите очи) на нашите нужди по този начин.
В нашата индустрия обаче съществува система от догми. Вече не се стремим да поставяме компромисите в перспектива и да ги сравняваме, а да се борим срещу „школи на мисълта“, всяка от които е разработила аксиоми (принципът не се демонстрира, но се използва като основа за разсъждения).
След поредния дебат за съвременните технологии, използвани отпред, опроверган от защитниците на някои от тези аксиоми, ще се опитам да рационализирам нашия подход и да обясня компромисите му.
Идеята тук е да се направи разбирам защо използваме тези подходи и технологии, в какъв контекст, и да не ги налага на никого. С малко късмет тази статия ще промени някои речи от „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 реагира на нарастващо разочарование с шаблони без логика, които принудиха създаването на помощници и трансформацията на данни нагоре.