×

Советы сеньоров: как прокачать знания junior Front-end/JavaScript

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

Михаил Стадник, Senior JavaScript Engineer, 16 лет опыта во Front-end/JS:

Первое и самое важное — быть фанатом своего дела. Если этого нет, зачем себя обманывать, займитесь тем, что вам по душе. На самом деле зарабатывать можно не меньше (а может и больше) и в других сферах. Работа разработчика — это постоянное обучение. Ежедневное. И это должен быть осознанный выбор. Со временем вы обнаружите, что знания, которые были актуальны 15 лет назад, вдруг оказались устаревшими и никому не нужными. Действительно, кому какое дело в 2017 году, какие особенности были у рендеринга таблиц в IE6? А ведь когда-то об этом могли и на собеседовании спросить...

Поэтому всегда проявляйте любознательность. И главное — не бойтесь программировать и совершать ошибки.

Читайте официальные документации, следите за изменениями стандартов. Обновляйте то, что у вас в голове — забывайте ненужное, складывайте то, что актуально.

Не бойтесь задавать вопросы более опытным коллегам. Единственное, что важно понимать — вопросы должны быть максимально конкретизированы. Опытные люди, как правило, с радостью готовы поделиться своим опытом, но только в том случае, если понимают и видят, что человек задает вопросы по существу и действительно пытается разобраться в той или иной проблеме, а не просто пытается её решить чужими руками.

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

Я гарантирую, что специалиста с глубокими знаниями чистого JavaScript и пониманием базовых принципов программирования, алгоритмов и структур данных, но с отсутствием знания отдельного фреймворка (или какой-то библиотеки) с гораздо большей вероятностью возьмут на работу на позицию сеньора, чем того, кто условно знает или применял десять фреймворков, но не понимает, чем двоичный поиск отличается от простого перебора или чем нестрогое равенство отличается от строгого. Условно, можно сказать так, что разработчик, который теоретически может сам создать фреймворк (то есть имеет для этого достаточно базовых знаний) гораздо более интересен того, кто умеет лишь применять какой-то конкретный.

Поэтому изучайте шаблоны проектирования. Все наши любимые фреймворки, в большинстве своем — это набор реализаций тех или иных шаблонов. Например, для ООП-парадигмы много шаблонов описал и систематизировал Мартин Фаулер. Тем не менее JavaScript мультипарадигмальный язык, поэтому не зацикливайтесь на ООП, изучите принципы функционального, императивного/декларативного и основанного на прототипах программирования. Изучайте, что такое неблокируемый ввод-вывод и асинхронность, событийно-ориентированное, аспектно-ориентированное программирование и так далее (информацию, благо, сейчас найти не составляет труда). Особое внимание уделите пониманию базовых принципов функционирования языка, с которым вы работаете. Протоколы и стандарты, которые связаны с ним и со средой окружения, в которой выполняется ваша программа. Разберитесь, что такое многопоточность и однопоточность, чем потоки отличаются от процессов. В конце концов, опуститесь до низких уровней и разберитесь, как работает эта чертова железяка, которая стоит перед вами на столе и которую называют компьютером. Попробуйте, например, достоверно разобраться, что физически происходит в машине, когда вы объявляете в коде переменную и присваиваете ей какое-то значение. Через сколько и какие программные и аппаратные слои пройдет этот процесс? И помните: «There is no silver bullet».

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

Ведь мир очень динамичен. Вы не успели еще досконально изучить все тонкости работы Angular 1, а где-то кто-то уже пишет на Angular 5. Мой личный опыт говорит о том, что в самом начале выгодно инвестировать своё время в фундаментальные знания, так как всё остальное — приходит и уходит.

Также мы часто пользуемся такими ресурсами, как Stack Overflow и Google, чтобы найти решение той или иной проблемы. Это нормально, так как экономит наше время. Но не стоит слепо копировать решения. Каждый раз, когда вы прибегаете к этому, пытайтесь разобраться в сути найденного решения, разберитесь, как оно работает. Найдите второе похожее, сравните оба, попытайтесь понять, чем одно лучше другого. Может быть вы сможете в результате придумать какое-то своё, которое будет ещё лучше. Если возникают вопросы или непонимание — обсудите с коллегами. Вы — Junior, у вас есть для этого время, от вас никто не требует феноменальной скорости. Но все ждут, что ваш профессионализм со временем будет расти.

Если же вы попали на проект, в котором вам досталась скучная и неинтересная работа, но по каким-то причинам альтернатив нет — не отчаивайтесь. Мир OpenSource всегда готов вам предложить что-то интересное. Попробуйте сделать свой вклад в какой-либо популярный проект или начните свой, если у вас есть хорошая идея... В конце концов, опыт, приобретенный на практике, — самая важная составляющая вашего роста, да и будет что показать на следующем интервью в какую-либо компанию.

Сергей Россоха, Software Architect, 11 лет опыта во Front-end/JS:

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

Руководствуясь принципом: «полезность книги обратно пропорциональна её толщине», я не буду рекомендовать труды Д. Кнута, вместо этого быстрее и полезнее начать со статьи «10-ть структур данных, о которых стоит знать программисту». Здесь описаны основные структуры данных и алгоритмы работы с ними. Для тех из вас, кто хочет более детально ознакомиться с алгоритмами и структурами данных, я рекомендую книгу Н. Вирт «Алгоритмы и структуры данных», ее достаточно легко найти в Google или купить в книжном магазине. Я бы рекомендовал реализовывать в коде каждый алгоритм из этой книги, это поможет набить руку в написании кода, а заодно поможет лучше запомнить особенности реализации алгоритмов на JS. Как вариант, можно написать собственную библиотеку с реализацией алгоритмов, описанных в книге.

JS экосистема развивается очень динамично. Новые библиотеки и фреймворки появляются чуть ли не каждые полгода. И перед начинающими JS-разработчиками стоит нелегкий выбор, какой из них стоит учить. Мой ответ достаточно прост — учите JavaScript. В этом вам поможет серия книг YDKJ, тем более она доступна на GitHub. Для любителей настоящих книг доступна также и бумажная версия. Не стоит забывать и о всеми любимом Mozilla Development Network (MDN) — это отличный справочник, в который можно подсмотреть, если что-то забыли ;)

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

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

Александр Смолянинов, Front-end Tech Lead, более 10-ти лет опыта во Front-end/JS:

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

Поэтому в первых двух советах хотелось бы поговорить о верстке и JS.

Не отодвигайте верстку на второй план

Последнее время часто можно встретить довольно пренебрежительное отношение к верстке. Возможно, именно поэтому сейчас так сложно найти действительно хорошего HTML/CSS специалиста, который кроме качественной верстки заботится о клиентской производительности, делает приятную анимацию, не забывает о доступности, применяет современные техники и знаком с нюансами фреймворков и CMS, под которые верстает. Помимо основ уделите время нюансам — и станете на голову выше целой армии верстальщиков.

Не забывайте о нативном JS

Если раньше мы сталкивались с поколением «jQuery-программистов», не умеющих обращаться с ванильным JavaScript, то сейчас все чаще встречаются молодые разработчики, взращенные на модном JS-фреймворке и не способные написать простейший алгоритм на чистом JS, иногда практически не владеющие версткой. Не надо так. Хорошие знания языка позволят намного быстрее понять любой новый фреймворк на нем. И да, штудируя проверенные временем книги по JS, не забывайте о ES2015.

Одновременно и простой, и сложный вопрос, где же этой базой овладевать. Кому-то проще штудировать книги, кому-то ходить на офлайн-курсы, кому-то заниматься онлайн. Несмотря на то, что курсы фронтенда — одни из самых популярных среди всех айтишных, там не всегда высокий уровень преподавания из-за низкого порога вхождения. Лично мне видится идеальным сочетанием — проверенные онлайн-курсы + ментор, к которому всегда можно обратиться с вопросом. Если проблемы с английским языком, то можно попробовать свои силы на ITVDN, Loftschool, HTML Academy или Hexlet. Среди англоязычных неплохо себя показали freeCodeCamp, udemy, Code School и codecademy. Ментора же лучше искать по рекомендациям, личному отношению и в офлайн-доступности. Однако слишком увлекаться курсами тоже не стоит, чем раньше вы перейдете к реальным задачам, тем лучше.

Старайтесь всегда быть в теме

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

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

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

Каналов для мониторинга на сегодняшний день более чем достаточно: это и вышеупомянутый дайджест, и RSS/Twitter лента с подпиской на тематические (микро)блоги, и периодические почтовые рассылки, и агрегаторы ссылок типа echojs.com, frontendfront.com или heydesigner.com. Для любителей соцсетей есть reddit.com/r/Frontend, hashnode.com и medium.com (с фильтрацией по нужному тегу), паблики и каналы в slack или telegram. Также нельзя забывать о подкастах, которые последнее время растут как грибы — Веб-стандарты, Frontend Weekend, Пятиминутка React, Пятиминутка Angular, Фронтёрки, devschacht и многие другие.

Проактивность

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

Сделали сайт с перспективой будущей поддержки или в процессе работы над крупным проектом? Добавьте стайлгайд и облегчите жизнь всем разработчикам на проекте. Закончили верстку быстрее, чем планировали? Добавьте хотя бы базовую поддержку accessibility, проверьте стили для печати и убедитесь, что анимация работает со скоростью 60 FPS. Осваивайте и предлагайте добавить поддержку offline, оцените возможность создания PWA и поборитесь за 100 баллов в google page speed.

Увидели разнобой в коде? Предлагайте внедрить линтеры, поднимите вопрос о стандартизации. И не забывайте делиться полученными знаниями с командой.

Ответственность

Последний, но, наверное, самый важный совет. Можно идеально освоить любую технологию, стать богом CSS, JavaScript ниндзя и быть крутым спецом в Angular и React. Но если вы не попадаете в свои же естимейты, регулярно срываете сроки, подставляя всю команду, не сигнализируете вовремя о проблемах на проекте, исчезаете с рабочего места без объяснений, убегаете на условную тренировку во время критической ситуации на проекте и тому подобное — то в таких ситуациях ценность ваших знаний будет стремительно катиться к нулю. К сожалению, дежурный набор слов в конце каждого второго резюме (про ответственность, усидчивость и стрессоустойчивость) на деле оказывается просто набором слов, а найти по-настоящему ответственного и надежного специалиста — тот еще квест.

Роман Савицький, Team Lead, Senior Software Engineer, 6 років досвіду у Front-end/JS:

Напевно, я не буду розпочинати з того, як «увійти в ІТ», адже занадто багато статей на цю тему. В ІТ увійти можливо, головне розуміти, що таке ІТ. Я працюю зі студентами і випускниками ВНЗ, і деякі з найбільш активних отримують роботу у свої 18. З чого ж почати у фронтенді?

Основи

Розпочинати потрібно з основ програмування і мови, якою ви хочете займатись. Фронтенд розробку я пропоную вивчати з основ HTML5, а саме семантики. Насправді, у мене погані новини тим, хто починає з ToDo List React і вважає, що семантика відійшла в минуле, і все, що зверстано div елементами, — це чудово. Розуміння різниці між b та strong залишиться на все життя, і саме цією базою ви будете користуватись щодня.

Також вивчайте CSS, до того ж послідовно. Починати з bootstrap не раджу, краще чистий CSS. Завжди вважав помилкою, коли розробники не розуміють одиниць вимірювання, підбирають все навмання. Розповім про цікавий випадок на співбесіді одного новачка на вакансію трейні. Розпочали ми, як завжди, із запитань невеликої складності для розуміння рівня. Усе наче добре, і дійшли до CSS. Отримали позитивні відповіді на рахунок flex, box моделі й інші. Коли ж запитали на рахунок одиниць вимірювань, отримали відповідь: «Є пікселі, навіщо ще щось». В очах виник подив і сумнів на рахунок знань. Цікавим відкриттям співбесіди стало те, що, чим простіше було запитання, тим гірша була відповідь.

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

Вивчайте спочатку основи, а далі набирайте оберти і додавайте технології.

Найкращою мовою програмування на фронті був і залишається JavaScript. Розпочинайте з нього, а далі можна CoffeeScript, TypeScript й інші. Але головне, розпочинайте з останнього стандарту, не намагайтесь вивчити старий стандарт, якому 10 років, і думати, що, можливо, знадобиться на старих проектах. У такому разі будете завжди доганяти поїзд.

Ментор

Після того як ви вже маєте мінімальну базу, на мою думку, найкращий варіант — це знайти ментора — людину, яка зможе вас направити в правильний бік і допоможе швидко розібратись з принадами фронтенду. Адже різноманіття технологій, підходів і фреймворків просто вражає.

Курси

Ну якщо ж ви не знайшли ментора і немає змоги стати трейні в одній з компаній, тоді віддайте перевагу курсам. Якщо мову вести про офлайн, то віддавайте перевагу тренінгам при компаніях: саме їм цікаво якісно навчити вас і запросити на роботу. Це те, що потрібно молодому спеціалісту. Платні офлайн-курси, які побудовані на комерційній основі, я не раджу, тому що зацікавленості у менторів немає (тільки грошова), і вона не залежить від ваших результатів. Добре, якщо ви дістанете хоч якусь інформацію, а здебільшого youtube канал допоможе більше.

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

Англійська

Тут все просто: не володієте англійською, навряд чи зможеш програмувати. Уся актуальна інформація англійською, ресурси українською та іншими мовами перекладають із запізненням, якщо взагалі перекладають. Та й мови програмування, у цілому, «англомовні».

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

Практика

Напевно, буду я не першим і не останнім, хто скаже, що інформація, яку прослухав, прочитав з будь-якого джерела, не збережеться в пам’яті і не допоможе вам, якщо ви не спробували її на практиці.

Вивчаєте створення макетів і HTML, обов’язково скачайте макет і зверстайте його. Без практики неможливо увійти в ІТ. Будете проходити 100-500 курсів — і розвитку ніякого не буде.

Коли на практиці виконаєте декілька завдань, тоді спробуйте визначити напрямок фронтенду, у якому хочете розвиватись, — і вперед.

Ресурси

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

По-перше, рекомендую ресурси в стилі готових рішень CodePen. Тут можна і попрактикувати технології, вивчити і зрозуміти, як це виконують інші, і знайти різні завдання.

Далі, напевно, W3Schools, MDN web docs, HTML5 Rocks — це набір довідників, які оновлюються гарно і де завжди можна знайти актуальну інформацію.

На рахунок онлайн-відеоконтенту, тут раджу ютуб з різноманітними каналами, cousera, udemy, codeschool.

Наостанок додам, що головне мати бажання, вибрати напрямок і активно розвиватись в ньому, завжди виконуйте роботу, яку пропонують, практика допоможе вам — і з часом отримаєте все кращі і кращі задачі. Не хвилюйтеся, коли робите помилки, наступного разу вийде краще. Який критерій того, що ви можете працювати і боротись за позицію junior для мене? Коли декілька рандомних практичних задач ви можете виконати різними способами і розумієте різницю між ними, переваги кожного. Це перша ознака готовності до роботи у фронтенді.

Тимофей Лавренюк, Full Stack Engineer, 6 лет опыта во Front-end/JS:

Front-end сегодня развивается очень быстро. 10 лет назад для создания Front-end хватало знания верстки и jQuery. Но сейчас совсем другое время — количество фреймворков, библиотек, языков и прочих фишек во Front-end просто зашкаливает. И тут у новичка может появиться вопрос: как разобраться в огромном количестве фреймворков и библиотек и что и в какой последовательности изучать, чтобы стать Front-end разработчиком в 2017 году? Придется много учиться, если хочется быть хорошим разработчиком и решать сложные задачи. Но если такой задачи нет, то список можно сократить вдвое.

0. English

Английский очень важен. Часто нужно будет читать документацию, статьи и книги, смотреть уроки и лекции, общаться. Почему на 0-м месте? Все описанное ниже можно выучить, не зная хорошо английский язык. Но с годами появляется нужда в коммуникации и углубленном изучении. И здесь без знаний английского будет трудно.

0. Computer Science

Как и с английским, каждый должен сам для себя решить, на какой пункт ставить CS.
Часто хочется изучить только одно направление (в нашем случае Front-end) и сразу идти в бой. В итоге появляются программисты, которые и базовых вещей не знают. Отсюда вытекают проблемы с качеством кода, эффективностью алгоритмов и созданием велосипедов.

Если хочется быть хорошим разработчиком и не зацикливаться в будущем только на Front-end, то нужно понимать:

  • как работает ЭВМ;
  • как работает Сеть и Интернет;
  • базовые алгоритмы и структуры данных;
  • устройство браузера.

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

1. Верстка

Конечно, сейчас хочется выучить React или Angular, взять Bootstrap и сразу делать веб-приложения. Но нужно помнить, что веб начинался не с них. В первую очередь желательно выучить HTML и CSS и сверстать пару десятков сайтов. Нужна практика, чтобы понять, как работает верстка блоками, flex-aми или даже таблицами, и где какой layout нужно применять. Постепенно можно освоить сетки, верстку под различные экраны и препроцессоры.

2. JavaScript

Если CS для вас немаловажно, то лучше сначала изучить язык С, а после него взяться за изучения основного языка для Front-end разработки. А именно JavaScript-a по спецификации ES5. Надо понять, что умеет этот язык, как реализовать на нем базовые алгоритмы и паттерны, и потом уже есть смысл посмотреть на его эволюцию в виде ES2015 или TypeScript. Для изучения базового JavaScript я бы посоветовал серию уроков JavaScript Road Trip на CodeSchool. Это может показаться скучно и бессмысленно поначалу. Поэтому нужно не затягивать и браться за следующий пункт. Но не стоит забывать, что нужно стремиться учить JavaScript всегда, постепенно познавая тонкости языка и его Best Practices. В этом может помочь ресурс learn.javascript.ru

3. Frameworks

Можно учить Framework, не зная тонкости JS. Но, по моему мнению, лучше учить фреймворк после того, как знаешь хорошо JS. Со временем фреймворки меняются, а JavaScript остается. И, зная основные паттерны и JavaScript, можно выучить любой Framework. Но для начала хорошо подойдут уроки на том же CodeSchool.

Однако с фреймворками также можно и переусердствовать. Не редко встречал случаи у новичков, когда небольшие сайты делали на React или Angular, потому что они были популярны, хотя можно было обойтись Bootstrap и jQuery. Со временем получится научиться использовать технологию там, где она лучше всего подходит под задачи.

4. Работа

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

Поэтому если хочется расти не только в $ плане, я бы рекомендовал не останавливаться учиться. А чтобы изучать глубже верстку, JavaScript, фреймворки и различные новые технологии — можно параллельно создавать свои pet-проекты. Решение реальных проблем, которые действительно что-то значат для тебя — это лучший путь к становлению хорошего разработчика. А если получится выпустить свой проект в production и поддерживать его, то это 2x boost опыта. Проверено на личном опыте и проекте.

Я надеюсь эти советы помогут стать хорошим разработчиком, но они не решают всех проблем. Front-end разработка постоянно меняется. И обучение никогда не закончится. Это значит, что сколько бы книг ты ни прочел, сколько бы митапов ты ни посетил или сделал проектов, обучение должно продолжаться, если ты хочешь оставаться в теме.

Влад Лукьянов, Senior Software Engineer, 5 лет опыта во Front-end/JS:

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

Что касается технических навыков, сейчас ценится знание ReactJS и Redux, но важно понимать, что это самый сложный стек за всю историю Front-end разработки, поэтому если у вас что-то не будет получаться либо что-то непонятно, не стоит расстраиваться. Я бы не стал смотреть в какой-то большой проект, где используется React, Redux, Immutable, RxJS и еще много чего, а учить все поэтапно. Конечно же, нужно начинать с самых основ, понимание цикла жизни компонентов (например, в чем отличие componentDidMount от componentWillMount), что такое state, props, какое между ними отличие и когда нужно использовать одно либо другое, как работают events в React. Есть замечательная библиотека, которая позволяет сразу писать React код без каких-либо настроек npm, webpack, babel и прочего, — это create-react-app, однозначно это сэкономит массу времени.

Будучи джуниором, я бы поставил первоочередную задачу для себя — это, конечно же, поиск работы, где можно будет учиться у своих более опытных коллег и работать на реальных проектах. В Киеве можно рассчитывать на зарплату $600-800/mo, от вас в основном будут требовать знание HTML/CSS/LESS/SASS, JavaScript (события, замыкания, функции для работы со строками, числами, прототипы, промисы, ES6/7), знание одного из популярных фреймворков (Angular, React, Vue.JS) на уровне «я могу создать страницу, прикрутить к ней API, вывести данные на страницу и обработать actions от юзера», а также знание Git. Могут поставить задачи на знание Core JavaScript, например, как создать такую функцию:

var a = ‘Hello’.myFunc();
console.log(a); // HelloolleH

Ресурсы, на которые обязательно стоит взглянуть:
learn.javascript.ru
developer.mozilla.org
datasift.github.io/...​w/IntroducingGitFlow.html


См. также другие советы сеньоров:
— .NET
— Python
— Java
— QA

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному12
LinkedIn

Схожі статті




117 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

ain.ua/...​fikaciya-mobilnyx-web-dev

Google запустил сертификацию мобильных веб-разработчиков. Сдать экзамен и получить электронный бейдж-сертификат можно за $99. В компании считают, что это позволит программистам дифференцировать себя на «переполненном рынке» веб-разработки.
var a = ‘Hello’.myFunc();
console.log(a); // HelloolleH

ну і яке практичне застосування? ці задачки на сферичних коней у вакуумі ще нічого не доводять..

Социальными сетями прибило

habrahabr.ru/post/312022

«Каково оно учить JavaScript в 2016»

а теперь добавились yarn и rollup, и новый Angular который вечно ломается

З тою кількістю issue які є в yarn його можна викидати

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

В начале своей карьеры я писал код подряд, в одном файле и мне было нормально. Затем пришло понимание того, что нужно как-то структуризировать код, я начал использовать фунции. Пока не устроился на работу абсолютно не мог понять как именно применяется ООП, зачем создавать классы, обьекты, когда можно воспользоватся старыми-добрыми функциями. Чтение книжек утомляло информацией, которую тяжело осознать не подкрепляя практикой.

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

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

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

я вот нынче тоже смотрю и думаю нахера нужны эти классы когда есть функции

А щось складне писали? Чи так, CRUD, таблички і фанбойство Редаксу? Скільки часу в активному супорті підтримували щось на базі Редаксу?

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

кстати редакс я не очень люблю, как по мне многие его используют не к месту.

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

Тоді мені незрозуміло, як ви можете заперечувати ООП. Кожен з двох інструментів (ооп і фп) має використовуватися для своєї цілі. Навіщо заперечувати одне і кидатися в крайнощі до іншого?

Может, звучит по-дурацки, просто привел пример из личного опыта, я действительно очень долго вьезжал в суть ООП, да и сейчас еще только на полдороги.

Статья конечно, получилась занудная, но целомудрие у ветеранов есть и хорошо, что они готовы им делиться с нубами. Но вот комментарии, как и всегда на доу или хабре, они то и доставляют :-) Получилось, что нужно писать целую статью "101 b vs strong, где все-таки разобрать разницу между этими важнейшими понятиями для начинающих и не очень Frontend-еров. Спасибо участникам дискусии за вечернее настроение. Пис :-)

А я вот вижу как минимум материала на цикл статей, а то и на полноценные курсы.

дуже тішить згадка про CS та алгоритми в майже усіх порадах)

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

Розуміння різниці між b та strong залишиться на все життя, і саме цією базою ви будете користуватись щодня.

Это из разряда диванных аналитиков, зачем молодёжи мозги пудрите?

Хочется верить, что это просто стёб

Ну-ка, а кому важна разница между b и strong в 2017? Может браузеру? Или заказчику? Уточню, в контексте фронтенда я рассматриваю в основном SPA.

Недавно, на код ревью попросили заменить b на стронг, в SPA.

в теории это могут как то иначе парсить скрин ридеры — хотя на сколько проверял то нет

Всем, кто следит за семантикой и понимает разницу между физическим и логическим выделением. Как показывает практика, многие разработчики SPA этим не заморачиваются, как и множеством других штук типа доступности. Что, впрочем, не мешает им писать в резюме «эксперт в html/css», помимо всяких js регалий.

Так. Нормальными человеческими словами, пожалуйста. Что сломается если я напишу b вместо strong? Про семантику я помню, вы мне скажите что сломается.

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

ну вообще можно делать более менее доступны интерфейсы по умолчанию — большая часть не требует каких-то больших усилий — семантическая верстка это то что покроет 70 процентов проблем

Без тестов это не доступность, имхо. особенно в SPA, когда все рендерится на клиенте без перезагрузок. Я вот не знаю как на это скринридеры реагируют.

когда все рендерится на клиенте без перезагрузок. Я вот не знаю как на это скринридеры реагируют.

они нормально на это реагируют. они все работают на основе реального дома

Ничего не сломается, речь же не о том. Одно дело, что человек использует, а другое — насколько он понимаеет разницу между тегами, если уж называет себя специалистом фронтенда. Главная функция для ’b’ - жирность текста, для `strong` же жирность — побочный эффект, основной смысл у нее другой. Ну и кроме того,
«In theory, screen readers could pronounce STRONG and EM in a different voice or style. However this
rarely happens in practice (the same is true for B and I tags)» (из каких-то гайдлайнов accessibility )

То есть если кто-то делает хороший фронтенд, но не знает разницы между b и strong или даже использует b — то всё, не специалист? Это какой-то черно-белый мир. Вообще я понимаю о чем вы — сейчас каждый именует себя экспертом, и меня это тоже смущает. Но такое время. Прочел доку по фреймворку внимательно — и уже эксперт, потому что вокруг много «специалистов», которые даже этого не могут.

Скоріше за все, якщо людина не знає такі базові відмінності, то абсолютно не цікавиться темою. Тобто людина, яка каже, що знає html, але ніколи не чула про «семантичну верстку» змушує задуматися про її чесність, або вона просто не читає інформації по темі і розвиток її не цікавить.

Або це глибокий джуніор, який завчив кілька прийомів, але ще не має знань теорії.

Цілком можливо, що вона хороший ремесленик і підійде під певні проекти, але я б до себе в команду наврядчи взяв на відповідальну позицію.

Это банальный элитизм. Там нет такой огромной разницы и практическое применение «семантики» нулевое. Одно дело верстать таблицей или рисовать таблицу дивами, и совсем другое разбираться в неуловимых тонкостях семантики strong и b. Точно такой же элитизм, «что будет если сложить массив с объектом». Знания ради знаний.

Ви вважаєте, що знати, що таке «семантична верстка» — це елітизм? Знати базово, а не розбиратися в тонкощах. Відповідь «тег Б робить жирним, а Стронг — це семантичне виділення» — це неуловимі тонкощі? Те, що кандидат знає, що Б та І тепер мають синтатичний зміст — це просто додатковий плюс, який показує, що він просто цікавиться новинами веб-розробки.

Почитайте уважно мій попередній коментар. Я сказав слово «базові». Зверніть увагу, я хочу, щоб профессіонал базово знав один із найпопулярніших принципів своєї професії, а ви це називаєте елітизмом?

А що ще елітизм? Щоб майстер по ремонту автомобілів базово знав як влаштована коробка передач? Чи може бажання щоб електрик базово знав чим відрізняються мідні дроти від алюмінієвих — це теж елітизм?

І так, я хочу, щоб людина, яка буде в моїй команді JavaScript’ером знала, що якщо зложити об’єкт з масивом, чи два масива — получиться хрінь. Мене не цікавить, чи він точно знає, яка до букви хрінь там получиться, але якщо він не знає, що получиться хрінь, то з нього вийде дуже небезпечний для компанії програміст.

Відповідь «тег Б робить жирним, а Стронг — це семантичне виділення» — це неуловимі тонкощі?

И что же дает это ваше семантическое выделение? Вот уже несколько человек пытаются доказать что это важно. Пока аргумент только один — возможно какой-то редкий скринридер читает strong и b по-разному. Скажите же уже, кому нужна эта семантика? У вас пользователь читает html-код?

А що ще елітизм? Щоб майстер по ремонту автомобілів базово знав як влаштована коробка передач? Чи може бажання щоб електрик базово знав чим відрізняються мідні дроти від алюмінієвих — це теж елітизм?

Об автомеханиках и электриках позвольте говорить автомеханикам и электрикам. Мы тут о фронтенде.

І так, я хочу, щоб людина, яка буде в моїй команді JavaScript’ером знала, що якщо зложити об’єкт з масивом, чи два масива — получиться хрінь

А что, этого можно не знать? У меня в голове не укладывается чтобы здравомыслящий программист попытался сложить один сложный тип данных с другим. Меня возмущает то, что многие подают как базу как раз-таки знание того, что именно получится. Прям с каждого утюга «А ВЫ ЗНАЕТЕ???».

Скажите же уже, кому нужна эта семантика?

Програмістам. Тому що b і strong — тільки базовий приклад, що людина розуміє, що таке семантика. Тому що тей, хто не розуміє змісту семантики до повідомлення про помилку застосує клас «red», замість класу «warning-message». Це теж семантика, між іншим. І буде використовувати тег «b», хоча в цьому місці буде необхідно просто зробити жирним через css. «А шо такое, оно ведь жирное теперь?!». А потім тобі потрібно зробити ім’я людини в списку тих, хто підтримав коментар сірим курсивом, а там замість (a className="sup-user«) взяті теги b, i та font і ніяких стилів.

Семантика — вона в першу чергу для програмістів, а вже в другу для роботів і людина, яка цього не розуміє наврядчи буде претендувати на senior-позицію. Для джуна це знання буде бонусом — значить цікавиться темою, а не просто завчив пару прийомів.

А что, этого можно не знать?

Ооо, я бачу, ви ніколи не співбесідували людей. Багато не знають навіть більш базових речей

Наприклад, в резюме у людини написано «Design Patterns». Запитуєш: «які знаєш Design Patterns?». Він: «А что такое Design Patterns?». Навіщо в резюме писав?

Або в резюме: «разрабатывал высоконагруженные системы». У нього запитуєш: «які?». Він: «никакие, я написал потому-что все так пишут».

Або питання: «що таке цикл?» (при самий звичайний цикл, наприклад for). Як обговорювати в роботі алгоритми з людиною, яка не знає терміну «цикл».

Або не знають, що таке «prototype» в JS. Ніколи не працювали з JS без JQuery. Ніколи не чули терміну «семантична верстка»

І це все — люди, які співбесідувалися у мене на позицію Senior JS Programmer (або Java в випадку з Highload) в Wargaming, у цих людей купа технологій і величезний досвід в резюме.

я с вами почти со всем согласен, но есть одно замечание — семантика — это как вы сами написали для людей, она дается людьми — точто также с тегом < i > - согласно стандарту — это курсив, а вовсе не иконка, но, люди дали этому тегу семантическое значение иконки — семантику поменяли. если в проекте все используют b — для выделение нечто важного в предложении, во внутрених системах — то они получают семантику strong — да, это идет в разрез со стандартом — но если именно придератся к вопросу семантики — то этот кейс является валидным, хотя я согласен что городить собственные абстракции там где можно и без них — зло

В вашому прикладі все-одно потрібне розуміння, що таке «семантика» і навіщо вона потрібна. І я сумніваюся, що люди, які прийняли таке рішення — ніколи не чули про стандартну семантику цих тегів.

конечно нужно понимание, я же сказал, что почти со всем согласен ))

ніколи не чули про стандартну семантику цих тегів.

в целом в ситуации b / strong могу допустить что кто-то не знал что одно семантическое по стандарту, а другое нет.

главный пример на семантику следующий — хотим сделать колапсбл ареа, как сделаете контрол для схлопывания и разворачивание — и, многие кто даже знает разницу между b и strong скорее там сделают span или div с onclick вместо нормального button

Т.н. семантическая вёрстка — прекрасная идея, но это всё, похоже, накрылось, давно и окончательно. Это такая себе игра в бисер, эстетство и набивание себе цены, как XHTML и валидная разметка. Ни в коем случае не говорю, что это неважно, но и преувеличивать значимость этого не стоит.

Думаю, для вас не секрет, что поисковики и пр. сервисы, которые парсят веб (2GIS, Instapaper и т.п.) давно забили на всё это дело и для анализа используют всякий там AI.

Знову зверну увагу. Одна справа — суворо вимагати семантичну верстку та проходження валідатором коду документу.

Зовсім інша, коли людина, яка називає себе профессіоналом не має уявлення, що таке семантична верстка і що взагалі між b та strong є різниця.

Банальна цікавість до своєї професії не залишила б таких прогалин, бо це один з небагатьох теоретичних принципів, які взагалі існують в html.

То есть если кто-то делает хороший фронтенд, но не знает разницы между b и strong или даже использует b — то всё, не специалист?

Спеціаліст, але якщо фронтенд не буде знати базової семантики і верстки навряд чи він стане джуном після співбесіди.

Ассемблер тоже программисту нужно знать? Или в двоичном коде уметь писать? Это как раз про постоянное обучение и устаревание знаний.

Так, погоджуюсь з вами про постійність навчання. І, як раз, я хотів зосередити увагу на сучаних знаннях і семантиці. Думка одна: новачок повинен розуміти основи семантики і верстки сучасних стандартів, вивчати і розвиватись в цьому напрямку, а не стартувати з JS фрейморків, шаблонізаторів і т.д.
А про новітність і архаїчність знань, тут все просто, я за сучасність. :)
Тому і додав ті теги, які будуть прості для новачка і актуальні.

Ассемблер тоже программисту нужно знать? Или в двоичном коде уметь писать? Это как раз про постоянное обучение и устаревание знаний.

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

Незвачаючи на те, що модняві хіпстери давним давно перейшли на всякі сучасні мови і вважають, що такою фігньою як Сі і компілятор користуються тільки ті, хто застряг в минулому.

Ви кажете, що знання семантики застарілі? Вибачте, але актуальний стандарт — html5, який вийшов кілька років тому вказує на те, що ви — неправі і багато речей там були зроблені саме для збагачення семантики.

Посилення можливостей CSS3 також зроблені для дого, щоб макет був максимально семантичний.

А ви виправдовуйте свою лінь і небажання бути профессіоналом в професії якимось інакшим чином.

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

Не, ну давайте про фронтенд

А ви виправдовуйте свою лінь і небажання бути профессіоналом в професії якимось інакшим чином.

Для чего вы используете знание разницы между b и strong в работе, кроме высокоинтеллектуальных дискуссий? Были случаи, когда strong семантически не подходит? Были случаи, когда верстка поползла из-за того что использовали b?

Не, ну давайте про фронтенд

Так навіщо примішуєте асм до фронтенду, що за дешева демагогія?

Для чего вы используете знание разницы между b и strong в работе

b і strong — ніколи. А різниця між ними (в сучасній семантиці) ніколи не була предметом дискусій.
Семантичну розмітку — кожного дня. Так само, як не сру посеред кухні теж кожного дня, хоча, впевнений, можна знайти людину, яка не відрізнить кухню від туалету.
Вище пояснив чому — семантичність вона, в першу чергу, для розробників. І поганий тей фронд-ендщик, який не розуміє, навіщо вона потрібна.

Так навіщо примішуєте асм до фронтенду, що за дешева демагогія?

Как работает процессор, компьютер, сервер — это тоже основы.

Вище пояснив чому — семантичність вона, в першу чергу, для розробників.

То есть «так не по фен шую», понял.

Попередній коментар, де я давав аргументи, ви вирішили просто проігнорувати. Вигідно.

Я просто сократил

так не по фен шую
Я просто сократил

Це у вас такий евфемізм для «аргументов у меня больше нету, потому я просто сольюсь, вдруг никто не заметит», так?

А какие могут быть аргументы, если от вас я их не увидел? Вы делаете семантичную верстку потому что вам кто-то сказал что так правильно. И передаете это «знание» другим. А я устал спорить, к тому же мне уже пора идти работать.

Вы делаете семантичную верстку потому что вам кто-то сказал что так правильно.

уже говорили что accesability by default, и переход из категорий технических к категориям логическими, что уменьшает количество ошибок, ибо становится понятно какие стили/логика относятся к данному элементу, и не возникает ситуации что страшно css править ибо чтото гдето развалится

вообще теперь как штаты ввели штрафы за невыполнение WCAG 2.0 AA это будет намного популярнее

и переход из категорий технических к категориям логическими, что уменьшает количество ошибок

Ну и в таком случае — это явно не о b/strong, с чего все началось.

Я так і думав, за вашими словами — немає нічого, пусто...

Если вы намекаете что я плохой специалист — то вы не лучше. Специалист в этой ветке только Anton Kononenko, потому что он может отстоять свое мнение понятными словами, а не

Так само, як не сру посеред кухні теж кожного дня, хоча, впевнений, можна знайти людину, яка не відрізнить кухню від туалету.

Напомню, моя претензия была к важности b/strong, а не к семантике в целом. Вы пустились в абстрактные обсуждения о том как и где срать.

Я натякаю на те, що ви проігнорували моє прохання процитувати слова, які ви мені приписали.

к важности b/strong

А я ствердив, що людина, яка не знає, що є відмінності, яка не знає поняття «семантичності» — сумнівний професіонал. А різниця між b та strong — перший приклад, на який натикаєшся, коли цікавишся цією темою.

Ще раз (не знаю, вже вкотре, але ви раз за разом не можете це прочитати, ви розумієте українську?) — вважати це вважливим, чи ні — це не питання, про яке я говорив.

А ось взагалі не знати про існування цієї відмінності — змушує задуматися. Саме тому на співбесіді задають це питання. Хоча я б сформулював його більш відкрито, на зразок — «що ти знаєш про семантичну розмітку та навіщо цим запарюватися?»

вам кто-то сказал что так правильно

Процитуйте, де ви в моїх коментарях це знайшли.

Так навіщо примішуєте асм до фронтенду, що за дешева демагогія?
Как работает процессор, компьютер, сервер — это тоже основы.

ну вообще с появлением wasm — как работает стек, куча, и все что связано с миром С приобретает новую актуальность

Главная функция для ’b’ - жирность текста, для `strong` же жирность — побочный эффект, основной смысл у нее другой.

До речі, згідно з новими стандартами семантика „strong”, „em”, „b” та „i” змінена:

i — was italic, now for text in an „alternate voice”, such as transliterated foreign words, technical terms, and typographically italicized text
b — was bold, now for „stylistically offset” text, such as keywords and typographically emboldened tex
em — was emphasis, now for stress emphasis, i.e., something you’d pronounce differently
strong — was for stronger emphasis, now for strong importance

Тобто раніше вони правда вважалися просто „товстим” та „курсивом”, а зараз вже мають своє семантичне значення і знову валідні для використання в файній верстці.

Мэтт Катс, бывший глава отдела поискового спама в Гугл, -врет, что нет разницы между b и strong?
www.youtube.com/watch?v=WgqgBGHllOw

Он говорит о весе тегов в контексте SEO. а сео — это отдельная песня

А разве не смысл семантической верстки- боле точное определение значимости элементов вебстраницы- пауками поисковых систем?

в реальности намного хуже когда чтобы сделать пожирнее-выделить юзают h3-4 — вот это зло

То уже незнание основ html

юзают не в заголовке?

ну да, просто выделить фразу к примеру

Вы мне? Я про слова комментатора. Звучит, мол, как стёб. Потому что это настолько ничтожное знание, что даже слов нет.

і саме цією базою ви будете користуватись щодня

Неправильно распарсил, дико извиняюсь

Богдане, це приклад для нашого з вами спору.
Я рахую, що написати для новачка, що необхідно знати html, css, js, common sience, english, без розкриття і додаткових прикладів, то краще взагалі нічого не писати.

А насправді, у вашій компанії, наскільки часто джуни/трейні використовують знання html/css/js (базовий)? Я думаю, що висока періодичність.
Думаю, що тепер я Вам доніс свою ідею

Не совсем понял вас, сори. Возможно, предложение так построено. Потому что сейчас оно звучит (подозреваю, не для меня одного), как «разница между b и strong = база, которой будете пользоваться каждый день». Ладно, не придираюсь к словам.

Прошу вибачення за невірне розкриття і приклад.
Моя ідея була показати, що розуміння верстки і базових можливостей необхідно при розробці, особливо для новачків.
Тому і приклад додавав максимально простий, адже стаття саме для тих, хто тільки намагається почати працювати. Якось болісно бачити розробників на співбесіді, які обмежуються div і не знають і не розуміють, навіщо більше тегів. Реакт і так працює.

База — это понимать разницу между block, inline и inline-block элементами, знать какие теги по умолчанию какими являются. Тонкие различия между strong и em — это не база, а элитизм.

Если различия между strong и em — это элитизм, то я даже не знаю..

По-перше, ми спілкувались про семантику, а не про блочність, як таку, а по-друге, ви ж все рівно скажете, що це елітизм

знать какие теги по умолчанию какими являются

div и span по-разному отображаются в браузере (если не переопределить в css конечно). strong и b — одинаково. Но вы почему-то считаете что важнее второе. Если вы уж говорите о различии в тегах с теми, кто о различиях не знает, то логично начинать с явного, а не с семантики.

Ребята, какие там b и strong, выросло поколение людей что 2 блока в строчку не поставят без бутстрапа! Реакт знают, ES6 знают, а отступ между блоками как работает не знают! Элементарный вопрос вот 2 блока, вот их margin — какое расстояние будет между блоками?
Зависание и ответ — не знаю.
Всё, приехали.

Если уж на то пошло, то что вы думаете о fontawesome? И вообще об использовании тега i для рисования иконок? Ведь семантически верно было бы <span class="icon"></span>

Иконочные шрифты сами по себе зло, а i в качестве тега — особенно

А что не зло? Спрайты, которые заново делать каждый раз как нужна новая иконка?

Норм должность сменил! ;)

var a = ‘Hello’.myFunc();
console.log(a); // HelloolleH

тю. вот это было бы интересней:

var a = new String(‘Hello’);
console.log(a); // HelloolleH

Задание из статьи интереснее :)
В вашем можно console.log перегрузить, в первом нужно со String что-то делать

в статье точно также используется консольлог, тем не менее имелось ввиду сделать что-то со стрингом, конструктор перегрузить

Такое?

function String(str){
  var s = new "".constructor(str);
  s.reduceRight = [].reduceRight;
  return new "".constructor(s.reduceRight(function(str,c){
      return str + c;
      },str));   
}

Что-то в роде, идея та

ктобы написал куда смотреть когда уже прошел все это и знаешь/применяешь... когда возникает ощущение что это все, конец, можно только пробовать другие технологии типа clojure, rust или вообще другие тематики типа machine learning ... но к фронтенду это имеет отношение весьма опосредственное, ибо функциональщину использовать нельзя реально т.к. половина не понимает, что такое функции высшего порядка и боятся их как огня, а если увидит кто побитовые операции просто прийдет в полное недоумение — в итоге знаешь уже в избытке — юзать нельзя, а оно бы помогло

не знаю, як можна програмувати на JS і не розуміти функцій вищого порядку.
Для мене така людина була би джуном, незалежно від того, скільки років він штампував формочки на ріактах.

А что такого в функциях высшего порядка, кроме загадочного названия которое мне пришлось гуглить?

боятся. вообще у людей простейший каринг вызывает приступы страха

Это какие-то новички совсем должны быть.

ну не знаю — все кого я знаю этого боятся как огня

Ээм, а что там в принципе можно бояться-то? типа «оужас, функция вернула функцию»?

тип того, с воскликами как с этим работать, зато 3 вложенность ифов их не смущает

Дикость какая-то. А как они с промисами работают? Крестятся когда .then набирают? Там же тоже функция аргумент.

мне кажется они не осознают этого

Не редко встречал случаи у новичков, когда небольшие сайты делали на React или Angular, потому что они были популярны, хотя можно было обойтись Bootstrap и jQuery

Верстаю лендинги на реакте ололо

І правильно, якщо ви добре знаєте реакт і юзаєте якийсь react2html, типу gatsby.

Зачем тратить энергию на клиентский рендеринг, когда можно сделать статический html?

Чтобы был +1 в копилке понтов, ну или разные вкусы и людей бывают

Шоб адекватно робити статичний HTML потрібен як мінімум шаблонізатор типу pug. Але якщо людина вже привикла писати на реакті, то разом з генератором статичних сайтів він цілком може замінити той шаблонізатор.

Если есть много динамичных данных то да, а если это лендинг или сайт визитка то там все по классике лучше будет сделать

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

SEO из коробки, лоад спид в плюсе, при этом очень просто делается и без привязки к node js на сервере

Ну не знаю как на реакте (не работал с ним), но если взять ember:
1. Это просто некоторое количество лишней (причем высококвалифицированной) работы для статичного сайта. Если для себе для тренировки — не вопрос. Если на коммерческой основе — то статика пишется быстрее, и специалисты которые её делают к тому же дешевле.
2. Зачем этот весь js, если конечному пользователю просто почитать. А если брать какой-то генератор чтобы потом сделать статику — ну не надежней ли и проще сразу взять gulp, подключить шаблонизатор-препроцессор и быстро сделать сайт?

Ну я и беру вебпак со всем обвесом и реакт как шаблонизатор. Такая статика иногда попадается и мне лень менять поток ради нее.

Якщо використати gatsby то на виході буде простий HTML. Як у випадку з рендером реакта на сервері. Шаблонізаторів є багато, і без них статичні сайти мало обходяться, бо є однакові елементи: блоки з пропозиціями, списки людей чи компаній-клієнтів, навіть пункти меню для скролу вниз. Просто намножити ці елементи чи згенерувати один раз через Emmet це погана ідея, don’t repeat yourself.

Якщо на сторінці немає елементів, які повторюються, то так. Але такого практично не буває навіть на лендінгах і візитках.

в резюмешці можна написати «React developer» !!!

много дельных рекомендаций, хорошая статья, благодарю.

Підписатись на коментарі