Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед

А это как стартапы — надо ли создавать свою компанию? Да вы что, это же дикий геморрой и 95% шанс прогореть и потратить время просто так, просто работать в корпорации куда надежнее и безопаснее. Но да, все существующие компании когда-то были стартапами…

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

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

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

Тебе блин не нужен персистентный чейн всех слайсов стейта приложения

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

Например, когда я осваивал 3д графику, написал свой код для векторов, матриц и кватернионов. В процессе собрал все грабли и досконально разобрался. После этого я могу взять любую библиотеку, использовать её на 100% и при необходимости дописать недостающую функциональность.

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

Автора прекрасно понимаю, так как сам сделал похожий “велосипед” (только под Ангуляр). И статью про его принципы написал. И хотел даже сделать её перевод на Хабре, но пока не решился, поскольку опасаюсь описанной автором реакции.

Думаю, что причина подобного отношения — это не то, что кто-то создал “велосипед”, а то, что этот кто-то не обладает достаточным авторитетом в глазах остальных разработчиков. Если бы эту библиотеку сделал Гугл, Фейсбук или, на худой конец, Яндекс, то её возможно критиковали бы, но никто бы не назвал её “велосипедом”.

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

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

Тут было бы уместно спросить чем велосипед отличается от продукта. Вроде бы тот же программный код, разработчиков у продукта может быть даже меньше, чем у велосипеда. То есть те кто не хотят велосипеда — чего они не хотят? На мой взгляд не хотят отсутствия документации, отсутствия версионирования и минимальной обратной совместимости, отсутствия поддержки, отсутствия вменяемой загрузки через регистр (например через npm, pip, composer), отсутствтвия нужных для разработки API и должного тестирования, проблем с производительностью которые "внезапно" вылазят на проде, подводных камней на которые наскакиваешь когда половина проекта уже сделана и спрыгнуть с "велосипеда" уже нельзя. А в остальном — все хорошо.

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

XML — это подмножество SGML, разработанное для упрощения процесса машинного разбора документа.

Велосипедостроители бывают разные и причины у них разные

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

Я не знаю, что за инструмент вы сделали, знаю только, что редакс это редкостное г… но, в котором есть здравые идеи. Ваша мотивация мне понятна. К сожалению русскоязычное коммьюнити очень злое. Я бы сразу писал все на английском и рассказывал об инструменте на HN и Reddit. Так будет больше шансов получить позитив. Только там другая проблема — вам скажут «все круто, давно хотел такую штуку, вот бы ещё там было X и Y» Вы можете броситься ее делать, а вам это написали просто из вежливости.

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

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

Это крайне близорукое утверждение, оно никак не подкрепляет ваш тезис. XML набирал популярность вместе с Web 1.0, начиная с 1995 года. В то время кода на JS было очень мало, зато много писали HTML. Довольно разумным казалось сделать гибкий и похожий на HTML язык для описания данных.

JSON появился в 2001 году, кода на JS было уже сильно больше и этот код был главным потребителем XML. Уже стало понятно, что 99% данных форматируются очень просто, а гибкость XML оказалась невостребованной. Логичным стало поменять формат данных на урезанный JS, браузеры его уже и так понимали. Это особенно было хорошо для штук вроде JSONP, web sockets тогда еще не было.

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

Во всём нужен здравый смысл — без него никуда.

Умные дяди сказали мне, что я идиот, и надо брать Redux.

Индустрия говорит — Дэн Абрамов дал нам путь.

Когда мне говорят, что в разработке всё уже изобретено, я спрашиваю: «а что, разве у нас не осталось проблем?».

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

Вы же все понимаете да, что редакс был ответом на адский React.Context API? Я им пользовался, каждый раз с содроганием.

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

Я понимаю, что при должном уровне упорства этого можно добиться и на Redux, но зачем когда всё из коробки работает?

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

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

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

Во втором случае, правда, это не совсем велосипед.

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

А вот не может ли кто-нибудь мне, человеку далекому от веба, объяснить зачем нужны фреймворки управления состоянием и желательно дать концептуальный анализ почему они нужны в вебе и не нужны на десктопе, или менее распространены (например в каком-нибудь WPF).

С моей точки зрения вот это вот практически полностью не очень хорошо спроектированный бойлерплейт:

const LoginComponent = (state = initialState, action) => {
    switch (action.type) {

      // This reducer handles any action with type "LOGIN"
      case "LOGIN":
          return state.map(user => {
              if (user.username !== action.username) {
                  return user;
              }

              if (user.password == action.password) {
                  return {
                      ...user,
                      login_status: "LOGGED IN"
                  }
              }
          });
default:
          return state;
      } 
};

И в высокоуровневом коде такое не желательно — хотелось бы как-то связать View с моделью, но при этом не думать об управлении состоянием, причем, в терминах текстовых констант. Типа как в WPF + MVVM.

Семь бед — один ответ:
Костыль и велосипед!
Семь бед — один ответ:
Вставь костыль, изобрети велосипед!

Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед

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

Представьте себе группу разработчиков, которая замахнулась на продукт. Их ожидает два-три года увлекательной жизни с рисованием схем на стирабельных досках, кофе-брейков и прочих внешних признаков творения продукта. При этом разрабатывается по сути велосипед под видом продукта и начинает использоваться в нескольких внутренних проектах. Но рано или поздно наступает момент когда разработчики сливаются и это все оказывается на поддержке у людей которые ничего не знают об этом продукте-велосипеде. И тут как всегда "внезапно" выясняется, что
1) Нет ни строчки документации по продукту-велоспеду
2) В разных проектах заюзаны разные несовместимые версии продукта-велосипеда, а в репе продукта находится только последняя из них
3) Много багов
4) Проблемы с производительностью
В одном из случаев, с котрым я имел дело, разработчики планировали завоевать мир и рубить бабло по полной, поэтому репы размещали в своих личных репозитариях на github под лицензией имени себя, а один из разработчиков или от обиды на работодателя или от стыда за свой код — просто закрыл или удалил репу с исходным кодом. Когда это выяснилось, пришлось восстанавливать ее из кода на продакшин сервере.

Если разобраться объективно, мог ли у них получиться продукт а не велосипед. Может быть у них был шанс? Я бы ответил что нет, не мог. По причинам, что задачи которые они ставили имели более высокую трудоемкость, чем мог позволить их коллектив. Такие вещи как документирование, тестирование, версионирование, доставка изначально не были продуманы и внедрены, и значит не могли быть внедрены никогда. Это как бы объективно. Кроме того такие моменты которые конечно уже можно оспорить как отсутствие опыта, критического отбора решений но это уже лирика.

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

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

Вобщем я полностью согласен и поддерживаю мысли автора в этой статье!

Полностью согласен с автором. Я когда начал писать свою ORM-либу на плюсах мне то же самое говорили https://github.com/fnc12/sqlite_orm. А сейчас она на втором месте по кол-ву звезд среди ORM для SQLite3 на плюсах на гитхабе