Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Хипсторы должны быть в теме всего. У ребят уже реально крышу сносит
Многие идут во Front-end, думая что это вёрстка. Мол изучу HTML+CSS+jQuery и пойду сайты клепать. Не тут то было.
Это же и есть front-end, ну еще фреймворки. Иначе это будет full-stack.
ну как бы нет)
Нет, это только вершина айсберга.
Есть ещё
Есть ещё
- Кроссбраузерность
- Скорость загрузки ресурсов
- Порядок отрисовки
- Порядок выполнения скриптов
- Шрифты, и их форматы
- Векторная графика, иконки
- Оптимизация изображений
- Адаптация к разным экранам
- Адаптация для разных ОС
- Адаптация для разных способов ввода (Мышь + клавиатура, тачскрин, жесты)
- Доступность для разных способов вывода (соблюдение WAI ARIA для слепых, субтитры для глухих, особые цветовые решения для эпилептиков)
- Правила вывода на печать
- Мета-данные для парсеров и роботов
- Деградация на старых устройствах
Лучше бы фронт не пытался лезть в бек, нахвататься верхов, а потом лезть советовать. Каждому свои задачи по знаниям и опыту.
Особенно порадовали требования знать ЯП бека и работу БД.
Особенно порадовали требования знать ЯП бека и работу БД.
Ведь никто и не говорил, что фронт должен пилить бек. Фронт должен понимать как работает бек. Как минимум, чтобы было понятно почему иногда нужно делать «еще один костыль на фронтенде». Или подсказать, что он может сделать, чтобы этот костыль и вовсе не пришлось бы пилить.
Но, почему-то это «понимание бэка» часто сводится к «запили еще один костыль на бэке, иначе мне на фронте придется целых 3 лишних строчки кода написать».
По-моему, это уже можно назвать непониманием. В любом случае, нужно уметь договориться. В некоторых случаях костыль лучше делать на фронте, а в некоторых на беке. Если совместно не разобрать все плюсы и минусы отбросив абстрактные «костыль» или «лишний код», то любые споры кто должен запилить — это простой треп.
Иногда три строчки в коде на фронте могут похерить пару костылей. Аналогично и для бека. Тут и важно понимать, что надо сделать самому, а что просить у бека.
Буквально на днях столкнулся с проектом, у которого аж три фронтенда. И каждый отдает данные по-своему. В результате три визуально одинаковых элемента работают по-разному. Это частность, но из-за таких вещей фронтенд перегружен. А расхлебывать тому, для кого это все дело пишется — пользователю.
Лучше бы идиоты не пытались лезть в фронт. и в бэк. и вообще.
Потому что когда ты приходишь к бэкэндеру с фразой «у нас эндпоинт отдает данные 300 секунд, это неправильно» и получаешь ответ «ой да ладно тебе, как будто ты таймаут побольше выставить не можешь» хочется в лицо бить.
Каждый разработчик должен иметь знания смежных domain of knowledge на уровень ниже. То есть senior front-end должен иметь уровень хотя бы mid-backend, mid-ui, mid-content, mid-QA. Это тянет за собой junior DBA, junior devops, junior design+ux, junior stretegy. Иначе это бесполезный специалист, живущий в своем мирке и не смотрящий по сторонам.
К бэкэндерам это так же относится, только теперь для senior back-end нужно middle devops, middle dba, middle front-end, middle QA, junior UI, junior content.
Это не только про фронтэнд история, это про все. Все знать должны смежные области.
А иначе получится вечная история о том, как умный фронтэндер пришел и обосрал всю архитектуру, после чего пятерых разработчиков разогнали, потому что он оказался frontend/node.js fullstack. Или пхпшник оказался на самом деле сишником, который расширения для пхп уже 5 лет пишет. Или дизайнер оказался неплохим верстальщиком и все на него свалили. Сколько я этих историй уже насмотрелся…
Потому что когда ты приходишь к бэкэндеру с фразой «у нас эндпоинт отдает данные 300 секунд, это неправильно» и получаешь ответ «ой да ладно тебе, как будто ты таймаут побольше выставить не можешь» хочется в лицо бить.
Каждый разработчик должен иметь знания смежных domain of knowledge на уровень ниже. То есть senior front-end должен иметь уровень хотя бы mid-backend, mid-ui, mid-content, mid-QA. Это тянет за собой junior DBA, junior devops, junior design+ux, junior stretegy. Иначе это бесполезный специалист, живущий в своем мирке и не смотрящий по сторонам.
К бэкэндерам это так же относится, только теперь для senior back-end нужно middle devops, middle dba, middle front-end, middle QA, junior UI, junior content.
Это не только про фронтэнд история, это про все. Все знать должны смежные области.
А иначе получится вечная история о том, как умный фронтэндер пришел и обосрал всю архитектуру, после чего пятерых разработчиков разогнали, потому что он оказался frontend/node.js fullstack. Или пхпшник оказался на самом деле сишником, который расширения для пхп уже 5 лет пишет. Или дизайнер оказался неплохим верстальщиком и все на него свалили. Сколько я этих историй уже насмотрелся…
Лезть и не надо. Достаточно знать, как все устроено, чтобы бекенд-разработчику не пришлось обьяснять, как делать не надо и почему не надо.
А на выходе получается — DevOps.
Нет, даже не рядом
Смотря что считать DevOps.
Ок. Представьте себе DevOps-а (любого, которых принято считать девопсами), который не знает, что такое Docker, Chef, Ansible, bash, linux. Представили? Я — нет.
Ни одного из этих слов в статье нет. Максимум: «знать апач и PHP».
В статье говорится, что фронтенд должен знать, что такое сервер — как минимум, если картинка не показывается, если её nginx затёр, или как правильно управлять кешем этих самых картинок. Даже знать, что такое куки, почему их не надо отправлять вместе с картинками, и почему есть поддомен static.* — полезно. Но Девопсом он от этого не станет, даже рядом.
Ни одного из этих слов в статье нет. Максимум: «знать апач и PHP».
В статье говорится, что фронтенд должен знать, что такое сервер — как минимум, если картинка не показывается, если её nginx затёр, или как правильно управлять кешем этих самых картинок. Даже знать, что такое куки, почему их не надо отправлять вместе с картинками, и почему есть поддомен static.* — полезно. Но Девопсом он от этого не станет, даже рядом.
Но это же не всё.
13. Он должен умело писать, чтобы хорошо доносить свои мысли до других, как в этой статье.
14. Он должен хорошо торговаться, чтобы умело продать свою работу и идеи.
15. Он должен уметь поддерживать светский разговор, когда попадёт на ужин с инвесторами.
16. Он должен иметь вкус в одежде, чтобы не шокировать окружающих.
17. Он должен уметь готовить, чтобы создать уютную обстановку при романтической встрече.
18. Он должен виртуозно работать в любой OS, в том числе и в мобильных.
19. Он должен говорить на международном бизнес-языке, чтобы первым улавливать музыку далёких гонгов.
20. Он должен быть материалистом, чтобы отличать ошибочные идеи от выполнимых.
21. Он должен быть в курсе постановлений правительства, чтобы знать, куда бежать.
22. Он должен думать о бекапах имеющих к нему отношение работ.
23. Он должен иметь под рукой компьютер и связь, чтобы рационально использовать своё время.
24. Он должен излучать оптимизм, чтобы быть своим в доску в компании.
25. Он должен иметь нюх на ещё не озвученное решение руководства стартапа о его закрытии.
13. Он должен умело писать, чтобы хорошо доносить свои мысли до других, как в этой статье.
14. Он должен хорошо торговаться, чтобы умело продать свою работу и идеи.
15. Он должен уметь поддерживать светский разговор, когда попадёт на ужин с инвесторами.
16. Он должен иметь вкус в одежде, чтобы не шокировать окружающих.
17. Он должен уметь готовить, чтобы создать уютную обстановку при романтической встрече.
18. Он должен виртуозно работать в любой OS, в том числе и в мобильных.
19. Он должен говорить на международном бизнес-языке, чтобы первым улавливать музыку далёких гонгов.
20. Он должен быть материалистом, чтобы отличать ошибочные идеи от выполнимых.
21. Он должен быть в курсе постановлений правительства, чтобы знать, куда бежать.
22. Он должен думать о бекапах имеющих к нему отношение работ.
23. Он должен иметь под рукой компьютер и связь, чтобы рационально использовать своё время.
24. Он должен излучать оптимизм, чтобы быть своим в доску в компании.
25. Он должен иметь нюх на ещё не озвученное решение руководства стартапа о его закрытии.
Сразу видно — статью писал front-end разработчик
Оригинальная статья написана очень крутым человеком и по сути дела батей современного фронтенда, как минимум в плане вклада в его развитие и создания вещей этому сопутствующих. Chris Coyer — создатель css-tricks и один из отцов codepen. Это вам не очередные пятничные мысли Васи-сеньера читать.
Автор прав, фронтенд разработчик должен знать это все, хотя бы для понимания как это работает и почему иногда нужно прислушиваться с бекенд-проблемам, а не ныть о своих.
Но все, что автор говорил про фронтенд, в равной мере относится и к бекэнду. Бекэнд разработчик тоже должен знать это все и думать о том, чтобы выполнить свою задачу так, чтобы фронтенду было проще (у них так много боли). А не «отвалите от меня! я сделал свою часть!».
В идеале (и это достижимо) и те и другие должны уметь и хотеть разбираться во всем, и самое важное — уметь договориться как они будут решать поставленную задачу!
Но все, что автор говорил про фронтенд, в равной мере относится и к бекэнду. Бекэнд разработчик тоже должен знать это все и думать о том, чтобы выполнить свою задачу так, чтобы фронтенду было проще (у них так много боли). А не «отвалите от меня! я сделал свою часть!».
В идеале (и это достижимо) и те и другие должны уметь и хотеть разбираться во всем, и самое важное — уметь договориться как они будут решать поставленную задачу!
«Он должен знать принцип работы генератора — ведь сайты работают от электричества»
«Он должен знать работу АЭС — т.к. генераторы работают там, а они дают электричество, а электричество питает сайты энергией.»
Статья притянута за уши. 80% тезисов верны. Но не являются обязательными. Лишь как рекомендации для хорошего фронтенд мастера.
«Он должен знать работу АЭС — т.к. генераторы работают там, а они дают электричество, а электричество питает сайты энергией.»
Статья притянута за уши. 80% тезисов верны. Но не являются обязательными. Лишь как рекомендации для хорошего фронтенд мастера.
Мой опыт подсказывает, что бэкенд разработчику почти всегда нужно быть, по факту, фуллстеком(ну может только что не фигачить pixel-perfect вверстку, да и то разок-другой придется делать и такое).
Хм, что же тогда должен знать full-stack разработчик.
Frontend-разработчик должен разбираться в настройке веб-серверов
Без них не было бы веб-сайтов.
Что без серверов не было бы сайтов — очевидная вещь. Но, извините меня, каким боком настройка серверов касается frontend-разработчиков и их непосредственной работы?
Или я чего-то не понимаю, или полезность статьи нулевая. Подставить в текст вместо frontend-разработчика любого другого специалиста и смысл ни капли не поменяется.
Предположу, что надо знать про gzip, https и http 2.0
Ну это как раз системные вещи, а не frontend. Перед условной нодой будет стоять nginx, который и будет делать gzip, https и все на свете. Я не спорю, что условный express тоже может статику отдавать и жать, но в продакшене я такого давно не видел.
Как раз любой протокол — это то, что связывает бекенд и фронт. По-моему говорить, что протокол реализует только веб-сервер, некорректно. Как минимум есть ещё один опонент — браузер. В большинстве случаев, действительно всё делает браузер и веб-сервер. Но бывает, что нужно более детально разбираться, банальный пример — нужно прочитать заголовки ответа сервера/послать свои.
Будучи автором redux-oauth мне сложно с Вами не согласиться.
Спасибо большое за подборку. Есть над чем думать и что читать!
Фронтэнд разработчик может разбираться в чем угодно, и рассказывать об этом где угодно и сколько угодно, но если в вашем проекте он должен разбираться в чем-либо кроме фронтэнд разработки — вопрос к менеджементу проекта.
Не увидел в статье чего-то экстраординарного.
Как и любой другой разработчик он должен разбираться в:
методологиях разработки, системах сборки, тестировании, производительности.
Как и любой другой разработчик связанный с сетями он должен понимать как они работают.
Как и любой другой разработчик в окружении которого есть БД должен уметь делать с ней базовые вещи, никто от него не требует полноценного администрирования баз.
Ну а остальное вытекает просто из специфики конкретного места т.е. фронэнда.
Как и любой другой разработчик он должен разбираться в:
методологиях разработки, системах сборки, тестировании, производительности.
Как и любой другой разработчик связанный с сетями он должен понимать как они работают.
Как и любой другой разработчик в окружении которого есть БД должен уметь делать с ней базовые вещи, никто от него не требует полноценного администрирования баз.
Ну а остальное вытекает просто из специфики конкретного места т.е. фронэнда.
«кодоводство» — ОК!
Уважаемые комментаторы, разумеется, front-end не обязан этого всего знать, но вот претендующий на звание Senior и Lead — да.
WebGL забыли. Он уже даже на iPhone работает.
Современному FrontEnd разработчику надо понимать, что такое shader.
Про Tessellation shader'ы пока можно не знать. Но остальные хотя бы использовать, но надо уметь.
На самом деле, Web с каждым годом становится все сложнее.
Вот интересно бы еще порассуждать на тему, как Web разработчику своевременно обновлять багаж знаний, выкидывая отжившие свое hack'и времен IE6 и планируя, что надо изучить нового.
Современному FrontEnd разработчику надо понимать, что такое shader.
Про Tessellation shader'ы пока можно не знать. Но остальные хотя бы использовать, но надо уметь.
На самом деле, Web с каждым годом становится все сложнее.
Вот интересно бы еще порассуждать на тему, как Web разработчику своевременно обновлять багаж знаний, выкидывая отжившие свое hack'и времен IE6 и планируя, что надо изучить нового.
Хорошая статья, единственное замечание:
article.body.replace(/[Ff]rontend[-]?[\s]*/g, "");
//TODO capitalize next word in proper cases
Frontend-разработчик должен разбираться в базах данных
Больше 10 лет во фронтенде и толком не знаю ничего о базах данных. И вот как-то даже не нуждался
Оригинальная статья «A Front End Developer is Aware» переведена слишком прямолинейно, нет неуловимой мягкости 50 оттенков модальности английского. К примеру «A front end developer is aware of design» = «Фронтенд разработчик знает о дизайне». Когда и как он это узнал — за кадром. Хорошо или плохо знает — за кадром.
Оригинальная статья была ориентиром. «Дружок, тебе было бы неплохо ориентироваться в A,B,C». А перевод получился приговором: «должен A, должен B, должен C». И рядом идут пункты законов, по которым он что то должен.
Через полгода-год начинающий фронт глянет на то, что пройдено, на то что должен, оценит результаты, оценит перспективы и застрелится :( Если бы меня так испугали на заре карьеры, я бы уже того…
Пожалейте новичков.
Оригинальная статья была ориентиром. «Дружок, тебе было бы неплохо ориентироваться в A,B,C». А перевод получился приговором: «должен A, должен B, должен C». И рядом идут пункты законов, по которым он что то должен.
Через полгода-год начинающий фронт глянет на то, что пройдено, на то что должен, оценит результаты, оценит перспективы и застрелится :( Если бы меня так испугали на заре карьеры, я бы уже того…
Пожалейте новичков.
(Комментирую как fullstack-разработчик .net, angular, ms sql в прошлом, сейчас в основном занимаюсь фронтенд разработкой)
на какой… фронт-енд-разработчик — (далее ФР), знать как работает БД!
Пф!
Да, согласен —
но это разве понимается как знание БД, разве ФР на клиенте пишет/должен писать sql-запрос? это ж ужс!
и комментарий автора мне нравится… Но по сути это не за чем. Это удел админа или на край бекенд-разраба.
Некоторые моменты действительно наивны,
любой уважайющий себя web-программист обязан хоть немного знать что такое TCP/IP, DNS… принципы работы сети — ну это перебор ребята, КОНЕЧНО ЖЕ он должен разбираться в сетях, это же его область деятельности в принципе. Производительность, это уже опыт, практика, методология разработки — нуууууу, согласен, но все таки — это не аргументы, чтоб считать ФР центральным лицом разработки.
Раньше что-то особо не парились ФР или бекенд,… ВЕБ-программист — вот оно, ВСЕ!!! этот чудо человек знает все! — как получить кучку записей из бд, как красиво написать бизнес логику, как это вывести на страницу с рюшечками и тенями и анимациями, как асинхронно подгрузить данные (ajax-ом).
Видимо, менеджеры проектов хотят максимально разделить круг задач разработки( чтоб максимально уместно раздавать чудотворные люля специалисту, который тормозит)
этот занимается дизайном,
этот — версткой, js-скриптами, ajax/json
этот пишет бэкенд,
этот проектирует базу данных,
— ну вроде логично!
ну а раз идет разделение ролей — то выше описанное как по мне перебор.
по сути тогда и кассир-операционист должен знать как ведется учет персонала, бухгалтерия, ведь он работает с деньгами!
Эти все знания будут полезны, но не входит в обязанности специалиста.
на какой… фронт-енд-разработчик — (далее ФР), знать как работает БД!
Пф!
Да, согласен —
frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных..
но это разве понимается как знание БД, разве ФР на клиенте пишет/должен писать sql-запрос? это ж ужс!
-Frontend-разработчик должен разбираться в настройке веб-серверов
и комментарий автора мне нравится… Но по сути это не за чем. Это удел админа или на край бекенд-разраба.
Некоторые моменты действительно наивны,
— Frontend-разработчик должен разбираться в работе сетей, Frontend-разработчик должен разбираться в производительности,
— Frontend-разработчик должен разбираться в производительности
— rontend-разработчик должен разбираться в методологиях разработки
любой уважайющий себя web-программист обязан хоть немного знать что такое TCP/IP, DNS… принципы работы сети — ну это перебор ребята, КОНЕЧНО ЖЕ он должен разбираться в сетях, это же его область деятельности в принципе. Производительность, это уже опыт, практика, методология разработки — нуууууу, согласен, но все таки — это не аргументы, чтоб считать ФР центральным лицом разработки.
Раньше что-то особо не парились ФР или бекенд,… ВЕБ-программист — вот оно, ВСЕ!!! этот чудо человек знает все! — как получить кучку записей из бд, как красиво написать бизнес логику, как это вывести на страницу с рюшечками и тенями и анимациями, как асинхронно подгрузить данные (ajax-ом).
Видимо, менеджеры проектов хотят максимально разделить круг задач разработки
этот занимается дизайном,
этот — версткой, js-скриптами, ajax/json
этот пишет бэкенд,
этот проектирует базу данных,
— ну вроде логично!
ну а раз идет разделение ролей — то выше описанное как по мне перебор.
по сути тогда и кассир-операционист должен знать как ведется учет персонала, бухгалтерия, ведь он работает с деньгами!
Эти все знания будут полезны, но не входит в обязанности специалиста.
Признаюсь, статью полностью не прочитал, но добавлю от себя — без понимания полного цикла работы программы (с сервером, и прочими системами), возможности анализа проблем программы, и разработки технических решений затрагивающих несколько сторон проекта, ограничены.
Возможно, мыслю со своей колокольни, потому что работаем при помощи обычного JavaScript с далеко не базовыми вещами, такие как спутниковое и кабельное вещание, 3G сеть, вещание потоков, и прочее.
Возможно, мыслю со своей колокольни, потому что работаем при помощи обычного JavaScript с далеко не базовыми вещами, такие как спутниковое и кабельное вещание, 3G сеть, вещание потоков, и прочее.
Полезная инфа.
Читаю читаю что должен знать, и хоть бы где была «архитектура» или «паттерны»…
Ребят, вы с ума посходили? Вы себе вообще представляете сколько по времени занимает «знать все»? Году к 2046 ты наверное выучишь все, что вышло на 2016-й год, и будешь способен использовать… ну а когда наверстывать прошедшие с 2016 десятки лет? Годам к 90-100? А доживешь? А когда наверстывать все, что выйдет снова за следующие годы? Напомню, что все это время вам еще нужно как минимум получать зарплату чтобы не сдохнуть с голода.
И главное — кому ты после этого нафиг нужен весь такой? Да у тебя знаний как у целого ИТ подразделения. Но по массе причин любая фирма наймет себе целый отдел вместо того, чтобы платить миллионы тебе. Потому что ты один — это чудовищный во всех отношениях риск.
И главное — кому ты после этого нафиг нужен весь такой? Да у тебя знаний как у целого ИТ подразделения. Но по массе причин любая фирма наймет себе целый отдел вместо того, чтобы платить миллионы тебе. Потому что ты один — это чудовищный во всех отношениях риск.
Хочешь быть в курсе всего но нет ноды и реакта на картинке :(
Мне кажется фронтендщикам немного сложнее чем серверным разработчикам. Для фронтенда постоянно появляется куча методологий, языков, фреймверков, библиотек и тд — и им нужно успевать за всем этим следить/изучать или хотя бы ознакамливаться, что бы быть в курсе. Мне кажется если серверный разработчик отойдет от дел, скажем, на год, то ему будет намного проще наверстать чем фронтендщику.
Глубина бекендных технологий больше. Имхо.
Если инженер (фронт, бек) отойдет от дел на 1 год — он забудет как код пишется в принципе. Даже 1 месяц пропустить — это очень много для ИТ мира.
Да, фронтенду сейчас сложнее, но не из-за того, что постоянно появляется что-то новое, а из-за того, что постоянно кто-то тянет одеяло в свою сторону и не хочет придерживаться стандартов ни для HTML, ни для CSS, и даже для JS не хотят.
Если раньше были «браузерные войны», то сейчас это можно расценивать как «холодная война браузеров»: с одной стороны и придерживаются стандартов, но с другой — вводят новый функционал, который есть только у них и больше ни у кого. Или придумывают одну и ту же фичу, но делают ее по-разному.
В бекэндах в этом плане проще. Не гнаться за чужими маркетинговыми причудами (хотя это тоже присутствует: то все на рельсы кинутся за рубинами, то на js бекенды писать начнут, то в Go начнут играть). В бекендах все по стандартам и по спецификациям коих несметная гора.
ps: Фронтенду нужно гнаться за тем, что сейчас популярно, а бекенду нужно изучать тонны материалов, которые уже существуют.
Да, фронтенду сейчас сложнее, но не из-за того, что постоянно появляется что-то новое, а из-за того, что постоянно кто-то тянет одеяло в свою сторону и не хочет придерживаться стандартов ни для HTML, ни для CSS, и даже для JS не хотят.
Если раньше были «браузерные войны», то сейчас это можно расценивать как «холодная война браузеров»: с одной стороны и придерживаются стандартов, но с другой — вводят новый функционал, который есть только у них и больше ни у кого. Или придумывают одну и ту же фичу, но делают ее по-разному.
В бекэндах в этом плане проще. Не гнаться за чужими маркетинговыми причудами (хотя это тоже присутствует: то все на рельсы кинутся за рубинами, то на js бекенды писать начнут, то в Go начнут играть). В бекендах все по стандартам и по спецификациям коих несметная гора.
ps: Фронтенду нужно гнаться за тем, что сейчас популярно, а бекенду нужно изучать тонны материалов, которые уже существуют.
Если инженер (фронт, бек) отойдет от дел на 1 год — он забудет как код пишется в принципе
Нет. Это не так. Это даже полезно на какое-то время заняться чем-то другим. Вы сами удивитесь, как быстро восстанавливаются умения. На самом деле, каждый новый виток делает разработку проще. Освоил инструмент и можешь забыть о куче сопутствующей работы, которую делал раньше. Вон сейчас иной раз даже не поймешь, на каком сайте находишься из-за того, что все освоили bootstrap.
Скорее, как мне кажется, наоборот сложно. Если вы начали работу с FrontEnd с самых последних технологий, то чтобы перейти на более низкий уровень придется очень много доизучить.
Да, порой появляются принципиально новые технологии, для изучения которых, что для «старика», что для «молодого» (в кавычках, т.к. вообще не связано с возрастом), одинаково времени потребуется (типа SPDY или HTTP/2). Но и там и там достаточно RFC прочесть. Ну это если все знания на готовых инструментах не построены.
И опять же, незнание чего-то сейчас не блокирующий фактор, а снижающий эффективность.
Немного поясню. Раньше человек делал страничку в Word или FrontPage и гордо звался Web master. Потом те, кто не захотел развиваться просто ушли с рынка, превратившись в кого-то другого. Теперь есть набор инструментов, которые позволяют создавать стили толком не понимая, что делается в CSS (bootstrap, например), писать скрипты не думая, что с этим всем делает браузер (любой framework), разрабатывать сайт не понимая, как это будет работать на сервере, т.к. development server теперь есть везде, и в gulp и в symfony и в Django и в Rails и т.д… И при смене чего-то на более глубоком уровне кто-то за вас поменяет все инструменты так, чтоб они работали с новыми технологиями. Разве что придется рекомендации почитать и перестать использовать спрайты и inline картинки в CSS.
Это не хорошо и не плохо, это движение к тому, чтоб разработчик мог сконцентрироваться на своих непосредственных обязанностях. Но это же дает возможность выпасть из отрасли, а потом вернуться в нее, как будто и не прошло года.
Как иллюстрация из современного мира — уже упомянутый мной выше WebGL. Те, кто столкнутся с ним сейчас, изучат что такое WebGL и будут изучать его с каждым новым изменением все глубже. Лет через 5-7 человек получит сильно улучшенный three.js и начнет делать то, что сейчас не представляется возможным. При этом, если технология не изменится на 100%, например не станет WebDirectX'ом, то человек, начинавший сейчас и год занимавшийся… ловлей рыбы, например, вернется, быстро просмотрит изменения и начнет что-то делать. Возможно пару месяцев он будет делать недостаточно эффективно, т.к. не знает всего набора новых инструметов и не имеет наработок. Но через 2-3 месяца он станет даже более эффективен, чем начавший с инструментов, т.к. понимает, что же там происходит внутри.
И насчет гнаться — я бы это не назвал гнаться. Но вот способ обновлять знания — было бы неплохо найти. Для себя я решил, что время от времени надо смотреть, что делают молодые команды, даже если все во мне кричит, что я сделал бы лучше. Просто потому что они не имеют кирпич опыта, тянущий ко дну, и многие вещи делают просто, даже не знаю, что когда-то так просто было нельзя.
В тоже время я ни разу не чистый FrontEnd (хм, даже чисто программистом уже сложно назваться), так что возможно для кого-то все не так, как для меня выглядит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Frontend-разработчики должны быть в теме всего