Comments 504
Я вот одного не понял: почему отказались от классов? Не уж то классы в js так тормозят, что что использование всяких мемо для функций и переменных выходит дешевле
Нет, производительностью самой системы классов на данном этапе для большинства нормально написанных проектов можно пренебречь. Я думаю, что основной причиной послужило желание избавиться от наследования и иерархии классов, которые в ООП создают самый большой объём сложности. За это мы заплатили отсутствием встроенного стейта и необходимостью использовать хуки, соблюдать правила хуков, иметь ту самую неочевидную последовательность исполнения.
Лично я не знаю одного идеального способа разработки, я писал свои проекты очень по-разному, и везде есть плюсы и минусы. Большинство программ стремится либо к "морю акторов" (много мелких блоков/функций/компонентов, взаимосвязи которых сложно проследить), либо в "монолит" (одно большое неделимое ядро со сложным, почти неопределённым состоянием и его обвязка). Всегда выбор сводится к тому, предпочитаем мы терпеть объёмную или концептуальную сложность кода. Всегда приходится прикладывать чудовищные усилия, чтобы проект представлял собой прозрачные взаимодействия фиксированного количества акторов, и в процессе роста он всё равно будет стремиться в одно из вышеописанных состояний, какой бы парадигма ни была.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке. Отговорка с "много входов/выходов" тут не очень работает, потому что практически на все ваши фронтовые входы есть соответствующие им входы в API бэка. Этот API нередко очень объёмный, и, как и на фронте, в конечном итоге влияет на некое очень большое состояние (БД), иногда разделённое между компонентами (микросервисами), иногда монолитное. В общем, параллели довольно очевидные, а вот такой боли (и заодно непрерывного мелькания инструментов/библиотек/фреймворков) как на фронте - нет. Причём этого нет вне зависимости от используемого ЯП бэка (может, за исключением ноды, там теоретически должно мелькать примерно то же, что и на фронте, но это результат того, что вы в каком-то смысле "взяли фронт и запустили его на бэке" как раз для того, чтобы не использовать штатные технологии и ЯП бэка - так что это особый кейс и его в текущем контексте обсуждения можно игнорировать).
Идея автора статьи рендерить часть UI на бэке выглядит рабочей, но он тоже не задаётся вопросом "а почему выполнить ровно эту же самую работу на бэке не является настолько же сложным, как на фронте - ведь работа-то в конечном итоге одна и та же".
Лично я предполагаю, что ключевой частью ответа на этот вопрос может быть "дисциплина". На бэке принято соблюдать длинный список ограничений, к которым мы настолько привыкли, что для многих "так было всегда" и они их даже не воспринимают как что-то особенное. Например, на бэке никто не делает свои БД. В смысле, чтобы вот у каждого проекта была своя уникальная БД - такого нет. А ведь когда-то такое было нормой, и я даже эти времена ещё немного застал. Но уже нет. Есть SQL, есть NoSQL, есть message brokers, есть K/V кеши - все они накладывают свои ограничения, но мы всё-равно берём кого-то из них а не пишем своё хранилище состояния приложения. Любые глобальные переменные вызывают нервный тик, даже если это "просто" конфигурация или логгер. Чуть менее очевидные/однозначные примеры включают в себя чистую/гексагональную архитектуру (100% изоляцию бизнес-логики от внешнего мира для простой тестируемости), модульную/микросервисную архитектуру (тут фишка в том, чтобы адекватно спроектировать архитектуру, чтобы размер этих модулей был и не очень мелким и не очень крупным плюс удачно соответствовал границам транзакций и UX-ожиданиям консистентности - для этого придумали стратегические паттерны DDD). Чуть более очевидный пример - на бэке в принципе считается нормальным сначала сделать архитектуру и уделять ей много внимания, даже если это блокирует новые фичи. А ещё - на бэке считается нормальным говорить "НЕТ" в ответ на пожелания бизнеса (это примерно то же, что рекомендует автор статьи в контексте "делайте меньше кнопок"): "нет, это работать не будет", "нет, это слишком сложно реализовать и мы в этом утонем", "нет, это будет архитектурная дыра в безопасности", … много разных "нет". И хотя за некоторыми из них может скрываться "нет, мне лень это делать", сам факт что бэк умеет говорить "нет" имеет значение!
Но уже нет. Есть SQL, есть NoSQL, есть message brokers, есть K/V кеши - все они накладывают свои ограничения, но мы всё-равно берём кого-то из них а не пишем своё хранилище состояния приложения.
Ну я вот пилю своё хранилище, где не нужны ни SQL, ни message brokers, ни K/V кеши, но я вам его не покажу, а то ещё больше забанят личку.
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Да и задачи разные, не будут те же инструменты так удобны на фронте.
Есть вероятность, что задачи просто кажутся разными. Иначе почему перенос рендеринга на бэк обычно всё заметно упрощает? Я допускаю, что ключевое различие между задачами, из-за которого они и воспринимаются "разными", заключается как раз в дисциплине: на фронте задача "сделать что сказал продакт", а на бэке задача "сказать продакту что мы можем и чего не можем сделать".
Собственно, на бэке вполне долго и упорно пытались писать без оной дисциплины, послушно делая всё, что просил бизнес. Как правило, всегда получали в результате "большой комок грязи" и необходимость переписывать проект с нуля. Этот подход просто не работает, особенно если проект изначально сложный или его нужно много лет развивать.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Ну, я говорю о дисциплине "в среднем по индустрии". Отдельные разработчики могут значительно от этого среднего отличаться. Но и как Вы говорите тоже часто бывает: на бэке строгая типизация, линтеры и свои правила/best practices и подходы к разработке/тестированию/отладке/мониторингу, а на фронте всё это совсем другое. И один и тот же человек вполне может писать один проект чисто и соблюдая кучу ограничений и при этом параллельно писать другой на другом языке быстро-грязно.
Иначе почему перенос рендеринга на бэк обычно всё заметно упрощает?
Потому что на беке не надо собирать данные для view из асинхронных запросов api. Либо sql запрос и сразу все взял что нужно, либо какой то относительно удобный orm и работа с моделями. Выглядит это все равно проще чем работа с данными из api методов на фронте
Погодите, а как же redux, который как раз выполняет функцию хранения данных. Мне вообще довольно сложно представить использование реакта без связки с редаксом. А многокомпанентная архитектура позволяет выстраивать кусочки данных в эти компоненты, таким образом мы же вполне можем свести все к очень не большому набору (если вообще не единичному вызову useEffect). Но в целом, я думаю согласится с автором можно. На бэке люди более дисциплинированны, потому что есть компилятор как минимум, который тебе скажет, почему ты чудак на букву м. А есть ещё всякие штуки, которые проверяют codesmells, типа sonarcube-а. В js этого изначально не было. Транспиляция согласно некоторым правилам появилась только вот в angular 2/react-е. А щас есть typescript и возможность писать реактивные компоненты на нем. Использование ts в свою очередь накладывает свои правила. А есть ещё js стандарты и паттерны, которые ты можешь заставить использовать в проекте подключи библиотеку контроля codesmells (забыл как называется). Просто вся эта дисциплина она не сразу же появилась в случае с бэкендом, в том числе умение говорить нет, ну или хотя бы предупреждать, что мы можем, но потом у нас всех будут большие проблемы с поддержкой и вам придётся заплатить крупную сумму за разработку и сопровождение. Упоминание крупных сум иногда действует на бизнес довольно отрезвляюще. Мне кажется это все дело времени. Пока во фронте не устаканится какие-то bestpractises, не наработаются шаблоны проектирования, пока разработчики и инструменты под них подстроятся... Все это требует времени.
Погодите, а как же redux, который как раз выполняет функцию хранения данных. Мне вообще довольно сложно представить использование реакта без связки с редаксом.
Открываю глаза, есть такая штука, называется MobX. И все проблемы у неудобства управления состоянием сразу как рукой снимет.
Не снимет, т.к. в react оно пропихивается через явный костыль и использовать его можно сотней неудачных способов(на которые я насмотрелся до крови из глаз).
Нет, если правильно использовать то всё отлично, но тут та же проблема что и со всем React в целом - излишек свободы говнокода и мутные best practice, зачастую выглядящие как грязные хаки.
А не поделитесь каким-то примером, где описано как правильно и при этом без мутных best practices?
Вопрос без подвоха.
А не поделитесь каким-то примером, где описано как правильно и при этом без мутных best practices? Вопрос без подвоха.
Не обращайте внимания, он описал сугубо индивидуумов, которых природа наградила так сказать альтернативным мышлением. Посмотрите этот коммент - https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28589778
А ещё посмотрите вот это, тут конкретно показано как использовать react + mobx правильно:
https://stackblitz.com/edit/vitejs-vite-dspjoj?file=src%2FApp.tsx&terminal=dev
https://stackblitz.com/edit/vitejs-vite-ffchmx?file=src%2Fpages%2Fmain%2Findex.tsx&terminal=dev
https://stackblitz.com/edit/vitejs-vite-3ajbxs?file=src%2Fpages%2Fmain%2Findex.tsx&terminal=dev
А вот тут показано как надо сконфигурировать MobX чтобы всё было идеально, чтобы был автобатинг по умолчание и возможность там где надо(input и textarea) его отключать и снова включать.
https://stackblitz.com/edit/stackblitz-starters-yefape38?file=src%2FmobxConfig.ts,src%2FApp.tsx
Не снимет
Интересно, у всех снимает, а у вас не снимает?
т.к. в react оно пропихивается через явный костыль
Ага, т.е. хуки и useState это костыль. Понятно)))
и использовать его можно сотней неудачных способов(на которые я насмотрелся до крови из глаз)
Т.е. если вы работали с так сказал разработчиками с особенностями развития, которые умудряются запороть нативный синтаксис
export class MyState {
fetching = false;
items = [];
error = null;
constructor() {
makeAutoObservable(this);
this.fetchItems();
}
fetchItems = async () => {
this.fetching = true;
try {
const response = await apiRequest(`GET /api/v1/items`);
this.items = response.data;
this.error = null;
} catch(e) {
this.error = e.message;
} finally {
this.fetching = false;
}
}
}То, я боюсь представить чтобы было. если бы там был redux или голый реакт, или что угодно другое.
Нет, если правильно использовать то всё отлично
А в чём проблема? Это элементарно, причём by design.
но тут та же проблема что и со всем React в целом - излишек свободы говнокода и мутные best practice, зачастую выглядящие как грязные хаки.
У MobX таких проблем, не надо нести ахинею, он не пропагандирует писать говнокодище, в отличии от redux и ему подобных. Просто посмотрите на код из этого же комментария, это самое типичное и стандартное использование MobX, укажите мне хоть строку говнокода.
Или вот:
export const MyComponent = observer(() => {
const [state] = useState(() => new MyState());
if (state.fetching) return <div>fetching...</div>;
return (
<div>
<button onClick={state.fetchItems}>Load more</button>
{state.items.map(item => <div>{item.title}</div>)}
</div>
)
});А вот типичное и стандартное использование, но уже внутри Реакт компонента у которого есть локальное состояние. Укажите мне хоть строку говнокода.
Состояние гонки при множественных кликах.
Проглатывание ошибки загрузки.
При удалении виджета, загрузка не отменяется, а продолжает висеть.
Много технической копипасты.
Болезненная смена по всему проекту индикаторов загрузки.
Стирание текущих данных на время загрузки.
Нет классов для привязывания стилей.
Нет идентификаторов для привязывания тестов.
Нет возможности настроить текст вообще и локализовать в частности.
Текст "load more" на кнопке не соответствует выполняемой функции (обновление данных).
Нет возможности подменить источник данных вообще и протестировать в изолированном окружении в частности.
Изменение названия одного элемента приводит к ререндеру всего списка.
Перенос элемента из начала в конец или наоборот приводит к ререндеру всего dom дерева.
Загрузка эквивалентных данных приводит к ререндеру всего списка.
В классе MyState сломано наследование.
MyState превентивно загружает данные даже если вьюшке они не понадобятся.
С вас 2к за ревью.
Если интресно, вот тот же самый компонент на $mol, без всех упомянутых проблем:
// Модель
export class $my_state extends $mol_object {
items( fresh?: null ) {
return this.$.$mol_fetch.json( '/api/v1/items' )
}
}- \Композиция
$my_component $mol_list
state $my_state
items => items_data
items? => update?
rows /
<= Update $mol_button
title @ \Update
click? <=> update?
^ items /
<= Item*0 $mol_view sub / <= item_title* \// Поведение
export class $my_component extends $.$my_component {
@ $mol_mem
items() {
return Object.keys( this.items_data() ).map( key => this.items( key )
}
item_title( key: string ) {
return this.items_data()[ key ].title
}
}Плюс тут ещё есть опрятный вид из коробки, но и его можно настроить под себя:
// Стили
$mol_style_define( $my_component, {
gap: $mol_gap.block,
Update: {
color: $mol_theme.accent,
},
Item: {
padding: $mol_gap.text,
},
} )С вас 2к за проектирование и разработку с нуля.
Главная ремарка: примеры упрощены, и отражают именно работу MobX, а не обработку всех corner case) И все ваши пункты не имеют никакого отношения непосредственно к MobX. А вообще Keep It Simple Stupid и будет тебе счастье.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Если использовать Объектное Реактивное Программирование, то никаких проблем с пониманием потоков данных по коду нет вообще. Так что проблема определённо не в гуях, а в инструментах для них не пригодных.
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Я правильнорпонимаю, что вы пробовали ОРП и говорите со знанием дела, а не просто транслируете свои убеждения, основанные на опыте использования иных парадигм?
Про него не знаю, но вот мой плюс тому сообщению был поставлен на основе опыта работы с реактивными библиотеками.
Менять библиотеки, оставаясь в той же парадигме, это как кровати в борделе переставлять, а потом с умным видом заявлять, что нет достойных девушек на свете.
Хватит считать оппонентов идиотами, парадигмы я учу в первую очередь.
Про него не знаю
Продолжайте изучение.
Вы сейчас серьёзно утверждаете, что для изучения парадигмы ОРП я должен знать пробовал ли его @Kerman? А где связь?
Я вертел на болту ОРП, вертел реакт, жаваскрипт и весь веб в целом. Десктопщик я. А для своего сайта сделал ssr и мне за глаза хватает.
На бэке нет гуя.
Это довольно очевидный, напрашивающийся… но, вполне возможно, некорректный ответ.
Я не буду спрашивать в чём принципиальное отличие GUI от TUI и CLI (которые на бэке есть). Я спрошу другое: а как же условный Web 1.0? Ровно тот же HTML+CSS+JS, но рендеринг полностью на бэке - чем это не GUI? И окажется, что отличие тут ровно в том, о чём я писал - в ограничениях и дисциплине. Условно можно считать, что во времена Web 1.0 мы говорили продакту "нет, мы не сделаем SPA, а будем рендерить всё на беке, и страничка у юзера будет постоянно перечитываться". И никаких сопоставимых с текущей ситуацией на фронте сложностей при этом не возникало. (Подсказка: в случае TUI и CLI всё выглядит очень похоже - и там и там есть куча ограничений, которые приходится соблюдать, которые создают кучу неудобств и для пользователей и для разработчиков этих UI, но зато код получается вполне умеренной сложности.)
но рендеринг полностью на бэке
Вот и ответ. Бэк рендерит ровно один стейт, а не следит за связностью какая кнопка тебе таблицу загрузит, а какая в подвал нагадит
О, это вы не застали какой-нибудь ASP, гоняющий весь вью-стейт туда-сюда в каждом запросе.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Я вот эти веб-формы застал. И бардак в них был такой, что реакт на том фоне выглядит шедевром архитектуры.
VCL нормальный гуй был.
Да чего там был — прямо сейчас 3 живых проекта на нем веду.
По соотношению заработок/качество/скорость просто топ до сих пор для определенного вида проектов.
Я, понимаю, что эти три проекта - это не показатель "живости" для индустрии.
Но пример того, что можно брать и успешно использовать.
Похоже на то да. Видимо сама программа становится настолько большой по функционалу, что управлять состоянием gui становится слишком сложно независимо от того какой подход ты используешь...
Оно просто сложное само по себе.
Выход: просто меньше элементов ui для взаимодействия с пользователем) , либо выделять новые отдельные приложения (по образу микросервисов на беке)
Отдельные приложения выделяются, называются микрофронтенды и федерация. И как и с микросервисами - при теоретическом профите особо лучше не становится, разве что слегка и по-началу.:)
А, кстати, почему так?
На бэке от микросервисов лучше всё-таки становится, и значительно. Но для этого нужен хороший архитект, это обязательное условние. (Без него станет хуже, и тоже значительно.) После чего основная сложность остаётся там, где остаются нужны распределённые транзакции/саги в том или ином виде. На фронте транзакций вроде бы нет. Что тогда создаёт сложности в микрофронтендах?
Вон ниже картинка " Dependency Hell in Microservices", с микрофронтами аналогично(но, само собой, с фронтовой приправой сырости и отсутствия устоявшихся практик).
Конечно "хороший архитект" и тут зарешает, но на всех таких не напасёшься.
Одна из общих глобальных проблем человечества, по моему мнению, это "оптимистичные системы", т.е. такие системы, которые рассчитаны на умных, компетентных людей. Это проблема буквально повсюду, не только в программировании, но и во всём вплоть до политики. Эти системы прекрасно выглядят на бумаге, но разваливаются в хлам, как только по ним начинаю работать средние люди(которые, увы, в большинстве своём очень далеки от понятия компетентность).:)
Конечно "хороший архитект" и тут зарешает, но на всех таких не напасёшься.
Это правда, но с этим ничего не поделаешь. Суть микросервисной архитектуры в том, что часть сложности переносится из кода в связи между микросервисами. Это позволяет снизить требования к квалификации разработчиков (которых много) за счёт повышения требований к квалификации архитектов (которых мало). Обычно такой размен бизнесу выгоден. Но только при наличии архитекта, который сможет справиться с повысившейся сложностью лично его работы.
Какие-то проблемы на бэке определённо есть...
Dependency Hell in Microservices:
Зоопарк блоков для построения архитектуры:
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
Сами себе противоречите. Как раз у ноды и будут макароны из кода и мелькание библиотек и фреймворков как и в клиентской части. Так что да, именно язык без полноценного ООП.
Хотя еще проблема в интерактивности. У бэка ее почти нет. Из за этого обычно меньше неопределенности.
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке.
Вон тут с галерки вещают что для бэка существует куча языков на любой вкус и набор задач. А на фронте как был один JS из нетскейп навигатора, так и остался по сей день.
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
Подскажите плиз кто из браузеров понимает TS.
То есть, на чем бы мы не написали фронтовый функционал, в результате он все равно откомпилится в js потому что
как был один JS из нетскейп навигатора, так и остался по сей день
Но несмотря на этот факт я несу какую-то "не очень релевантную" чушь...
Хм.
Ок.
Хорошо.
Как будто на бэке какая-та среда исполнения понимает Java или C#. Максимум — JVM / CLR Bytecode. Я уж не говорю о разработчиках C++ / Go / Rust, которые как-то с набором инструкций AMD64 обходятся. Поддержка языка на уровне браузера нужна только для дебагера, где она вполне себе есть.
Так в этом и смысл, JavaScript - божественный дар, на этих ваших бэках уже десятки языков и фреймворков родились и умерли, от ColdFusion и ASP и до RoR. А в браузере - лучший из языков вселенной, созданный за 7 дней. Аминь
Так проблема же не в молотке, никакой ЯП не решит архитектурную проблему.
Во-о-о, сразу видно, что бэкенд тесно связан со школой сетевых парадигм проектирования.
Священная инкапсуляция и обязателность ее исполнения заложенная в протоколы поведения:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28575664
Я пишу на беке, но иногда нужен фронт. Для меня выбор был сделан уже давно и похоже навсегда - для фронта я использую GWT и только его :) Так что подобные статьи у меня вызывают искренний вопрос - "о чём говорят все эти люди?" :)
Дисциплина у вас есть, ага. У вас есть машинка с известной цпу и оперативкой, вот что у вас есть. Все проблемы в промышленном frontend начинаются когда надо отобразить миллион всего на разных устройствах, появляются сложные паттерны, которые так невзлюбил автор. Все ваши знания о промышленном фронтенте видимо и сидят где-то - ой да там же формочки, можно и на бэке генерить. Когда нужно на 4-м андроиде показывать бесконечную ленту я бы посмотрел как вы бы ее на бэке генерили. Сложность про на которую мы идем в самом начале заложены боль от прошлых решений. .
У вас есть машинка с известной цпу и оперативкой, вот что у вас есть.
Не-а. Не "есть". Мы на бэке её себе искусственно организуем (через контейнеры докер). И делаем это как раз потому, что иначе будет куча лишних сложностей. Это как раз один из тех подходов, о которых я говорил, вместе с фиксированным набором разных типов БД и т.п.
Когда нужно на 4-м андроиде показывать бесконечную ленту
Я не понял, каким боком тут вообще андроид (вроде же веб-фронт обсуждаем). Но для веб-фронта я бесконечную ленту на бэке делал - ничего сложного, микрокод на JS который дозапрашивает ещё кусок страницы когда скроллер приближается к концу и дописывает присланный бэком кусок html в нужный div.
Поздравляю, вы сделали утечку.
Я не понял, каким боком тут вообще андроид
Андроид тут таким боком что наш код должен работать в любом браузере на любом устройстве.
кусок страницы когда скроллер приближается к концу и дописывает присланный бэком кусок html в нужный div
Я и говорю что вы ничего не понимаете в промышленном фронтенде. Этот способ годится для небольших лент аля бложик, который вы вероятно и реализовывали. В реальных приложениях нужен подход с виртуальным скролом, но где вам такое знать, фронт это же про формочки.
Ты просто не понимаешь фронтэнд, чтобы отрисовать один ui элемент приходится запрашивать данные из разных источников, бывает что и из 10, с таблицами это повсеместно, именение в ключевых данных, скажем статус пользователя, влияет на ui элементы по всему приложению, это не похоже на: пришел запрос, о ветил и забыл, правда? Все данные у тебя в памяти, изменение их влияет на логику других, все перепелетено
А когда этот же UI элемент генерирует бэк что, источников данных становится меньше? Чтобы бэк мог ответить и забыть на нём много всего сделано, чтобы данные из этих разных источников попали в нужном виде в ту БД, из которой бэк "просто ответит и забудет". Всё это - вопрос архитектуры, не больше и не меньше. А когда на архитектуру забили, то и получается "всё переплетено". Это не специфика фронта, это специфика разработки без архитектуры, на бэке так тоже умеют делать.
Напиши как найдеш хорошую архитектуру на фронт, я работал на всех 3 топ библиттеках и везде мрак, ангулар лучше всех, и то там переплетение всего и вся, так что пиши, если что
чтобы отрисовать один ui элемент приходится запрашивать данные из разных источников
А что мешает сделать для такого сложного элемента отдельный ендпоинт, который все эти данные будет отдавать?
В вашей вселенной знаний о фронте ничего не мешает. Вот тут реклама с сервиса рекламы, тут данные с сервиса данных, тут юзер ох блин Блэк бокс нельзя хранить там же где данные, ой еще сервис данных? И что надо отображать все асапом? Чтобы то что есть сразу отобразить а медленные ручки отвечали чуть позже, нет, не слышали. Что есть еще ленивая подгрузка и бесконечная лента? Ой бесконечная лента бесконечных лент еще бывает? Ой и в нее надо вставить рекламу которую надо тоже подгрузить? Да, думаю обойдемся одной ручкой!
low coupling and high cohesion
Радует то, что отраслевики начинают задумываться о фундаментальных причинах, обсуждать их.
Я топлю за «структурированную/организованную инкапсуляцию парадигм для разных нужд».
Окей, если нам нужен для разных задач/проектов дифференцированный подход к исполнению парадигм, то давайте это пропишем в некой «Глобальной доктрине парадигм программирования»! Разработкой и поддержкой которой будут заниматься уважаемые представители отрасли в составе Комитета, например. Все протоколировано.
Сам Линус, Интел, академики, и остальные представители производства железа, ОС и конечного ПО будут участниками этого Комитета / Института.
Появилась задача — подумали полгода — выбросили решение на рынок — рынок подстроился. Организовано, обязательно, структурировно.
PS: нет, я не предлагаю вводить тотальную регуляцию, но какой организованный остров решений стремящийся к безопасным и солидным решениям — призываю построить.
Есть большая тройка: производители железа, ОС и конечного ПО, — те кто из гих будут придерживаться этих политик, их ПО и железо будет получать сертификат, и распространяться в соотвествующих «магазинах» со знаком качества.. а остальное — без этого знака и уже на риск покупателя.
Радует то, что отраслевики начинают задумываться о фундаментальных причинах, обсуждать их.
Начинают?! LOL. Они начали когда вас ещё в проекте не было.
Просто люди не учат историю. И история не учит людей, ибо всякая старая глупость предстаёт перед ними в новом свете.
давайте это пропишем в некой «Глобальной доктрине парадигм программирования»!
Откуда вы берётесь такие, любители доктрин?
От туда от куда появилось ПДД, умник (за любителя).
Что-то не нравится— предлагай- критикуй, а не отвлекайте меня своими вопросам в никуда унижая мою моральную установку с утра. Спасибо за внимание.
Или Вы считайте, что мне интересно тут с вами полемикой заниматься? Разжовывать, как ребенку — то-сё-это.
Чо трудно написать: не согласен, такието аргументы!
Нет он блин вынуживает меня с утра огоряаться в своей саркастической манере.
Не нравится идея — чао. Я вас лично не трогал. Лютеранин Вы наш. Почему лютеранин? Я так решили. Вы же тоже меня уже приписали в когорту умалишенных.
Чао. И удачи дальше спорить чей стек лучше.
И не надо мне отвечать. Я лишь подкинул идею.
То же мне, Склифософские тут все собрались, думают что пупы мира. А вы со стороны на индустрию посмотрите, Сеньер-архиктор-пуп-мира.
И грошь вам цена, и всем вашим заявлениям, если у вас дыры в ПО годами сидят.
От туда от куда появилось ПДД
И как появились ПДД, все их выучили наизусть, и все нарушения немедленно кончились и воцарилось благоденствие?
удачи дальше спорить чей стек лучше.
Как будто в "Комитете по доктринам" споров не будет, ага. И с решениями Комитета все будут единогласно согласны, конечно же.
Я вам своми вопросом "в никуда" как бы намекнул, что у вас в голове какая-то детская вера в мудрость Больших Дядь в Комитетах и в магию Незыблемых Директив. Та же благословенная OSI, с которой вы носитесь, нарушается только пыль стоит.
В реальном мире (а не в воображаемом вами) вначале само сообщество разработчиков набивает шишки на реальных задачах (что означает баги!), потом публикует статьи по этим набитым шишкам и по лучшим практикам того, как избегать их набивания. Потом приходят новые люди, которое либо грамотны, но остались неудовлетворены существующими решениями, либо тупо ничего из всего этого написанного этого не читала, но имеет мнение -- и начинает изобретать свои велосипеды, набивая новые шишки.
Вы не предлагаете никаких инженерных решений, решающих реальные проблемы. Вы предлагаете административное ограничение -- обязать всех писать только по директиве. Это никогда не работало, и работать не будет. В списке ["физические ограничения", "технические ограничения", "административные ограничения"], административные -- самые слабые, ибо легко нарушаются/обходятся. Они же -- самые заманчивые для тех, кто не умеет в технические.
И как появились ПДД, все их выучили наизусть, и все нарушения немедленно кончились и воцарилось благоденствие?
Уоа-а-а, конструктив в чат вторгся!
Естественно вы правы, но, — частично.
ПДД — гарантирует безопасное передвижение по дорогам общего пользования, в случае когда пользователи этих самых дорог САМИ же их и исполняют! Логику чуете?
Я про Вам про Ивана, вы мне про Болванов…
То есть сама парадигма вам гарантирует. Но если водители нарушают, то тут уж…
(Пусть не на все 💯, но езжай каждый по правилам, ну процент инцидентов был бы не смешной, а никакой, 0,000 чо-то там в периоде, например.
— надеюсь по этому вопросу замяли споры.
PS: не забывайте, все эти примеры с пдд и ось-ями — это беглые примеры, на которых вы все сильно тормозитесь..
ОДНАКО: именно этт примеры очень показательные в данной полемике.
Повторяю: мы говорим об очень глубоких идеях. Ска, и не мудрено же ж, — проблема просто ГРАНДИОЗНАЯ. Поэтому и решения фундаментальные и очень комплексные, ибо наща современная цивилизация — превратилась в реальный огронмный клмбайн технологий и в скждтсциплинарных взаимозависимостей.
Да эти проблемы стараются не поднимать в паблик — бизнесу не выгодно поднимать на поверхность свою импотенцию. Все ради точек роста на биржа, дед лайны, сырой дырявый отвратительный код повсеместно. выжимают соки из всех отделов ради точек роста (ну и прогресса! Скажите Вы и будете праввы.
Ну и кому это нафиг надо? Мне, пользователю? И вы меня еще обвиняйте в неправильности примера ПДД.
Пдд гарантирует безопасность, если юзер следует, а вы (индустрия) — жалкие рабы бизнеса и дизайнеров с карандашами. Спасибо бизнесу.
ТАК ВОТ — это все мне не нравится. Это все бардак бардаком.
теперь понятно что да!!!! Я мыслю котегориями того самого мальчика мечтателя.
И извините меня, если я нарушил ваши категории мыщления, вот толку об этом спорить. Если вы все равно пдд не напишите, вы даже сопротивляйтесь этому.
то есть вы со сной не об иване говорите, а рассказывайте мне сказки, пдд фуфло.
Боже
В реальном мире (а не в воображаемом вами) вначале само сообщество разработчиков набивает шишки на реальных задачах (что означает баги!), потом публикует статьи по этим набитым шишкам и по лучшим практикам того, как избегать их набивания. Потом приходят новые люди, которое либо грамотны, но остались неудовлетворены существующими решениями, либо тупо ничего из всего этого написанного этого не читала, но имеет мнение -- и начинает изобретать свои велосипеды, набивая новые шишки.
В каком реальном мире? Вы мне рисуете какой-то свой реальный мир. С чего вы взяли, что это истина? В реальном мире, однажды — все ваши разработки зарегулируют. Вопрос какой ход мы этому дадим и какие цели.
У меня цель— прогрессивное развитие нашей Цивилизации.
Вы не предлагаете никаких инженерных решений, решающих реальные проблемы. Вы предлагаете административное ограничение -- обязать всех писать только по директиве. Это никогда не работало, и работать не будет. В списке ["физические ограничения", "технические ограничения", "административные ограничения"], административные -- самые слабые, ибо легко нарушаются/обходятся. Они же -- самые заманчивые для тех, кто не умеет в технические.
Центральная идея направить все усилия в правильное русло. Админ решения были представлены, как ПРИМЕР. Я тоже за свободы, но извините самолетная отрасль полетов — полностью зарегулирована.
Я предлагаю— хорошенчеко сесть т подумать над всем комплексом.
А не обсуждать частные проблемы стеков в уютных чатах. Еще и юзера обвинять — тупой.
ПДД — гарантирует безопасное передвижение по дорогам общего пользования, в случае когда пользователи этих самых дорог САМИ же их и исполняют!
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
У меня цель— прогрессивное развитие нашей Цивилизации.
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Я предлагаю— хорошенчеко сесть т подумать над всем комплексом.
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
самолетная отрасль полетов — полностью зарегулирована.
Вы ошибаетесь насчёт "полностью".
Дисклаймер: стиль моей речи - сумбурный, вечно пишу быстро чтобы не потерять мысль (неврология, не знаю), времени мало вечно, стараюсь как могу. Простите.
Давайте снова свяжем все воедино.
Мы живем в «золотое» время свободного (пока что) интернета. Точно так же, когда-то люди жили на заре автомобиле строения, например. Не было никаких (почти) правил. Не видите аналогию? Ну! Вникните. Ну. Пошевелите анализатором жесче. Копните глубже. Зарегулируют все дет через сто двести.
Заложат точные модели поведения. Да лет сто ПДД строили. И сто лет строить будут еще. Ибо прогресс. Цивилизация внезапно снова ворвалась в чат.
Не видите связи. А вы крутите шестеркнки.
Моя цель видимо — просто поднимать эти темы. Да. Я академик, видимо.
Другой пример. Вы там деретесь ФП или ООП — спросите у Эдисона с Теслой.
Точно та же полемика, война и становление отрасли происходило. И что имеем жесткую, четкую регуляцию, которая не просто жизни спасает, а обеспечивает жизнь цивилизации в 9млрд человек, а не лярд , как в начале двадцатого века.
Какую-то неидеальность ПДД вы пне впихивайте. Какую-то бездарность регуляции? Ненадобность….
Очнитесь — моя цель. Выйдите из чата девелопа, и оглянитесь.
Мы дивем реально в свободные времена интернета. Такие же дикие как на заре электричества и гребанных ПДД… (и ничего— никто вам не запрещает дома соединять батарейки, собирать радио конструкторы, или в гараже ставить мега турбину, но прпвила то есть. Так вот эти правила мы еще не построили. Может начнем уже закладывать зерно ценных смыслов? На будующее. Да че там будущее, давай сецчас требовать! Я не знаю. Нужен совет мудрецов).
Удачи.
Внатуре мечтатель какой-то я ( Визионер. Я хз.
Доброго времени суток и добра!
Я академик, видимо. ... Внатуре мечтатель какой-то я ( Визионер. Я хз.
Если хз, то подскажу более подходящий термин. и, соответственно, название склонности.
Take care.
Я думал я аутист и уменя неврология, но… Вам виднее. Давайте остановимся на мечтатель школьник в вашем реальном мире, о котором Вы выше упоминали.
Вы код когда чистый писать начнете?
Спасибо за новый термин, буду знать. Вот только разница между визионером и ризонером - от любви до ненависти один шаг.
Нет я честно думал, что виду будущее, но оказывается я троль не принимающий участие в беседе.
Хорош ярлыки вешать, и давайте по теме говорить.
И вернемся к нашему ПДД с правилами воздушного сообщения.
1) Вы хотели бы отменить регуляцию в этих сферах? Нужна ли она по сути?
2) я не говорю о регуляции как о кошмаре. Я говорю о системе О разработке:
Систем поведения и взаимодействия между игроками.
До тех пор пока эти системы не будут разаработаны и приняты обязателному исполнению, вы будете спорить об эффективности ФП и ООП (кто лучше)).
Да ежу понятно что обе системы нужны. И как все это организовать в рабочий механизм — и есть задача!
И она будет решена рано или поздно. И будет решаться в неррерывном режиме, ибо мир меняется.
вот так то: это предсказание, а не резонизм или даже визионерство. Я ванга, которая вам предсказыаает.
И негодую я не просто так, не ради троллинга.. А потому что задолбали все эти глюки и баги. Мне банковская аппа показывает что у меня на счету 100 эро, я набираю корзину на 30 эро, подхожу к кассе, бамц — платеж не прошел. Блин бегу разбираться, оказывается внатуре глюк. Я опозорился на кассе, мне пришлось гнать за наличкой домой (я на велике выскочил в магазин на районе печенья купить)..
Мне это надо? Что я как пользователь сделал не так? Ни че го. А вот вопросов к вашему коду дохрилион.
Так какого черта мы обсуждаем бессмвсленные стеки, если вы самоорганизоваться не можете. Определить уровни взаимодействия.
Пустое все рассказываю. Ну извините.
Давайте так. Я от чего отталкиваюсь?
Вы мне это объясните:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28584632
тут вы обсуждайте внутреннюю кухню. Я тут бессилен, ибо не поограммирую, но! У меня как у игрока вопоос — что вам мешает, не достает, что значительно / радикально исправить ситуацию в лучшуу сторону?
Мне лично нравится простота функциональных компонент. Как то понятнее, что-ли. Вот есть функция, которая возвращает компонент и все. Все на виду, в определенной последовательности. С классами весь код получается размазанным, там дефолтные параметры, там Стейт, там загрузка данных, в углу функция отрисовки опять же. Прочесть код класса сложнее кмк.
Вот есть функция Component, которая вызывает ещё функции use*, которые вызывают ещё функции useHook, внутри которых вызываются ещё другие функции useHookN…
Я лет 15 назад был в проекте. Сервер, на Си. Там функции были на несколько страниц, в функциях были запросы к базе и ветвистая логика. Да и сами файлы были на 15к и больше строк. Там черт ногу сломишь. Проект был запущен, большая текучка. Я и сам сбежал от туда. Так вот я к чему.
Ведь такие огромные методы, не значит же, что Си плохой и с С++, с классами получилось бы лучше. Я думаю имели бы громадные классы на 15к строк и методами на три страницы.
Если писать по фэншую, придерживаться clean code. Не писать компоненты на десять страниц и на все случаи жизни, то вполне себе можно обойтись минимумом хуков.
но ведь в классе будет происходит ровно то же самое, только без префиксов use. есть классовый компонент, в нём есть метод Component*, который вызовет в себе метод для загрузки данных(к примеру) и т.д. что изменилось глобально? кроме того, что в случае функциональных компонентов у нас нет привычной возни с контекстом, его потерей, необходимости местами прибивать его гвоздями и прочими весёлыми штуками
Только без префиксов use
Без ограничений React экосистемы (можем ли мы под условиями запускать хуки? Можем ли мы одноразово вызывать сложные вычисления ? Можем, но при помощи хуков, но хуки у нас вызываются на каждом рендере (useMemo, useEffect, useState)
у нас нет привычной возни с контекстом.
Да, тут согласен, только теперь у нас есть возня с хуками
перерисовки реакта т.е. повторный вызов кода скорее всего приводят к дрочеву памяти(а если есть утечки к быстрому ее исчерпанию) и логики, которая может быть написана в конструкторах
С чего бы? Теперь и сейчас умеет переползать компоненты, а с классами это было заметно проще делать и снизило бы нагрузку. Все равно под капотом там самые обычные объекты, только обложенные костылями, чтобы их видно не было.
там рендеринг это вызов функции, результат выполнения которых хранится закешированным, т.е. может содержать ссылки на созданные в процессе объекты. И если такая функция 10 раз все-таки отработала она 10и-кратно повысила нагрузку на ресурсы, это не считая каскадных вызовов по зависимостям. Поэтому там все заворачивается в useMemo и useCallback. А решение аплаить ли новую верстку на страницу принимается на основе диффа, что тоже вычисления.
Использовать реакт составляющие в контексте обычного кода прямо запрещается его рантаймом, а без этого использовать классы вообще довольно малоэффективно и насколько я помню не рекомендуется.
Снизить нагрузку можно было бы не занимаясь софтовым рендерингом за браузерный движок, но все эти концепции закладывались когда поиски и изменения на DOM-дереве в большинстве Интернет Эксплореров работали крайне медленно, поэтому такие архитектуры казались более оптимальными.
Смею предположить, что основная причина отказа от классов было нежелание изучать и/или внедрять ООП подход
Официально, насколько помню, причина в mixins - не до конца доведенной до ума фиче, в которой можно было переиспользовать логику, содержащую жизненный цикл. То есть это был аналог useEffect. А то, что "многие не умеют работать с this и форумы забиты вопросами - почему onClick={this.handleClick} говорит this is not defined" - это второстепенно.
Нужен был именно механизм разбиения сложной логики на более атомарные части и возможность их комбинации и переиспользования. Но реализация в useEffect с ручными зависимостями и частой необходимостью оборачивать функции в useCallback для сохранения ссылок при очистке `window.removeEventListener` вкупе с "правилами хуков", что нельзя что-то включать-отключать-переставлять, привела к куда большим проблемам.
какой кошмар, столько плюсов сией нелепой мысли) для начала, в предположении, основная причина отказа от классов со стороны кого? тут два варианта:
- со стороны разработчиков реакта. то есть фейсбук не вывез в ООП, хотя до 16 версии реакта в нём активно использовались классовые компоненты? и их до сих пор никто не запрещает использовать. сомнительно, правда?
- со стороны разработчиков, использующих реакт. то есть разработчики использовали-использовали(раз отказались потом), и вдруг такие "ну всё, я больше не могу"? при том, что в рамках реакта ООП это в основном контекст и его привязка - совершенно ничего сложного. тоже сомнительно, но будто бы речь больше про это, ведь встречаются слова про "нежелание изучать/внедрять ООП". однако классовые компоненты не развивают с 16.8 версии реакт(с 2019 года, не секудочку), при этом активно развивают хуки(т.е. функциональные компоненты). смысл продолжать использовать умирающее?
удивляюсь порой, насколько далёкие от темы обсуждения люди, вместо того, чтобы хоть немного погрузиться или банально подумать, просто "смеют предполагать" какую-то дичь. а на самом-то деле прибежали просто адепты церкви ООП, и если сделать поправку на это - в принципе сразу всё встаёт на свои места
Очевидно, чтобы всех запутать. Во времена классовых компонентов код можно было просто читать таким, какой он есть. Но, видимо, были люди, которые не умеют в ООП, у которых аллергия на классы. Поэтому сейчас нужно всего лишь изучить правила хуков, не запутаться в их многообразии и знать, какой кусок кода читать снизу вверх
почему отказались от классов?
Всё дело в замыканиях.
Функции позволяют "замыкать" свойства и состояние компонента, а для классов пришлось бы для этого помещать почти весь код в один метод render() класса. - Но зачем тогда вообще использовать класс, если бы он состоял в основном из одного метода?
Более подробно об этом Ден Абрамов написал в "How Are Function Components Different from Classes?" (March 3, 2019)
В классовых компонентах код группируется по событиям, то есть низкоуровневой логике: componentDidMount, componentDidUpdate и т.д.. А в функциональных компонентах код группируется по высокоуровневой логике, например, синхронизация данных, интерактивность дропдауна, подключение D3.js. Группы кода можно вынести в отдельные функции, благодаря чему код компонента разделяется на независимые куски высокоуровневой логики (хуки, комбинирующие другие хуки). Эти функции можно легко переиспользовать между компонентами. В то же время классовый компонент — это спагетти из логики, где для понимания куска логики часто приходится прыгать по коду на десятки строк вверх и вниз.
создание интерактивного UI, где любой компонент может обновлять любой другой компонент, просто является одним из сложнейших аспектов в разработке
возможно, с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта
React+Redux для этого и существуют. на смену redux пришёл react context api, и неплохо с этим справляется.
Простота и польза React особенно видна в React Native, который упрощает и удешевляет мобильную разработку.
Эта штука прекрасна для своего класса задач!
от авторской критики веет безумием.. :)
Разработку под мультплатформы - да, но вот поддержку…
У нас вышел новая iOS, клиент хочет новые фишки. А вот фиг, так как вы используете package для push notifications, который автор не хочет пока обновлять. А когда обновит, он не хочет собираться под старый gradle от андроида, а что бы обновить версию gradle вам надо обновить все остальные пакеты. И тут оказывается что один из них заброшен и вам надо переписывать половину приложения под новый пакет. Особо приятно было когда перестал поддерживаться NativeBase.
Ну или не клиент пишет, а гугл. Мол со следующего месяца ваша приложение будет удалено если не обновите версию api, что вызывает те же проблемы, описанные выше + ещё и reactnative надо обновить до какого-нибудь 0.80 у которого половина пакетов не работает, просто потому что мы решили что разработчики слишком хорошо живут без глобальных изменений.
Так это так сейчас практически везде. Весь софт стремительно протухает и портится стоит ненадолго оставить без внимания. Я вот в ближайшее время буду переделывать один проект с PHP 7.2 на PHP 8.2. И там во Vue части есть еще древние куски с Vuex которые надо бы переписать на Pinia. И сборщик заменить с webpack на vite потому что он тоже уже протух. И это еще PHP пожилой и зрелый язык, про Go и Rust пишут, что там чехарда не слабее JS библиотек.
Я видимо уже не молодой и наблюдал как одно и то же приложение переписывалось по пять раз практически не меняя функционала
Trubo C + assembler
Clarion
Windows Forms/Delphi
Классический server-side web с JQuery
Angular/Vue/React
Ладно, первые два пункта по рассказам старших коллег, но Clarion приложение еще видел вживую.
На чем оно будет переписано в следующей раз? Go + Flutter? Rust?
Единственное заметное изменение для пользователей было - появление многозадачности при переходе с DOS на Windows, даже графический интерфейс ничего особо полезного для пользователей не принес.
Для поддержки появление постоянных каналов связи с сервером. Правда центральные сервера имеют обыкновение временами падать, причем даже не в самых мелких и бедных конторах вот недавно В «Спортмастере» из-за ливней затопило IT-инфраструктуру, серверы «сушили» почти сутки (то приложение о котором я пишу было в намного более бедной и простой организации).
Функционал не менялся.
С другой стороны я без работы не останусь, если только ИИ программистов не заменит.
react context api — это не средство для стейтменеджмента, а скорее средство для DI. Смешно слышать, что релакс с кучей фичей заменяет штука, которая передает данные глубоко вниз по дереву
Простота и польза React особенно видна в React Native, который упрощает и удешевляет мобильную разработку.
Даже сложно представить как бы тормозил какой-нибудь Telegram если бы его написали на React Native. Я не говорю, что Telegram хорошо написан, он ужасно написан (посмотрите исходники Android-клиента, там настоящий ад и файлы по 20 тысяч строк), но на Java можно написать так, чтобы приложение было супер быстрое и отзывчивое, а на React Native нельзя.
Просто в то время глазами бэкенд-инженера вся система Angular выглядела совершенно неадекватной.
Я думал, я один такой - несовременный и немодный и "молчал в тряпочку". Там где ssr "просто пушка", пихали одностраничники, и пока они были на стадии mvp все было прекрасно, стильно и модно. Но как только проходил год два три развития, этот одностраничник становился кошмаром.
Это всё потому, что клиентские компоненты к чисто серверному рендеру подключаются просто ужасно, а без них уже и сайт не сайт.
Вот если бы что-то вроде https://stimulus.hotwired.dev/ появилось не сейчас, а одновременно с первым поколением клиентских фреймворков...
Вот мы имеем React, Vue, Angular и прочее. По каким критериям какой фреймфорк когда лучше применять?
Пример 1 - одностраничник на десяток кнопок и с пяток модальных окон
Пример 2 - приложение на десяток страниц + "динамические" страницы/репорты
Пример 3 - приложение на 50 страниц и дохренилион кнопок и компонент
Я не настоящий фронтендер, но интуитивно Vue ощущается намного удобнее, проще и изящнее в любой из этих задач. Это ведь была эволюция. Сначала был JQuery. Парни из Google посмотрели на это безобразие и сделали Angular. Потом парни из Facebook посмотрели на безобразие под названием Angular и сделали React. Потом один чел из гугла снова посмотрел на всё это переусложненное безобразие и сделал Vue. Ещё Svelte развивался судя по всему примерно из тех же соображений. Судя по количеству головняка, в который необходимо вникнуть для работы с этими фреймворками, и все возрастающему удобству и красоте кода по хронологии их появления, на Ангуляре и Реакте люди пишут просто по инерции, т.к. они очень хорошо его изучили и на них создано много разных проектов. Если бы все эти фреймворки появились в один день, я думаю что подавляющее количество людей отдали бы предпочтение Vue.
А ещё на Vue можно просто сразу взять и писать, подключив его одной строчкой на страницу. Без монструозного и запутанного инструментария, тормознутой помойки под названием npm, кучи препроцессоров, системы/пайплайна сборки (конфиги которых передают по наследству, даже не пытаясь в них разобраться) и кучи доп. библиотек для совершенно базовых вещей.
Исторически это немножко не бьётся, они появились примерно в одно время, но Vue тогда был сильно другим фреймворком по стилю. Vue 3, да, был рефлексией в т.ч. на сложности с React. После React я воспринимаю Vue как такой неплохой набор best practices в одном месте: как вы правильно отметили, можно сразу садиться и писать.
В React же я вынужден использовать собственный конструктор из пакетов и конфигов, который я наработал за годы. Но я его уже наработал, так что особых трудностей у меня это не вызывает. Сейчас поглядываю на какой-нибудь SolidJS: синтаксис реакт-подобный, много всего встроено, весьма быстрый. В теории выглядит хорошо, но ничего большого я на нём пока не писал, да и слишком молодой он, чтобы полагаться на него в больших проектах.
Solid вполне можно использовать, для простоты можно взять универсальную архитектуру, пример которой приводил здесь. Пока от него только приятные впечатления, если не нужна большая экосистема готовых компонентов. Но не стоит забывать, что на js до фреймворков было написано огромное количество библиотек (да и для Web Components сейчас), и если стереть с них пыль и обернуть в простой компонент - то Solid даже для средних по размеру проектов подойдет.
Гуд, спасибо за опыт.
Solid это Vue в фантике React'а минус virtual dom. Видимо, чтобы работягам на React проще было пересаживаться на что-то кошерное )
А на что «более кошерное» им понадобится пересаживаться после Solid?
Например, на Qwik (но только для SSR приложений). Отличие которого в том что у него нет гидрации, но при этом он тоже похож на React, как и Solid.
Что-то он медленнее всех конкурентов: https://krausest.github.io/js-framework-benchmark/2025/table_chrome_138.0.7204.50.html
Скрытый текст
Чем же он более кошерный?
По ссылке в моём первом комментарии можете подробно почитать про Resumability и отличие её от гидрации. Но если совсем коротко: Меньше JS на клиенте (только то, что должно быть на клиенте чтобы интерактивные элементы работали), меньше кода исполняется (выполняется только код, который нужен в данный момент), ленивая загрузка кусков вашего приложения (раньше они делали это через service worker, а теперь через modulepreload). Ну а скорость - это проблема решаемая. Кроме того чтобы понять, почему бенчмарк такие результаты показывает, нужно понимать, как он реализован, а ещё обновлять фреймворки до актуальных версий, например
В React же я вынужден использовать собственный конструктор из пакетов и конфигов, который я наработал за годы. Но я его уже наработал, так что особых трудностей у меня это не вызывает.
В настоящее время визионеры React предлагают именно из-за того, что все рано или поздно но нарабатывают собственный "конструктор", то есть фреймфорк и поэтому предлагают сразу использовать разработанный профи фреймворк, где React не более чем библиотека- например Next.js.
Но в программистких кругах пошли слухи что React продался Vercel (владельцу Next.js).
Визионеры React же утверждают что истинная причина именно в том, что пора уже сразу использовать созданный профи фреймфорк, а не городить свой "огород" вокруг библиотеки React.
Но как я понял, читая отзывы, веб-девелоперы в настоящее время к этому ещё не привыкли, что React умер! (как библиотека). - и всячески препятствуют "закапыванию стюардессы". Поди.
Не от простой жизни на фронте существует тот же Angular. Фреймворк задает структуру и правила, при соблюдении которых в крупном проекте получается довольно неплохо бороться со сложностью и видеть все взаимосвязи. Плюсом также является наличие Typescript и наличие в компиляторе строгой проверки шаблонов. Таким образом весь код обложен всеми возможными видами поверок и уже на этапе компиляции можно отловить большинство багов. Также можно провести изменение на сотню или две файлов и быть уверенным что ничего не изменится. Конечно платим мы за это жутко костыльным механизмом change detection, но вроде с сигналами стало чуть полегече. Ну и справедливо это все для действительно сложных интерфейсов, например каким нибудь редактором дашбордов, тогда есть смысл платить эту цену, потому что в long-term это окупится.
Однако же замечу, что часть коллег из фронтенда пренебрегают жесткими настройками компилятора в угоду скорости. И тогда поддержка проекта после таких «разработчиков» превращается в серьезное испытание.
Ну и справедливо это все для действительно сложных интерфейсов, например каким нибудь редактором дашбордов, тогда есть смысл платить эту цену, потому что в long-term это окупится.
UI для Google Cloud Platform написан на Angular. Может им удаётся экономить на костах разработки, но чисто со стороны пользователя решение выглядит как антиреклама данному фреймворку: тяжело, медленно, неудобно и некрасиво.
Без монструозного и запутанного инструментария
Как раз у Vue инструментарий более монструозный, как минимум в силу того, что это фреймворк. Можете даже банально сравнить кол-во страниц в документации реакта и вью. Если из реакта "выкинуть" "легаси" про классы, SSR и хуки, которые опционально используются раз в сто лет, то это несколько страниц
тормознутой помойки под названием npm
...которая никак с реактом или вью не связана - и при этом вью точно так же его использует. Хотите меньше тормозов - yarn или pnpm
кучи препроцессоров
Которые настраиваются один раз или не настраиваются вообще, потому что есть готовые коробочные решения. Или вы думаете, что вью ничего не препроцессит?
системы/пайплайна сборки (конфиги которых передают по наследству, даже не пытаясь в них разобраться)
Сами написали рандомные конфиги, а виноват реакт
кучи доп. библиотек для совершенно базовых вещей
То есть буквально никакой разницы со вью нет, вы что там ставите внешние стейт менеджеры, клиенты для апи, валидации, дат, тестинга и т. п., что там
Или вы думаете, что вью ничего не препроцессит?
Vue прекрасно работает вообще без сборки, npm и т.д. Особенно, когда речь про небольшие приложения на несколько страниц.
вы что там ставите внешние стейт менеджеры
vue reactive state доступен из коробки, ничего ставить не надо. Для небольших приложений на несколько страниц этого более чем достаточно.
Vue прекрасно работает без сборки, npm и т.д.
React тоже можно использовать без сборок, npm и прочего: Просто импортируете его из какого-нибудь esm.sh в обычном JS-модуле и используете: https://codepen.io/octet-stream/pen/EaVjVmK
У вас не будет JSX - придётся вручную вызывать createElement, но так тоже можно. Другое дело что, а нужно ли? Равно как и с Vue - намного удобней использовать его со всеми этими инструментами.
vue reactive state доступен из коробки, ничего ставить не надо
Опять же, useState, useReducer и createContext доступны из коробки, ничего ставить не нужно. Для простых приложений должно быть достаточно. Работает даже без препроцессоров (ссылка на codepen выше в моём комментарии).
Я не спорю, при желании или необходимости на Vue также можно навесить что угодно. И повсевместно навешивают. И я не утверждаю, что это всегда плохо.
Я пишу о том, что очень ценю лаконичность, а именно - возможность написать в <head>:
<script src="https://unpkg.com/vue@3/dist/vuпe.global.js"></script>
И полноценно использовать возможности Vue на странице. Есть способы сделать так и для React, но выглядит и ощущается это как грязный хак, а не нормальный сценарий его использования для небольших проектов.
И мне при таком сценарии использования не нужно, чтобы написанный мной код транспилировался/препроцессился каким либо внешним инструментом. Я просто нажимаю "сохранить" - и оно работает.
Там, где 95% разрабов на реакте будут использовать какой-нибудь Axios (хотя вроде бы никто не заставляет, но это почему-то распространено повсеместно), я просто возьму ванильный fetch.
И мне не нужно при этом тащить аналог Redux для нормального и удобного управления состоянием. Я понимаю, что React по своей философии в первую очередь о компонентах, а не о маршрутизации событий и управлением состоянием приложения. Но где компоненты - там рядом всегда логика их взаимодействия. У React эта важная и неотъемлемая часть прикручена будто бы сбоку.
Если у вас приложение, где вы вместо сборки вставляете standalone скрипт в хедер, то вообще не вижу смысла это обсуждать, это даже не пет-проект, а страница с двумя кнопками, там вы можете хоть на чистом HTML и JS в одном файле написать и вам вообще ничего не нужно
Там, где 95% разрабов на реакте будут использовать какой-нибудь Axios (хотя вроде бы никто не заставляет, но это почему-то распространено повсеместно), я просто возьму ванильный fetch
Каким образом связан react и axios? Почему на реакте нельзя написать ванильный fetch?
И мне не нужно при этом тащить аналог Redux для нормального и удобного управления состоянием
И мне не нужно при этом тащить аналог Pinia для нормального и удобного управления состоянием
вообще не вижу смысла это обсуждать
Если вы не можете сделать так на Реакте, значит никому это не нужно, верно? )
с двумя кнопками
Ну почему же. Законом не запрещено ещё табличку и дропдаун добавить
Почему на реакте нельзя написать ванильный fetch?
Извините, вы похоже невнимательно прочитали
> вроде бы никто не заставляет
Каким образом связан react и axios?
> 95% разрабов на реакте будут использовать какой-нибудь Axios
Знаете, самому было интересно, почему
И мне не нужно при этом тащить аналог Pinia
Представляете, мне тоже! Ну хоть что-то вам тащить в реакт не надо, уже хорошо.
Там, где 95% разрабов на реакте будут использовать какой-нибудь Axios (хотя вроде бы никто не заставляет, но это почему-то распространено повсеместно)
Потому что там есть intercept, catch, таймауты и прогресс из коробки. Вообще не вижу ни одной причины пользоваться голым fetch где-либо кроме крохотных пет-проектов.
Но ещё до React появились Backbone, Knockout и Ember.
А у меня впечатление, что Vue не знает кем хочет быть, и просто пытается быть на гребне тренда.
Сначала он был как типа улучшенный AngularJS, т.к. Angular 2 - сложна, потом пришел React, и Vue начал косить под него, сейчас вроде уже выработался свой стиль, но кто знает, щас ребята впечатлятся чем то еще, и привет Vue4.
Разве когда-либо Vue косил под React? Да, у него есть и VDOM, и JSX он поддерживает как следствие, но React он в целом не повторял ни в developer experience, ни в системе реактивности.
У Vue есть хуки, и из-за этого некоторые думают что он косит под React. Однако, при внимательном взгляде видна принципиальная разница: если у React вызовы хуков делаются во время рендера, то во Vue они используются на этапе инициализации компонента.
И наличие этого самого этапа инициализации очень многое меняет в архитектурном плане.
Это ведь была эволюция. Сначала был JQuery. Парни из Google посмотрели на это безобразие и сделали Angular. Потом парни из Facebook посмотрели на безобразие под названием Angular и сделали React. Потом один чел из гугла снова посмотрел на всё это переусложненное безобразие и сделал Vue.
Вот чтобы всего этого безобразия не было, было бы круто, чтобы все уважаемые вышеперечисленные персоны и фирмы выделяли своих людей для работы в спец-комитете. И академики там должны присутствовать. И решал бы этот комитет все насущные задачи совремнников и задавал бы тон развитию:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28575664
не отдельные люди / фирмы должны создавать парадигмы, а специальный комитет в состав которого они и входят. Сообща.
А то сегодня Линус хочет так, а завтра Гейтс ему такой — эдак. Вот вам и бардак.
Благодаря этому бардаку и происходит прогресс. А что до комитетов, то пожалуйста не надо.
Если вас какой-то фреймворк/библиотека/подход не устраивает - не используйте. Благо есть выбор.
В том то и дело, что я обычный пользователь, и из года в год баги-баги-баги.
Дайте мне мне пул-сертифированного ПО для выбора, а не один глаобальный черный ящик.
И нет — этотне я требую рюшечки, эты вы и дизайнеры мне их впихивайте.
Мне нужна, простота, быстрое исполнение, стиль да -пусть будет, его не может не быть, и минимизация багов. Что не возможно без создания комитета регулирующего взаимодействие между Большой тройкой.
Ах да, и если у Вас не увязывается одно с другим, то я подскажу, как это реализовать без потерь доя прогресса и стабильного развития.
Видете ли — мир стал очень комплексным, сложным, чтобы решать все насущные задачи старым добрым методом.
Соревновательность и маргиналов никто не отменяет , но нужна СТРУКТУРА ПАРАДИГМ ПОВЕДЕНИЯ И ВЗАИМОДЕЙСТВИЙ.
Вы думаете в сертифицированном ПО не бывает багов?
Как наличие коммитета поможет вам с минимизацией багов?
Мир никогда не был простым.
но нужна СТРУКТУРА ПАРАДИГМ ПОВЕДЕНИЯ И ВЗАИМОДЕЙСТВИЙ.
так они есть. И не один. Хотите ООП, хотите ФП и так далее. Выбирайте под задачу. Есть баги? Ну так помогите с их починкой.
Даю другой пример.
Обучение: школы, вузы.. все это организовано. Однако есть возможность воспитывать дома, персональными учителями и тд
И не факт, что это хорошо на самом деле. Есть страны где одновременно несколько разных образовательных систем и у родителей есть возможность выбора.
Вы так и не ответили каким образом коммитет сделает так, что багов будет меньше.
Вы бы по ссылке прошли.
ОРГАНИЗАЦИЯ ПРОЦЕСОВ. Задание тона, четкое структурирование имеющихся вызовов, парадигм их решения и введение/разработка соотвесствующих рекомендаций.
Что ттут непонятного…
Вот было обучение через подмастерье раньше, от отца к сыну, но почему мы пришли к организованным вещам. Ибо комплексность увеличилась. Мы вынуждены регулировать это через Мин Просвещения (или как там оно у вас называется).
А модель OSI добилась большего. Весь мир бегает по ее «указке». Результат не идеальный, но….
Вы поймите. Я не иделаьный, и лишь пытаюсь направить в нужное русло решение насущных проблем, плюс закладка фундамента.
А модель OSI добилась большего. Весь мир бегает по ее «указке».
Это просто принято так считать. Эксперты же полагают, что это просто абстрактная модель, которая мало соотносится с реальностью, включая реализацию TCP/IP, в которой 5 слоёв. Некоторые предлагают 3-слойную модель, а RFC 3439 вообще считает слои вредным усложнением.
Так что модель OSI существует только в книжках для студентов, поэтому ссылаться на неё как успешный пример единого глобального дизайна не стоит.
Это лишь беглый пример. Причем не стоит слушать каждый чих колкого эксперта. Линус тоже считает одно, создатель GNU, третье, а тот критики, которого Вы упомянули в контексте эталонной сетевой модели — вообще о третьем поет. Пооизводттели железа четвертое нам пихают и так далее
И вот чтобы избежать всех этих коллизий взаимодействия, я и предлагаю обвернуть это все в единую квази идеальную модель поведения. На экспертном уровне, где не будут перетягивать одеяло на себя каждый игрок, а будут добиваться консенсуса.
Пусть это будет уютный чатик академиков, и прочих представителей отрасли (железняки, ос-еры, производители конечного ПО)
Однако это тяжео реализовать.
Но я это предвижу. Как и пдд строилось, как было с телефонынми сетями, так и тут лет черезы сто все зарегулируют. К бабке не ходи.
Поздравляю, мы живем в «золотое» время я свободного интернета и ПО. Уже гайки затягивают, дальше больше. Поэтому радуемся пока так.
В разных странах разные ПДД, и хотя часть из них некоторым образом гармонизирована Венской и Женевской конвенциями, однако они всё равно различаются в мелочах. Но это хотя бы более-менее чёткие правила, а от комитетских документов под названием «Структура парадигм взаимодействия» вы не дождётесь никакой конкретики, там будут максимально обтекаемые формулировки, бесполезные чуть менее, чем полностью.
Соревновательность и маргиналов никто не отменяет , но нужна СТРУКТУРА ПАРАДИГМ ПОВЕДЕНИЯ И ВЗАИМОДЕЙСТВИЙ.
На самом деле стандарты, сертификация, обучение и лицензирование персонала используются там где это важно (PSI DSS, SOC2, и т.п). Но там критерии, по классике, указываются в терминах результов ("что", а не "как"). Маршеровать строем ни кто не заставляет, но если вы пойдёте не туда, то на это укажут.
Я узер, и как вы там собирайтесь решать свои задачи меня условно не волнует. Но вы должны отталкиваться не от приихоти бизнеса или меня, а от заданых цивилизациооных задач. То чем занимаются в академиях.
Поэтому я желаю иметь магазин, где бду уверен, что это ПО написано красивым стилем, имеет минимум багов. —Дорого? Окей, но я имею выбор, а не этот глобальный черный ящик.
Сертеыицированное ПО. Не Вы, а ПО.
Суть не в этом, а то шо вами крутят как котят, а вы все прихоти бизнеса и дизайнеров исполняйте
Поэтому я желаю иметь магазин, где бду уверен, что это ПО написано красивым стилем, имеет минимум багов. —Дорого? Окей, но я имею выбор, а не этот глобальный черный ящик.
Глобально правила игры задаёт государство. В остальном же любой каприз за ваши деньги - в конце-концов за все платит не бизнес или дизайнер, а клиент.
Точно! 💯
Только я наблюдаю обратную картину: Линус,, ФБ, АйБиМ, — кто угодно, только не совет мудрецов формирует повестку)), регулирует даже.
Ну условно.
Ещё раз: платите деньги — и всё будет так, как вам хочется. Нужен совет мудрецов? Профинансируйте его. Напишут они вам структуру парадигм — профинансируйте пропаганду этой структуры. Организуйте независимую сертификацию ПО с присвоением «знака качества» и помещением в некий «каталог качественного ПО».
Вот чтобы всего этого безобразия не было, было бы круто, чтобы все уважаемые вышеперечисленные персоны и фирмы выделяли своих людей для работы в спец-комитете. И академики там должны присутствовать.
И получится в лучшем случае новый Си++, а в худшем -- модель OSI.
Вы не понимаете о чем. Я не лезу в ваши споры о стеках и конкретных реализациях, и модель OSI этим не занимается. Она строит МОДЕЛЬ ПОВЕДЕНИЯ, взаимодействия. Она закладывает в протоколы поведения все современные Физические открытия используемые в бизнесе, военке. Понимаете?
Был телефон по проводам. Никакой модели не было. Потом выдумали комп сеть на основе чего? Телефонных линий, кабелей. Уже два игрока. Производители кабелей и оборудования, производители логики. И обе эти отрасли развиваются безпрерывно!
Удобно иметь институт, который регулирует / ОРГАНИЗУЕТ взаимодействие между этиии отрослями? — ну конечно удобно!!!! Поодуктивно и прибыльно и полезно мне — пользователю.
Поэтому телеком очень успешен. Есть уважаемые организации, Институ стандартов (электро, прочие).
По сути производители средств связи сумели вынуждено хорошо организоваться. И те пооизводители «логики» что работают со связистами не имеют проблем. Ибо есть четкие парадигмы — гоу, пили код:
— у тебя есть 50 кб памяти, 80 тактов процесора в секунду;
— у тебя инструменты реализации «логики»;
— пилите девайс в этих рамках;
— девайс должен соотвествоаать такими-то нормам того-то.
Слушайте. Этих примеров много из жизни.
Автомобили — ПДД, регуляция норм безопасности и прочее.
Даже когда на повозках ездили, придумывали и обязовали участникам к каким-то нормам поведения/взаимодецствия. Едет Дартаньян на свижание на коне, а ему на встречу экипаж и отддельные всадники — вот они молча договоились, что этот пройдет справа, а те ему с лево по встречке. Молча, без короля и регуляции, — но договоились. Безопасно? - на сколько возможно, сэр.
А вот когда мир усложнился, трафик увеличился, что мы имеем?
Да вам к компу без прав даже не подпустят)))))
Условно конечно. Но не ходите далеко, когда истина где-то рядом.
Топик стартер об этом и говорит, что не суть важно, какой стек вы используйте (почитайте комментарии к этой статье), а то что все эти споры не о том. .. проблема глубже. Щас эволюционирует все огромными темпами, а порядка нет. :))))
Модель OSI это упрощение - абстракция, как идеальный газ. На ней удобно объяснять студентам базовые вещи. Но это не догма. Реальные инженерные задачи всегда решаются в ограничениях, которые ставит наш окружающий и изменчивый мир, а не абстракции. Поэтому на практике решения оказываются формально многоуровневыми, скажем как QUIC. Ну или мультипарадигменными, как все современные языки программирования.
Модель OSI взята, как образец, реальный действующий фундамент. Я, что виноват, что спец из области? Совпадение.
Вы уже зависите от модели. И никакая это не абстракия, эта реальная модель задающач парадигмы поведения взаимодействия. А вы ее прямой участник. Ибо весь ваш реакт никому не нужен, не будь линий связи.
Все что надо сделать — организовать надстройку, переорганизовать некоторые уровни.. Да или выдумать отдельную модель организации и реализации парадигм программирования в зависимости от насущных проблем.
Вас W3C чем-то не устраивает? Или вы хотите, что бы они ещё решали как фреймворки делать?
Вас все устраивает?
W3C, как раз к ним вопросов нет. Да и я не особо слежу как они работают, может и там найду треки для оптимизации.
меня не устраивает — дыры в ПО. Вопросы еще будут?
Так этого все хотят. Но никакой спец-комитет в этом не поможет.
Сомнительное заявление, но не буду спорить, ибо просто выложил очевидную идею.
Спор будет полезным при аргументах. Их нет. «Не поможет— и все!».
Я и сам подозреваю, что дело гиблое, но пытаюсь хоть немного разогреть какого-то конструктива.
По судите сами, я смотрю со стороны. Не являюсь практикующим программистом и поэтому вынужден следить за трендами со стороны. И что я вижу. Вместо организованного процесса — бердак, бардак, бардак. И так со временем, когда я учился (конец девяностых). Споры, перетягивание одеял. Может так и надо. Но чую я что лет через сто все будет зарегулировано по самые гогошары. Как и в ПДД сейчас, то есть регуляции дорожного движения.
ладно. Идея есть идея. И не я ее выдумал. Фиг с ней. Я уже устал ее озвучивать, и видимо она тупая.
Думаю не буду больше об этом думать, вещать.
Доброго дня.
Я полагал, что аргументы довольно очевидны. Нереально заставить всех строго соблюдать регламенты. Наглядный пример - упомянутые ПДД. И это ещё при том, что есть контролирующий орган, и нарушения наказываются.
Да и лично мне сложно представить, как вообще можно зарегулировать разработку ПО в целом. Это огромная и динамическая сфера.
Если не нарушать, то безопасность гарантирована.
Вот и речь о том, что вы даже модель не можете построить, а чем еще говорить дальше. Какие нарушения водителей Вы упоминайте в аргументе, если у вас сама база не упорядочена.
Уловили когнитивную ошибку суждения?
Добра Вам.
ПыСы: и да, мне нафиг не сдалась та регуляция, но факт есть факт. И отрасль поидет к этому, точнее естественно эволюционирует.
Так же было на заре Электричесвта: Тесла и Эдисон много спорили( сравните это с ФП и ООП), и что в конце? Кто кого победил? Оба победили, и отрасль зарегудирована по самые гогошары. И что? Все там в порядке: генерация электричества есть, поставка есть, сбыт есть — аварии на производстве с годами минимизированы, биткоины копаются.
Поэтому я говорю об основе, а вы о нарушениях эксплуатации.
Пример 1 - одностраничник на десяток кнопок и с пяток модальных окон
React + MobX
Пример 2 - приложение на десяток страниц + "динамические" страницы/репорты
React + MobX
Пример 3 - приложение на 50 страниц и дохренилион кнопок и компонент
React + MobX
Пример 1 - одностраничник на десяток кнопок и с пяток модальных окон
$mol
Пример 2 - приложение на десяток страниц + "динамические" страницы/репорты
$mol
Пример 3 - приложение на 50 страниц и дохренилион кнопок и компонент
$mol
Скажите кто-нибудь, зачем вообще на ОДНОСТРАНИЧНИКЕ какой-либо фрэймворк?
React восхитителен! Он позволяет мне обходиться без ООП. Хуки исчерпывающий и потрясающе удобный инструмент обработки изменений состояний.
Мне кажется, вы троллите
Я не троллю. Я искренне считаю React самым сбалансированным конструктивом для разработки фронтендов.
что на счет Vue?
Vue мне не зашел. Просто субъективно дискомфортно в Vue и все. А у меня есть привычка получать удовольствие от процесса написания кода.
Ну, вообще говоря, он тоже не идеален. Меня очень смущает DSL и магия компилятора.
// v-bind:href – это что?
// "url" – выглядит как текст, а на деле переменная
<a v-bind:href="url"
// v-on:click – это что?
// "doSomething" – выглядит как текст, а на деле переменная
<a v-on:click="doSomething"
// и т.д.
<div v-bind:id= // ?
<time :title="toTitleDate(date)" :datetime="date" // ?
<p v-if="seen" // ?В этом смысле JSX выглядит немного привычнее.
Нормальный там DSL. Как я понимаю - они делают его совместимым с HTML, поэтому у вас все условные блоки и циклы реализованы через директивы v-* в аттрибутах и строки, поэтому вы заварачиваете ваши компоненты в <template>, и поэтому вы пишите блочные элементы, даже если они пустые, как блочные элементы. Ну, то есть не <slot />, а <slot></slot> (хотя можно и так и так - компилятору без разницы, а вот линтер будет по умолчанию ругаться).
v-bind:href – это что?
Это директива, котрая привязывает вашу переменную к аттрибуту href и подписывает элемент на изменения значения этой переменной, если переменная реактивная (можно передать туда ref и он сам будет подставлять вам url.value из вашего рефа).
"url" – выглядит как текст, а на деле переменная
Да, но редактор вам подсветит это как код.
Немного непривычно после JSX, но на мой взгляд так даже удобней будет. Как минимум писать условия и циклы приятней, чем в React, и выглядит это не настолько плохо, как в Solid с его специвльными компонентами для этих самых условий и циклов.
В этом смысле JSX выглядит немного привычнее.
Привыкайте к новому для вас языку и проблема решится сама собой :)
Нормальный там DSL.
Звучит как тавтология.
Привыкайте к новому для вас языку и проблема решится сама собой :)
Вот счастье то! )) Типа мне HTML/JS/CSS недостаточно, надо еще привыкать к DSL-ю Vue. А ради чего?
Но ведь к JSX вам когда-то в прошлом тоже привыкать пришлось же. А там смесь языков ещё более дикая.
Приведите пример, где JSX выглядит более дико. Мне к jsx привыкать не приходилось.
С первого же символа. Как-то в обычном JS не ожидаешь открывающей угловой скобки.
Дальше можно про className вспомнить, из-за чего невозможно взять кусок HTML и превратить его в шаблон без переписывания. Ни один альтернативный язык шаблонов не имеет подобной проблемы. Ну ладно, у pug и mol тоже эта проблема есть.
Ну и "циклы" в JSX могут быть сколь угодно "привычными", но выглядеть менее ужасно от этого они не будут.
function CardGallery({ count, tools, footPre, footAfter, onselect, onclear, onclose, className, closeClass, clearClass, numbClass }) {
return <>
<Panel
className={ className }
tools={<>
{tools}
<button
class={ closeClass }
title={ l10n.get( 'CardGalleryClose' ) }
onclick={ event => onclose( event ) }
>
{ fontIcon.close }
</button>
</>}
foot={<>
{footPre}
<button
class={ clearClass }
onclick={ event => onclear( event ) }
>
{ l10n.get( 'CardGalleryClear' ) }
</button>
{footAfter}
</>}
>
{
Array.from( { length: count }, ( _, i )=> (
<Card
className={ numbClass }
title={
l10n.get( 'CardGalleryElement' )
.repalce( '{numb}', i.padStart( 2, '0' ) )
}
onclick={ event => onselect( i, event ) }
/>
) )
}
</Panel>
</>
}Сравните с "нечитаемым" view.tree:
$my_card_gallery $my_view
count 0
kids /
<= Panel $my_panel
tools /
<= tools /
<= Close $my_button
hint @ \Close Gallery
click? <=> close? null
kids / <= Close_icon $my_icon_close
foot /
<= foot_pre /
<= Clear $my_button
title @ \Clear Cards
click? <=> clear? null
<= foot_after /
body <= cards /
<= Card*0 $my_card
title <= card_title* \Element #{numb}
click? <=> card_select*? nullexport class $my_card_gallery extends $.$my_card_gallery {
cards() {
return Array.from(
{ length: this.count() },
( _, i )=> this.Card( i )
)
}
card_title( numb: number ) {
reutrn super.card_title( numb )
.replace( '{numb}', numb.padStart( 2, '0' ) )
}
}Так ведь действительно нечитаемый. Имхо
Обоснуйте.
Хоть это и странно, ибо если предлагаете – сами и продайте мне это. Убедите в том, что мне это нужно. Но ладно, мне не сложно:
$my_card_gallery $my_viewЧто означает $my_card_gallery? А $my_view? Зачем нужен знак доллара? Пока непонятно.
count 0А count это что? Наверное какая-то переменная, а 0, это видимо значение по умолчанию. Ну ок. Тогда получается, что ответ на предыдущий вопрос такой: $my_card_gallery это переменная, а $my_view это значение по умолчанию, хотя что такое $my_view все еще совершенно непонятно.
kids /Эммм... Кажется, что kids это тоже переменная, а значение по умолчанию /? Как-то не верится, возможно предыдущие мои выводы – ошибочны.
Обоснуйте
Я прочитал всего пару строк, а вместо того, чтобы понять что тут написано, у меня накопилась куча вопросов.
Идем дальше.
<= Panel $my_panelТут какое-то выражение. Сходу кажется что один операнд забыт, а Panel это как тип для $my_panel. Это очень странно. Представляю, будто это какой-то строго-типизированный язык, но настолько строго, что тип нужно указывать каждый раз обращаясь к переменной, типа так:
for (int i = 0; int i <= int 5; int i++) {
System.out.println("Итерация: " + int i);
}Наверное я ошибаюсь, но это что-то, что я пока понять не могу. Идем дальше:
tools /
<= tools /Да что такое то! Пропускаем. Может разгадка будет ниже.
<= Close $my_button
hint @ \Close Gallery
click? <=> close? null
kids / <= Close_icon $my_icon_closeF***k!
Так, ладно. Очевидно все эти /\><=, это какие-то операторы, но как тогда это читать, и причем тут разметка?
Ок, что там еще?
<= Card*0 $my_card
title <= card_title* \Element #{numb}
click? <=> card_select*? nullЕсли пустота меньше или равно Card помноженный на 0, тогда $my_card, иначе, если title меньше или равно card_title помноженный на... Нет. Я сломался.
Я не знаю как иначе объяснить, что это нечитаемо.
Ну, то есть вы выдаёте свою личную неосведомлённость за нечитаемость языка, как скучно.
<Родитель роль="Отец" имя="Виктор" возраст="32">
<Ребенок имя="Катя" возрас="8" роль="дочь" />
<Ребенок имя="Лена" возрас="12" роль="дочь" />
<Ребенок имя="Максим" возрас="16" роль="сын" />
</Родитель>или
<xuz role="Отец" name="Виктор" age="32">
<qux name="Катя" age="8" role="дочь" />
<qux name="Лена" age="12" role="дочь" />
<qux name="Максим" age="16" role="сын" />
</xuz>Предположу, что даже без малейшего представления об XML, большинство поймет что тут описано. Так что нет, я выдаю нечитаемость за нечитаемость.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
А вы пробовали или теоретизируете? Язык так-то довольно мнемоничен.
Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
То есть язык в деле вы не пробовали, а только читали про него? Ничего удивительного, что вы ничего не запомнили.
Да сделай ты уже простой для обычного разраба DSL, похожий на HTML, пусть и без каких-то фич. И у народа пропадёт основная претензия, мол, чего это ты тут нам свои кракозябры суёшь, зачем? Не хотите кракозябры - окей, держите HTML-like вариант! Да, в нём нельзя будет делать что-то, но для 95% задач этого должно хватить. Как в том же Vue, в котором можно и JSX с рендер-функциями взять, но почти всегда можно обойтись просто шаблонами. Это возможно?
Конечно это возможно. Но Дмитрий совершает логическую ошибку. Сначала он придумывает формат tree как универсальный структурированный формат для данных на замену XML, JSON, YAML, объявляя его самым эффективным в общем случае. Затем он использует его для описания интерфейсов, тем самым создав подмножество view.tree. Логическая ошибка в том, что этот формат также неявно объявляется самым эффективным, то есть имеет место ошибочная апелляция к общему (fallacy accident).
На самом деле последовательность была такая:
Всё описывалось тс классами, но это был многословно и не наглядно.
Попытка приспособить jsx провалилась из-за фундаментальных проблем с ререндерами.
Попытка приспособить html провалилась из-за невозможности вставлять дерево в атрибут и крайней ограниченности возможных типов.
Разработан собственный язык композиции компонент со всеми необходимыми возможностями.
Для упрощения его обработки выделен абстрактный формат tree.
В ответ на критику язык композиции перепроектировался с нуля, но в итоге поменялся лишь косметически.
На базе формата спроектировано множество других языков, включае xml.tree для более наглядного представления xml.
Теперь приходит ноунейм с Хабра и рассказывает, что всю эту долгую борьбу за читаемость и простоту надо откатить в пользу
копчикаhtml.
А как называется логическая ошибка. Когда человек с умным видом несёт чушь, не имея ни малейшего представления о предмете разговора?
Попытка приспособить html провалилась из-за невозможности вставлять дерево в атрибут и крайней ограниченности возможных типов.
Извините, но звучит как чушь. Почему vue как-то работает несмотря на эту самую невозможность, а у вас она оказалась критической?
Очевидно потому, что vue не решает вопрос кастомизации компонент в полной мере.
Так это нужно в одном случае из ста. Почти всегда достаточно механизма слотов.
Но, твоя правда, когда нужно - очень не хватает такой возможности. Особенно если в ui-библиотеке забыли добавить этот самый слот. Поэтому я и предлагаю вариант с параллельно существующим "простым" (т.е. привычным большинству) DSL для "простых" случаев. Это сделает вкат в $mol более плавным и дружелюбным.
Ну да, конечно, и придётся людям учить не один простой синтаксис, а два: один простой и мощный, а другой сложный и урезанный. Обожаю эти экспертные советы, как правильно делать фреймворки.
Вы уже предлагаете
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
О каких глюках в документации идёт речь?
https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Если твой фреймворк такой хороший, то почему он такой непопулярный?
Просто возьми за основу уже знакомый всем html/jsx/vue templates. И не придётся никому ничего учить. Потому что концепция будет понятна, а нюансы вроде "тут другое ключевое слово" - это именно что нюансы. Неужели не доходит?
А как называется логическая ошибка
dicto simpliciter или accident fallacy
На самом деле в вашем случае действительно лучше подошё кастомный формат, но ему бы следовало быть более человекочитаемым. Например, использовать хотя бы двоеточие для обозначения наследования, квадратные скобки для списков и так далее. Да, может быть сложнее написать парсер, зато его когнитивно проще воспринимать и, в том числе, проще такой формат продать.
$my_card_gallery: $my_view {
count: 0
kids: [
Panel: $my_panel {
tools:
foot:
body:
}
...
]
}В какой-то степени выглядит похоже на Jetpack Compose.
Подражание чужеродному синтаксису порождает ложные ожидания, которые только мешают изучению новых концепций, а не способствует ему. Попробуйте переписать весь файл, не скипая самое интересное, и поймёте, что двоеточие тут совсем не уместно, а фигурные и квадратные скобки ничего полезного кроме лесенки в конце не дают, но создают ожидание, что нужны запятые-разделители, и когнитивный диссонанс от ключей внутри массива. Если развивать эту мимикрию под JS дальше, то получится язык xts из анализа по ссылке ниже.
когнитивный диссонанс от ключей внутри массива
Пхпшники живут же с ассоциативными массивами с квадратными скобками или array(), и ничего. Наоборот, здесь подчёркивается строгая последовательность элементов, которые будут выводиться в списке, в отличие от атрибутов компонента.
только мешают изучению новых концепций
Незнакомый и непривычный синтаксис создаёт дополнительную когнитивную нагрузку. Из мнемоничности же в нём только стрелки потока данных.
Если развивать эту мимикрию под JS
Не обязательно мимикрировать под JS, язык может быть более кастомный, но попытка выхолащивать синтаксис не идёт ему на пользу, и об этом говорят многочисленные критические комментарии.
Для пхпшника видеть двоеточие вместо стрелки ещё более не привычно.
Опять вы бравируете своей неосведомлённостью: https://mol.hyoo.ru/#!section=docs/=cx1tyu_aduyqj/Docs.View'cx1tyu_aduyqj'.Details=Шпаргалка по спецсимволам
Использование квадратных и фигурных скобок в данном контексте ничем кроме мимикрией под JS обосновать нельзя.
Да, я читал это. Я понимаю, что твой view.tree нужен для решения одной проблемы - переопределение каких-либо узлов дерева компонентов. А теперь вопрос: как часто это переопределение нужно? Да ещё в таком сложном виде, что с этим не справится синтаксис а-ля вьюшные слоты. Тем более, что твой вариант view.html выглядит так, словно его действительно можно свести к шаблонам вью.
И философский вопрос. Ты понимаешь, что вся проблема такого ярого неприятия возникает именно из-за странного для большинства синтаксиса, странность которого не могут объяснить приводимые тобой примеры? Если ты действительно хочешь продвинуть своё детище в массы, то, быть может, стоит всё же пойти на поводу у масс? Дать массам какой-то не столь радикальный вариант использования фреймворка? Тот же Solid пошёл по пути похожести на реакт и этим завоёвывает огромную популярность в среде реактеров, хотя ему до возможностей вью далеко. Понимаешь, к чему я?
А теперь вопрос: как часто это переопределение нужно?
Когда это достаётся бесплатно - постоянно.
Да ещё в таком сложном виде, что с этим не справится синтаксис а-ля вьюшные слоты.
Так это как раз у вьюшных слотов сложный громоздкий синтаксис. Да даже одно только разделение на пропсы и слоты чего стоит.
проблема такого ярого неприятия возникает именно из-за странного для большинства синтаксиса
yaml как-то освоили, и pug освоили, и sass освоили, даже python освоили, а тут видите ли трансцендентный синтаксис.
Если ты действительно хочешь продвинуть своё детище в массы, то, быть может, стоит всё же пойти на поводу у масс?
Типа, если вокруг много говноедов, то надо и самому начать производить и потреблять ту же субстанцию? Нет, спасибо. Давайте вы с этим без меня.
yaml как-то освоили, и pug освоили, и sass освоили, даже python освоили, а тут видите ли трансцендентный синтаксис.
Интересно, что в среде фронтендеров в целом подобный синтаксис не прижился: pug нишевый, sass уступил scss'у, coffeescript забыли с приходом es6. Интересно также, что один из ваших последователей — как раз человек с питоновским бэкграундом. Так может тогда вам с $mol исключительно на эту аудиторию таргетироваться?
Типа, если вокруг много говноедов, то надо и самому начать производить и потреблять ту же субстанцию?
Кстати это тоже демагогический приём — сведение к абсурду, не говоря уже об уважении к аудитории. Но получается, что если массы — исключительно говноеды, и вам с ними не по пути, то зачем вы их постоянно переубеждаете?
Эгоцентризм - это думать, что если твои слова опровергают, то именно тебя хотят в чём-то убедить или что-то продать.
Отлично, значит остаётся только продавать питонистам
Примечательно, что у нас в сообществе много бэкендеров, которые, посмотрев на ужасы, что творятся во фронтенде, приходят в итоге к $mol, потому что на нём сделать вменяемый фронтенд проще, чем собирать свой фреймворк из реакта и палок.
А вы не собирали случайно статистику по бекендному бекграунду (окак!) своего комьюнити?
Чтобы что? Чтобы для чего?
Know Your Customer же. Знание аудитории позволит лучше проанализировать сильные и слабые стороны продукта.
Build Your Customer. Лучше играть на своём поле, чем на чужом.
А ресурсов хватит на билд?
Слушай, тебе умные люди говорят, что надо сделать, чтобы кратно увеличить шансы на то, что твой фреймворк наконец-то пойдёт в массы. И уже после этого ты сможешь продвинуть свои идеи в эти самые массы. А вместо того, чтобы быть чуточку хитрее и всё же стать Моисеем для заблудших, ты дуешь щёки, бросаешься цитатками, обзываешься и вообще ведёшь себя некрасиво. Ты не Джобс, у тебя нет армии фанатов, которых ты можешь гнуть как угодно, ты ноунейм, смирись уже с этим. Ты можешь быть тысячекратно гениальнее любого из нас, но что толку, если мир устроен так, что одна лишь гениальность ничего не значит?
Когда это достаётся бесплатно - постоянно.
Тебе говорили, что цепочки переопределений всего подряд до добра не доводят?
Так это как раз у вьюшных слотов сложный громоздкий синтаксис.
Но для среднего разраба он гораздо понятнее, чем твой супер-пупер язык, вся выразительность которого нужна не так часто, как кажется.
Да даже одно только разделение на пропсы и слоты чего стоит
Стоит того, что шаблон не выглядит как jsx-каша
yaml
Пришли большие дяди и всем его насадили
pug
Никому не нужен, так как большие дяди не пришли
sass
Никому не нужен, все предпочли писать на scss, который чуть более многословен, но гораздо более привычен и структурирован
python
А это тут при чём? Ну освоили и освоили, мало ли извращенцев. Сейчас это осваивают потому, что стандарт такой. Большие дяди поддержку оказывают.
говноеды
Так ты не ешь говно, а подставляй его говноедам. И все будут счастливы.
React никогда в жизни не подойдёт для крупного приложения, оно будет неподдерживаемым. И да, че то реакт отстал от angular в виде производительности и функционала)))))))))))
Ну да ну да... завтро скажу команде на работе, а то 5 лет разработки ентерпрайс апсы с 128 сервисами надо сварачивать, поддерживать нельзя... react + class component+ mobx, новые разделы функции+хуки, часть старых так и останется, часть переписывается аишкой за короткое время.
Причем самое смешное, что заходил же он с козыря, что VirtualDOM намного быстрее тормозного ангуляра
React и Express два восхитительных в своей простоте инструмента, которые позволяют мне обходиться в остальном чистым Javascript без использования ООП.
Чем же плохо ООП?
ООП поощряет разработчиков к бессмысленному усложнению структуры кода, требуя упаковки и группировки всего и вся в классы.
Ага. Например плохой OOP
const todo = { selected: false };
todo.selected = true;и хороший не OOP
const [todo, setTodo] = useState({ selected: false });
setTodo(prev => ({ ...prev, selected: true }));
Лукавите
class Clock extends React.Component {
constructor(props) {
super(props);
this.state = {date: new Date()};
this.setDate = this.setDate.bind(this);
}
setDate(value) {
this.setState({
date: value
});
}
render() {
return (
<div>
<h1>Hello, world!</h1>
<h2>It is {this.state.date.toLocaleTimeString()}.</h2>
</div>
);
}
}против
const Clock = () => {
const [date, setDate] = useState(new Date());
return (
<div>
<h1>Hello, world!</h1>
<h2>It is {date.toLocaleTimeString()}.</h2>
</div>
);
};Лукавите
Нет. Просто у меня нет ассоциации ООП = React Class Component.
class Clock extends Component<Clock> {
@mem date( next?: Date ) { return next ?? new Date() }
return (
<div>
<h1>Hello, world!</h1>
<h2>It is { this.date().toLocaleTimeString() }.</h2>
</div>
)
}@mem date( next?: Date ) { return next ?? new Date() }Вот лично мне такое не заходит. Декоратор? Ну ок, только @mem не очень читабельно, непонятно зачем экономить на буквах. А вот дальше совсем не нравится. Почему свойство в функцию то превратилось?
Почему не так? Было бы классно.
class Clock extends Component<Clock> {
@mem
date = new Date();
return (
<div>
<h1>Hello, world!</h1>
<h2>It is {this.date.toLocaleTimeString()}.</h2>
</div>
)
}Ну или так, тоже вполне себе:
class Clock extends Component<Clock> {
#date = new Date();
@mem
get date() {
return this.#date
}
set date(value) {
this.#date = value;
}
return (
<div>
<h1>Hello, world!</h1>
<h2>It is {this.date.toLocaleTimeString()}.</h2>
</div>
)
}Я не хочу свойства функции, мне так непривычно, и просто не нравится))
P.s. Ну и return в теле класса выглядит очень непривычно.
return я забыл в метод обернуть. А функция там потому что в реальности там будет не константа, а получение данных из удалённого хранилища.
class Clock extends Component<Clock> {
@mem date( next?: Date ) {
return new Date( fetchJSON( '/date', next ) ?? Date.now() )
}
@mem compose() {
return (
<div>
<h1>Hello, world!</h1>
<h2>It is { this.date().toLocaleTimeString() }.</h2>
</div>
)
}
}Даже если в реальности данные нужно получить, я бы предпочел держать для этого отдельный метод, а свойство пусть останется свойством.
Еще вопрос как такое состояние шарить между компонентами. Можно ли им в конструктор что-то передать состояние из вне? Как вызвать ререндер при изменении состояния?
Только вот нормальный класс должен был выглядеть вот так (но что-то пошло не так):
class Clock extends SomeObserverBase {
@observable accessor date = new Date();
render() {
return (
<div>
<h1>Hello, world!</h1>
<h2>It is {this.date.toLocaleTimeString()}.</h2>
</div>
);
}
}
Уверены, что приведенные вами два примера кода можно считать эквивалентными?
Чем же плохо ООП?
Он хорош в своей нише. Однако в React отрисовка изначально задумывалась как stateless. Концептуально, React-компоненты это фрагменты, из которых собирается функция для применения React.render(), и они, по логике, так же не должны иметь своего состояния.
Абрамов много экспериментировал с синтаксисическими конструкциями языка, чтобы дать пользователям выразительный и лаконичный API для описания компонентов. Идея с классами была неплохой. Но она позволяла легко выстрелить себе в ногу, когда юзер переставал играть в синтаксическую игру и начинал использовать классы всерьез, как это принято в ООП - пытаясь сохранять какое-то состояние внутри свойств объекта.
Решение описывать компоненты функциями так же является компромиссным - ему пришлось добавить "хуки" и стек для них в рантайме. Но оно ближе к сути и порождает меньше ненужных ассоциаций из обычного опыта разработчиков.
Я полагаю, что на самом деле разработчики React вдохновлялись OCaml, который любят в Meta. В конце-концов у React и ReasonML (вариация на тему OCaml для JS) один автор - Jordan Walke. Однако у чистого JS тут нехватает выразительности, чтобы избавить API от лишнего шума.
Это норма что под каждым постом или обсуждением реакта, есть человек который бесконечно спамит про свою библиотеку?
По теме: Реакт очень хорошая и удобная библиотека, просто многие люди заходя во фронт почему-то пропускают изучение JS, если к тебя хороший уровень JS в реакте ничего сложно не будет, хуки очень наглядные
Библиотека на самом деле хорошая, но Дима в силу каких-то особенностей не считывает как воспринимается его поведение и закапывает этим ее. Он от этого и по жизни страдает (как я это вижу, наблюдал со стороны).
Теоретически иногда бывает примерно такая ситуация:
Ты сделал хорошую программу.
Выложил на GitHub.
Прошёл год, а эту страницу на GitHub'е никто даже не посетил, кроме тебя.
Наверное, автор попал в подобную ситуацию.
Да такое бывает, ты придумал и сделал пироженку, угостил окружающих, но все стройными рядами проходят мимо и идут есть кактус. И что тогда делать?
Задаться вопросом, правильно ли у тебя с восприятием мира, действительно ли это пироженка и кактус :)
Перестать бегать по кругу, сообщая всем, что более развитый инженерный подход это единственное, что им нужно.
Ты не мега корпорация, которая прикрывает собой поддержку фреймворка, который ты обязательно выбрал по ошибке, потому что вот сосед как-то всегда круче.
Весь твой ресурс - это твой интерес к твоему детищу. Единственная возможность популярности - набрать комьюнити, которое примет тебя.
У нас есть пример более менее международного и популярного Yii который подхватили у нас в РФ и который мейнтейнил и пиарил Александр Макаров после того как проект покинул основатель (охладел к php). К Саше как к лицу фреймворка вопросов нет вообще, очень грамотно работает с токсичными вопросами (моими) и аудиторией. Пусть они так медленно шли что фронтенд в целом две революции совершил, но они ведут себя правильно.
У нас есть VUE, который вышел тоже из одних рук и который обрек популярность, за Эваном я не следил, но, как я понимаю, он успешно себя подает как успешного (семья, дети, vue) самодостаточного, цельного, уверенного и гениального разработчика.
Он посветил Vue фуллтайм (вроде), вроде живет на поддержку $ того комьюнити, которое сформировал своим жизненным путем.
И у нас есть б*ть $мол. Яндекс не осилил,а Карловский осилил, но который "ты просто не компетентный, открой глаза, сколько можно есть кактус, да реакт выбирают только д*ебы, даже vue лучше"
Это какая-то не проработанная травма чтоли.. или это наше желание быть услышанными, любимыми, признанными. Или желание сломать и начать строить заново и вот теперь то уж точно правильно... просто надо дуракам объяснить что они дураки.. я не знаю, ну это точно не рабочий вариант. Здесь только строить секту в хорошем смысле как Эван сделал и Макаров (ушел отец-мейнтейнер? Ну и что? Вы же прекрасно видите, что это пример того что прекрасные продукты продолжают жить на поддержке самостоятельно).
Это фреймворк, не библиотека, очень стоит почитать, очень много здравых идей и решений которые кучу проблем решают
Так как @moderator поудалял все мои комментарии, внесу ясность по поводу "спама". Комментариев было 5:
Про Объектное Реактивное Программирование, которое один из комментаторов не пробовал, а потому нагородил чуши. $mol, разумеется, основан на идеях ОРП, но акцент тут был вообще не на нём.
Объективный ответ на вопрос что лучше для каких кейсов, c аргументацией и ссылками на пруфы. Только тут было про $mol.
3 шортса опровергающие тейки местных фанбоев реакта про его неимоверное удобство и простоту. Про $mol тут не было ни слова.
Ну а так как Хабр - торт, а не место для дискуссий, то перечисления пунктов правил, которые я нарушил своими вопиющими комментариями, конечно же не будет.
А потом они ещё обижаются, когда их идиотами называешь...
/me гадает, забанят ли Дмитрия за виртуаловодство.
Hidden text
Можно заметить, что ссылка ведёт на Geektimes. Почему? Потому что при простой ссылке на профиль текст ссылки ("виртуаловодство") игнорируется и ставится текст "@vintage". Если ставить на habrahabr.ru, то то же самое. А вот про Geektimes разработчики забыли.
Только реакта? :D
Мистер nin-jin занимается этим уже очень давно, мною воспринимается уже как традиционная часть хабра. В каком-то смысле его подход даже работает - про $mol я теперь отлично помню. Использовать правда я его конечно не буду. Но про его существование помню!
На самом деле тут теперь два таких человека и две библиотеки
И всё это прекрасно работает в случае простых приложений, но можете себе представить кошмар с обслуживанием, возникающий при создании крупных программ. И винить нужно не jQuery, а аппетиты современных пользователей, которым повсюду требовалась эта интерактивность. В итоге разработчики были вынуждены продолжать использовать jQuery, несмотря на то, что этот инструмент перестал быть удачным выбором для текущих задач.
Могу сказать как человек который начал участвовать в проектах с очень толстым фронтом даже еще до появления jQuery (когда он вышел он прям таки нехило помог нашему тогдашнему проекту монстру с которым мы работали стать кроссбраузерным и слезть с иглы ie6) что реализовать проекты любой сложности можно на чем угодно, главное это прямые руки и склонность команды к борьбе с техническим долгом. А тем более сейчас когда технологий навалили в фронтэнд так много что можно выбирать и это не выбор только из большой тройки, библиотек/фреймворков/встроенный решений полно.
Согласен по первой части. Работал на проекте с angular 7, который мне достался в наследство от другой команды. Компоненты по 3к строк, 5000 any в проекте, неявные изменения состояний через мутации - настоящий ад. Хотя сам angular изначально бьет по рукам, задает структуру и по дефолту включена тонна проверок. Но вот кривые руки решили все это отключить, потому что им было лень писать типы и разбираться в ошибках компиляции. Был и обратный пример - проект на angular Js без typescript. Был написан в 2014 году где-то, попал ко мне на поддержку в 2022. Хоть и ts нет, es5 во всей красе - но все было понятно, потому что были нормально выделены домены, все аккуратно разложено по сервисам и компонентам. И с этим проектом было на порядок легче, чем с первым.
Со второй частью не совсем соглашусь - чем специфичней технология, тем больше рисков. Не найти разработчиков, кто бы согласился с этим работать. Какие-то баги, которые всплывают в самые неподходящие моменты, а создатель библиотеки уже давно забил на свое детище. Отсутствие или неполная документация. Все это сильно влияет на стоимость решения и его поддержки.
Со второй частью не совсем соглашусь - чем специфичней технология, тем больше рисков. Не найти разработчиков, кто бы согласился с этим работать. Какие-то баги, которые всплывают в самые неподходящие моменты, а создатель библиотеки уже давно забил на свое детище. Отсутствие или неполная документация. Все это сильно влияет на стоимость решения и его поддержки.
Этими симптомами страдают все технологии даже те которые сегодня на хайпе завтра могут пасть в забвение, такое происходит постоянно. К тому же как именно пользуются библиотеками и фреймворками это тоже лютая специфика на конкретном проекте. Например я работал на трех проектах с Vue и казалось бы одна библиотека и все должно быть одинаково но нет каждый проект сделан по своему со своими приколами и своими фишками а текущий проект в котором я участвую вообще на Vue3 где все очень сильно поменялось в самом фреймворке.
так что Angular не только первым предоставил нам набор функций, но и стал реальным фреймворком, на котором можно было создать веб-приложение.
Вообще-то был уже ExtJS. Он стал фреймворком ещё до того как в JS классы появились. Там из коробки было столько всего, сколько ещё потом десять лет в другие завозили. А умер он потому что 5к баксов за лицензию на человека в год и отсутствие перехода на ES6 классы в своё время.
Автор либо слишком молод, либо тогда не интересовался всем этим.
Умер? До сих пор то там то сям его встречаю. С популярностью Реакта не сравнить, но версии релизят.
Тоже помню этого "монстра". Хотя я в 2014 только начинал, когда заглянул в генерируемый им код, то сразу понял что страдать поддерживая это безумие лично я не буду. У простой кнопки вложенность как у настоящей мартешки. Вот именно тогда я познакомился с понятием "ООП головного мозга".
А чем это хуже вложенности компонентов? Просто вместо функций классы. Можно сказать что стейта нет расшаренного, но вот статья говорит что всё тоже самое.
Там вложенность была потому что каждый уровень что-то давал и при создании своего компонента можно было выбрать на сколько низкоуровнево или высокоуровнево ты хотел иметь в базе. Самый низкий уровень - обертка над хтмл с шаблонизатором, почти JSX. Выше обычно уже уровень UI с конфигурацией, так называемые компоненты. Далее докидываешь миксины типа эвент-эммитерра и прочего, но если нужно. Дальше были всякие контейнеры или кнопки. Но были и ещё более составные - панель, которая имела контейнер в середине и бары по краям с кнопками. Ну и всякие там ресайзы, тоглы и всё чего надо. Только вместо JSX объекты-конфиги JS. Не так красиво, но и отдельный язык не нужен, ни какой транспиляции и прочего. До появления ES6 было неплохо.
По факту концептуальная идея та же. Кстати, там была возможность выбирать тип биндинга - MVC, MVVM. Можно было по олдскулу на эвентах. Также можно было пропсы прокидывать.
Но уровень входа был резко сложным, это одна из причин смерти. Хотелось брать и просто писать UI, с ходу. А ExtJS надо было изучать сидеть долго. Так ещё и скачать бесплатную версию сложновато было, ну и вырезание платных функций из бесплатной документации это прикол. Фреймворк убил менеджмент. Сейчас оно живое, но это зомби.
Прямо сейчас на нем делаем продукт. Вся логика на тайпскрипте, extjs просто дергает методы модели и слушает события, ну в целом как и должно быть в любом ui приложении. Каких то проблем с ооп не имеем, так как у нас есть деление на классы логики, которые тру классы, и классы компонентов, основанные на extjs схеме. Почему extjs? Да потому что с точки зрения компонентов, у него просто нет альтернатив: дата гриды, лейауты, деревья, меню - в остальных библиотеках это детский сад.
Собираем это всё через webpack, сам бандл extjs подключается как глобальная зависимость.
Большинство людей которые пишут на реакте не понимают что это именно библиотека для отображения UI. Из за того что у них нет технического бекграунда(в большинстве своем это именно так и есть, реакт выбирают вкатуны из за низкого порога входа). Если вы хотите реализовать MV* паттерн, то нужно понять что реакт это именно V, т.е. в компоненты должны прилетать уже готовые данные. И многие не понимают как все собрать в кучу и делают все что предлагает npm. следовательно проект превращается в кладбище пакетов и жирнущую реализацию flux архитектуры, поверх которой накрутили уже всяких FSD, Atomic design и т.п.
Что бы избежать всего этого ужаса, достаточно чуть чуть пораскинуть мозгами и почитать умных книжек. К примеру, для реализации mvvm паттерна, можно взять сигналы или rxjs, написать хук биндер, который свяжет стейт jsx и данные модели и будет вам счастье. вы сможете писать отдельно бизнеслогику не перегружая реакт. Добившись того что большая часть проблем описанных в статье просто пропадет
rxjs
А это точно удобно и просто?
сигналы
Это те самые, которые во вью уже много лет имеются, причём более жирные по функциональности, но в остальных экосистемах выдаются за инновацию?
А это точно удобно и просто?
Пробовал такое на небольшом проекте в 2015-м году, (тогда вроде как реакт еще не перешагнул за 2.0, сейчас уже не помню). Я тогда посмотрел на редукс и другую муйню, что предлагал сам фейсбук и другие "идеолухи" ФП, и уже тогда понял, что с этим будут проблемы. И вот они уже почти 10 лет из пустого в порожнее переливают 😁 Взял тогда react+rx, потому что ангулар был вообще трэшаниной, а jquery мне надоел, хотелось нового... На jquery до этого имелся опыт двух средних по размеру проектов. Один проект писался "как есть", без всякой доп обвязки, на голом jquery. В целом там получился довольно запутанный код, но все же читаемый и поддерживаемый. А вот второй я делал уже на своем собственном фреймворке, который содержал подобие компонентов на jquery и был реализацией mvc, где "компоненты" отвечали за V. И это не плохо работало, хоть было очень "наколеночной" реализацией. А реакт меня сначала очаровал тем, что это были компоненты из коробки. Но попробовав на маленьком проекте, сразу выявились беды с отладкой и местами непредсказуемое поведение. В итоге чувства остались смешанными. До сих пор считаю, что без rx это вообще не юзабельно. (Недавно наш фронтэндер провел для меня экскурсию, как у него устроено все вокруг реакта, я мало что понял, но то что у него каждый компонент сам дергает апи, я увидел, и был этим несколько озадачен. А теперь вот выясняется, что я такой не один 🤣) А потом они ушли с классов, а я ушел в чистый бэкенд 😁
А это точно удобно и просто?
Почему это должно быть сложно? ангуляр живет с этим и проблем не наблюдается.
но в остальных экосистемах выдаются за инновацию
С каких пор использование инструмента по назначению это инновация? реакт это библиотека для рендера. Всегда было непонятно почему все считают его серебренной пулей и жалуются что в него не пичкают ненужным ему хламом.
Ангуляр в последних версиях как раз ушёл от rxjs.
Не ушел, а дополнил.
Во первых, как более простая альтернатива для синхронных изменений, и чтобы мягко приучить к реактивным концепциям, тех что сломал зубы с наскока об rxjs.
Во вторых, чтобы в будущем выкинуть zone.js, changedetection и всю эту binding магию.
в данном случае это не важно, важен сам факт успешного применения подхода. Все реактивные либы +- одинаковые, как и di контейнеры.
Я согласен, что mvvm отлично ложится на Реакт, если его использовать для View - и можно например с Mobx, эта связка еще раньше Vue показала, насколько удобно работать с реактивностью. Но в этой связке реактивность "покомпонентная", а не "поэлементная", то есть ререндерятся хоть и целевые компоненты, но целиком - так Реакт работает.
жалуются что в него не пичкают ненужным ему хламом.
А вот здесь наоборот - пичкают и очень активно ненужным хламом, от тьмы лишних хуков до серверных компонентов. Лучше бы сконцентрировались на View, уменьшении размера, увеличении перфоманса и возможности полноценно интегрировать сторонние системы реактивности.
Хуки нужно воспринимать как промежуточное решение, я бы сказал - тестирование концепции, насколько я помню, скоро все сведется к одному хуку use. Если юзать compiler то против вообще можно будет забыть. Северные компоненты сильно упрощают жизнь, особенно если приложение работает на сервере. Так что формально там лишнего нет. Всё необходимое для рендера.
увеличении перфоманса
Всегде интересовал вопрос - что вы там такое делаете все, что вам так дико нехватает перформанса?? у вас там что пользователи заполняют формы быстрее чем реакт инпуты рендерит? вы где то на глаз замечаете эти сотые секунды задержки между вводом и ререндером?
и возможности полноценно интегрировать сторонние системы реактивности
Никто вам не мешает использовать для бизнеслогики стороннюю реактивность, от самописной до сигналов. если вы хотите заменить потроха реакта на [любая реактивная библиотека], то возникает вопрос - зачем? И предположу, что любой ваш агрумент будет сводится к тому что вы хотите замешать кучу лишний логики в слой отображения. Которой там быть не должно.
вы хотите замешать кучу лишний логики в слой отображения
Как правило, делается это отчасти потому, что отправка интерактивных изменений на сервер, вычисление там нового состояния, получение этого состояния по сети и перерисовка окажется значительно медленнее, чем перевычисление этого же состояния на клиенте, даже если это кажется «архитектурно неправильным». Подобное можно и в онлайн-играх увидеть.
Причем тут сервер? Раговор про фронтовое приложение,в его архитектуре так же есть бизнеслогика, она специффична именно клиенту, но она есть и она не должна быть в слое реакта.
export const useReactiveProperty(property: ReactiveProperty) {
const [state, setState] = useState(property.value);
useEffect(() => property.observe(next => {
setState(next)
}), [])
return state;
}Накидал пример кода как подружить реакт со сторонней либой, Всю реактивность можно запишнуть в DI контейнер и там сохранить бизнеслогику. вызывать апи клиенты, проводить валидации и тп. а из контейнера выставлять именно реактивные пропсы, таким образом на реакт слой прилетают только пропсы и колбеки. Все делается элементарно и не нужно ничего выдумывать. Вместо di контейнера вы можете использовать mvvm, тогда этот хук будет для него binder'ом, а модель может быть рукописным классом
сигналы
Это те самые, которые во вью уже много лет имеются, причём более жирные по функциональности, но в остальных экосистемах выдаются за инновацию?
Это те самые, которые придумали еще в нокауте.
но в остальных экосистемах выдаются за инновацию?
...например, в экосистеме JS, где их планируют нативно добавить. Почему-то Vue такого эффекта не произвёл.
Честно говоря, доводы у автора какие-то сомнительные.
Автор упоминает Redux, но говорит, что в него не углублялся. Далее продолжает осуждать передачу состояния через контекст. При этом, тот самый менеджер состояния (Redux, Mobx и другие) забирает на себя большую часть бизнес логики. Запросы, синхронизации и т.д. Оставляя самим компонентам только переменные ВИЗУАЛЬНОГО состояния. Которые либо вообще не пробрасывются в детей, либо опускаются только на один уровень. Вот тебе и разделение на View и Model.
Проектируюя фронтовое приложение (а не страничку) не получится ограничится только лишь одним реактом. Либо тебе придется писать компоненты высокого уровня, следиться за провайдерами и перусложнаять код.
Но автор опускает эту тему, пытаясь вилкой съесть гороховый суп.
Но в конце статьи, автора задаёт вопрос: " а зачем нам вообще нужен гороховый суп, если можно уменьшить количество ингредиентов и будет вкусный свежий горох без бульона"
Согласен с автором, что если у тебя простейший одностраничник - можно вынести всю логику на бек. Но современные интерактивные web приложения в таком подходе проиграют, потому что пользователь зажрался. Пользователю нужна интерактивность, попапы, UI как на мобиле и чтобы все светилось. Но. Пользователь платит деньги. И он будет платить тем, у кого удобнее и красивее.
Вот и получается, что менеджеры ничего не понимают, им нужно больше кнопок, но приложение, которое делает всё понимающий разработчик с одной кнопкой - никто не покупает.
Фронт и правда переусложнен. НО React это не весь фронт. Это библиотека которая хорошо делает свое дело в создании реактивности.
А вот пихать в него бизнес логику, это уже пытаться есть гороховый суп вилкой.
Могу быть где-то не прав, но это лично мой взгляд на ситуацию с позиции React разработчика.
А хорошо ли? JSX - это неудобно, давайте будем честны. Он нужен в одном компоненте из тысячи, когда требуется действительно сложный процедурный рендеринг, в остальных случаях приходится жить со стрёмным синтаксисом и кривыми идиомами. Только условный рендеринг на JSX чего стоит.
Про экосистему отдельный разговор вообще. Наличие обширной экосистемы, когда приходится каждый раз заново выбирать из пятёрки одних только стейт менеджеров, не говоря уже об остальных библиотеках, без которых приложение не получится собрать - это, скорее, минус, чем плюс.
Ну и реактивность, которая отваливается по поводу и без, тоже удобства не добавляет.
Пользователю нужна интерактивность, попапы, UI как на мобиле и чтобы все светилось. Но. Пользователь платит деньги. И он будет платить тем, у кого удобнее и красивее.
Не заплачу. Как же задолбали эти 100500 бесполезных уведомлений. И как же я устал от этих ваших мобильных интерфейсов в десктопном браузере, когда у тебя вся страница занимает всего 10% ширины экрана.
P.s. Извиняюсь, наболело.
Я наоборот, люблю React. Прост, удобен, понятен, гибок. Причём я не супер крутой спец и много ещё не (идеально) понимаю. Вот Ваш пример с useEffect. Одно вызывает другое, потом третье, потом четвертое. Ну и что в этом плохого? Можно вызвать хоть 100 раз в одном компоненте и они всегда будут ожидаемо вести себя и влиять на состояние и.т.п. Резюмируя, есть простота использования при некотором хаосе под капотом. Главное с пониманием использовать те или иные решение, как и везде впрочем.
Со своей стороны могу сказать, что мне, как новичку в UI больше зашел Vue чем React.
Причины простые - тут простой шаблон на базе привычного HTML, привычный CSS, привычный JavaScript. Из коробки есть все нужные кубики и не нужно заморачиваться ни с какими либами/зависимостями.
Кривая входа в React выше и пока не понятно какой профит в итоге от этого будет.
Профит только в том, что эти кубики заменяемы по усмотрению, т.е. гибче. Но это же и недостаток: сторонние либы регулярно устаревают: либо всё через адаптеры, либо регулярно будешь бегать и чинить несовместимости. Особенно весело, когда какой-нибудь react-router в очередной раз решает поменять форму записи своих роутов, и ты как дурак носишься по всей иерархии маршрутов и переписываешь, потому что чувство прекрасного у автора либы взыграло, и он решил всё переназвать.
Не понял про "бегаешь и переписываешь все маршруты". Их же можно хранить в отдельном файле/классе и править лишь в нём. Ну и с кастомными либами просто чуть избирательнее быть. Зачастую можно (лучше) обойтись своими решениями, чтобы не зависеть от чего-то шаткого. Вопрос архитектуры. Просто мнение, не спорю...
А возможность у вью2 интегрироваться в уже готовый Легаси? Подключил и фигач на чистом js с реактивностью и компонентами. Красота.
Ого, спустя десять лет об этом наконец можно говорить и не бояться получить ушат помоев только за то, что мнение отличается от мейнстримного нарратива от евангелистов и смузихлёбов, мол, реакт - это для beautiful complex awesome projects, а вот всё остальное - это плохо.
Если уж говорить о фреймворках, то Vue, начиная со второй версии, в любой момент своей жизни был на голову выше, чем конкурирующие фреймворки. О чём говорит хотя бы тот факт, что ангуляр и реакт пережили по три смены парадигмы и паттернов, в то время как Vue пережил одну, и то с сохранением обратной совместимости. При этом по удобству использования ни реакт, ни ангуляр не приблизились к вью.
К слову, фреймворк, который тут нельзя называть, но у которого есть свой отдельный хаб, за 10 лет не потребовал ни одной смены парадигмы, но до сих пор является более прогрессивным. У меня даже есть сравнительная табличка кто у кого когда что потырил из фичей, а что до сих пор не осилил. Но пруфов не будет, за них банят.
Как человек посторонний и довольно далёкий от фронта, но много лет наблюдающий конкретно за Вами, могу дать один непрошенный совет (который Вы проигнорируете), но который ценен именно тем, что описывает впечатление "со стороны", не предвзятое.
Я вполне допускаю, что $mol это очень достойный проект, как минимум не хуже своих основных конкурентов. Но единственное, что его может спасти (точнее, сделать заметно популярнее) - это ребрендинг и полное отстранение лично Вас от общения с коммьюнити. Для коммуникации этому проекту нужен совершенно другой человек, который умеет разговаривать с разработчиками так, чтобы не агрить их на пустом месте. Софты не просто важны, они критичны - пока пользователи Вашего продукта это обычные люди. Это обидное (особенно для крутых технарей), но это факт.
Что ж, позволю и вам дать непрошенный совет: как только найдёте этого прекрасного человека, направляйте его ко мне. Я тогда смогу совсем расслабиться и ничего не делать.
Вообще, всегда забавно наблюдать, как люди без чувства такта раздают непрошенные советы, как другим тактично себя вести.
Эк вам правда глаза-то колет...
@nin-jin, давайте рассмотрим гипотетический пример.
Некий разработчик решает попробовать $mol в своём проекте. В процессе работы он натыкается на ошибку или неправильную работу вашего фреймворка -- как он сам думает. Он пишет вам письмо, где описывает свою проблему и просит исправить ошибку во фреймворке. Вы получили это письмо. Какие будут ваши дальнейшие действия?
Как фронтендер/фулстак с 10+-летним стажем, я полностью согласен с автором. И это он ещё не лез в redux, не выбирал из 20 библиотек для стейт менеджмента, валидации форм и дата фетчинга, не видел ужасы nextjs, graphql, не писал костыли через кастомный webpack config. А самое веселое это апгрейды старых библиотек, где все ломается каждую версию. Но, как говорится, что нас не убивает 😄
React вообще афера какая то 😄 Его продали под соусом простоты и низкой кривой обучения с красивыми хеллоувордами в документации.
А когда народ на нем начал делать реальные задачи, оказалось что архитектура это не предусматривает и распахнулся ящик Пандоры, со всеми этими дикими способами решить проблемы.
Ещё один ящик Пандоры открыл Эдди Османи, когда предложил с помощью реализации TodoMVC сравнивать фреймворки. В нём не была учтена асинхронная работа реального приложения, а потому TodoMVC, использующий чистый Redux, выглядел проще конкурентов, которые сразу проектировались с поддержкой асинхронных операций.
Скажу честно, я не пробовал React, но я пробовал и jQuery, и Vue, и Angular.
Мне, как человеку с Java бэкграундом, Angular (тогда это был Angular 6) сразу показался наиболее понятным и удобным из всех. Да, он требует потратить немного времени изначально на когфигурацию приложения, зато потом все работает отлично и легко. C тех пор использую его во всех своих проектах (последний раз работал с Angular 17). Не вижу смысла переизобретать то, что и так отлично работает.
Не так давно на работе в соседнем проекте (тоже Angular) коллега использовал NgRx ("inspired by Redux"). Худшего опыта в попытке разобраться в этой каше из эффектов, экшонов, селекторов и редьюсеров у меня в жизни не было. Буквально несколько дней я потратил, чтобы отрефакторить фичу в приложении - все из-за максимальной неясности происходящего. В обычном Ангуляре работы было бы на несколько часов.
Я тоже как backend разработчик которому пришлось работать с фронтом, очень полюбил ангуляр. Он выглядит более собранным и целостным что ли.
Также как бэкендер, теперь уже фулстэк подпишусь, Angular выглядит наиболее адекватным из крупных фреймворков для фронта.
человек с ООПшным бэкграундом расхваливает ООПшный фреймворк, в котором ему оказалось привычно по синтаксису. это настолько само собой разумеющееся, как если бы веган нахваливал овощи
NgRx - это самая страшная вещь, с которой мне приходилось сталкиваться, такая, с налетом мазохизма, когда ты добавляешь себе страданий, чтобы якобы решить то, чего и не было.
Ерундой занимаетесь. Вы должны понимать что каждая библиотека или фреймворк служит какойто цели и создавалась изначально в ядре под конкретную задачу а уже потом дорабатывалась. Так что считать что что-то одно хорошо непродуктивно. У каждого решения есть преимущества и недостатки. Архитектор должен уметь их правильно балансировать под задачу.
PS: методы в setState в примере имеют потенциальные проблемы. Потому что не используют функции в setState. Проблема в том что код асинхронный а вызовы выполняются параллельно! И возникает проблема когда потоки в параллеле могут модифицировать одинаковую переменную. И это происходит в useEffect!
React это фреймворк наоборот, в нем тэги компонентов используют сильное зацепление в отличии от гибкого и расширяемого html. При этом с бизнес-логикой они обычно законекчены слабосвязными решениями. Вместо упорядоченного ООП структурирования API - кусочки хуков и колбеков с явным перечислением зависимостей и максимально усложненным переиспользованием. Вместо прозрачных декораторов - явный вызов оберток типа useMemo. Вместо DRY дублирование имен на входах и выходах. Вместо наследования при объявлении - локальное переопределение при деструктуризации. Вобщем, каждая единица реакт-мира построена на каких-то антипаттернах и ошибках проектирования.
Вы забыли смешивание html и js в одном файле)
некоторые и стили хардкодят, вообще фронт полон таких решений, где-то сочиняют какой-нибудь бэм, который тоже наоборот относительно суммы класснеймов применяемой в любом CSS-фреймворке. Где-то на класснеймы мапят отдельные проперти со значениями типа "отступ 5 пт" хардкодя стили в верстку. Кто во что горазд получается. Только разработчики-потребители этих технологий ходят от проекта к проекту построенному вокруг таких решений набивать новые шишки.
Неистово плюсую. React - отстой, я постоянно это говорю. Люди, которые сделали facebook не способны делать что-то логично! :)
Если серьезно, то главная проблема React, на мой взгляд, это нарушение принципа единства ответственности. Компонент в React отвечает за рендеринг, за хранение состояния и реактивность. Поэтому React не библиотека и проекты на нём по своей сути одинаковы. Будь это библиотека, то он бы выдавал наружу некоторое апи для шаблонизации и отдельное апи для взаимодействия с реактивным состоянием. Тогда разработчик мог бы какой угодно фронт, и даже реактивный бэк написать. В реакте же это не так, реактивность и хуки гвоздями прибиты к компонентам, поэтому разработчик к представлению прибивает логику.
Так в Ангуляр также компонент отвечает часто за состояние (если не выделен сервис) и реактивность (rxjs). Но на мой скромный взгляд в Ангуляре нету хаоса - есть класс компонент, ты можешь в нем хранить Стейт, можешь добавить тут же реактивность для данных. Есть отдельный шаблон. Если надо, ты можешь унаследовать функционал компонента (мы так делаем в проекте — наследуем компонент для мобилки, но верстка для него отдельная, можно эффективно переиспользовать бизнес логику компонента).
Я по большому счету согласен с вашими доводами. Представьте если вынести управление стейтом из Реакта чтобы можно было использовать любой стейт менеджер. Убрать хуки и ре-рендеринг. И оставить только две функции: create и update DOM элементы. Получится простой и без скрытых уровней абстракции максимально гибкий и скоростной подход к разработке фронтенд приложений.
const ClickCounter = ({ count = 0 }) => (
<button click_e_update={() => count++}>
Clicked {() => count} times
</button>
);
но все об этом молчат
Не все. Но голос разума теряется в шуме толпы. Остальные популярные фронтенд-либы, кстати, тоже говно. Они либо заигрывают с сомнительными паттернами, которые уже стали привычными для реакт-фанбоев, и поэтому считаются "проверенными", либо городят излишние слои непрозрачных абстракций с "черными ящиками", где творится вся "магия". Там, где есть простые и эффективные решения, нагородили огородов и при попытке решить задачу чуть в стороне от банального SPA и формошлепства - ты постоянно упираешся в ограничения, просто на ровном месте. Смотря на весь этот цирк, я написал свою либу и кайфую.
У меня неоднозначное отношение прежде всего к JSX. Я профессионально с реактом не работаю, только поверхностно сталкивался, но JSX у меня вызвал вопросы. Во-первых, как я понимаю, в реакте нет HTML, вообще нет, есть только js-код, а то что кажется html-кодом, это лишь синтаксический сахар, который всё равно под капотом заменяется функциями. Компоненты - это конечно удобно, но как быть с отделением представления от логики? Можно ли JSX код отдать верстальщику? Или программист должен заниматься и версткой? Извините, если вопрос глупый, просто интересно узнать, как обстоят дела с версткой реакт-компонентов в компаниях, кто занимается версткой?
Фронтенд верстают сами фронтендеры, которые же и пишут потом логику.
Лично я считаю, что в любом случае промежуточное звено в виде верстальщика — устаревший подход, поскольку такая вёрстка чаще всего подходит для подключения логики. Но давно уже в проектах веб-приложений вёрсткой приложения занимаются те же фронтендеры.
Но давно уже в проектах веб-приложений вёрсткой приложения занимаются те же фронтендеры.
Но это же выходит дороже. Обычно бизнес идет противоположным путем: разбивает процесс на простые части и нанимает дешевую рабсилу. А реакт-разработчики далеко не дёшевы. Получается, из пушки по воробьям?
Нет. Главным образом потому что в веб-приложениях вёрстка и поведение компонентов довольно сильно сцеплены. Следовательно, неправильная вёрстка потребовала бы от разработчика возвращать задачу на переделку верстальщику. Это невероятно усложнит и замедлит процесс. Кроме того, любые последующие правки чаще всего потребуют взаимодействия верстальщика и разработчика. В то же время поддержка современных фич в браузерах и их совместимость всё же стала значительно лучше, чем в эпоху господства IE 5-6, а потому для многих задач какого-либо невероятного мастерства и умения делать хаки в CSS больше не требуется. Наконец, раньше верстальщик шёл перед бекендером, который занимался совсем другой работой, а теперь фронтендер непосредственно специализируется на реализации задач в браузере, причём хороший фронтендер знает, когда задачу лучше решить через CSS, когда лучше использовать нативные функции Web API и когда нужно манипулировать DOM через фреймворк.
Да, обычно верстальщики справляются
Мешать представление и логику всегда плохо, в JSX логику не делают.
То что там не html - позволило создать react native - по сути реакт мэпит компоненты в платформенные примитивы.
Компоненты - это конечно удобно, но как быть с отделением представления от логики? Можно ли JSX код отдать верстальщику?
Можно, но верстальщику придётся учить JSX :-)
Вообще, JSX был хорош прежде всего тем, что он очень легко статически типизируется, остальные форматы шаблонов подтянули типизацию куда позже, если вообще подтянули. Но да, если в команде есть отдельный HTML-верстальщик, то переход на Реакт будет не самой удачной идеей.
Я думаю что для написания кода любой сложности с использованием реакт нужно использовать всего несколько дополнительных библиотек и подходов.
SWR/tanstack query. Мы не делаем никаких явных запросов в компонентах. Мы говорим что в этом компонента нам нужен ресурс по определённому ключу. Это позволяет описать в компоненте от чего он зависит, но не городить логику запросов. Она сама отработает.
Zustand. Создаём мелкие сторы, там где не хватает useState в одном компоненте. Не надо поселять большой редакс, и доставать оттуда данные.
Глобальные переменные прокидываем через контекст. Таким образом легко будет писать тесты.
Вся логика хранится в хуках. Вообще всё что не js, то код в хуках. Хуки комбинируем как угодно, как и остальные компоненты в реакте. Не забываем чтобы хук не зависили о глобальных переменных
В итоге получаем максимально модульный и тестируемый код. Вроде даже и не много абстракций получается
Можно и я вставлю свои пять копеек? Фреймворки — они же про разный подход, а не просто синтаксис. React — разбивай на компоненты. Vue — пиши меньше, работает само. Angular — всё включено, но по строгим правилам. Svelte — вообще без лишнего кода. Solid — React, но быстрее. jQuery — просто работает.
Реакт очень крут, если использовать его к месту. Другое дело, что в 99% случаев он совершенно не к месту. Мне доводилось делать много проектов с CSR, SSR и даже на React Native. Изначально в нём души не чаяли и пихали, где ни попадя. Но потом начались вопросы но попугаям в pagespeed insight и по цене хостинга. Решили с одного проекта выпилить реакт и рендерить всё по старинке Друпалом, то есть php + twig. В результате клиент переехал на хостинг, который втрое дешевле, pagespeed стал зелёный, а все доработки по сайту стали делаться в разы быстрее.
Второе разочарование было, когда разрабы next.js признали, что SSR на реакте невозможно сделать приемлемо быстрым, поэтому надо пользоваться SSG. Сама идея сгенерировать статику для сайта с хотя бы 100 тысяч страниц звучит дико.
Но оставалось понимание, что если нужна вот эта вся интерактивность и реактивность, то без реакта никуда. И вот прилетает задача сделать фронт для чатбота с этими модными LLM и RAG. Целый час думал, надо ли реакт, потом думаю напишу на ванильном js. 8 часов работы, 500 строк кода, ноль внешних зависимостей и всё работает. Отправляет сообщения, синхронизирует диалоги в разных вкладках, при переходам по страницам сохраняет состояние.
Единственное, где лично мне реакт ещё нужен - это в мобильной разработке, потому что я недостаточно хорошо знаю Java или Kotlin, поэтому там меня React Native отлично выручает. Хотя если делать что-то серьёзное, всё равно придётся лезть в нативный код. А там уже наловчишься со временем и никакой реакт не будет нужен.
Реакт мёртв, виртуал дом не нужен и не справился с тем, что обещал
обёрткой для (тогда довольно паршивых) HTML DOM API
А сейчас, типа, нет? JS это, возможно, наиболее массовый язык из всех функциональных, и сам бог велел сделать функциональный DOM API, но вместо чейнинга и лямбд в браузерах нам предлагается лютая императивщина, подразумевающая использование циклов и переменных. Ну да, в какой-то момент осчастливили: теперь не надо парсить запросы на языке селекторов самому, чтобы получить элемент, но этого, извините, недостаточно, чтобы не считаться паршивым.
А вот у интерактивного UI, который мы реализуем в веб-среде, потенциально может быть бесконечное число входов и бесконечно много выходов. Как вообще можно ожидать реализации всего этого в виде чистого кода? […] Какую бы технологию вы ни выбрали, она неизбежно скрючится под гнётом невыносимой сложности реактивных UI.
Прикольно, конечно. Люди десятилетиями писали UI и не ныли. Написали такие вещи как 3DStudio MAX, AutoCAD и Microsoft Word. Как-то осилили. Но потом пришли зумеры и началось: «Какую технологию не возьмём, всё пулемёт выходит. Ой-вей, да это просто UI такой сложный, что хорошо не написать!» А раньше как писали? А?
Я вам сейчас расскажу, как. Потому, что «веб-среда» не вносит в вопрос НИЧЕГО нового. Даже latency между сервером и клиентом сейчас примерно такая же, какая была в начале (в 90-х) между слоем UI и слоем бизнес-логики на одной машине. UI есть UI, а бизнес-логика есть бизнес-логика, и не важно, где она — в соседней dll'ке или на удалённом сервере. Нормально проектируй — нормально будет.
И во времена, когда UI и бизнес-логика были на одной машине, разрабы, как и сейчас, тоже были двух сортов. Одни строили UI в рамках архитектуры, основанной, например, на подходе «документ — представление», и это был прекрасный способ управлять сложностью. А другие брали C++ Builder, Delphi или VB и пытались создать UI на основе готовых компонентов. Обычно чужих, а если и писали свои, то по тем же чертежам, то есть изолированные чёрные ящички, не поддающиеся сквозной обработке. О да, КОМПОНЕНТЫ. Они кажутся прекрасной идеей, пока ты из кубиков лего собираешь автомодельки, но когда тебе надо создать настоящий взрослый автомобиль, дети со своими кубиками пролетают. Я помню, как когда-то написал сложную систему с 2D- и 3D-представлениями одного документа (с табличными данными) и уволился. А потом через год вернулся обратно и ошалел. Когда людям понадобилось дописать такую малость, как подписи к цветовым обозначениям (визуально это табличка, которая находится в слое поверх отображаемых графиков, и юзер её перемещает с места на место, пришпиливает к краям и т.п.), то сделали это в виде ActiveX-компонента (!!!). Представляете? Полноэкранный режим Direct3D с трёхмерными графиками, а сверху наляпан ActiveX-компонент, который мыргает, роняет fps, а при перетаскивании оставляет за собой неперерисованный фон, и никто не знает, как это исправить. Ах да, и помимо чисто технических проблем, описанных выше, нагорожено турусов на колёсах, чтобы синхронизировать цвета с основным представлением.
Лично я ещё тогда испытал все эмоции, связанные с тем, что «от компонентного подхода (а не React!) веет безумием», и сейчас только рукой машу. Сейчас просто разработчиков в целом стало сильно больше, чем раньше, и любителей компонентов тоже стало пропорционально больше. А может, и непропорционально.
О да, КОМПОНЕНТЫ. Они кажутся прекрасной идеей, пока ты из кубиков лего собираешь автомодельки, но когда тебе надо создать настоящий взрослый автомобиль, дети со своими кубиками пролетают.
Вообще-то, современные автомобили именно из компонентов и собираются. Разумеется, это не детские кубики, а специальные, предназначенные для автомобилей.
Полноэкранный режим Direct3D с трёхмерными графиками, а сверху наляпан ActiveX-компонент, который мыргает, роняет fps, а при перетаскивании оставляет за собой неперерисованный фон, и никто не знает, как это исправить.
Ой, кажется тот, кто писал рендер на Direct3D, забыл обработать событие WM_PAINT...
Ну и, уж извините, не верю я в просадку fps просто из-за ActiveX-компонента. Там явно были проблемы с чем-то ещё. Кстати, зачем вообще fps при отображении графиков? Это ж статичная картинка!
Тогда возникла тенденция к использованию односторонних привязок (сверху вниз), что с технической стороны звучит как более удачное решение, но на практике только всё усложнило и привело к дискуссии, которая кончилась тем, что сегодня мы используем Redux.
Причина в использовании redux в другом. Это чисто исторически сложилось. Когда появился react он хайпанул, все кинулись его изучать, штука была новая и как передавать данные между разными частями приложения не особо было понятно. Сначала был flux, потом уже Дэн Абрамов явил миру redux, который на тот момент стал самым понятным инструментом для описанной задачи. Потом хайп react возвёлся в степень хайпа redux и интернет наводнили десятки(или даже сотни) курсов react+redux. Выпускники таких курсов вышли в реальный мир с ощущением, что react может быть только с redux'ом, так ещё в этот redux начали пихать вообще всё (даже какое-то одно состояние, которое нужно только какому-нибудь небольшому компоненту локально)
При чём redux изначально был... сильно ну такое себе. Собственно даже сам Абрамов признавался, что ему redux не нравится. И вообще он его изобрёл на коленке для какой-то презентации и "так вышло, что все эти начали пользоваться".
Ну а как надо? Это тот же самый event bus, просто со стейтом. А так вариаций хватало и до него. Постоянно возникает задача в сколь-либо сложном приложении, что надо из дерева компонентов повлиять на соседний, который и не дочерний, и не родительский (в одной вкладке получили результат, хотим отправить в другую вкладку в качестве входного параметра, например).
Можно прокидывать стейт/сеттер/сигнал-слот в оба сверху, и получится лесенка из параметров функций. Нужен ещё один? Добавляем в обе лесенки, красота, ага. А можно использовать контекст как в реакте, и кстати, контексты — это наверно самая крутая фича в нём, этакие глобально-локальные переменные, которые ещё и вкладывать друг в друга можно. Ну и редукс, по сути, просто глобальный контекст, который можно кусочками вытягивать в разных компонентах, равно как и useDispatch близок к сигналам в каком-нибудь Qt, а useSelector — к слотам.
Где мы свернули не туда, один идиот потратил пару дней, чтобы написать что он тупой и не смог в нормальный Реакт, другой потратил время на перевод. Каюсь и я не удержался, строчку вот комментарий. А на деле то все просто: не нравится - не ешь, пиши на волшебном Ангуляре, где в 24 или 35-м уже релизе не могут определиться, как данные связать, Input/Output/RxJS/pipes/maps/signals и http.get не делающий запроса на сервер :-)
Почему бы не писать тогда на Vue или каком-либо ещё фреймворке?
Input/Output/RxJS/pipes/maps/signals
Странно видеть от фаната реакта.
И нормальный реакт это какой?
А типа реакт как УАЗ буханка (сразу вышел идеальным) и его не болтает от края к краю проруби от релиза к релизу?
классы круто!!! -> классы говно, это ж очевидно!
redux круто!!! -> redux говно, это ж очевидно!
А еще там, кстати, уже определилсь как работать с CSS?
Мне тема интересна и я понял, что Ангуляр - сложен для новичка, React - не фреймворк, а библиотека (и не стал его учить, хотя по количеству вакансий он гораздо востребованнее), и в результате для себя выбрал Vue. Другие (Svelte, например), тогда только только появились.
Автор, а какие альтернативы рассматривали? И что выбрали в итоге?
Можете кидать в меня камнями, но большинство фреймворков вообще избыточны и многое можно создать без них на js/ts. Единственное для чего нужны фреймворки - библиотеки компонентов и разный сахар, что позволяет делать проекты быстрее. Однако какой ценой. Вы в папку node_modules пустого проекта на том же react давно заглядывали? Поизучайте на досуге сколько там мусора на несколько сотен мегабайт и всё это тянется в конечные билды. Имхо, но оно того не стоит. Да, можно стать богом оптимизации веб пака и vite, "обвесить" их десятками плагинов, но это не спасёт от попадания мусора в билды. Лично мне бы хватило пачки готовых компонентов под чистый ts на котором можно спокойно реализовывать бизнес логику, как удобно. Хоть в функциональном стиле, хоть в ООП, что лучше для того или иного проекта. Однако, я больше бэкендер и может, чего-то не понимаю.
Вы предлагаете изобретать велосипед, а не брать готовый. Потому что по мере разработки крупного проекты, велики шансы столкнутся с проблемами и роутинга, и запросов, и кеша, и ререндинга, стейтов, формы, валидации и .т.д. придётся всё это писать самому.... а если понадобится ssr можно еще и свой nextjs изобрести...
Если писать на современном Vanilla JS, то эти проблемы не возникают. Все описанные проблемы возникают из-за самих JS фреймворков, которые призваны их решать.
Пишите, сначало сделайте генератор openapi на typescript - чтоб генерить готовый апи и модели например. Потом напишите authjs или betterauth. Ссылки можно добавить сюда я согласен контрибутить в ваши проекты.
Такое чуство что вы кроме 5 страничных проектов ни чего более крупного не пытались делать....
сначало сделайте генератор openapi на typescript
Что? Для таких задач использовать ts/js очень странное решение. Обычно подобное пишут на Java, C#, Rust и т.д.
Потом напишите authjs или betterauth.
Зачем мне писать очередной JWT менеджер? Я вообще не особо люблю JWT.
> Такое чуство что вы кроме 5 страничных проектов ни чего более крупного не пытались делать....
Причём тут страницы проекта, если вы говорите вообще о бэкенд технологиях?
Я предлагаю использовать в фреймворках только то, что нужно, а не тянуть за собой кучу бесполезных библиотек по типу is-num, is-string и т.д. Уже молчу про то, что появились мета фреймворки, которые наваливают ещё больше анюзлес кода в проекты.
Касаемо ssr, то имхо, но как по мне it сфера потратила десяток лет, чтобы от этого уйти, но по итогу фронтендеры изобрели php5 с phpQuery из-за чего мы снова видим в коде например sql запросы в html тегах. Однако это отступление
Опять же у вас странная позиция. ssr это всё же больше про бэкенд решение, я же говорил про фронтенд фреймворки и что они сильно захламлены.
А я вас поддержу. Для 99% вещей Vanilla JS более чем достаточно. Просто фронтендеры сами себе создают сложность, словно дети, играющие во взрослую жизнь. У меня есть вполне интерактивный PWA с бекендом на Java, и фронтендом, написаным на JS в папке /public, состоящим из обычных JS файлов, подключающих нужные библиотеки через import *.js. Очень мало кода в итоге и легко поддерживать, а люди пользуются.
В то же время приходилось поддерживать проекты с React, webpack, npm и черт знает с чем еще, так вот, там все гораздо сложнее, тривиальные действия становятся целыми эпиками.
Это изначально скриптовый язык, зачем вообще начался весь этот бред с играми в компиляцию, в сборку, в шаблонизаторы шаблонизаторов, роутинг, совершенно непонятно, единственное логичное объяснение, что фронтендеры хотели выглядеть солидно, "по взрослому", и собезьянили понятия изначально относившиеся к бекенду, сделав нелепые имитации, от которых больше сложности, а польза весьма мнимая.
А я попытаюсь ответить за фронтенд (я фулстак техлид, 15+ лет опыта). Я писал и на пыхе, и на плюсах, и на jquery и на ваниле. Возможно, когда-то, мы действительно повернули не туда (меня бесит вкладка с пустым ангуляром, которая кушает 100 мб), но вы попробуйте запустить простой html с простым js - браузер будет кушать в инкогнито - 40+ мб.
Проблема не в фреймворках или библиотеках, проблема более прозаична - бабки. Я могу (и очень часто практикую) написать красивый сайт без использования библиотек и фреймворков, но это настолько долго выходит и настолько много ошибок может породить, что возникает вопрос - зачем?
Аналогия: я могу писать на чистом SQL, а могу взять орм.
И не фронтендеры создают сложность, а рынок и потребители создают потребность - фронтендеру насрать на валидацию инпутов и xss, да и на роутинг болт положить можно, но это не будет качественным продуктом, которым хочется пользоваться.
От фронтендера зависит выбор фреймворка. Там, где после месяцев мучений один фреймворк скушает гигабайт загружая страницу целую минуту, другой скушает 40 метров, загружаясь за 5 секунд, потребовав на разработку лишь пару дней (реальный кейс).
браузер будет кушать в инкогнито - 40+ мб.
И это тоже проблема, потому что многие браузеры так же по факту набор готовых библиотек, зачастую с кучей мусора и легаси внутри, прикрученных к форку хромиума.
> проблема более прозаична - бабки
Но лично я и не предлагаю писать прямо всё с нуля. Если вы писали на php наверное 100% сталкивались с symfony или laravel. Эти фреймворки, по факту собраны из десятка никак не связанных библиотек, каждую из которых я могу использовать отдельно в ванильном php и к каждой я могу в теории сделать fork чтобы, например убрать тот функционал, который не использую (но это уже оверхед). Почему нельзя делать так же для js?
> Аналогия: я могу писать на чистом SQL, а могу взять орм.
Кстати очень хороший пример, учитывая что ORM есть на любой вкус и цвет от минималистичных, до "приборных панелей космического корабля". И это хороший пример того, что когда я использую ORM (готовую, самописную не важно), то мне не нужно чаще всего для её использования ставить целый отдельный фреймворк. с папкой модулей на 500мб весом. Опять же аналогия из php. Я могу писать на ванильной php, но использовать только готовый router, минималистичную orm и этого уже будет достаточно. Я вот этого не понимаю, почему так же не принято делать в js? Если нужно написать большой проект, то окей проблем в фреймворках не вижу, но для большинства проектов они избыточны имхо. Точнее избыточно их содержимое.
По вашей же аналогии на PHP бекенд тоже легче писать, чем на Java: кинул файлы по FTP — и всё работает. А в Java выдумали какую-то компиляцию, JDK, Maven... :)
PHP это отличный выбор когда речь идёт о продуктивности разработки. В Meta до сих пор много пишут на Hack/HHVM - местном диалекте PHP. Фактически, React во многом слизан с Hack и XHP.
Вот я и говорю: кинул index.php на сервер — вот тебе и бекенд, а то вот эти мавены, градлы, спринги, джакарты, хибернейты, апачколлекшены, ломбоки, джуниты, сваггеры и чёрт знает что ещё :)
Компиляция Java выдает байт-код, который выполняется на порядки быстрее чем интерпретация JS. А что делает "компиляция" и "сборка" JS? Да ничего не делает, ни сборки ни компиляции как таковой, для браузера остается все тот же медленный JS.
А что делает "компиляция" и "сборка" JS?
Проверяет типы, объединяет файлы, делает преобразования кода, выбрасывает лишний код, минифицирует оставшийся.
интерпретация JS
он тоже JIT-компилируется виртуальной машиной
Проверяет типы, объединяет файлы, делает преобразования кода, выбрасывает лишний код, минифицирует оставшийся.
И что? Был JS на входе, остался JS на выходе. Все это буквально онанизм. Минификация никак не ускоряет работу самого приложения, а обфускация даже наоборот. Это еще один бессмысленный ритуал, придуманный чтобы было чем оправдать все эти пляски вокруг обычных скриптов в браузере
он тоже JIT-компилируется виртуальной машиной
Вот только JIT-компилируется любой JS из коробки, все что вы пафосно именуете "компиляцией" и "сборкой" на этот процесс никак не влияет. Тоже самое (только быстрее) будет происходить если просто воткнуть в обычный index.html обычный main.js на чистом JS без всяких "сборок".
Минификация никак не ускоряет работу самого приложения, а обфускация даже наоборот. Это еще один бессмысленный ритуал
Бандлеры ускоряют доставку кода в браузер. Разрабатывать удобнее с мелкими файлами, а вот погружать лучше более крупными кусками. Но если у вас реально небольшой проект и скорость загрузки страниц не принципиальна, то можете не связываться.
на входе
TS, JSX, (S)CSS
Минификация
ускоряет загрузку бандла за счёт уменьшения размера, можно даже в gz/brotli сразу экспортировать
обфускация даже наоборот
там уменьшение размера токенов, а не запутывание кода
все что вы пафосно именуете "компиляцией"
это вы именуете и с пафосом критикуете
на этот процесс никак не влияет
влияет: в исходном коде может быть более новый синтаксис, неподдерживаемый браузеров
обычный main.js на чистом JS
да, пока у вас всего сотня-другая строк
Спасибо. Я скорее про то, что фреймворки превратились в большие мусорки, куда навалено всё подряд и даже в крупных проектах зачастую не используется и половина от функционала ядра, который попадает зачастую полностью в конечный билд.
Касаемо солидности, то это в целом проблема IT. Я часто от заказчиков слышал, мол "мы не хотим чтобы вы использовали этот стек, потому что это не солидно". Это, к сожалению есть везде.
Бэкенд - отмазка для недоучек, не осиливших архитектуру и оптимизацию. Я за 25 лет таких насмотрелся, "я - сеньор дотнет бэкенд девелопер, мне эти ваши фронтовые свистоперделки не нужны", а потом"азязя, дайте мне сервер помощнее, а то мой Entity Framework почему то гарантии 600+ запросов в БД на один запрос в API, и 10 юзеров не могут нормально работать с сайтом."
Я вообще не понял к чему вы это. Каким боком orm и то что вы видели плохих бэкендеров, относится к перегруженности фронтенд фреймворков?
> я - сеньор дотнет бэкенд девелопер, мне эти ваши фронтовые свистоперделки не нужны
Тут вообще не понял к чему это и как в теории "фронтенд свистоперделки", относятся к плохому бэкенду? Открою секрет, на бэкенде и фронтенде оптимизация и архитектурные подходы разные, по очевидным причинам. Я не говорю, что фронтенд вообще не нужен, давай те всё на html писать. А писал, что многие фронтенд проекты на нём чаще всего "перегружены" из-за фреймвороков и это проблема не отдельных людей, а фронтенда в целом.
> Entity Framework почему то гарантии 600+ запросов в БД на один запрос в API, и 10 юзеров не могут нормально работать с сайтом
Просто в дополнении, я не знаю как можно даже в теории использовать ORM так чтобы 1 запрос к серверу генерил 600 запросов в бд, учитывая, что большинство из ORM чуть ли не автоматом применяет жадные загрузки, имеет встроенный функционал для батчинга и т.д.
Поизучайте на досуге сколько там мусора на несколько сотен мегабайт и всё это тянется в конечные билды.
Трафик и оперативка дешевые как грязь, зачем это крохоборство?
Я вот согласен, что часто можно и просто нативным Js/Html обойтись. Он ведь тоже не стоит на месте и уже пару лет как умеет в Web-компоненты (с "пропсами" через observed attributes), переиспользовать HTML-шаблоны (тег template) и CSS (через adoptedStylesheets), кастомными событиями (для общения компонентов). Но многие почему-то даже не в курсе таких технологий. Видимо потому что "зачем? я на реакт пишу"
В этих HTML-шаблонах из коробки нет инструментов для доступа к свойствам компонентов, а атрибуты принципиально только строковые. Так что совсем без сторонних инструментов всё ещё тяжело..
В браузерах JS и DOM это две отдельные подсистемы, для взаимодействия между которыми нужны тяжёлые операции синхронизации потоков и сериализации данных. Нативные Web-компоненты можно рассмотреть когда объёмы и частота изменения данных невелики. В остальном, лучше взять фреймворк с VDOM под капотом, который автоматически сводит такие взаимодействия к минимуму.
Да по-моему ото всего современного фронтэнда продолжает веять безумием, нет?
А вот эта вот иммутабельность данных, когда при каждом изменении несчастный массив/объект деструктурируют и собирают заново? Ну, чтобы сборщику мусора не было скучно.
Не, я понимаю, что для этой механики есть определённые причины. Но разве это не выглядит как огроменный костылище?
Но разве это не выглядит как огроменный костылище?
Вы описали весь современный фронтенд. Это костылище сдохнет когда допилят wasm и бекендеры наконец станут писать фронт сами на нормальных языках, Java, Rust и Go, etc.
А речь не про язык, а про подходы конкретной библиотеки. Лично я считаю JS вполне нормальным языком (хоть и не без проблем, конечно) и никакого Go не жду.
Там проблема не столько в WASM, сколько в удобной коммуникации между DOM/JS и "нормальным языком" во-первых, и во-вторых в том, что совершенно непонятно что делать с громадным количеством библиотек/компонент на JS, которые необходимы для формирования привычного UI - как правило попытка их использовать совместно с WASM приводит к конфликтам (оба пытаются контролировать одну и ту же часть DOM не зная друг о друге). Очевидное решение этого конфликта - переписать всё на "нормальном языке"… Но пока что-то никто не взялся столько всего переписать.
так то Вы давно можите писать фронт на java, используя gwt или j2cl. Но это так и не стало популярным. А ну и на Go впрочем тоже. На данный момент можно скомпилить java в wasm, но доступ к дом там очень так себе
Это костылище сдохнет когда допилят wasm и бекендеры наконец станут писать фронт сами на нормальных языках, Java, Rust и Go, etc.
Не уверен, попадает ли Dart под критерий "нормального языка", но как пример такого подхода есть Flutter Web. На выходе 2.5Mb WASM бандл, который рендерит всё в Canvas. По ощущениям ненамного лучше Flash или Silverlight. Банальные вещи типа прикрутить Google Analytics, сделать динамический title или favicon превращаются в увлекательное приключение.
А какая разница? Ну вот сейчас у вас есть
const buttonSend = document.getElementById('#buttonSend');
buttonSend?.addEventListener('click', () => {
sendData();
});А было бы
Element buttonSend = Document.getElementById("buttonSend");
if (buttonSend != null) {
buttonSend.addEventListener("click", new EventListener() {
@Override
public void handleEvent() {
sendData();
}
});
}А вот эта вот иммутабельность данных
Но разве это не выглядит как огроменный костылище?
Да, вы абсолютно правы. Поэтому все адекватные люди давно используют MobX в связке с реактом.
иммутабельность данных, когда при каждом изменении несчастный массив/объект деструктурируют и собирают заново
По смыслу, иммутабельность говорит о том, что с памятью делать особо ни чего не нужно. Поблема в том, что на уровне имеющегося синтаксиса это выглядят как нечто прямо противоположное.
По смыслу, иммутабельность говорит о том, что с памятью делать особо ни чего не нужно.
Эмм нет. С каких пор полное копирование участка памяти(объекта) с целью его изменения означает "с памятью делать особо ни чего не нужно"? Вы знаете как компьютер вообще работает?) Что есть память, у нее есть адреса, в эти адресы вы можете засовывать нолики и единички, есть стэк, есть куча(heap), стэк - быстрый, heap - медленный. Объекты в JS - heap.И всё это не бесплатно, за это мы платим процессорными тактами, пропускной способность шины RAM <==> CPU и т.д.. Шина данных в свою очередь это дорожки на плате, на которых в каждый момент времени либо есть напряжение, либо нет, чем больше этих дорожек, тем больше мы можем данных передать/прочитать за 1 рабочий такт. Но и тут не всё так просто, мы ограничены периферией процессора, у нее тоже не бесконечное кол-во ножек(на которые можно подавать 0...3.3в и которые могут читать 0 и 1, когда на ножку подали 0 или 3.3в), а так же возможностями мат. платы, плат RAM и т.п. На каждом пути нас встречают ограничения, как по частотам, так и по таймингам. А ещё нас встречают физические ограничения, скорость нарастания напряжения не бесконечная, много влияний паразитных ёмкостей и т.п.
Ах да, а ещё в JS есть garbage collecor, работа которого тоже не бесплатна. Поэтому когда речь про иммутабильность, то с памятью очень даже много всего нужно делать(и не только с памятью).
Чтобы ваше утверждение стало частично верным, нужны выключить garbage collector. Тогда да, та память которая уже была выделена по какой-то объект так и останется мусорной и с ней ничего уже делать никто не будет, просто каждый раз выделяете новую память, не очищая уже ранее выделенную и неактуальную. Но вот ведь не задача, у вас просто оперативка сразу закончится и всё, синий экран смерти.
Человек правильно сказал, вот его цитата:
иммутабельность данных, когда при каждом изменении несчастный массив/объект деструктурируют и собирают заново
С каких пор полное копирование участка памяти(объекта) с целью его изменения
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
У меня для вас плохие новости. Снимите розовые очки и попишите на C, реализуйте все эти подходы и вы поймете, что то, что вы думаете(просто где-то прочитав или услышал и приняв это за истину) это не имеет отношение к реальности. По копируйте структуры в цикле, проведите бенчмарки скорости и результат вас шокирует. Особенно ярко выражен он будет на голом железе, где исполнение программы и не делит ресурсы с тысячи других процессов. А измерять производительность там легко, подключили к ножке логический анализатор, подали/убрали напряжение с ножки, сделали работу(бенчмарк), подали/убрали напряжение с ножки и сравнили время между этими сигналами.
Купите себе микроконтроллер и попишите для него программки, там как раз голое железо, маленькие частоты десятки или сотни Mhz, это ничто по сравнению с гигагерцами и множеством ядер. Там вообще всё построено на мутабильности, а если вы там начнете заниматься иммутабильной дичью, то ваша программа будет:
a) Стоять на коленях из-за медленной работы на ровном месте
б) Может закончиться память (она там измеряется в килобайтах, а не в гигабайтах)
Знаете что такое "быстрые кучи/арены" на самом деле? Это тупо сразу же аллоцированный кусок в памяти, вне зависимости от того будут ли в него записаны какие-то данные полезные или нет, его просто у тебя сразу отнимают без вариантов. А вы знаете что работа с ним не бесплатна? У вас вокруг их работы построена целая обвязка, которая за всем этим следит, выравнивает память и т.д и т.п. всё это жрёт процессорное время, всё это жрёт память, всё это жрёт энергию.
В общем, поучите как всё это устроено на самом деле на уровне железа и ваш розовый с бесплатной иммутабильностью мир сразу разобьется о камни.
Вывод:
Каким был "правильным" или с какими бы "хаками" не был подход иммутабильный, он всегда будет проигрывать в производительности, в потреблении энергии и памяти. Это просто факт, с которым ничего не поделать, потому что так работает цифровая электроника. Каждая манипуляция стоит времени, места и энергии.
Каждая манипуляция стоит времени, места и энергии.
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Вообще-то я фронт-энд разработчик, а микроконтроллеры это хобби, как и программирование в целом и изучение работы процессоров и периферии на низком уровне. Последние 9 лет использую MobX (мутабильность!) в связке с реактом.
А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
const oldValue = { count: 1 };
// Упс, ссылка изменилась, а данные нет. Все гарантии в унитаз.
// Лишний рендер здраствуй. Лишняя память привет.
const newValue = { count: 1 };Как бы)
Вы с другой колокольни смотрите.
Когда кто-то говорит про оптимизации или производительность или о том, что какие-то манипуляции ничего не стоят, я как раз смотрю с правильной колокольни. С колокольни процессорных тактов, с колокольни аллокаций/реаллокаций памяти и т.п.
Так вот, ладно если бы платой за иммутабильность была только потеря производительности и памяти, так к этом прибавляется плата говонокода.
Вместо state.count++ приходится код в говно превращать.
Не нужна. Нужно распространение флага dirty. Реализовывать это распространение через пересоздание цепочки объектов - это очень медленно.
Иммутабельность не обязательна для Реакта. Это лишь один из способов оптимизации.
Иммутабельность не обязательна для Реакта. Это лишь один из способов оптимизации
Иммутабильность - оптимизация?) Интересненько) С каких это пор постоянное копирование объектов в памяти на каждый чих это оптимизация?
Это расходование процессорных тактов в холостую, а значит это замедление работы. А если это происходит на мобильном устройстве, то и увеличенное потребление энергии в холостую.
А главное иммутабильность даёт ноль профита.
Я понимаю когда мы жертвуем производительностью, расходом памяти и энергии когда пишем на JS вместо Assembler'a, потому что это даёт вполне себе огромный буст в скорости и простоте разработки.
Но если для вас падение производительности, увеличенных расхода памяти и энергии, не оправданное ничем это оптимизация, то мне очень жаль.
Я не утверждал, что иммутабельность сделает UI таким же оптимизированным как точечные вызовы DOM API.
Иммутабельность используется вкупе с memo, чтобы пропускать рендер компонентов, когда данные не меняются. Оптимизация заключается в избавлении от ненужных рендеров. Подробнее можете почитать тут: https://react.dev/reference/react/memo#skipping-re-rendering-when-props-are-unchanged
А главное иммутабильность даёт ноль профита.
Иммутабельность даёт гарантии, что объект, который ты получил, не
взорвётся у тебя в рукахостанется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флаговisModified, или перерисовывать весь UI на каждый чих.Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
Иммутабельность даёт гарантии, что объект, который ты получил, не
взорвётся у тебя в рукахостанется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флаговisModified, или перерисовывать весь UI на каждый чих.
А вы как, на шару разрабатываете? Или модифицируете объекты осознанно, а не просто чтобы символом побольше напечатать?
С таким же успехом можно сказать, что нужно всего быть в каске и спать в ней, потому что в любой момент может в окно залететь камень прямо в голову или кусок стены отвалится и упадёт прямо на голову.
Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Да, максимально тупой и топорный, согласен. Но и не без приколов:
const oldValue = { count: 1 };
// Упс, ссылка изменилась, а данные нет. Все гарантии в унитаз.
// Лишний рендер здраствуй. Лишняя память привет.
const newValue = { count: 1 };Открою великую тайму, с 2010 года есть такие штуки getters/setters, вот с этих помощью прекрасно детектируются все изменения в объекте.
state.count = 0;
// Было изменение, вызывает реакции
state.count = 1;
// НЕ было изменений, НЕ вызывает реакций
state.count = 1;Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Да вы что, прям яваскрипт знает какая часть неизменной будет, а какая нет?))) А может ещё это бесплатно и память не кушает?))) Опять розовые очки. Вернемся в реальность, либо полное копирование, либо нарушаете принцип иммутабильности.
Упс, ссылка изменилась, а данные нет.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
есть такие штуки getters/setters ...
Было изменение, вызывает реакции
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Да вы что, прям яваскрипт знает какая часть неизменной будет, а какая нет?)))
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Это ответственность того, кто меняет данные
Гениально. Т.е. все ваши мнимые "гарантии" мгновенно испарились.
Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
Класс, рекурсивный обход 2х объектов и сравнение полей)
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Элементарно.
Вот: https://stackblitz.com/edit/stackblitz-starters-c87ad3cy?file=src%2Findex.tsx
У MobX есть такая штука, конфиг называется, там можно отключить синхронный вызов реакций за пределами action. Либо если не хочется, то делая пачку изменений можно все завернуть в action или runInAction, но я против этого, потому что так код грязнее. Поэтому конфиг - лучший вариант.
Класс, рекурсивный обход 2х объектов и сравнение полей)
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
У MobX есть такая штука
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
вы путаетесь в показаниях и включаете заднюю
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Или Immer, например.
Proxy getters/setters поверх иммутабильности, опять "гениально") Зачем лишняя прослойка(иммутабильность)?
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
Ппц, на полном серьезе такую брехню нести, да ещё с таким видом, как будто писать придерживаясь таких принципов код это нормально, это конечно что-то с чем-то.
А потом удивляемся почему нас такой убогий софт окружает, который выжирает всю оперативку, лагает на мощном желе и т.п. Ну а как иначе, когда такой подход к разработке и такое "понимание" как всё устроено на самом деле.
Конкретных разоблачений "брехни", конечно же, не дождёмся.
Конкретных разоблачений "брехни", конечно же, не дождёмся.
С чего вдруг? Я уже всё разоблачил, вот же они:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28580098
И вот:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28584342
И вот:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28585100
И вот:
https://stackblitz.com/edit/vitejs-vite-dspjoj?file=src%2FApp.tsx&terminal=dev
Давайте только быть честными самими с собой, лучше такого кода (нативного, максимально понятного и очевидного) просто быть не может. Это очередной раз разбивает все ваши розовые фантазии о том, какая иммутабльность хорошая о медный таз.
Давайте только быть честными самими с собой, лучше такого кода (нативного, максимально понятного и очевидного) просто быть не может.
Давайте, может:
@mem data( fresh?: null ) {
sleep( 2000 )
return 'Data from server'
}Что именно вы разоблачили? На ваши комменты c разоблачениями были ответы, простое повторение тех же комментов не является разоблачением, заявы "Ппц, на полном серьезе такую брехню нести" ими тоже не являются -- я тоже умею такие заявы кидать.
Я вижу вы ярый апологет MobX. Я ничего против MobX не имею, я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука, которая якобы приводит к ПОЛНОМУ копированию всего состояния на каждый чих. Это просто чушь, выкурите structural sharing уже.
Ну и, к слову о розовых очках и реальности: тот же MobX под капотом приводит к аллокациям и диффам на каждый пересчёт каждого derivation, с целью отслеживания [новых] зависимостей, с дедупликацией оных. "С каких это пор постоянный копирование объектов трекинг зависимостей на каждый чих это оптимизация?" (с) алаверды
Т.е. проблема аллокаций просто перемещается на другой уровень. То, что в вашем коде их нет, не значит, что их нет вообще. "А может ещё это бесплатно и память не кушает?)))" (с) алаверды-2
Опять розовые очки. Вернемся в реальность
Возвращайтесь, я не против.
тот же MobX под капотом приводит к аллокациям и диффам на каждый пересчёт каждого derivation, с целью отслеживания [новых] зависимостей, с дедупликацией оных.
Это хороший аргумент. В kr-observable, например, для этих целей используется один раз аллоцированный Map, который очищается перед выполнением эффекта, а во время выполнения в него кладутся ссылки на прочитанные объекты. К новым аллокациям это не приводит. Если в mobx также, то это дешевле чем structural sharing.
МобХ постоянно аллоцирует память, что связано с его не самым высоким перфомансом.
Очистка Мапы не факт, что не освобождает память, иначе это была бы утечка. Вы проверяли это?
В $lmol_wire я отдельно заморачивался, чтобы переиспользовать уже аллоцированную память и не трогать gc вообще.
Вы проверяли это?
Да, проверял.
Не знаю, что я из этого должен понять.
<!doctype HTML>
<html lang="en">
<head>
<script type="module">
class MyCoolMap extends Map {}
const a = new MyCoolMap;
const b = new MyCoolMap;
const fill = document.getElementById('fill')
fill.addEventListener('click', () => {
for (let i = 0; i < 100; i++) {
a.set(Math.random(), Math.random());
b.set(Math.random(), Math.random());
}
})
const clear = document.getElementById('clear')
clear.addEventListener('click', () => {
a.clear()
})
</script>
</head>
<body>
<button id="fill">fill</button>
<button id="clear">clear</button>
</body>
</html>
MyCoolMap использовал чтобы удобнее было фильтровать по классу.
Что именно мы пытаемся проверить?
я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука
Как бы да, это дорогая штука, как по CPU, так и по RAM. Учите матчасть. Вот тут простыми словами всё изложено https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28580098
которая якобы приводит к ПОЛНОМУ копированию всего состояния на каждый чих.
Как бы да, копирование ПОЛНОЕ) Иначе вы иммутабильность путаете с мутабильностью. Если копирование не полное, то вы НАРУШАЕТЕ иммутабильность, они больше иммутабильностью не является.
Это просто чушь, выкурите structural sharing уже.
Чушь несете вы, не понимая принципов работы процессора, материнской платы и оперативной памяти. И уж тем более не понимаете принципе иммутабильнсти.
Я просто в шоке от того, что вы не понимаете разницу между этим(Выше на скрине) и вот этим
this.count++;У вас знания и понимание реально нулевые.
Вот вам, бенчмарк, в выгодных условиях для вашей фейковой полу иммутабильности со Structural Sharing
https://stackblitz.com/edit/stackblitz-starters-1f9errps?file=src%2Findex.tsx
Разница в 100 раз карл!
Вместо тысячи слов.
А вот с настоящей, используя так же ваш кривой Structural Sharing
https://stackblitz.com/edit/stackblitz-starters-kutw927n?file=src%2Findex.tsx
Тут уже в 500 раз проигрыш
А вот с настоящей иммутабильностью, но без лишней кривой прослойки в виде Structural Sharing
https://stackblitz.com/edit/stackblitz-starters-hkgeey7x?file=src%2Findex.tsx
Тоже проигрыш в 100 раз, но тут хотя бы настоящая иммутабильность.
Зачем же вы с убогими-то сравниваете? Берите тогда уж самый шустрый реконцилятор: https://www.npmjs.com/package/mol_conform
А ещё лучше самый шустрый иммутабилизатор: https://www.npmjs.com/package/mol_mutable
Зачем же вы с убогими-то сравниваете?
Да, реализация реактивности с помощью getters/setters у MobX не самая быстрая, но даже ее в принципе за глаза хватает в real world приложениях. Моя реализация реактивности с помощью getters/setters, которую я использую на своих проектах в этом тесте в 20 раз быстрее MobX.
Чёт вы рано начали оправдываться. Разумеется даже самая быстрая реализация иммутабельности для объекта с 1к полями будет медленнее прокси.
Чёт вы рано начали оправдываться
Да нет) Я констатирую факты) В абсолютных значениях MobX не самый быстрый, но по сравнению с иммутабильностью он чудовищно быстрый) А у нас как раз разговор иммутабильность vs мутабильная реактивность)
Разумеется даже самая быстрая реализация иммутабельности для объекта с 1к полями будет медленнее прокси.
А это усреднённое значение, с упором на реальную жизнь, часто в реальной жизни мы имеем дело с массивами объектов, допустим 100 элементов и каждый это объект с 15 полями, а в некоторых полях могут быть ещё вложенные объекты и итого это условно равносильно, объекту с 1.5к-2к полями и больше. Но и то, это со звездочкой, один плоский объект с 2к полями будет быстрее в иммутабильности чем массив более мелких объектов, тем более с вложенными объектами где совокупное кол-во полей также 2к.
Если мы оперируем объектами в которых суммарно 5-10 полей, то с точки зрения производительности тут вообще можно этим пренебречь, можно считать что они будут условно равнозначны. Но это уже условия в вакууме и за пределами реального мира.
Как бы да, копирование ПОЛНОЕ) Иначе вы иммутабильность путаете с мутабильностью. Если копирование не полное, то вы НАРУШАЕТЕ иммутабильность, они больше иммутабильностью не является.
Похоже, у вас понятие "полное" какое-то совершенно отличное от моего. Для меня полное копирование -- это глубокое клонирование, т.е. создание полного клона объекта, с клонированием всех полей, включая детей, и внуков, правнуков и т.д.
Structural sharing не клонирует всех детей до последнего колена -- те объекты, что не поменялись, остаются на месте, их никто не удаляет, они шарятся между обоими копиями стейта (и при хорошем дизайне это бОльшая часть стейта). Никакого нарушения иммутабельности при этом нет, хотя клонирование тут частичное (в том смысле, что не для всех данных производятся дубликаты).
Чушь несете вы, не понимая принципов работы процессора, материнской платы и оперативной памяти.
Умерьте пыл, телепат вы наш, есть немалый шанс, что принципы процессора и проч я изучил, когда вы ещё под стол пешком ходили.
И уж тем более не понимаете принципе иммутабильнсти.
Судя по тому, что вы называете structuredClone "настоящей иммутабельностью", принципов не понимаете вы. Я даже не знаю откуда вы эту чушь берёте, клонирование и иммутабельность -- это концептуально разные вещи, хоть и идут рука об руку рядом. Может быть клонирование без иммутабельности, может быть иммутабельность без клонирования (любая константа вам скажет)
Вот вам, бенчмарк
Если у вас весь стейт -- это один огромный плоский массив/мапа на тысячи элементов, то да, будут проблемы с производительностью, потому что основными затратами будет перекладывание одних и тех же ссылок. Да, такие структуры плохо подходят для immutability, если стейт надо часто менять, кто бы спорил. И никто не спорит, что лазить в структуры напрямую и "пачкать" данные "по-живому" эффективнее с т.з. скорости. Ну так горе-админы тоже считают, что лазить на прод и что-то там менять напрямую -- это быстрее и эффективнее. До первого падения прода и люлей.
Иммутабельность имеет свою цену -- я это могу вам повторить ещё раз, если первые два раза не поняли. Точно так же, как запрет лазить на прод руками имеет свою цену. Вопрос в том, готовы ли вы платить эту цену за отсутствие головняка с гонками данных, неконсистентностью, откатами и прочими ништяками.
Если у вас стейт -- не огромный плоский массив, а более-менее глубокое дерево, то выигрыш прямый изменений уже становится не такой уж значительный:
https://stackblitz.com/edit/stackblitz-starters-c2hsjkty?file=src%2Findex.tsx
Особенно если программист не идиот и не складывает быстро-меняющиеся данные в общий стейт.
https://stackblitz.com/edit/stackblitz-starters-nmrgfkqg?file=src%2Findex.tsx
Это у вас спец олимпиада, вы в свои бенчмарки не включаете реальный рендер.
О которых моих бенчмарках идёт речь?
Для меня полное копирование -- это глубокое клонирование, т.е. создание полного клона объекта, с клонированием всех полей, включая детей, и внуков, правнуков и т.д.
Да, и для меня тоже. Это обязательное условие для выполнения иммутабильности. В противном случаеoldState.title = 123;
И ваш актуальный "иммутабильный" объект, изменился, а вы не в курсе и react не в курсе, да и вообще никто не в курсе.
Умерьте пыл, телепат вы наш, есть немалый шанс, что принципы процессора и проч я изучил, когда вы ещё под стол пешком ходили.
Может быть, но по состоянию на сегодняшний день, знания замылились и их можно обновить)
Ваш бенчмарк показывает:
1) Используя immer или Structural sharing вы НЕ используете иммутабильность. А используете костыль, и завуалировано используете мутабильность и proxy getters/setters.
2) Ваш костыль всё равно в разы медленнее работает. А учитывая то, что код при этом гораздо хуже и грязнее, то этому нельзя простить падение производительности в разы.
А ещё у MobX скорость стабильная, а у костыля immer она плавает и чем идеальнее для него условия(меньше отношения к реальному миру).
И как вишенка на торте, MobX в качестве реализации реактивности с использованием getters/setters не самое быстрое решение, мой аналог MobX'a работает в среднем в 20 раз быстрее, а в определенных сценариях в 1000 раз быстрее. Т.е. если сравнить фейковую иммутабильность immera и удачную реализацию мутабильной реактивности, то проигрыш MobX'у умножьте ещё в 20 раз)
Как вы там говорите?)
в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
Дешевле? Пока этому ровно 0 подтверждений. Это и не удивительно, если понимать как работает CPU, RAM и т.п.
я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука
Да, она дорогая) Опять же это очевидно любому кто понимает как работает CPU, RAM и т.п. А ещё это подтверждается бенчмарками.
Вырисовалась совершенно отчетливая закономерность, вы всегда не правы. Каждое ваше утверждение разбивается о скалу экспериментально подтвержденных фактов.
А нужно то всего на всего понимать как работает железо, хотя бы в самых общих чертах, у вас бы даже мыслей не было что каким-то чудесным образом тысячи процессорных тактов могут быть не медленнее, или не принципиально медленнее, чем несколько процессорных такстов)
А чего это вы стесняетесь использовать в бенчмарках свой волшебный в 1000 раз более быстрый аналог мобикса?
Это обязательное условие для выполнения иммутабильности.
Нет, не обязательное. Просто, читая "Объект не может быть изменён. Если нужно новое состояние, создаётся новый объект, исходный остаётся неизменным", вы упёрлись в единственную трактовку, что "не может" означает якобы техническую невозможность ("должно быть невозможно поменять"), и не допускаете, что это может быть нормативным требованием "не надо менять".
Structural sharing не меняет старый объект, и он создаёт новый объект на основе старого. Если вы сами злонамеренно не меняете старый объект, то все условия иммутабельности выполнены.
Глубокое клонирование точно так же никак не защищает старый объект от злонамеренного изменения, какой-нибудь уникум всегда может написать:
const newState = structuralClone(oldState);
oldState.id = 123;-- и всё, приехали. Тогда каким образом structuralClone является "настоящей иммутабельностью", по-вашему?
Иммутабельность -- это в первую очередь дисциплина, принцип, паттерн. Если есть дополнительные safeguards через средства языка (вроде Object.freeze или opt-in mutability как в Расте) или через библиотеки типа ImmutableJS -- отлично, но если нет, то вы всё равно можете использовать её, просто избегая прямых мутаций состояния.
Про tradeoff "производительность vs фишки"я в четвёртый раз одно и то же писать не буду, если с трёх раз не дошло, то я пас.
Про tradeoff "производительность vs фишки"
Вы опять несете чушь, вот смотрите:
1) Assembler(быстро) vs Javascript(медленно) - да, куча реальных удобных фишек за которые можно заплатить.
2) Реактивная мутабильность(быстро) vs Иммутабильность(медленно) - используя иммутабильность мы получаем более грязный, более раздутый, с большим кол-вом бойлерплейта код, который даёт ровно ноль реальных преимуществ, но при этом мы за это ещё и должны заплатить потерей производительность, в в идеальных условиях(и то, для фейковой иммутабильности) в 5 и более раз, а так легко и в 10 и в 100 раз. Выбирать то, что по всем фронтам хуже, а ещё и медленнее в разы и десятки раз - звучит как полный бред. И называть это tradeoff'ом смешно, это чистой воды безальтернативный downshifting и downgrade, идя на которые ты только теряешь.
вы всё равно можете использовать её, просто избегая прямых мутаций состояния.
Зачем? Если я знаю что я делаю и для чего я это делаю. И на шару не пишу this.count++. Зачем мне срать самом себе в удобстве, в красоте коде, в чистоте кода и в производительности.
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок.
Пожалуйста
import { makeObservable, autorun } from "https://esm.sh/kr-observable";
const { data } = makeObservable({ data: [] });
for (let i = 0; i < 100; i++) {
data.push({ active: false, id: i });
}
autorun(() => {
console.log('effect', data.every(el => el.active === true))
})
data.forEach(el => el.active = true);Лог:
effect false
effect trueСкопируйте, и вставьте на codepen.io (не могу дать ссылку, потому что из рабочей сети он заблокирован).
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Вы путаетесь в показаниях и включаете заднюю, вы не понимаете как работает иммутабильность, как она соблюдается и что для этого нужно делать) Зато льёте сказки про
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Не надо от балды. Давайте говорить на языке фактов и того, как на самом деле работают те или иные вещи, а не на языке розовых пони в мире розовых облаков.
Больше всего в
useEffectменя раздражает то, что этот хук используется для задачи «выполнить что-то после монтирования компонента».
Больше всего в молотке меня раздражает то, что он используется для задачи «ударить по гвоздю».
и под этим 100500 комментов с чудо-доводами типа "это говно" просто потому что мне не нравиться...
торт! торт!
От себя добавлю, у меня более 18 лет опыта, как говорят я знал jQuery еще до того как выучил JS. Читаю ваши комментарии про проблемы Реакта и понимаю что то что вы учатники описываете и то что автор (оригинальный до перевода) пытается показать проблемой, для разработчиков на Реакт давно не проблемы. Конечно можно найти в любом коде купленном за миллионы сомнительный код (как буд-то в ангуларе за те же деньги, не найдешь факапов). Но правда в том что опытные разработчики знают как обойти все эти проблемы. Но об этом действительно мало где можно почитать и увидеть реальные кейсы. Может надо самому начинать писать такие примеры.
Отдельно хочу сказать про добавлении 3й кнопки - умение сказать НЕТ очень важно.
У автора претензия как раз в том, что в сообществе принято вместо "у нас есть такие проблемы, с ними мы боремся таким образом" вопить что-то вроде "у нас нет проблем, надо просто правильно использовать инструмент и накатить тысячу библиотек". Не баг, а фича в форме какой-то оголтелой религии, короче.
Не знаю о таком сообществе, которое вообще не признает проблем. Хотя бы наличие большого количества стейт-менеджеров и возведение определенных в "стандарт" - явное признание useState и Context несостоятельными в этом плане. И это понимание есть даже у новичков, что сам по себе Реакт крайне несовершенен, и нужно использовать эти "тысячу библиотек", чтобы исправить ситуацию.
На собеседованиях часто слышал "расскажите о недостатках фреймворка/библиотеки/подхода", и если ничего не говорить - то значит опыта было мало и проекты были слишком простые, чтобы на что-то наткнуться. В большинстве случаев этим вопросом можно явно определить джун-миддл. Так с любой технологией, в том числе с Реактом - чем больше его используешь, тем больше видишь недостатков, и тем больше копится база собственных решений, как их обходить.
Мой любимый прием)
Я всегда видя в резюме список технологий, прошу рассказать о недостатках пары представленных. Работает безотказно! Например, самый частый случай — module federation, только попросишь рассказать, так сразу — нууу, настраивал не я, там целая команда, бла, бла, бла…
То самое сообщество, которое в ответ на критику апеллирует к "развитой экосистеме" и наличию способов обхода тех или иных проблем. Взять те же ререндеры на каждый чих. Укажешь на них - сообщество ответит, мол, а ты просто не умеешь готовить реакт, тебе надо использовать мемоизацию. Руками. Каждый раз. В каждом компоненте. Проблема ведь перестаёт быть проблемой, если у нас появляется способ её обойти, правда?
Я, пожалуй, не буду приводить иные примеры аргументации, так как я хотел только продемонстрировать принцип споров фанатов с критиками. Хотите больше примеров - можете здесь же в комментах поискать, к слову. Почему в техническом сообществе, которое должно быть всё-таки чуть более объективным, чем в среднем по больнице, имеется столько фанатов - это для меня загадка, конечно.
Взять те же ререндеры на каждый чих. Укажешь на них - сообщество ответит, мол, а ты просто не умеешь готовить реакт, тебе надо использовать мемоизацию. Руками. Каждый раз. В каждом компоненте.
Не правда, ничего руками делать не нужно, MobX всё сделает сам, автоматически. Никаких лишних рендеров не будет. Особенно если сконфигурировать mobx на автобатчинг. Это объективно. Так же объективно, как я сам использую не MobX последние 2 года, а его самописный аналог, просто потому что могу) А с 2016 по 2023 использовал с react'ом исключительно mobx, потому что все альтернативы хуже.
Почему в техническом сообществе, которое должно быть всё-таки чуть более объективным, чем в среднем по больнице, имеется столько фанатов - это для меня загадка, конечно.
Согласен
все альтернативы хуже.
Это по какому это параметру $mol_wire хуже?
Я писал о проблеме реакта: постоянные ререндеры и необходимость ручной мемоизации. И писал о проблеме сообщества: оно не считает проблемы реакта проблемами, если есть костыль для их обхода.
И мне тут же приводят в качестве контраргумента существование сторонней библиотеки, которая позволяет обойти проблему реакта.
Ну сказка просто. Лучше и придумать нельзя.
React вроде сознательно пытается сделать так, чтобы вы могли писать компоненты декларативно, а не императивно. Поэтому не нужно там искать направления потока выполнения и удивляться почему один хук выполняется после другого. В идеале каждый хук - отдельная сущность, писать её нужно без оглядки на другие.
"добавление трёх кнопок вместо двух повышает количество багов на 5% и на 30% усложняет последующее проектирование и реализацию работы страницы" уверен, ссылки на какое то исследование или статистику не будет.
Автор и сам признаёт - сложность React вытекает из сложности задач, которые он решает. У React очень крутая кривая обучения/внедрения в начале. Но, когда у вас будет граммотно настроенный проект как раз таки добавление пары кнопок не должно вызвать каких то затруднений.
Мне кажется, что все дебаты по поводу плох React или нет, просто тратят наши нервные клетки. Убежать от этого Франкенштейна просто невозможно, т.к. это продукт Фейсбука и они активно его продвигают. Хотя спасибо разрабам Vue, они пошатнули хорошо их позиции.
Надеемся, что мыв ближайшем будущем сможем увидеть норм библиотеку, которая сможет заменить и react и react native
Краткий пересказ статьи:
"... React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…"
"... с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта для каких-то конкретных предложений."
Дальше можно расходиться. У автора просто недостаточно опыта в Redux, а приведенный пример кода, тоже не смогли осилить в Redux.
У меня вообще не было проблем с React — всё сразу укладывалось в голове без конфликтов. Возможно, это из-за дислексии: мне проще оперировать абстрактными сущностями. Для меня разница между фреймворками — исключительно в синтаксисе. Но так уж совпало, что синтаксис — это ахиллесова пята дислексии: нейросетка во время подсказывает, я пишу половину букв правильно — и всё фиксится в один клик.
Ещё добавлю: недавно понадобилось сделать несколько сервер-сайд компонентов в Next.js, и оказалось, что там нельзя использовать useState. Признаюсь, я на какое-то время завис — думал, что в React всё делается через useState. Чтобы вы поняли, насколько я застрял в клиент-сайд React’е… Каково же было моё удивление, когда через полчаса я понял, что можно просто использовать обычные переменные. Как говорится, не забывай свои корни.
Почему-то увидев заголовок статьи, я подумал что тут будет про ReactOS... И смелым безумцам будет тут петься песня...
О боги, верните десктопные приложения и RAD типа Delphi, в которой каждый школьник за наносекунду мог одной мышкой нарисовать работающий пользовательский интерфейс! Перекомпиляция за секунду, отладка моментальная, интерактивность полная. Работа на 0.333 ГГц CPU возможна, навигация через Tab летает.
Вот скажите, можно ли сейчас на React мышкой набросать пару десятков компонентов на пяток формочек и получить готовый макет UI приложения за час? Чтобы кнопки нажимались и окошки открывались?
Возможно стоит обратиться внимание на GUI приложений. Тут конечно и про них немало "добрых" слов уже сказали. Однако создается впечатление, что все WebUI фрейморки, по своей сути ближе к этапу написания GUI на чистом WinAPI, чем к сколь-нибудь развитым GUI фреймворкам.
А можно больше конкретики, чтобы можно было хотя бы предметно разговаривать? Если будет пример кода, демонстрирующий реактивность — ещё лучше.
Вот про это и речь. Почему сразу реактивность? Свет клином сошелся? Десктоп испокон живет без нее, а интерфейсы многих программ, намного более функциональны. Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений. При этом я не отрицаю полезности реактивности в отдельных местах.
Когда поглядываю на веб-фреймворки, вижу в них скорее не UI фреймворки, а брокера связности, на котором можно писать UI. Не настолько квалифицирован в данной области, чтобы продвигать настолько глобальные архитектурные концепции, однако хотелось бы видеть более глубокое разделение на собственно UI фреймворк и брокера. Первый позволяет писать UI и только за него отвечает. Причем UI виджеты должны быть более отдалены от их реализации, которую поймет браузер и более отражать сущность виджета. Второй отвечает за объект данных. А разработчик может выбрать, использовать классическую модель событий onCreate / onShow / onChange реализуя требуемое императивно или подключить данный виджет к отслеживаемой переменной декларативно. И даже сделать гибрид — пользовательские действия в виджете обрабатывать императивно, а изменения в данных отображать на виджет декларативно.
Без реактивности получается много кода и багов в нём, на избавление от которых приходится тратить много ресурсов.
Десктоп испокон живет без нее
На самом деле мне неизвестно, есть ли в интерфейсе сложных программ какая-либо реализация реактивности.
Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений.
Изначально там не было реактивности, но и приложения были довольно простыми. Потом же в Android стали использовать RxJava, а потом ушли к реактивности на Compose с корутинами и MVVM. В iOS тоже сначала появился ReactiveCocoa, затем RxSwift, а теперь официально рекомендуется реактивность на SwiftUI + Combine.
В браузерах работа с UI осложнена тяжеловесностью DOM API, в котором нужно делать точечные манипуляции над элементами для нормальной производительности. Напрямую манипулировать элементами никто не мешает, но это очень неудобно. Поэтому, например, в React придумали делать Virtual DOM, который сам вычисляет и применяет изменения элементов, а разработчику нужно только построить этот VDOM с опциональной мемоизацией поддеревьев. Конечно, это очень неэффективно. В SolidJS решили по-другому: обернуть каждый DOM-элемент реактивной обёрткой, так что система реактивности сама должна наиболее эффективно вычислить минимально необходимые изменения в DOM.
На более высоком уровне реактивность как будто бы так сильно и не нужна, но если она есть — жить с ней намного легче, чем манипулировать данными императивно.
Мои тезисы ничуть не противоречат вашим. Я не говорю что реактивность плоха, лишь что она — полезный инструмент, а не основополагающая базовая концепция, вокруг которой вертится всё-всё-всё. Должна быть сверху, предоставлять выбор использовать только там где нужна, а не снизу, вынуждая подстраиваться под себя везде.
В принципе, никто не мешает реализовать часть самостоятельно. Но есть нюанс, нет ни одного императивного WebUI фреймворка. а самостоятельная реализация уходит в излишне низкоуровневый слой. А вот если бы был, возможно архитектура и взяла бы лучшее из обоих миров.
Должна быть сверху... а не снизу
Так я же и говорю, что она не от хорошей жизни потребовалась.
нет ни одного императивного WebUI фреймворка
Нужен именно по типу дельфовского VCL или дотнетного WinForms, потому что простые формочки из 3 полей удобно было мышкой программировать?
Мышкой, кодом или декларативно аля QML, но да, что-то похожее.
Причем нужна не столько для формочки из 3 полей, сколько для возможности увидеть и сравнить две парадигмы. Фронтендеры не готовы выйти из зоны комфорта и не видят жизни за пределами реактивной "клетки". А точно ли ее там нет? Почему за столько лет десктопа, не появилось ни одного новомодного, самого лучшего, изначально и до самого конца реактивного фреймворка? Уж точно дело не в простоте отображения изменения состояния окна, в противовес сложности модификации DOM. Реактивность вообще лежит вне этой аргументации. Это просто двунаправленная связь данных и контрола отображения.
Странный аргумент. Зачем же отказываться от реактивности, если с ней намного удобнее? Это показывает и пример десктопов (тот же WPF), и мобил (Jetpack Compose и SwiftUI), и самого веба. Но приходит человек, который говорит: «Я когда-то что-то делал на Делфи, поэтому считаю, что вы тут все неправы, выходите из зоны комфорта». Кажется, это выглядит довольно абсурдно.
Хороший аргумент. :) Но разве к WPF реактивность прибита гвоздями? В свойство Text обычного TextBox можно записать одно и двунаправленные биндинги, а можно собственно текст. И это правильно. Где удобнее реактивность, используем реактивность. Где не удобнее, используем свойства и события UI контрола. Думаю на мобилах разработчик тоже не прибит гвоздями к парадигме.
Тут правда рядом на биндинги жаловались, но я наоборот, считаю это контролируемой сложностью.
Ну то есть вы предлагаете фронтендерам вернуться куда-то во времена jQuery и Backbone, и тогда-то всё станет хорошо.
Как из моих слов вы сделали такой вывод? Хочу видеть UI контрол (скорее, хорошо проработанную библиотеку контролов), где вся сложность инкапсулирована и нужна, только если хочется чего-то эдакого, то есть в обычных условиях почти никогда. Он управляется собственными свойствами и событиями, в том числе с одно и двунаправленной привязкой к данным. Где ключевое "в том числе", а не исключительно.
Backbone, насколько про него когда-то читал, мог бы служить далеким предком такого подхода. А вот с jQuery даже рядом не лежало.
Так ведь даже jQuery позволял инкапсулировать любые контролы и затем работать с ними в ООП-стиле. Сколько тех же Select на нём было.
По нынешним временам слишком низкоуровнево. Как говорил выше, почти WinAPI. И даже если можно инкапсулировать, это надо делать самому. Поэтому не надо передергивать.
Возможно вы и правы. Но скорее потому, что мы говорим о разных интерфейсах. Для информационных страниц, просто добавь интерактивность, возможно существующие фреймворки годны. С другой стороны расположены полноценные десктопные приложения, в виде html-страницы (без рисования на canvas). Сплошь состоящие из контролов, контролов и еще раз контролов.
И даже если можно инкапсулировать, это надо делать самому.
Нет, инкапсуляцию контрола делал сам разработчик контрола. Например, dropdown или datepicker: наружу выставлялись методы для настройки, установки значения и подписки на результат. То же самое, что и в десктопных фреймворках.
полноценные десктопные приложения, в виде html-страницы
Десктопные приложения, которые выглядят как html-страницы или html-страницы, которые выглядят как десктопные приложения? У вас мысль нечётко сформулирована.
Кстати я наверное понимаю, почему вы пропагандируете именно классическую модель работы с компонентами: в простых приложениях кажется, что она проще и понятнее, но это вызывает сильную связность компонентов, которые начинают зависеть не от данных, а от других компонентов.
Вот предположим: есть простая форма с вводом суммы и двух выпадаек: исходная валюта и конечная валюта. Приложение должно делать конвертацию в реальном времени: периодически загружаются новые биржевые курсы валют, введённая сумма также пересчитывается. В классическом подходе получится, что будут нужны метод расчёта и метод вывода конечной суммы. При этом метод вывода будет вызываться из четырёх мест: при изменении начальной суммы, при выборе валют и при обновлении курсов, и будет вызывать метод расчёта суммы, который будет собирать данные из всех контролов. В итоге, даже для такого простого случая вам понадобится явно подписаться на все источники событий, а также на все данные, которые они порождают. В реактивном же подходе вы просто создадите функцию расчёта значения, а всё остальное сделает система реактивности.
Зачем-то опять выставляете так, будто я отрицаю полезность реактивности. Повторю, она полезна. Но как опциональный инструмент, а не фундаментальная концепция — ни шагу в сторону. Модель контролов, должна в равной удобной мере позволять использовать для них как реактивность, так и реализовать связи вручную через свойства/события.
Предположу, что мы уже оба в достаточной мере высказали свою позицию. На чем предлагаю попрощаться.
Хочу видеть UI контрол
Тут полно таких: https://mol.hyoo.ru/#!section=demos
Хочешь интерактивно управляй их состоянием, хочешь реактивно связывай между собой одним из 4 видов биндингов.
Десктоп испокон живет без нее
Урезанная и глючная реактивность называемая "биндингами", уже давно кочует из одной десктопной библиотеки в другую.
Статья ни о чем. За главу "Паттерны" поставил статье минус, потому что просто нельзя взять и сказать, что веб-приложения - это просто. Нет, блин, не просто. Это совсем не просто и никогда просто не было, если вы разрабатывали хоть что то сложнее лендинга.
Все эти букерские сайты с миллионами фильтров по десятками категорий, медицинские или научные платформы для исследований или фиксации результатов, всякие фигмы и прочее - это офигенно сложные инженерные решения.
Для их реализации потребовалось внушительное количество человеко-часов, а чтобы всё это было хоть сколько нибудь поддерживаемым, потребовалось усилий гораздо больше, чем накатать хобби проект на JQuery, а потом заявлять, как раньше трава была зеленее (Я знаю что автор оригинала использовал React, я намеренно упомянул Jquery).
P.S Смешно читать подобное от человека, который пишет на Java фабрики для фабрик, которые перекладывают данные в синглтон, а потом называет это всё дело как то типа StaticVoidNullGetPointerPositionInterfaceClass
Напомнило
А истина где-то рядом. Очевидно же, что все эти ваши Реакт, все это является надстройкой к эталонной модели OSI.
От сюда и пляшите. Структурируйте, организуйтесь, исполняйте, получайте сертификат. И тогда Большая Тройка заработает более-менее. остальные остануться маргиналами, но кое-кто из них будет продвигаться в Большую Тройку (производители железа, ОС и конечного ПО):
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28575664
Можно долго ругать автора на тему "как он посмел сказать такое", но оглянувшись на вставку стилей в код и фактическое превращение css-классов в id, можно таки предположить, что кое-что во фронте давно идет не туда. Некоторые уже бояться (не умеют) использовать "основной фреймворк", http://vanilla-js.com/, и вместо него пишут сайт-визитку на TS только потому, что "так принято".
Также, я слышал про такую штуку на бэке, как компиляторы - программы, которые можно установить, обновлять и собирать в них код в другие программы. Например компилятор для С может занимать 100кб в одном файле.
А чтобы собирать (например соединить 2 CSS файла в один со сжатием) фронт, который в чистом виде вообще не надо собирать, нужно держать на диске тысячи файлов, которые могут занимать гигабайты. И да, управление только через консоль - нормальный GUI не придумали. И да, зависимости проверяются постфактум (возможно вами), и каждая из них может снести все данные с вашего компа - https://www.opennet.ru/opennews/art.shtml?num=56870
Недавно слышал мотив выбора React для простейшей работы - "Мы не наймем топ-разработчика для поддержки чего-то на чистом JS, поэтому будем делать это на React"
- KISS? - Что-то слышали. Это про то, что нужно делать как можно сложнее?
Некоторые уже бояться (не умеют) использовать "основной фреймворк", http://vanilla-js.com/, и вместо него пишут сайт-визитку на TS только потому, что "так принято".
Нет, просто так проще. Я писал на чистом JS. Буквально год назад поддерживал сайт на чистом JS, который даже не собирался, и имел поддерживал с IE11. И скажу честно: ванильный JS просто требует сильно больше, чем дает, даже в самых простых кейсах.
Ну и из забавного, чтобы люди задумались: когда люди пишут, что многие вещи можно делать на чистом JS (чаще всего подобное слышу от бекендеров, что забавно), это звучит так же, как если бы бекендеру на Java сказали, что его простую задачу можно решить на Си или ассемблере, без нагромождения всех этих фреймворков, БД и т.п.
требует сильно больше, чем дает, даже в самых простых кейсах
Может быть это просто вопрос компетенций?
Нет, просто так проще
Если ты чего-то не знаешь, конечно тебе проще сделать так, как знаешь
это звучит так же, как если бы бекендеру на Java сказали, что его простую задачу можно решить на Си или ассемблере, без нагромождения всех этих фреймворков, БД и т.п.
Если какую-то задачу можно просто и быстро решить одной-двумя строчками на C/ассемблере, а вместо этого городят тонны Java, это определенно плохо и говорит о том, что руководство поставило не того разработчика (особенно теперь, когда ИИ может вполне соорудить рабочий код и на том и на другом)
Другое дело, что представить себе такие задачи сложно. Мы не можем просто взять и дописать к Java коду ассемблерную вставку. Чего не скажешь про JS и TS
Ну и да, тут некоторое время была статья про ассемблерные вставки в Quake (https://habr.com/ru/articles/1000200/)
Оригинальный Quake (1996) занимает около 30 Мб. Quake Champions (2017) - 30 Гб
Конечно, многое поменялось, но в первую очередь поменялся подход
От "а как тут красивее написать?" до "закрою таску быстрее. Оптимизацией займется другая команда"
Большая часть объема - это текстуры и прочее медиа, а не код.
И заставки в таких играх тормозят на железе, на котором можно эффективно майнить биток, торже из-за текстур?
А в андроид-приложениях на 1Гб тоже текстуры?
Я прекрасно понимаю, что есть разные причины. Но предлагаю не закрывать глаза на обсуждаемую, как будто это сделает ее менее острой
Статья от крайне некомпетентного разработчика.
Приводит отвратный react код, где не используется кэширование а есть загрузка из useEffect (говнокод), потом вместо мемоизации вычислений с помощью мемоизирующих селекторов или хотя бы синхронного useMemo вычисляет данные в другом useEffect (нереальный говнокод), а потом рассказывает какой реакт плохой.
Джавист, одним словом.
The cost of creating a React SPA varies, but investing in quality React.js development ensures a scalable, maintainable, and high-performing application that can grow with your business. Creating a single-page application can significantly enhance the performance and user experience of your web application.
От React всё так же веет безумием, но все об этом молчат