Рассматриваю варианты разработки фронта. Речь о asp.net.
Первая мысль, что не нужно полностью весь фронт делать на стороне клиента.
По мне коробчный вариант нужен только для офлайн-приложений с собственной навигацей.
Но тогда лучше переписать все в виде стандалон приложухи.
Оптимальным является реализация обычных страниц с богатым интерфейсом.
Появились 3 кандидата достойных.
первые два функциональные.
1. elm
хорош независимым компилятором, простой интеграцией через порты с жс библиотеками типа сигналР.
2. fable (F#)
Позволяет использовать общую библиотеку типов и один ЯП на обеих сторонах.
Смущает, что кроме реализации реактового интерфейса ничего больше не нашел.
3. vue — не требует фп, просто обходит структуру и слушает изменения на всех свойствах.
у меня подозрение, что 3 вариант будет работать намного шустрее.
и вообще есть ли смысл перестраивать весь компонент, если изменился лишь один элемент в списке?
пробовал, смысл только если на F# (fs-bolero).
C# это тот же js. для меня нет проблемы кодить на них одновременно.
А в случае блазора + C# приемуществ — чуть-чуть (ну типа реакт без реакта), а геморой такой, что ой-йо-йой.
Из что серверный, и тем более клиентский.
Здравствуйте, varenikAA, Вы писали:
AA>у меня подозрение, что 3 вариант будет работать намного шустрее. AA>и вообще есть ли смысл перестраивать весь компонент, если изменился лишь один элемент в списке?
в первых 2-х паттерн MVU. его плюс в функции model -> view
не надо заморачиваться за то чтоб при изменении какой-то детали в данных думать как инкрементально точечно обновить view.
ну а минус, да — при изменении одного элемента в списке, view полностью будет перестроено.
инфраструктура смягчает это тк апдэйтит dom в браузере не полностью, а вычисляет оптимальный патч.
то есть тут трэйдоф между — простота поддержания консистентности вью при любых изменениях в модели и затратами на полное построение вью по модели при любом её изменении.
