💡 Про оптимизацию и Мурыча

— Нужна ли оптимизация JavaScript обычному разработчику?
— Чем лучше будут оптимизированы библиотеки и фреймворки, тем меньше нужно залазить в оптимизацию прикладным программистам.

Кто-то думает, что это важно и интересно, другие считают, что это все фетишизм и карго культ, но в действительности все гораздо сложнее.
1. Есть продуктовые разработчики, их нельзя пускать к оптимизации, их задача эффективно решать задачи предметной области. Но у них есть соблазн и непреодолимое желание что-то поизмерять и пооптимизировать, потому, что их уже тошнит от монотонной работы... формочки, модельки и апишки. Есть ощущение, что ты мнешь дерьмо в ступе и далек от настоящего программирования. Хоть это не так, нужно вникать в предметную область, которая не так проста, вот только не хочется...
2. Есть специальные люди, вот как Мурыч, которые с утра до вечера только и занимаются оптимизацией, да... как основной профессией. Это не так просто, как кажется прикладным программистам, невозможно просто повторить операцию 10 млн раз и сравнить несколько ее реализаций, тут очень просто измерить совсем не то, что вы хотели измерить, нужно иметь большой опыт именно измерений и хорошо знать устройство виртуальной машины.
3. Есть системные программисты, которые пишут платформы, библиотеки и фреймворки, они бы хотели оптимизировать свой код и именно им это действительно нужно, но в большинстве случаев они тоже гонятся за популярностью своего продукта, и на декомпиляцию, дебаг и профайлинг времени у них мало.
4. Так вот, профессиональные оптимизаторы вполне могут подсказать им основные типовые шаблоны эффективного кода и они даже поймут многое, потому, что часто умеют опыт си и ассемблера, ну в основном понимают, так даже от понимания низкоуровневого языка, системный код становится быстрее в разы, потому, что человек может себе в общих чертах представить оптимизации, но не про все знает.
5. В прикладном коде хочется писать более понятно и надежно, что не всегда совпадает с оптимизациями. Ну часто и совпадает, но не всегда. Если их немного обучить писать оптимально под V8, добавить автоматическую проверку оптимизаций линтером, паттерны, ревью кода... то можно меньше заморачиваться оптимизацией на прикладном уровне.
6. Прикладным прогпраммистам нужно больше заниматься на семантикой, надёжностью и поддерживаемостью кода, но немного простых правил оптимизации и им тоже можно внушить. Бессмысленно прикладным программистам самим писать тесты производительности, исследовать поведение виртуальной машины, дезасемблировать код, для того, чтобы вникнуть, нужно лет 5. Но вот не писать примеси, не делать optional полей и не использовать деструктуризацию массива, не использовать юнион тайпы для классов и структур - это важно и нужно.

💡 Вообще, стилей взаимодейстия больше, разработчики привыкли думать в терминах конкретных технологий и протоколов (websocket, grpc, http api, sse), но имеет смысл обобщить:
- REST/Resources
- RPC/Calls
- Events/Messages
- Shared Database
- Simple data sync
- Operation log sync
- Peer-to-Peer
Описание тут: https://github.com/tshemsedinov/feed/blob/main/README.md#communication-styles-2025-02-24

💡 Как сделать новый популярный фреймворк:
1. Взять один случайный паттерн
2. Дать ему неузнаваемое название
3. Сделать презентацию, пообещав всем, что это и есть решение всех проблем