Как стать автором
Обновить

Комментарии 122

Ну так никто ж и не лезет в ваш удобный мирок иллюзий. Пишите и дальше без ООП, плодите лапшу в коде и будьте счастливы. А мы как-нибудь со своим Angular сами разберёмся. (Адресовано автору текста, само собой)
Но все же доля правды во вбросе автора есть )
Не могли бы Вы эту «долю правды» в виде tl;dr сформулировать?
Порог вхождения в ангулар местами неоправданно высокий.
Спасибо, правда, честно говоря, неожиданная выжимка из этой статьи :)
Хотя, все же интересно, уточнить, где именно это порог вхождения высокий? Потому что та специфика, за которую зацепился автор, она как бы и не должна изначально всплыть. Так как сервисы и разные их вариации начинаются тогда, когда начинаешь задумываться о декомпозиции, а соответственно архитектуре приложения. Но если человек об этом начал задумываться, то как-то сомнительно, что у него вызовет какие-то проблемы разобраться с разными вариациями сервисов и понять, зачем они нужны.
Есть PHP, там низкий
«Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду %yourPreferredOOFramework%» © ))
Ога, а ООП — это прям верное средство от лапши.
К оригинальной статье был комментарий удачный —

У меня была проблема и я решил ее добавив в проект ангуляр. Теперь у меня есть Problem Directive Provider
Между «пишите без ООП» и CarProviderProvider есть очень много градаций.

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

Кстати, в моем типичном ангулярном приложении большинство сервисов — это самые что ни на есть POJO (и при этом да, там есть провайдеры и фабрики).
Для господ заминусовавших, видимо разделяющих незнание автора статьи — никто не пишет определение провайдера с именем CarProvider, у него должно быть имя Car, так как он определяет инжектируемую сущность, а не класс провайдера. Автор сам пошел неправильным путем, написав CarProvider, после чего должен пенять на собственную глупость, а не на странную получившуюся в итоге инжектируемую сущность CarProviderProvider.
Для меня счастье, что можно практически забыть о селекторах, dom и лапши в коде, но за всё хорошее приходится платить.
Тут палка о двух концах. Разобраться в селекторах и лапше под силу любому джуниору (оставим эффективность). А при виде ангулара новички впадают в транс.
Зависит от джуниоров и того как написано. У нас джуниоры нормально добавляют новые правила валидации к существующему коду. Когда примеры есть и ничего особенно замысловатого добавлять не надо.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Начать пользоваться ангуларом можно почти сразу же. Действительно освоить — совсем другое дело.

А не освоив по-настоящему, можно по несколько дней выяснять, почему что-то с чем-то вдруг не байндится. Микрофреймворки без магии в этом смысле значительно проще в освоении
Ну я не фанат angular но все же вы также используете dom и также пишите «ng-model» и все прочее, лучше уж React. А так angular скучная не нужная вещь.
React.js прекрасен, и прекрасен в частности тем, что оставляет всю архитектуру вам и решает только одну проблему, но решает ее прелесть как хорошо.
Ember.js? Я вас умоляю. У них на форуме есть целая большая дискуссия о том, как сделать эмбер попроще так, чтобы он по learning curve смог хоть как-то приблизиться к ангуляру. Сейчас там все очень плохо в этом плане. Автор этой статьи, судя по всему, в случае эмбера ни до каких CarProviderProvider бы вообще докопаться не смог, так как просто не осилил бы написать ни одной строчки работающего кода.
ок, React тогда)
Ну это смотря с чем сравнивать. Если сравнивать Ember и Angular, то первый намного проще. А сравнивать его с React — вообще смысла нет, тут уж скорее React и Knockout сравнивать стоит. Плюс, юзать Реакт в связке с Эибером довольно удобно.
Если сравнивать Ember и Angular, то первый намного проще.
Почитайте комментарии по ссылке, что я дал выше. Это официальный форум эмбера.
Я в курсе. Я пишу и на том, и на другом достаточно долго. Эмбер явно проще. Концепции в Эмбере проще сами по себе из-за того, что многие их них менее гибкие. Плюс конвенции, плюс вложенные ограничения. Плюс лучшая документация. Видео в стиле «делаем приложение за 20 минут».

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

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

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

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

Реальное различие между ангуляром и эмбером в другом. Эмбер — это чистый фреймворк «из коробки», а ангуляр — это скорее метафреймворк, то есть такой фреймворк для написания своего фреймворка. Это подходы с разных уровней, у ангуляра он более широкий и в конечном счете включает в себя всё, что может дать Эмбер. А конечные юзкейсы приложений у них совершенно одинаковые.
Автор не справился с angular и у него бомбануло?
Кстати резонный вопрос — есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?
rivets, ractive, ripple.
а также vue.js
С размазыванием HTML по коду?
Нет, спасибо.
Хм, скорее уж наоборот:)
А можно примеры? от <div>' в js меня слегка передернуло. Подхода ангуляра мне импонирует тем что это тот же хтмл.
Единственный минус ангуляра — это медленная работа с большим количеством элементов. Но недавно пост пролетал с рендерингом на React. Такой спидфолбек норм, но пока не сталкивался.
Я как-то вас не понимаю. Ведь это же в именно React HTML-ные литералы размазаны по JS-коду? return <div>Hello {this.props.name}</div>; — первый же пример с оффсайта.
То, что я перечислил, исповедует как раз обратный подход, больше похожий на Angular — HTML с директивами.
Пардон, туплю, конец рабочего дня.
Посмотрю, спасибо за подборку.
kendoui
Какие ужасные слова вы используете: «бомбануло», «батхерт».
Дети, что с них взять…
За употребление таких слов детей надо больно шлёпать по трогательно гладкой розовой попке.
Дата-байндинг и $scope — это одна фича ангуляра, а сервисы, абстракции и Dependency Injection — совсем другая, не связанная с первой.
есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?

Есть, Angular Light, — это как «выжимка» из angular.js, $scope + двойной дата биндинг + директивы. Без всяких сервисов и фабрик и т.п.
Для $scope есть нативное Micrpdata API, через которое и двойной байндинг делается достаточно легко.
P.S. Может быть я покажу себя дилетантом, т.к. не использовал в работе Angular (смотрел демки, читал доки) и могу неправильно понимать $scope.
Это api который выпилен из chrome?
Дело как раз в том, что популяризации 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 не контрибучу, поэтому меня они не послушают.
Автор перевода-то хоть согласен с автором текста?
По сути, там говорится, что для простых задач используется неоправданно сложный инструмент. Проблема вполне реальная, только вывод неправильный: не инструмент плохой, а люди, которые его используют не по назначению.
Я как раз приехал с конференции, где рассказывал о том, как мы разрабатываем фронтэнд к нашему внутреннему корпоративному софту на angularjs — и тут такой пост. Сложно пройти мимо.

Не знаю согласен ли я с автором — сам я на js без angular написал мало что. Теперь благодаря этому посту очень хочу попробовать что-то сделать с помощью просто react.js.
из всех библиотек, понравился ReactJS, тем, что ничего не навязывает и очень близок к обычному JS.
уже 3ий проект на нем и пока всем доволен, местами подмешивают jquery, потому, что он уже есть на проекте и исполльзовать можно по ситуации.
Посмотрите примеры todo.

А вообще мне еще очень нравится ractive.js
Андрей Попп на прошедшем во вторник MoscowJS классно рассказал про основные идеи, заложенные в React и его фишки.
Я нашёл только слайды, есть где-нибудь запись?
moscowjs это тоже фреймворк? ааааа
Этот пост не даёт моей мечте увянуть: увидеть пост — перевод англоязычного поста, по которому без плашечки нельзя понять, что это перевод.
Спасибо большое, это лучшее что я мог бы услышать.
Это была не похвала
А я прочитал и получил такой смысл:
Если бы было «Ваш перевод не дает моей мечте сбыться» было бы другое дело.
Тут же говорится именно о том, что перевод пусть не идеальный, но хороший, и потому благодаря таким переводам как ваш мечта не увядает (хотя и не исполняется).
Абсолютно нормальный перевод, не парьтесь! Да, по тексту видно, что это перевод, но по-моему это нормально — у них другой стиль работы с текстом, другие идиомы, и когда всё это заменяют нашими аналогами результат получается… ммм… странноватый, а когда всё это выхолащивают то, да, определить что это перевод становится почти невозможно, но текст от этого обычно много теряет.
Тут возможно ещё сыграло то, что я, получив нелестных отзывов, перевод правил в течение дня. Было хуже.
НЛО прилетело и опубликовало эту надпись здесь
Много хейта, мало вдумчивости. Если бы автор поработал над приложением, где много сложной клиентской логики, и которое пытается следовать лучшим практикам современного программирования в плане тестируемости, использования IoC, и тому подобного, то он бы сам все понял. Хотя, возможно, и не понял бы, но от этого ангуляр не становится менее прекрасным.

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

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

Ну а в целом да, у ангуляра довольно крутая learning curve, и это скорее достоинство, чем недостаток, потому что позволяет быстро и точно отсеять тот табун js monkey coders, про которых сам же автор и упомянул в начале.
А вам не кажется, что сложность ангулара не очень то позитивно сказывается на его распространении? Нет, он, конечно в тренде, и пробудет там еще (долго?), но все же…
Совсем не кажется, потому что это практически уже MVC-фреймворк #1 на данный момент. Сужу по вакансиям на odesk.com и бывшем hantim.ru — куда ни плюнь, везде требуется либо ангуляр, либо, реже, ember.js.
НЛО прилетело и опубликовало эту надпись здесь
Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых.
Это сложно.

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

И надо сказать — плохому учите. Мне всегда не нравилась эта практика защиты от мифического дурака.
Вообще эта тема может стать, если уже не стала, холиварной.
Почему сразу дурака? Я считаю, что здесь «new» играет роль boilerplate code и не нужен.

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

Не ходить по этакому минному полю — это мудро.
Ваши доводы (как и доводы Резига) об опечатках и иже с ними я не считаю серьёзными и сколько либо имеющими почву для обсуждения. Если пишете в блокноте код — продолжайте в том же духе. Жалуйтесь на опечатки и т.д. и т.п, придумывайте оправдания и костыли для того, что бы не писать качественный код, а подпирать его костылями.
Всё сказанное выше также относится и к забытому new. Но — здесь есть один момент. Чтобы не было сомнений нужен new или не нужен, просто функции-конструкторы нужно начинать с заглавной буквы (это считается хорошей практикой).
Таким образом, моё мнение сводится к тому, чтобы повышать качество кода, а не подпирать костылями говно-код, а тем более способствовать его написанию с помощью вот таких вот практик, типа автоматизированных конструкторов.
Насчёт блокнота и т.д. на свой счёт пожалуйста не принимайте — это просто метафора.
Иногда мне импонирует подход 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 получая экземпляр нужного подтипа.
Забытый new? Jshint не даст забыть, там эта опция вроде как включена по умолчанию
По мне так javascript вообще плохо подходит для написания приложений с более-менее серьезной логикой. Сужу с точки зрения разработчика системы документо-оборота (50 000 — 100 000 строчек javasript в качестве фронтенда).
Основная проблема — очень часто непонятно, что возвращают функции, какого типа объекты записаны в массив. В голове просто не умещается структура приложения и часто приходится скакать по коду, 'вспоминая' особенности реализации. В строго типизированном языке таких проблем значительно меньше.
Согласен, и для решения этой проблемы уже существует три различных решения от противоборствующих лагерей — typescript от майкрософт, dart и closure compiler от гугла. И независимо от предпочтений, все три замечательно сочетаются с ангуляром.
Кстати, по поводу 100 000 строк кода. История ангуляра началась с того, что Мишко Хевери практически на спор смог переписать фронтэнд Google Feedback, насчитывающий на тот момент 17 000 строк, так, что он уместился в 1500 строк, не потеряв в функциональности. Это к вопросу о сложных и простых вещах из комментария товарища SowingSadness ниже.
А какой фреймворк взят за основу? У меня тоже сейчас проект со сложной фронтенд логикой.
Но у меня есть четкая структура приложения, (за основу взят marionette).
Функции который возвращают что-то неизвестное отсутствуют как класс, просто потому что есть четкие правила навязаные фреймворком.
Благодаря этому, новые программисты в проекте вникают в правила очень быстро и разбираться им уже приходится только с бизнесс-правилами а не «воевать с фреймворком».
За графическую часть отвечает extjs. А так в основное время приходиться бороться с бизнес логикой, которая судя по техзаданию совершенно не логичная. Так же есть вкрапления lua кода служащего для отображается табличек 2-3 тысячи строчек(вполне типичные документы для системы документы). Ну и поддержка таких мелочей как загрузки выгрузка данных в excel на стороне клиента накладывает отпечаток.
P.S. Ко всему этому в добавок написан свой костыль для печати документа с учетом фильтров и формата страниц.
Я устал уже слушать оправдания сложных(с высоким порогом вхождения) фреймворков, что они нужны для больших и сложных приложений, поэтому и сложные.
Тут большая логическая ошибка, из первого никогда не следует второе.
Как правило, время расставляет всё на свои места и потом эти сложные фреймворки получают «заслуженную» славу.

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

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

Порог вхождения — … это требования…
Хорошо, вы мне сейчас определение в вашей интерпретации описали, а дальше то что? Вы ничего по поводу того, что этот фреймворк с высоким порогом вхождения является эффективным инструментом не сказали. Пока что лишь вижу минус в скорости обучения команды и вливания новичков.
В качестве аргумента я привел то, что мои сложные приложения от использования ангуляра стали проще, и не только мои. Я считаю это важным фактором эффективности. И как тимлид с некоторым опытом, я лучше возьму в команду дорогого специалиста, умеющего с помощью ангуляра решить сложную задачу за 1500 строк, чем трех дешевых новичков, которые напишут 17 000 строк «простого» кода с тем же результатом.
Что вы считаете сложностью кода? И как вы её высчитывали?
некие сложности в работе с ключевым словом new

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

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

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

В чем конкретно спасения Angular?
Ну там как бы сарказм был :)
Скажете тоже, Backbone. Backbone все же на уровень проще Angularjs или Ember.
Ну понятно же, что Backbone+Marionette (или Chaplin/Thorax). Но даже тогда он требует ниписания больше всякого бойлерплейта, чем Angular или Ember.
По этому нужно написать «своё решение» по сложности на уровне Angular и т.д. И тогда точно не придёт второй как ты :)
Хорошая реклама React.

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

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

http://facebook.github.io/react/
React это не фреймворк, а всего лишь View. Вместе с ангуляром кстате использовать можно http://davidchang.github.io/ngReact/
Философия у React очень понравилась мне, кстати. Т.к. MVC (или MVP) у меня всё же ассоциируется как с архитектурой всего приложения вместе с серверной частью.
Когда постепенно входило в моду MVC in MVC я становился всё более и более грустным, т.к. ничего не упрощалось, а лишь наоборот.

Пока что я не встречал ничего более простого и удобного чем React для того что бы синхронизировать состояние и DOM.
НЛО прилетело и опубликовало эту надпись здесь
После первого взгляда на доки и примеры, ощущение что это тот же Knockout.
На Knockout я писал и Ractive я вижу один весомый плюс — свойства ModelView избавлены от того что они должны быть функциями.
В React же главные фишки в том, что у него виртуальный DOM и классы React можно агрегировать друг с другом. А в Knockout, Angular и Ractive — нельзя
НЛО прилетело и опубликовало эту надпись здесь
Можно ли как то в шаблоне и в методах экземпляра Ractive использовать другие экземпляры Ractive?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Если в шаблоне DonutChart можно использовать другой компонент, то это близко.
С автором согласен. То же самое я чувствовал когда писал проект на ExtJS (нынче Sencha). Такое чувство что к библиотеке явно приложился чей-то воспалённый от паттернов и прочих фабрик мозг. Допиливать под свои нужны эти компоненты было сущим адом. В результате решил забить на этот геморрой и ограничиться jquery c компонентами из jqueryUI. И тучи рассеялись и птицы запели. В конце концов часто(а у меня так всегда) бывает что не этот очкарик напротив с красными глазами, обложенный книгами по расово верному программированию вам платит деньги, а тот вечно торопящийся товарищ, обложенный обязательствами, обещаниями и контрактами, которому нужно чтобы всё было готово ещё вчера и чтобы всё работало.

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

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

Потом берешь произвольное количество девочек/индусов, и они тебе клепают 100500 форм для, например, ведения внутреннего учета в sencha architect, вообще не вникая что такое front-end разработка, браузерное окружение и прочее.
«Отличный код из маленьких модулей и автономных функций и виджетов» — это как раз про Angular. В гораздо большей степени, чем про jQuery. Вот когда вы делаете приложение, в котором маленькие модули и автономные виджеты приходится друг с другом увязывать, сервисы Angular как раз оказываются весьма уместны. А так можно простой виджет для сайта зафигачить на Angular гораздо проще и изящней, чем с jQuery. Без всяких сервисов.
О, Д'артаньян
Может, я что-то непопулярное скажу, но когда появилось понятие, что сложный фреймворк это что-то плохое? Да, ангуляр сложен, потому что он решает сложные задачи! Если вам нужно вывести хелло ворлд или заполнить одну форму, у вас в руках неверный инструмент.

А когда ваш проект разрастётся до соответствующих размеров, то у вас и сервисы появятся, и фабрики сервисов, а потом ещё провайдеры фабрик сервисов, только с той разницей, что напишете вы их сами, и на колене, и с соответственным качеством.
Просто ребята с большим бэкграундом по java, перенесли все эти фишки в js, вот и все. Там так решаются сложные задачи, через фабрики, паттерны и паттерны фабрик. Знаете как решать сложные задачи простым способом, создайте свой фреймворк. jQuery кстати решает 80% проблем на клиенте, при желании можно шаблоны прикрутить + require js для модульности или browserify и будет нормальная такая замена.
В этом треде не хватает вброса про Backbone.
Пст, не пали контору )
Судя по комментариям — есть те кто согласен со статьей.
Это одна из причин почему появился Angular Light
Ну да, по началу было сложно разобраться в отличиях между фабрикой и провайдером. Но у меня и опыта в программировании не было и английский не знал. А вот почему автор, так и не понявший этих вещей, получал зарплату в большой компании… лучше бы он этот вопрос обсудил, а мы бы все посмеялись)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории