Два пути реинжиниринга фронтенд-решений для повышения скорости.
Более быстрые и легкие веб-интерфейсы — это следующие важные вещи, и команды разработчиков переделывают свои решения, чтобы сделать их быстрее не только потому, что поисковые системы учитывают показатели скорости, но и из-за ценности времени для клиентов. Время — деньги — это поговорка, которую хорошо знает каждый из нас, и в контексте веб-разработки больше времени на создание и загрузку веб-приложения — это деньги, потраченные владельцем веб-приложения и клиентами.
Большинство комнат оптимизации находится на стороне пользователя, в браузере, где манипулирование DOM и его более быстрая визуализация стали приоритетом высшего уровня, который ставит перед инженерами фронтенда непростые времена после того, как они построили и усовершенствовали потрясающий пользовательский интерфейс.
Большая часть медлительности веб-приложений в настоящее время связана с загрузкой веб-страниц из-за постоянно растущего числа сторонних сценариев JavaScript, которые делают пользовательский интерфейс интерактивным и простым в разработке, и которые браузеры должны загружать, компилировать и выполнять. Благодаря минимизации, упаковщикам, разделителям кода и т. д. мы значительно сократили время загрузки JavaScript и его выполнения в браузере, но еще есть возможности для улучшения, и переосмысление дизайна и архитектуры интерфейсных фреймворков — одна из таких областей.
Осознавая эту важную потребность в повышении скорости загрузки, разработчики интерфейсных фреймворков javascript повторно взяли свой исходный код и поработали над ним, чтобы сделать свое решение быстрее, и новые интерфейсные фреймворки специально построены вокруг этого обещания. Если мы возьмем пример React, команда, стоящая за этим фреймворком, разработала более быструю и легкую версию этого фреймворка под названием Preact, специально созданную для скорости, и конкурирующие решения, такие как Svelte, позиционируют себя, чтобы конкурировать с этой оптимизированной версией React. . Тогда решение для более быстрых веб-приложений и опыта — это двусторонний путь, улучшающий уже принятый интерфейсный фреймворк (Preact) или принимающий новый (Svelte или другой, например Inferno, или тот, который я не знаю).
Я знаю, что многие фронтенд-инженеры, такие как вы, знают об этой ситуации и о том, что необходимо сделать, и многие из вас изучают способы оптимизации веб-приложений для сокращения времени загрузки. Например, такие люди, как Nilanth, полностью перестраивают свои приложения, используя новые заявленные более быстрые интерфейсные фреймворки js, такие как Preact, и сравнивают их со старыми, которые они использовали, и если вы читали отчеты о тестах Nilanth здесь в Javascript на простом английском вы увидите, что разница важна, по крайней мере, с моей точки зрения, и эта разница намного важнее, чем та разница, которую я пытался выделить с помощью моего плохого бенчмаркинга статья о React, Vue о основных показателях жизнедеятельности.
В заключение я бы сказал, что производительность разработчиков и эффективность взаимодействия с пользователем — две конкурирующие сильные стороны, которые мы должны использовать для оценки фреймворков. Некоторые делают разработчика более продуктивным, но как насчет результата с точки зрения пользовательского опыта. Некоторые из них сложны в реализации и менее продуктивны, но, возможно, они более эффективны с точки зрения пользовательского опыта.
Давайте вспомним, что я считаю, что пользовательский опыт имеет больший вес и приоритет, чем производительность команды разработчиков программного обеспечения или одного инженера-программиста, такого как я. Но мои навыки управления продуктом и дизайна инстинктивно когнитивно заговорили вслух, чтобы объяснить мне, почему я не сказал менеджера по продукту и дизайнера вместо инженера-программиста, потому что то, что я говорю с вами с этими словами, также касается дизайна и управления техническим продуктом. который касается производительности разработки веб-приложений и тестирования производительности, а также сравнительного анализа не только для принятия технических решений, но и для предоставления лучшего опыта конечным пользователям.
Технические специалисты основывают свои решения на науке, знаниях, данных и технологиях, тогда зачем просто выбирать платформу, не имея четких данных о производительности и пользовательском опыте и почему бы не использовать всю доступную платформу для создания наших решений и предоставить каждому пользователю ту, которая наиболее эффективна в его среде.
PS:С Новым годом всех, кто читает Javascript на простом английском языке, и всех, кому это небезразлично. Я желаю, чтобы 2020 год был лучше, чем этот тревожный год, который мы оставили позади. Я желаю и надеюсь, что этот год станет для вас годом удовлетворения, радости, счастья и успеха в личной и профессиональной жизни. С НОВЫМ ГОДОМ.
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Получите эксклюзивный доступ к возможностям написания и советам в нашем сообществе Discord.
