• Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Отличный ответ, благодарю! Хотел бы прояснить пару моментов:

    1. "Лучшая работа с перерендергином компонентов (обновлением частей страницы), когда может обновиться не вся страница, а только её часть. Это даёт лучшую скорость реакции на действия пользователя, что улучшает его впечатление от работы с сайтом. И это особенно критично, если идёт работа с какими-то частями со сложными вычислениями на странице."
    Чем хуже вариант с аяксом? Мы также обновляем часть страницы, можем её предварительно загрузить, чтобы не ждать полной загрузки по кнопке (если уже есть данные), можем получать их "на лету" и так далее.

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

    vekov
    @vekov Автор вопроса
    Иван Веков, как правило это способ экономить на ФОТ. Гораздо дешевле нанять психолога по корпоративному тарифу, заплатив 1 раз за много сотрудников с большой скидкой или купив печеньки оптом, чем добавить стоимость разового визита к этому же психологу или розничной стоимости печенек к зарплате, а сверху заплатить НДФЛ, ФОМС, ФСС, ПФР и т.д. Можно конечно этого всего совсем не платить, вот только выгоревший к чертям сотрудник имеет производительность на уровне нуля, а з/п ему нужно платить ту же.


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

    Есть фронтенды, которые знают только вью/реакт, а за их пределами толком ничего не могут - такие стоят дешего. Есть фронтендеры которые умеют голый TypeScript/JavaScript, а изучить react/vue/svelte/angular/ember/любую другую новомодную хрень для них дело 1-2 вечеров, такие стоят дорого.


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

    Вы не поверете, в городе от гелика гораздо больше пользы чем за городом. Если за городом бездорожье, то там лучше уаз или нива. А вот в городе, там где пузотерки встают во дворе напротив друг друга и спорят, кто должен сдавать назад и пропустить, гелик объезжает их по сугробу и не парится, много раз такое видел в СПб.


    Можно купить ту же Ниву, в городе, в таком случае) отлично проедет через сугроб. Также впрочем как и Nissan Patrol, TLC, Escalade, QX80, H5, H9, 500, LX и многие другие, в разы более комфортные автомобили, которые стоят в 2-5 раз дешевле) Так что в итоге и сэкономите и больше комфорта получите.
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Спасибо за ответ!

    Ну на самом деле "сайтец" - это образно. По факту это был корпоративный портал, с кучей всяких особенностей, типа согласования бизнес-процессов, динамическая карта офиса с поиском сотрудника и изменением рабочих мест, заявления на отпуска/выдачу расчётных листочков и тд. Ну и многие разделы, как те же бизнес-процессы - были динамические, то есть когда меняются данные на сервере - меняется и отображение на фронте. И там хватило 2-х обычных битриксоидов со средними знаниями в JS/Jquery, PHP и самом Битриксе.
    В дальнейшем он обрастал доп функционалом, и команда разработки увеличилась до 10 человек. И уже было разделение на фронт/бэк. Однако кажущимися "лишних" компонентов - node, npm, webpack, vue/react - так и не использовали. Просто бэкендеры писали модули и компоненты, а фронты - верстали css и писали JS/jQuery. Деплой происходил в таком стэке за считанные секунды. Что довольно затруднительно при использовании трендов (встречал компании, где сборка лишь фронтовых компонентов занимала 30 минут).
    Ну и как понимаете, найти замену разработчику, который знает немного js и немного php - вообще не сложно. А после разбиения на фронт/бэк (php / js + css) - так вообще плёвое дело. Правда за 6 лет развития проекта, ушел всего один разраб - и то уехал в другую страну.

    Еще более сложные продукты - тоже писали, обработки миллионов запросов, терабайтов данных и прочее, обернутое в кубер, сервисмеш, с брокерами очередей, графкуэлями и прочими потребствами. Кстати там использовали на фронте Vue3. И вот с этим были проблемы:
    1. Фронт делался непривычно долго, особенно на начальных стадиях.
    2. Разработчик ушел, и поняли, что без знаний во vue, не поправить даже мелочей. Хотя с обычным JS таких проблем не бывает - всегда всё очевидно любому человеку, который хоть раз видел код на любом ЯП.
    3. Разработчик ушел и найти нового было сложно, потому что кто-то на реакте, кто-то на ангуляре, кто-то на вью, но втором, кто-то еще на чем-то. А потом пришедший вьюшник, сказал что не нравится использованный подход, надо переделывать)
    4. Какие-то вещи обновились и сборка перестала собираться. Потратили много времени.

    Наверное соглашусь с тем, что сложные с точки зрения фронта очень быстро обновляемые вещи, можно писать на Vue, и развлекаться со всякими вебпаками. Но по факту, таких приложений, где это надо - 1 на миллион. Сложно придумать что-то кроме дашбордов криптобирж например. Там много всяких элементов - курсы, графики, кошелек, ставки и тд. которые должны оперативно обновляться. Тут думаю реактивность себя окупит, и то под вопросом.
    В прочих случаях - выглядит будто CSS + JS + наше всё.
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Я бы может согласился, но просил бы лям... Хотя скорее всего нет, нервы дороже бабла...

    Хм... а в чем нервы? Чистый жс, мне кажется более понятен, нежели путешествия по компонентам и либам какого-нибудь реакта.
    Ну и в итоге, как показывает практика, если увольняется разработчик за 50 тысяч, находится другой за 50 тысяч) В комментариях к ответу пользователя Karington описал ситуацию недавнюю.

    Ну и легаси на чистом жс, опять же, как я видел - проще к пониманию, нежели легаси на vue. Всё получается нагляднее.
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Спасибо за ответ. Но ведь:
    1. Для начала разработки, требуется скачать фреймворк, npm'ы, ноджс, все это подготовить.
    2. Для сборки - нужно запускать... сборку)
    3. Чтобы внести правку - нужно перезапускать сборку (ну банально npm install/run build и тд)

    Разве это получается быстрее?
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Сайт из 2014 года закрывал потребности бизнеса в 2014 году, и не закрывает их в 2024 году.


    Это верно, но мне кажется в большей степени из-за развития маркетологов и в целом понимания что такое "сайт" и что он умеет. Конечному пользователю то пофиг, Vue там или Jquery, главное чтобы работало.

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

    1. Бизнесы стараются быть в тренде. Если у тебя в компании есть психолог корпоративный, а у соседа - нет, значит ты лучше. Если у тебя есть печеньки в холле - ты лучше. И так далее. Не всегда это объективно, или про реальные потребности, это больше про имидж.
    2. Рынок и тренды диктуют свои правила бизнесу порой. Все фронтенды сейчас изучают вью/реакт, других почти нет. А если находятся - то стоят дешевле и бизнес думает: "хм... значит этот плохой, раз дешевый, еще и каких-то вью не знает, что бы это ни было". И берет более дорогого. Это знаете, как гелик. В городе от него нет смысла, он жесткий, неудобный, много жрет. Но он модный - поэтому в центрах крупных городов - их навалом, но объективно, в 5 раз дешевле можно взять авто лучше по всем параметрам, важным для города - отделка, комфорт, музыка, приблуды.

    Вам правильно сказали, что вам никто не мешает сейчас за три дня сделать сайт на технологиях 2014 года, но сможете ли вы конкурировать с сайтом на технологиях 2024 года?

    Вот пока что не видел проблем в этом, если честно. У меня сейчас есть несколько проектов, несколько в куберах, с вьюхами и кучей всего. И сейчас мы запускаем новый проект, для него сайт разрабатываем по-старинке, вот прямо всё самое простое, делают простые разработчики (где-то откопали толковых, при этом не ушедших в тренды), и знаете, пока на старте сложно оценить, но расходы по сравнению с другими проектами - мизерные, а посещаемость и профит - по приросту - не меньше. Разработчиков, что удивило, нашли крайне быстро (вопрос занял меньше недели) и за реально 1/3 оплаты от того, что платим на других проектах.
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Проблемы с индексацией есть и сейчас, чтобы там не заявляли ПС, а в древние 2016 года они были выражены в несколько раз сильнее. То, что Вы проблемы не замечали - не значит, что их не было.


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

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

    P.S. в некоторых ситуациях действительно быстрее и дешевле написать некоторые функции на чистом js и не тащить весь react стек в проект, но это больше исключение, чем правило.

    Вот эта мысль уже больше мне нравится, но, складывается ощущение, что скорее - наоборот. Возможно, есть случаи, когда применение Vue/React/Angular - обоснованно, но пока не понятны эти критерии...
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Ну, тенденции, как минимум) Если сейчас "все пишут так", то и ресурсы на рынке уже на это ориентированы)
    Написано
  • Есть ли реальный профит от использования актуальных фронтенд-технологий?

    vekov
    @vekov Автор вопроса
    Андрей Колесов, спасибо за развернутый ответ) а то в основном тут банальные обиды.

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

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

    Смотрите, я активно использую контейнеризацию, оркестраторы, пакетные менеджеры, балансировщики, различные виды автотестирований, мониторингов и многое другое из современных технологий. Потому что это быстро, удобно, повышает масштабируемость.
    Ну то есть, тот же контейнер - это божество, когда делаешь сложносочиненное приложение, с кучей сервисов. Без него у тебя расходы были бы выше, и надежность ниже. Смотрим дальше, над контейнерами нужен оркестратор, иначе с ума сойдешь и все сломается. Значит снова - расходы снижаются, надежность повышается. Без того же helm'a было бы всё дольше и менее удобно.
    А вот конкретно по фронтовым (в основном) модным темам - у меня большие вопросы. Так как ни я в практике, ни кто либо из комментирующих - не наблюдал реального профита.
    Так как в основном все комментарии - это, как я уже сказал, вопли "обиженных", типа "вот и работай без них!". Я задал конкретный вопрос, замечал ли кто конкретный профит для бизнеса, судя по всему - его нет. Это грустно.
    Написано
  • Как реализовать сквозную авторизацию?

    vekov
    @vekov Автор вопроса
    Да, нужно без ввода пароля.
    Мне кстати показалось, что keycloak для этого не подходит...
    Написано
  • Как реализовать сквозную авторизацию?

    vekov
    @vekov Автор вопроса
    Вроде бы столкнулись с тем, что с новыми версиями ПО может не работать корректно старая библиотека. (Ну например используем РНР 8.2, а либа под 5.4). Ну и ощущается будто софт который не обновлялся десятилетиями - обязан быть дырявым :)
    Написано
  • Поиск по LDAP, как найти пользователей в группе?

    vekov
    @vekov Автор вопроса
    Роман Безруков, Ага, возвращается.
    В системных логах ничего интересного не замечали, просто ходят запросы, ошибок или чего-то еще не найдено
    Написано
  • Поиск по LDAP, как найти пользователей в группе?

    vekov
    @vekov Автор вопроса
    Роман Безруков, подумал было, что это то, что нас спасет, попробовали фильтр:

    (memberOf:1.2.840.113556.1.4.1941:=CN=CplLdapTest,OU=Domain_users,DС=abt,DС=orl)

    Вернуло пустоту...
    Написано
  • Поиск по LDAP, как найти пользователей в группе?

    vekov
    @vekov Автор вопроса
    Да, поиск по атрибутам - работает.
    Ищем через порты 389 или 636.
    Когда используем memberOf - всегда получаем пустой результат выборки. Хотя в AD видим что пользователи в группе есть. Ну то есть такой фильтр:
    (memberOf=CN=MyTest,OU=Domain_users,DС=abt,DС=orl)
    Не отрабатывает корректно.

    По ссылке что вы скинули - такие же фильтры как у нас и используются, и по sAMAccountName нашел и по memberOf. И написаны также как у нас, но у нас не работает почему то...

    Еще вот не понял, может вы знаете. В примерах указан вариант:
    (memberOf:1.2.840.113556.1.4.1941:=CN=BackOffice,CN=Users,DC=test,DC=local)
    Что это за цифры, где они берутся и для чего?)
    Написано
  • Почему комп не опознаёт сеть по кабелю?

    vekov
    @vekov Автор вопроса
    Тоже пробовал, к сожалению не помогло. Буду пересобирать розетку. Отдельная сетевая карта не помогла также
    Написано
  • Почему комп не опознаёт сеть по кабелю?

    vekov
    @vekov Автор вопроса
    Не, пункт 11 отметает эти варианты)
    Написано
  • Почему комп не опознаёт сеть по кабелю?

    vekov
    @vekov Автор вопроса
    А, роутер перезагружал, забыл перечислить) смена порта... А для чего, если ноутбук подключенный через этот же порт через тот же кабель - в норме?
    Написано
  • Как убрать дубли getList D7?

    vekov
    @vekov Автор вопроса
    Александр Маджугин, а это и так инфоблоки 2.0, место хранения - отдельная таблица.
  • Как мониторить ответы сервера для Bitrix через Prometheus?

    vekov
    @vekov Автор вопроса
    Странно что ранее не видел вариант с лог-экспортером. А втс как раз ставил, потратив двое суток справился. Поставлю тогда ещё лог экспортер для сравнения выдаваемой информации