MA> Ну и в целом — реактивность не везде нужна. Выпендреж в виде реакта — имхо, вообще не нужен. Сам подход — известен был до того как они фейсом то научились торговать. Ангуляр — аналогично. По большому счету вкусовщина.
MA> Вот как найдут единственно правильный...
В браузере нужны две вещи:
— встроенный легкий пабсаб
— встроенная легкая база данных, в которой можно подписываться на changesets
— встроенный virtual dom
Это убивает 90% говна, нагороженного воркруг постройки stateful UI и попытки нормально его отрисовать, не убивая браузер. Первые два пункта убивают redux и его производные. Второе убивает собственно все возможные варианты virtual dom'а.
Но увы. w3c дрочит на мертворожденные web components, которые устарели еще 4 года тому назад.
Re[8]: JavaScript (точнее front-end) в 2018 году...
Здравствуйте, andini, Вы писали:
A>Не важно, что там внедрено. Следующее твое заявления является ложью:
A>
A>И даже в этом случае в шаблоне нет логики.
В шаблоне Angular ты не можешь писать куски JS. А вот в React — пожалуйста. В этом разница.
С этим будем спорить?
A>То есть:
A>
A><div className="class">text</a>
A>
A>это просто более лаконичный способ записи следующего кода
A>
A>React.createElement('div', {className: "class"}, ["text"]);
A>
И что это меняет? Все равно по факту в шаблоне можно писать куски JS.
Вот, в старом ASP.Net Classic — тоже в шаблоне можно было писать куски кода на C#. Там тоже все HTML-элементы превращались в классы. И что? Сама парадигма ошибочная — у вас смесь шаблона (представления) и логики (кода на JS любого размера).
Минимальная логика на стороне представления — типа показывать или нет тот или иной участок — допустима. Но в React у вас в шаблоне могут быть огромные куски кода — это ничем не ограничивается.
A>В отличие от ангуляра, который имеет:
A>- HTML-подобный шаблон в виде строки A>- со специальными маркерами для интерполяции некоторого ограниченного набора JS {{}}
Вот в этих ограничения и вся соль — чтобы нельзя было использовать JS на стороне шаблона.
Здравствуйте, Shmj, Вы писали:
S>Судя по трендам Google — Angular не так популярен как React. И этого и следовало ожидать, ведь Angular идеологически более правильный. А React — это лапша из JS кода и HTML, по сути — а толпе именно это и подавай (макаронный моннстр и его последователи, понимаш, любят лапшичку!).
не знаю откуда Google берет свои тренды, но Angular обьективно более востребованный на рынке труда, имеет "нормальные" классы и подход к разработке естественный для обычного разработчика
Здравствуйте, Shmj, Вы писали:
S>Вообще, какой наиболее оптимальный набор этих самых библиотек/фреймворков сегодня?
зачем темлейты в студии? create-react-app же
Я с redux не могу работать, уродец какой-то. остановился на mobx и счастлив
поэтому для меня необходимые шаги
1. create-react-app
2. npm run eject
3. yarn add react-router react-router-dom mobx mobx-react axios @babel/plugin-proposal-decorators
4. package.json=> babel=>plugins:
Здравствуйте, andini, Вы писали:
A>Ядро реката не такое большое. И точно не требует AOT и Bazel, чтобы собраться в что-то вменяемое, как Angular. Самая большая его часть — это React DOM. В основном из-за того, что там внутри до сих пор поддержка всякой экзотики и, например, "выравнивание" событий между браузерами ("synthetic events" https://reactjs.org/docs/events.html). DOM там урезается чуть ли не на порядок, если это из него убрать, но они пока не могут (хотя планы есть).
есть PReact где все это уже выкинули, вместе с preact-compact 6kb
Re[2]: JavaScript (точнее front-end) в 2018 году...
Здравствуйте, koenig, Вы писали:
K>не уверен, что оно изменилось
K>бесконечные, просто бесконечные итерации по выбору фреймворка
не знаю, я не вижу особо большого выбора на данный момент,
старые игроки почти окончательно сдохли( Backbone, knockout, jquery )
Vue — китайский клон Реакта по сути, китайщиной оттуда прямо несет( в то числе комьюнити, и часто семплы на китайском )
по сути выбор Angular&React&Ember
и выбор по большому продиктован опытом комманды
Re[3]: JavaScript (точнее front-end) в 2018 году...
Здравствуйте, koenig, Вы писали:
K>это если он есть и он одинаковый, а иначе ...
если внутри команды сложно прийти к консенсусу — то это организационные и коммуникационные проблемы а не технологические
Успешные проекты делают на любом из фреймворков
Re[2]: JavaScript (точнее front-end) в 2018 году...
I just replied in another thread. I will copy the answer. TLDR; the benefits of Redux are not free and most apps don't need them:
I'd argue that Redux is overused. See also You Might Not Need Redux by its author. It's not that Redux doesn't solve valid problems. Rather, most apps do not need to solve these problems. You get nice properties out of Redux. But the are not free. You pay for them at least with boilerplate.
MobX, and transparent reactive paradigms in general, are not without their pitfalls. But the deal you accept is, in my opinion, much better for most apps.
People use Mobx because they love it.
People use Redux because they were shamed through functional programming imposter syndrome into believing that they must write 5x the code, use an entire ecosystem of packages and spend half their productive coding time thinking about state management instead of just using Mobx, being happy and moving on.
Re[5]: JavaScript (точнее front-end) в 2018 году...
Автор mobx сделал еще вот такую штуку: https://github.com/mweststrate/immer про которую реактовцы говорят, что это самое близкое к видению реакта, и куда он должен развиваться.
Re[6]: JavaScript (точнее front-end) в 2018 году...
И что это меняет? Все равно по факту в шаблоне можно писать куски JS.
что бы было проще — в реакте вообще нет шаблонов он исключительно "программный"
