Что можно считать глубокими знаниями в js?

Question

[Keksonov]

Везде пишут, что нужно глубокое знание/понимание языка. Что это значит?

Answer 1

[Алексей Струков]

Немного дополню, чтобы новички не пугались. А то страшилок много о том, что надо знать все, хотя в реальности, тех кто действительно "знает все" можно пересчитать по пальцам:

Как работает браузер - можно знать лишь в общих чертах, для общего развития. В повседневной жизни это в 99% случаев не нужно. Браузер предоставляет нам API и мы его используем. То как оно устроено внутри пусть остается инкапсулировано внутри.

Как работает V8 - опять же, достаточно общего представлени об event loop. Все остальное пусть остается скрыто и используется через API.

Оптимизация кода под браузерные движки - в большинстве случаев вообще не надо.

Утечки памяти - если умышленно не стрелять себе в ногу, то тоже никаких проблем с этим не будет.

Написание быстрого кода - практически не нужно (он и так будет достаточно быстрый). Лучше сосредоточиться над написанием читаемого, тестируемого и поддерживаемого кода.

К общему списку еще можно добавить паттерны проектирования. Это будет намного полезней, чем всякие техники спичечной оптимизации)

Comments

[Алексей Струков]

MaxKorz: какие знания об устройстве браузеров необходимы по вашему?

[Алексей Струков]

MaxKorz: теперь разберем что из этого относится к JS:
1) это те самые базовые вещи для общего развития. Можно еще добавить BOM. Для JS разработчика тут интересны их методы, объекты и всякие особенности типа живых коллекций, событий и т.д. Глубже в устройство самого браузера лезть не придется.
2) это на этапе изучения верстки должно было быть изучено.
3) это так же к верстке можно отнести, к разделу парсинга HTML документа.
4) верстка (анимация)
5) базовое
6) верстка
7) верстка

Про удаление элементов - согласен, но это можно рассматривать как выстрел в ногу, о котором я упоминал.

Про быстрый код не соглашусь - давно я считал, что это важно: оптимизировал все подряд, избегал медленных селекторов, учитывал особенности передачи файлов по TCP, делал отложенную загрузку ассетов, стараясь всегда добиваться скорости загрузки страницы в 1 секунду на 3G соединении, выносил длину массива в отдельную переменную для использования в циклах и всякие прочие ухищрения))

А потом вся эта красота отдавалась для интеграции с CMS и все усилия рушились о жесткие реалии - никто не будет заморачиваться на поддержке вашего идеального кода.

- Сеошники повесят кучу скриптов от аналитики, онлайн консультантов, формы из CRM и прочие вещи, которые затормозят ваш идеальный код.
- Контент-менеджеры загрузят кучу огромных, неоптимизированных картинок.
- Пользователи навставляют айфреймов с ютуба.

В итоге, я бы сейчас назвал все эти оптимизации - борьбой с ветряными мельницами. О чем можно говорить, если у самого Гугла их сервис по тестированию скорости загрузки сайтов, сам набирает около 60 баллов всего)

[Алексей Струков]

MaxKorz: единственное, на мой взгляд, где скорость будет иметь значение - игры на js в канвасе. Там может быть ситуация с огромными массивами и со всякими сложными вычислениями, которые должны быть очень быстрыми, но я скептически отношусь к возможности создания нормальных игр в браузере, поэтому даже не рассматривал этот вариант.
Если однажды мне захочется заняться созданием игр, то я точно не выберу для этого браузер и JS - есть более удобные и практичные инструменты, типа Unity.

[Алексей Струков]

MaxKorz: значит у нас возникло недопонимание)
Для меня глубокие знания JS это примерно 4 по 5-бальной шкале.
Про SPA - как-то они не вписываются в этот ряд)

[Алексей Струков]

MaxKorz: у него было 20-50 одинаковых объектов?
Запустил тест - создание объекта с внутреними свойствами на 12 процентов медленней (iPad mini 2)
А что будет при чтении этих свойств? Доступ к прототипу происходит ведь медленней чем к внутреннему свойству.
Да и тесты слишком абстрактные: создание 300 миллионов объектов. Такого на практике не бывает. Незнаю точно что там было в коде, но может причина была в чем то еще а не в подходе к созданию объектов?

PS: в функциональном подходе вообще прототипы не рекомендуется использовать из за неявной зависимости через this)

[Иван]

Алексей Струков: Здравствуйте,вопрос новичка, вот сидишь такой ,читаешь все эти ужасы и понимаешь,что предстоит много учить,так вот вопрос :
На сколько могут покрыть этот список книг знания по js,то есть чтобы понимать тут всё описанное и можно было бы считать что у меня "глубокие знания js",чтобы кодить на реакте либо на ноде. Вот список :
learn.javascript.ru ;

3) Good Parts ;

4) Секреты JS ниндзя ;

5) карманый справочник js-частично;

6) JS шаблоны;

7) ES6;

8) 68 способов использовать js.

[Алексей Струков]

MaxKorz: в любом случае этих объектов там будет создано очень много)

[Иван]

MaxKorz: Я имел ввиду,откуда брать знания ,чтобы практиковаться :) Благодарю за ответ!

[Иван]

MaxKorz: на данный момент занимаюсь на нем:) это ресурс под номером один в моем списке,потом ещё 6 книг,но планирую после прочтения учебника кантора,взяться за изучение реакт,и паралельно штудировать ещё 6 книг из моего списка

[Алексей Струков]

Иван: книги издательства Packt - обходить стороной. 90 процентов материала там это бесполезные туториалы от хипстеров.
Лучшие книги по JS - все от авторов: Дуглас Крокфорд, Николас Закас, Кайл Симпсон.
Лучшие сайты: javascript.ru

Самое сложное в изучении это паттерны и архитектура кода, и то лишь потому, что по ним очень мало адекватного материала с разборами и примерами. По реакту и ноде тоже мало книг нормальных. Приготовься искать по кусочкам на всяких блогах неизвестных (не хайповых) чуваков.

[Алексей Струков]

MaxKorz: имел ввиду будет много итераций создания этого одного объекта)

[Иван]

Алексей Струков: Спасибо)

[Edymov]

Алексей Струков: Полностью согласен с вами. То, о чём пишет MaxKorz, конечно, тоже верно, но всё же это больше справедливо для вакансий с зп выше 100к

[Алексей Струков]

MaxKorz: немного не так меня поняли. Новичков я упомянул из за того, что топикстартер, как мне показалось, хотел оценить длину и сложность пути, по которому ему предстоит продвигаться, а глубокие знания, скорее всего из требований к соискателю взял. Мне так показалось...

Я его понимаю, ибо постоянно вижу вакансии, где в требованиях пишут кучу всяких вещей типа паттерны наизусть, знание React на уровне "бог", коммиты в известные опенсорс проекты, а на деле в этой конторе jQuery и бутстрап используют)

Все это создает видимость, что кругом одни крутые разработчики, которые в день по новому фреймворку изучают и у новичка опускаются руки. Ему кажется что он никогда не поднимется до такого уровня и бросает свое увлечение, ошибочно полагая, что ему просто не дано.

Те знания, что описали Вы, они понадобятся одному из ста программистов, ибо работы такого уровня не так уж и много. Всем остальным достанется кровавый энтерпрайз и разработка лендингов в веб-студиях. А там свои критерии оценки "глубинности" знаний - можешь сделать все что требуется в короткий срок и за небольшие деньги)

PS:
Если заменить термин "глубокие" на "экспертные", то соглашусь, что к ним можно добавить все что вы написали о браузерах и еще плюс спецификация ECMA.
Все разногласие возникло из-за толкования слова "глубокие"))

[АртемЪ]

Написание быстрого кода - практически не нужно (он и так будет достаточно быстрый). Лучше сосредоточиться над написанием читаемого, тестируемого и поддерживаемого кода.

Далеко не всегда.
Зачастую задача стоит написать именно быстрый код.
В некоторых случаях поддерживаемость и тестируемость кода не важна абсолютна. А читаемость так вообще чаще всего не нужна ;)

[Алексей Струков]

АртемЪ: где например может понадобиться быстрый код во фронтенде кроме игр?

[АртемЪ]

Например в финансовых приложениях, и в любых приложениях осуществляющих приличный объем вычислений.

[Алексей Струков]

АртемЪ: никогда таких не видел)
Да и не практично это, по моему, делать сложные вычисления на фронте, а не на сервере. Любой желающий через консоль достанет код и получит алгоритм этих вычислений.

[АртемЪ]

Алексей Струков: Дорого делать тяжелые вычисления на стороне сервера, если их на клиенте можно сделать.
А то что алгоритм достанет - что в этом такого?

[Roman K]

Алексей Струков: если эти вычисления нужны только самому юзеру, то что толку, что он откроет консоль? Через сервер нужно только валидировать данные. Делать такие вычисления на фронте = разгружать сервер от ненужных вычислений.

[Алексей Струков]

Roman Kitaev: Есть какие то сервисы в интернете, где эти сложные вычисления происходят, которые можно в пример привести? Я реально не могу себе представить что это может быть)

[Алексей Струков]

MaxKorz: я сторонник мнения: преждевременная оптимизация - зло)
И вспомнил древнюю поговорку заодно: экономьте не биты, а байты. Если код работает медленно, то скорее всего это ошибка в архитектуре. В целом я не одинок в таком подходе. Во всех значимых книгах по разработке этот подход приветствуетя: Кнут, Макконнелл и прочие.

[Сергей delphinpro]

Алексей Струков:

экономьте не биты, а байты

Поясните, плиз

[Алексей Струков]

Сергей: был такой древний учебник по ассемблеру, где я встретил эту фразу. Суть в общем и так понятна: если программа работает медленно, то надо смотреть на архитектуру, а не заниматься спичечной оптимизацией типа битовых операций для быстрых математических вычислений. Иногда достаточно поменять используемую структуру данных, например заменить массив на lookup table и ускорить алгоритм в разы.

[Алексей Струков]

MaxKorz: я таких мест к сожалению или к счастью не встречал)

PS: предлагаю закончить этот бессмысленный спор. Он ни к чему не приведет сейчас. Пока я лично не столкнусь на практике с такими ситуациями, я не изменю своего мнения. А ситуации эти, как я понял, лежат в области игр и анимации - то, что меня не интересует)

[Алексей Струков]

MaxKorz: тот пример оптимизации, это обычная практика. Тут нет ничего, что требует знания особенностей браузера. Во всех языках будет актуально написание грамотного кода, который работает хорошо, не зависимо от окружения. Во фронтенде, по моему скромному мнению, все эти оптимизации отходят на второй план, ибо читабельность важнее. Сейчас вспомнил фразу от Apple из их учебника по Swift - "всегда отдавайте предпочтение читабельности кода против скорости". Даже с точки зрения бизнеса, они хотят получить максимально дешевый продукт адекватного качества в адекватные сроки. Все алгоритмы с факториальным темпом прироста сложности имеют быстрые аналоги на жадных алгоритмах. Элементарная экономическая целесообразность. Пусть будет нестабильней на 5 процентов, зато дешевле в 10 раз.

Ну и по поводу антинаучного подхода к "de omnibus dubitandun est", у меня есть иное мнение, правда боюсь тогда эта беседа никогда не закончится)

[Игорь Перегудов]

Иван вы серьезно? "3) Good Parts ;" на дворе 2017 год, вы до сих пор рекомендуете эту книгу, в которой уже 80% информации неактуально... Прочитал ее - никому не рекомендую, тратить время, практической пользы не вынести из нее, в реалиях

[Иван]

Игорь Перегудов: Здравствуйте Игорь,я никому не советую,и сам только начну читать её, потому что многие советуют её,что в ней плохого?И что посоветуйте прочитать новичку?

[Игорь Перегудов]

Иван: не советую ее читать, т.к. там практически всё устарело, и приемы программирования в том числе, сам автор - очень крутой дядька, но информация в книге не актуально к 2017 году.
Рекоменду прочитать Флэнагана - "Подробное руководство".

[Алексей Струков]

Игорь Перегудов: не соглашусь. Книга Флэнагана примерно тех же годов, что и книга Крокфорда (если брать последние редакции). Ну и по поводу того, что там все устарело - тоже спорный момент. Нормальных книг не так уж и много есть по JS и поэтому вреда от прочтения Good Parts я не вижу никакого. Наоборот может помочь заполнить некоторые пробелы в недопонятых вещах из других книг, ибо Крокфорд пишет достаточно простым языком.

[Артём Токаревских]

Good Parts всего-то полтораста страниц, прочитать однозначно стоит

[Игорь Перегудов]

Алексей Струков: "Книга Флэнагана примерно тех же годов, что и книга Крокфорда"

2012 год и 2008... :) 9 лет для "хорошей практики" в вебе, а особенно в js... продолжать не буду

[Alex Kheben]

Пишу на JS уже много лет и не понимаю почему знания того как работают браузеры относят к знаниям по JS (языка программирования), ведь браузеры и их API не являются частью этого языка программирования. Мне всё таки кажется, что в вопросе "глубокие знания JS" нужно относить именно JS, а не все среды где этот JS может выполняться. А то как работать с DOM или CSS в браузерах - это уже знания по frontend-у, а не по JS.

Если исходить из логики, которую описал MaxKorz, то JS разработчик серверных приложений никогда не будет знать JS хорошо, т.к. ему абсолютно наплевать как работать с DOM в браузере.

Я сторонник того, чтобы писать код понятно, а не оптимально. Если есть ситуация, когда код написан локонично и понятно, но работает на 10% медленнее, чем если его оптимизировать, сделав при этом не очень понятным и местами не очевидным, то я выберу первый вариант. Хотя бывают, конечно, ситуации, когда и код получается оптимизировать и читабельность сохранить, так же как и бывают случаи, когда без оптимизации через потерю читабельности не обойтись, но бывают они очень редко, во всяком случае в моей практике. Всё таки нужно исходить из позиции, что не только ты один должен понимать как и что работает, для этого, собственно, паттерны проектирования приложения и придумали.

Насчёт того, что кто-то выше писал, что нужно ещё знать современные библиотеки - это тоже к знаниям языка программирования, о котором автор вопроса спрашивает, имеет мало отношения (за исключением того, что бОльшая часть из них написана на JS), тем более в JS, где этих библиотек/модулей, которые решают примерно одни и те же задачи как у дурака фантиков.

А в общем, полностью согласен с автором данного ответа :)

[Alex Kheben]

MaxKorz: для NodeJS единственные отличия в средах, с которыми я сталкивался, это разрядность ОС и самой ноды (при работе с более-менее большими числами заметно), больше никаких, иногда ещё бывают проблемы с компиляцией нативных модулей, но это не особенности ЯП, а особенности среды выполнения кода и решаются не при помощи знаний ЯП. И если вы не знаете как работает какая-то конструкция в ЯП или паттерны проектирования, то никакие знания о том что есть какая-то редкая особенность в каком-то браузере с какой-то версией вам это знание ЯП не восполнит и отсутствие такого знания не оправдает.

Всё же нужно различать ЯП и среды. Если бы знание сред выполнения кода являлись частью "хорошего знания ЯП", то не было бы отдельных вакансий типа "NodeJS разработчик" или "Frontend разработчик", а были бы они с названиями "JS разработчик" и нанимая такого человека с хорошими знаниями ЯП работодатель бы думал, что он умеет писать хорошо и быстро приложения под любую среду. Но вы же сами понимаете, что это не так :)

Я могу сказать точно, что у меня хорошие знания JS, но знания в NodeJS намного перевешивают по объёму и качеству знания по фронтэндовым направлениям. Можно ли сказать, что если человек не знает как работает поиск элемента в DOM в сафари или линксе (есть такой браузер, весьма специфичный), что он плохо знает ЯП или знает ЯП хуже, чем человек, который знает об этих особенностях? Ответ: НЕТ! Потому, что это не является частью ЯП.

[Alex Kheben]

MaxKorz, у меня глюки или вы действительно удалили комментарий на который я отвечал?

[Gran Torino]

Алексей Струков: согласен, и сам гугл жалуется, на не оптимизированый css подключенный с google fonts, вообще красавчики

[Gran Torino]

Иван: а толку от того, что вы все это прочли, огласите перечень того, что вы написали в итоге?

[Артём]

Алексей Струков: Добрый день, скажите пожалуйста конкретнее по поводу паттернов и архитектуры кода
Возможно вы можете посоветовать материалы по данным темам?
Интересует front-end

[Алексей Струков]

Object Saymon: привет, по паттернам нормальной книги ни одной не встречал. Из разных источников надо собирать по крупицам. Можно попробовать почитать Addy Osmany, но по-моему он немного запутанно все объясняет. И еще вот это можно от него же: large scale JS.

Все остальное ща уже не помню точно, но искал давно гуглением примерно по таким запросам "javascript patterns", "javascript mvc", "javascript observer mediator"

[Дмитрий Pacification]

Алексей Струков: Вот тут полностью согласен. Я занимался сео оптимизацией, тоже видел подобные примеры. Ты оптимизируешь сайт, а потом приходит клиент и говорит что ему нужна какая-то фишка на сайте, которая вразрез идет с принципами сео, а потом приходит маркетолог, дизайнер и еще кучу ребят, и тоже говорят тебе что-то добавить, что убивает оптимизацию.

Вывод один: если ты делаешь свой собственный проект, то можно запариваться с оптимизацией сколько угодно глубоко, но для продакшена не всегда и не всем эта оптимизация нужна.

Answer 2

[Олег Лустенко]

Я бы конечно определился, что такое более глубокое понимание. Для себя я бы обозначил глубокое понимание, как умение решать "бизнес-задачи" на языке JavaScript, наиболее эффективным образом.

Глубокое понимание, уже перестает относиться только к JavaScript, а начинает очень тесно взаимодействовать с общими паттернами которые есть в программировании.

Знать и уметь применять паттерны проектирования:

- Singleton
- publish/subscribe
- factory
- proxy
- facade
- strategy

Понимать структуры данных и понимать для чего эти структуры предназначены, сложности алгорит:

- Список, связанный список
- Деревья, бинарные деревья
- Очередь/Стек
- Графы

Уметь писать в ООП парадигме и в функциональном стиле, просто чистый код:

- SOLID
- fp (pipe, compose, curry, functor, monads, etc)
- SOA, понимание Service-oriented architecture

Понимание работы компилятора и интерпретатора, MaxKorz хорошо уточнил.

Answer 3

[Андрей]

У каждого HR/техлида, который будет собеседовать, свои представления о прекрасном. Есть база, которую надо знать, иначе будешь плавать категорически, все остальное - по мере необходимости (имхо). Если с инглишем туго, то сожалею, хотя у кантора весьма недурной ресурс, да и есть платные качественные курсы по JS. Опять же зоракс на ютубе доходчиво объясняет базу.

Правда кроме теории неплохо бы все это дело на практике обкатать на нескольких проектах, и чем заковыристее задачи - тем лучше, в крайнем случае на том же кодварс можно навыки обкатывать.

Собеседующим главное надо показать, что их задачи ты сможешь решить. Для этого софт-скиллы местами даже гораздо важнее технических скиллов.

Answer 4

[Семён Белоглазов]

Я думаю, опыт работы минимум 2 года + знания современных библиотек и фреймворков, возможность самому создавать их.
Ну и иметь парочку проектов не мешало бы.

Comments

[dom1n1k]

2 года + 2 парочка проектов = глубокие? Я как-то всю жизнь полагал, что такие громкие слова применимы для опыта порядка 10 лет и более :)

[dom1n1k]

Pavel Ustyugov: Нет.
Ну то есть освоить-то можно и это будет вполне нормальный уровень для решения многих практических задач. Но это нельзя назвать глубокими знаниями. Это будет уровень ремесленника (совершенно не вкладываю в это слово уничижительного оттенка).
"Глубокие" или как еще говорят "экспертные" - это фундаментальный теоретический бэкграунд + богатый практический опыт (включая смежные области!), которые позволяют разбираться в подкапотных нюансах, понимать взаимосвязи, уметь предвидеть последствия решений, понимать не только как оно работает, но и почему именно так, и тд и тп.

[DrunkMaster]

dom1n1k: А можно 10 лет скрипты на jquery писать простейшие и ничего не узнать глубокого ))

[dom1n1k]

Может и так быть. Необходимое условие - еще не значит достаточное.

Answer 5

[xmoonlight]

В 99.9% случаев: кодить без jQuery.
Когда звучат такие слова, как "глубокие знания", то речь идёт о скорости исполнения JS-кода и достижение максимально-возможной через знания того, что под "капотом" как функционируют все прослойки.
Ошибочное мнение, что речь идёт о знаниях стандартных JS функций, методов и алгоритмов.

А вообще, MaxKorz всё верно изложил.

Comments

[DrunkMaster]

Если "кодить без jQuery" тогда у меня глубокие знания ))) Хотя тоит посмотреть на мои вопросы тут и станет понятно что это не так

[xmoonlight]

DrunkMaster: я дополнил ответ до того, как Вы написали коммент... )
Возможно, сейчас станет понятнее.

Answer 6

[Kir ---]

Все что выше написали булщит.
Глубокое понимание JS, это умение написать функции наследования через прототипы не по памяти, а потому что понимаешь как это делается.
+ Теперь ещё понимание символов.