Pull to refresh

Comments 21

Такие знания кишков JS требуют даже если пришёл всякие CRM на фреймворке писать? Не пугайте меня, у меня впереди маячат собеседования, а я там глубоко не погружался.

Я, когда собеседовался, сам этому удивился. Причём такой глубины не требовали ни в React, ни в Angular. У меня даже была мысль написать об React, Angular и Vue.js в рамках статьи о собеседованиях. Но смутило то, что о них особо не спрашивали. Пару простых вопросов и всё. Но тут все индивидуально.

Ну смотря где, в топовые фирмы, куда я собеседовался, меня очень подробно распрашивали как минимум о том, как работает event loop (все что вы описал тс, и еще большие тонкости), не считая других особенностей работы JS. В одной из них я сейчас работаю и очень доволен тем, что уровень всех моих коллег на моем и выше уровнем, что довольно приятно, будучи старшим разрабом. Собеседовался на angular разработчика. Уровень фильтров большинства компаний, куда я пробовался прошлым летом оставляет желать лучшего… А потом удивляемся, как это народ умудряется сделать на столько тормозные сайты, используя готовые фреймворки…

Любители писать на фреймворке обычно так же любят в какой-то момент сказать "это не я, это фреймворк тормозит" и гордо свалить в закат. А тебе потом разбираться, в что же они на этот раз не смогли и делать так, чтоб фреймворк не тормозил.


Поэтому да, некоторые знания "кишков JS" обычно говорят много хорошего о кандидате.

У JS не так много кишков, понимание деревьев в разы сложнее знания замыканий и эвентлупа. Вот про AST сомневаюсь что кто-то спросит. Хотя я спрашивал, но у нас проект был про разработку IDE понимающей js.

Ну, раз так, то где мне почитать, в каком порядке выполняются setTimeout и промисы?

Из-за незнания таких основ, мы как пользователи получаем тормозные сайты и утечку памяти во фронтах.

Не достаточно пользоваться фреймворком, надо понимать что ты делаешь.

Я объявляю computed-свойство в vue, для этого мне не принципиально знать, реализовано оно черкз геттеры с сеттерами или через Proxy, потому что я всё равно на это не влияю и уж точно не буду переписывать часть vue, чтобы стало быстрее. Это другой уровень задач.

Думаю, стоит исходить ещё и из того, какого уровня задачи будут ставиться на работе, где задают эти вопросы. Если это магазинчик, который пишется-верстается за месяц, то есть ли там что-то, что может тормозить и для чего нужно погружаться во все эти тонкости? О вакансиях какого диапазона мы говорим? Кажется, о CRM на фреймворке у разных людей разное представление. Я, например, нацелен на зарплату 100-150 тысяч, чтобы надо мной был опытный коллега, который в случае тех же тормозов что-то посоветует.

нацелен на зарплату 100-150 тысяч

Для такого уровня зп знать основы js - обязательны.

Знание особенностей работы js, это именно основы.

Я объявляю computed-свойство в vue, для этого мне не принципиально
знать, реализовано оно черкз геттеры с сеттерами или через Proxy, потому
что я всё равно на это не влияю и уж точно не буду переписывать часть
vue, чтобы стало быстрее. Это другой уровень задач.

Вам так же ни кто не запрещает использовать замыкания, а большая часть утечек именно из-за их использования и не знания как работает сборщик мусора в js.

Основы основам рознь. Не для всех основы — это понимание работы движка на уровне регистров процессора. Может быть, я допускаю какие-то ошибки из-за своего незнания чего-то, а может быть, я благодаря опыту избегаю их, даже не зная, что я их избежал.

Знать основы JS != знать все тонкости движка и сборщика мусора. Да, если ты это уже знаешь, это большой плюс для каких-то компаний, но упарываться на этом точно не будут.

У меня помню спрашивали об утечках памяти на собесе на 150-200к. О том как они выявляются, как их избежать. Я просто сказал честно что опыта в этом не было, но знаю что это можно сделать с помощью вкладки Perfomance, что обработчики событий нужно удалять, если удаляется компонент. Мне сказали что многие кандидаты даже не слышали о вкладке Perfomance и то что я знаю даже такое это уже плюс. Ну и спрашивали о том как примерно работает сборщик мусора, как он определяет какие объекты очищать, на что тоже не так сложно ответить, об этом поверхностно пишется на том же learn.javascipt.ru. (P.S. по итогам собеса оффер мне дали).

Основы JS для меня это Event loop, замыкания, контекст и т.д. Этого вполне достаточно чтобы получать 100-150к, имхо. Хотя с нулевым опытом тебе даже с этими знаниями не будут скорее всего платить столько. (я по регионам сужу, в МСК может и готовы)

Спасибо за ваш опыт собеседований. Я просто описал то, о чем спрашивали меня.

У меня опыт не нулевой, я для себя программирую уже 15 лет (не считая школьных экспериментов), а за деньги — примерно 8 лет, из них с осознанным применением JS — плюс-минус 6 лет, потому что я постепенно вкатывался, переходя из бэкенда всё больше во фронтенд. Например, в 2007 я использовал ajax копипастой из учебника, году в 2015-2016 наконец дошёл до учебника по jQuery, а в 2016-2017 узнал про fetch. Но всё это изучение было не очень систематичным, потому что из полноценных учебников по JS я прочитал лишь "ES6 и не только", остальное — MDN отдельными частями.

Хотелось бы книжку, где объяснят, как работает сборщик мусора и прочие внутренности, но не в терминах функций на C, потому что C у меня в очень зачаточном состоянии, я им баловался месяц году в 2001 и всё.

Сейчас читаю "Программируй & типизируй", там упомянули про event loop, что это как массив, содержащий функции, даже пример такого массива привели. Но на таком уровне я и без этого понимал, это не добавляет знаний того, в каком порядке выполняются промисы и setTimeout.

Чтобы быстро и значительно укрепить знания, то You don't know JavaScript.

Системно выучить все основы, то LearnJavaScript
Тем кто хочет ультра деталей, я бы советовал читать сразу спеку ECMA TC39


Я объявляю computed-свойство в vue, для этого мне не принципиально знать, реализовано оно черкз геттеры с сеттерами или через Proxy, потому что я всё равно на это не влияю

Ну вот соседние пацаны с редаксом берут и пишут что-то, скажем, положение скролла в редакс-стор. И ходят потом довольные, им ведь не обязательно знать, что теперь при каждом изменении скролла будут безусловно отрендерены все компоненты, у которых это свойство стора поставлено в зависимости.
А когда потом простенький проект ставит на колени процессоры офисных компьютеров (потому что реактовский рендер — это потенциально очень большой объем вычислительной работы, даже когда внешне ничего и не меняется) — делают вид, что они тут не при чем. В самом деле, не будут же они редакс переписывать. Что? Оптимизировать вызовы рендера? Воткнуть дебаунс на худой конец (сразу, а не когда всё начало тормозить)? Не, это же другой уровень задач.


Если это магазинчик, который пишется-верстается за месяц, то есть ли там что-то, что может тормозить и для чего нужно погружаться во все эти тонкости?

Вы думаете, что нельзя легким движением руки сделать тормозным то, что в общем-то ни при каких обстоятельствах не должно тормозить? Можно.

Наверное можно, если поставить перед собой такую цель. Но не понимаю, зачем её ставить.

Маленькое уточнение - JS начинает работать не после загрузки страницы а в процессе

Да, вы правы, спасибо поправлю.

Спасибо за статью
Возможно неправильно понял ваше определение tasks queue, но, учитывая что

Кстати, setTimeout() так же является частью Web API.

и то, что на диаграмме приоритетов вызовы Web API, в том числе, находятся под вторым пунктом, нахожу тут ошибку
Согласно этому докладу, приоритет вызовов за 1 тик event loop'а будет таким:
1. Выполняются все колбэки из call stack'а
2. Как только call stack пуст, выполняются все микротаски (колбэки, которые были добавлены в microtasks queue, через then, catch или все то, что идет после await)
3. Как только microtasks queue пуста, будет выполнена одна таска (один setTimeout, например)
4. На этом тик считается законченым
Поправьте, если что-то не так

Выполняются все операции из JavaScript execution stack (https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide). Т.е. все что уже на исполнении должно отработать. Как я это понял (посмотрев исходники libuv) - в момент переключения между таской и микротаской, что-то может начать исполняться и вот это должно закончится. Функции, которые вызывают сallback'и имеют разное время выполнения. И если у вас, например, 2 callback'а один из которых вызовется через 1 секунду, а другой через 10, то Javascript не будет ждать 10 секунд, чтобы выполнить микротаски первого.

Sign up to leave a comment.

Articles