Комментарии 18
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик!
Не смотря на то, что swc хвалят за производительность, babel наминого интересней в плане поддержки, разных возможности. Тот же hot reload не работает в swc и скорее всего и не будет. Также и интеграции с другими инструментами у babel много. Поэтому для разработки веб приложения выберу babel. Да и babel можно настроить эффективно, чтобы быстрее работал. Т.е. в вебе babel себя зарекомендовал хорошо.
Помимо трех указанных сборок, я создал еще одну, в которой код тестируемой фичи оставался нетронутым. Её я далее по тексту буду называть современной.
ссылки "Исходный код теста" ведут на файлы ts. а где "нетронутые" файлы js, которые на графиках называются modern?
Каждая из 4х версий проходили процесс сборки, в т.ч. и современная. Под "нетронутыми" файлами я подразумевал код, который не был скомпилирован. Т.е. в тесте использования асинхронных функций должен был остаться синтаксис async/await.
Вы можете сами посмотреть на собранный код каждой из сборок и убедиться, что в современной версии код фичи остается нетронутым
ничего не понял. исходный год — ts, и его эти трое транспилируют в js?
Да, все верно. Есть исходный код. Его я для удобства решил держать в TS. Исходный код собирается 4 раза в разных конфигурациях. 1 сборка от Babel в ES5, 1 от SWC в ES5 и 1 от TypeScript в ES5.
Ещё одна сборка - modern - должна быть в ES2022. Её я компилировал при помощи SWC. Т.к. собиралась она под ES2022, можно было использовать любой из 3х инструментов, если их правильно настроить. И я решил использовать SWC.
Единственное, для чего используется сборщик в modern сборке - это конвертация кода в JS.
зачем на графиках указана opera? у нее двигло тоже самое, что и у chrome.
Статья очень информативная, спасибо! Я хотел задать вопрос по поводу Modern. Что в данном случае принимается за нее?
Я из платформы ozon.ru, мы компилимся в es5. Недавно катнули на полчаса в прод билд на es2018 и не увидели изменений в перфоманс метриках, кроме очевидного уменьшения js transfer size.
По поводу статьи. Почему нет сравнения var vs let/const? Например, в typescript выяснили, что переключение на var может улучшить производительность компилятора из-за отсутствия проверок TDZ.
Добавлю про разницу в генерируемом коде. Некоторые фичи языка можно скомпилить по разному: в код, максимально строго соответствующий спецификации (strict), или в упрощенный код, который покрывает большую часть реальных кейсов, но может работать некорректно в редких/нестандартных ситуациях. У babel во многих трансформирующих плагинах есть опция loose, которая как раз позволяет включить упрощенный режим. Также можно точечно настраивать через assumptions. Например, с помощью флага ignoreFunctionLength можно устранить разницу в эмите tsc и babel в примере со стрелочной функцией. У typescript фичи языка компилятся то в strict, то в loose код, и это не настраивается, кроме, пожалуй, флага useDefineForClassFields; а в TS 4.5 они сделали breaking change и стали более строго компилить шаблонные строки.
Наверное все зависит от того, как вы считываете метрики. Если transfer size был снижен, значит уже из-за этого метрики могут стать ниже, т.к. пользователь просто напросто быстрее скачает файлы для отображения сайта.
Про разницу генерируемого кода замечание верное. Но если бы я рассматривал матрицу компиляторов со всеми их возможными конфигурациями, бенчмарк и статья бы разрослись раз в 20.
И по поводу let/const. Наверное, да, вы правы. Для более полноценной картины и их следовало добавить. Просто мне показалось, что let и const это совсем уж минорные синтаксические различия. Которые ещё и могут быть изменены минификаторами.
В поисках лучшей версии EcmaScript для сборки сайта