След като приложих няколко авангардни JavaScript рамки, намерих добри причини да спра да разчитам на тях

Angular, Ext JS, React, Vue, Svelte, Alpine, Remix, Blitz, Qwik и така нататък. Нарастващ списък от фантастични платформи за разработка отпред. Започнах да ги използвам около 2011 г. и продължих до ден днешен с чести промени, винаги търсейки следващата най-добра технология.

През последните години обаче започнах да обмислям и практикувам алтернативен начин, който наричам „тухла и хоросан“ разработка, базиран на основните градивни елементи на мрежа приложение, а именно HTML, CSS и Javascript, с възможната помощ на jQuery.

По малко провокативен начин искам да представя тук аргументи в подкрепа на тезата, че изборът на такива инструменти на „ниско ниво“ може да донесе реални ползи в разработката на предния край в сравнение с приемането на сложни платформи като Angular или React . Не искам да подценявам иновациите, въведени от най-модерните инструменти, но поставям под въпрос тяхната реална „устойчивост“ в дългосрочно развитие.

Какво не е наред с разширените рамки

1. Твърде много опции

Има твърде много налични „най-съвременни“ рамки. Изглежда, че не е проблем, но може би е основният проблем. Намерете някой, който никога не се е чудил защо има постоянно разпространение на нови платформи.
Като разработчик на пълен стек, защо трябва да променям толкова често, дори ако рамката, която използвам, вече е подходяща за предназначението си?

Освен лични съображения, прекомерният брой възможни технически архитектури предизвиква различни реални проблеми, свързани с качеството и количеството на необходимите умения и остаряването на решенията.

2. Крива на учене и умение за програмиране

Първото предизвикателство е да се изгради и поддържа във времето екип с достатъчно ноу-хау и умения за програмиране за разработване и дългосрочна поддръжка на уеб приложение, създадено с такава усъвършенствана платформа.

Да предположим, че искаме да разработим достатъчно сложна система с платформа X (където X може да означава Angular, React, Vue или всяка друга eXtra-Cool-JS-Framework). Идеалният кандидат да се присъедини към програмния екип трябва да притежава следните качества:

  1. отлично работно познаване на основите (HTML, CSS, JS, jQuery)
  2. добра експертиза на платформа X(надявам се в най-новото й въплъщение)
  3. работен опит с най-добрите практики на X

Поне един старши човек в екипа също трябва да знае

4. Кой е най-добрият начин за структуриране на система с невероятната X технология

Тъжната реалност е, че сме късметлии, ако намерим някой, който се доближава до #4, можем да накараме някои момчета или момичета да бъдат обучени на X (#2), но не толкова надеждни на #1, и се отказваме по отношение на #3.

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

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

Ако това не е достатъчно, ръководителят на проекта вероятно не знае достатъчно за X, за да прецени ефективността и правилността на направените дизайнерски решения.

Обратно, в проектния екип от тухли и хоросан, единствените необходими неща са добро познаване на едни и същи основни инструменти, които винаги са под капака: HTML, CSS, Javascript и jQuery. Същият градивен елемент от стотици милиони уебсайтове.

3. Поддръжка и волатилност

Помислете за три прости факта:

  1. най-добрите системи за приложения издържат години (моят рекорд е ERP система, създадена преди 20 години, все още работеща)
  2. рано или късно някой, който не е написал софтуера, ще извърши поддръжката
  3. най-модерните платформи за разработка се развиват бързо (или понякога умират)

С тези предпоставки мислите ли, че е по-евтино да се поддържа с течение на времето система, изградена с изключително стабилни основни инструменти, или такава, направена с най-новите най-добри технологии в непрекъсната еволюция?

Предположи.

Освен това помислете за следното: каква е вероятността инструментът, който сте избрали, да бъде масов инструмент години след първоначалното му разработване?

4. Структура и синтаксис

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

Моето мнение е, че намеренията са добри, но са прекалили по няколко причини:

  1. Всяка рамка е използвала синтактичната свобода на HTML по свой собствен начин, въвеждайки собствени разширения, понякога с екзотичен синтаксис. Някои рамки дори позволяват на разработчиците да добавят свои собствени HTML разширения.
  2. Автоматичното свързване на данни и управлението на състоянието може да бъде сложно за контролиране и оптимизиране в сравнение със съответните „тривиални“ JS/DOM решения.
  3. Компактният синтаксис, кодът, вграден в тагове, автоматичното управление на събитията и скритата логика на обработка могат да направят отстраняването на грешки по-трудно.
  4. Рамките имат нелек отпечатък и собствен набор от допълнителни инструменти/библиотеки, необходими за функциониране. Повече инструменти означават по-стръмна крива на обучение и повече възможни проблеми със съвместимостта с развитието на платформите.
  5. Нито една рамка на JavaScript елиминира необходимостта да се прибягва до допълнителни библиотеки, за да се възприемат „най-добрите от породата“ решения, налични за потребителски интерфейси.

5. Фалшиви митове и сурова реалност

Приемането на рамка често се ръководи от ефекта „тревата винаги е по-зелена от другата страна“. Лесно е да се заблудите от твърдения, които приличат повече на маркетингови промоции, отколкото на обективно проверими факти.

Мит № 1: По-бързо развитие

Трудно доказуемо, както е трудно да се докаже обратното. Всяко нетривиално уеб приложение отнема много време и много код, дори и с най-модерната рамка.

Мит № 2: По-добра софтуерна архитектура

Добротата и коректността не зависят от инструмента, а от метода, дисциплината и умението. Колкото по-сложна е рамката, толкова по-лесно е да не се възползвате напълно от нейните възможности и да допуснете грешки при структурирането.

Мит № 3: По-добри резултати

За някои рамки това е очевидно невярно.

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

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

Неудобен факт №. 1: Крива на учене и недостиг на умения

Наличието на професионални умения на напреднали платформи е фрагментирано. В дългосрочен план трудностите при получаване на ресурси за поддръжка вероятно ще нарастват.

Неудобен факт №. 2: Остаряване

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

Неудобен факт №. 3: Загуба на технически контрол

По-сложните рамки отслабват способността ви да контролирате вътрешната механика на приложението. Определянето на проблеми и оптимизирането могат да се превърнат в трудни задачи.

Много глупости?

Както очаквах, тази статия има за цел поне отчасти да бъде провокация. Аз съм първият, който се запалва по новите технологии. Всеки път се влюбвам в иновативните инструменти, които случайно използвам. В същото време обаче осъзнавам, че често първоначалният ентусиазъм води до пренебрегване на по-конкретните аспекти относно способността на даден продукт да издържи във времето.

Бих искал да знам какво мислите. Може ли някой от вас да ми даде убедителна причина да приема определена рамка пред други или която и да е рамка вместо никоя?

Може да се интересувате и от тези публикации:



7+1 JavaScript Frameworks Compared
Безпристрастен бенчмарк с малко помощ от AIjavascript.plainenglish.io





Близо ли е краят на всички рамки на JavaScript?
Надстройките, изобретени за ускоряване на широкомащабно развитие, бързо стават безполезни поради AI.javascript.plainenglish.io



Повече съдържание в PlainEnglish.io. Регистрирайте се за нашия безплатен седмичен бюлетин. Следвайте ни в Twitter, LinkedIn, YouTube и Discord .

Интересувате ли се от мащабиране на стартирането на вашия софтуер? Вижте Circuit.