Ваш комментарий только подтверждает вашу зашоренность.
Я нигде в ветке не защищал и не продвигал реакт. Но ваша зашоренность не позволят вам объективно участвовать в дискуссии и воспринимать тезисы других людей.
У вас явно проблемы с коммуникацией, поэтому не понимаете почему везде есть компромиссы, в т.ч. в разработке. Да, в программировании компромиссов почти нет, но мы говорим про разработку, а не про научный подход.
Мне вас в некотором смысле жаль, т.к. явно знания есть, но вы не можете их реализовать из-за зашоренности.
Как много примеров компаний вы знаете которые закрылись из-за плохого фронта?
Если следовать вашей статье, то нужно ставить условия бизнесу, а не искать компромиссы.
Но если вы так будете делать, то бизнес найдет более подходящего разработчика, который за неделю склепает фиг пойми что, фиг пойми как, главное что будет работать и денег меньше потратит. И продукт запустят через неделю, а не через месяц.
Если бы бизнес думал о том, как сделать лучше в долгосрочной перспективе, то в каждой стране были бы заводы и везде был бы замкнутый цикл производства. Но почему-то бизнес импортирует товар за три копейки и продает в сто раз дороже, нежели производит за 30 копеек и продаёт в 10 раз дороже.
Там, где есть риски, есть и потребность выбирать менее популярные, но более подходящие и менее рискованные (в данном случае под менее рискованным подразумевается больший контроль над технологией и независимость) подходы. Но это тот случай, когда мы говорим про возможные потери бизнеса.
Чем больше разработчиков знающих определенную технологию, тем меньше рисков у бизнеса.
И поэтому написать костыль для известной штуки дешевле и меньше рисков, чем брать малопопулярную технологию.
Вы почему-то используете тезис, что "Давайте сделаем уникальное решение, которое на 100% будет подходить для нас", но при этом забываете, что такое решение придется как поддерживать, так и обучать новые кадры для работы с данным решением. Хотя использовать известную технологию и подогнать её под себя тоже не является бескомпромиссным решением, но всё же в обоих случаях есть компромиссы.
Т.е. если мы говорим про известную технологию, то меньше рисков, что столкнемся со специфичными багами, что в будущем нужно будет долго разбираться в легаси, что новые сотрудники будут долго вкатываться в процесс. Но получаем проблему с зависимостью от мейнтейнеров.
Это же прям в вашей статье написано, что вы выбрали непопулярное решение (Dart) для веба и столкнулись с проблемами в процессе разработки, что в итоге стоило денег компании.
Возможно проблема в том, что вы понимаете под популярностью и известностью - хайп, а не зрелость и распространенность. Поэтому вы неверно толкуете высказывания других пользователей.
В параллельной вселеной много чего сделано по другому. Но это не означает, что всё что хорошо "там", будет так же хорошо и для "здесь".
Вы можете сколь угодно много заниматься научной работой, но только часть из наработок попадёт на рынок и будет жизнеспособными. На исследования выделяется отдельный фонд. Если бизнес будет все деньги тратить только на исследования, то он не будет зарабатывать. Поэтому в бизнесе много типовых задач, для решения которых ты будешь использовать одни и те же инструменты, т.к. такое сочетание позволит удешевить и ускорить разработку, а так же принесет прибыль.
Кто в комментах критикует архитектуру? Её невозможно критиковать, потому что автор не предоставил информации о ней. Максимум что есть, это конкретное решение про мемоизацию. Собственно это решение и критикуется, а точнее подход автора к решению проблемы.
При этом заявления автора, что он только через 6 лет понял на практике эффективность мемоизации, вызывает минимум улыбку.
И что ему предложить? Люди в комментах попытались догадаться что и как у автора сделано, попытались предложить решения на основе своих догадок.
Или вы предлагаете собрать список статей по реакту и скинуть ему ссылки в коммент? Если такие проблемы с мемоизацией, то явно есть проблемы в принципе с теорией. Ну так займитесь тогда этим.
По статье можно сделать вывод о том, что у автора проблема с использованием технологий, а от сюда уже вывод о том, что скорее всего и проблема с проектировкой, т.к. шанс удачной проектировки системы без теории 50% (либо нормально либо нет).
Я занимаюсь фронтенд разработкой на React последние 6 лет (в роли full-stack разработчика). Я знал и слышал, что существуют хуки useCallback и useMemo, которые нужны для оптимизации рендеринга. При этом про их использование я слышал только в теории или на собеседованиях.
Это шутка? Статья была заготовлена для 1 апреля? Или под "последние" вы имеете ввиду что больше не будете разрабатывать на реакте?
Мемоизация уже заметно помогает при рендере больших списков, где нужно прокинуть хотя бы один параметр вниз, в каждый дочерний компонент. Т.е. вы за 6 лет не делали интерактивных приложений, а только условные лендинги?
Но если рассматривать вашу проблему, а не отдельно мемоизацию, то вам сторы не помогут. У вас в принципе проблема с проектировкой системы и использованием технологий. Можете просто почитать статьи аля "React best practice", "React in action".
Если свести мой посыл до пары предложений, то он будет звучать примерно так:
Если у вас нет никаких вводных данных и ограничений, то делайте так, как хотите, так, как больше опыта, т.к. для большинства задач подойдёт множество разных решений, в том числе монолит/микросервис. Придерживайтесь правилам написания кода, они позволят в будущем с меньшей болью переходить что в одну сторону, что в другую. Но в большинстве случаев это не потребуется.
Размышлять глобально над архитектурой стоит только тогда, когда есть какие-то вводные.
Пусть развлекаются как хотят) Особенно если вносят вклад в сообщество.
У меня был период в жизни, когда я пытался добиться идеала от архитектуры. И это был самый непродуктивный период. Оттуда я вынес то, что идеала не существует и нужно идти на компромиссы =)
Если вы думаете, что для успеха достаточно представить/выпустить идею/технологию, то это не так. Поддержка не менее важна. Как самого формата, так и экосистемы.
Библиотека на 600 строчек не требует "большой поддержки". Даже если вас что-то не устроит - вы её легко перепишете за пол дня с нуля.
Я боюсь что подобные темы развернуто больше подходят не для статей, а для более глубоких и больших работ.
Я высказал общее мнение по поводу "Статья на тему архитектуры приложение". Т.е. высказал не конкретно о вашей статье, а о всех статьях на эту тему, включая вашу =)
Ну и я хотел подчеркнуть для "неопределившихся", что не нужно засиживаться над продумыванием. Если у вас продумывание архитектуры превращается в бесконечный квест, то лучше сделать как умеете, просто держите код в хорошем состоянии. Что-то сделав, задеплоив, когда начнут пользоваться люди, тогда вы поймёте в какую сторону стоит развивать систему.
У меня складывается стойкое ощущение, что вы работаете только в своей экосистеме и не работаете в реальном мире. Вообщем какая-то оторванность от реальности.
Аналогия верная, вы сами назначили себя экспертом, сами решили что имеете право выносить решение "проф непригодность" будто судья.
Мне в таких статьях не нравится то, что они дают только поверхностное представление о подходах.
Проблема не в авторах и не в статьях. Проблема в том, что такие темы можно понять только на практике. Если изучать по теории, то придется изучать множество чужих практик. И это всё займет не мало времени, и не даст того, что дадут свои набитые шишки.
Т.е. для незнающих это даст только поверхностные знания, для знающих вспомнят теорию.
Это на словах может быть легко развернуть кластер с микросервисами, либо наоборот, использовать эффективно все 64 ядра. Но по факту, знающему человеку нет особой разницы, 16 машин по 4 ядра, или одна на 64. Есть задача, есть ресурсы, есть существующая инфра. И уже от вводных начинаешь скакать и придумывать решение на компромиссах. Я не говорю что можно выполнить любую задачу из любых вводных, Я говорю о том, что большинство задач можно решить разными способами и построить разные архитектуры.
Точно так же и в выборе монолит/микросервис. Если соблюдать простой принцип разделения ответственности, то в 90%+ случаев этого будет достаточно для выделения отдельных БЛ в сервисы.
JSON тут действительно ни при чем. В JSON нет никаких проблем с длинными целыми и датами, как и в XML (в котором их можно на лету сериализовать еще). Проблема в JS.
Возьмите любой нормальный язык, который поддерживает целые неограниченной длины — и все в порядке. Или (как протобуфы) — напишите свою библиотеку, которая будет на лету сериализовать в строки — и даже JS справится.
Если ваша реализация отличается от спецификации, то не удивляйтесь потом сюрпризам во время работы.
Всегда или только когда мы не уходим дальше пары вложенности? Даже хак с табуляцией вместо пробелов не сработал. Вы же знаете почему многие выбирают пробелы вместо табов? Как раз из-за вашего пункта про читаемость. Табы везде по разному рендерятся.
Скрытый текст
Я перешел в репы в вашей статьи, у вас там больше контрибьюта, чем в 2 языках и одной IDE. (Возможно вы забыли в гите замаскироваться при коммите).
Вы видимо живете в своём обособленном мире, раз для вас уровень поддержки внешних зависимостей не является одним из критериев выбора.
Вы на вопрос не ответили. Тянуть в кор - использовать как основу и зацикливаться на технологии, а не использовать её где-то один раз для "потыкать, работает, пусть будет".
Был один персонаж, он делил людей на тварей дрожащих и право имеющих. Ознакомьтесь, чтобы не повторить судьбу.
Я устал читать вашу статью про Tree, там воды, надменности и бахвальства больше, чем полезной информации. Уж другие не хочется изучать.
Ваш комментарий только подтверждает вашу зашоренность.
Я нигде в ветке не защищал и не продвигал реакт. Но ваша зашоренность не позволят вам объективно участвовать в дискуссии и воспринимать тезисы других людей.
Откуда такие выводы?
Человек спросил о работе компаний с вузами для привлечения кадров, Я написал, что такая работа проводится в т.ч. через ппс.
У вас явно проблемы с коммуникацией, поэтому не понимаете почему везде есть компромиссы, в т.ч. в разработке. Да, в программировании компромиссов почти нет, но мы говорим про разработку, а не про научный подход.
Мне вас в некотором смысле жаль, т.к. явно знания есть, но вы не можете их реализовать из-за зашоренности.
Как много примеров компаний вы знаете которые закрылись из-за плохого фронта?
Если следовать вашей статье, то нужно ставить условия бизнесу, а не искать компромиссы.
Но если вы так будете делать, то бизнес найдет более подходящего разработчика, который за неделю склепает фиг пойми что, фиг пойми как, главное что будет работать и денег меньше потратит. И продукт запустят через неделю, а не через месяц.
Если бы бизнес думал о том, как сделать лучше в долгосрочной перспективе, то в каждой стране были бы заводы и везде был бы замкнутый цикл производства. Но почему-то бизнес импортирует товар за три копейки и продает в сто раз дороже, нежели производит за 30 копеек и продаёт в 10 раз дороже.
Там, где есть риски, есть и потребность выбирать менее популярные, но более подходящие и менее рискованные (в данном случае под менее рискованным подразумевается больший контроль над технологией и независимость) подходы. Но это тот случай, когда мы говорим про возможные потери бизнеса.
Чем больше разработчиков знающих определенную технологию, тем меньше рисков у бизнеса.
И поэтому написать костыль для известной штуки дешевле и меньше рисков, чем брать малопопулярную технологию.
Вы почему-то используете тезис, что "Давайте сделаем уникальное решение, которое на 100% будет подходить для нас", но при этом забываете, что такое решение придется как поддерживать, так и обучать новые кадры для работы с данным решением. Хотя использовать известную технологию и подогнать её под себя тоже не является бескомпромиссным решением, но всё же в обоих случаях есть компромиссы.
Т.е. если мы говорим про известную технологию, то меньше рисков, что столкнемся со специфичными багами, что в будущем нужно будет долго разбираться в легаси, что новые сотрудники будут долго вкатываться в процесс. Но получаем проблему с зависимостью от мейнтейнеров.
Это же прям в вашей статье написано, что вы выбрали непопулярное решение (Dart) для веба и столкнулись с проблемами в процессе разработки, что в итоге стоило денег компании.
Возможно проблема в том, что вы понимаете под популярностью и известностью - хайп, а не зрелость и распространенность. Поэтому вы неверно толкуете высказывания других пользователей.
В параллельной вселеной много чего сделано по другому.
Но это не означает, что всё что хорошо "там", будет так же хорошо и для "здесь".
Вы можете сколь угодно много заниматься научной работой, но только часть из наработок попадёт на рынок и будет жизнеспособными.
На исследования выделяется отдельный фонд. Если бизнес будет все деньги тратить только на исследования, то он не будет зарабатывать. Поэтому в бизнесе много типовых задач, для решения которых ты будешь использовать одни и те же инструменты, т.к. такое сочетание позволит удешевить и ускорить разработку, а так же принесет прибыль.
Мне кажется во всех универах преподы имеют контакты с компаниями и поставляют им кандидатов...
По крайней мере в двух разных универах в разных городах я знаю это точно.
Тут нет спора про архитектуру. Чтобы про неё спорить нужно чтобы были какие-то тезисы про архитектуру. А пока что тут только догадки про архитектуру.
Кто в комментах критикует архитектуру?
Её невозможно критиковать, потому что автор не предоставил информации о ней.
Максимум что есть, это конкретное решение про мемоизацию.
Собственно это решение и критикуется, а точнее подход автора к решению проблемы.
При этом заявления автора, что он только через 6 лет понял на практике эффективность мемоизации, вызывает минимум улыбку.
И что ему предложить? Люди в комментах попытались догадаться что и как у автора сделано, попытались предложить решения на основе своих догадок.
Или вы предлагаете собрать список статей по реакту и скинуть ему ссылки в коммент?
Если такие проблемы с мемоизацией, то явно есть проблемы в принципе с теорией.
Ну так займитесь тогда этим.
По статье можно сделать вывод о том, что у автора проблема с использованием технологий, а от сюда уже вывод о том, что скорее всего и проблема с проектировкой, т.к. шанс удачной проектировки системы без теории 50% (либо нормально либо нет).
У вас в статье даже нет информации о профилировании...
"На глаз" это не решение, "на глаз" это костыль.
У вас проблемы с теорией, пробежаться глазами, а тем более бежать от проблемы (ставя минусы комментам и не замечать) не даст вам никакого профита.
Это шутка? Статья была заготовлена для 1 апреля? Или под "последние" вы имеете ввиду что больше не будете разрабатывать на реакте?
Мемоизация уже заметно помогает при рендере больших списков, где нужно прокинуть хотя бы один параметр вниз, в каждый дочерний компонент. Т.е. вы за 6 лет не делали интерактивных приложений, а только условные лендинги?
Я вам могу даже один пример зачем нужна мемоизация показать, но там видно, что новичок писал статью, а не человек с 6 годами опыта. https://habr.com/ru/articles/873044/comments/#comment_27773258
Но если рассматривать вашу проблему, а не отдельно мемоизацию, то вам сторы не помогут. У вас в принципе проблема с проектировкой системы и использованием технологий. Можете просто почитать статьи аля "React best practice", "React in action".
Оно над (или под, в зависимости от десктоп/моб). Т.е. нужно с новой строки, а не выделять текст.
В целом верно, но ещё дополнение =)
Если свести мой посыл до пары предложений, то он будет звучать примерно так:
Если у вас нет никаких вводных данных и ограничений, то делайте так, как хотите, так, как больше опыта, т.к. для большинства задач подойдёт множество разных решений, в том числе монолит/микросервис. Придерживайтесь правилам написания кода, они позволят в будущем с меньшей болью переходить что в одну сторону, что в другую. Но в большинстве случаев это не потребуется.
Размышлять глобально над архитектурой стоит только тогда, когда есть какие-то вводные.
Пусть развлекаются как хотят) Особенно если вносят вклад в сообщество.
У меня был период в жизни, когда я пытался добиться идеала от архитектуры. И это был самый непродуктивный период. Оттуда я вынес то, что идеала не существует и нужно идти на компромиссы =)
Формат это же не только описать спецификацию =)
Если вы думаете, что для успеха достаточно представить/выпустить идею/технологию, то это не так. Поддержка не менее важна. Как самого формата, так и экосистемы.
Данные высказывания довольно инфантильны =)
Я от вас не жду этого =)
Я боюсь что подобные темы развернуто больше подходят не для статей, а для более глубоких и больших работ.
Я высказал общее мнение по поводу "Статья на тему архитектуры приложение". Т.е. высказал не конкретно о вашей статье, а о всех статьях на эту тему, включая вашу =)
Ну и я хотел подчеркнуть для "неопределившихся", что не нужно засиживаться над продумыванием. Если у вас продумывание архитектуры превращается в бесконечный квест, то лучше сделать как умеете, просто держите код в хорошем состоянии. Что-то сделав, задеплоив, когда начнут пользоваться люди, тогда вы поймёте в какую сторону стоит развивать систему.
Мы вроде про формат говорим, а не про библиотеку.
У меня складывается стойкое ощущение, что вы работаете только в своей экосистеме и не работаете в реальном мире. Вообщем какая-то оторванность от реальности.
Аналогия верная, вы сами назначили себя экспертом, сами решили что имеете право выносить решение "проф непригодность" будто судья.
Мне в таких статьях не нравится то, что они дают только поверхностное представление о подходах.
Проблема не в авторах и не в статьях. Проблема в том, что такие темы можно понять только на практике. Если изучать по теории, то придется изучать множество чужих практик. И это всё займет не мало времени, и не даст того, что дадут свои набитые шишки.
Т.е. для незнающих это даст только поверхностные знания, для знающих вспомнят теорию.
Это на словах может быть легко развернуть кластер с микросервисами, либо наоборот, использовать эффективно все 64 ядра. Но по факту, знающему человеку нет особой разницы, 16 машин по 4 ядра, или одна на 64. Есть задача, есть ресурсы, есть существующая инфра. И уже от вводных начинаешь скакать и придумывать решение на компромиссах. Я не говорю что можно выполнить любую задачу из любых вводных, Я говорю о том, что большинство задач можно решить разными способами и построить разные архитектуры.
Точно так же и в выборе монолит/микросервис. Если соблюдать простой принцип разделения ответственности, то в 90%+ случаев этого будет достаточно для выделения отдельных БЛ в сервисы.
У вас будто конвейер по выпуску статей запустился. Отдышитесь, осмотритесь =)
А то такими темпами и карму себе загубити.
Если ваша реализация отличается от спецификации, то не удивляйтесь потом сюрпризам во время работы.
https://datatracker.ietf.org/doc/html/rfc8259#section-6
Всегда или только когда мы не уходим дальше пары вложенности? Даже хак с табуляцией вместо пробелов не сработал. Вы же знаете почему многие выбирают пробелы вместо табов? Как раз из-за вашего пункта про читаемость. Табы везде по разному рендерятся.
Скрытый текст
Я перешел в репы в вашей статьи, у вас там больше контрибьюта, чем в 2 языках и одной IDE. (Возможно вы забыли в гите замаскироваться при коммите).
Вы видимо живете в своём обособленном мире, раз для вас уровень поддержки внешних зависимостей не является одним из критериев выбора.
Вы на вопрос не ответили. Тянуть в кор - использовать как основу и зацикливаться на технологии, а не использовать её где-то один раз для "потыкать, работает, пусть будет".
Был один персонаж, он делил людей на тварей дрожащих и право имеющих. Ознакомьтесь, чтобы не повторить судьбу.
Я устал читать вашу статью про Tree, там воды, надменности и бахвальства больше, чем полезной информации. Уж другие не хочется изучать.