Pull to refresh

Comments 164

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


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


И ты смотришь на него и думаешь — ну может так и быстрее, но нужен ли он нашему стартапу, приятно ли будет иметь с ним дело?


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

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


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

Смотрите, всё намного проще. Если вы придёте, покажете себя толковым разработчиком на собеседовании, лучше других, вас скорее всего возьмут. Про обучаемость умных чуваков все знают, и имеют это в виду (ну кроме совсем уже забюрократизированных контор, где на входном фейс-контроле стоит бездушный и безмозглый робот).
Но вот допустим пришли вы в какой-то там ЕРАМ. Там эйчар на одну вакансию уже тридцать резюме собрал. И вы там не один толковый, там ещё три парня есть, и два из них уже реакт могут «из коробки». Какой им смысл брать именно вас, если другие на собесе были не хуже, и сразу имеют нужные им скиллы? Ну да, это действительно второстепенный навык, и человек, если умеет программировать, сможет в достаточно короткие сроки освоить другой фреймворк. Но если у нанимателя нет более достоверной информации о том, кто лучше умеет программировать, а есть только информация о том, что несколько человек таки умеют, но кто-то из них знает нужный стек, а кто-то не знает?
Вроде как логично, но как-то оторвано от реальности. По факту эйчар нашёл под сотню вакансий, из которых удалось уговорить пообщаться десяток, из которых хорошо если пара человек с натяжкой соответствуют заявленному уровню, и если попадается действительно хороший спец, даже при неполном попадании в стек — скорее всего его будут пытаться нанять всеми силами.
Смотря какая компания. Если компания известная, а зарплата рыночная (или тем более больше рыночной), то количество годных спецов в выборке будет куда больше, чем пара из сотни. А если компания не особо известная, то они обычно и не перебирают, а действительно берут первого умного.
Ну и опять же таки, React сейчас — мейнстрим, специалистов, которые с ним работали, навалом, и хороших, и не очень. Это скорее исключение, когда к вам на собеседование React-разработчика пришёл кто-то, кто не знает React.
На тот же реакт любая парадигма натягивается

В отличии от того же vue.js :D
По этому заставить чела который раньше фигачил на react, теперь фигачить на vue/angular проще чем чела который фигачил только на vue. ИМХО.

Такое же ИМХО:

Ы-ылитарность, В-вкусовщина. Тот же реакт ничуть не сложнее, в общем и целом, чем ангуляр или вью. Рокет-сайенс отсутствует во всем вышеперечисленном. Человек, не освоивший реакт, в 99% случаев и вью не осилит. А в масштабах команды на существующем проекте вся эта разница в фреймворках вообще сводится к «подсмотрел в соседнем файле, как тут принято, написал так же».

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

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

Реакт сам по себе проще, чем ангулар. Отсюда и больше поклонников. Ангулар больше заточен на крупные приложения, а реакт нет. Чем больше проект, тем структура на Ангулар не сильно усложняется. Тогда как на реакте все зависит от архитектора проекта и скилов команды разработки. Т.е. кашу наварить очень легко.
Имхо реактовиков больше так как новички при выборе первого инструмента или, если угодно, старички переходя во фронтенд смотрят статистику по вакансиям
Человек, не освоивший реакт, в 99% случаев и вью не осилит

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

Мне вот реакт зашёл на ура. Не могу сказать в чём конкретно, но как-то чувствуется какая-то близость к PHP-like бэкенду.

Ну, я начинал вообще с десктоп-разработки на Windows Forms. Потом ASP.Net… а сейчас, можно сказать, в фуллстек ушел.

С одной стороны, хочется восхищённо сказать «Три пива этому столику!», с другой стороны, – ну вас, с вашими полторашками.
Образность немного зашкаливает для приличного общества.

Такой подход — просто ещё один способ сбить зарплатные ожидания

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

И не сможешь отличить хорошего от не очень.

Плюс боятся что будут выглядеть в глазах сишарповца тупарём, когда не сможешь правильный вопрос задать.
Меня за примерно 10+ лет опыта ни разу на собеседовании не спрашивали про какие-нибудь особенности языка. Только что-то совсем общее, типа как GC работает, например. Более того я каждый раз менял язык при смене работы и никогда не писал на этом языке до этого. Давно писал на С++ и Perl, потом перешел в другое место с Python и Java, год назад перешел на Go и Ruby. Язык это инструмент и как правило незначительная вещь, не говоря уж про фреймворки.
А собеседования прекрасно проводились и меня понимали на том языке, который я знал.
Вам повезло видимо). Проходил как-то перед пандемией собеседованиям, так меня гоняли по особенностям языка, которые не то, что нужны, а вредны. Js: [] ==![]
Мне кажется, такие вопросы сигнализируют о том, что на эту работу не стоит устраиваться.
Я, когда меня спрашивали какие-то оторванные от реальности вещи, говорил примерно в таком стиле — «Я не знаю что будет, и не стал бы так делать. Но если это техническое задание, и вы его обоснуете — я поставлю эксперимент, чтобы узнать результат. Запоминать такое не буду.»

Думаю, приелось. Гораздо более неожиданным и возмутительным стало бы, если бы Филипп Ранжин написал скучную километровую статью про код.

Да, жаль только ты бы не стал её читать. Первые три страницы комментов в твоем профиле — ни один из них не комментирует технические статьи. Зато вот в мои статьи с мнением про индустрию ты заскакиваешь регулярно. Может как-то уже пора принять в себе, что заходишь сюда отдохнуть, а не поучиться?


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


Есть статья про разные модели типизаций — тут действительно глубоко копнул. Была статья про либу, которую делали с другом — тоже есть какой-то экспертный взгляд, я им поделился.


Когда в индустрии есть какая-то проблема, и я могу об этом поразмышлять — я это делаю. И люди читают. В чем проблема?

Тролль подорвался на тролльской мине )
Давно ли комментарии стали для тебя проблемой?


Короче, слушай сюда, я дам покурить тебе свои старые портянки ЖЖ:
даже "лирический" текст, написанный ради трёпа, только выиграет в качестве, если продумать его так же тщательно, как километровую простыню с подсвеченным синтаксисом.
Даже в текст ради трёпа можно и нужно вкладывать чуть больше, чем полторы тривиальные мысли.
Хочешь стать настоящим самураем, точи клинок хоть иногда, а то так и будешь крапиву сшибать.

Простите, но почему вы измеряете читаемость статьи количеством комментариев к ней?

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


Опять же, учитывая качество этих коментов, он явно не из тех, кто откажется что-то написать, потому что не очень хорошо разбирается в теме

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

Тут ещё проще (fillpackart не дотянул туда свою логическую цепочку):
интересные мне статьи по интересующему меня ЯП появляются на Хабре примерно раз в квартал :)

UFO just landed and posted this here
UFO just landed and posted this here

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

Можно, например, упрекать их за отсуствие темы для обсуждения. Например, пересказали туториал или спеку — что тут обсуждать?

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

)) а много из них можно назвать чисто техническими?

Думаю, две-три. Что кстати намного больше, чем у большинства здесь

Если тебе просто надо порендерить четыре формы, то тебе не нужен ни реакт, ни тайпскрипт, ни вебпак — ничего. Создаешь три файлика .html, .css и .js — вот тебе и приложение.

Вот не надо тут. Я недавно делал сайт с корзиной — простейшая форма типа когда пиццу заказываешь, добавить / удалить товары, жмешь далее, вводишь телефон с именем, на почту падает письмо "поступил заказ блабла"


И я вот этими вашими "фу, фреймворки" впечатлился, решил на чистом js. Ага, началось, по изменению идешь document.getElementById обновлять. А ещё "итого" пересчитай. В конце концов, на функционале "далее/назад" плюнул и быстренько переписал на реакте. Все чисто, аккуратно, вся логика уместилась в useReducer.


В общем, предъявляю что автор не пробовал написать 4 формы на чистом js уже n лет и гонит пургу.

Я на чистом TS написал целый фреймворк для датагридов с 0 зависимостей. Что я сделал не так? :)

Да вон есть очень известный и очень неплохо работающий leaflet — там целая картография на голом js, и причём написанная кодом очень неплохого качества и организованности.

Ну вот знаете, всё ведь от человека зависит в конце концов. Можно и на голом JS запилить, а можно взять что-то чтобы поднять скорость.


Мне вот, короче, кажется что перед тем как использовать фреймворки — стоит какое-то время позапиливать сайтики на голом JS и HTML. Просто чтобы иметь представления о проблемах, которые фреймворки решают.

Этак вы сейчас договоритесь до того, что и 5 лет реакта в вакансиях не надо требовать, а вместо этого смотреть на знания базовых технологий; а ночью за вами приедет черный воронок и больше вас никто не увидит!

^_^

Я вот искал себе в команду фронтендера — опросил десяток знакомых на предмет "а как их собеседовать?". Семеро мне сказали — "ищи того, кто хорошо шарит в JS, остальное фигня".

Я бы взял любой шаблонизатор (lit-html и подобные), а остальное таки бы преспокойно сделал на vanillajs. Десятки document.што-то-там и element.што-то-еще на любой чих — сомнительное удовольствие даже в write-only коде, но вот тащить реакт, чтоб «итого» пересчитывать — да нет, оно реально не требуется.

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

Ну то есть, я к чему клоню — можно обходиться без реакта (заменить на любой другой конкретный фреймворк), но при определенном объеме сложно обходиться при этом и без своих фреймворков, пусть и более простых. Можно запилить на голом js 4 формы — но вряд ли стоит это делать, если форм будет 40, и их нужно будет сопровождать, потому что типовые решения — это сразу «типовые разработчики», если угодно.
Да, естественно. Соль в том, что для 4х форм я могу не брать реакт, а взять процентов 10-20 самого полезного (например компоненты или шаблонизацию) и этим сократить 80% унылого кодописательства для этих моих 4х форм.

Да и даже для сорока форм часто можно так делать. Проектов, где прям нужна подавляющая часть кода того же реакта (или тем более ангуляра) — на самом деле не так много. Вы не фейсбук и не гугл.

и их нужно будет сопровождать, потому что типовые решения — это сразу «типовые разработчики», если угодно

Если у вас есть разработчик, который может в реакт, но не может в другие библиотеки с солидной степенью подобия — значит вы взяли очень плохого разработчика, который со временем вам и в реакте такого «наподдерживает», что надо будет переписывать всё.
Я бы взял любой шаблонизатор (lit-html и подобные)

И в чем их преимущество в сравнении с тем же preact'ом?
В чем преимущество яблок в сравнении с морковью?

Правильный ответ — «это разные вещи». Мне не нужен VDOM для уменьшения объема кода на условных «четырех формах».

Вот если б вы спросили «в чем преимущество lit-html в сравнении с jsx» — это было бы более правильным вопросом, и я бы рассказал, например, про то, что tagged template literals сами по себе являются нормальным JS и не требуют транспиляции, в то время как jsx сам по себе ни в одном браузере в мире не запустится. Или про то, что preact, при всём моем к нему уважении, всё-таки тянет с собой VDOM, а не просто превращает jsx в рабочий код, и инструмента только для шаблонизации (без чего-либо еще реактового) для jsx нет.

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

А, вижу, там вместо значений подставляется псевдослучайный маркер — и получившаяся строка используется как идентификатор шаблона. Ну, это позволяет дереву VDOM расти не так глубоко как в Реакте — но для вложенных шаблонов всё равно дерево получается.

Я бы даже сказал, что иногда и форм не надо. При помощи фреймворка (leaflet) вы сделаете карту, ну не за 15 минут, а скажем за день. На голом js считай вообще не сделаете никогда. Идеологически карта выглядит даже проще, чем четыре формы — всего-то одна «картинка», которую можно зумить и панорамировать — но за ней лежит столько всего, что писать это с нуля как правило совершенно бессмысленно.

Ну в общем, таких примеров думаю можно привести полно, стоит лишь чуть подумать.
А если написать пару функций-обёрток для упрощения работы с выбором элементов?
Чтото вроде собственного jQuery-lite (только ещё меньше).
Я не могу себе позволить делать свои проекты на чистом джаваскрипте, потому что тогда меня никто не возьмет на работу.

Но это очевидная неправда. Я могу в свое резюме написать много страшных названий фреймворков и условные «года опыта», но на собеседованиях всегда говорю, что кроме принципов их устройства и общих достоинств/недостатков обсуждать их не собираюсь, и проходить экзамен по их API и уж тем более его тонкостям — тем более. Меня преспокойнейше берут на работу. За всё время пришлось послать лесом только одну контору, да и то это была контора HR, которая вознамерилась меня экзаменовать по реакту даже после того, как им открытым текстом было сказано, что если им надо такое — то пусть говорят с кем-нибудь другим.
Я понимаю, когда тебя не готовы взять на другой ЯП — они тоже очень сложные. Но, Господь Всемогущий, кто-то действительно верит, что asp.net webApi прям так критично отличается от asp.net core?
Не знаем именно про asp.net упомянутые, но фрейворки друг от друга зачастую отличаются сильнее чем ЯП. Просто потому, что фреймворк обычно предоставляет больше возможностей чем ЯП, а больше возможностей — больше сложность — больше отличия от другого аналогичного фреймворка.

Фреймворки обычно пишут на том же ЯП. Фреймворк — подмножество всего кода на этом ЯП. У него не может быть больше возможностей, чем у голого ЯП

Фреймворк — подмножество всего кода на этом ЯП. У него не может быть больше возможностей, чем у голого ЯП
Вы любопытно трактуете термин возможность.
Возьмем возможность работать с БД через ORM (как абстрактный пример).
В голом ЯП она обычно есть? Нет.
В фреймворках обычно есть? Да.
Hазумеется можно сказать, что в голом ЯП тоже есть такая возможность, но Вам придется добавить фразу «только сначала надо расширить ЯП добавив туда ORM» и вот именно в момент добавления этой фразы Вы превращаете ЯП в фреймворк — надмножество ЯП:)

Вот как раз думаю написать пост об использовании ORM (напомню, что это лишь архитектурный паттерн) на голом PHP :) Без сторонних библиотек, но и без изобретения универсальных велосипедов. Простые примитивы ЯП в объёме несравнимом с объёмом популярных библиотек, реализующих ORM.


Или по-вашему, написав одну функцию я расширяю возможности ЯП? Так возможность написания функций заложена в ЯП. Фреймворк же ограничивает, навязывает свою архитектуру.

Без сторонних библиотек, но и без изобретения универсальных велосипедов. Простые примитивы ЯП в объёме несравнимом с объёмом популярных библиотек, реализующих ORM.
*картинка про 14 и 15 стандартов*. Много ORM библиотек начинали именно с такой идеи- напишем мол кратко и четко без всякого хлама.

Или по-вашему, написав одну функцию я расширяю возможности ЯП?
Да, именно так.
Потому что до функции Вы могли а и б сложить только через а+б, а после уже можете написать адд(а, б). Это новая возможность.

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

Фреймворк же ограничивает, навязывает свою архитектуру.
Не, фрейворк предлагает возможности. Ограничиваться сугубо ими или нет — решает программист. То что у Вас машина, не значит что Вам нельзя ходить пешком. Хотя да, программисты из соседнего отдела могут зачморить за нарушение инкапсуляции и расшаривания публичного доступа к приватным свойствам.
картинка про 14 и 15 стандартов.

Неуместна. Я про прямую, ad-hoc имплементацию паттерна без намёка на библиотечность.


Да, именно так.

Не согласен, в синтаксис и семантику ЯП заложена возможность получить сумму множеством способов, в том числе и путем написания функции add


Это разные возможности.

Нет. Я имею возможность водить водить машину — надо только научиться.


Не, фрейворк предлагает возможности.

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

Неуместна
Все так говорят:) Любой набор функций уже можно назвать библиотекой. Опять же — вопрос терминологии.
Не согласен, в синтаксис и семантику ЯП заложена возможность получить сумму множеством способов, в том числе и путем написания функции add
Вы смешиваете в кучу возможность написания функции и возможность ее использования. Первое в ЯП есть, второго будет только когда эта функция будет написана, а когда она будет написана, это будет уже фреймворк.
Нет. Я имею возможность водить водить машину — надо только научиться.
Вы будете иметь эту возможность когда научитесь. До этого у Вас есть только возможность научиться.
Не, фреймворк предлагает добровольные ограничения в использовании ЯП в обмен на уменьшение количества бойлерплейта.
«Предлагает добровольно»!=«ограничивает принудительно», это как раз «предлагает возможности» — о чем мы и сказали.
Любой набор функций уже можно назвать библиотекой.

А можно не называть. А можно наш диалог назвать фреймворком или библиотекой. Но я предпочитаю более общепринятые трактовки терминов.


Вы смешиваете в кучу возможность написания функции и возможность ее использования.

Возможность использования — подмножество возможностей написания. Можно написать и не использовать, но нельзя не написать и использовать.

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

Ни один фреймворк, написанный на каком-то ЯП, не может добавить возможностей к этому ЯП.


Рассказывал: "конкретно Java не знаю, но вот посмотрите мой код на PHP и список интересных задач, которых я на нём решал типа взаимодействия АРМ в браузере с фискальным регистратором рядом с сотрудником"

Думаю, мысль заключалась в том, что язык предоставляет инструментарий, а фреймворк — разные фичи, реализованные при помощи этого инструментария(но при этом фреймворк не может реализовать те фичи, которые не поддерживает инструментарий).
Фишка в том, что каждый из фреймворков под капотом использует существующие концепты.

Посмотрите на фронтовый ангуляр и бэковый nest.js. Если вы учили что-то одно из этого, большая часть концепций другого будет понятна даже без дополнительного чтения документации.
Flux из redux переиспользуется как минимум в том же Vuex.
Концепция компонентов используется вообще везде, где не лень.
Зная концепцию Proxy или Observer, несложно понять на высоком уровне работу стейтов(подхват изменений).

Потому мне ближе та точка зрения, что если ты знаешь базу(включая сам язык, принципы и алгоритмы), то изучить новый фреймворк или язык — это дело времени и памяти, не более того. После определенного опыта новые концепции начинают встречаться все реже и реже.
Фреймворк — подмножество всего кода на этом ЯП. У него не может быть больше возможностей, чем у голого ЯП
Так же, как поэма «Евгений Онегин» и роман «Идиот» являются подмножеством русского языка? Тогда у них не больше возможностей, чем у сочинения «Как я провёл лето» за седьмой класс.
Но ведь вы только что сравнили фреймворки, признанные сообществом, и лабы по информатике, а не фреймворки с самим языком…
В C# или Java стеке все ещё хуже — у нас есть один основной фреймворк,

В Java есть "основной фреймворк,"??? Сколько их штук?
Я когда решил свой пет проект делать не на C# а на Java, слегка прифигел от разношёрстности экосистемы. Мало того что разношёрстная так ещё и не всё между собой совместимо без костылей...


и надо выбрать тупого шарпист или умного джависта.

Вообще не вижу глобальной разницы между C# и Java, с C# на Java больно спрыгивать. Но не в плане языка. А в плане синтаксического сахара. Те же async/await, геттеры/сеттеры. Не то что бы в java их нет, там есть например streams. Но streams был сделан в угоду некой мифической совместимости, и не удобный.
Лично мне сложно представить чела который захочет соскочить на постоянной основе с C# на Java. Как развлечься это ещё вариант :)


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

Например попробуй фронтендера попросить пофиксить бэкенд, когда например бэкенд разраб в отпуске, а что-то срочно надо поправить… В лучшем случае мягко откажут, в худшем пошлют на… и уволятся. (не шутка, сам наблюдал такое). А вот бэкендеров почему-то просят фиксить фронт.
Дело в ответственности.
Упрощенно говоря: что на фронте не городи — база в проде от этого не дропнется — ничего критичного не произойдет, а вот малейшая ошибка на бакэнде может убить проект так или иначе рано или поздно.
Поэтому над фронтом можно приглашать работать почти кого угодно, а вот над бэком только людей в этом понимающих.
вы удивитесь, но даже бекед в обычных энтерпрайз можно заархитектить так,
что на него можно будет приглашать работать кого угодно, имея 2 х человек, которые чуть что смогут вывезти любой косяк который нагородят остальные 10…
C# и asp.net core как раз для этого и придумали

имхо фронт сейчас сложнее бека
есть мнение что джава умрет, Kotlin Node.js и .Net Core делают свое дело
>И попробуй откажи.
согласен.

Например попробуй фронтендера попросить пофиксить бэкенд…
А вот бэкендеров почему-то просят фиксить фронт. И попробуй откажи.

ИМХО, это кейс вашей команды. Я на одном из проектов будучи фронтендером писал API просто потому что, когда надо было первый читать доку по JAX-RS у меня было больше времени, чем у бекендера. Ну или может фронтендеры отупели за последние 3-4 года, но по-моему половина моих коллег знает что-то из PHP/Java/C# на уровне джуна хотя бы, не говоря уже о Ноде.

Вот кстати у меня такой же опыт. Я нанял к себе в команду фронтендеров, и частенько прошу добавить пару контроллеров на C# — по аналогии с существующими. И все норм, делают

Дайте угадаю, вы бэкендер?
Я 10 лет работал бэкендером и 2 года фронтом, и скажу что и тут и там заморочек хватает. Там где бэкендер экономит цпу и поход в базу, фронт экономит перерендеры и пересчеты vdom, чтобы оно завелось на условном андроид 4

Angular отстой, ну и есть еще Vue.js, Svelte и др. и даже, прости господи, Blazor…
вообще тема стара как мир
вот вполне разумный для наших реалий хоть и радикальный доклад,
который не противоречит выводу статьи, а скорее дополняет
www.youtube.com/watch?v=jiJxA37hmsQ&ab_channel=ManagementChannel
для наших СНГ реалий, прагматизм и простая как палка логика важнее смутной перспективы, нанят творца-разраба который свалит через год
А можно услышать более аргументированный ответ на счет того что Ангуляр отстой? Об этом много говорят, но аргументы какие-то всё в основном нелепые приводят. Что же в Ангуляре не так-то?

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

Но что это значит в контексте разработки и конкретно на примере Ангуляра? И почему это плохо? Что нельзя сделать на Ангуляре, но можно сделать на других более лучших фреймворках?

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

Извините, но это больше похоже на маркетинговый текст, только наоборот. Много слов, но ничего конкретного. Вопрос вполне конкретный: какие параметры в Ангуляре заставляют людей писать вот такие вот комментарии выше про то что он отстой. При этом, как я понимаю, такие комментарии в основном пишут люди которые «давно не имели с ним дело» или вообще с ним дела не имеют, зато мнение имеют)

не поймите не правильно
я могу оставить вам пример банальной сравнительной статьи
вот хоть эта https://habr.com/ru/post/476312/
в индустрии важнее всего скорость и размер артефактов
ангуляр в этом всем проигрывает (я понимаю что есть разница между lib и framework)


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

не поймите не правильно
я могу оставить вам пример банальной сравнительной статьи
вот хоть эта habr.com/ru/post/476312

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

А разве в Реакте тебе не нужно изучать дополнительно 100500 таких же абстракций и библиотек для того чтобы сделать тоже самое?

Реакт не слишком opinionated когда заставляет писать все на своем JSX? Что вообще значит слишком opinionated? Лучше когда каждая компания разрабатывает свои React guidelines?

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

В том-то и дело, что не нужно много. Если уже владеешь ванильным фронтендом.

А можно немного поподробнее? Ангуляр будет мешать вам использовать свои ванильные навыки? Или вы имеете ввиду что в Реакте на больших проектах можно себя прекрасно чувствовать зная только ванильный фронтенд и ничего дополнительно больше не нужно?

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


Не ничего дополнительно больше не нужно, а мало дополнительных знаний нужно, при этом мало и "забудьте всё, чему вас учили".

То есть в Реакте такого нет, из проекта в проект кочуют все 15 вариантов одной и той же библиотеки?)))

Не очень понял кто куда кочует. Пример можно более конкретный?

Когда работаешь на Реакте при смене компании/команды/проекта набор библиотек всегда один и тот же? И там не нужно ничего нового учить?

Как раз нет, если проект более-менее серьёзный, то он уникален по зависимостям.


И не 15 вариантов одной библиотеки, а, условно, 15! вариантов комбинаций разных. Одних популярных стейт-менеджеров штуки три, не считая двух или трёх встроенных в сам реакт. Но прелесть в том, что это, как правило, обычные js/ts-библиотеки, гвоздями к реакту не прибитые, а имеющие отдельный "биндинг" %libname-react

Так чем же вариант с Реактом, когда приходится под каждый проект подбирать свой набор библиотек и учить 3 варианта одной библиотеки ЛУЧШЕ варианта Ангуляра когда у тебя ОДИН стандартный набор который во всех проектах один? Мне кажется я что-то конкретно не догоняю.

Вы можете подобрать тот набор библиотек, который лучше для конкретного проекта.


P.S. Не понимаю, что значит "учить три варианта одной библиотеки". реакт 15, 16 и 17?

Вы сами сказали что одних менеджеров состояний в Реакте штук 5, и при этом их набор может меняться с каждым проектом. По факту, может быть так что под каждый новый проект придется переучивать половину всего стека. При этом вы говорите про Ангуляр с его одним стандартным набором либ, который во всех проектах один и тот же — нужно «забыть всё что знаешь».
А зачем вообще под каждый проект «подбирать» свои библиотеки? Они что, все настолько кривые что их постоянно нужно «подбирать»?
Все дело в том, что ангулар предлагает архитектуру с коробки, которая устраивает минимум на 80%. Реакт по своей сути ничего не предлагает. Причина в фейсбуке. Они развивают реакт как им надо, а не сообществу. Сообщество соответственно начинает развивать свое. Сообщество огромна и по своей сути без явного лидера и костяка. Отсюда и весь этот зоопарк

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

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

Ну я выбираю и вилки, и ложки, и ножи. Для свинины, например, один нож, для говяжьего стейка другой.


Примерно правильно. Не то чтобы ненужную, а ту, которая начинает больше мешать чем помогать.


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

Тут я с вами соглашусь, если срок неделя, то Реакт тут вне конкуренции.

Когда у тебя ОДНО хорошее решение — это замечательно. А вот когда у тебя есть ОДИН кривой вариант, то как-то грустно становится и хочется большей гибкости. Было дело я прикручивал MobX к Angular, чтобы уменьшить число багов и увеличить скорость. Не скажу, что обошлось без костылей. Прочем, и к Реакту прикручивать что-либо не вписывающееся в его философию — боль и страдания.

Когда ты вырос до такого уровня что можешь писать свои фреймворки(а в вашем случае, я полагаю это именно так), тогда тебе становиться некомфортно в любом фреймворке. Ведь фреймворк он на то и фреймворк, чтобы дать некие рельсы начинающим, не так ли?
И да и нет. Фреймворк позволяет всей команде мыслить в одном русле, проще взаимодействовать с сторонними разработчиками. Когда у вас свой велосипед, приходиться постоянно обучать персонал. Что усложняет привлекать сторонних разработчиков, ведь они не в курсе вашего велосипеда. Даже вроде такие ит гиганты РФ как yandex, mail, стараются использовать популярные готовые решения, а не пилить свое

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

Думать, что какая-то one button to rule them all устроит все компании — в высшей степени наивно.
А уж про более сложные UI-элементы и вовсе смешно.

Ровно по этой причине «библиотеки готовых компонент» для фронта взлетают довольно вяло, даже если их производят мегакорпорации типа гугла. Некоторым подходит. Другим нет. Последних сильно больше.

Думать, что в каждой компании какие-то уникальные требования ко кнопкам и прочим даже сложным ui элементам — не менее наивно.


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

Думать, что в каждой компании какие-то уникальные требования ко кнопкам и прочим даже сложным ui элементам — не менее наивно.

«Думать, что люди уникальны — наивно» (с)
Когда совокупные требования представляют собой довольно большой набор параметров, пусть и возможных значений каждого параметра — немного, в целом количество возможных вариантов всего пакета — куда больше.

Вяло взлетают они из-за херовой кастомизируемости.

Это, очевидно, не так, потому что есть и мегакастомизируемые решения, которые точно так же не взлетают. Потому, что они слишком кастомизируемые, и там нужно 100500 раз подумать о всех возможных опциях просто чтоб компонент нарисовать.
Плюс, каждая библиотека поет много песен о своей всесторонней кастомизируемости. Проблема «лишь» в том, что создатели библиотеки и её пользователи имеют разные представления о том, какая же именно кастомизируемость главным образом нужна. Это то самое несовпадение по набору параметров, о котором я выше написал.
есть и мегакастомизируемые решения

У них мегапереусложнённое апи. Но по степени кастомизации это в основном детский сад. Думаю, пока вы не попробуете $mol, ну или БЭМ хотя бы, мы не придём ко взаимопониманию.

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

https://github.com/nin-jin/HabHub/issues/23


Неужели можно так придти куда-то в команду, сказать — все ваши фреймворки отстой, я буду mol использовать! и будет всё норм?

Всё зависит от степени вашего влияния на технические решения.


полное отсутствие каких-либо туториалов на эту тему

https://github.com/eigenmethod/mol#tutorials


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

Скорее пару тройку десятков. Но да, цена этому — несовместимость с кривой экосистемой.

Спасибо, за статью, прочитал полностью. Многое показалось интересным, согласен что индустрия как правило выбирает самый «безопасный» путь. Я думаю у вас может получится, может не в первой тройке оказаться, но в одном из первых мест среди тех кто понимает, можете оказаться заслуженно.

Что мне не хватило из всей информации, которую я прочитал, так это ссылку на код с большим проектом — как Real World App. Те, несколько приложений типа Hello World интересно выглядят, но что насчёт чего-то реального? С управлением состоянием, авторизацией и других ОРМ? Не у всех может хватить опыта чтобы выяснить это по паре-тройке туториалов и исходникам. Иногда очень удобно посмотреть 2 часовой туториал и сделать уже какие-то выводы.

Процитирую текст из статьи:

Простое, казалось бы, приложение, которое на $mol можно было бы реализовать за несколько дней да ещё и в более качественном виде, мы пилили на Ангуляре несколько месяцев и получалось так себе — огромный бандл, медленная работа, медленные тесты, просто тонны кода и, конечно, куча кастомных компонент, так как существующие либо не настраиваются толком, либо вообще не работают.


Это очень сильное утверждение, которому сложно верить на слово. Хотелось бы увидеть реальный код, реально работающую программу. И тогда все вопросы о крутости mol`a отпали бы сами собой.

В статье вы написали к одному приложению что на его создание было потрачено 2 часа. Почему бы вам не записать эти два часа с экрана и выложить это на Ютуб? Можно сколько угодно рефлексировать на тему фреймворков, но пока своими руками не попробуешь и не увидишь готовый результат — вряд ли что-то поймешь.
Создатель TailwindCSS вот стримит как пилит компоненты, и чтобы понять и принять его идеи для меня хватило пару роликов, хотя до этого очень склонялся к Tachyons — всё порешала доступная инфа и куча практических примеров. Хотя по-сути это фрейморки одного уровня.
И за фреймворк тоже спасибо! Хороших идей мало не бывает))

пс: Увидел сейчас пуллреквест в репозитории RealWorldApp который висит с 18 года. И не совсем понимаю в чем может быть проблема в его создании. На Юдеми есть курс по созданию RealWorldApp на Ангуляре и просто КУЧЕЙ бойлерплейта на NGRX — который длиться всего 14 часов. По вашим прикидкам на Моле его можно создать часов за 7 максимум) Я бы даже купил такой же курс на Юдеми, чтобы поддержать вас)
мне не хватило из всей информации, которую я прочитал, так это ссылку на код с большим проектом — как Real World App

https://github.com/hyoo-ru/realworld.hyoo.ru


Но он ещё не доделан. Лучше смотреть на те, что уже зарелизились: https://showcase.hyoo.ru/


Иногда очень удобно посмотреть 2 часовой туториал и сделать уже какие-то выводы.

До видео урока руки пока что всё не доходят.


И не совсем понимаю в чем может быть проблема в его создании.

Отсутствие практической ценности приводит к прокрастинации вот и всё.


Я бы даже купил такой же курс на Юдеми, чтобы поддержать вас)

Лучшая поддержка всё же — личное участие.

Лучше смотреть на те, что уже зарелизились: showcase.hyoo.ru

По рассказам и презентациям всё очень круто. Не хватает внятного объяснения как этим всем пользоваться. Внятная документация оставляет далеко позади всех ближайших конкурентов — стоит только посмотреть как взлетел Вью, и как сейчас взлетает Tailwind c NestJs — всех их изначально отличает отличная документация. А создатели NestJS так вообще свои курсы начали делать. Дэн Абрамов делал курс по Редаксу… Какой смысл от Феррари в гараже, если не знаешь как её завести?))

Отсутствие практической ценности приводит к прокрастинации вот и всё.

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

Лучшая поддержка всё же — личное участие.

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

Ну так, ходить, давать советы и ничего не делать я тоже замечательно умею.)


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


$mol — это не продут, который вы купили (пусть даже за "бесплатно") и шлёте претензии производителю. Это скорее экосистема, где люди могут легко шарить наработки, кастомизировать их под себя и помогать друг другу их развивать.

Процитирую вашу же статью:

Да даже просто написать разгромную статью, рассказывающую как в $mol всё плохо. Мы будем только рады хорошей критике. Да и моим рассказам о том, какой $mol классный, мало кто верит. Не ангажированный взгляд мог бы сформировать у аудитории более объективное мнение.


Полагаю имеет смысл убрать этот абзац, чтобы не вводить людей в заблуждение.
И еще по-поводу абстракций: судя по этой логике, чем больше абстракций, тем хуже фреймворк. Могу ли я предположить что Тайпскрипт хуже Яваскрипта потому что в нем больше абстракций? С++ хуже чем Си или голый Яваскрипт лучше вообще любого фреймворка?
По ссылке я вижу какой-то батхерт, напоминающий ролик 10 летней давности где рассказывается насколько Nodejs никчемная технология что ей не место на нашей планете. Насколько я понимаю, в Реакт или Вью сделано изначально всё идеально и нет таких проблем? Там всё работает сразу и как надо? Нет багов на трекерах и не нужно отлаживать компоненты по несколько дней? И вообще, такие комментарии только про Ангуляр пишут?

В Реакте свои болячки, во Вью свои. Из этих троих меньше всего косяков у Vue. Хотите ещё меньше батхёрта — смотрите на $mol.

Интересная ситуация получается, везде есть проблемы, но отстой всё таки Ангуляр))
А могу я поинтересоваться вашей методикой сравнения косяков у этих фреймворков? Как можно сравнить количество косяков и сделать выводы самостоятельно без того чтобы полагаться на чье-либо (возможно ошибочное) мнение?

Все отстой, а Ангуляр в особенности.
Методика вдумчивого архитектурного анализа через призму бизнес-потребностей и множественного прототипирования.
А вы хотите и на ёлку влезть и не поцарапаться?

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

Приходится либо самому копаться, либо доверять тому, кто покопался. Простого и надёжного способа сравнить по звёздочкам нет.


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

Можете привести пример где я опровергал ЛЮБУЮ критику? Если я уточняю, это не значит что опровергаю. Я знаком со всеми фреймворками, и прекрасно понимаю что проблемы есть во всех фреймворках, и опровергать наличие таковых, тем более в Ангуляре мне и в голову не придет.

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

Вот же. Никаких уточнений.


Вы слышали про дилемму Эскобара?

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

Всё относительно. В двух комментариях, на которые я дал ссылку, я выразил почему Ангуляр — полное дно. С тех пор, конечно, некоторые вещи поменялись, но не в корне. Про Реакт претензий меньше, но тоже полно.

Хорошо. Будем считать что Ангуляр вам не нравится, а по какой причине — написано в том комментарии, который даже не ваш))

Который даже мой, но значения это не имеет.


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

По ссылке которую вы дали, я не нашел комментариев с вашим именем.
Мне Ангуляр и правда нравится, но не настолько чтобы игнорировать какие-то существенные недостатки. Я даже эту дисскуссию начал чтобы выяснить что-же это за недостатки, только ничего кроме каких-то абстрактных размышлений не услышал. Тот эмоциональный комментарий на который вы ссылаетесь, имеет место быть, и я его внимательно прочитал, но одного его недостаточно чтобы сделать вывод что Ангуляр это отстой. Все остальные мои вопросы в этой теме были проигнорированы на тему сравнения фреймворков, все повторяют в основном одни и теже речевки. Даже для эффективности алгоритмов придумали О-нотацию и хоть как-то можно объективно оценить их. Но когда речь заходит о фреймворках, то всё сводится к вкусовщине, субъективщине и повторению каких-то мантр без объяснения.
Мое мнение по поводу всей тройки фреймворков очень похоже на ваше — они все в какой-то степени дно — либо сложны, либо имеют лишние абстракции, либо что-то в них не так. В том же самом комментарии, на который вы ссылаетесь, можно взять любую проблему и наверняка можно найти аналогичную либо во Вью либо в Реакте. Так почему же нужно принимать как непреложный факт что именно Ангуляр самый худший из них? Мне действительно интересно, если уж это не заставит меня перейти на что-то другое, то по-крайней мере буду знать к чему готовиться.
А те, кто использует и Ангуляр и Реакт, наоборот говорят что Ангуляр очень даже отличный фреймворк, и многим даже лучше Реакта.

Я не пользуюсь Ангуляром современным, но даже я могу сказать, что Ангуляр как фреймворк многим лучше Реакта, который не фреймворк, а библиотека для рендеринга DOM :) В Ангуляре по слухам роутинг есть, работа с API, DI и т. п.

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

Может это и есть главный недостаток Ангуляра: всё или ничего. :) не, наверняка, можно, например, заменить роутер на свой или сторонний, но это будет борьба с фреймворком.

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

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

Завидую вашей способности определять и видеть наперед то что будет лучше для проекта.

Это мелочи по сравнению с вашей способность видеть наперёд весь набор библиотек сразу. Я по одной лишь за раз выбираю )

хорошая ссылка спасибо

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

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

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

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

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

А эти 10 JS или CSS знают хуже.

Потому что, мил человек, можно знать реакт, а больше ни хрена не знать. Когда в руках молоток — всё вокруг кажется гвоздями.


Что касается аналогии с пилотами — у разработчиков цена ошибки и обучения существенно ниже. Действительно неплохой разработчик разберётся с реактом недели за две сам. А экономить две недели профессионала в пользу найма недоучки — это мне кажется порочной практикой.

А можете раскрыть, что, по-вашему, входит в понятие «разберется»?

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

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

Легко! На примере реакта, разберётся значит поймёт:


  • для чего это. В смысле какие проблемы оно решает, почему без него хуже (что не всегда);
  • как это работает. В смысле вот если бы реакта не было — как бы человек писал его сам. Скорее всего профессионал уже знает достаточно инженерных идиом, чтобы представлять себе в двух словах что внутри реакта;
  • как на этом принято писать. В смысле что откроет уже написанное на реакте в рамках проекта, почитает и увидит как надо писать чтобы коллеги не запутались, что документировать а что нет и т.п. Совсем хорошо если есть формальные code conventions.

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

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

Вот когда те, кто знает, на вакансию особо не рвутся — можно и поискать тех, кто «разберется».

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


Это по сути дискуссия о длине вертикальной палочки в букве T :)

Поэтому выбор между теми, кто детали знает, и теми, кто не знает, вполне очевиден.

Напомню цитату:


А экономить две недели профессионала в пользу найма недоучки — это мне кажется порочной практикой.
Да почему же сразу недоучки. Могут быть два человека с плюс-минус одинаковой базой и соображалкой, но если первый уже полгода работает на реакте — извините, за две недели второй его ну никак не догонит. И если они оба претендуют на одно место — какой смысл брать второго?

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

Ну так эту "плюс-минус одинаковую базу" надо ещё выяснить, прежде чем резюме отбрасывать. Напомню исходный критикуемый тезис:


Не понятно зачем работодателю брать на работу того кто не знает реакт, если у него десять резюме на столе тех кто знает и ему нужен тот кто знает реакт.
UFO just landed and posted this here

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

UFO just landed and posted this here
Да потому что нет других средств, чтобы проверить базу твою. Алгоритмам учат в вузах — вот и проверяют на знания. Даже если тебе никогда по работе не понадобится сортировать красно-черные деревья — если ты про них знаешь, то это гарантия (не 100%, но все же), что ты знаешь про битовые операции, основы теории вероятности и комбинаторики, тебя не нужно учить пользоваться списками и стэком, ты знаешь про массивы, словари, списки, их преимущества и недостатки, сможешь в нужный момент сделать выбор между использованием class и struct, при необходимости напишешь свою реализацию Sort(), и т.д. и т.п.
На фоне этого конкретный язык или фреймворк вообще теряют свое значение, потому что если ты представляешь, что такое SQL и реляционные БД, то ты наверняка сможешь сам разобраться в замечательной документации Microsoft и освоить Linq, например, или Entity framework.
UFO just landed and posted this here

Это видимо повезло или имеет место что компания faang. Если мы говорим просто про крупные компании — точно так же — React/Angulat/Symphony/etc. + git, jira + стрессоустойчивость (утрировано, но заголовки и описание вакансией в условной Германии ни чем не отличается от Московских контор).

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

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

Золотые слова. Начал проходить собеседования, спустя пять лет работы на одном месте. Думал что надо бы подучить какую-либо фигню, типа архитектурных паттернов, солид и прочих умных слов. Но было лень. Подумал, что для меня важнее пройти собеседование в компанию которая спросит про опыт, про то что делал, задаст приближенные к реальным задачам вопросы и решит что нам по пути — а не в ту, где на меня вывалят кучу шаблонных вопросов по теории. В результате меня погоняли и по теории — немного — и по практическим задачам, и по архитектуре — но именно в формате диалога. Я не боялся говорить что вот конкретно это не знаю или не помню, рассуждал над вариантами решения, и получил оффер, которым вполне доволен.
В целом согласен. Давно убежден, что современные собеседования в IT-компании идеально подходят для найма людей, которые очень хорошо научились проходить современные собеседования в IT-компании. Нанять людей, которые хорошо умеют разрабатывать такие собеседования, кажется, помогают чисто случайно.
думаю пока научились НЕ нанимать тех, кто не умеет разрабатывать.
Сомнительное утверждение. Как вы это поняли?
Надо с точки зрения фронтендера излить свою боль и пожаловаться, что у вот у бэкендеров можно с C# .net core перейти на Java Spring, а у нас нос воротят, если ты работал с React Native и не знаешь Styled Components, которые используются в веб версии React.

Внезапно — именно с этой статьей Фила я полностью согласен.

Sign up to leave a comment.