Pull to refresh
210
0
Андрей «A.I.» Ситник @Iskin

Фронтенд-разработчик

Send message

Включи VPN. Роскомнадзор забанил Netlify.

24TTL?

А что это такое?


CDN?

CDN никак не решает проблему того, что 500 КБ надо откомпилировать и запустить. 3,8 секунд нагрузки на ЦПУ и 0,5 секунд фриза из отчёта Google Lighthouse «до» — это как раз время запуска Three.js.


Статья как раз про решение вопроса запуска JS, а не его скачивания.

Этот бенчмарк очень синтетический. Он использует блокировку по одному и тому же ресурсу.

Да, нельзя легко вызывать функции, которые возвращают Promise

Плагин может читать с диска или вызывать другие инструменты.

Например, давно есть идея сделать babel-плагин, чтобы прогонять postcss-плагины через CSS-в-JS. Но это сделать сложно, так как в PostCSS много асинхронных плагинов (например, те, что конвертируют картинки в WebP) — в итоге приходится делать костыли.

Или, например, плагин может читать/писать на диск какой-то кеш.
1. Костыль. Почему не сделать нормальный асинхронный API для плагинов?
2. Ты неправильно тестируешь. Запусти много задач, которые будут читать диск или что-то ожидать от системы. Асинхронность позволит другому JS-коду выполняться, пока твоя функция ожидает данные от файловой системы или сети. Без асинхронности вся виртуальная машина будет заблокирована одним HTTP- или IO-запросом. Но на математике или на одной функции результата не будет — ты прав.

Увы, мы очень далеки от зрелости. Стагнация проявляется в том, что инструменты выбирают по моде а не по тому, подходят ли они к задаче. Подходящие инструменты использовать боятся, так как не мейнстрим и не модно.

Проблема в том, что из-за моды все берут ожно и то же решение, даже для задач, где оно не подходит

ПРоблема не в том, что нет новый версий. А проблеа стагнации, что используются неподходящие под задачи инструменты из-за моды.

Документация для плагинов — тоже довольно плохая.

Смысл, что нельзя использовать асинхронный код в плагине

  1. Например, внутри babel-плагина нельзя вызывать какую-то асинхронную функцию.
  2. А если вызывать *Sync версии функций, то это плохо влияет на производительность
Тут скорее ваши предпочтения не совпадают с теми, что у разработчиков Vue.

Когда я говорил про отличный DX, я имел в виду хорошую документацию (например, на русский она была переведена на год раньше Реакта), браузерный DevTools, готовые решения, а не «найди на npm и собери сам».
А что именно не нравится в тулинге и что нравится в тулинге Реакта?
Таких архитекторов единицы. Достаточно посмотреть сколько фронтендеров гордяться, что сделали блог на 3-4 поста на Gatsby.js с 500 КБ JS.
Или даже граблями, которыми все забивают гвозди, хоть не удобно, потому что всем сказали, что грабли — это модно.
Конечно. Напиши мне в личку в Тви twitter.com/andrey_sitnik со ссылкой.
Хороший архитектор не станет брать React из-за того что сейчас так можно.

Ага. Я согласен. И таких примеров единицы.

Я не гвоорю, что нет выбора. Я говорю, что новые револционные идеи часто не находят отклика из-за того, что маркетинговые каналы перекрыты. Выбор есть. Но чтобы сделать правильный выбор, надо узнать о наличии альтернатив.

А сейчас даже Parcel люди не знают (или боятся), хотя он исправляет то, за что все критикую Вебпак (отвратительный DX с кучей конфигов). То же самое с Vue — все критикую Реакт что там ничего не понятно и сторонние библиотеки (типа роутера) плохие, но продолжают боятся Vue (так как он не мейнстрим).

Правом выбора реально пользуются единицы.
Речь про то что стагнация только началась. Во времена jQuery легко было прийти с новыми идеями.

Information

Rating
5,062-nd
Location
Barcelona, Barcelona, Испания
Date of birth
Registered
Activity