Вы мне Javascript сломали

[@Paul_Smith]

Ну так никто ж и не лезет в ваш удобный мирок иллюзий. Пишите и дальше без ООП, плодите лапшу в коде и будьте счастливы. А мы как-нибудь со своим Angular сами разберёмся. (Адресовано автору текста, само собой)

[@creage]

Но все же доля правды во вбросе автора есть )

[@aav]

Не могли бы Вы эту «долю правды» в виде tl;dr сформулировать?

[@creage]

Порог вхождения в ангулар местами неоправданно высокий.

[@aav]

Спасибо, правда, честно говоря, неожиданная выжимка из этой статьи :)
Хотя, все же интересно, уточнить, где именно это порог вхождения высокий? Потому что та специфика, за которую зацепился автор, она как бы и не должна изначально всплыть. Так как сервисы и разные их вариации начинаются тогда, когда начинаешь задумываться о декомпозиции, а соответственно архитектуре приложения. Но если человек об этом начал задумываться, то как-то сомнительно, что у него вызовет какие-то проблемы разобраться с разными вариациями сервисов и понять, зачем они нужны.

[@bubuq]

Есть PHP, там низкий

[@HandleX]

«Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду %yourPreferredOOFramework%» © ))

[@clamaw]

Ога, а ООП — это прям верное средство от лапши.

[@vittore]

К оригинальной статье был комментарий удачный —

У меня была проблема и я решил ее добавив в проект ангуляр. Теперь у меня есть Problem Directive Provider

[@int19h]

Между «пишите без ООП» и CarProviderProvider есть очень много градаций.

В той же Java особый термин POJO в свое время тоже не просто так появился.

[@artch]

CarProviderProvider — это замечательный пример в статье, показывающий, что ее автор вообще не понимает, что такое сервисы в ангуляре и как их готовить (и даже в принципе не очень знаком с базовым синтаксисом из документации). Но смешно писать умеет, этого не отнять. Хотя после этого примера дальше можно и не читать.

Кстати, в моем типичном ангулярном приложении большинство сервисов — это самые что ни на есть POJO (и при этом да, там есть провайдеры и фабрики).

[@artch]

Для господ заминусовавших, видимо разделяющих незнание автора статьи — никто не пишет определение провайдера с именем CarProvider, у него должно быть имя Car, так как он определяет инжектируемую сущность, а не класс провайдера. Автор сам пошел неправильным путем, написав CarProvider, после чего должен пенять на собственную глупость, а не на странную получившуюся в итоге инжектируемую сущность CarProviderProvider.

[@polyakov_andrey]

Для меня счастье, что можно практически забыть о селекторах, dom и лапши в коде, но за всё хорошее приходится платить.

[@creage]

Тут палка о двух концах. Разобраться в селекторах и лапше под силу любому джуниору (оставим эффективность). А при виде ангулара новички впадают в транс.

[@vittore]

Зависит от джуниоров и того как написано. У нас джуниоры нормально добавляют новые правила валидации к существующему коду. Когда примеры есть и ничего особенно замысловатого добавлять не надо.

[@Konojoto]

Начать пользоваться ангуларом можно почти сразу же. Действительно освоить — совсем другое дело.

А не освоив по-настоящему, можно по несколько дней выяснять, почему что-то с чем-то вдруг не байндится. Микрофреймворки без магии в этом смысле значительно проще в освоении

[@mr47]

Ну я не фанат angular но все же вы также используете dom и также пишите «ng-model» и все прочее, лучше уж React. А так angular скучная не нужная вещь.

[@vittore]

React.js прекрасен, и прекрасен в частности тем, что оставляет всю архитектуру вам и решает только одну проблему, но решает ее прелесть как хорошо.

[@Mushtat]

А что за проблему он решает?

[@Pozadi]

facebook.github.io/react/ дает тоже самое и не надо платить, или на крайняк emberjs.com/

[@artch]

Ember.js? Я вас умоляю. У них на форуме есть целая большая дискуссия о том, как сделать эмбер попроще так, чтобы он по learning curve смог хоть как-то приблизиться к ангуляру. Сейчас там все очень плохо в этом плане. Автор этой статьи, судя по всему, в случае эмбера ни до каких CarProviderProvider бы вообще докопаться не смог, так как просто не осилил бы написать ни одной строчки работающего кода.

[@Pozadi]

ок, React тогда)

[@alist]

Ну это смотря с чем сравнивать. Если сравнивать Ember и Angular, то первый намного проще. А сравнивать его с React — вообще смысла нет, тут уж скорее React и Knockout сравнивать стоит. Плюс, юзать Реакт в связке с Эибером довольно удобно.

[@artch]

Если сравнивать Ember и Angular, то первый намного проще.

Почитайте комментарии по ссылке, что я дал выше. Это официальный форум эмбера.

[@alist]

Я в курсе. Я пишу и на том, и на другом достаточно долго. Эмбер явно проще. Концепции в Эмбере проще сами по себе из-за того, что многие их них менее гибкие. Плюс конвенции, плюс вложенные ограничения. Плюс лучшая документация. Видео в стиле «делаем приложение за 20 минут».

В Angular очень многое делается для того, чтобы за 20 минут демо получить сногсшибательный wow-эффект. Но если человеку дать провести с каждым из них по одному дню (не один на один, а с ментором), то Эмбер нравится гораздо больше.

Вообще сложно спорить и сравнивать, ведь фреймворки предназначены для совсем разных юскейсов: Angular для SPA (т.е. приложений без урлов и переходов — например, для Google Docs Writer), а Ember — для мультистраничных веб-клиентов — например, для Github, где почти каждое слово — это ссылка. Да, с одной стороны Эмбер решает гораздо больше задач. Но с другой стороны, приложений второго типа пишется намного меньше, и значит Эмбер там не необходим, и мы возвращаемся на уровень сугубо личых предпочтений.

А это уже холивар. Что вам нравится больше: одинарные иди двойные фигурные скобки в темплейтах? Контроллеры-прокси или $scope? Ember Inspector или Batarang? и т.д. Согласитесь, смысла спорить о таком нет. Я обычно в таких случаях свожу все к тому, что Эмбер тяжелее в килобайтах, но конпоненты для него писать и отлаживать проще, чем директивы в Angular.

[@artch]

Вообще сложно спорить и сравнивать, ведь фреймворки предназначены для совсем разных юскейсов: Angular для SPA (т.е. приложений без урлов и переходов — например, для Google Docs Writer)

Ангуляр действительно хорошо подходит под SPA, только SPA — это совсем не то, что вы описали, а приложение вида «толстый клиент», где страницы рендерятся браузером, и где переходы по урлам (а они там, разумеется, есть) обрабатываются клиентом, а не сервером. И Google Docs Writer, и GitHub, и Gmail, и Twitter, и любое другое приложение с "#!" (или HTML5 History API, как на гитхабе) замечательно пишется на ангуляре.

Реальное различие между ангуляром и эмбером в другом. Эмбер — это чистый фреймворк «из коробки», а ангуляр — это скорее метафреймворк, то есть такой фреймворк для написания своего фреймворка. Это подходы с разных уровней, у ангуляра он более широкий и в конечном счете включает в себя всё, что может дать Эмбер. А конечные юзкейсы приложений у них совершенно одинаковые.

[@Insayt]

Автор не справился с angular и у него бомбануло?
Кстати резонный вопрос — есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?

[@k12th]

rivets, ractive, ripple.

[@anotherpit]

а также vue.js

[@Azy]

С размазыванием HTML по коду?
Нет, спасибо.

[@k12th]

Хм, скорее уж наоборот:)

[@Azy]

А можно примеры? от <div>' в js меня слегка передернуло. Подхода ангуляра мне импонирует тем что это тот же хтмл.
Единственный минус ангуляра — это медленная работа с большим количеством элементов. Но недавно пост пролетал с рендерингом на React. Такой спидфолбек норм, но пока не сталкивался.

[@k12th]

Я как-то вас не понимаю. Ведь это же в именно React HTML-ные литералы размазаны по JS-коду? return <div>Hello {this.props.name}</div>; — первый же пример с оффсайта.
То, что я перечислил, исповедует как раз обратный подход, больше похожий на Angular — HTML с директивами.

[@Azy]

Пардон, туплю, конец рабочего дня.
Посмотрю, спасибо за подборку.

[@mentatxx]

kendoui

[@yadobr]

Какие ужасные слова вы используете: «бомбануло», «батхерт».

[@namespace]

Дети, что с них взять…

[@Mithgol]

За употребление таких слов детей надо больно шлёпать по трогательно гладкой розовой попке.

[@artch]

Дата-байндинг и $scope — это одна фича ангуляра, а сервисы, абстракции и Dependency Injection — совсем другая, не связанная с первой.

[@lega]

есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?

Есть, Angular Light, — это как «выжимка» из angular.js, $scope + двойной дата биндинг + директивы. Без всяких сервисов и фабрик и т.п.

[@termi]

Для $scope есть нативное Micrpdata API, через которое и двойной байндинг делается достаточно легко.
P.S. Может быть я покажу себя дилетантом, т.к. не использовал в работе Angular (смотрел демки, читал доки) и могу неправильно понимать $scope.

[@freeart]

Это api который выпилен из chrome?

[@termi]

Дело как раз в том, что популяризации Microdata API как раз и мешает её отсутствие в Chromium. А выпилина экспериментальная поддержка была как раз из-за низкой популярности :) Замкнутый круг какой-то.

Ну и из-за того, что Microdata API не правильно позиционируется, это можно понять просто почитав ветку в Google Group, в которой обсуждали выпиливание.

По мне, так это не правильно. Microdata API такая же часть WEB API, как и Clipboard API (наполовину бесполезный), Drag and Drop API (кроме дропа файлов бесполезный), Keyboard API (который пилят и переписывают уже более двух лет, а в Chrome как раз реализована самая старая спецификация — самая бесполезная, и её никто не выпиливает, хотя её использовать не возможно), File API (который проигрывает по скорости и потреблению памяти флешу).

В той ситуации, когда мы, по факту, имеем в современных браузерах полу-бесполезные недоработанные (редакторами спецификации) API, которые никто напрямую не использует (потому что неудобно), выпиливание Microdata API (которая привносила действительно что-то новое) это просто верх маразма. Но, я в Chromium не контрибучу, поэтому меня они не послушают.

[@dima117]

Автор перевода-то хоть согласен с автором текста?
По сути, там говорится, что для простых задач используется неоправданно сложный инструмент. Проблема вполне реальная, только вывод неправильный: не инструмент плохой, а люди, которые его используют не по назначению.

[@Konojoto]

Я как раз приехал с конференции, где рассказывал о том, как мы разрабатываем фронтэнд к нашему внутреннему корпоративному софту на angularjs — и тут такой пост. Сложно пройти мимо.

Не знаю согласен ли я с автором — сам я на js без angular написал мало что. Теперь благодаря этому посту очень хочу попробовать что-то сделать с помощью просто react.js.

[@imgen]

из всех библиотек, понравился ReactJS, тем, что ничего не навязывает и очень близок к обычному JS.
уже 3ий проект на нем и пока всем доволен, местами подмешивают jquery, потому, что он уже есть на проекте и исполльзовать можно по ситуации.

[@vittore]

Посмотрите примеры todo.

А вообще мне еще очень нравится ractive.js

[@iSnifer]

Андрей Попп на прошедшем во вторник MoscowJS классно рассказал про основные идеи, заложенные в React и его фишки.

[@Konojoto]

Я нашёл только слайды, есть где-нибудь запись?

[@zag2art]

moscowjs это тоже фреймворк? ааааа

[@asci]

О, похоже, не я один такой.

[@ilammy]

Этот пост не даёт моей мечте увянуть: увидеть пост — перевод англоязычного поста, по которому без плашечки нельзя понять, что это перевод.

[@Konojoto]

Спасибо большое, это лучшее что я мог бы услышать.

[@DiMurer]

Это была не похвала

[@Konojoto]

Да, я очень глупо протупил, и теперь даже комментарий удалить не могу.

[@withoutuniverse]

А я прочитал и получил такой смысл:
Если бы было «Ваш перевод не дает моей мечте сбыться» было бы другое дело.
Тут же говорится именно о том, что перевод пусть не идеальный, но хороший, и потому благодаря таким переводам как ваш мечта не увядает (хотя и не исполняется).

[@powerman]

Абсолютно нормальный перевод, не парьтесь! Да, по тексту видно, что это перевод, но по-моему это нормально — у них другой стиль работы с текстом, другие идиомы, и когда всё это заменяют нашими аналогами результат получается… ммм… странноватый, а когда всё это выхолащивают то, да, определить что это перевод становится почти невозможно, но текст от этого обычно много теряет.

[@Konojoto]

Тут возможно ещё сыграло то, что я, получив нелестных отзывов, перевод правил в течение дня. Было хуже.

[@Konojoto]

Интересно, что вы это упомянули. Дело в том, что Роб уже увидел TDD и его уже немножко порвало.

[@Shaddix]

habrahabr.ru/post/172039/
Это его же пост о ТДД :)

P.S. да что ж такое, мало того, что с переводом поста опередили, так и тут… :)

[@artch]

Много хейта, мало вдумчивости. Если бы автор поработал над приложением, где много сложной клиентской логики, и которое пытается следовать лучшим практикам современного программирования в плане тестируемости, использования IoC, и тому подобного, то он бы сам все понял. Хотя, возможно, и не понял бы, но от этого ангуляр не становится менее прекрасным.

Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых. Так жизнь будет сильно роще.

В ангуляре 2.0 сервисы вообще станут обычными классами ES6 с аннотациями, и проблема исчезнет вовсе.

Ну а в целом да, у ангуляра довольно крутая learning curve, и это скорее достоинство, чем недостаток, потому что позволяет быстро и точно отсеять тот табун js monkey coders, про которых сам же автор и упомянул в начале.

[@creage]

А вам не кажется, что сложность ангулара не очень то позитивно сказывается на его распространении? Нет, он, конечно в тренде, и пробудет там еще (долго?), но все же…

[@artch]

Совсем не кажется, потому что это практически уже MVC-фреймворк #1 на данный момент. Сужу по вакансиям на odesk.com и бывшем hantim.ru — куда ни плюнь, везде требуется либо ангуляр, либо, реже, ember.js.

[@Mithgol]

Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых.

Это сложно.

Я вот по той причине, что есть некие сложности в работе с ключевым словом new, всем всегда рекомендую не использовать это слово перед конструкторами — а вместо того сами конструкторы сочинять таким образом, чтобы это были самовызывающиеся конструкторы Джона Резига.

[@AndyGrom]

всем всегда рекомендую не использовать это слово перед конструкторами

И надо сказать — плохому учите. Мне всегда не нравилась эта практика защиты от мифического дурака.
Вообще эта тема может стать, если уже не стала, холиварной.

[@Mithgol]

Почему сразу дурака? Я считаю, что здесь «new» играет роль boilerplate code и не нужен.

Можно ведь и не быть дураком, но допустить опечатку, набирая «new» (особенно в быстром темпе), ну или просто жалеть о том времени, которое будет расходоваться на чтение ужé набранного «new» в этом месте.

[@Mithgol]

Но самое главное — это, конечно, устранить высокую цену той ошибки, при которой единственный забытый оператор «new» опоганивает всю глобальную область видимости итогами работы «this.чегоУгодно» в конструкторе, и итог работы конструктора бывает далёк от желаемого.

Не ходить по этакому минному полю — это мудро.

[@AndyGrom]

Ваши доводы (как и доводы Резига) об опечатках и иже с ними я не считаю серьёзными и сколько либо имеющими почву для обсуждения. Если пишете в блокноте код — продолжайте в том же духе. Жалуйтесь на опечатки и т.д. и т.п, придумывайте оправдания и костыли для того, что бы не писать качественный код, а подпирать его костылями.
Всё сказанное выше также относится и к забытому new. Но — здесь есть один момент. Чтобы не было сомнений нужен new или не нужен, просто функции-конструкторы нужно начинать с заглавной буквы (это считается хорошей практикой).
Таким образом, моё мнение сводится к тому, чтобы повышать качество кода, а не подпирать костылями говно-код, а тем более способствовать его написанию с помощью вот таких вот практик, типа автоматизированных конструкторов.

[@AndyGrom]

Насчёт блокнота и т.д. на свой счёт пожалуйста не принимайте — это просто метафора.

[@MuLLtiQ]

Иногда мне импонирует подход Scala, где immutable-типы данных конструируются не с помощью new, а с помощью объекта-конструктора, который имеет такое же название как и имя типа конструируемого экземпляра. В этом случае есть возможность создавать объекты не одного типа, а производных этого типа, в зависимости от переданных параметров.

Что-то вроде этого

function Animal(animalType, name) {
  if (this instanceof Animal) {
    throw new Error('Should be called without "new" keyword');
  }

  var instanceType = ({
    'dog': Dog,
    'cat': Cat,
    'cow': Cow
  })[animalType];

  if (typeof instanceType == 'undefined') {
    throw new Error('Unknown type of the animal');
  }

  return new instanceType(name);
}

Animal.prototype.say = function() { throw new Error('Not implemented'); };

// -----------------------------------------------------------------------------

function Dog(name) {
  this.name = name;
}

Dog.prototype = Object.create(Animal.prototype);
Dog.prototype.constructor = Dog;
Dog.prototype.say = function() { return this.name + ' says Woof!'; };

// -----------------------------------------------------------------------------

function Cat(name) {
  this.name = name;
}

Cat.prototype = Object.create(Animal.prototype);
Cat.prototype.constructor = Cat;
Cat.prototype.say = function() { return this.name + ' says Meow!'; };

// -----------------------------------------------------------------------------

function Cow(name) {
  this.name = name;
}

Cow.prototype = Object.create(Animal.prototype);
Cow.prototype.constructor = Cow;
Cow.prototype.say = function() { return this.name + ' says Mooo!'; };

// -----------------------------------------------------------------------------

var animals = [
    Animal('dog', 'Sparky'),
    Animal('cat', 'James'),
    Animal('cow', 'Mathilda')
];

animals.forEach(function(animal) {
  console.log([animal.constructor.name, animal instanceof Animal,
      animal.say()].join(', '));
});

/*
Dog, true, Sparky says Woof!
Cat, true, James says Meow!
Cow, true, Mathilda says Mooo!
*/

Т.е. есть возможность абстрагироваться от проверки конкретных значений параметров, когда это не требуется и просто вызывать конструктор Animal получая экземпляр нужного подтипа.

[@Bektimirov]

Забытый new? Jshint не даст забыть, там эта опция вроде как включена по умолчанию

[@intet]

По мне так javascript вообще плохо подходит для написания приложений с более-менее серьезной логикой. Сужу с точки зрения разработчика системы документо-оборота (50 000 — 100 000 строчек javasript в качестве фронтенда).
Основная проблема — очень часто непонятно, что возвращают функции, какого типа объекты записаны в массив. В голове просто не умещается структура приложения и часто приходится скакать по коду, 'вспоминая' особенности реализации. В строго типизированном языке таких проблем значительно меньше.

[@artch]

Согласен, и для решения этой проблемы уже существует три различных решения от противоборствующих лагерей — typescript от майкрософт, dart и closure compiler от гугла. И независимо от предпочтений, все три замечательно сочетаются с ангуляром.

[@artch]

Кстати, по поводу 100 000 строк кода. История ангуляра началась с того, что Мишко Хевери практически на спор смог переписать фронтэнд Google Feedback, насчитывающий на тот момент 17 000 строк, так, что он уместился в 1500 строк, не потеряв в функциональности. Это к вопросу о сложных и простых вещах из комментария товарища SowingSadness ниже.

[@josser]

А какой фреймворк взят за основу? У меня тоже сейчас проект со сложной фронтенд логикой.
Но у меня есть четкая структура приложения, (за основу взят marionette).
Функции который возвращают что-то неизвестное отсутствуют как класс, просто потому что есть четкие правила навязаные фреймворком.
Благодаря этому, новые программисты в проекте вникают в правила очень быстро и разбираться им уже приходится только с бизнесс-правилами а не «воевать с фреймворком».

[@intet]

За графическую часть отвечает extjs. А так в основное время приходиться бороться с бизнес логикой, которая судя по техзаданию совершенно не логичная. Так же есть вкрапления lua кода служащего для отображается табличек 2-3 тысячи строчек(вполне типичные документы для системы документы). Ну и поддержка таких мелочей как загрузки выгрузка данных в excel на стороне клиента накладывает отпечаток.
P.S. Ко всему этому в добавок написан свой костыль для печати документа с учетом фильтров и формата страниц.

[@SowingSadness]

Я устал уже слушать оправдания сложных(с высоким порогом вхождения) фреймворков, что они нужны для больших и сложных приложений, поэтому и сложные.
Тут большая логическая ошибка, из первого никогда не следует второе.
Как правило, время расставляет всё на свои места и потом эти сложные фреймворки получают «заслуженную» славу.

А судить тех, кто не желает сено перекидывать штыковой лопатой, я бы не стал.

[@artch]

Порог вхождения — это не блажь или злые козни разработчика фреймворка, желающего потешить свое самолюбие, а объективные требования к квалификации программиста. Ангуляр сложный ровно настолько, насколько это требуется. Я и до ангуляра писал приложения, используя примерно те же самые подходы, просто не настолько элегантно выполненные. Для меня ангуляр сделал работу проще, а не сложнее.

[@SowingSadness]

| Порог вхождения — это не блажь или злые козни разработчика фреймворка, желающего потешить свое самолюбие, а объективные требования к квалификации программиста

Порог вхождения — … это требования…
Хорошо, вы мне сейчас определение в вашей интерпретации описали, а дальше то что? Вы ничего по поводу того, что этот фреймворк с высоким порогом вхождения является эффективным инструментом не сказали. Пока что лишь вижу минус в скорости обучения команды и вливания новичков.

[@artch]

В качестве аргумента я привел то, что мои сложные приложения от использования ангуляра стали проще, и не только мои. Я считаю это важным фактором эффективности. И как тимлид с некоторым опытом, я лучше возьму в команду дорогого специалиста, умеющего с помощью ангуляра решить сложную задачу за 1500 строк, чем трех дешевых новичков, которые напишут 17 000 строк «простого» кода с тем же результатом.

[@SowingSadness]

Что вы считаете сложностью кода? И как вы её высчитывали?

[@vitalets]

некие сложности в работе с ключевым словом new

А можно поподробней про это?

[@yadobr]

Действительно существует проблема многослойных, зачастую не нужных абстракций. И в итоге код не становиться проще, а наоборот — усложняется.
И поэтому, использовать angular повсеместно, просто глупо. Для простых вещей — простые инструменты, для сложных — сложные.

Angular решает проблему ознакомления, когда новый человек приходит в команду и тратит меньше времени на знакомство с архитектурой.
Но, не для этого ли существуют паттерны проектирования?

[@YSO]

Сказочный перевод… И где ссылка на оригинал?
codeofrob.com/entries/you-have-ruined-javascript.html

[@Argutator]

Справа от стрелок, которыми пост оценивается. Сразу же после звездочки «добавить в избранное».

[@YSO]

От я лошара. Буду знать.

[@front_end]

Вы не понимаете, AngularJS — это спасение всех front-end разработчиков! Вот раньше ты верстал за 30К 10 лет назад, тебя взяли и выкинули, уволили, растоптали потому что верстать мог любой программист таблицами… Обидно! А сейчас? Перенес всю бизнес логику на клиент, намазал все это сверху через AngularJS, подкрепил тестами, сборщиком, пакетными зависимостями, покодил все это пол года посложнее и все — без тебя дальше никак! Ты звезда команды! Тебя ждут из отпуска с нетерпением! Все плюшки твои… Но мир рушится, когда приходит он… второй такой как ты, который понимает что такое grunt, bower, yoman, angularjs…

[@misha91]

В вашем текстеAngularJS можно заменить любым другим фреймворком (Backbone, Ember etc) и смысл не поменяется.

В чем конкретно спасения Angular?

[@VasilioRuzanni]

Ну там как бы сарказм был :)

[@radist2s]

Скажете тоже, Backbone. Backbone все же на уровень проще Angularjs или Ember.

[@VasilioRuzanni]

Ну понятно же, что Backbone+Marionette (или Chaplin/Thorax). Но даже тогда он требует ниписания больше всякого бойлерплейта, чем Angular или Ember.

[@NekR]

По этому нужно написать «своё решение» по сложности на уровне Angular и т.д. И тогда точно не придёт второй как ты :)

[@Mithgol]

Хорошая реклама React.

Я сроду нигде не использовал React и даже не читал о нём, а вот теперь захотел прочесть.

Но гиперссылки-то на React тут и нету — поневоле пришлось в Гугле нагугливать, и нагуглил:

http://facebook.github.io/react/

[@misha91]

React это не фреймворк, а всего лишь View. Вместе с ангуляром кстате использовать можно http://davidchang.github.io/ngReact/

[@SowingSadness]

Философия у React очень понравилась мне, кстати. Т.к. MVC (или MVP) у меня всё же ассоциируется как с архитектурой всего приложения вместе с серверной частью.
Когда постепенно входило в моду MVC in MVC я становился всё более и более грустным, т.к. ничего не упрощалось, а лишь наоборот.

Пока что я не встречал ничего более простого и удобного чем React для того что бы синхронизировать состояние и DOM.

[@SowingSadness]

После первого взгляда на доки и примеры, ощущение что это тот же Knockout.
На Knockout я писал и Ractive я вижу один весомый плюс — свойства ModelView избавлены от того что они должны быть функциями.
В React же главные фишки в том, что у него виртуальный DOM и классы React можно агрегировать друг с другом. А в Knockout, Angular и Ractive — нельзя

[@SowingSadness]

Можно ли как то в шаблоне и в методах экземпляра Ractive использовать другие экземпляры Ractive?

[@SowingSadness]

Нет.
Вот это: facebook.github.io/react/docs/tutorial.html#composing-components

[@SowingSadness]

Если в шаблоне DonutChart можно использовать другой компонент, то это близко.

[@sigod]

Взгляните на:
docs.ractivejs.org/latest/components
docs.ractivejs.org/latest/partials

[@SowingSadness]

Да, похоже на то.

[@ukostin]

С автором согласен. То же самое я чувствовал когда писал проект на ExtJS (нынче Sencha). Такое чувство что к библиотеке явно приложился чей-то воспалённый от паттернов и прочих фабрик мозг. Допиливать под свои нужны эти компоненты было сущим адом. В результате решил забить на этот геморрой и ограничиться jquery c компонентами из jqueryUI. И тучи рассеялись и птицы запели. В конце концов часто(а у меня так всегда) бывает что не этот очкарик напротив с красными глазами, обложенный книгами по расово верному программированию вам платит деньги, а тот вечно торопящийся товарищ, обложенный обязательствами, обещаниями и контрактами, которому нужно чтобы всё было готово ещё вчера и чтобы всё работало.

И да, мне больше симпатизирует следующий подход: для простых вещей — простые инструменты, для сложных — тоже простые. :)

[@mrjj]

ExtJS не ныне сенча, а приобретен Sencha и существует в рамках их продуктовой линейки.

Принципиальная особенность ExtJS в том что он по большей части декларативен и configuration driven, разумеется, это усложняет разработку отдельно взятых компонентов, но обеспечивает конечную цель, важную для enterprise приложений — ты берешь одного-двух умных программистов, чтобы они заложили каркас, базовую интеграцию с бэком и недостающие компоненты. Вся сложность вытеснена в этот этап.

Потом берешь произвольное количество девочек/индусов, и они тебе клепают 100500 форм для, например, ведения внутреннего учета в sencha architect, вообще не вникая что такое front-end разработка, браузерное окружение и прочее.

[@bloomdido]

«Отличный код из маленьких модулей и автономных функций и виджетов» — это как раз про Angular. В гораздо большей степени, чем про jQuery. Вот когда вы делаете приложение, в котором маленькие модули и автономные виджеты приходится друг с другом увязывать, сервисы Angular как раз оказываются весьма уместны. А так можно простой виджет для сайта зафигачить на Angular гораздо проще и изящней, чем с jQuery. Без всяких сервисов.

[@MniD]

О, Д'артаньян

[@bubuq]

Может, я что-то непопулярное скажу, но когда появилось понятие, что сложный фреймворк это что-то плохое? Да, ангуляр сложен, потому что он решает сложные задачи! Если вам нужно вывести хелло ворлд или заполнить одну форму, у вас в руках неверный инструмент.

А когда ваш проект разрастётся до соответствующих размеров, то у вас и сервисы появятся, и фабрики сервисов, а потом ещё провайдеры фабрик сервисов, только с той разницей, что напишете вы их сами, и на колене, и с соответственным качеством.

[@feligz]

Просто ребята с большим бэкграундом по java, перенесли все эти фишки в js, вот и все. Там так решаются сложные задачи, через фабрики, паттерны и паттерны фабрик. Знаете как решать сложные задачи простым способом, создайте свой фреймворк. jQuery кстати решает 80% проблем на клиенте, при желании можно шаблоны прикрутить + require js для модульности или browserify и будет нормальная такая замена.

[@josser]

В этом треде не хватает вброса про Backbone.

[@mrjj]

Пст, не пали контору )

[@lega]

Судя по комментариям — есть те кто согласен со статьей.
Это одна из причин почему появился Angular Light

[@remal]

www.youtube.com/watch?v=TSAlj04_tkA
www.youtube.com/watch?v=cPXTozVjSHo
Очень хороший доклад про Java. Схожие проблемы, как мне показалось, затрагивается. Советую не только Java-программистам.

[@tamtakoe]

Ну да, по началу было сложно разобраться в отличиях между фабрикой и провайдером. Но у меня и опыта в программировании не было и английский не знал. А вот почему автор, так и не понявший этих вещей, получал зарплату в большой компании… лучше бы он этот вопрос обсудил, а мы бы все посмеялись)