Комментарии 122
Ну так никто ж и не лезет в ваш удобный мирок иллюзий. Пишите и дальше без ООП, плодите лапшу в коде и будьте счастливы. А мы как-нибудь со своим Angular сами разберёмся. (Адресовано автору текста, само собой)
+1
Но все же доля правды во вбросе автора есть )
+71
Не могли бы Вы эту «долю правды» в виде tl;dr сформулировать?
0
Порог вхождения в ангулар местами неоправданно высокий.
+13
Спасибо, правда, честно говоря, неожиданная выжимка из этой статьи :)
Хотя, все же интересно, уточнить, где именно это порог вхождения высокий? Потому что та специфика, за которую зацепился автор, она как бы и не должна изначально всплыть. Так как сервисы и разные их вариации начинаются тогда, когда начинаешь задумываться о декомпозиции, а соответственно архитектуре приложения. Но если человек об этом начал задумываться, то как-то сомнительно, что у него вызовет какие-то проблемы разобраться с разными вариациями сервисов и понять, зачем они нужны.
Хотя, все же интересно, уточнить, где именно это порог вхождения высокий? Потому что та специфика, за которую зацепился автор, она как бы и не должна изначально всплыть. Так как сервисы и разные их вариации начинаются тогда, когда начинаешь задумываться о декомпозиции, а соответственно архитектуре приложения. Но если человек об этом начал задумываться, то как-то сомнительно, что у него вызовет какие-то проблемы разобраться с разными вариациями сервисов и понять, зачем они нужны.
0
Есть PHP, там низкий
+3
«Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду %yourPreferredOOFramework%» © ))
+9
Ога, а ООП — это прям верное средство от лапши.
+39
К оригинальной статье был комментарий удачный —
У меня была проблема и я решил ее добавив в проект ангуляр. Теперь у меня есть Problem Directive Provider
+35
Между «пишите без ООП» и CarProviderProvider есть очень много градаций.
В той же Java особый термин POJO в свое время тоже не просто так появился.
В той же Java особый термин POJO в свое время тоже не просто так появился.
+3
CarProviderProvider — это замечательный пример в статье, показывающий, что ее автор вообще не понимает, что такое сервисы в ангуляре и как их готовить (и даже в принципе не очень знаком с базовым синтаксисом из документации). Но смешно писать умеет, этого не отнять. Хотя после этого примера дальше можно и не читать.
Кстати, в моем типичном ангулярном приложении большинство сервисов — это самые что ни на есть POJO (и при этом да, там есть провайдеры и фабрики).
Кстати, в моем типичном ангулярном приложении большинство сервисов — это самые что ни на есть POJO (и при этом да, там есть провайдеры и фабрики).
-2
Для господ заминусовавших, видимо разделяющих незнание автора статьи — никто не пишет определение провайдера с именем CarProvider, у него должно быть имя Car, так как он определяет инжектируемую сущность, а не класс провайдера. Автор сам пошел неправильным путем, написав CarProvider, после чего должен пенять на собственную глупость, а не на странную получившуюся в итоге инжектируемую сущность CarProviderProvider.
+4
Для меня счастье, что можно практически забыть о селекторах, dom и лапши в коде, но за всё хорошее приходится платить.
+8
Тут палка о двух концах. Разобраться в селекторах и лапше под силу любому джуниору (оставим эффективность). А при виде ангулара новички впадают в транс.
+6
Зависит от джуниоров и того как написано. У нас джуниоры нормально добавляют новые правила валидации к существующему коду. Когда примеры есть и ничего особенно замысловатого добавлять не надо.
-2
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Начать пользоваться ангуларом можно почти сразу же. Действительно освоить — совсем другое дело.
А не освоив по-настоящему, можно по несколько дней выяснять, почему что-то с чем-то вдруг не байндится. Микрофреймворки без магии в этом смысле значительно проще в освоении
А не освоив по-настоящему, можно по несколько дней выяснять, почему что-то с чем-то вдруг не байндится. Микрофреймворки без магии в этом смысле значительно проще в освоении
+9
Ну я не фанат angular но все же вы также используете dom и также пишите «ng-model» и все прочее, лучше уж React. А так angular скучная не нужная вещь.
+11
facebook.github.io/react/ дает тоже самое и не надо платить, или на крайняк emberjs.com/
0
Ember.js? Я вас умоляю. У них на форуме есть целая большая дискуссия о том, как сделать эмбер попроще так, чтобы он по learning curve смог хоть как-то приблизиться к ангуляру. Сейчас там все очень плохо в этом плане. Автор этой статьи, судя по всему, в случае эмбера ни до каких CarProviderProvider бы вообще докопаться не смог, так как просто не осилил бы написать ни одной строчки работающего кода.
+1
ок, React тогда)
0
Ну это смотря с чем сравнивать. Если сравнивать Ember и Angular, то первый намного проще. А сравнивать его с React — вообще смысла нет, тут уж скорее React и Knockout сравнивать стоит. Плюс, юзать Реакт в связке с Эибером довольно удобно.
+1
Если сравнивать Ember и Angular, то первый намного проще.Почитайте комментарии по ссылке, что я дал выше. Это официальный форум эмбера.
0
Я в курсе. Я пишу и на том, и на другом достаточно долго. Эмбер явно проще. Концепции в Эмбере проще сами по себе из-за того, что многие их них менее гибкие. Плюс конвенции, плюс вложенные ограничения. Плюс лучшая документация. Видео в стиле «делаем приложение за 20 минут».
В Angular очень многое делается для того, чтобы за 20 минут демо получить сногсшибательный wow-эффект. Но если человеку дать провести с каждым из них по одному дню (не один на один, а с ментором), то Эмбер нравится гораздо больше.
Вообще сложно спорить и сравнивать, ведь фреймворки предназначены для совсем разных юскейсов: Angular для SPA (т.е. приложений без урлов и переходов — например, для Google Docs Writer), а Ember — для мультистраничных веб-клиентов — например, для Github, где почти каждое слово — это ссылка. Да, с одной стороны Эмбер решает гораздо больше задач. Но с другой стороны, приложений второго типа пишется намного меньше, и значит Эмбер там не необходим, и мы возвращаемся на уровень сугубо личых предпочтений.
А это уже холивар. Что вам нравится больше: одинарные иди двойные фигурные скобки в темплейтах? Контроллеры-прокси или $scope? Ember Inspector или Batarang? и т.д. Согласитесь, смысла спорить о таком нет. Я обычно в таких случаях свожу все к тому, что Эмбер тяжелее в килобайтах, но конпоненты для него писать и отлаживать проще, чем директивы в Angular.
В Angular очень многое делается для того, чтобы за 20 минут демо получить сногсшибательный wow-эффект. Но если человеку дать провести с каждым из них по одному дню (не один на один, а с ментором), то Эмбер нравится гораздо больше.
Вообще сложно спорить и сравнивать, ведь фреймворки предназначены для совсем разных юскейсов: Angular для SPA (т.е. приложений без урлов и переходов — например, для Google Docs Writer), а Ember — для мультистраничных веб-клиентов — например, для Github, где почти каждое слово — это ссылка. Да, с одной стороны Эмбер решает гораздо больше задач. Но с другой стороны, приложений второго типа пишется намного меньше, и значит Эмбер там не необходим, и мы возвращаемся на уровень сугубо личых предпочтений.
А это уже холивар. Что вам нравится больше: одинарные иди двойные фигурные скобки в темплейтах? Контроллеры-прокси или $scope? Ember Inspector или Batarang? и т.д. Согласитесь, смысла спорить о таком нет. Я обычно в таких случаях свожу все к тому, что Эмбер тяжелее в килобайтах, но конпоненты для него писать и отлаживать проще, чем директивы в Angular.
+1
Вообще сложно спорить и сравнивать, ведь фреймворки предназначены для совсем разных юскейсов: Angular для SPA (т.е. приложений без урлов и переходов — например, для Google Docs Writer)
Ангуляр действительно хорошо подходит под SPA, только SPA — это совсем не то, что вы описали, а приложение вида «толстый клиент», где страницы рендерятся браузером, и где переходы по урлам (а они там, разумеется, есть) обрабатываются клиентом, а не сервером. И Google Docs Writer, и GitHub, и Gmail, и Twitter, и любое другое приложение с "#!" (или HTML5 History API, как на гитхабе) замечательно пишется на ангуляре.
Реальное различие между ангуляром и эмбером в другом. Эмбер — это чистый фреймворк «из коробки», а ангуляр — это скорее метафреймворк, то есть такой фреймворк для написания своего фреймворка. Это подходы с разных уровней, у ангуляра он более широкий и в конечном счете включает в себя всё, что может дать Эмбер. А конечные юзкейсы приложений у них совершенно одинаковые.
0
Автор не справился с angular и у него бомбануло?
Кстати резонный вопрос — есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?
Кстати резонный вопрос — есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?
-7
rivets, ractive, ripple.
+4
а также vue.js
+2
С размазыванием HTML по коду?
Нет, спасибо.
Нет, спасибо.
+2
Хм, скорее уж наоборот:)
-1
А можно примеры? от
Единственный минус ангуляра — это медленная работа с большим количеством элементов. Но недавно пост пролетал с рендерингом на React. Такой спидфолбек норм, но пока не сталкивался.
<div>
' в js меня слегка передернуло. Подхода ангуляра мне импонирует тем что это тот же хтмл.Единственный минус ангуляра — это медленная работа с большим количеством элементов. Но недавно пост пролетал с рендерингом на React. Такой спидфолбек норм, но пока не сталкивался.
+1
Я как-то вас не понимаю. Ведь это же в именно React HTML-ные литералы размазаны по JS-коду?
То, что я перечислил, исповедует как раз обратный подход, больше похожий на Angular — HTML с директивами.
return <div>Hello {this.props.name}</div>;
— первый же пример с оффсайта.То, что я перечислил, исповедует как раз обратный подход, больше похожий на Angular — HTML с директивами.
0
kendoui
-4
Какие ужасные слова вы используете: «бомбануло», «батхерт».
+18
Дата-байндинг и $scope — это одна фича ангуляра, а сервисы, абстракции и Dependency Injection — совсем другая, не связанная с первой.
+1
есть ли другие наработки в сфере js, которые дают двойной дата биндинг и аналог $scope из коробки, но не используют всю кучу абстракций, от которых автор получил батхерт?
Есть, Angular Light, — это как «выжимка» из angular.js, $scope + двойной дата биндинг + директивы. Без всяких сервисов и фабрик и т.п.
+1
Для $scope есть нативное Micrpdata API, через которое и двойной байндинг делается достаточно легко.
P.S. Может быть я покажу себя дилетантом, т.к. не использовал в работе Angular (смотрел демки, читал доки) и могу неправильно понимать $scope.
P.S. Может быть я покажу себя дилетантом, т.к. не использовал в работе Angular (смотрел демки, читал доки) и могу неправильно понимать $scope.
0
Это api который выпилен из chrome?
0
Дело как раз в том, что популяризации 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 не контрибучу, поэтому меня они не послушают.
Ну и из-за того, что Microdata API не правильно позиционируется, это можно понять просто почитав ветку в Google Group, в которой обсуждали выпиливание.
По мне, так это не правильно. Microdata API такая же часть WEB API, как и Clipboard API (наполовину бесполезный), Drag and Drop API (кроме дропа файлов бесполезный), Keyboard API (который пилят и переписывают уже более двух лет, а в Chrome как раз реализована самая старая спецификация — самая бесполезная, и её никто не выпиливает, хотя её использовать не возможно), File API (который проигрывает по скорости и потреблению памяти флешу).
В той ситуации, когда мы, по факту, имеем в современных браузерах полу-бесполезные недоработанные (редакторами спецификации) API, которые никто напрямую не использует (потому что неудобно), выпиливание Microdata API (которая привносила действительно что-то новое) это просто верх маразма. Но, я в Chromium не контрибучу, поэтому меня они не послушают.
+1
Автор перевода-то хоть согласен с автором текста?
По сути, там говорится, что для простых задач используется неоправданно сложный инструмент. Проблема вполне реальная, только вывод неправильный: не инструмент плохой, а люди, которые его используют не по назначению.
По сути, там говорится, что для простых задач используется неоправданно сложный инструмент. Проблема вполне реальная, только вывод неправильный: не инструмент плохой, а люди, которые его используют не по назначению.
+18
Я как раз приехал с конференции, где рассказывал о том, как мы разрабатываем фронтэнд к нашему внутреннему корпоративному софту на angularjs — и тут такой пост. Сложно пройти мимо.
Не знаю согласен ли я с автором — сам я на js без angular написал мало что. Теперь благодаря этому посту очень хочу попробовать что-то сделать с помощью просто react.js.
Не знаю согласен ли я с автором — сам я на js без angular написал мало что. Теперь благодаря этому посту очень хочу попробовать что-то сделать с помощью просто react.js.
+6
Андрей Попп на прошедшем во вторник MoscowJS классно рассказал про основные идеи, заложенные в React и его фишки.
+2
О, похоже, не я один такой.
+37
Этот пост не даёт моей мечте увянуть: увидеть пост — перевод англоязычного поста, по которому без плашечки нельзя понять, что это перевод.
+22
Спасибо большое, это лучшее что я мог бы услышать.
+11
Это была не похвала
+8
Да, я очень глупо протупил, и теперь даже комментарий удалить не могу.
+8
А я прочитал и получил такой смысл:
Если бы было «Ваш перевод не дает моей мечте сбыться» было бы другое дело.
Тут же говорится именно о том, что перевод пусть не идеальный, но хороший, и потому благодаря таким переводам как ваш мечта не увядает (хотя и не исполняется).
Если бы было «Ваш перевод не дает моей мечте сбыться» было бы другое дело.
Тут же говорится именно о том, что перевод пусть не идеальный, но хороший, и потому благодаря таким переводам как ваш мечта не увядает (хотя и не исполняется).
+7
Абсолютно нормальный перевод, не парьтесь! Да, по тексту видно, что это перевод, но по-моему это нормально — у них другой стиль работы с текстом, другие идиомы, и когда всё это заменяют нашими аналогами результат получается… ммм… странноватый, а когда всё это выхолащивают то, да, определить что это перевод становится почти невозможно, но текст от этого обычно много теряет.
+3
НЛО прилетело и опубликовало эту надпись здесь
Интересно, что вы это упомянули. Дело в том, что Роб уже увидел TDD и его уже немножко порвало.
+4
habrahabr.ru/post/172039/
Это его же пост о ТДД :)
P.S. да что ж такое, мало того, что с переводом поста опередили, так и тут… :)
Это его же пост о ТДД :)
P.S. да что ж такое, мало того, что с переводом поста опередили, так и тут… :)
+3
Много хейта, мало вдумчивости. Если бы автор поработал над приложением, где много сложной клиентской логики, и которое пытается следовать лучшим практикам современного программирования в плане тестируемости, использования IoC, и тому подобного, то он бы сам все понял. Хотя, возможно, и не понял бы, но от этого ангуляр не становится менее прекрасным.
Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых. Так жизнь будет сильно роще.
В ангуляре 2.0 сервисы вообще станут обычными классами ES6 с аннотациями, и проблема исчезнет вовсе.
Ну а в целом да, у ангуляра довольно крутая learning curve, и это скорее достоинство, чем недостаток, потому что позволяет быстро и точно отсеять тот табун js monkey coders, про которых сам же автор и упомянул в начале.
Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых. Так жизнь будет сильно роще.
В ангуляре 2.0 сервисы вообще станут обычными классами ES6 с аннотациями, и проблема исчезнет вовсе.
Ну а в целом да, у ангуляра довольно крутая learning curve, и это скорее достоинство, чем недостаток, потому что позволяет быстро и точно отсеять тот табун js monkey coders, про которых сам же автор и упомянул в начале.
+1
А вам не кажется, что сложность ангулара не очень то позитивно сказывается на его распространении? Нет, он, конечно в тренде, и пробудет там еще (долго?), но все же…
0
Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых.Это сложно.
Я вот по той причине, что есть некие сложности в работе с ключевым словом new, всем всегда рекомендую не использовать это слово перед конструкторами — а вместо того сами конструкторы сочинять таким образом, чтобы это были самовызывающиеся конструкторы Джона Резига.
+2
всем всегда рекомендую не использовать это слово перед конструкторами
И надо сказать — плохому учите. Мне всегда не нравилась эта практика защиты от мифического дурака.
Вообще эта тема может стать, если уже не стала, холиварной.
+2
Почему сразу дурака? Я считаю, что здесь «new» играет роль boilerplate code и не нужен.
Можно ведь и не быть дураком, но допустить опечатку, набирая «new» (особенно в быстром темпе), ну или просто жалеть о том времени, которое будет расходоваться на чтение ужé набранного «new» в этом месте.
Можно ведь и не быть дураком, но допустить опечатку, набирая «new» (особенно в быстром темпе), ну или просто жалеть о том времени, которое будет расходоваться на чтение ужé набранного «new» в этом месте.
-1
Но самое главное — это, конечно, устранить высокую цену той ошибки, при которой единственный забытый оператор «new» опоганивает всю глобальную область видимости итогами работы «this.чегоУгодно» в конструкторе, и итог работы конструктора бывает далёк от желаемого.
Не ходить по этакому минному полю — это мудро.
Не ходить по этакому минному полю — это мудро.
-1
Ваши доводы (как и доводы Резига) об опечатках и иже с ними я не считаю серьёзными и сколько либо имеющими почву для обсуждения. Если пишете в блокноте код — продолжайте в том же духе. Жалуйтесь на опечатки и т.д. и т.п, придумывайте оправдания и костыли для того, что бы не писать качественный код, а подпирать его костылями.
Всё сказанное выше также относится и к забытому new. Но — здесь есть один момент. Чтобы не было сомнений нужен new или не нужен, просто функции-конструкторы нужно начинать с заглавной буквы (это считается хорошей практикой).
Таким образом, моё мнение сводится к тому, чтобы повышать качество кода, а не подпирать костылями говно-код, а тем более способствовать его написанию с помощью вот таких вот практик, типа автоматизированных конструкторов.
Всё сказанное выше также относится и к забытому new. Но — здесь есть один момент. Чтобы не было сомнений нужен new или не нужен, просто функции-конструкторы нужно начинать с заглавной буквы (это считается хорошей практикой).
Таким образом, моё мнение сводится к тому, чтобы повышать качество кода, а не подпирать костылями говно-код, а тем более способствовать его написанию с помощью вот таких вот практик, типа автоматизированных конструкторов.
+7
Насчёт блокнота и т.д. на свой счёт пожалуйста не принимайте — это просто метафора.
0
Иногда мне импонирует подход Scala, где immutable-типы данных конструируются не с помощью new, а с помощью объекта-конструктора, который имеет такое же название как и имя типа конструируемого экземпляра. В этом случае есть возможность создавать объекты не одного типа, а производных этого типа, в зависимости от переданных параметров.
Что-то вроде этого
Т.е. есть возможность абстрагироваться от проверки конкретных значений параметров, когда это не требуется и просто вызывать конструктор Animal получая экземпляр нужного подтипа.
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 получая экземпляр нужного подтипа.
0
Забытый new? Jshint не даст забыть, там эта опция вроде как включена по умолчанию
+2
По мне так javascript вообще плохо подходит для написания приложений с более-менее серьезной логикой. Сужу с точки зрения разработчика системы документо-оборота (50 000 — 100 000 строчек javasript в качестве фронтенда).
Основная проблема — очень часто непонятно, что возвращают функции, какого типа объекты записаны в массив. В голове просто не умещается структура приложения и часто приходится скакать по коду, 'вспоминая' особенности реализации. В строго типизированном языке таких проблем значительно меньше.
Основная проблема — очень часто непонятно, что возвращают функции, какого типа объекты записаны в массив. В голове просто не умещается структура приложения и часто приходится скакать по коду, 'вспоминая' особенности реализации. В строго типизированном языке таких проблем значительно меньше.
+3
Согласен, и для решения этой проблемы уже существует три различных решения от противоборствующих лагерей — typescript от майкрософт, dart и closure compiler от гугла. И независимо от предпочтений, все три замечательно сочетаются с ангуляром.
+2
Кстати, по поводу 100 000 строк кода. История ангуляра началась с того, что Мишко Хевери практически на спор смог переписать фронтэнд Google Feedback, насчитывающий на тот момент 17 000 строк, так, что он уместился в 1500 строк, не потеряв в функциональности. Это к вопросу о сложных и простых вещах из комментария товарища SowingSadness ниже.
+4
А какой фреймворк взят за основу? У меня тоже сейчас проект со сложной фронтенд логикой.
Но у меня есть четкая структура приложения, (за основу взят marionette).
Функции который возвращают что-то неизвестное отсутствуют как класс, просто потому что есть четкие правила навязаные фреймворком.
Благодаря этому, новые программисты в проекте вникают в правила очень быстро и разбираться им уже приходится только с бизнесс-правилами а не «воевать с фреймворком».
Но у меня есть четкая структура приложения, (за основу взят marionette).
Функции который возвращают что-то неизвестное отсутствуют как класс, просто потому что есть четкие правила навязаные фреймворком.
Благодаря этому, новые программисты в проекте вникают в правила очень быстро и разбираться им уже приходится только с бизнесс-правилами а не «воевать с фреймворком».
+1
За графическую часть отвечает extjs. А так в основное время приходиться бороться с бизнес логикой, которая судя по техзаданию совершенно не логичная. Так же есть вкрапления lua кода служащего для отображается табличек 2-3 тысячи строчек(вполне типичные документы для системы документы). Ну и поддержка таких мелочей как загрузки выгрузка данных в excel на стороне клиента накладывает отпечаток.
P.S. Ко всему этому в добавок написан свой костыль для печати документа с учетом фильтров и формата страниц.
P.S. Ко всему этому в добавок написан свой костыль для печати документа с учетом фильтров и формата страниц.
0
Я устал уже слушать оправдания сложных(с высоким порогом вхождения) фреймворков, что они нужны для больших и сложных приложений, поэтому и сложные.
Тут большая логическая ошибка, из первого никогда не следует второе.
Как правило, время расставляет всё на свои места и потом эти сложные фреймворки получают «заслуженную» славу.
А судить тех, кто не желает сено перекидывать штыковой лопатой, я бы не стал.
Тут большая логическая ошибка, из первого никогда не следует второе.
Как правило, время расставляет всё на свои места и потом эти сложные фреймворки получают «заслуженную» славу.
А судить тех, кто не желает сено перекидывать штыковой лопатой, я бы не стал.
+4
Порог вхождения — это не блажь или злые козни разработчика фреймворка, желающего потешить свое самолюбие, а объективные требования к квалификации программиста. Ангуляр сложный ровно настолько, насколько это требуется. Я и до ангуляра писал приложения, используя примерно те же самые подходы, просто не настолько элегантно выполненные. Для меня ангуляр сделал работу проще, а не сложнее.
+4
| Порог вхождения — это не блажь или злые козни разработчика фреймворка, желающего потешить свое самолюбие, а объективные требования к квалификации программиста
Порог вхождения — … это требования…
Хорошо, вы мне сейчас определение в вашей интерпретации описали, а дальше то что? Вы ничего по поводу того, что этот фреймворк с высоким порогом вхождения является эффективным инструментом не сказали. Пока что лишь вижу минус в скорости обучения команды и вливания новичков.
Порог вхождения — … это требования…
Хорошо, вы мне сейчас определение в вашей интерпретации описали, а дальше то что? Вы ничего по поводу того, что этот фреймворк с высоким порогом вхождения является эффективным инструментом не сказали. Пока что лишь вижу минус в скорости обучения команды и вливания новичков.
+1
В качестве аргумента я привел то, что мои сложные приложения от использования ангуляра стали проще, и не только мои. Я считаю это важным фактором эффективности. И как тимлид с некоторым опытом, я лучше возьму в команду дорогого специалиста, умеющего с помощью ангуляра решить сложную задачу за 1500 строк, чем трех дешевых новичков, которые напишут 17 000 строк «простого» кода с тем же результатом.
+1
некие сложности в работе с ключевым словом new
А можно поподробней про это?
+1
Действительно существует проблема многослойных, зачастую не нужных абстракций. И в итоге код не становиться проще, а наоборот — усложняется.
И поэтому, использовать angular повсеместно, просто глупо. Для простых вещей — простые инструменты, для сложных — сложные.
Angular решает проблему ознакомления, когда новый человек приходит в команду и тратит меньше времени на знакомство с архитектурой.
Но, не для этого ли существуют паттерны проектирования?
И поэтому, использовать angular повсеместно, просто глупо. Для простых вещей — простые инструменты, для сложных — сложные.
Angular решает проблему ознакомления, когда новый человек приходит в команду и тратит меньше времени на знакомство с архитектурой.
Но, не для этого ли существуют паттерны проектирования?
0
НЛО прилетело и опубликовало эту надпись здесь
Сказочный перевод… И где ссылка на оригинал?
codeofrob.com/entries/you-have-ruined-javascript.html
codeofrob.com/entries/you-have-ruined-javascript.html
-12
Вы не понимаете, AngularJS — это спасение всех front-end разработчиков! Вот раньше ты верстал за 30К 10 лет назад, тебя взяли и выкинули, уволили, растоптали потому что верстать мог любой программист таблицами… Обидно! А сейчас? Перенес всю бизнес логику на клиент, намазал все это сверху через AngularJS, подкрепил тестами, сборщиком, пакетными зависимостями, покодил все это пол года посложнее и все — без тебя дальше никак! Ты звезда команды! Тебя ждут из отпуска с нетерпением! Все плюшки твои… Но мир рушится, когда приходит он… второй такой как ты, который понимает что такое grunt, bower, yoman, angularjs…
+22
В вашем текстеAngularJS можно заменить любым другим фреймворком (Backbone, Ember etc) и смысл не поменяется.
В чем конкретно спасения Angular?
В чем конкретно спасения Angular?
+4
По этому нужно написать «своё решение» по сложности на уровне Angular и т.д. И тогда точно не придёт второй как ты :)
+1
Хорошая реклама React.
Я сроду нигде не использовал React и даже не читал о нём, а вот теперь захотел прочесть.
Но гиперссылки-то на React тут и нету — поневоле пришлось в Гугле нагугливать, и нагуглил:
http://facebook.github.io/react/
Я сроду нигде не использовал React и даже не читал о нём, а вот теперь захотел прочесть.
Но гиперссылки-то на React тут и нету — поневоле пришлось в Гугле нагугливать, и нагуглил:
http://facebook.github.io/react/
+4
React это не фреймворк, а всего лишь View. Вместе с ангуляром кстате использовать можно http://davidchang.github.io/ngReact/
0
Философия у React очень понравилась мне, кстати. Т.к. MVC (или MVP) у меня всё же ассоциируется как с архитектурой всего приложения вместе с серверной частью.
Когда постепенно входило в моду MVC in MVC я становился всё более и более грустным, т.к. ничего не упрощалось, а лишь наоборот.
Пока что я не встречал ничего более простого и удобного чем React для того что бы синхронизировать состояние и DOM.
Когда постепенно входило в моду MVC in MVC я становился всё более и более грустным, т.к. ничего не упрощалось, а лишь наоборот.
Пока что я не встречал ничего более простого и удобного чем React для того что бы синхронизировать состояние и DOM.
+1
НЛО прилетело и опубликовало эту надпись здесь
После первого взгляда на доки и примеры, ощущение что это тот же Knockout.
На Knockout я писал и Ractive я вижу один весомый плюс — свойства ModelView избавлены от того что они должны быть функциями.
В React же главные фишки в том, что у него виртуальный DOM и классы React можно агрегировать друг с другом. А в Knockout, Angular и Ractive — нельзя
На Knockout я писал и Ractive я вижу один весомый плюс — свойства ModelView избавлены от того что они должны быть функциями.
В React же главные фишки в том, что у него виртуальный DOM и классы React можно агрегировать друг с другом. А в Knockout, Angular и Ractive — нельзя
0
НЛО прилетело и опубликовало эту надпись здесь
С автором согласен. То же самое я чувствовал когда писал проект на ExtJS (нынче Sencha). Такое чувство что к библиотеке явно приложился чей-то воспалённый от паттернов и прочих фабрик мозг. Допиливать под свои нужны эти компоненты было сущим адом. В результате решил забить на этот геморрой и ограничиться jquery c компонентами из jqueryUI. И тучи рассеялись и птицы запели. В конце концов часто(а у меня так всегда) бывает что не этот очкарик напротив с красными глазами, обложенный книгами по расово верному программированию вам платит деньги, а тот вечно торопящийся товарищ, обложенный обязательствами, обещаниями и контрактами, которому нужно чтобы всё было готово ещё вчера и чтобы всё работало.
И да, мне больше симпатизирует следующий подход: для простых вещей — простые инструменты, для сложных — тоже простые. :)
И да, мне больше симпатизирует следующий подход: для простых вещей — простые инструменты, для сложных — тоже простые. :)
+16
ExtJS не ныне сенча, а приобретен Sencha и существует в рамках их продуктовой линейки.
Принципиальная особенность ExtJS в том что он по большей части декларативен и configuration driven, разумеется, это усложняет разработку отдельно взятых компонентов, но обеспечивает конечную цель, важную для enterprise приложений — ты берешь одного-двух умных программистов, чтобы они заложили каркас, базовую интеграцию с бэком и недостающие компоненты. Вся сложность вытеснена в этот этап.
Потом берешь произвольное количество девочек/индусов, и они тебе клепают 100500 форм для, например, ведения внутреннего учета в sencha architect, вообще не вникая что такое front-end разработка, браузерное окружение и прочее.
Принципиальная особенность ExtJS в том что он по большей части декларативен и configuration driven, разумеется, это усложняет разработку отдельно взятых компонентов, но обеспечивает конечную цель, важную для enterprise приложений — ты берешь одного-двух умных программистов, чтобы они заложили каркас, базовую интеграцию с бэком и недостающие компоненты. Вся сложность вытеснена в этот этап.
Потом берешь произвольное количество девочек/индусов, и они тебе клепают 100500 форм для, например, ведения внутреннего учета в sencha architect, вообще не вникая что такое front-end разработка, браузерное окружение и прочее.
0
«Отличный код из маленьких модулей и автономных функций и виджетов» — это как раз про Angular. В гораздо большей степени, чем про jQuery. Вот когда вы делаете приложение, в котором маленькие модули и автономные виджеты приходится друг с другом увязывать, сервисы Angular как раз оказываются весьма уместны. А так можно простой виджет для сайта зафигачить на Angular гораздо проще и изящней, чем с jQuery. Без всяких сервисов.
+2
О, Д'артаньян
-1
Может, я что-то непопулярное скажу, но когда появилось понятие, что сложный фреймворк это что-то плохое? Да, ангуляр сложен, потому что он решает сложные задачи! Если вам нужно вывести хелло ворлд или заполнить одну форму, у вас в руках неверный инструмент.
А когда ваш проект разрастётся до соответствующих размеров, то у вас и сервисы появятся, и фабрики сервисов, а потом ещё провайдеры фабрик сервисов, только с той разницей, что напишете вы их сами, и на колене, и с соответственным качеством.
А когда ваш проект разрастётся до соответствующих размеров, то у вас и сервисы появятся, и фабрики сервисов, а потом ещё провайдеры фабрик сервисов, только с той разницей, что напишете вы их сами, и на колене, и с соответственным качеством.
+3
Просто ребята с большим бэкграундом по java, перенесли все эти фишки в js, вот и все. Там так решаются сложные задачи, через фабрики, паттерны и паттерны фабрик. Знаете как решать сложные задачи простым способом, создайте свой фреймворк. jQuery кстати решает 80% проблем на клиенте, при желании можно шаблоны прикрутить + require js для модульности или browserify и будет нормальная такая замена.
0
В этом треде не хватает вброса про Backbone.
0
Судя по комментариям — есть те кто согласен со статьей.
Это одна из причин почему появился Angular Light
Это одна из причин почему появился Angular Light
0
www.youtube.com/watch?v=TSAlj04_tkA
www.youtube.com/watch?v=cPXTozVjSHo
Очень хороший доклад про Java. Схожие проблемы, как мне показалось, затрагивается. Советую не только Java-программистам.
www.youtube.com/watch?v=cPXTozVjSHo
Очень хороший доклад про Java. Схожие проблемы, как мне показалось, затрагивается. Советую не только Java-программистам.
-1
Ну да, по началу было сложно разобраться в отличиях между фабрикой и провайдером. Но у меня и опыта в программировании не было и английский не знал. А вот почему автор, так и не понявший этих вещей, получал зарплату в большой компании… лучше бы он этот вопрос обсудил, а мы бы все посмеялись)
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Вы мне Javascript сломали