С точки зрения реализации ребята в Vue, Angular и Svelte действительно проделали большую работу
Если нужно, что бы работу проделали за тебя, можно взять Mobx, и получится то же самое. А плюс тут в том, что есть широкий выбор
логику проекта, скажем на Vue, можно спокойно перенести на Svelte
Смелое заявление, я бы посмотрел, как легко получится мигрировать средний проект на Vue на ангуляр
С точки зрения того, как с этим работать — очень субъективно, лично мне после разных mvvm решений интерфейс реакта кажется максимально удобным и обоснованным.
Что вообще делает реакт? абстрагирует меня от работы с DOM. И да, это всё, что мне нужно от UI фреймворка. А состоянием я предпочитаю управлять или через свои решения, или через фреймворки для работы с состоянием.
Можно всю жизнь писать на встроенном MVVM, в том же 500 лет назад изобретенный WPF. Лично моя практика показывает, когда ты не думаешь о работе с сотоянием — ты работаешь с ним хреново. И архитектура твоего приложения от этого страдает. Появляется куча неявных связей в виде подписок на ивенты, которые никак не отследишь, просто глядя на кодовую базу. Только через дебаг, и то с кучей проблем.
В этом смысле, реакт с его четко детерминированной парадигмой — компонент отображает входные данные на пользовательский интерфейс — глоток свежего воздуха.
Это кстати отлично подходит для функционального подхода к программированию. Что, по-моему, определяющий плюс.
Нет, надо было нагородить своих стандартов и откатить веб на 20 лет назад, и пиарить этот подход среди людей, которые не знают другого
А это просто чушь. Даже не знаю, что тут можно сказать. На полном серьёзе обвинить добрую половину фронтенд инженеров мира (включая техлидов, синьоров и т.д.) в том, что пиар акция убедила их использовать дерьмовую технологию, а лично вы прекрасно видите, как они все ошибаются — человеку с таким самомнением не стоит тратить время на разъяснение очевидной истины всяким тупицам с хабра. Уверен, есть задачи и поважнее
но по хорошему такой задачи вообще не должно возникать, как её не возникает во Vue, Angular или Svelte
как раз потому, что они её сделали за тебя.
реакт даёт односторонню привязку данных из коробки, предлагая тебе самому решить проблему обратной привязки. Другие фреймворки дают двухсторонюю, и ты об этом не думаешь.
В целом, на вкус и цвет. Какой бы фреймворк у тебя ни был, тебе всегда нужно объяснить ему, какие данные он должен отображать, где ему их брать, и как ему понять, что они обновились, и ему нужно переотразить их заново. Как бы, если ты не говоришь об этой проблеме — это не значит, что у тебя её нет. Если тебе поставляют вместе с фреймворком имплементацию МВВМ или любого другого МВx, ты думаешь об этом меньше. Но я бы не сказал, что это хорошо
Ребята, создатели React, это не ваше дело определять что можно, а что нельзя, это зависит от структуры данных, требований к программе и в разных случаях может быть разным.
Вот они и не определили. Сам реакт не управляет состоянием фронтенд приложения, он даёт вам апи, что бы вы могли управлять состоянием конкретного компонента. Как бы, ничего не мешает использовать любой подход. Можно мввм, можно флакс, можно мвц, можно своё что-то придумать.
На деле, навязывается скорее редакс или мобикс, но навязывается он не реактом, а сообществом
В этом смысле. реакт один из лучших решений из ui фреймворков вообще, не только в вебе. Все остальные, с которыми я работал, навязывали парадигму работы с данными (например wpf навязывает MVVM)
Да, а потом ты садишься писать пет проект, с беком на java и спринге, и фронтом на реакте, и поражаешься, насколько на беке все отсталое. То что на фронте автоматизируется за пол минуты, в старой джаве не автоматизируется вообще никак, или автоматизируется с помощью кодогенерации в связке с плагинами к IDE. Ну хрен знает, что выгодно бизнесу, но разработчику точно выгодно переходить на новые инструменты
Ну, на самом деле не всегда. Хватает позиций, когда компания ищет конкретно рок звезду, и платить будут, сколько попросишь. Ну, после того, как отберут тебя из сотни кандидатов. Всё таки рынок у разработчков сейчас шикарный. У меня лично были кейсы, когда вакансия была на фултайм, я проходил собес, а потом требовал ремоут — и соглашались
То есть автоматизировать можно не только рефлексией?
Я бы не назвал кодогенерацию (тем более такую) автоматизацией процесса. Она автоматизирует только набор кода.
Вот в java например есть автоматизации разные, типа
@ constructor
вешаешь на класс, и у него генерится конструктор, который ты в кодовой базе не видишь. По-моему — адский костыль, но лучше чем ничего.
Мои познания в синтаксисе хаскеля оставляют желать лучшего, но если я правильно понял
type List<T> = null | { Cons: List<T> }
Тут структурная типизация мне не мешает.
В классической структурной типизации у вас нет имён для типов.
Есть шанс, что в typescript она неклассическая, но тут есть имена для типов. А структурной она считается, потому что при сравнении типов несовпадение имён не имеет значения
const fn = (n: number) => {...}
const sample = fn('3'); // вот тут тс меня отругает
const sample = fn('3' as any);
// вот это он сожрёт, и во время выполнения скастит '3' к 3
Если нужно, что бы работу проделали за тебя, можно взять Mobx, и получится то же самое. А плюс тут в том, что есть широкий выбор
Смелое заявление, я бы посмотрел, как легко получится мигрировать средний проект на Vue на ангуляр
С точки зрения того, как с этим работать — очень субъективно, лично мне после разных mvvm решений интерфейс реакта кажется максимально удобным и обоснованным.
Что вообще делает реакт? абстрагирует меня от работы с DOM. И да, это всё, что мне нужно от UI фреймворка. А состоянием я предпочитаю управлять или через свои решения, или через фреймворки для работы с состоянием.
Можно всю жизнь писать на встроенном MVVM, в том же 500 лет назад изобретенный WPF. Лично моя практика показывает, когда ты не думаешь о работе с сотоянием — ты работаешь с ним хреново. И архитектура твоего приложения от этого страдает. Появляется куча неявных связей в виде подписок на ивенты, которые никак не отследишь, просто глядя на кодовую базу. Только через дебаг, и то с кучей проблем.
В этом смысле, реакт с его четко детерминированной парадигмой — компонент отображает входные данные на пользовательский интерфейс — глоток свежего воздуха.
Это кстати отлично подходит для функционального подхода к программированию. Что, по-моему, определяющий плюс.
А это просто чушь. Даже не знаю, что тут можно сказать. На полном серьёзе обвинить добрую половину фронтенд инженеров мира (включая техлидов, синьоров и т.д.) в том, что пиар акция убедила их использовать дерьмовую технологию, а лично вы прекрасно видите, как они все ошибаются — человеку с таким самомнением не стоит тратить время на разъяснение очевидной истины всяким тупицам с хабра. Уверен, есть задачи и поважнее
Вот серьёзно, чем они думают?
как раз потому, что они её сделали за тебя.
реакт даёт односторонню привязку данных из коробки, предлагая тебе самому решить проблему обратной привязки. Другие фреймворки дают двухсторонюю, и ты об этом не думаешь.
В целом, на вкус и цвет. Какой бы фреймворк у тебя ни был, тебе всегда нужно объяснить ему, какие данные он должен отображать, где ему их брать, и как ему понять, что они обновились, и ему нужно переотразить их заново. Как бы, если ты не говоришь об этой проблеме — это не значит, что у тебя её нет. Если тебе поставляют вместе с фреймворком имплементацию МВВМ или любого другого МВx, ты думаешь об этом меньше. Но я бы не сказал, что это хорошо
Вот они и не определили. Сам реакт не управляет состоянием фронтенд приложения, он даёт вам апи, что бы вы могли управлять состоянием конкретного компонента. Как бы, ничего не мешает использовать любой подход. Можно мввм, можно флакс, можно мвц, можно своё что-то придумать.
На деле, навязывается скорее редакс или мобикс, но навязывается он не реактом, а сообществом
В этом смысле. реакт один из лучших решений из ui фреймворков вообще, не только в вебе. Все остальные, с которыми я работал, навязывали парадигму работы с данными (например wpf навязывает MVVM)
Я бы не назвал кодогенерацию (тем более такую) автоматизацией процесса. Она автоматизирует только набор кода.
Вот в java например есть автоматизации разные, типа
@ constructor
вешаешь на класс, и у него генерится конструктор, который ты в кодовой базе не видишь. По-моему — адский костыль, но лучше чем ничего.
Минусы подхода тянут на целую статью
если fn делает что-то типа (n: number) => 5-n — то каст будет
причём автоматизировать это можно только рефлексией без каких либо гарантий на этапе компиляции.
В тайпскрипте номинативное поведение всё же можно организовать, и без кучи бойлерплейта.
Но в тайпскрипте нельзя получить рантайм проверку данных на основе типа, и тут уже пишется бойлерплейт.
В идеале, хочется ЯП с номинативными и структурными структурами данных. Я вроде читал, что так сделано в OCaml, но всерьёз рассмотреть руки не доходят
Тут структурная типизация мне не мешает.
Есть шанс, что в typescript она неклассическая, но тут есть имена для типов. А структурной она считается, потому что при сравнении типов несовпадение имён не имеет значения