Комментарии 19
Вопрос не совсем в тему, но раз вы говорите об идеологии, не могу не спросить. Давно мучает вопрос)) Сейчас функционал старого «веб-разработчика» очень разрознен. Появились различные наименования, границы функционала которых, найти, лично мне, стало трудно. Изначально веб-разработчик занимался созданием веб-сайтов, полностью. Опустим пока backend. Как различить обязанности frontend-разработчика с верстальщиком, веб-дизайнером, веб-разработчиком, ui-диз./раз., ux-диз./раз.? Где их границы?
Я думаю, что вопрос как раз в тему. Истоки всей этой печальной ситуации сводятся к одному — бизнесу и его потребностям. А теперь раскручиваем логическую цепочку.
Бизнесу нужен максимальный доход с минимальными тратами -> обучаются и набираются не программисты-создатели, мыслители, а толпы людей, которых обучили нескольким «узким» приемам, и они только ими пользуются, правильно или нет, никого не волнует, компаниям главное, чтоб продукт работал и был сделан в срок, работникам важно получить деньги — все, какое качество продукта, новизна, креативность, Вы о чем.
Идем дальше. Огромное количество низкоквалифицированных работников -> мало того, что начинается ситуация, которая и описана в статье, так и начинается вот это мракобесие (frontend-разработчика с верстальщиком, веб-дизайнером, веб-разработчиком, ui-диз./раз., ux-диз./раз). Потому что компании смекают, что можно платить еще меньше, ставя под конкретную работу еще более узко-специализированного человека и платя ему меньше.
Не знаю, как у остальных, я надеюсь, коллеги оставят свои комментарии, но для меня теперь даже проблемно иногда сходу понять, что должно выполняться на стороне клиента, а что на стороне сервера, потому что все уже делают, кому как удобней и кого как научили.
Вывод, а заодно ответ на Ваш вопрос: часто их обязанности идентичны, кое в чем могут расходиться, все зависит от конкретной компании, что они подразумевают под тем или иным названием. Понятное дело, что различия между frontend-девелопером и дизайнером очевидны, но когда сравнивают web-разработчика и frontend-разработчика, утверждая, что это абсолютно разные понятия, ну тут я уже не знаю, как это комментировать.
В итоге, если такой хаос происходит даже в вакансиях, а соответственно, в распределении работы и ответственности, то представьте, что происходит с продуктом и качеством, о чем и пишет автор, я уверен, это он осветил нам только верхушку айсберга
Бизнесу нужен максимальный доход с минимальными тратами -> обучаются и набираются не программисты-создатели, мыслители, а толпы людей, которых обучили нескольким «узким» приемам, и они только ими пользуются, правильно или нет, никого не волнует, компаниям главное, чтоб продукт работал и был сделан в срок, работникам важно получить деньги — все, какое качество продукта, новизна, креативность, Вы о чем.
Идем дальше. Огромное количество низкоквалифицированных работников -> мало того, что начинается ситуация, которая и описана в статье, так и начинается вот это мракобесие (frontend-разработчика с верстальщиком, веб-дизайнером, веб-разработчиком, ui-диз./раз., ux-диз./раз). Потому что компании смекают, что можно платить еще меньше, ставя под конкретную работу еще более узко-специализированного человека и платя ему меньше.
Не знаю, как у остальных, я надеюсь, коллеги оставят свои комментарии, но для меня теперь даже проблемно иногда сходу понять, что должно выполняться на стороне клиента, а что на стороне сервера, потому что все уже делают, кому как удобней и кого как научили.
Вывод, а заодно ответ на Ваш вопрос: часто их обязанности идентичны, кое в чем могут расходиться, все зависит от конкретной компании, что они подразумевают под тем или иным названием. Понятное дело, что различия между frontend-девелопером и дизайнером очевидны, но когда сравнивают web-разработчика и frontend-разработчика, утверждая, что это абсолютно разные понятия, ну тут я уже не знаю, как это комментировать.
В итоге, если такой хаос происходит даже в вакансиях, а соответственно, в распределении работы и ответственности, то представьте, что происходит с продуктом и качеством, о чем и пишет автор, я уверен, это он осветил нам только верхушку айсберга
Но ведь чем уже специальность, тем сложнее найти работника. Это ставит под вопрос "дешевизну" узкоспециализированных специалистов
Бизнесу нужен максимальный доход с минимальными тратами -> обучаются и набираются не программисты-создатели, мыслители, а толпы людей, которых обучили нескольким «узким» приемам, и они только ими пользуются, правильно или нет, никого не волнует, компаниям главное, чтоб продукт работал и был сделан в срок, работникам важно получить деньги — все, какое качество продукта, новизна, креативность, Вы о чем.
Дану, поэтому всем подавай «фуллстэков» сейчас?
(frontend-разработчика с верстальщиком, веб-дизайнером, веб-разработчиком, ui-диз./раз., ux-диз./раз)
Верстальщик, как отдельная профессия, уже вроде совсем выродилась, и лично я ни разу не встречал ситуацию когда за UI и UX отвечали бы разные люди, что-то вы выдумываете.
Вы точно внимательно читали мой комментарий?
Я ж и говорю о том, что компании занимаются искусственным разделением на специальности, да, верстальщика, которого мы знали, нет, но вакансий на верстальщика полным полно, 5 минут погуглить и Вы сами их штук 50 без труда найдете, смотрим требования этих вакансий и удивляемся, там уже и глубокие знанияJS нужны, а некоторые даже запрашивали знания PHP и баз данных (на верстальщика!!!)
Об этом и есть мой комментарий, что хаос твориться с определением, кем является тот или иной фронтендер, чем и пользуются
А про UI/UX я просто скопипастил предложение предыдущего комментатора, мне было лень переписывать:) Вы совершенно правы, это один человек
Я ж и говорю о том, что компании занимаются искусственным разделением на специальности, да, верстальщика, которого мы знали, нет, но вакансий на верстальщика полным полно, 5 минут погуглить и Вы сами их штук 50 без труда найдете, смотрим требования этих вакансий и удивляемся, там уже и глубокие знанияJS нужны, а некоторые даже запрашивали знания PHP и баз данных (на верстальщика!!!)
Об этом и есть мой комментарий, что хаос твориться с определением, кем является тот или иной фронтендер, чем и пользуются
А про UI/UX я просто скопипастил предложение предыдущего комментатора, мне было лень переписывать:) Вы совершенно правы, это один человек
Вот например, первое же, что нашел)
www.work.ua/ru/jobs/3507909
тут вообще интересность начинается с первого же предложения. В вакансии четко написано, HTML-верстальщик, и тут же в первом же требовании к соискателю:
опыт работы на позиции Frontend Developer не менее 3 лет
ну не бред ли? и предложат же заработную плату, как верстальщику, а не как фронту (в большинстве случае, не уверен, может где-то просто рекрутеры не совсем корректно понимают, о чем речь, но зп платят исправно и по делу).
Но вот такая дичь встречается регулярно, повторюсь, открыл первую же вакансию
www.work.ua/ru/jobs/3507909
тут вообще интересность начинается с первого же предложения. В вакансии четко написано, HTML-верстальщик, и тут же в первом же требовании к соискателю:
опыт работы на позиции Frontend Developer не менее 3 лет
ну не бред ли? и предложат же заработную плату, как верстальщику, а не как фронту (в большинстве случае, не уверен, может где-то просто рекрутеры не совсем корректно понимают, о чем речь, но зп платят исправно и по делу).
Но вот такая дичь встречается регулярно, повторюсь, открыл первую же вакансию
Я понял вашу мысль, но мнe кажется тут еще присутствует такой фактор как неумение некоторых работодателей нормально заполнять требования к вакансии.
Сам был свидетелем, как тимлид сказал HР-у что нужен java программист, но будет неплохо если человек хоть немного знаком с C/C++. После чего HR написал в требованиях «необходимо знание C/C++» (сама вакансия называлась «Java developer»)
Сам был свидетелем, как тимлид сказал HР-у что нужен java программист, но будет неплохо если человек хоть немного знаком с C/C++. После чего HR написал в требованиях «необходимо знание C/C++» (сама вакансия называлась «Java developer»)
Веб не перегружен JavaScriptом-он перегружен студентами, которые не понимают, как делать более правильно.
Сколько лет уже этим песням, а JS похоже все равно продолжает двигаться в какой-то диаметральной плоскости.
Я опускаю непонятные рассуждения на тему терминологии на примере ос и пчел, опускаю лозунги про светлое будущее и навязывание паттернов. Но я упорно не могу понять, почему скорость работы приложения на Nokia 2 должна быть одним из основных критериев для бизнеса. И почему личные потребности конкретного программиста в какой-то чистоте, структурированности, оптимизированости и в общем перфекционизме, должны экстраполироваться на других программистов, на бизнес, на пользователей и называться ответственным подходом.
В целом я с автором согласен, и тоже за все хорошее, против всего плохого. Но рассмотрение продукта и производственного процесса лишь с точки зрения программиста, с заключением многозначительных выводов о том что хорошо, что плохо, мягко говоря, отдает предвзятостью. А мир не идеален.
Я опускаю непонятные рассуждения на тему терминологии на примере ос и пчел, опускаю лозунги про светлое будущее и навязывание паттернов. Но я упорно не могу понять, почему скорость работы приложения на Nokia 2 должна быть одним из основных критериев для бизнеса. И почему личные потребности конкретного программиста в какой-то чистоте, структурированности, оптимизированости и в общем перфекционизме, должны экстраполироваться на других программистов, на бизнес, на пользователей и называться ответственным подходом.
В целом я с автором согласен, и тоже за все хорошее, против всего плохого. Но рассмотрение продукта и производственного процесса лишь с точки зрения программиста, с заключением многозначительных выводов о том что хорошо, что плохо, мягко говоря, отдает предвзятостью. А мир не идеален.
По-моему, пчёлы что-то подозревают!
Обычно бывает так, что лучше от системы клиентской маршрутизации отказаться.
Уже долго интересуюсь чужими мнениями на свои вопросы. Зачем вообще может понадобится клиентский роутинг в одностраничном приложении? И кто в команде должен решать какой роут (его название, их количество) соответствует какому состоянию приложения?
Не рассматриваю тот вариант, когда команда решила делать контентный сайт, допустим, на ангуляре, прости господи)
как фронт-ендич хочу заметить, что тут не вина JS или разработчиков, а просто неправильный подход к разработке, который идет от бизнеса/менеджера по разработке (ну и конечно же мейнстрим хайпа).
Раньше как, все понимали, что что-то ресурсоемкое нужно делать на сервере, пусть долго, пусть сложно, но это должно быть на хорошем сервере, чтоб у пользователя не возникало проблем. Теперь практически все можно отдать на клиента вместе с бизнес логикой (быстро и легко в разработке) — быстро вывели, дешево сделали — зарабатываем.
При правильном подходе (код сплитинг, импорт только нужных компонентов + SSR) любое тяжелое SPA становится быстрым и легким, на это иногда приходится тратить столько же, а то и больше времени чем на разработку. И тут к менеджеру продукта приходит истина, что сделав бизнес логику на сервере и отдавать конечный результат на клиента — дешевле и быстрей, и пользователям так больше нравятся. Но уже прошел N времени, бабки утрачены, бэкндиков нет. Пилим и плачем дальше.
А так очень годная статья.
Раньше как, все понимали, что что-то ресурсоемкое нужно делать на сервере, пусть долго, пусть сложно, но это должно быть на хорошем сервере, чтоб у пользователя не возникало проблем. Теперь практически все можно отдать на клиента вместе с бизнес логикой (быстро и легко в разработке) — быстро вывели, дешево сделали — зарабатываем.
При правильном подходе (код сплитинг, импорт только нужных компонентов + SSR) любое тяжелое SPA становится быстрым и легким, на это иногда приходится тратить столько же, а то и больше времени чем на разработку. И тут к менеджеру продукта приходит истина, что сделав бизнес логику на сервере и отдавать конечный результат на клиента — дешевле и быстрей, и пользователям так больше нравятся. Но уже прошел N времени, бабки утрачены, бэкндиков нет. Пилим и плачем дальше.
А так очень годная статья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ответственный подход к JavaScript-разработке, часть 1