В целом, я согласен, что обратная связь нужна. Но получать ее в виде интервью крайне сомнительно, т.к. интервьюером будет HR. Не знаю, как у большинства людей, но у меня в 2х прошлых компаниях из 2х именно HR играл значительную роль, почему я уходил. В последней компании решение об уходе на 90% состояло из-за ряда ее действий в течение полутора лет. И, естественно, отдавать полноценную достоверную обратную связь при личном общении с таким человеком будет проблематично
Ну слушайте, я не хочу обобщать, но учась в ИТМО (как мне известно один из лучших в стране по ИТ), я получил несколько "отлично" по профильным предметам буквально от того, что преподаватели на занятия не ходили. А в магистратуре из-за разброса багажа знаний у студентов, профессоры читали лекции только по самому базовому материалу, и в результате в магистратуре я получил исключительно повторение бакалавриата
Вам интересны валидаторы, которые применяются на проекте или просто интересно, какими они должны быть? Во втором случае можно зайти на сайт с документацией, там довольно много примеров)
Кстати, в случае использовании схемы и на бэке, и на фронте, можно на бэкенде схемы создавать в ручном режиме, т.к. реактивность там ни к чему. А ещё можно на бэкенде не использовать вообще @watch декораторы, если в них нет необходимости, а на фронте наследоваться от бэковых схем
Я думаю, всегда, когда бэкенд пишется не на JavaScript придется дублировать логику валидации. Но если таки JavaScript используется, схемы можно без проблемы использовать и там. Они не привязаны к DOM'у)
А, я понял о чем вы. Вы правы, можно через решить проблему с компьютед. Но т.к. в схеме есть возможность ручной валидации, в ней есть функции для расчета ошибки. И они же используются в autorun, чтобы просто переиспользовать логику.
Однако, при помощью computed можно было бы переписать расчет условия валидации. Хотя функционально он бы все равно остался таким же, но кода так немного поменьше получилось бы
Это сделано для оптимизации. Навешивать глобально computed на объект, который бы рассчитывал валидацию сразу для всех полей можно, но в таком случае при изменении одного поля, происходил бы полный перерасчет валидации всего объекта. А так можно удобно локализовать необходимые расчеты
Наверное все зависит от того, как вы считываете метрики. Если transfer size был снижен, значит уже из-за этого метрики могут стать ниже, т.к. пользователь просто напросто быстрее скачает файлы для отображения сайта.
Про разницу генерируемого кода замечание верное. Но если бы я рассматривал матрицу компиляторов со всеми их возможными конфигурациями, бенчмарк и статья бы разрослись раз в 20.
И по поводу let/const. Наверное, да, вы правы. Для более полноценной картины и их следовало добавить. Просто мне показалось, что let и const это совсем уж минорные синтаксические различия. Которые ещё и могут быть изменены минификаторами.
На случай, если вам было интересно, будет ли наблюдаться разница между различными V8 браузерами. Да и все-таки Opera это надстройка над Chromium, не совсем уж клон Chrome.
Да, все верно. Есть исходный код. Его я для удобства решил держать в TS. Исходный код собирается 4 раза в разных конфигурациях. 1 сборка от Babel в ES5, 1 от SWC в ES5 и 1 от TypeScript в ES5.
Ещё одна сборка - modern - должна быть в ES2022. Её я компилировал при помощи SWC. Т.к. собиралась она под ES2022, можно было использовать любой из 3х инструментов, если их правильно настроить. И я решил использовать SWC.
Единственное, для чего используется сборщик в modern сборке - это конвертация кода в JS.
Каждая из 4х версий проходили процесс сборки, в т.ч. и современная. Под "нетронутыми" файлами я подразумевал код, который не был скомпилирован. Т.е. в тесте использования асинхронных функций должен был остаться синтаксис async/await.
Вы можете сами посмотреть на собранный код каждой из сборок и убедиться, что в современной версии код фичи остается нетронутым
Babel действительно себя хорошо зарекомендовал. Однако, я не очень понял, почему в SWC не работает горячая перезагрузка? Быть может вы о какой-то старой версии говорите? Просто не помню за ним таких проблем.
Понял вас. Но судя по информации из Readme в репозитории, на который вы сами и сослались, прибегать к такому приему не стоит. Разработчики V8 подвергают критике применение практик, описываемых в OptimizeJS. И по мне так, если честно, разработчики V8 вызывают гораздо больше доверия, чем разработчик, прямым текстом говорящий в своем репозитории, что поддержка его библиотеки не планируется
Не совсем понял, почему мой ответ отличается от реальности. Я в статье указал, что главный файл должен быть указан в package.json, и ответ я написал, опираясь на то, что вы уже осведомлены об этом правиле.
И все же я считаю, что в статье есть смысл. Не все люди знают как работают импорты, и таким людям я помог в этом разобраться. Механизм разделения сборок будет полезен даже в случае, если минификация будет проводиться исключительно в конечном продукте.
К тому же минификация пакета при разработке пакета и при разработке конечного продукта отличаются. Я описал, как сделать минификацию более качественно в рамках одной единицы кода - вашего пакета. Без помощи разработчика пакета, минификация будет менее качественной.
А если дело именно в Node.JS, то по поводу минификации пакета, используемого для него, я уже согласился, так что не понимаю, зачем вы в очередной раз пытаетесь доказать свою правоту.
В целом, я согласен, что обратная связь нужна. Но получать ее в виде интервью крайне сомнительно, т.к. интервьюером будет HR. Не знаю, как у большинства людей, но у меня в 2х прошлых компаниях из 2х именно HR играл значительную роль, почему я уходил. В последней компании решение об уходе на 90% состояло из-за ряда ее действий в течение полутора лет. И, естественно, отдавать полноценную достоверную обратную связь при личном общении с таким человеком будет проблематично
Ну слушайте, я не хочу обобщать, но учась в ИТМО (как мне известно один из лучших в стране по ИТ), я получил несколько "отлично" по профильным предметам буквально от того, что преподаватели на занятия не ходили. А в магистратуре из-за разброса багажа знаний у студентов, профессоры читали лекции только по самому базовому материалу, и в результате в магистратуре я получил исключительно повторение бакалавриата
Вам интересны валидаторы, которые применяются на проекте или просто интересно, какими они должны быть? Во втором случае можно зайти на сайт с документацией, там довольно много примеров)
Кстати, в случае использовании схемы и на бэке, и на фронте, можно на бэкенде схемы создавать в ручном режиме, т.к. реактивность там ни к чему. А ещё можно на бэкенде не использовать вообще
@watchдекораторы, если в них нет необходимости, а на фронте наследоваться от бэковых схемЯ думаю, всегда, когда бэкенд пишется не на JavaScript придется дублировать логику валидации. Но если таки JavaScript используется, схемы можно без проблемы использовать и там. Они не привязаны к DOM'у)
А, я понял о чем вы. Вы правы, можно через решить проблему с компьютед. Но т.к. в схеме есть возможность ручной валидации, в ней есть функции для расчета ошибки. И они же используются в autorun, чтобы просто переиспользовать логику.
Однако, при помощью
computedможно было бы переписать расчет условия валидации. Хотя функционально он бы все равно остался таким же, но кода так немного поменьше получилось быЭто сделано для оптимизации. Навешивать глобально
computedна объект, который бы рассчитывал валидацию сразу для всех полей можно, но в таком случае при изменении одного поля, происходил бы полный перерасчет валидации всего объекта. А так можно удобно локализовать необходимые расчетыДа, на бэкенде с декораторами разработчики давно привычные. Но на фронте это штука свежая
Наверное все зависит от того, как вы считываете метрики. Если transfer size был снижен, значит уже из-за этого метрики могут стать ниже, т.к. пользователь просто напросто быстрее скачает файлы для отображения сайта.
Про разницу генерируемого кода замечание верное. Но если бы я рассматривал матрицу компиляторов со всеми их возможными конфигурациями, бенчмарк и статья бы разрослись раз в 20.
И по поводу let/const. Наверное, да, вы правы. Для более полноценной картины и их следовало добавить. Просто мне показалось, что let и const это совсем уж минорные синтаксические различия. Которые ещё и могут быть изменены минификаторами.
Если говорить о графиках. Но если вы про секцию о том, как мы в компании переходили на "современную" сборку, то для себя мы решили использовать es2018
В данном случае современной сборкой считался код стандарта ES2022
На случай, если вам было интересно, будет ли наблюдаться разница между различными V8 браузерами. Да и все-таки Opera это надстройка над Chromium, не совсем уж клон Chrome.
Да, все верно. Есть исходный код. Его я для удобства решил держать в TS. Исходный код собирается 4 раза в разных конфигурациях. 1 сборка от Babel в ES5, 1 от SWC в ES5 и 1 от TypeScript в ES5.
Ещё одна сборка - modern - должна быть в ES2022. Её я компилировал при помощи SWC. Т.к. собиралась она под ES2022, можно было использовать любой из 3х инструментов, если их правильно настроить. И я решил использовать SWC.
Единственное, для чего используется сборщик в modern сборке - это конвертация кода в JS.
Каждая из 4х версий проходили процесс сборки, в т.ч. и современная. Под "нетронутыми" файлами я подразумевал код, который не был скомпилирован. Т.е. в тесте использования асинхронных функций должен был остаться синтаксис
async/await.Вы можете сами посмотреть на собранный код каждой из сборок и убедиться, что в современной версии код фичи остается нетронутым
Babel действительно себя хорошо зарекомендовал. Однако, я не очень понял, почему в SWC не работает горячая перезагрузка? Быть может вы о какой-то старой версии говорите? Просто не помню за ним таких проблем.
Можно вот этого вот почаще)
Нет, к Context API доступа нет. Однако, вы можете сделать что-то типа
viewModel.someContextValue = useContext(SomeContext)
Понял вас. Но судя по информации из Readme в репозитории, на который вы сами и сослались, прибегать к такому приему не стоит. Разработчики V8 подвергают критике применение практик, описываемых в OptimizeJS. И по мне так, если честно, разработчики V8 вызывают гораздо больше доверия, чем разработчик, прямым текстом говорящий в своем репозитории, что поддержка его библиотеки не планируется
Что ж, вы проделываете невероятно большую работу. Могу только позавидовать вашему упорству
Не совсем понял, почему мой ответ отличается от реальности. Я в статье указал, что главный файл должен быть указан в package.json, и ответ я написал, опираясь на то, что вы уже осведомлены об этом правиле.
И все же я считаю, что в статье есть смысл. Не все люди знают как работают импорты, и таким людям я помог в этом разобраться. Механизм разделения сборок будет полезен даже в случае, если минификация будет проводиться исключительно в конечном продукте.
К тому же минификация пакета при разработке пакета и при разработке конечного продукта отличаются. Я описал, как сделать минификацию более качественно в рамках одной единицы кода - вашего пакета. Без помощи разработчика пакета, минификация будет менее качественной.
А если дело именно в Node.JS, то по поводу минификации пакета, используемого для него, я уже согласился, так что не понимаю, зачем вы в очередной раз пытаетесь доказать свою правоту.