Я к тому, что и на ангуляре можно нормально делать приложения.
Тут главное вовремя понять, что без ангуляра могло бы быть всё гораздо лучше. Вот скажем на хабре уже довольно давно пишут ребята из Тинькофф, делающие Taiga UI. Пишут они замечательные вещи. Но каждый раз читая их, я не могу отделаться от мысли, что то, что они пишут — где-то наполовину или даже больше борьба с ангуляром (в которой они мужественно победили ангуляр).
ну и тут тоже ошибка, как-бы. redux-saga не решает проблемы, созданные redux. redux-saga решает проблемы, которые не решил redux.
Я вас, пожалуй, тоже поправлю: redux-saga не решает проблемы, созданные redux, не решает проблемы, которые не решил redux, а решает проблемы, созданные им самим.
Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот.
Именно ради этого и нужна гибкость. Писать простой код квадратно-гнездовым методом попросту невозможно, квадратно-гнездовым методом можно писать исключительно квадратно-гнездовой код.
В редчайших случаях вы можете точно попасть в ту прикладную область и в проект такого размера, при которых выбранный фреймворк позволит вам писать простой код без больших отрицательных эффектов. Во всех остальных — вы получите всё того же франкенштейна, с которым рано или поздно никто не захочет работать.
Строгие фреймворки и индустриальные стандарты позволяют этого достичь.
Ахахахах.
Как-то раз меня со слезами в глазах уговаривали идти переводить проект с одного "строгого фреймворка" по имени AngularJS на другой "строгий фреймворк" по имени Angular2, строго по индустриальным стандартам™, сиречь официальным гайдам по миграции. Правда, денег особо дать не могли, вместо этого живописуя трагическую историю о том, что те, кто идут за предлагаемые деньги (люди без особого опыта) — тупо не справляются, а кто бы справился — не идёт, денег трагически мало.
Это всё видимо от легкости поддержки происходит, не иначе.
ЗЫ: Вообще, у меня уже много лет как есть такая "народная примета": те, кто много говорят о легкости поддержки и индустриальных стандартах — как раз живут на самых высоких нагромождениях кривоватого кода, просто им повезло никогда не попадать под воздействия, которые бы всё это обрушили. Или у них есть сложившийся кружок B2B, который просто вынужден жрать что дают, каким бы кривым оно не было, или у них настолько элементарнейшее B2C, что даже и кратный перерасход ресурсов на разработку и запуски этого на компах клиентов — не замечается, в конце концов никому нет дела до кривоты проекта, пока он работает и приносит деньги.
Я больше 10 лет во фронте. Всё это время я работал на крупный энтерпрайс, никогда не занимался сайтиками или мелкими проектами.
Я тоже.
Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%.
Я брал и делал. Что дальше?
И это был даже не реакт-ангуляр-вью, а просто нормальный выбор технологий "по месту" для задачи. С решением всех вопросов по интеграции в остальную часть проекта, разумеется.
И да, в нашу контору приходили адепты vue, им дали картбланш и повелись на их убеждения что они напишут большую информационную систему за 2 месяца
Слова "большая информационная система" прямо таки вопят о том, что проблема в данном случае была не во фронтах. Я тоже видел немало проектов, где главной, основной, и практически единственной проблемой было отсутствие понимания, что же в итоге хочется получить. Либо отсутствие способностей разложить это понимание в приемлемую для исполнителей форму. А далее на фронтах всего лишь происходит классическое "нет ТЗ — результат хз".
И чем больше проект, тем вероятность того, что все полимеры на нем будут просраны на уровне организаторов (даже и не аналитиков) всё больше приближается к единице.
Проблема свободно в том, что каждый городит как хочет, и переход между проектами с такой свободой становится все сложнее и сложнее.
А проблема несвободно в том, что все пишут какое-то унылое говно, тратя на это кратно больше времени, чем могли бы, взяв реально удобные технологии. И в итоге всё равно получают здоровое раздутое нечто, которое надо еще отдельно причесывать и утрясать за еще дополнительные расходы времени и денег. Зато переходить между проектами просто, агась.
Вся тимлидошная рукоплещет — народ можно между проектами кидать как угодно, никакого проектного онбординга, везде одно и то же квадратно-гнездовое. А что люди пишут неделями то, что даже в голом VanillaJS можно было б сделать за пару дней — так это наоборот прекрасно, чем дольше всё идёт, тем больше тимлидам зряплаты зряплатят!
О чем же? О том, что их страну безальтернативно распилили на части две фундаментально превосходящие силы, и что сопротивлялись бы они или нет военными методами — это не изменило бы примерно ничего?
А сфигали в хибернейте POJO? Откуда тогда взялось дополнительное требование к no-arguments constructor? Или тут POJO, тут не POJO, тут рыбу заворачивали?
Все эти дополнительные требования — это и есть описание интерфейса.
Я снова спросил окей, но этим УЖЕ занимается ublock. Он же уже фильтрует загружаемые ресурсы по паттернам, а еще и контент вырезает лишний.
Во-первых, так было не совсем всегда ^_^
В относительно недавние времена ublock умел в крайнем случае не выполнять, загрузив. Теперь уже умеет как угодно, но блочить скрипты через UI всё так же не умеет (а noscript да), т.е. на каждый случай надо пойти и руками вписать новый фильтр.
Во-вторых, noscript легко работает в парадигме белого списка (блочить всё, кроме), а в ublock настраивать белый список — нуууу, удачи. Удобство этого такое себе.
Правда, для ререндеринга конкретного компонента есть detectChanges()
Ну так это всё равно all or nothing, просто вручную. Я к тому, что в 2022 году уже много что умеет (Svelte и т.д.) в точечные локальные изменения DOM именно в местах привязки данных.
А если не затруднит, не могли бы привести примеров, какие у вас были проблемы с DI, когда было больно?
Да в общем-то любые поломки в ангулярских модулях (и DI, соответственно) всегда болезненны, в основном потому, что примерно никогда не могут показать вменяемое сообщение об ошибке, а не просто упасть с каким-то там стектрейсом.
Ну и конечно во всех нетривиальных случаях падает оно только в рантайме, а не при транспиляции. Хоть и тайпскрипт вроде как везде.
Я совсем не понимаю, с чем вы всё еще пытаетесь спорить.
Но объекту про само наличие этого маппинга знать не надо ровным счётом ничего.
Объекту всегда (включая эти ваши хибернейты) нужно удовлетворять критериям пригодности к использованию в маппере.
"Знать" не нужно, нет. Иметь совместимый с маппером интерфейс — да.
Это тянет на огромнейшую статью, которую я конечно же не буду писать (сложно и мало толку).
Но если очень-очень сжато, то — ангуляр катастрофически не успевает за эволюцией техстека фронта. В нем полно прекрасных (на момент их появления) идей, которые на 2022 страшно неудобны в их ангулярской инкарнации, от собственного нескучного механизма DI, который нормальный только когда работает, а вот проблемы в нем чинить — полный ад. До вещей типа рендеринга компонентов по принципу all or nothing, который на текущий год уже архаичен.
Ну и отдельные лучи добра за фиксацию версий тайпскрипта сверху и снизу. Все люди, которые по любым причинам вынуждены работать со старым ангуляром (а мир кровавого энтерпрайза может не обновляться годами), вынуждены так же и работать с устаревшим тайпскриптом.
Я б даже вместе с вами посмеялся, если б в данный момент не работал бы вынужденно с ангулярским стеком четырехлетней давности.
Но поскольку таки работаю, то мне не смешно.
Затем, что через стандартный функционал браузера вы не сможете включить JS на habr.com, отключив его при этом для скрипта трекера, загруженного с google-analytics.com
У людей не просто "рефлексия" (она много у кого есть), а рекурсивная саморефлексия (способность осознавать рефлексию и размышлять над ней, и так далее, в несколько слоев глубины как минимум).
Универсальное решение для персистенции вообще всего, очевидно, невозможно. За исключением случаев, когда необходимые для этого механизмы не будут обеспечены внешним миром (т.е. средой выполнения, например). Во всех остальных случаях — вам придётся таки договариваться о том, что у вас там будут за объекты. Даже если таковые договоренности достаточно простые.
PS: даже и в яве с её безусловной рефлексией нельзя персистировать что угодно.
В этом случае объекту всего лишь достаточно удовлетворять определенному интерфейсу. Т.е. в яве быть Serializable, а в терминах нашего разговора — не иметь приватных полей, или не хранить там ничего относящегося к состоянию.
И это опять же выбор объекта, быть ли ему таким или эдаким, вы не можете просто так проигнорировать все слои абстракции под объектом, заявив, что вы хотите сделать что-то такое, что "всего лишь инфраструктурная деталь". Объекту лучше знать, можно ли над ним совершить такое действие, или таки нет. Игнорируя абстракции и их неизбежные протечки, вы так завтра начнете писать /dev/urandom в БД до исчерпания потока, да еще и будете возмущаться, что у вас с этой деятельностью что-то пошло не так.
как, скажем, позволяет сделать, пусть с определенными неудобствами и оговорками, Reflection в Java
Рефлексия никогда не является вычислительно бесплатной, и если она мне не нужна — я предпочту её не иметь вообще, чем иметь всегда, и не пользоваться (ява, да).
PS: Да и вообще говоря, дело не в приватности — ваш пример про сериализацию уже требует от объекта намного более детального и конкретного контракта, чем просто "не пользуйтесь #" (тут и по чтению полей будет много соображений, и по записи — еще больше). Так что вы сильно лукавите, когда ставите этот случай в упрек яваскриптовым приватным полям.
Информация из Вирта передаётся с помощью управляемого коллапса множества волновых функций внутри мозга
А границу по мозгу вы взяли потому, что вам так нравится? Информация о всей вселенной передаётся с помощью управляемного коллапса множества волновых функций в, собственно, всей вселенной. И управляю всем этим я. Оспорьте.
Особенно с js-овским #private, об использовании которого надо миллион раз подумать, поскольку сериализовать такой объект с сохранением его внутреннего состояния просто невозможно.
Это вполне нормально, что вопрос о возможности сериализации того или иного объекта должен решаться с участием этого объекта. А не то, что внешние силы чего-то там сериализуют как им удобно.
Тут главное вовремя понять, что без ангуляра могло бы быть всё гораздо лучше. Вот скажем на хабре уже довольно давно пишут ребята из Тинькофф, делающие Taiga UI. Пишут они замечательные вещи. Но каждый раз читая их, я не могу отделаться от мысли, что то, что они пишут — где-то наполовину или даже больше борьба с ангуляром (в которой они мужественно победили ангуляр).
Я вас, пожалуй, тоже поправлю: redux-saga не решает проблемы, созданные redux, не решает проблемы, которые не решил redux, а решает проблемы, созданные им самим.
Именно ради этого и нужна гибкость. Писать простой код квадратно-гнездовым методом попросту невозможно, квадратно-гнездовым методом можно писать исключительно квадратно-гнездовой код.
В редчайших случаях вы можете точно попасть в ту прикладную область и в проект такого размера, при которых выбранный фреймворк позволит вам писать простой код без больших отрицательных эффектов. Во всех остальных — вы получите всё того же франкенштейна, с которым рано или поздно никто не захочет работать.
Ахахахах.
Как-то раз меня со слезами в глазах уговаривали идти переводить проект с одного "строгого фреймворка" по имени AngularJS на другой "строгий фреймворк" по имени Angular2, строго по индустриальным стандартам™, сиречь официальным гайдам по миграции. Правда, денег особо дать не могли, вместо этого живописуя трагическую историю о том, что те, кто идут за предлагаемые деньги (люди без особого опыта) — тупо не справляются, а кто бы справился — не идёт, денег трагически мало.
Это всё видимо от легкости поддержки происходит, не иначе.
ЗЫ: Вообще, у меня уже много лет как есть такая "народная примета": те, кто много говорят о легкости поддержки и индустриальных стандартах — как раз живут на самых высоких нагромождениях кривоватого кода, просто им повезло никогда не попадать под воздействия, которые бы всё это обрушили. Или у них есть сложившийся кружок B2B, который просто вынужден жрать что дают, каким бы кривым оно не было, или у них настолько элементарнейшее B2C, что даже и кратный перерасход ресурсов на разработку и запуски этого на компах клиентов — не замечается, в конце концов никому нет дела до кривоты проекта, пока он работает и приносит деньги.
Я тоже.
Я брал и делал. Что дальше?
И это был даже не реакт-ангуляр-вью, а просто нормальный выбор технологий "по месту" для задачи. С решением всех вопросов по интеграции в остальную часть проекта, разумеется.
Слова "большая информационная система" прямо таки вопят о том, что проблема в данном случае была не во фронтах. Я тоже видел немало проектов, где главной, основной, и практически единственной проблемой было отсутствие понимания, что же в итоге хочется получить. Либо отсутствие способностей разложить это понимание в приемлемую для исполнителей форму. А далее на фронтах всего лишь происходит классическое "нет ТЗ — результат хз".
И чем больше проект, тем вероятность того, что все полимеры на нем будут просраны на уровне организаторов (даже и не аналитиков) всё больше приближается к единице.
А проблема несвободно в том, что все пишут какое-то унылое говно, тратя на это кратно больше времени, чем могли бы, взяв реально удобные технологии. И в итоге всё равно получают здоровое раздутое нечто, которое надо еще отдельно причесывать и утрясать за еще дополнительные расходы времени и денег. Зато переходить между проектами просто, агась.
Вся тимлидошная рукоплещет — народ можно между проектами кидать как угодно, никакого проектного онбординга, везде одно и то же квадратно-гнездовое. А что люди пишут неделями то, что даже в голом VanillaJS можно было б сделать за пару дней — так это наоборот прекрасно, чем дольше всё идёт, тем больше тимлидам зряплаты зряплатят!
О чем же? О том, что их страну безальтернативно распилили на части две фундаментально превосходящие силы, и что сопротивлялись бы они или нет военными методами — это не изменило бы примерно ничего?
А сфигали в хибернейте POJO? Откуда тогда взялось дополнительное требование к no-arguments constructor? Или тут POJO, тут не POJO, тут рыбу заворачивали?
Все эти дополнительные требования — это и есть описание интерфейса.
Во-первых, так было не совсем всегда ^_^
В относительно недавние времена ublock умел в крайнем случае не выполнять, загрузив. Теперь уже умеет как угодно, но блочить скрипты через UI всё так же не умеет (а noscript да), т.е. на каждый случай надо пойти и руками вписать новый фильтр.
Во-вторых, noscript легко работает в парадигме белого списка (блочить всё, кроме), а в ublock настраивать белый список — нуууу, удачи. Удобство этого такое себе.
Ну так это всё равно all or nothing, просто вручную. Я к тому, что в 2022 году уже много что умеет (Svelte и т.д.) в точечные локальные изменения DOM именно в местах привязки данных.
Да в общем-то любые поломки в ангулярских модулях (и DI, соответственно) всегда болезненны, в основном потому, что примерно никогда не могут показать вменяемое сообщение об ошибке, а не просто упасть с каким-то там стектрейсом.
Ну и конечно во всех нетривиальных случаях падает оно только в рантайме, а не при транспиляции. Хоть и тайпскрипт вроде как везде.
Я совсем не понимаю, с чем вы всё еще пытаетесь спорить.
Объекту всегда (включая эти ваши хибернейты) нужно удовлетворять критериям пригодности к использованию в маппере.
"Знать" не нужно, нет. Иметь совместимый с маппером интерфейс — да.
Это тянет на огромнейшую статью, которую я конечно же не буду писать (сложно и мало толку).
Но если очень-очень сжато, то — ангуляр катастрофически не успевает за эволюцией техстека фронта. В нем полно прекрасных (на момент их появления) идей, которые на 2022 страшно неудобны в их ангулярской инкарнации, от собственного нескучного механизма DI, который нормальный только когда работает, а вот проблемы в нем чинить — полный ад. До вещей типа рендеринга компонентов по принципу all or nothing, который на текущий год уже архаичен.
Ну и отдельные лучи добра за фиксацию версий тайпскрипта сверху и снизу. Все люди, которые по любым причинам вынуждены работать со старым ангуляром (а мир кровавого энтерпрайза может не обновляться годами), вынуждены так же и работать с устаревшим тайпскриптом.
Я б даже вместе с вами посмеялся, если б в данный момент не работал бы вынужденно с ангулярским стеком четырехлетней давности.
Но поскольку таки работаю, то мне не смешно.
Самый быстрый фреймворк на рынке — VanillaJS. А в нем никакого батчинга нет абсолютно.
Затем, что через стандартный функционал браузера вы не сможете включить JS на habr.com, отключив его при этом для скрипта трекера, загруженного с google-analytics.com
У людей не просто "рефлексия" (она много у кого есть), а рекурсивная саморефлексия (способность осознавать рефлексию и размышлять над ней, и так далее, в несколько слоев глубины как минимум).
Универсальное решение для персистенции вообще всего, очевидно, невозможно. За исключением случаев, когда необходимые для этого механизмы не будут обеспечены внешним миром (т.е. средой выполнения, например). Во всех остальных случаях — вам придётся таки договариваться о том, что у вас там будут за объекты. Даже если таковые договоренности достаточно простые.
PS: даже и в яве с её безусловной рефлексией нельзя персистировать что угодно.
В этом случае объекту всего лишь достаточно удовлетворять определенному интерфейсу. Т.е. в яве быть Serializable, а в терминах нашего разговора — не иметь приватных полей, или не хранить там ничего относящегося к состоянию.
И это опять же выбор объекта, быть ли ему таким или эдаким, вы не можете просто так проигнорировать все слои абстракции под объектом, заявив, что вы хотите сделать что-то такое, что "всего лишь инфраструктурная деталь". Объекту лучше знать, можно ли над ним совершить такое действие, или таки нет. Игнорируя абстракции и их неизбежные протечки, вы так завтра начнете писать /dev/urandom в БД до исчерпания потока, да еще и будете возмущаться, что у вас с этой деятельностью что-то пошло не так.
Рефлексия никогда не является вычислительно бесплатной, и если она мне не нужна — я предпочту её не иметь вообще, чем иметь всегда, и не пользоваться (ява, да).
PS: Да и вообще говоря, дело не в приватности — ваш пример про сериализацию уже требует от объекта намного более детального и конкретного контракта, чем просто "не пользуйтесь #" (тут и по чтению полей будет много соображений, и по записи — еще больше). Так что вы сильно лукавите, когда ставите этот случай в упрек яваскриптовым приватным полям.
Что "это"? Есть душа — живое, нет души — мертвое? Так что такое душа-то? Разница между живым и мертвым? Это рекурсивное объяснение.
Это всё никак не отличается от солипсизма.
А границу по мозгу вы взяли потому, что вам так нравится? Информация о всей вселенной передаётся с помощью управляемного коллапса множества волновых функций в, собственно, всей вселенной. И управляю всем этим я. Оспорьте.
Это вполне нормально, что вопрос о возможности сериализации того или иного объекта должен решаться с участием этого объекта. А не то, что внешние силы чего-то там сериализуют как им удобно.