Двата пътя за реинженеринг на интерфейсни решения за скорост.

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

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

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

Осъзнавайки тази важна необходимост от подобряване на скоростта на зареждане, създателите на предни рамки на javascript възобновиха своя изходен код и работиха върху него, за да направят решението си по-бързо, а новите предни рамки са изградени специално около това обещание. Ако вземем примера на React, екипът зад тази рамка дойде с по-бърза и по-лека версия на тази рамка, наречена Preact, целенасочено създадена за скорост, а конкурентни решения като Svelte са се позиционирали да се конкурират с тази оптимизирана версия на React . Тогава решението за по-бързи уеб приложения и преживявания е двупосочен път, подобряване на вече възприетата предна рамка (Preact) или приемане на нова (Svelte или друга като Inferno или такава, която не познавам).

Наясно съм, че много фронтенд инженери като вас са наясно с тази ситуация и какво трябва да се направи и много от вас проучват начини за оптимизиране на уеб приложенията за намаляване на времето за зареждане. Например хора като Nilanth възстановяват целите си приложения, използвайки нови декларирани по-бързи js фронтенд рамки като Preact и ги сравняват със старите, които са използвали, и ако прочетете отчета за сравнителния тест на Nilanth тук в Javascript на обикновен английски ще видите, че разликата е важна поне от моя гледна точка и тази разлика е много по-важна от тази разлика, която се опитвах да подчертая с моя лош бенчмаркинг статия за React, Vue за основните жизнени показатели.

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

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

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

PS:Честита нова година на всички читатели на Javascript на обикновен английски и на всички, които се интересуват. Иска ми се 2020 г. да бъде по-добра от тази тревожна година, която оставихме зад гърба си. Пожелавам и се надявам тази година да бъде за вас година на удовлетворение, радост, щастие и успех в личния и професионалния живот. ЧЕСТИТА НОВА ГОДИНА.

Повече съдържание в plainenglish.io. Регистрирайте се за нашия „безплатен седмичен бюлетин“. Получете изключителен достъп до възможности за писане и съвети в нашата общност Discord.