Safari это новый Internet Explorer? 😳

P.S.
Кстати, на тему эпловского JavaScriptCore у меня готовится ресёрч, скоро завезу тебе материал.

И вообще, думаю объявить эту неделю - неделей JavaScript, браузеров и их движков, так что можешь накидывать своих приколов и рабочих нюансов в комментариях 👇

Ну что малята, добро пожаловать в мир JavaScript движков — это будет длинное путешествие в конце которого мы придём к не однозначным, но интересным результатам 🤡

На данный момент существует только 2 основных решения:

🔹 v8 - разрабатывается Google, используется в Chromium-like браузерах (Chrome, Edge, ...тысячи их), а так же является важной частью рантайма nodejs

🔹 JavaScriptCore - разрабатывается Apple, является частью WebKit и используется во всех версиях Safari, а так же во всех iOS браузерах, включая Chrome. Если вдруг кто не знал, то теперь знай - в iOS версии браузера Chrome не используется v8.

JSC примечателен тем, что после перехода на процессоры M1 - движок реально полетел. Если посмотреть браузерные бенчмарк тесты, то по моим прикидкам прирост в производительности в сравнении с моей x86 версией Chrome составил 50-70% (тест ни разу не претендует на объективность, я просто заставил своих корешей-макодэбилов погонять бенчмарки).

В принципе можешь сам запустить бенч в браузере и закинуть свои результаты в комменты. Сравним, так сказать, у кого движок длиннее быстрее.

✌️IT KEKW NEWS™:
В набор компиляторов GCC была утверждена поддержка языка Rust.

👉 WebKit, как и JavaScriptCore в его составе — также является Open Source разработкой, поэтому его можно взять и прикрутить куда-нибудь, например к ПРИНЦИПИАЛЬНО новому JavaScript рантайму (но об этом чуть позже 😂).

В комментариях к прошлому посту можно увидеть разницу в производительности браузеров на различных платформах.

Но вот если взять два этих двигла и столкнуть их лоб в лоб на amd64, то результаты уже получаются не такими однозначными:

Test       v8      JSC
Geo. mean  10.58   10.95

Цифры измеряются усредненным показателем "runs/s". Бенчмарк проводится фиксированное время - поэтому, чем этот показатель больше, тем лучше - полный результат здесь, там присутствует детальный отчёт.

Важно, что в этом тесте проверяется производительность самого JavaScript движка, а не операций ввода/вывода или других нерелевантных аспектов. Поэтому бенчмарки браузеров будут отличаться от этих результатов - это важно.

Сама бенчмаркалка от Google лежит в этом репозитории.

И конечно же, по АБСОЛЮТНО ОБЪЕКТИВНЫМ РЕЗУЛЬТАТАМ вышло, что в одинаковых условиях на одной платформе
— JSC в среднем быстрее v8 на ~3.5% 🧐

⚡️⚡️BLAZING FAST⚡️⚡️

И тут собственно врывается новый рантайм для JavaScript под названием Bun.

Меня чудовищно возмутили заявления автора в Twitter, о том что Bun быстрее Node.js в 4.5x раза!!!, не менее чудовищно я возмутился с результатов бенчмарка на главной странице сайта - где в серверном рендеринге React приложения показан прирост производительности в 300%!!!

Поэтому я незамедлительно скачал эту адскую поделку и принялся ее бенчмаркать по полной программе.

Во время использования обратил внимание на следующие моменты:

1. Местный аналог NPM просто НЕВЕРОЯТНО быстр, мем про create-react-app скоро станет не актуальным и нам придется искать новую заставку под видосы.

2. Bun реально хорош, я проводил все тесты на Linux/amd64. Конечно не так быстро, как обещано - всего лишь 45-50% прирост в предоставленных бенчмарках в рендеринге SSR на моей машинке. Можно конечно возмутиться - где еще 250%? Но не всё сразу.

Тем не менее это ОТЛИЧНЫЙ результат, +50% к перформансу на ровном месте, это ли не чудо? 😳

ExtremeCode moment ✌️

👉 Почему так быстро?

В качестве причин, автор указывает 2 основных аргумента:
1. В качестве основы используется WebKit и JavaScriptCore
2. Из движка не вырезан Web API, поэтому сохраняется совместимость с браузерными API типа fetch

На основе fetch api кстати говоря и работает сервер в Bun.

И если несколько раньше я приводил Benchmark сравнение по результатам которых JSC не настолько быстрее, чем v8 в одинаковых условиях.

НО! Похоже именно реализация I/O, в частности Http + Web API даёт нам этот самый перформанс в серверном рендеринге - только за счёт сетевого взаимодействия от 50% до 300% но это не точно 🧐

Не стоит забывать, что чисто теоретически за счёт оптимизации WebKit под архитектуру M1 - именно Mac Os получит наибольший прирост в производительности, потому что условный Nodejs не имеет таких оптимизаций.

У Nodejs же еще вырезан Web API и в нём используется собственная реализация модуля Http. Видимо недостаточно быстрая, ну что поделать 🤖

👉 Начни свой день с IT KEKW NEWS™: Unity Software объявили о слиянии с ironSource за $4.4 млрд.

Почитал я, значит, комментарии об этой сделке на YCombinator и чуть не умер от кринжа 😑

ОКАЗЫВАЕТСЯ, что ironSource — печально известная компания, которая занимается распространением вредоносного ПО, типа malware, adware bundlers и приправлено всё это рассылочками спама: Пруф #1, Пруф #2.

Ранее я уже писал про сокращение сотрудников в Unity Software.

UPD: Почему это плохо? Если бы Unity Software полностью выкупила эту компанию, то вопросов бы ни у кого не возникло. Но это СЛИЯНИЕ двух крупных компаний, в результате которого акционеры ironSource получат примерно 26% акций Unity Software — дальше сами додумывайте, к чему это может привести.

Вычёркиваем?

🤡🤡 BLAZING SLOW 🤡🤡

Да ладно, вы и вправду подумали что я просто так это всё оставлю и не попытаюсь детально разобраться в чем же причина такой мега-скорости Bun?

В первую очередь мой острый взгляд пал на React - и в принципе я не прогадал: в марте вышло обновление 18.0 и в нём переделали Stream'ы для Nodejs в серверном рендеринге. Моментально я наткнулся на следующий Issue в github где чувак обратил внимание на то, что у него деградировал перформанс чуть ли не в 5 раз!

Почему это важно? Да всё просто - в Node используется своя версия реализации стриминга. В Deno используется другая реализация. А вот в Bun вообще нет официальной поддержки - авторы используют самопальный polyfill для стриминга отрендеренной страницы.

Поэтому, переписав код бенчмарка и заменив функцию renderToPipeableStream на renderToString результат Nodejs заметно улучшился и разрыв в среднем сократился уже до 25% — заметь, это не 300% разницы и даже не мои изначальные 45%, по результатам самых первых тестов.

Собственно продолжив копаться дальше, я обратил внимание на следующий момент: Bun с какой-то стати игнорирует Http заголовки которые указаны в бенчмарке — а Nodejs в свою очередь наоборот ДОБАВЛЯЕТ лишние заголовки. В итоге разница составляла в среднем: ~130 байт данных, которые приходилось гонять ноде.

Разбираться почему Bun игнорирует заголовки - я не стал, пусть этим разработчики занимаются. Я в свою очередь просто привел Nodejs к тем же самым условиям - важно чтобы заголовки совпадали по размеру, для чистоты эксперимента.

В итоге разрыв сократился до 18-20% в пользу Bun — это мой максимум. Я не использовал никаких кастомных Http серверов, для меня было важно использовать средства чистой Node.js

Более того, если из этих переменных выкинуть React SSR и оставить голые байтики - разрыв будет точно таким же. Я понятия не имею каким образом сетевой код у разработчика Bun вышел на столько производительней, но факт остаётся фактом — это 20% дополнительного перформанса только за счёт I/O.

👉 IT KEKW NEWS™:
CEO Unity Software Джон Ричителло (экс CEO Electronic Arts) в интервью заявил, что все разработчики, которые не планируют включать в свои проекты монетизацию, цитирую - "Ёбаные идиоты", источник.

👉 При этом не стоит забывать, что Bun АБСОЛЮТНО не готов к Production разработке.

В процессе тестов он постоянно падал с разными ошибками, то сервер начнёт код 500 сыпать, то с Segmentation Fault упадёт, то JS код скомпилировать не сможет. Стабильности здесь НЕТ.

Ещё Bun не смог запуститься на WSL, якобы ему ядро Linux не подошло, хотя моя версия ядра попадала под системные требования.

Короче, как по мне - шляпа подает надежды, как минимум она гораздо перспективнее того же Deno, но работы в Bun нужно сделать еще очень много.

К тому же, написана Bun на очень интересном языке программирования, который называется Zig (за шутки про зиги буду банить) - можешь посмотреть, прикольная штука!

👉 Знаете, разница между паттернами MVC и MVP примерно такая же как между куколдом и параноидальным шизом.

MVC(uckold) берёт модельку, знакомит её с вьюхой и наслаждается видом. В это же время MVP(araniod shiz) никого настолько жёстко не подпускает к своей модельке, что сам носится между ней и вьюхой, передавая данные.

Исправление багов в Bun идёт полным ходом. Всё Open Source сообщество сплотилось и начало усердную работу 🤡

🗞 Материалы прошлой недели

🔹 🪦 Надгробие для Internet Explorer

🔹 Интро про JS движки

🔹 Про преимущества WebKit и JavaScriptCore

🔹 Bun ⚡️ НЕВЕРОЯТНО БЫСТРЫЙ

🔹 Почему Bun такой быстрый

🔹 Unity Software ТОЧНО ВСЁ

🔹 Bun 🤡 НЕВЕРОЯТНО МЕДЛЕННЫЙ

🔹 Bun не работает как надо

Ну всё, недельная эпопея с JavaScript закончена, по такому поводу можно бахнуть 🍺🥴

Я тут, смотрю, айтишнички любят по выгорать в последнее время. Весь интернет мне засрали гайдами в стиле "Устал? Ну так пойди отдохни". Знаете, что я подумал? Раз выгоральщиков так много, значит им надо помогать.

P.S.
Ну и если я какой-то текст дочитываю до конца, то никогда не поленюсь поставить лайк и в комменте написать что-то типа: "Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?"

https://youtu.be/LOYpqjtsbic

😳 Rust способен залить в 3-х литровую банку 5 литров мочи или ВСЯ СУТЬ BENCHMARK ТЕСТИРОВАНИЯ

Анонимные источники подкинули мне контент, значит - есть web server под названием faf, что является сокращением от Fast as Fuck [вставить шутку про скорострела] - написан он на 100% с использованием Rust. В Benchmark тестах он показывает феноменальный результат нарушая все мыслимые и немыслимые законы физики.

Господа на GitHub уже обратили внимание, что физический предел протокола при данном Benchmark'е c каналом 10 gbit/s имеет следующие ограничения:
⏫ запросов - 7.2kk в секунду и ⏬ ответов - 9.4kk в секунду.

faf обработал 8.6kk запросов/ответов в секунду 🙉

Каким образом сервер смог выйти за рамки отправленных запросов — история умалчивает. Но факт остается фактом, faf отправляет ответ раньше, чем от клиента приходит запрос на сервер 🙈

ВОТ ОНА ВСЯ СУТЬ БЫСТРОТЫ RUST!
Ну и конечно же, PRESS 💩 FOR BLAZINGLY FAST

👉 IT KEKW NEWS™:
CEO Unity Software Джон Ричителло (экс CEO Electronic Arts) извинился за то, что назвал разработчиков, которые не планируют включать в свои проекты монетизацию, цитирую — "Ёбаными идиотами", источник.

Прощаем?

Каждый раз кринжую, когда читаю что-то вроде "Учи зык Х, а не язык Y, потому что он быстрее", просто потому что за одно предложение, мало чего, советчик умудряется спиздеть дважды, так ещё и дать дерьмовый совет.

Во-первых, язык - это всего лишь спецификация. Как ты понимаешь, сама по себе она не может быть ни медленной, ни быстрой. Заявлять, что какая-нибудь Java медленная, это всё равно, что определить с помощью инструкции по сборке шкафа - выдержит ли этот шкаф удар молотком?

"Скорость" определяется, в первую очередь реализацией этой спецификации. Nodejs может быть медленным, JVM может быть медленной, JavaScript быть медленным не может.

Во-вторых, "скорость" может быть действительно востребованным показателем. Ты вполне можешь перебирать различные платформы в поиске наилучшей производительности под своё приложение, для которого важно выдавать обратную связь за 0.0000000001 секунду. Только делается это под конкретное приложение и требования.

Никому в хер не впёрлась "скорость", если ОНА НЕ ОКАЗЫВАЕТ ЗНАЧИТЕЛЬНЫЙ ЭФФЕКТ НА ВЫПОЛНЯЕМУЮ ЗАДАЧУ. Какая разница, выдаёт тебе приложение обратную связь за 200мс или 100мс? Пользователь просто не в состоянии заметить разницу.

Далеко не все задачи требовательны к перфомансу настолько, чтобы на уровне выбора платформы начинать пердолиться. Если даже задача и требовательна, то в первую очередь ищут "бутылочные горлышки" и устраняют их, а не сразу же в панике бегут менять платформу. Именно поэтому мы (программисты) пользуемся платформами, которые обеспечивают различный уровень перфоманса, а не самыми "быстрыми".

И именно поэтому рекомендовать кому-то учить какой-то язык, только потому что он 🤡🤡 БЛЕЙЗИНГЛИ ФАСТ 🤡🤡 тупейшая затея. Учите что хотите. Излишний перфоманс нужен только под узкий пул задач, для остальных достаточно будет и не самого перфомансного перфоманса.

PHP Developer moment ✌️