Что посоветуете почитать для левелапа в JS?

Question

[RaulDuke]

Всем привет.

Относительно давно пишу на JS. Очень люблю его и все такое. Стараюсь быть лаконичным, но понятным, придерживаюсь общепринятых практик и культуры кода, когда слышу, что кто-то пишет на jquery как и полагается поднимаю одну бровь (довольно высоко). Короче говоря стараюсь вести жизнь праведника.

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

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

Спасибо и с пятницей!

Comments

[Андрей Б.]

Что мешает написать напрямую этим крутым ребятам и спросить об их опыте?

[Bunga]

когда слышу, что кто-то пишет на jquery как и полагается поднимаю одну бровь (довольно высоко)

AFAIK, профи не страдают подобными детскими загонами и понимают, что всему свой инструмент.

[RaulDuke]

EireenK: пропустим часть, в которой я сообщаю, что я не профи и все такое.

А для каких задач в 2к17 году вы считаете хорошей идеей использовать инструмент jquery? (как вы могли догадаться, вопрос с двойным дном, после вашего ответа я планирую наброситься на ваши доводы, пару раз намекнуть, что вы плохой кодер и скорее всего буду упирать на ванила js)

[Kovalsky]

RaulDuke: это интересная тема, давайте поговорим об этом. Например, раз уж вы упомянули плохих кодеров и vanilla js, то скажите пожалуйста сколько у вас приблизительно уйдёт времени на то, чтобы самостоятельно написать на JS функцию jQuery.fn.on?

Ваша очередь рулить.

[RaulDuke]

Никита Полевой: а это Вы на какой вопрос ответили вопросом?

P.S. из вежливости поучаствую в Вашей игре бессмысленных вопросов, непонятно к чему заданных:

Сколько приблизительно у Вас уйдет времени, чтобы заполнить катлован 4х4 черничным киселем.

Ваша очередь рулить.

[Kovalsky]

RaulDuke: ну, это не то чтоб ответ, это я скорее так согласился поиграть в вашу игру, в которой вы обещали наброситься на мои доводы, пару раз намекнуть на то что я плохой кодер и скорее всего упирать на ванила js. Начал я сразу с встречного вопроса.

Не хотите играть - не надо, хотя жаль. Только тогда вот эта статья, значит, о вас.

[RaulDuke]

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

Не умеете вести беседу так и вовсе не вступайте, вероятно, за пределами интернетиков проблема та же? :)

P.S. Оскорблять не стану, уж больно жалко это смотрится со стороны.

[Kovalsky]

RaulDuke: окей. В "2к17", как и в любой другой период своего существования, jQuery предоставляет функционал более чем достаточный для разработки проектов у которых сложность ниже уровня веб-приложений: блоги, лендинги и сайты других типов, не нуждающихся в реализации SPA. Следовательно, в "2к17", как и в любой другой период существования jQuery, использование его для не-SPA проектов является хорошей идеей. И если вас действительно интересует что об этом думают крутые ребята, то это не мои слова - это почти цитата из чятика в котором крутые ребята типа Тода Мотто и Аурелио де Роза рассказывают о своём отношении к $.

[RaulDuke]

Никита Полевой:

jQuery предоставляет функционал более чем достаточный для разработки проектов у которых сложность ниже уровня веб-приложений: блоги, лендинги и сайты других типов

В общем случае блоги и лендинги требует несложную анимацию, какие-то простейшие манипуляции с DOM, пару визуальных фишек (параллакс, каруселька) -- все это несложно реализовать на ваниле (или взять готовые плагины на ваниле). На мой взгляд, не за чем туда тащить комбайн на 85кб, 90% которого не будет использовано в проекте.

По этой причине я и посчитал Ваш пример с методом jquery.fn.on некорректным. Предложенный Вами вопрос слишком абстрактен, есть много решений в $, которые я с наскока не воспроизведу также качественно и универсально, но на большинстве блогов и лендингов мне и не надо их воспроизводить, бОльшая часть потребностей будет закрыта EventTarget.addEventListener()

Я кстати не ёрничал, когда спрашивал где его использовать в 2к17. Я действительно этого не знаю. Для одностраничников и блогов $ слишком большой, для серьезных проектов необходима уже какая-никакая архитектура и принципы организации сущностей. Какие-то вариации на тему jquery-in-parts мне еще хоть как-то понятны.

Если есть идеи, киньте какой-нибудь практический пример с реального проекта где Вы были вынуждены использовать $. Вы хоть и нарекли меня пиз#$болом, но я не обломлюсь сказать: да в этой ситуации я бы тоже тащил в проект jquery.

[Антон Зеленский]

RaulDuke: вам совершенно справедливо намекнули, что перед оценкой инструмента, полезно с ним ознакомиться. JQuery можно собрать самостоятельно ровно такого размера, какой вас устроит, исключительно с нужным вам функционалом.
https://jquery.com/download/

The repository's README has more information on building and testing your own jQuery, as well as instructions on creating a custom build that excludes some APIs to reduce file size.

[RaulDuke]

Антон Зеленский:

Какие-то вариации на тему jquery-in-parts мне еще хоть как-то понятны.

[sudo rm -rf /]

RaulDuke: в таком случае, стоило конкретизировать, что речь идет о полном jquery, а не о $ в принципе.

[Kovalsky]

RaulDuke: ну во-первых да, существует ведь туча способов кастомизировать $ и использовать только нужное вам.

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

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

Тут я с вами согласиться не смогу, addEventListener это только самая низкая функция которой пользуется $ для того чтоб вешать события, над ней происходит еще много чего, там очень много функционала. Например, $ реализует умный алгоритм делегирования событий, это не просто matches, это сложная и надёжная система, которая к тому же реализует очень полезный механизм всплытия событий. Не знаю есть ли какая-то статистика или что-то такое, но $.fn.on я именно потому и привёл как пример, что почти со стопроцентной отдачей использую его сам и часто вижу как он используется в небольших проектах.

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

Опять же, можно сколько угодно муссировать тему "$ слишком большой чтобы тащить его в проект", но по факту в абсолютно подавляющем большинстве случаев разницу по бессмысленно сжираемому количеству трафика между "проект без $" и "проект с $" с лихвой компенсирует одно (одно, Карл!) несжатое изображение. Короче говоря, я ещё не видел сайта, где бы отказ от $ причинил бы больше пользы чем оптимизация. А уж в 2к17 погоды эти 50-90кб (варианты размеров кастомного $) точно не сделают, особенно через CDN. К тому же если вы используете CDN, то с очень большой вероятностью пользователь возьмет файл из кеша.

Ну, скорее всего я просто не застал то время когда $ был почти обязательным, у меня не было ни одного случая где я бы был вынужден использовать $. Чаще всего бывало, что он уже используется, вот и вся необходимость.

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

jQuery имеет смысл использовать для типовых задач в небольших проектах, это сильно экономит время. В нём реализовано вообще всё, что вам может понадобиться. А т.к. небольшие проекты (блоги/лендинги/корпоративные сайты) в интернетах до сих пор превалируют по количеству, то можно не стесняясь говорить, что jQuery, хоть его основная функция - нормализация DOM - больше не так востребована, даже и не собирается уходить со сцены или как-то устаревать. Просто сейчас очень модно делать SPA, в котором $ непригоден. Разработка проектов остальных типов, как обычно, сильно ускоряется и упрощается если используется $. К тому же я знаю реальные примеры использования $ в маленьких соц сетях, и выглядит это вполне себе органично, не костыльно.

Answer 1

[AntonDrelin]

Список книг:

• "ES6 и не только" Кайл Симпсон. - очень хорошая книга, достойна чтобы просто прочитать, переведена достаточно хорошо.
  
• Learning JavaScript Design Patterns автор Addy Osmani примеры правда большинство относятся к ES5, что можно подчерпнуть как там выглядить паттерны, ну какой должен быть хороший стиль, очень хорошая книга
  

Ещё один способ, берет библиотеку jQuery и разбирайте её на части)) очень интересное штука и занимает многие вечера. Но пользы будет очень много. Ибо когда-то это библиотечка произвела фурор)

Comments

[RaulDuke]

спасибо!

Answer 2

[holymotion]

https://github.com/getify/You-Dont-Know-JS

Answer 3

[Negwereth]

https://habrahabr.ru/post/135897/
https://books.google.com.ua/books?id=iyIvGGp2550C&...

Для начала. Крутость в программировании не от того берётся, на каком языке пишешь, а от того, как ты пишешь.

Answer 4

[Юрий Костин]

Есть мнение, что нужно изучать другие языки.
Например, я неоднократно слышал, что те js разработчики, которые попробовали Haskell или ClojureScript, начинают мыслить по-другому.
Посмотрите доклад Александра Соловьёва, там он немного об этом говорит (да и сам доклад просто прелесть).

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

Гениальные решения приходят либо спонтанно, либо путём трудов. Но в любом случае и то и другое доступно для вас.

Answer 5

[Igor Kalashnikov]

Посмотрите как рекомендуют писать крутые чуваки из гугла:
https://angular.io/tutorial
Прекрасно тем, что можно сочетать с практикой.
т.е. придумайте себе учебную задачу и пилите Angular2 приложение, только "по-честному", разбирая рекомендации из документации, заодно RxJS захватите.

Comments

[RaulDuke]

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

[Igor Kalashnikov]

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

Если хочется "ублюдочного" кода, то я для этих целей просто без ума от CoffeeScript-а, вот уж где можно извращаться просто невероятно :)

[RaulDuke]

Igor Kalashnikov: спасибо. С ангуляром работал мало, все последние проекты пишу на vue. Тоже очень нравится подход к компонентной декомпозиции проекта во вью. Понимаю что сравнение не очень корректное, но все же. Как вы оцениваете подходы вью и ангуляра?

[Igor Kalashnikov]

RaulDuke: у меня до Vue руки не дошли, поэтому мнение будет ооочень издалека, на сколько я понимаю: в Angular-е более жестко установлены рамки и правила, Vue же более "гибок".

Это палка о двух концах - жёсткость против гибкости.

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

Сам я свалил из мира Java-enterprise в JavaScript, как раз за гибкостью и свободой :), однако строгие правила Java в моей голове заставляет меня писать нормальный поддерживаемый и читаемый код по привычке.

Так и с Angular. С одной стороны раздражает, когда тебя заставляют писать "типовой" код. С другой стороны, иначе приходится самому придумывать правила. Я о себе хорошего мнения, но соревноваться с командой гугла затея не очень перспективная :).

В итоге получается, что
Vue хорош для небольших проектов, где все как на ладони, и разворачивать комбайн нет смысла (даже TypeScript для таких проектов может быть оверхедом).
Однако, если проект планируется немаленький, писать его будет не один человек, то Angular очень хорош.
Соответственно, крутые большие web-приложения будут разрабатываться при помощи более жестко ограниченных технологий.

[RaulDuke]

Igor Kalashnikov: спасибо, отличный ответ

[xfg]

Igor Kalashnikov: а есть какие-нибудь практики отделения доменной модели от инфраструктурного кода? Что-то типа DDD в контексте фронтенда. Уже надоело практически с нуля переписывать фронтенд то с jquery на angularjs, то с angularjs на angularjs 1.5 и сейчас готовлюсь с 1.5 на angular. Весь мой код прошит насквозь фреймворком. Из-за этого не так просто уйти на другой фреймворк если текущий умирает.

[Igor Kalashnikov]

xfg: Ответ будет немного сумбурным, т.к. сейчас в цейтноте

Я бы выделил отдельно классы - модели.
Часто модели делают "толстыми", чтобы они сами себя умели сохранять, типа

// толстая модель - плохо
let car = new Car();
car.save();

Толстая модель плоха тем, что напрямую зависит от фреймворка. Модель должна быть тонкая, т.е. по сути набором свойств и полей. Можно там же различные валидации держать (но я бы в отдельный класс)

Второй момент - продумать API.
Цель - как можно меньше операций над данными на фронте, для этого нужно написать CRUD для каждой модели.

Прекрасным помочником является Swagger: editor.swagger.io
Описываете документ в yaml стиле, а потом с него генерите сервер и клиент

[des1roer]

закопайте вы ng. vue - за ним будущее

[Igor Kalashnikov]

des1roer: поясните, пожалуйста, почему?

[xfg]

Igor Kalashnikov: тонкую модель Фаулер называет анемичной и критикует её в пользу толстой модели. Вместе с этим он также критикует паттерн Active Record и вообще любой инфраструктурный код внутри моделей. Он говорит, что модель должна быть POJO (plain old java object). Но не тонкой. Указывает на то, что поведение у объекта также должно присутствовать, а если это просто набор свойств, то это DTO какое-то получается, а не модель.

[Igor Kalashnikov]

xfg: Вы правы. За путаницу с терминами, сорри, пишу на бегу :(.
Честно говоря, когда писал ответ, так и написал POJO :D, но стёр подумав, что в контексте JS термин будет не в тему и заменил его на "тонкую модель". Под тонкой моделью - я имел ввиду модель без инфраструктурного кода.

По Фаулеру на модельке нужно держать "бизнес правила", это нормально, однако, как я написал выше про валидации, я предпочитаю для них отдельный класс. Почему? Потому, что класс с моделью я открываю часто, а валидации меняю редко, и не хочу каждый раз пролистывать код с валидациями, чтобы найти интересующую меня инфу, ну и в принципе люблю, когда классы компактные. Таким образом у нас появляется слой с бизнес-логикой, который тоже можно легко перетаскивать, т.к. там нет завязок на инфраструктуру. (Ещё можно спрятать часть кода через наследование)

С точки зрения переносимости кода, ещё вариант вытащить валидации/доп. логику по другую сторону API, т.е на сервер.
Например, у нас есть объект Event {id, title, date, price_from, price_to},
если price_from = 0 и price_to = 0 или null, то пользователю нужно написать "бесплатно",
если price_from = x и price_to = y, то пользователю нужно написать `от ${price_from} до ${price_to} USD"
это можно вытащить в отдельное "виртуальное" поле price (или price_string), которое будет вычисляться на бекенде. (В данном конкретном примере такой подход может быть не удачной идеей, в случае интернационализации это придется переделывать.)

Уточню, по моему мнению в общем случае ActiveRecord - плохо, car.save() -- это был пример плохой модели. Для этих целей у меня обычно модуль "api", который содержит набор сервисов по сохранению моделей.

Но вообще переход с фреймворка на фреймворк все равно - боль :)))