stanlee: ну вы же сами сказали - с webpack то что было раньше легко делать теперь сложно.
webpack - это бандлер. Если стили не являются частью ваших модулей - лучше собирать их gulp-ом и gulp-ом же запускать webpack (не webpack stream а просто webpack).
Попытки заменить таскраннер бандлером не очень то оправданы. Есть еще куча вещей которые лучше сделать просто в gulp-е. У меня например после сборки webpack-ом еще какие-то мелочи делаются, например запускаются тесты, генерятся репорты и в итоге собирается zip файлик с результатом сборки.
w3u - серьезно? Повторюсь, мне не особо интересны интерфейсы десктопов 90-х. Но если вам хочется... под второй ангуляр сходу не нашел, но есть под первый. И это первое что я нашел. Остальное - модальные окна, UI компоненты - их тьма. Лично я использую twitter bootstrap и angular material и в принципе мне хватает. Я использую несколько другие подходы при проектировании UI своих приложений.
Для первого валом бесплатных плагинов. Платные плагины для jQuery? вы использовали оные? Меня как-то эта беда обошла стороной. Только опенсурс.
Ну и да - никто не запрещает вам использовать jQuery плагины в проектах на ангуляр. Иногда приходится, просто надо изолировать это добро в директивку.
CAMOKPYT: сделать плохо можно всегда и используя что угодно.
Вообще не хватает примеров реальных приложений на гитхабах. В частности с такими вот штуками. К сожалению делать бесполезный пример у меня нет никакого желания, а мини-приложеньку пример со схожим функционалом, которую можно выложить в опенсурс что бы оно хоть кому пользу приносила - такую я придумать просто так не могу. Если у вас будут на этот счет мысли - поделитесь, мне может даже будет не лень подготовить пример.
По поводу форм - есть форм билдеры, так что лапшы уже будет меньше. Можно подробить все на директивы, для модальных окон есть возможнос регистрировать их как отдельные вьюшки и прокидывать туда часть состояний.
Что до того что "кода столько же" - зато код проще, меньше побочных эффектов, проще отлаживать и, как вы уже заметили, проще тестировать.
Качество не в количестве кода меряется а в возможности скейлиться как никак.
CAMOKPYT: не ну если хочется делать UI аля 90-е то согласен. Но мы же говорим о приличных приложениях, с какой-то минимальной бизнес логикой на клиенте и т.д. И пусть разработка фронтэнда усложняется если сравнивать со старыми добрыми формами и jquery, то бэкэнд сильно упрощается и по итогу мы получаем в сумме профит.
Пример - да, для первого ангуляра. Для второго суть будет примерно та же, только не надо будет кастыли вставлять для ngModel.
CAMOKPYT: я пишу на Angular вот уже 2 года, и это безумно эффективно если знать что делаешь.
По поводу "зачем мне фреймворе, если все что сложнее тудушек надо писать руками" - я вам даже больше скажу, и todo-ки придется писать руками. Вот только огромный процент рутины возьмет на себя angular.
Ну вот, вы уже описали случаи когда ваша сортировка особенно эффективна. Осталось только реально посчитать алгоритмическую сложность вашего алгоритма для подобных случаев (когда не отсортировано 10% выборки, при разных вероятностных распределениях и т.д.)
из этого можно очень крутую статью родить которая мало того что расскажет о нюансах выбора алгоритмов, придумывания своего под конкретную ситуацию и т.д. А еще эту статью можно кидать в качестве ответа на вопрос "зачем нас учат пузырек писать, это ж никогда не пригодится". Мол задача может попасться где модифицированный пузырек справляется эффективнее модных квиксортов.
copal: в JS все объекты, хотите вы того или нет. И с изоляцией изменений проблем нет и без ООП (инкапсуляция организовать можно как угодно).
Модификаторы доступа - кастыли в виду отсутствия модулей (эмуляция областей видимости по сути, даже дядя Боб так говорит). Абстрактные и приватные классы... ну не кастыли а необходимость, в функциональном мире это все решается чуть проще просто опять же за счет областей видимости и модулей.
Паттерны - они сами по себе то сводятся к двум-трем паттернам, а все множество названий - та же структура и идея но просто в разных контекстах и для разных целей.
И это все - далеко не архитеткура. Это просто слова, термины и подходы. Архитектура не в паттернах.
CAMOKPYT: увы в опенсурсе подобных проектов банально нет. Подавлюящее количество проектов где было бы прикольно посмотреть исходники закрыто NDA, и вам это прекрасно известно.
А что до архитектуры - stateless-компоненты, unidirectional data flow (redux например) и вперед. ну и не забываем про готовые решения.
Опять же тесты и ходить по граблям и получать экспириенс. Вообще помимо JS надо таки знать хоть что-то об архитектуре и подходах к разработке и неплохо так знать JS. Подавляющее же количество разработчиков сразу после установки плагинов на jquery начинают писать поделки на ангуляре. Как думаете, какое будет у них качество?.
То о чем вы говорите не имеет отношения ни к реакту, ни к розеткам. Вы можете вызвать logout из кнопки send, можете послать через диспатчер запрос на выполнение действия, а можете еще хоть как делать. Это ваше право.
И что за чушь с инджектором? Вы про "не пользуйтесь $injector потому что сервис локатор это плохо" или о чем вообще? Есть Dependency Inversion (не путать с Injection). И в JS это дело разруливается модулями (как и в Python или Ruby или Haskell). А уж используется контейнер зависимостей или фабрики или еще чего - это детали реализации. И это опять же к ООП отношения не имеет никакого так как этот подход практиковали с 60-х в Си используя в качестве модулей таблички указателей на функции и т.д.
copal: да будет вам. ООП на самом деле избыточен для большинства современных приложений. 80% ООП штуковин придуманы так как они есть, что бы было удобнее справляться с последствиями мутабельности данных. Если у нас все данные имутабельные, то работают уже чуть другие подходы, благо нынче нет проблем с тем что бы лишний раз выделить 16 килобайт оперативки, память стала дешевой и продолжает дешеветь.
Компоненты не имеют собственного EventDispatcher - потому что он там не нужен. Ну вот совсем не нужен. Если посмотреть схемку Flux/Redux то там диспатчер таки используется но это уже уровень приложения а не уровень UI.
Посмотрите например мой пример. Если у вас есть предложения где там диспатчер воткнуть что бы все стало ок, то милости прошу сделать PR или хотя бы отписать мне в личку/gitter.
Что до gamedev о котором вы так любите вспоминать, даже думать неочем. Это очень специфичная задача, и шаблоны проектирования там применяются чуть отличные от WEB-а (Entity component systems вместо MVC), и копировать на каждый чих миллион объектов там не выгодно...
Почитайте про функциональное программирование, вот там есть над чем подумать.
А то что ООП много кто не знает - ну так это проблема не только JS разработчиков. А еще большая проблема среди разработчиков - упертость, консерватизм, внимание слишком много уделяют второстепенным вещам.
Ivan Soshnikov: точно так же - денормализовать потом не проблема. А EAV хорошо описанный подход который решает все проблемы, хорошо скейлится (в плане функциональности) и в принципе ок.
Опять же для e-commerce если очень переживать какую модель хранения данных использовать - всегда можно вооружиться event sourcing-ом и формировать оптимизированную денормализованную структуру для монги той же. Ну или опять же - каталог хранить в той же монге или эластике.
Джон Голт: ну так придумайте. Те штуки которые мне нужны вы просто не сделаете. А что вам нужно - я без понятия.
todomvc - это простое приложение на котором можно много чего попробовать. А самое полезное - есть десятки готовых реализаций и всегда можно сравнить решения.
webpack - это бандлер. Если стили не являются частью ваших модулей - лучше собирать их gulp-ом и gulp-ом же запускать webpack (не webpack stream а просто webpack).
Попытки заменить таскраннер бандлером не очень то оправданы. Есть еще куча вещей которые лучше сделать просто в gulp-е. У меня например после сборки webpack-ом еще какие-то мелочи делаются, например запускаются тесты, генерятся репорты и в итоге собирается zip файлик с результатом сборки.