Я не уверен, что когда-либо существовал язык, который бы так ненавидели, но при этом так широко использовали, как JavaScript.
Я не отношусь к этому лагерю. Мне вполне нравится JavaScript. Его причуды, его недостатки. То, как он каким-то образом опирается на Scheme, но ему суждено стать самым распространенным языком программирования.
JavaScript был задуман как компаньон. Язык сценариев для выполнения простых задач, чтобы помочь небольшим интерактивным элементам на странице. Язык веба.
Но веб вышел далеко за рамки того, чем он был изначально. Он охватывает все виды опыта и устройств. От компьютеров, мобильных телефонов, телевизоров и часов до всевозможных IoT-устройств. От простого сайта с контентом до захватывающей видеоигры виртуальной реальности.
И JavaScript появился вместе с ним.
Феноменальные космические силы, ничтожно малое жизненное пространство
Основы веб-технологий неоднократно показывали нам, насколько критична сеть как ресурс. Большинство программистов заботятся о памяти или скорости диска, но веб всегда заботится о сети. Это, наряду со свободным выбором платформ и действительно единственным доступным вариантом, привело к тому, что JavaScript развивался очень своеобразно.
Если JavaScript по любым меркам является интерпретируемым динамически типизированным скриптовым языком, то теперь он представляет собой транспилятор, плавильный котел DSL и целый инструментарий. Машина JavaScript уже давно заменила душу. Он должен быть всем для всех, но при этом быть незаметно маленьким и легким по ресурсам.
Когда я смотрю на то, как мы разрабатываем приложения на JavaScript, я вижу, что, в конечном счете, независимо от того, насколько велик потенциал, в разговоре по-прежнему руководствуются наименьшим общим знаменателем возможностей устройства и скорости сети. Это неизбежная истина. Закон физики, которому мы должны подчиняться.
Роль фреймворков JavaScript
Нередко язык или фреймворк помогают разработчикам достичь желаемой производительности. Но как насчет удаления нашего собственного кода? Наиболее ориентированные на производительность JavaScript-фреймворки одержимы идеей позволить нам выполнять меньше JavaScript.
JavaScript, вероятно, больше, чем кто-либо другой, озабочен тем, чтобы производить меньше JavaScript. Вы видите это, когда такие фреймворки, как Svelte или Solid, значительно меньше, чем Stimulus или даже Alpine. Это видно по всему тому, что Marko, Astro и Qwik сосредоточились на частичной гидратации. Даже такие вещи, как React Server Components, отражают эту озабоченность.
0 кб JavaScript в вашем будущем?
Райан Карниато для This is Learning ・ May 3 ’21 ・ 6 min read
Мы в значительной степени полагаемся на бандлеры и компиляторы, чтобы удалить каждый бит кода, который нам не нужен. Цель — оптимизировать каждый последний бит выполнения в наших шаблонах. Чтобы сделать все это возможным, мы создаем специальные языки для лучшего отражения намерений. Мы анализируем наши приложения, чтобы отделить код, который может быть запущен только на сервере, от кода, который работает в обоих местах. И мы используем эту информацию для снижения затрат на сериализацию данных.
Мы даже используем рендеринг на стороне сервера, чтобы определить, как снизить затраты на загрузку приложения в браузере, благодаря таким новым концепциям, как возобновляемость. Запуск приложения на сервере заполняет пробелы, которые компиляция не может устранить заранее.
Мэдисон Канна@madisonkannaВсе в порядке, детка? Ты едва прикоснулась к новейшему JS-фреймворку.03:32 AM — 04 Aug 2022
Как говорится, каждую неделю новый JavaScript Framework. Постоянная борьба за инновации и расширение границ. Фоновое знание о том, что никогда нельзя быть удовлетворенным статус-кво, преследует это пространство. Для этого даже существует термин. Усталость JavaScript. Закопанные в сложности обучения и выбора. И все же они продолжают подниматься, как нескончаемый поток нежити. Каждый из них опирается на останки прошлого.
Это не обязательно плохо. Это знак того, что есть еще над чем работать. Если вы измените свою точку зрения на то, что статус-кво — это скорее 4 из 10, а не 8 из 10, то ничего удивительного в этом нет. Усталость от JavaScript вызвана тем, что реальность не соответствует ожиданиям. Давайте поговорим об этих ожиданиях подробнее.
Парадокс JavaScript
Мы сами создали проблемы, которые решаем. Мы стремимся к большей интерактивности и лучшему пользовательскому опыту. Не так сильно полагаться на сеть. Желание использовать единый набор инструментов для создания любых сайтов и приложений для Интернета.
Но это нечто большее. Мы могли бы взять язык бэкенда и посыпать его JavaScript, и какое-то время это было бы неплохо. Механически это все, что мы когда-либо хотели. Но практически невозможно повернуть время вспять в отношении опыта разработчиков, который мы наблюдали в течение последнего десятилетия. Возможность создавать вещи как единое приложение, вместо того чтобы продираться через JavaScript как через постоянно растущую, но нежелательную сироту поверх нашего серверного приложения.
Если уж на то пошло, мы получаем все больше и больше преимуществ от сокращения границ между передней и задней частями. До такой степени, что даже не так уж противоречиво предположить, что использование JavaScript в полном стеке — это лучший способ поставлять меньше JavaScript.
Время выполнения другого языка может дать экономию в десятки мс, но когда мы говорим о влиянии, которое мы можем оказать на конечного пользователя на конечном устройстве благодаря использованию JavaScript на сервере, оно может исчисляться сотнями мс. Это на порядок более значительный эффект для конечного пользователя.
Но, признаться, это может повлиять на вашу прибыль. Единственной целью существования JavaScript был браузер, а теперь мы перенесли его повсюду.
Мы застряли?
Ну, там, где я сижу, по крайней мере, пока. Это прямое продолжение того, что JavaScript является единственным языком браузера. WASM показывает многообещающие результаты в некоторых областях, но пока еще не продвинулся в области пользовательского интерфейса. Существуют внутренние издержки, которые ему необходимо преодолеть.
zack@zack_overflowТак что я не думаю, что перфект — это супер убедительная причина для использования фронтенд-фреймворка WASM.И именно поэтому переписывание React/Svelte/SolidJS/etc. на WASM не даст значительного прироста производительности, если вообще даст.
16:34 PM — 27 Jul 2022
Если устройство и сеть конечного пользователя находятся на критическом пути, оптимизация под них может быть самым эффективным, что мы можем сделать. И если лучший способ борьбы с JavaScript — это использование большего количества JavaScript, то мы на этом и остановились.
Я уверен, что кто-то укажет на серверно-управляемые архитектуры, такие как LiveView или HTMX, и они содержат отличные подходы к снижению затрат. Они абстрагируют часть JavaScript от разработчика для поддержания серверно-ориентированного представления. Однако, когда вам нужна интерактивность на клиенте (по какой-либо причине, в автономном режиме и т.д.), когда JavaScript — единственный выбор, что ж, JavaScript — единственный выбор.
Учитывая это, инструментарий для JavaScript перешел на Rust и Go (и Zig). Есть желание повысить производительность и найти все более творческие способы их использования, чтобы обеспечить возможность работы с JavaScript.
В поисках серебряной пули
Не поймите меня неправильно. Вы всегда можете просто создать HTML-сайт и добавить на него JavaScript по мере необходимости. Вся эта мотивация исходит из желания масштабировать разработку одного приложения. Это касается не каждого проекта.
Но мне показалось интересным, что в ходе поиска я обнаружил, что существует более одного способа решения проблемы для устройств и сетей низкого класса. Я думаю, что для тех, кто привык к быстрым сетям с перебоями, как в метро, легко думать о том, как оптимизировать для какого-то базового случая, не меняя уравнения.
Адди Османи (Addy Osmani)@addyosmaniУ eBay был большой год оптимизации производительности: bit.ly/ebayspeed ~ меньшая полезная нагрузка, умная предварительная выборка & краевое кэширование оказало влияние.На каждые 100 мс улучшения времени загрузки страницы поиска они наблюдали 0,5% увеличение количества добавлений в корзину! ⚡️
07:30 AM — 28 Jan 2020
Если посмотреть на то, как работает крупная международная электронная коммерция, например Amazon или eBay, или такие сервисы, как Google Search, — все это подтверждает сказанное. Создавайте маленькие, легкие и разумно используйте сервер, чтобы получить максимально быструю начальную загрузку и взаимодействие. Существует достаточно исследований, показывающих, как это влияет на доходы.
Однако в Китае и некоторых других регионах, где интернет не так устойчив, они приняли совершенно другую модель. Мини-программы, которые немного похожи на PWA, загружаются в существующие мобильные приложения в качестве подключаемых суб-приложений. Своего рода локализованный магазин приложений.
Вместо оптимизации начальной загрузки страницы они оптимизируют фоновую загрузку данных, чтобы приложение работало как можно лучше независимо от ресурсов сети или устройства. Часто использование большего количества JavaScript для экономии будущих сетевых запросов считается чрезвычайно полезным. В результате мы имеем целую экосистему веб-приложений в ограниченных средах, совершенно не заинтересованных в использовании сервера.
Если можно сделать какой-то вывод, то не всегда все так однозначно. Если бы и существовал способ преодолеть этот разрыв, то, вероятно, сегодня он заключается в более активном использовании JavaScript.
Заключение
Эта тема задает нам много вопросов. Должен ли JavaScript продолжать «съедать» бэкенд? Есть ли лучшие способы использовать другие языки и платформы вместе с JavaScript? Стоит ли нам вообще гнаться за единым видением веба?
А может быть, нам всем следует задаться вопросом: как мы допустили такую монополию?
Хотя у вас есть бесконечный выбор в том, как создавать свои веб-сайты и приложения, у JavaScript есть существенное преимущество. Настолько, что это, вероятно, лучший способ на самом деле поставлять меньше JavaScript своим клиентам. И, на мой взгляд, это просто безумие.