Дмитрий Беляев @bingo347
Разработчик Rust
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Fullstack Developer
Lead
Разработчик Rust
1. связанность. Да-да, именно она. Для того, чтобы слушать событие, мне нужно знать его имя, как следствие слушатель уже что-то знает об отправителе.
2. отсутствие контроля. Без дополнительных абстракций вещать может кто угодно и что угодно. Если модуль А и модуль Б назовут свои события одинаково, будет конфликт.
3. хаос потока исполнения. В идеальном мире модули общаются только через шину событий. Неоднократно в проектах реализующих данный патерн натыкался на ситуации, когда одно событие порождает множество других. Это очень сложно отлаживать, особенно если некое событие отправляется из нескольких мест.
Поставленную задачу низкой связанности гораздо лучше решает связка патернов «машина состояний» (redux) и «наблюдатель» (rx.js)
1. Сборка шаблонов в рантайме. Это черевато проблемами с производительностью. Если правильно понял принятое решение, на клиент грузится несжатый исходник шаблона, что приводит к передаче лишних данных по сети. После исходник компилируется, что тратит ресурсы клиента.
2. Отсутствует проверка шаблона на ошибки. Любой незакрытый тег, отсутствующая переменная или метод просто уронят компонент.
Сама идея подгружать шаблоны, или даже компоненты целиком, очень даже стоящая. Но все таки должна быть сборка, которая как уменьшит объем загружаемых на клиент данных, так и может выявить ошибки в шаблоне до попадания в продакшн.
Так же вангую еще и третью проблему: системы контроля версий не используются, на сколько понял файлы шаблонов просто заливаются на сервер (ftp, scp, samba, rsync — не важно, они все ненадежны для выкладывания на продакшн). Нет разрешения конфликтов, нет возможности быстро откатится, нет истории правок, сложно автоматизировать сборку.
Также в текущей реализации вижу проблему внедрения данного решения в существующие проекты, придется править практически всю кодовую базу проекта, патчинг require в одном месте тут выглядит более привлекательным
Ну и напоследок, допустим Ваш пакет станет очень популярным, Вы можете дать гарантии, что пакет достаточно защищен от атак злоумышленников?
Теперь подумайте вот о чем:
1. На каждый экземпляр объекта созданного таким образом будут создаваться новые функции-методы. Это засоряет память, это убивает оптимизацию
Функции в js компилируются в момент первого вызова и оптимизируются при нескольких последующих вызовах. В случае Вашего подхода это будет делаться для каждого инстанса, что дорого, очень
Если же использовать правильный подход с прототипами функции будут созданы и скомпилированы только 1 раз, все инстансы будут использовать одну и ту же функцию. Мы экономим память. Инстанс создается быстрее. Инстанс работает быстрее, когда его методы уже скомпилированы при работе с предыдущим инстансом.
2. Как быть с наследованием? Допустим я хочу на базе Вашего двухсвязного списка сделать список с произвольным доступом на чтение и возможностью итерации. Если бы были прототипы — я бы относледовался от Вашего прототипа и добавил бы необходимые мне методы, но Ваш код я не смогу переиспользовать, это плохо
У меня одного плохо сочетается понятие "реалтайм" с тормозами socket.io?
подобные оптимизации — пережиток далекого прошлого
более того, подобная «оптимизация» может даже замедлить код
Моя репутация разработчика для меня дороже, чем работа в распиаренном бренде типа Apple, который производит низкокачественный софт, но если меня все таки примут, то примерно через год браузер сафари наконец то будет соответствовать веб-стандартам
Опыт использования блокировщиков у меня лично такой…
это где такую взять? на офф сайте только 6.9.4 и 7.4.0 на текущий момент
Исходники тестов:
Чекер:
Результат:
tryCatch Function is not optimized
forOf Function is not optimized
forIn Function is optimized
constDecl Function is optimized
letDecl Function is optimized
argsRest Function is optimized by TurboFan
argumentsRewrite Function is optimized
argumentsLeak1 Function is not optimized
argumentsLeak2 Function is not optimized
argumentsLeakToSecondArgOfApply Function is optimized
defaultArguments Function is optimized
arrayDestruct Function is not optimized
objectDestruct Function is optimized
generatorSimple Function is not optimized
generatorInfinity Function is not optimized
infinityLoop Function is optimized
containsObjectLiteralWithProto Function is not optimized
containsObjectLiteralWithGetter Function is not optimized
containsObjectLiteralWithSetter Function is not optimized
classStaticMethod Function is optimized
ClassConstructor Function is optimized
Go ровесник node.js, оба появились в 2009
У обоих развитое комьюнити
Так что странно упомянуть один и упустить другой