На мой взгляд, когда за рулем опытный разработчик, такие хорошо структурированные подходы сами собой появляются) Я помимо похожего подхода еще держу memory bank, и получается вполне качественно :)
Да никакой агрессии, с чего бы вдруг?) Но согласен, спорить бессмысленно, т.к. я отлично знаю JS и отлично знаю все его проблемы, но если Вам ок, то ок :)
Конечно это не просто "раньше было лучше", потому что раньше не было лучше) Все технологии, что сейчас есть основаны на прошлых технологиях, и так или иначе они приходят им на замену как раз решая их проблемы и делая технологию лучше. Тут все просто: если технология реально стоящая, она найдет свое применение, если нет, то сорри) Остается лишь наблюдать, кто знает, к чему ваш проект приведет :)
Да я то не против, но Вы должны понимать, что TypeScript придумали не просто так, и 90% фронтендеров не просто так его используют) Вот когда браузеры получат нативную поддержку TS (а я не уверен, что это произойдет когда-нибудь), тогда и посмотрим. Можно писать на чистом JS, конечно, но если мы с Вами умеем и без проблем пишем, то это не значит что все остальные также будут хорошо писать на нем, т.к. язык с дин. типизацией - что такое себе. И тут дело не в том, что Microsoft захотела отличиться, а в банальной удобности и уменьшении кол-ва багов из-за кривой (имхо) типизации.
Я же говорю: я не против и никаких претензий) Наоборот похвально, что свое что-то делаете, и Вы получили критику не в свой адрес ни в коем случае, а в адрес вашего продукта, который выглядит как возвращение в прошлое (чем по сути и является). Использовать его или нет - дело каждого, вот и всего)
Я понял Вас и ничего против не имею, но лично мое ИМХО - это просто шаг назад, то же самое, что вместо мессенджеров использовать почту) Писать фронт (а тем более бэк) на чистом JS в 2026 такое себе. Чисто мое мнение)
По сути да, так и есть, плюс многие приводят как преимущество то, что можно использовать разные стеки технологий, но такое на самом деле, только если реально много команд и компания большая.
Я не использую монолитную архитектуру в проектах с недавнего времени, но обычно сборка большого монолита была от 5 минут. Тут конечно же не только в скорости сборки дело, а и в других факторах, например как @GBR-613написал ниже)
Вы не до конца поняли, что такое микросервисы и зачем их придумали. Тут дело не в красивой ошибке 500, а в том, что при фиксе этой ошибки не придется пересобирать весь монолит (что долго и больно), можно собрать отдельно место фикса ошибки (микросервис) и быстро его выкатить.
Так serverless это больше фронтенд история)
Прям четкие следы в статье, что нейронкой написана: «почему это работает», «у тебя», «это не бред» 😀
На мой взгляд, когда за рулем опытный разработчик, такие хорошо структурированные подходы сами собой появляются) Я помимо похожего подхода еще держу memory bank, и получается вполне качественно :)
Присоединяюсь к необоснованно отхабренным)
Скоростью разработки, очевидно)
Так смотреть надо, что он делает и не давать тупо allow на все действия)
Да никакой агрессии, с чего бы вдруг?) Но согласен, спорить бессмысленно, т.к. я отлично знаю JS и отлично знаю все его проблемы, но если Вам ок, то ок :)
не совсем понял о чем Вы
не в этом дело, еще раз: TS придумали как раз чтобы решить проблему плохой типизации JS
Я не знаю, знаете ли Вы что-то кроме JS, но попробуйте освоить что-то со строгой типизацией и Вы удивитесь, насколько станет легче)
Конечно это не просто "раньше было лучше", потому что раньше не было лучше) Все технологии, что сейчас есть основаны на прошлых технологиях, и так или иначе они приходят им на замену как раз решая их проблемы и делая технологию лучше. Тут все просто: если технология реально стоящая, она найдет свое применение, если нет, то сорри) Остается лишь наблюдать, кто знает, к чему ваш проект приведет :)
Да я то не против, но Вы должны понимать, что TypeScript придумали не просто так, и 90% фронтендеров не просто так его используют) Вот когда браузеры получат нативную поддержку TS (а я не уверен, что это произойдет когда-нибудь), тогда и посмотрим. Можно писать на чистом JS, конечно, но если мы с Вами умеем и без проблем пишем, то это не значит что все остальные также будут хорошо писать на нем, т.к. язык с дин. типизацией - что такое себе. И тут дело не в том, что Microsoft захотела отличиться, а в банальной удобности и уменьшении кол-ва багов из-за кривой (имхо) типизации.
Я же говорю: я не против и никаких претензий) Наоборот похвально, что свое что-то делаете, и Вы получили критику не в свой адрес ни в коем случае, а в адрес вашего продукта, который выглядит как возвращение в прошлое (чем по сути и является). Использовать его или нет - дело каждого, вот и всего)
Не совсем понял Ваш тейк, мы же не о готовых компонентах говорим а об языке программирования для разработки этих компонентов.
К тому же, для того, что Вы описали есть HMR)
Я понял Вас и ничего против не имею, но лично мое ИМХО - это просто шаг назад, то же самое, что вместо мессенджеров использовать почту) Писать фронт (а тем более бэк) на чистом JS в 2026 такое себе. Чисто мое мнение)
По сути да, так и есть, плюс многие приводят как преимущество то, что можно использовать разные стеки технологий, но такое на самом деле, только если реально много команд и компания большая.
Я не использую монолитную архитектуру в проектах с недавнего времени, но обычно сборка большого монолита была от 5 минут. Тут конечно же не только в скорости сборки дело, а и в других факторах, например как @GBR-613написал ниже)
Вы не до конца поняли, что такое микросервисы и зачем их придумали. Тут дело не в красивой ошибке 500, а в том, что при фиксе этой ошибки не придется пересобирать весь монолит (что долго и больно), можно собрать отдельно место фикса ошибки (микросервис) и быстро его выкатить.
Точно также это приметил)
Да какие 100$, ну ало) Там не в одной подписке дело как бы, про токены не забываем
На Ваньку прода точно не хватит денег)