Как стать автором
Обновить

Комментарии 333

Спасибо. Интересный взгляд. Можно ссылку на оригинал?
В переводах ссылка на оригинал под названием поста.
image
спасибо. на мобилке этой фичи нет
Странно… Проверил на мобилке (Android), через Chrome — ссылка есть.

Просто во вкладке или в режиме PSA?

НЛО прилетело и опубликовало эту надпись здесь
я смотрел эту статью в приложении. Проверил сайт, да там есть ссылка. Буду знать.

image
в приложении на андроиде нет
Это перевод, под названием статьи есть ссылка на оригинал.
Я смотрел в приложении. Там нет.
В начале статьи же кликабельная надпись про оригинал
Я смотрел в приложении. Там нет.
Да, баг, наверно. В мобильном браузере, кстати, все нормально)

Не баг, а не реализовано. На приложение вообще официально забили.

FYI приложение давно не поддерживается qna.habr.com/q/731363

Вот я не совсем соглашусь с Вами, а соглашусь с автором… у меня не большая команда… и технологию я оцениваю так… если через более пол-года возвращаемя к коду расшририть функциональность… поправить баг… то для примера java(erp система)… разработан "целый космос " и всегда к коду возвращаться легко… легко дополнить и нет побочных эффектов.возможно из-за принципа концепции ленивой подгрузки кода… А вот в реакте небольшие проектики.(не то что у автора статьи) и вернуться к коду через время(React+Redux) или что-то дополнить… Это боль… я сменил стек .

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

И что сейчас? Ангуляр?

Вы знаете я как предприниматель в ИТ… рассуждаю просто(Мой взглаяд может не подходить для крупного бизнеса)… с точки зрения уменшения ресурса(технического, административного, по сопровождению)… Мои проекты связаны с базами данных(автоматизацией бизнеса)… для малого и среднего.
И в зависимости от ситуации или 1.Oracle Apex(Это быстрая среда для разработки бизнес приложений… мне кажеться быстрее нельзя можно только повтороить).
2.Или(если проект будет иметь много отраслевых подрешений) PHP+HTML контролы на jQuery

2 Со временем всё сложнее будет находить специалистов, готовых с этим работать. Особенно вдолгую.

Oracle Apex(Это быстрая среда для разработки бизнес приложений… мне кажеться быстрее нельзя можно только повтороить)

Быстрая среда для разработки бизнес-приложений — 1С: Предприятие. Не думаю, что в Oracle Apex можно быстрее что-то сделать.

Приведите, пожалуйста, пару примеров. Почему возвращаться к java коду легко и какие проблемы при доработках в стеке React+Redux?

Именно почему я не знаю...(тут же была ремарка для меня)… это по моему опыту… есть проекты на react(Это POS кассы на планшете… магазин ресторан), ЕГАИС Проверка марок(тоже чтоб мобилу использовать… тут React к месту) На java вообще большая кросспоатформенная Desctop ИС.с дублирующими web мордами для некторых отраслевых процессов(vaadin Это java). и oracle apex.Так вот если вдруг(для меня) нужно вернуть и доработать react… Это всегда выход из зоны комфорта… Пока пишешь(React)… держишь в уме "нить" вроде нормально. Решение выпущено работает… вернуться к нему… всегда жалеешь ,-на кой я выбрал React в этом решении… Возможно какая-то эфимерная нечёткая концепция у React… что потом "концы" сложно собрать в кучу".(Сугубо по моему мнению)

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

Кажется что в момент прихода новой команды можно было бы озвучить что вот мол «они новички в React, за мной право на design review».

У меня только один вопрос — почему технические решения принимает человек, знающий лишь полтора фреймворка?

А сколько он их должен знать, по-вашему? Что еще было в экосистеме JS, кроме React и Angular, что стоило рассмотреть для подобного размера приложения? Даже Vue в 2018 году был не настолько популярен.

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

Никто не говорит, что он не знал больше ни о чем, говорится, что Angular и React в бою были автором проверены. Боюсь, что при «альтернативном» выборе статья могла бы называться в стиле «Как меня чуть не уволили за выбор Svelte для корпоративного приложения» :)

Не пробовал в бою = не знал.
За выбор любого высокоуровневого фреймворка ($mol, ExtJS, SAPUI5, да хоть 1С) его бы только похвалили.

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

Типов фреймворков от силы десяток наберётся. Достаточно ознакомиться с представителем от каждого.


Если у самого не хватает опыта для принятия такого решения — всегда можно нанять того, у кого этот опыт есть для консультации. А не обрекать "большой и долгий проект" на кучу легаси и рефакторинги в первые же пару лет.


Самомнения у таких вот "любителей реакта" много, а совести — нет.

Люди с опытом обычно понимают, что проблема не в фреймворках.

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

Если смотреть на долговременную перспективу лет так в 10, то любая активно развивающаяся апликуха имеет тенденцию года через 3-4 начинать превращаться в тыкву по множеству причин. И архитектура среди них даже не в top 3.

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

Расскажите про тыкву ребятам из .NET или Java Enterprise которые поддерживают проекты часто больше 7 лет.

У самого 3 таких проекта на поддержке. И это тыква. За такое время от первоначальной архитектуры и светлых задумок мало что остаётся, всё зарастает мхом.

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

Вот реакт как раз ничего особо не форсирует

Ну конечно..


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

И это список можно ещё долго продолжать.

Просто перестаньте относиться к реакту как к тому, чем он не является — полноценному фреймворку.


Ок. Реакт навязывает единственную вещь: вью — чистая функция от переданных свойств и, опционально, стэйта и рендерится автоматически при их изменении в терминах JS. Если собираетесь с этим бороться, то это будет больно.

Обязательно, как только перестанут врать про "у нас проект на Реакте", скрывая от руководства, что на самом деле "проект на кривом велосипеде, слепленном из Реакта и ещё 10 библиотек и скрученных синей изолентой". Я много проектов повидал "на Реакте" — везде одни и те же проблемы. И они очевидны были с самого начала.


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

необходимость ручного прокидывания: классов для стилизации

Но зачем? Стилизация компонентов — ответственность самих компонентов, а возможная вариативность — это часть явного интерфейса компонента, которой в пропсах самое место. Да и то, не факт, что там нужны именно CSS-классы, а не флаги или другие высокоуровневые параметры.

В разных контекстах необходимо менять разные особенности визуализации компонента. Попытка выразить всё многообразие кастомизаций в пропсах выливается в свой недо css. За примерами можете посмотреть любой более-менее матёрый компонент. Фронтенд ходит по кругу, наступая на одни и те же грабли с каждым витком.

В разных контекстах необходимо менять разные особенности визуализации компонента.

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

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

За примерами можете посмотреть любой более-менее матёрый компонент.

Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию, хотя и поддерживают передачу css-классов в некоторых местах.
Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.

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


Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию

Эти настройки обычно покрывают лишь 60% потребностей проекта. Что делать с остальными 40%? Писать фичереквест и ждать с моря погоды? Форкать, вставлять костыли и поддерживать их при каждом обновлении? Форкать, неделю разбираться как адекватно сделать нужную тебе фичу, после чего ещё месяц бодаться с мейнтейнером, чтобы он принял мерж реквест?

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

Предлагается изменить внутреннее поведение компонента. Если так, то логичнее было бы его в самом деле форкнуть и наделить необходимым функционалом, а не патчить результат извне. Не факт, что будет дороже, но 100% — надежнее.

Форкать, вставлять костыли и поддерживать их при каждом обновлении?

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

Примечательно, что на поставленные вопросы вы так и не ответили.


А что если...


image


… можно построить архитектуру так, чтобы:


  1. Минимизировалась вероятность поломки при обновлении.
  2. При поломке падала бы сборка, а не появлялись скрытые баги.
  3. Изменения хранились бы в репозитории потребителя компонента, а не требовались форки.
  4. Достаточно было бы пары простых строчек кода, а не головоломные портянки.
на поставленные вопросы вы так и не ответили.

На все поставленные вами вопросы вроде бы ответил прямо или косвенно. Давайте еще раз:

Сколько итераций потратите на реализацию этой дизайнерской задумки?

Тут вы число ждали? Вслепую оценивать объем работ как-то странно.

Что делать с остальными 40%?

Искать более подходящий компонент или форкать имеющийся.

можно построить архитектуру так, чтобы:

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

Ну вот в $mol экосистеме есть все 4. В BEM — все, кроме вроде как 2.

Ну вот в $mol экосистеме есть все 4.

Это утверждение нуждается в доказательстве.

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


И да, опять вы комментарии спрятали.

Вы либо никогда не делали фронтенд, либо троллите. Время миллиона фреймворков прошло в 2016. Сегодня — Ангуляр для bloody enterprise, Vue для fast kick-off, но заплатите позже качеством, React — собери сам, и будет зависеть от того кто собирал. Все остальное (Свелты и прочие) — игрушки для гуру программирования, а не приложений на 120 страниц.
Я буквально сидел и ждал, как скоро вы упомяните $mol, это же единственная причина вашего появления тут, правда?
Не то чтобы это было плохо в рамках одной ветки комментариев, но к сожалению эта назойливая самореклама стала регулярной.

Я там ещё троих упомянул, если вы не заметили. Любой из них подошёл бы для задач автора лучше Реакта. И даже лучше Ангуляра.

Для корпоративного приложения, для которого даже Реакт — слишком быстро развивающаяся и меняющаяся штука?

Реакт так-то довольно медленно именно развивается, не смотря на частые изменения в апи и, особенно, экосистеме. Тот же $mol за то же время куда более существенно развился (появилось и исчезло квантование, появилась виртуализация, полностью переработана система реактивности, дважды), при этом для прикладного разработчика мало что поменялось. Реакт же тем временем всё никак не допилит фичи, которые были в $mol изначально (Suspense, Dependency Tracking, Context).

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

Я уже года 3 как не пиарю $mol, а делюсь идеями, наработками и результатами анализа. Тем не менее:


Но вы постоянно это делаете настолько агрессивно, с позиции "вы все дурачки и не лечитесь", что никакого желания даже смотреть в ту сторону не хочется.

Это довольно дурацкий ход мысли, показывающий иррациональность вашей позиции.

Ну было бы странно если бы вы со мной сразу согласились :)

ExtJS для такого вполне зашёл бы, разве нет?

ExtJS для такого вполне зашёл бы, разве нет?

Верно. ExtJS — это свыше 500 классов. Что-то вроди Дельфи для фронтенда.
И ExtJS — платный. Но это как-раз для энтерпрайз проекта.

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

Единственно ExtJS пользуется менее — 0,5% разработчиков — но свыше 500 классов! — Что вам ещё нужно то? Особенно если вы что-то делаете для внутреннего(!) продукта употребления в банке, к примеру!

Ну я вот один из тех 0.5%, скрывать не буду.


Вы кроме числа классов и платности про него что-то ещё знаете? Например, про огромное количество настроек и надстроек? Или про то, что его формат функциональных таблиц толком никто не повторил с тех пор, и именно из-за таких таблиц проект вообще до сих пор шевелится? Или хотя бы про то, что все 500 или сколько их там классов образуют единую систему, а не дикую портянку из слабосвязанных и зачастую несовместимых между собой лефтпадов, которые нынче в моде?
Уж поверьте, я работал с ExtJS от старых версий и до довольно новых, а сейчас соседняя команда с таким скрипом пытается на реакт+mobx повторить всё что в прежнем UI подключалось парой строчек — что от их стараний полсистемы шатает. И время билда только за счёт jsx у нас почти на 40% подскочило, и это ещё ни один наш модуль не стал полноценно переходить на молодёжные фреймворки, которыми пользуется больше 0,5% разработчиков.

соседняя команда с таким скрипом пытается на реакт+mobx повторить всё что в прежнем UI подключалось парой строчек

О да, это вершина программирования. «Программировать» галочками и 2мя строчками копи пасты из примеров с сайта.
Кто же в здравом уме будет сам реализовывать алгоритмы и тем более вообще писать код, это удел дурачков и неудачников.
Вот они там и мучаются на своими реактами и т.п. ха-ха.
А вы делите пьедестал почета с 1Сниками и гордитесь этим =)

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

Вы кроме числа классов и платности про него что-то ещё знаете?
Да, работал с ним до той поры пока он был бесплатным. До 5- версии.

Например, про огромное количество настроек и надстроек?
Огромное. Согласен. Да и классов поди уже свыше 700 там. Если брать по 10 методов — то под 7000 методов то будет то, поди.

Или про то, что его формат функциональных таблиц толком никто не повторил с тех пор, и именно из-за таких таблиц проект вообще до сих пор шевелится?
Да, если кому надо таблицы из Excel в веб закинуть, то возможно, не бесплатно, можно попробовать ExtJS — но сам я не использовал таблицы то. Не из банка я.

Или хотя бы про то, что все 500 или сколько их там классов образуют единую систему, а не дикую портянку из слабосвязанных и зачастую несовместимых между собой лефтпадов, которые нынче в моде?
Верно. Никакой моды. Всё кондово сделано. Как в Дельфи!

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

Но для банков это неважно — да и в банках дельфинариков хватает, чтобы освоить ExtJS то. Он им будет привычен. Кондовый ООП — это что-то!

И я не шучу!

(Разработчики ExtJS конечно наклепали и React библиотеку СВОИХ компонентов, то это мода, не более чем. На это можно, наверное не обращать внимание. — Кондовый дельфиподобный ООП — ExtJS — что ещё нужно банковскому программисту?)

И я не шучу!

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

но сам я не использовал таблицы то.

Но хаять их (выходит, безосновательно) это вам не мешает.


Так всё-таки, какие конкретно претензии к фреймворку? Меня количество классов и методов вообще не интересует (тем более что с количеством методов внутри вы ошиблись примерно на порядок), и у меня нет отвращения к Дельфи, ООП и тем, кто с этими технологиями работает.

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


А ещё ни в коем случае не реюзать код. Всегда проще закопипастить, ведь он может чем-то отличаться! Так и изменения вносить проще!


Ну и, конечно, "классы"! Это ведь мерзкое слово, почти как "сексист"! Даже если логично использовать класс — ты должен вывернуться и сделать то же самое, но без использования слова "класс".

Но хаять их (выходит, безосновательно) это вам не мешает.

ААААААААААААААААААААААААААААААААА!!!
Где я хаил таблицы? Какими словами или знаками препинания?
Я не работал с таблицами в ExtJS — ну НЕ пересекался никак.
Надо вам ООП как у Дельфи или таблицы — и заказчик в состоянии платить лицензию — используйте ExtJS.
Проблемы?

Меня количество классов и методов вообще не интересует (тем более что с количеством методов внутри вы ошиблись примерно на порядок)
Ну а что ещё можно сказать о ExtJS? Уже всё сказано.
Ошибся я в какую сторону? 10 методов на класс — это много — там 100? Или мало — там по 1 методу на класс то?
А кроме методов у классов есть ещё и СВОЙСТВА — по 10 на класс.
Итого — 10 000 методов и свойств на 500 классов, примерно.
У вас другие цифры? — так озвучьте.

и у меня нет отвращения к Дельфи, ООП и тем, кто с этими технологиями работает.
А я как-то обозначил отвращение к Дельфи и ООП?
Да у меня нет никакого отвращения и к Коболу!

Я написал что дельфинарики (программисты на Дельфи) вполне смогут ЛЕГКО начать писать код на ExtJS — там такой же кондовый (то есть ОСНОВАТЕЛЬНЫЙ) ООП что изучали в универах с середины 90-х годов прошлого века.

И я думаю, что дельфинарики ещё есть в банках то! Куда они смогли уйти то? На Java?

Я уверен что и функциональщина и даже Redux можно использовать в ExtJS (я подписан на рассылку ExtJS и там время от времени появляются упоминания что что-то такое делается и в ExtJS).

Так что НЕ надо на меня нападать за ExtJS. Я уже всё написал что знал про него.
Ну не пользуется ExtJS никакой популярносттью сейчас как и Дельфи — но если это кого-то не пугает, и не пугает плата за лицензию — то почему бы и нет?

Но, похоже, если я сейчас напишу что «два плюс два равно четыре», вы напишите мне в ответ (поставив минус посту) что типа Я ОБИДЕЛ ЦИФРУ ПЯТЬ!

Не надо так.
У вас другие цифры? — так озвучьте.

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


А я как-то обозначил отвращение к Дельфи и ООП?

Да, прямо в следующем абзаце сообщения.


Я уже всё написал что знал про него.

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

Надо вам ООП как у Дельфи или таблицы — и заказчик в состоянии платить лицензию — используйте ExtJS.

  1. Есть и бесплатные альтернативы ExtJS
  2. Если заказчик в состоянии платить за проф программистов, которые месяцам велосипедят то же самое на Реакте, то на лицензию у него есть деньги и подавно.

2) У некоторых заказчиков разное отношение к тратам на создание своей интеллектуальной собственности и на лицензирование чужой.

Речь шла про состояние платить, а не про желание.

Некоторые заказчики в состоянии вкладываться в ФОТ, но не в лицензии. 10-долларовые лицензии приходится месяцами выбивать для разработчиков с зарплатами в тысячи долларов, хоть на свои покупай команде

Есть и бесплатные альтернативы ExtJS…
на лицензию у него есть деньги и подавно.

Тут налицо противоречие — если есть бесплатные альтернативы то зачем платить?

Думаю «мощнее» по кондовости ООП и количеству классов нет альтернативы ExtJS.

Похоже главная причина почему ExtJS никто не рекомендует — это исчезающе малое число программистов желающих использовать ExtJS (и возможно и его кондовое ООП) на фронтэнде.

ExtJS спасают от забвения, похоже, банки, «подсевшие» на него до введения платной лицензии.
ExtJS спасают от забвения, похоже, банки, «подсевшие» на него до введения платной лицензии.

Для маленького примерчика, все веб-морды всех продуктов Synology написаны на ExtJS. Не стоит юродствовать.

Для маленького примерчика, все веб-морды всех продуктов Synology написаны на ExtJS.
ExtJS для интранета с кондовым ООП вполне окей.
Интранет — это и Synology и внутрибанковский продукт и прочее.

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

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

Architecture Decision Record (ADR).
Используется мозг и память :)
Пришли злые .net-разработчики и сломали React, плак-плак. А всего лишь начали задавать вопросы.
Сначала мы жалуемся что «Почему эти функции просто болтаются в коде, и почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?», а потом плачем о том что саги разбухли и непонятно что с ними делать. А понимание того что нужны сервисы — автоматически ведет к пониманию того что DI нужен если не в компонентах, то в самих сервисах и сагах — точно. Плач о именованиях файлов вообще клоунада, но напомню, что при одинаковом названии класса и файла — искать фултекст серчем — гораздо удобнее.
С одной стороны .net разработчики во многом правы (жить с DI, retry лучше чем без них), с другой стороны они продавливали своё мнение без учета специфики реакта.

Например требование class based components на самом деле продиктовано желанием использовать inversifyjs в режиме аннотаций, когда function based components потребовали бы явно обертывать функцию перед экспортом или использовать реактовский аналог service locator-a (context).

Требование retry policy через PollyJS так же не совсем обычно для экосистемы реакта (есть другие инструменты).

И это без учета претензий по скорости разработки/билда и качеству собственноручно созданной архитектуры, которые совсем странные.

Эта история скорее о том, как люди не хотели договариваться и каждый тянул одеяло на себя… итог в виде рваного одеяла не заставил себя ждать.
.net-разработчики просто должны в Angular приходить и не страдать

1) Переносим имеющееся приложение с WPF, разработчики все тоже с опытом WPF
2) Берём максимально отличающуюся от MVVM технологию управления стейтом
3) ???????
4) Почему меня чуть не уволили?!


А ведь достаточно было не натягивать свою любимую сову на очередной глобус. WPF-разработчики прекрасно переезжают на связку React + MobX + Typescript, поскольку идеология организации кода и состояния практически 1 в 1 совпадают. Но Redux-сектанты будут упорно продавливать своё мнение, да.

А почему бы не asp.net или ещё какой фреймворк именно на .net (C#), раз уж подавляющее большинство программистов уже используют эту технологию?

Из фреймворков именно на C# сейчас для браузерной части SPA-приложений условно-пригодным является только Blazor, всё остальное использовать в продакшене нельзя в принципе никак и будет нельзя ещё года два минимум. Если вам кто-то про свою чудо-библиотеку говорит обратное, плюньте ему в глаз.


Production-ready технологии же относятся к серверсайд-рендерингу и для ряда приложений просто неприменимы.


Так что по состоянию на 2021 год C# в вебе может использоваться только на сервере.


Есть ряд решений на F# типа Fable, но это опять же слишком отличается по парадигме от WPF+MVVM.

Согласен на все 100. С другой стороны, уникальный доступ к состоянию (read-write в любом месте) этот кошмар в долгосрочной перспективе :)
enforceActions не даст мутировать из любого места. В MobX 6 по умолчанию включен.
Если еще добавить модификаторы доступа TypeScript (private, protected), то вообще проблем не будет.

Совершенно с вами согласен. В моем случае мы выбирали для Vue использовать класс компоненты или новый composition API похожий на хуки React. Конечно на Typescript. Хорошо что у нас есть немного разделение на фронт и бек. Но все по умолчанию фулстеки. В итоге на фронте пошли по пути функционального кодинга. А бек у нас на PHP Laravel и там ООП, паттерны, классы… Так вот даже учитывая, что PHP не такой строгий ООП язык как C#, Java — все равно бек разработчикам крайне сложно понять и принять фунциональщину. И не все уже смогли работать фулстек. Поэтому да, если разделения нет, надо настраивать фронт под бек, никаких функций, только классы.

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

это реализация идей ФП в окружениях, построенных по принципам ООП

Скорее реализация в ООП идей, реализация которых в ФП не требуют каких-то специальных телодвижений. Если не говорить про стейтфулл паттерны )

Стратегия — это инверсия контроля путём согласованной подмены группы функций. На функциях (без объектов) это разве что через свичкейс реализуется.

Во-первых, группа функций, контролируемая Стратегией, может состоять из единственной функции, что позволяет делать Стратегию тождественной просто ссылке на функцию. Таким образом это может работать и без объектов, например в C.
Во-вторых, паттерн сам по себе не говорит, каким именно образом происходит выбор конкретной стратегии, это уже задача фабрики стратегий. А уже в фабрике можно и свитч, и словари, и много чего ещё.

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


Свичкейс нужен не для выбора стратегии, а для переключения между аспектами одной стратегии: https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers#handling-additional-actions

Видимо, у нас тут фундаментальное расхождение в терминах.
Вот моё определение — https://en.wikipedia.org/wiki/Strategy_pattern — здесь нигде не говорится про какие-то аспекты одной и той же стратегии. Более того, во всех блок-схемах и примерах стратегия с точки зрения use site состоит из единственной функции.
Где ваше определение? Эта ваша статья не содержит ни единого упоминания паттерна. Все сниппеты со свитчами — это вообще код фабрики. И даже если бы статья содержала слово "стратегия" — единственного примера из единственной библиотеки малость маловато для заключения, что паттерн всегда должен был именно как в этой библиотеке.

Я погуглил и… всё очень печально. Люди видят всего-лишь пример с одним методом и думают, что метод может быть только один. Ну, простейший пример — стратегия маршалинга, ей нужно как минимум 2 метода.

Это, кстати, и правда очень печально. Когда люди смотрят на паттерны — они не способны увидеть что-то большее, чем написано. Они не понимают, что это только приёмы, которые показаны на самых простых, вырожденных примерах и с них можно сделать что-то значительно более мощное.

НЛО прилетело и опубликовало эту надпись здесь

А что ещё ожидать, если люди вынуждены учить паттерны, как я английский учил: The Present Perfect Continuous Tense выражает действие, начавшееся ранее и продолжающееся в момент речи или завершающееся к моменту речи. Образуется с помощью вспомогательного глагола to be в форме Present Perfect (have been, has been) и Participle I смыслового глагола — ночью разбуди тогда и ответил бы без запинки.

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

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

паттерна можно упростить до единственной ссылки на функцию

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

А в чём упрощение?

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

НЛО прилетело и опубликовало эту надпись здесь
И тут я осознал, что React не дружественен ни к Java, ни к .NET разработчикам. Angular в этом случае был бы лучшим выбором из-за схожих шаблонов проектирования.


Это как? Депенденси инжекшен он и в африке… И если они бэкендистов заставили писать фронт, а не фуллстек/фронтенд разработчиков, то ожидаемо что они будут писать говнокод без энтузиазма. Хоть на ангуляре хоть на реакте.

И зря тут недооценивают разработчиков нет и жава. Сколько проектов видел написанных всякими жаваскрипт адептами которые раньше джеквери херачили. Зачем паттерны… это все овер, давайте без них. И быстро и кода меньше. А потом ни тестировать без магии жеста (Jest) ни поддерживать это гомно нельзя. Поэтому паттерны тут испортить ничего не могли, если естественно их применяли когда надо, а не паттерны ради паттернов.

Я никогда не видел двух проектов React с одинаковыми зависимостями, структурой проекта и руководящими принципами.


Ну если структуру делать feature based то она и на ангуляре разная будет.

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

Вообще тут намешаны разные вещи не связанные с реактом от слова совсем. Билд берет время? Ну это проблема всей экосистемы ноды.

Могу согласиться только с тем что новые хуки и контекст добавляют магию и конвенции, и действительно не все их любят, включая меня. Ну и борьба с самим собой потому что на тебе лежит ответственность выбора библиотек, а не как в ангуляре — что дали тебе в фреймворке то и юзай. Хотя и там сторонних библиотек хватает. Redux это отдельная пестня…
Поправлю себя. Тут даже не бэкенд разработчики, а WPF. То есть возможно они всю жизнь пилили стэнд элон приложения с коннектом к базе, и тут им — держите реакт, походу разберетесь. Это риски которые менеджмент должен был учесть и оценить.
Это как? Депенденси инжекшен он и в африке… И если они бэкендистов заставили писать фронт, а не фуллстек/фронтенд разработчиков, то ожидаемо что они будут писать говнокод без энтузиазма.

Заставили людей с опытом десктопного фронта на MVVM писать как завещали адепты Redux. Виноватыми оказались React и разработчики.

Обычно beckend разработка предполагает больше знаний, умений и ответственности. Поэтому не совсем понятно в чём должна быть сложность изучить и писать frontend, если стоит такая задача.

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

Как fullstack developer не могу с вами согласиться. Подавляющее большинство backend developer-ов занимаются более чем простыми вещами. Лишь немногие занимаются чем-то действительно интересным. Как например high-load-ом, сложными балансировками, большие смежными задачами.


Подавляющее большинство backend-разработчиков:


  • знают SQL только на базовом уровне (знают про индексы, умеют писать миграции, умеют в join-ы и groupby)
  • чаще всего используют ORM, чаще всего Active Record
  • имеют отдалённое представление о системных вещах (вроде тонкостей работы сетевого стека, маршрутизации, работы с диском и т.д.)
  • не пишут никаких сложных алгоритмов. По сути практически вся задача сводится к "взять из СУДБ записи по простому запросу, преобразовать их в другую структуру данных, отправить в виде JSON на клиент" и "взять из базы данны по 10-и запросам и собрать через либу в xls отчёт"
  • пишут в рамках одной и той же парадигмы годами без изменений
  • немного умеют в docker, k8s и смежные технологии

Разумеется из всего бывают исключения. И как только речь идёт о больших нагрузках и начинаются всякие шардирования — вот тут становится уже интересно и весьма непросто всё. Но таких контор минимум. Я думаю на 9 разработчиков уровня "гонять туда-сюда json" приходится 1 разработчик уровня серьёзного backend-а.


И я не могу винить в этом разработчиков. Просто рынку и в самом деле сейчас не нужен сильный backend в таком количестве. А в простом виде он ужасно скучен. И совсем несложен. Я почти отошёл от backend задач, во многом из-за того что он ужасно скучный. В то время как во frontend есть потребность в очень сложных приложениях. Challenge every day. Мы уже давно перешли в "эпоху" толстых клиентов.

У меня абсолютно противоположное мнение.
В большинстве случаев из опытов на front могут взять студентов или же людей без профильного — риски запороть из-за этого проект минимальны.
И картина абсолютно противоположная с backend, риски намного больше и ответственность тоже и бекенд должнен быть достаточно абстрагирован от фронденда в большинстве случаев. То что вы сталкивались с разработчиками с базовым уровнем SQL, docker, паттернов не значит что это норма и стандарт в индустрии.
По крайней мере для серьезных проектов или энтерпрайз нужны хорошие знания языка, ООП, паттерны, многопоточность, конкурентный доступ к данным, синхронизация и тд.
У меня абсолютно противоположное мнение.

Ну вот и ошибаетесь. Вы сами пробовали писать клиент, или так — сосед напел? Особенно какие-то сложные приложения или, тем более, игры. Я вот делал сайт для донатов — там и админка (которая позволяет ползунками настроить любую структуру), и страниця для отображения — сложные, объёмные задачи. А из сервера самое сложное — не забыть залить его вовремя, да бекапы настроить.


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

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

Для полноценного переключения с backend-а на frontend потребуется, минимум года 2. И это если человек с хорошо работающей головой. И это будут мучительные 2 года.


обычно требует очень серьезного изучения технологий

Не требует. Не нужны обширные знания по многопоточности и механизмам синхронизации. Люди часто вообще таких слов не знают. Я вам напомню что большая часть backend-а это PHP, Python, Ruby, Node.js. Не нужны знания паттернов и SOLID. Потому что большая часть backend-а очень устоявшаяся вещь. Условный MVC framework на PHP имеет вполне конкретные guidelines, best practices, разделение на слои.


Серьёзных знаний по SQL тоже не требуется. Большую часть головняка снимает ORM. Даже виды индексов знать не надо. Даже виды транзакций большинству до одного места, т.к. народ просто тупо не пользуется транзакциями. Либо их СУБД в них не умеет :D


Потребуются минимальные знания про работу с файлами. На уровне: смотри вот это файловый дескриптор, вот fwrite, 1-ым аргументом дескриптор. И не забудь fclose. Всё, бери таску из jira и фигачь отчёты.


Знания виртуализации тоже нужны на уровне: чем docker run отличается от docker exec. ДевОпс остальное за тебя уже решил

Я вам напомню

И я напоминаю, что несмотря на GIL у Python есть полноценный мультитриденг и он успешно работает для IO операций в связке с event loop от asyncio. также можно в пару cтрочек выносить управление в отдельный процесс.

Серьёзных знаний по SQL тоже не требуется. Большую часть головняка снимает ORM


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

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

По каждому из этих вопрсов написаны большие и толстые талмуды. Я могу себе только представить, что вы пишите простые сайты и поэтому у вас сложилось такое впечетление или же вас просто задевает и вы хвалите свое «болото». Так как entry level не вытянет бекенд, а фрондент успешно сможет именно поэтому даже из моего окружения множество перепрофилировалось из других профессий на фронтенд или QA automation, а на бекенд никого.
или же вас просто задевает и вы хвалите свое «болото».

Любопытно, что это у вас клиент пишут студенты и вы не видели хороших фрондэндщиков, а болото — у нас.

Ну с чего такие выводы? (вопрос риторический отвечать не стоит)
Я ничего про комманду не писал вообще, а вы фантазируйте. Я лишь выразил свое субьектинвное мнение основанное на опыте. Для меня ваши аргументы звучат все-равно что вы сейчас будете доказывать, что работа секретаря или QA сложней чем у программиста. Я понимаю, что она сложная и важная, но она проще. Учитесь не воспринимать в штыки другое мнение и слышать.

Ну у вас ведь вообще нету аргументов кроме "Бекенд это сложно". Вот вы говорите, что уходят с бекенда на фронтенд. Да, я вот первые 5 лет был бекендщиком и понял, что это — скучно, потому постарался переметнуться во фронтенд, ведь тут есть разные новые задачи, а в бекенде хотя я и не дошёл до верха — там всё то же самое. Ну да, выучил дополнительно пару технологий, но опять же просто фигачешь по шаблонам.


Ваша аналогия — глупая и я объясню почему.


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


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


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


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

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

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


С одной стороны почти никогда не бывает скучно. С другой стороны вечный brain-storm.

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

Ну ведь мы вам об этом как раз и говорим. Бекенд задачи — именно такие. Потому бекенд и неинтересный.

Это всё зависит от подхода. Если на каждый эндпоинт копипастить типовой код, то это мало чем отличается от копипасты формочек на фронте. Я, например, делал такой бэкенд, где:


  1. Предметная область описывается простым конфигом, по которому автоматически поднимается БД.
  2. Есть всего несколько эндпоинтов, каждый из которых может работать с любой моделью по единым правилам.
  3. Fetch Plan определяется текущими потребностями клиента, а не хардкодится.
  4. Код модели шарится с фронтом — её не надо описывать дважды.
  5. Данные в реальном времени обновляются через сокеты.
  6. Подсписка на обновления и отписка происходят автоматически.
  7. Всё это шардится и реплицируется.

Не назвал бы это скучным закручиванием гаек. Не бывает скучный областей деятельности. Бывают скучные люди.

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

Я десятый раз пишу, что это основано на моем опыте и он субьктивный.

А вас настолько задевает и трясет, что вы мне приписываете и неумение во фронтенд (хотя это самое легкое что я вообще делал).
И то что нас много студентов в комманде, хотя их нет вообще.

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

Ваш опыт очень плохо отражает объективную реальность. Но читать почему-то не умею я. Интересно.

А где тут в треде объективная реальность? Аргументы уровня "скучно", "интересно", "есть вызов" — это субъективизм чистой воды.

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

у Python есть полноценный мультитриденг

Да и в node-js можно с потоками писать. But why? Это точно не входит в перечень необходимых знаний для python\nodejs backend разработчиков middle (и возможно senior) уровней. А случае PHP вообще граничит с безумием и ненормальным программированием.


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

Не, никаких ни пол-года. Но года три в среднем достаточно. Для фронта мне кажется около 8-ми нужно.


что вы пишите простые сайты

Не я пишу. А backend программисты пишут. И да. Вы попали в самую точку. Большинство backend программистов пишут простые сайты. Вот прямо в десяточку. Не знаю как от вас эта простая истина ускользала все эти годы.


а фрондент успешно сможет

Не сможет. Не знаю таких случаев. Обратно — легко. Я провёл много собеседований.


QA automation

Вам не смешно сравнивать QA-automation c frontend? Вы выше писали про то, что вы full-stack. Мне кажется вы лукавите. Складывается впечатление что вы имеете очень отдалённое представление о современном frontend-е.

Складывается впечатление

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

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

Вы правда думаете что я не понимаю как устроен React и Vue? :) Сложность вызывает не изучение framework-ов, а умение с ними сварить кашу. В подавляющем большинстве случаев люди не могут выстроить разумную архитектуру. Ни разу не слышал о таких проблемах в популярных PHP-фреймворках. С ними вы начинаете приложение с того, что архитектура уже готова и она разумна. Главное придерживаться нескольких концептов.

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

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

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

Ну да, ну да. Ведь так круто писать фронтенд на пхп и питоне. А на ДжаваСкрипт люди начали идти только когда он тоже осерверился


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

JavaScript начали идти так как это один из самых простых языков программирования с низким порогом вхождения (ничего плохого в этом нет мне он тоже нравится).

Вот только JS появился в один год с ПХП и Питоном, а начали идти только когда стал популярный серверный. Причинно-следственные связи улавливаем?

Я вас удивлю и дам исторический урок, но JavaScript и на фронтенде стал популярным относительно недавно с выходом jQuery. А набег вайтишников уже попер с появлением фреймворков новой волны и это не связано с Node.JS так как при изучении JavaScript Node.JS учат в самую последнюю очередь.

Я вас удивлю, но эту историю я видел, писал и делал сам, а не прочитал в интернетике.

Я вас удивлю и дам исторический урок, но JavaScript и на фронтенде стал популярным относительно недавно с выходом jQuery.

На вашем месте я бы постеснялся в 2021 году имплицировать, что выход jQuery был "относительно недавно". Потому что в 2021 году выход jQuery относительно зарождения интернета был практически настолько же "недавно", что и относительно текущего момента.

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

Собственно дальше позиции верстальщиков из вайтишников мало кто уходит. А это не программирование.

Успешно справляются с React и Vue. Angular идет сложней обычно, но там нужно просто уже хоть два паттерна знать. Хотя меня это меня и немного удивляет, почему он вообще может казаться сложней.
Успешно справляются с React и Vue.

C React успешно справляется процентов 10% из тех кто на нём пишет. Оставшиеся 90% только думают, что что-то в нём понимают. Я проводил много собеседований и знаю о чём говорю.


Код этих 90% = write only. Именно после таких вот "справившихся" мы читаем очередной longread о том "как я внедрил в проект react и меня чуть не уволили". Концепции которые лежат в основе вменяемого React кода слишком сложны для подавляющего большинства разработчиков. Включая backend разумеется.


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


С Vue точно такая же петрушка. 99% "Vue разработчиков" (мне даже сам термин %framework%-разработчик противен) даже не знают как работает observable. О результатах я думаю вы догадываетесь


Вот только в случае с Angular есть какие-то надежды. Костные framework-и, где за вас уже всё решили — они пригодны для начинающих. Меньше шансов выстрельнуть в ногу = хорошо. К тому же он ближе к типичным backend концептам.

C React успешно справляется процентов 10% из тех кто на нём пишет. Оставшиеся 90% только думают, что что-то в нём понимают. Я проводил много собеседований и знаю о чём говорю.

Я думаю вы преувеличиваете, мой опыт говорит что от силы 5%. Истина где-то посередине =)
Оставшиеся 90% только думают, что что-то в нём понимают.


Про что я и писал выше. Ситуация на рынка такова, что такое качество допустимо и поэтому много вайтишников, и поэтому достаточно даже 5% чтоб начать. Но вот опять же, выбросить через год cайт, это не тоже самое, что выбрость core функционал.

Ситуация на рынка такова, что такое качество допустимо

Т.е. то что на рынке есть конторы которые готовы нанимать абы кого, чтобы писать абы что, и потом это выкидывать через год… Заставляет вас думать что frontend простой? :)


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

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

Возможно мой опыт нерелевантен, но я последние годы работал над проектами, куда не только студентов не возьмёшь, а вообще разработчиков уровня ниже senior-а лучше не брать. Да и senior-у вникать пару месяцев, прежде чем он выйдет на окупаемость. Про студентов я вообще молчу. Они действительно не смогут запороть проект, т.к. я не могу дать им вообще никаких задач. Признаюсь я вообще не знаю как можно выстроить архитектуру большого SPA так, чтобы junior мог приносить больше пользы, чем вреда. Наверное я дурак. А может web свернул не туда. Но правда — всё слишком сложно.


А вот на backend-е я вполне себе представляю задачи под junior-а. Например — напиши endpoint который по ID товара делает запрос в базу, трансформирует результат в такую-то форму и передаёт на клиент в таком-то виде. Сделай по аналогии с вот этим местом. И покрой тестом. Пример теста вот здесь. Там почти копипаста.


риски намного больше и ответственность

??? Почему выше риски? XSS сопоставимы с SQL инъекциями по уровню наносимого ущерба. Это если вы про безопасность. А если про ущерб бизнесу из-за багов — то не так важно где баг сломал функциональность на клиенте или на сервере. Если что-то не работает, то бизнес теряет деньги.


многопоточность

Огромная часть бакенда это PHP, python, ruby. О какой многопоточности вы говорите?


для серьезных проектов

Коих абсолютное меньшинство


энтерпрайз

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


конкурентный доступ к данным, синхронизация

В подавляющем большинстве случаев бакенд-разработчик может даже не знать таких слов и прекрасно справляться со своими должностными обязанностями. Come on, зачем вам это в связке "запрос в базу — отправить json на клиент".


ООП, паттерны

Не нужно всего этого знать. Для большинства backend проектов уже есть готовые матёрые framework-и где всё за вас продумано. Будь это Symphony, или Play или Django. Открыл документацию, почитал правила нейминга и как делить код на слои, посмотрел на примеры кода, посмотрел как другие ребята пишут в проекте — и понеслась.


Пожалуйста не путайте сложный замороченный backend, которого исчезающе мало, и обыкновенную монотонную работу по перекладыванию json-а.


В противовес этому на фронте есть множество замороченных паттернов и даже очень опытные разработчики не могут придти к тому как это всё правильно писать и связывать. На рынке frontend-а хаос, джунгли, полная анархия. Нет никаких best practice. Любая информация, которая сейчас рассматривается, как незыблемая истина, завтра считается мусором. Особенно если речь идёт про React. В случае React каждая контора пишет какой-нибудь свой универсальный велосипед, собирая его как конструктор, на лету изобретая его части. Это правда действительно очень сложно.

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

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

Энтерпрайз это где основные деньги, а избегают этого просто из-за того что нужно именно что-то знать)

O_o. WAT? Что-то знать для ынтерпрайза? Зачем?


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

Громадный != сложный. Громадный почти всегда = говнокод + legacy + кривая архитектура. Громадный = много команд разработчиков = большое количество бюрократии, дурака-валяния, подковёрных игр, идиотических поступков ради премий. Громадный обычно = устаревшие технологии, огромный технический долг, очень низкий уровень разработчиков.


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


Один из моих бывших шефов сказал гениальную фразу: программисты приходят в банки чтобы умирать (как специалисты). Один мой знакомый программист из банка пару лет назад хвастался что смог уговорить руководство и внедрить git. До этого у них СУВ вообще не было.


Ну и нет тут никакой деградации отрасли. Всегда так было.

кривая архитектура

Это совсем не так, если бы так было, то их бы не могли поддерживать годами, а это происходит.

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

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

вот вам моя любимая паста про Oracle:


long read

Oracle Database 12.2.
It is close to 25 million lines of C code.


What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.


Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.


Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.


The only reason why this product is still surviving and still works is due to literally millions of tests!


Here is how the life of an Oracle Database developer is:


  • Start working on a new bug.


  • Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.


  • Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.


  • Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.


  • Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.


  • Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.


  • Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.


  • Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.


  • Finally one fine day you would succeed with 0 tests failing.


  • Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.


  • Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.


  • After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.



The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).


The fact that this product even works is nothing short of a miracle!


I don't work for Oracle anymore. Will never work for Oracle again!


source


И это Oracle. В конторах попроще всё ГОРАЗДО хуже. Вы 1-ый программист на всём моём жизненном пути, кто вообще отзывается об ынтерпрайзе в позитивном ключе.

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

Если серьезно, ынтерпрайз бывает разный (даже в банках). Есть ынтерпрайз по типу того, что у вас в лонгриде про оракл. У него простые признаки:
1) он приносит деньги и продолжает приносить деньги
2) он древний, как говно мамонта, и продолжает быть таковым
Такой энтерпрайз практически всегда скатывается к тому, что описано в лонгриде — к стройной, и устоявшейся веками системе костылей, велосипедов, и подпорок. Которую невозможно переписать, а попытки поддерживать — вызывают рак мозга.


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


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

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

Да нет, вы просто $mol не пробовали, поэтому и не знаете. Тут всё просто:


  1. Инкапсуляция. Не сокрытие, а именно инкапсуляция, когда ты берёшь компонент и просто его используешь без приседаний вокруг импортов, сторов, DI и тп.
  2. Минимум абстракций. Простые абстракции. Классы, реактивные свойства, контекст окружения — этого уже достаточно.
  3. Разделение на слои. Модель отдельно, логика отдельно, композиция компонент отдельно, оформление отдельно. А не вперемешку, как в Реакте.

А вот на backend-е я вполне себе представляю задачи под junior-а. Например — напиши endpoint который по ID товара делает запрос в базу, трансформирует результат в такую-то форму и передаёт на клиент в таком-то виде. Сделай по аналогии с вот этим местом. И покрой тестом. Пример теста вот здесь. Там почти копипаста.

На фронте будут такие задачи по нарастающей:


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

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

У вас есть хоть одна ссылка где бы кто либо из профессионалов попробывал вашу библиотеку и дал сравнение или отзыв? Не с целью задеть, а реально интересно.

Сам уже 4 года жду какую-нибудь разгромную статью про то, как в $mol всё плохо, но пока глухо.

Это мои статьи, а речь шла о неангажированном анализе.

Я знаю, что это ваши статьи. Однако, все недостатки $mol винды прямо из них, достаточно внимательно прочитать…

То что вы считаете недостатками не обязательно таковым и является.

Открыл документацию, почитал правила нейминга и как делить код на слои, посмотрел на примеры кода

Вот в случае примеров кода Symfony в разделах про СУБД сплошные антипаттерны, потому что показывают как из фреймворка достучаться до слоя данных, а не как его организовывать.

антипаттерны

антипаттерны тоже паттерны ;)

Формально, да. На практике это "как надо делать" и "как не стоит делать без чёткого понимания плюсов и минусов". А так 90% проектов на Symfony с Doctrine будут содержать анемичные модели из геттеров и сеттеров потому что так в документации и даже средства кодогенерации для этого есть

А как должно быть по-вашему? Желательно конкретные названия паттернов или ссылки.

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

Вы про ActiveRecord что ли? Этот паттерн по-вашему лучше, чем DataMapper?
а не размазывающая их по всей кодовой базе
Где Вы «размазывание» увидели? Есть модель, есть репозиторий. Что не так?
НЛО прилетело и опубликовало эту надпись здесь

Речь тут прежде всего о хранении в памяти — составе и типах полей.

Мухи (модель) отдельно, котлеты (хранение) отдельно

Сущности Доктрины моделируют сущности предметной области, а там, обычно, нет операций типа "установить статус заказа в "Доставлен" или "Отменён"". Order::setStatus(Order::STATUS_CANCELED) отклоняется от предметной области и нарушает инкапсуляцию модели. Просто Order::cancel();


https://ocramius.github.io/doctrine-best-practices/

На самом деле в предметных областях очень много именно "статусов", а не вязанки cancel/reopen/reorder/resign и тд. Ибо многие переходы обратимы, а многие пропускаемы. В итоге на 10 статусов может быть до сотни переходов. И отдельно описывать каждый из них — это удавиться можно. Тут гораздо лучше работает разделение на "требования для перехода в нужный статус" (например, товар не отгружен, счёт оплачен) и "намерение перейти в нужный статус" (например, хочу, чтобы заказ был отменён).

Одно другому не мешает, метод cancel может быть примерно таким:


public function cancel(): void
{
  if ($this->canStatusBeChangedTo(self::STATUS_CANCEL) {
    $this->changeStatusTo(self::STATUS_CANCEL);
  } else {
    throw new \DomainException("Order can't be canceled"); 
  }
}

Или вы что-то другое имели в виду?

И какой смысл заводить 100500 методов с одинаковым содержимым, отличающимися лишь константами?

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

Отмена из разных состояний — это совсем разные процессы. Единственное, что их объединяет, — это конечное состояние.

Не "отмена из разных состояний" — а "отмена из разных мест в коде". Отменяться заказ может как прямой командой пользователя, так и реакцией на событие или вообще по истечению времени — и все эти случаи лучше привести к единому order->cancel(), чем иметь повсюду разные случаи прямых вызовов order->setStatus(CANCELLED), которые неизбежно в итоге разойдутся и будут выглядеть по-разному и содержать разные баги.

order->cancel() ничем принципиально не отличается от order->setStatus(CANCELLED) кроме возможности во втором случае иметь обобщённую логику, вместо копипасты.

Почему из order->cancel() хоть как-то следует копипаста?

Я вас не понимаю. И что? Вы предлагаете не писать код, который должен исполнятся при переходе в статус CANCELLED?


"Если юзер использует наше приложение не так, как задумал программист — он сам дурак", правильно?

Я предлагаю писать обобщённый код, а не копипастить типовой код на каждую проводку. Ну, подумайте над системой, где админ может накликивать бизнес процесс. Это предел обобщённости. Там не может быть никаких методов order(), а энам со статусами вообще в базе хранится. Даже если не нужна такая гибкость, проект куда проще развивать, если это все не хардкодить.

order->cancel() ничем принципиально не отличается от order->setStatus(CANCELLED)

Ну как это не отличается? Допустим, в вашей системе при отмене ордера должно так же отменяться всё планирование поставок, логистики, складских операций. Допустим, для упрощения, что всё напрямую не связанное с ордером выносится в другие домены через события. Тогда в псевдокоде:
cancel()


fun cancel():
    if not this->canBeCancelled() then:
        throw UpdateError('Order can not be cancelled')
    end
    this.status := OrderStatus.Cancelled
    storage->flush(this)
    evenBus->fireEvent(OrderCancelled(this))
end

А в случае с setStatus будет примерно вот так:


fun setStatus(OrderStatus value):
    eventType:= Nil
    if value == OrderStatus.Draft then:
        ...
    elif value == OrderStatus.New then:
        ...
    elif value == OrderStatus.InProcessing then:
        ...
    <!--думаю, так уже достаточно понятно-->
    elif value == OrderStatus.Cancelled then:
        if not this->canBeCancelled() then:
            throw UpdateError(
                'Order can not be cancelled'
            )
        end
        eventType := OrderCancelled::Ref
    else
        throw UnknownOrderStatus(value)
    end
    this.status := value
    storage->flush(this)
    eventBus->fire(eventType->create(this))
end

При этом в первом варианте если типы можно абстрагировать, то может быть вообще примерно так:


fun cancel():
    this->runStatusChange(
        this.canBeCancelled::Ref,
        OrderStatus.Cancelled,
        OrderCancelledEvent::Ref
    )
end

А вот во втором случае от if ... elif ... elif ... else (или аналогичного switch) избавиться уже далеко не так просто.

Ну вот вы в конце и пришли к обобщённой функции runStatusChange, параметризированной статусом. Теперь вы можете сделать ещё один шаг:


fun setStatus(OrderStatus status):
    this->runStatusChange(
        status.Allow,
        status,
        status.Event,
    )
end

А потом ещё один, и убрать этот runStatusChange совсем.


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

status.Allow, status.Event

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

НЛО прилетело и опубликовало эту надпись здесь

Я не понимаю, на что именно вы возразили, честно говоря.
Обобщённый объект — это который из двух? Order? Или OrderStatus? Если второе, то как раз плохо то, что стратегия является частью статуса — а это значит, что мой домен ей, вообще-то, не может доверять, если все возможные стратегии не известны заранее и сам объект конструирует кто-то за пределами домена.

Что-то я пропустил главную вашу фразу. Вот эту:


То что вы сталкивались с разработчиками с базовым уровнем SQL, docker, паттернов не значит что это норма и стандарт в индустрии.

Причём тут разработчики? Я вам про рынок говорю. Огромный процент backend разработчиков пишут весьма примитивные backend-ы для весьма примитивных сервисов. Ну come on. Большая часть бакенда в мире это просто 1 mysql/postgresql база, какой-нибудь Symphony или Django, и 50-200 endpoint-ов, из которых 90% это перекладывание JSON-а.


Я как раз сталкивался с крутыми backend разработчиками. Например я сейчас работаю в конторе, которая пишет отказоустойчивый high-load backend в облаке, на микросервисах, с шардированием, нестандартными решениями, и прочем фарше. И да, в FP парадигме.


Просто я прекрасно понимаю, что это даже близко не норма. Это "крутой уровень", и крутые интересные задачи. Открывая на бирже труда "backend developer" вы вместо этого скорее увидите "Middle/Senior PHP developer. Laravel min. 3 years". Получив offer будете клепать одинаковые web-проекты под копирку. Даже тесты, вероятно писать не будете, ибо финансово неоправданно. Весь code — write only.

Это "крутой уровень", и крутые интересные задачи

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

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

Вы вероятно невнимательно меня читаете. В моей текущей конторе как раз и работают весьма толковые backend программисты, которые пишут сложный high-load backend. И у нас на кухне разговоры про шардирование, property based testing, алгебраические эффекты, FP, всякие тонкости реализаций DI и пр.


Но я прекрасно понимаю насколько это редкий case. Типовой backend = перебрасывание json из базы на клиент и обратно. Это просто факт. Зачем вы пытаетесь это отрицать?

property based testing, алгебраические эффекты, FP, всякие тонкости реализаций DI и пр.

Но ведь все эти вещи обсуджают и клиентщики, плюс… куча всего дополнительного.

Да :) Всё так. Но я бы не стал так умалять заслуги серьёзного backend-а. Помимо своего головняка, у них там много всяких хитрых side-задач из нерелевантных областей. Могут припахать и какой-нибудь ML писать. Была бы голова на плечах, а чем её загрузить — найдётся. Не важно какая область. У нас backend на scala2, а это коммьюнити очень одарённых "извращенцев". Они себе геморрой на голову всегда придумают :D

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

Это относительно, иногда конторе все-таки выгодно наговнокодить и продать больше людей ;)

Легко сказать, да трудно сделать. Я конечно понимаю, что у вас святая вера в то, что ваши решения простые, правильно выстроенные, и вообще $mol впереди планеты всей.


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

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

С интересом слежу за вашей дискуссией, и у меня возник один вопрос:


Kromeshnaja, а вы точно не автор этой статьи завели себе второй аккаунт?

Нет, но я бы задал точно такой же вопрос.
У меня небольшой React проект из коробки в продакшене билдится больше 15 минут (кстати с ангуляром этого не происходит, а и там, и сям вебпак) и это моментально вызывает вопросы.
Если вам смешно и вы считаете этой нормой, и не понимаете почему бумеры что-то там нервничают.
То я вам предлагаю просто пообщаться с заказичками и вы увидите, что иногда для бизнеса это не очень то приемлимо.
Если вам смешно и вы считаете этой нормой, и не понимаете почему бумеры что-то там нервничают.

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


Для сравнения — парсер и транспайлер для JS/TS написанный на rust (правда без резолвинга типов) работает в 100 быстрее аналогичного в babel.


Нет, это не норма. Это грустно.

С одной стороны я тоже не в восторге от текущей ситуации и хотел бы переехать в webpack на esbuild.


Но в то же время, все мы помним историю libsass


  • Появляется энтузиаст, который пишет нативную имплементацию, супер быструю
  • Инициатива радостно приветствуется сообществом, кто ж не хочет ускорения билда почти забесплатно
  • При этом PR-ы сообщество не присылает, потому что нужно не только разбираться в SASS, но еще и в CPP и алгоритмах, чтобы держать на уровне планку производительности
  • Через какое-то время запал изначального создателя угасает, а заменить его некем
  • А фичи все равно допиливать надо, тут и CSS-variables появились, и новый формат SASS-модулей
  • В результате проект закрывается потому что поддерживать его некому.

Каковы шансы, что та же самая история не повторится с esbuild и каким-нибудь будущим стандартом ES2025?

Получается такая ситауация:


  • Вы считаете что во фронтенде нет сложных задач, джуниоры справятся со всем
  • И тут же приводите пример, что все-таки не со всем

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

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

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

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

С чего начинали


Обычно beckend разработка предполагает больше знаний, умений и ответственности. Поэтому не совсем понятно в чём должна быть сложность изучить и писать frontend, если стоит такая задача.

Чем закончили


Нет разницы, нужно понимать суть

Обе цитаты ваши.

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

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

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

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

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

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

Мне кажется всё упирается в следующие вещи:


Вы рассматриваете в качестве типичного backend разработчика человека, который работает на большим и сложным приложением. Которое использует несколько разных баз данных. Которое разбито на 10+ микросервисов. Которое имеет сложную контейнеризацию. В компании работает как минимум 1 dev.ops, который шаманит k8s. Почти все сервисы шлют сообщения в кафку, выворачивают redis на изнанку. Для всех популярных сущностей используется шардирование. Всё это тщательно покрыто разноуровневыми тестами. Приложения написаны на Java/Scala/C#/Haskel. Разумеется многопоточные. Требуется высокая отказоустойчивость. Разумеется это сложно.


А в качестве frontend-ера вы рассматриваете человека который занимается html/css вёрсткой, гоняет на backend и обратно json-ы. И его приложение это что-то вроде гостевой книги, корзины и формы оплаты в интернет-магазине. Ну, скажем, условный Amazon. Ну он правда несложный с точки зрения frontend-а. Или yandex.market-а (уже посложнее, но всё равно ничего особенного).


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


А мне под senior frontend developer-ом выдится человек которые пишет Google Docs, Facebook, GMail, Google.Maps и прочие SPA. Тут ключевые три буквы SPA = Single Page Application. Это то что мы раньше видели как десктопные приложения (условный Photoshop, After Effect, видео редакторы, офис и пр.). Вот это всё долго и уверенно переезжает в браузер. Это действительно большие приложения, с огромным количеством форм, экранов и тонкостей в UI.


Когда вы видите условный Instagram, вам может показаться — ну что такого сложного в том чтобы показать десяток картинок. Но если вы заглянете под капот вы сильно удивитесь, насколько сильно замороченным может быть показ десятка картинок. Для примера, из-за того что тег <picture/> это дикое позорище, а вовсе не, responsive image control, мне пришлось потратить неделю на написание своего, который по-настоящему responsive.


В сложном UI обычная кнопка может вызывать неделю споров о том, как организовать его архитектуру, и две недели реализации (с многочисленными правками и переобуваниями в воздухе). Хотя с виду кажется, что там делать нечего, это же ведь обыкновенный <button/>, чего там обсуждать.


Современный frontend бывает сложным как в мелочах, так и в архитектуре. 2-ая часть вообще кромешная беда фронта. Если пишешь приложение хотя бы под 50к LOC+ (да это одно frontend приложение, одна страница), то в попытке построить архитектуру сломаешь много копий и пару раз всё перепишешь.


Вот вам не придёт же в голову говорить, что 2GIS, Google.Docs или Google.Earth это простые приложения не требующие широких познаний во множестве областей? А это тот самый frontend. И вышеупомянутая вёрстка тут на фоне общих задач даже не отсвечивает. И вот очень странно читать сообщения про то, что фронтенд простой и его осилит даже самый тупой. В то время как из 100 кандидатов на вакансию хорошо если 1 что-то умеет. И ещё это всё странно читать когда народ уходит из backend-а устав от его скучных задач (мало кто сталкивается с вышеописанным сложным backend-ом).


Вы писали про банки. В банках я пока не встречал сложных приложений. Больших — да. Сложных нет. Немецкие банки легко обходятся самые древними web технологиями и в ус не дуют. Тот же самый Commerzbank. Даже переменные на немецком. Технический stack — каменный век. Типичный ынтерпрайз. Если оценивать сложность фронтенда по таких вот проектам то и правда окажется, что можно брать джунов с улицы и посылать на передовую. Вся передавая какая-нибудь говно-лапша на jQuery.

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

Вы сейчас на полном серьёзе утверждаете что Google Docs несложен? И что его бакенд часть требует бОльших компетенций? О_о.


Мне кажется у вас очень посредственное представление о задачах, которые решают любые фронтендеры. Будь то desktop/android/ios/web разработка.

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

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

Послушайте, вы меня изрядно утомили однотипными сообщениями.

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

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

Перестаньте заниматься ерундой.

Ладно-ладно, давайте без истерик. Видимо я необъктивен, а вы правы, что Гугл Доки — это примитивный клиент и любой серверщик такую фигню за три дня сделает. И в этом никакого хейта.

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

Ну вот я и говорю — либо вы абсолютно не понимаете, что там за объём работы, либо врёте

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

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

Разница в том, что я ничего не пытаюсь доказать, вы просто нафантазировали.

Вот давайте счёт на табло, так сказать

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

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

Если вы считаете глупым, что кто-то может подумать (ужасное мыслепреступление), что фронтенд разработка проще относительно бекенд разработки, ну что ж, вы общаетесь именно с таким человеком.

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

Подумать, что фронтенд на Google Docs у бекендера занял бы меньше времени чем бекенд — да, несусветная глупость.

Это не глупость, а факт. На фронтенде не нужно запариваться про безопасность, про контроль версий документа, про уровни изоляции БД, про нагрузку, про архитектуру REST вызовов, про синхронизацию между серверами и процессами; потоками, про парсинг, про кибербезопасность (CORS, сертификаты), про нагрузочное тестирование и сертификации на всякие penetration testing при выходе на prod, про SQL injection, про ORM или же организацию доступа к данным, даже SAD и тот обычно не требудется.  Все это, обычно, предоставляют и говорят уже что отобразить.
Это все сложней и объёмней написать чем SPА application и если вы сейчас будете приводить какие-то примеры форм или сложностей, то не забывайте что на каждый чих вы вызываете API где и реализована основная логика. 

Ну, одним словом, вы не знаете, чем там занимаються эти фрондэндищи — потому значит они нифига не делают.

В двух словах знаю, так как сам занимаюсь.

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


На фронтенде не нужно запариваться про безопасность

Нужно. Как минимум нужно отсекать небезопасные ссылки в документе, чтобы они при клике не запускали произвольный код на исполнение. А так же фильтровать то, что в документ может накопипастить пользователь.


про контроль версий документа

Необходима реализация undo/redo, которая откатывает лишь действия текущего пользователя, но не других пользователей. При этом действовать она должна мгновенно и не зависеть от размера документа и истории.


про уровни изоляции БД

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


про нагрузку

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


про архитектуру REST вызовов

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


Простой пример: если пользователь нажал B, то нужно пройтись по всем текстовым узлам и завернуть их в strong, кроме тех, что уже в strong. Но если все и так в strong, то нужно наоборот развернуть все strong.


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


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


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


про синхронизацию между серверами и процессами; потоками,

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


про парсинг

Пользователь может скопипастить в любую часть документа как плоский текст (мы ещё поддержали свой вариант маркдауна) так и весьма дикий html, который необходимо нормализовывать, ведь каждая IDE и каждый редактор документов выдаёт совсем разную вёрстку. Где-то строки разделяются br-ами, где-то заворачиваются в div-ы или p-шки, где-то и то и то. Про остальные типы блоков я даже не заикаюсь.

НЛО прилетело и опубликовало эту надпись здесь

Хуже, помирает в клозед сорсе.

Для примера, из-за того что тег <picture/> это дикое позорище, а вовсе не, responsive image control, мне пришлось потратить неделю на написание своего, который по-настоящему responsive.

Что вы вкладываете в слово "responsive"?


В сложном UI обычная кнопка может вызывать неделю споров о том, как организовать его архитектуру, и две недели реализации (с многочисленными правками и переобуваниями в воздухе). Хотя с виду кажется, что там делать нечего, это же ведь обыкновенный <button/>, чего там обсуждать.

Что там в кнопке 2 недели реализовывать? Это на Реакте такая жуть?

Просто рынку и в самом деле сейчас не нужен сильный backend в таком количестве.

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

Хотя я сам не сильно-то и люблю React, но всё же попробую ответить на некоторые придирки к нему.


«Где инъекции зависимости? Что ты имеешь в виду под „Не нужно никаких инъекций“? Вот пример: InversifyJS!»

https://habr.com/ru/company/docsvision/blog/350398/ (читать вместе с комментариями!)


«Функциональные компоненты»? Нет, нет, нет. Они нам не нравятся. Давайте работать с компонентами класса!"

Ну так работайте, в чём проблема-то?


«Почему эти функции просто болтаются в коде, и почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?»

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


Напомню, что в языках Java и C# глобальные функции запретили потому что там каждый файл с кодом "видит" все остальные, и без принудительного использования классов в качестве пространств имён получилась бы свалка. А в современном Javascript/Typescript используемые функции из других модулей импортируются явно.


Если же убрать из вопроса слово "статичными" — то ответ простой: ну а кто мешает их инкапсулировать при желании? Вот ни разу со мною не случалось такого, что я хотел что-то инкапсулировать — а фреймворк мне мешал!


«Где Retry Policy [прим. перев: политика повторения запросов] для API? Давайте реализуем её с помощью PollyJS».

Отлично, в вопросе уже содержится решение :-)


«Почему в именах файлов тире, когда имена классов – PascalCase? Имена файлов должны отражать имя класса в файле, поэтому отныне будем называть их SomePageComponent.tsx».

Переименовывайте, разрешаю :-)


А если серьёзно — то потому что в файле может быть не один класс.


И вопрос, который раздражает меня больше всего: «Как я могу запустить его в Visual Studio, а не в Visual Studio Code?»

Э-э-э, берём и запускаем?


Сборка фронта делается при помощи свойства PreBuildEvent или таргета с указанием AfterTargets="BeforeBuild". Хотя конкретно этот шаг я пропускал, потому что фронт собирается долго, и проще собирать его вручную чем каждый раз ждать когда он соберётся.


Далее прописывается .UseStaticFiles() с путём нужной папке и всё.

Напомню, что в языках Java и C# глобальные функции запретили потому что там каждый файл с кодом "видит" все остальные, и без принудительного использования классов в качестве пространств имён получилась бы свалка. А в современном Javascript/Typescript используемые функции из других модулей импортируются явно.

Да тоже могут получаться свалки, когда экспортируемые функции стекаются в index.ts, как "export * from ...", с возможными конфликтами имён и прочими радостями. Потому иногда группировать полезно.

При появлении подобных конфликтов имён самое время отказаться от сваливания всего в index.ts!

Теперь про вторую пачку вопросов.


Какой маршрутизатор следует использовать?

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


Если же маршрутизатор таки нужен (скажем, чтобы пользователи могли передавать друг другу ссылки или сохранять что-то в закладки) — то что, есть какие-то варианты кроме react-router?


Что кроме Redux мы должны использовать для асинхронных действий? Trunk? Saga?

А вот в формулировке этого вопроса уже содержится ошибка. Как уже упоминали в комментариях выше — для бывших WPF-разработчиков надо было выбирать mobx. Да, тут ошибка автора.


Должны ли мы использовать Axios или fetch API в браузере?

Swagger надо выбирать, swagger. Точнее, надо выбрать любой из OpenAPI-генераторов для кода клиента и забыть об этой проблеме.


Redux-Forms, Formiq или Final-Form?

Вот тут ничего не скажу, поскольку сам не до конца понимаю зачем оно вообще нужно.


Styled-Components, makeStyle, SASS или чистый CSS?

Чистый CSS — точно не вариант. А между остальными вариантами выбор должен был сделать автор, его для того в проект и приглашали же. И уж точно не WPF-разработчикам три недели спорить об этом.


А что с библиотекой интернационализации?

А корпоративному приложению она нужна?

Есть международных корпорации. Есть страны с несколькими языками.

что, есть какие-то варианты кроме react-router?

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

Но ведь роутер — это, прежде всего, компонент управляющий отображением. Где ещё может лежать его логика?

Ну по такой логике весь код на клиенте управляет отображением и всё должно лежать во вьюшке))


Ну если брать клиентский код и грубо делить его на вью/модель, то, конечно, он должен лежать в модели, ведь "вью" — это скорее "как отображать", а "модель" — это "что отображать".


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


Как только вы перенесёте роутер в модель — поймёте насколько глупой была идея делать роутинг во вьюшке.


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


type ArticleId = number;

class ArticleRoute {
    constructor (public readonly id: ArticleId) {}

    public url => $`/article/{id}`;
}

В мобиксовый моделях я могу полить соответствующие роуты:


class ArticleModel {
    public route => new ArticleRoute(this.id);
}

Соответственно, когда я делаю рендер с ссылками — там всё строго типизировано и я не могу перекинуть на неправильную ссылку:


{articles.map(a => (
    <Link to={a.route} />
)}

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

Соответственно, когда я делаю рендер с ссылками — там всё строго типизировано и я не могу перекинуть на неправильную ссылку

На самом деле можете:


class FooModel {
    public route => new BarRoute(this.id); // упс
}

Да, вы правы. Но количество точек отказа существенно меньше и они не дублируются. То есть ошибка связи "объект -> роут" может быть только в одном месте — в модели. И достаточно обнаружить её на тестировании только в одном месте, чтобы пофиксить во всех.


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

есть какие-то варианты кроме react-router?

Конечно, написать свой используя mobx.
react-router говно и всегда им был.

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

НЛО прилетело и опубликовало эту надпись здесь
Такое было уже сто лет назад в CMS под названием sitecore.
у них были формы на XAML, которые рендерились в html.
Чтоб не соврать, наверное лет 7 назад.
Проблема не в том, что React нарушает принципы .NET или Java, а в том, что вообще нарушает правила хорошего тона выработанные годами! Эти приципы чисто утилитарны — служат для разработки в команде, для легкой поддержки кода, для тестирования.

Это не решение для enterprisе и тем более не для ускорения разработки.

Любой проект с хуками вне tutorial превращается в нечитаемое спагетти. Нужны хорошие знания JavaScript и отличное абстрактное мышление, чтоб вообще знать и понимать когда и что там происходит и обновляется. Вместо декларации переменных громоздкий — useState, оборачивание всех if в useEffect. Во множестве случаев новички React нагромождают огромое количество ошибок даже не понимая этого, им кажется все простым. Для них загадка когда и почему идут обновления и сколько объектов создается при каждом рендере.
Множество проблем как сильное связывание кода, невозможность атомарно тестировать хуки, нет нормального dependency injection.

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

Все должно быть понятно с первого взгяда, но этого к сожалению это не про React.

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

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

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


И задача архитектора задать их и донести до команды

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


Ну самый простой пример, это один из самых ужаснейших антепаттерноа как множественное наследование. И такие древние языки программирования как C++ и Пухтон, которые рождались в муках когда ООП еще было просто прикольной концепцией и народ еще не успел шишок набить, страдали соответствующими врожденным изъяном — они допускали множественное наследование. Там, конечно, пытаются как-то побороть связанную с множественным наследованием неоднозначность, но в более современных ООП языках просто взяли и выпилили саму возможность иметь более одного базового класса, т.к. прием программирования от которого UB много больше чем пользы — это плохой прием. Джависту и дотнетчику не нужно объяснять, что единственный базовый класс является хорошим тоном, просто потому что ни Жаба, ни C# не дадут отнаследоваться более чем от одного :-)


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

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

Наследование в принципе оказалось неудачной концепцией с настоящими подводными валунами:


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


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


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


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


В общем наследование вещь опасная и требует очень осторожного подхода при проектировании архитектуры ПО, и даже большие и серьезные компании могут облажаться. Вот мой самый любимый пример — это стэк и очередь в Жабе. Вообще стэк и очередь — это достаточно примитивные структуры данных, в которые можно только поэлементно что-то пихать и также поэлементно опорожнять их, все, однако в Жабе поступили по другому — их сделали наследниками от списков, вот только списки и очереди это совершенно разные структуры данных, никак друг с другом не связанные, и при таком подходе к наследованию у стэка и очереди появляются нехарактерные для них свойства, ну, например, произвольный доступ. Т.е. однозначно вот это вот
https://docs.oracle.com/javase/7/docs/api/java/util/Stack.html
пример говнодизайна. Кто-то поторопился, не подумал как надо, и обратно уже не выпилишь, так и живем. Вроде бы работает, но сам факт того, что в самой Жабе встречаются примеры того как нельзя делать уже доставляет.


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


Кстати в Дотнете, который появился позже Джавы, со стэком и очередью так не опростоволосились
https://docs.microsoft.com/ru-ru/dotnet/api/system.collections.generic.stack-1
Но там тоже бывали свои приколы, как, например, на самой заре дотнета не было дженериков, зато была уйма неуниверсальных коллекций, которые до сих пор есть, но ими никто сейчас не пользуется и они уже давно стали атавизмом. Или еще более забавная ситуация, когда мелкомягким пришлось менять логику работы foreach — это уже не имеет прямого отношение к наследованию, это уже другая хипстерская штучка — функциональное программирование. Ну вот все любят ФП-сахар, но 90% любителей сахара отказалось не готово к такому явлению как замыкание, и все время напарывалось на одни и теже грабли.


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

Композиция же. Берем и собираем нужный набор компонентов в нужном контейнере и радуемся жизни.


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

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

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


пока Васян пилит свой свой класс, находящийся где-то на 10-ом уровне наследования, приходит Димон и что-то там фиксит на 2-ом уровне наследования, в итоге у всех наследников уровнями ниже меняется логика поведения, а Васян испытывает фрустрациии.

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


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

К приватным свистелкам он доступа не имеет. Инкапсуляция никак не нарушается.


Вот мой самый любимый пример — это стэк и очередь в Жабе.

В Жабе много бестолковых дизайнерских решений. Боксинг, вариантность и тд. Не пинайте калеку, возьмите более вменяемые ООП языки. Ну, D, например. Там нет таких проблем.


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

А потом распечатывает, чтобы это можно было хоть как-то протестировать.


Композиция же. Берем и собираем нужный набор компонентов в нужном контейнере и радуемся жизни.

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


Но на самом деле наследование — это и есть композиция с автоматическим делегированием. Плюс опциональные виртуальные методы. Больше отличий нет.

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


"Но на самом деле наследование — это и есть композиция с автоматическим делегированием. "


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


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

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

Делегирование и прокидывание ссылок друг на друга особо некуда выносить.


вы не можете независимо внедрить часть наследованной иерархии

При множественном наследовании очень даже могу.


тестировать композицию намного проще, так как вы имеете независимые куски

А для тестирования эти независимые куски надо каждый раз собирать во что-то осмысленное.


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

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

А для тестирования эти независимые куски надо каждый раз собирать во что-то осмысленное.

Везде так, но с Dependency Injection сборка сервисов cтановится пустяком в отличии от наследования.

При множественном наследовании очень даже могу.

Да, кроме вершины и середины иерарихии.

только вчера курсы верстальщиков закончил

Что правда? Тогда ясно.

Спасибо за грамотное развёрнутое объяснение.

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

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

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

Но не всегда это нужно. Блин, это два разных инструмента и удобно их использовать по разному, зависимо от ситуации.

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

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


А обязанности архитектор на каждом проекте разные: от нарисовать на листочке несколько фигурок до разработки production ready нескольких модулей как пример и код-ревью каждого коммита на предмет соблюдения спроектированной архитектуры.

У хуков много недостатков, и смешение слоя работы с событиями, внутреннего состояния, асинхронных сайд-эффектов и синхронизации с DOM в одной функции — только одна из болей. Если опустить семантические, клубок зависимостей кастомных хуков и необходимость кеширования переменных и функций для их равенства по ссылкам, есть еще одна ключевая проблема — несовместимость с SSR, т.к. нет хука на componentWillMount, а значит сервер не сможет запустить фетчинг данных и дождаться его завершения. Согласен, что подход с хуками в энтерпрайзе — плохое решение, но с классами все достаточно прилично.

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

Если решили использовать новый подход, то будьте добры и старый код перевести на новый лад, плодить зоопарк себе же хуже.

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

Не только в стилях, там и сам фрейморк пестрит проблемами.
Например, в Angular есть план миграции между версиями и поддержка CLI, в React это месяц ковыряния и хаков, чтоб старый код работал после апдейта. Например тима реакт пыталась взвалить это на свои плечи с их react scrip, но там критические вещи весят годами.

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