А не могли бы Вы чуть более подробно описать работу с операторами?
Первичный отбор более менее понятен. Интересно, как Вы дальше с ними работаете?
Как оцениваете работу? Только по положительным/отрицательным отзывам клиентов? Какой-то дополнительный контроль качества их работы есть?
Проводите ли какое-то обучение? Либо нацеливаете их на самостоятельную работу с базой знаний?
Операторы наполняют базу знаний? Или этим занимаются выделенные люди?
И для общего представления — у Вас сколько операторов?
Backbone: если посмотреть на тот же ToDoMVC, то получается интерфейс размазан на 3 части — общая схема интерфейса, пониже шаблоны двух частей интерфейса, в js — описание view и как это все собрать вместе. Имхо, у AngularJS — нагляднее, компактненько в одном месте. И кода меньше, особенно в js.
Ember.js: для шаблонизации там Handlebars, и вобщем-то от кастомных директив мы никуда не ушли: view, collection, contentBinding, itemClassBinding, classNameBindings. И кода JS больше. Он то, конечно, понятен. Но его много надо и написать и потом прочитать. А ведь наша работа заключается не в том, чтобы много писать и долго читать, а чтобы делать больше нового и полезного, правда?" ;-)
Извиняюсь за дубли, сначала думал, что Опера глючила, добавил коммент черех Хром, потом дошло, почему нифига теги не работают, подождал 5 минут, чтобы добавить ссылку на документацию и по запарке ткнул опубликовать на старый коммент в Опере :)
Ссылка на документацию: docs-next.angularjs.org/api/angular.module.ng.$compileProvider.directive
> В шаблонах очень много кастомных тегов
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
P.S. Надеюсь, blockquote только в предпросмотре не пашет.
В целом, если собрать вместе Knockout+ jQuery getJSON вместе с destructurring assignment из ES6/CoffeeScript + Jasmine/Mocha + Mockjax, то получим что-то типа AngularJS. Я правильно понял? Правда у AngularJS при этом будет цельная архитектура, философия, подходы к созданию приложения. С другой стороны — для кого-то это плюс, кому-то может чем-то мешать.
Кстати, синтаксис байдингов и атрибутов — это, похоже, действительно, очень субъективный момент, т.к. мне чище и проще AngularJS ;-) Ну и опять же, если смотреть ToDo из ToDoMVC, то, на мой взгляд, AngularJS лаконичнее, особенно в js.
У них цели разные. Jquery, грубо говоря, — для манипулиции с DOMом. И, если я не ошибаюсь, AngularJS его для манипуляций с DOMом и использует.
Если же Вам нужно писать одностраничные приложения, либо приложения с активно взаимодействующими друг с другом и с сервером элементами управления, то примерно для этого AngularJS и создавался.
Вкратце: он содержит возможности и Backbone, и Knockout + инструментарий для тестирования, но при этом имеет свою философию, которая может подойти не всем разработчикам и не всем приложениям.
Я не знаю, стоит ли. У них на главной примеры очень хорошо выложены.
Я надеялся этим переводом больше заинтересовать, а так — у них и документация хорошая и примеры.
«AngularJS is a Google project. Google is using it internally and Google has been funding it for 2 years already.» пруф
И у Igor Minar, и у Miško Hevery, и у Brad Green, и у Vojta Jína (наверное я не всех разработчиков перечислил) в профилях местом работы указан Google.
Disclaimer: я не считаю, что всем надо взять и начать юзать AngularJS. Каждый выбирает по себе.
Но, много кода в разметку Вы не намешаете, т.к. expression там весьма облегченные — никаких конструкций, управляющих потоком исполнения.
И, если Вам несложно, неплохо бы было увидеть альтернативы, которые Вы предлагаете. Т.к. всягие ng — это не просто привязки. Или я Вас просто неправильно понимаю.
А не могли бы Вы чуть более подробно описать работу с операторами?
Первичный отбор более менее понятен. Интересно, как Вы дальше с ними работаете?
Как оцениваете работу? Только по положительным/отрицательным отзывам клиентов? Какой-то дополнительный контроль качества их работы есть?
Проводите ли какое-то обучение? Либо нацеливаете их на самостоятельную работу с базой знаний?
Операторы наполняют базу знаний? Или этим занимаются выделенные люди?
И для общего представления — у Вас сколько операторов?
А Вы у себя тестируете интерфейс, разрабатываемый с помощью Knockout?
Backbone: если посмотреть на тот же ToDoMVC, то получается интерфейс размазан на 3 части — общая схема интерфейса, пониже шаблоны двух частей интерфейса, в js — описание view и как это все собрать вместе. Имхо, у AngularJS — нагляднее, компактненько в одном месте. И кода меньше, особенно в js.
Ember.js: для шаблонизации там Handlebars, и вобщем-то от кастомных директив мы никуда не ушли: view, collection, contentBinding, itemClassBinding, classNameBindings. И кода JS больше. Он то, конечно, понятен. Но его много надо и написать и потом прочитать. А ведь наша работа заключается не в том, чтобы много писать и долго читать, а чтобы делать больше нового и полезного, правда?" ;-)
Ссылка на документацию: docs-next.angularjs.org/api/angular.module.ng.$compileProvider.directive
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
> В шаблонах очень много кастомных тегов
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
P.S. Надеюсь, blockquote только в предпросмотре не пашет.
В целом, если собрать вместе Knockout+ jQuery getJSON вместе с destructurring assignment из ES6/CoffeeScript + Jasmine/Mocha + Mockjax, то получим что-то типа AngularJS. Я правильно понял? Правда у AngularJS при этом будет цельная архитектура, философия, подходы к созданию приложения. С другой стороны — для кого-то это плюс, кому-то может чем-то мешать.
Кстати, синтаксис байдингов и атрибутов — это, похоже, действительно, очень субъективный момент, т.к. мне чище и проще AngularJS ;-) Ну и опять же, если смотреть ToDo из ToDoMVC, то, на мой взгляд, AngularJS лаконичнее, особенно в js.
Если же Вам нужно писать одностраничные приложения, либо приложения с активно взаимодействующими друг с другом и с сервером элементами управления, то примерно для этого AngularJS и создавался.
Вот пара ссылок, где ключевые разработчики выссказываются по сходным вопросам:
Angular.js vs Backbone.js
angular seems like knockout + backbone?
Вкратце: он содержит возможности и Backbone, и Knockout + инструментарий для тестирования, но при этом имеет свою философию, которая может подойти не всем разработчикам и не всем приложениям.
Я надеялся этим переводом больше заинтересовать, а так — у них и документация хорошая и примеры.
Пример я попросил, в том числе потому что Вы в аргументации все время используете слово «привязка». ng* директивы — это не только привязки.
В целом, разработчики считают, что для описания интерфейса лучше подходит декларативный стиль, а для написания бизнес-логики — императивный.
Я вот подумал, что, наверное, не эту статью надо было перевести, а Overview из Developer Guide.
И у Igor Minar, и у Miško Hevery, и у Brad Green, и у Vojta Jína (наверное я не всех разработчиков перечислил) в профилях местом работы указан Google.
Но, много кода в разметку Вы не намешаете, т.к. expression там весьма облегченные — никаких конструкций, управляющих потоком исполнения.
И, если Вам несложно, неплохо бы было увидеть альтернативы, которые Вы предлагаете. Т.к. всягие ng — это не просто привязки. Или я Вас просто неправильно понимаю.