Насколько я понимаю, Mootools не считается предпочтительным способом написания JavaScript, потому что он имитирует обычный OO вместо языка OO на основе прототипов по умолчанию.
Откуда ты это взял? Самое замечательное в javascript - это то, что он так свободно напечатан (посмотрите, что я там делал) - вы можете написать то же самое в разных направлениях. Есть также так много способов абстрагировать и упаковать его - и это относится от простого new Array() против [] к тому, как вы структурируете свое приложение.
Если вы любите JavaScript (или просто знаете его и тайно ненавидите), вам будет хорошо с MooTools. API - это, в основном, нативная спецификация js или ES5 или - редко - дополнительная утилита, которая также кажется «естественной». Выделяется заметное исключение Class. И тот факт, что вы можете абстрагироваться от необходимости иметь дело с прототипным наследованием, передав объект в специальную функцию-конструктор Type, которая возвращает ваш экземпляр, ... о, подождите. Это выглядит по-другому, но то, что он делает, звучит как обычный javascript. Только проще - почему не вы предпочитаете это?
В наши дни многое делается в связи с бумом MVC на стороне клиента и этим «новым способом разработки приложений». Внезапно, люди jQuery получили роскошь водопроводной воды! Я говорил с многими разработчиками MooTools по этому поводу и (не) неожиданно обнаружил, что большинство думает, что MooTools редко нуждается в чем-либо подобном. Я склонен согласиться с ними. Единственная зияющая дыра - это контроллер представления с шаблонизацией, но есть немало решений.
Дело в том, что вы не можете напрямую сравнивать инфраструктуру MVC с MooTools, это не одно и то же. Совсем. Вы можете сравнить так называемые конструкторы моделей с классами.
Сейчас я потратил некоторое время на изучение различных решений и шаблонов MVC-фреймворков, чтобы посмотреть, можно ли превратить наше новое приложение в форму «наилучшей практики».
По сути, я попробовал backbone.js (с и без адаптера mootools) и нашел его неудобным для использования после MooTools - это было похоже на шаг назад. Когда я говорю использовать , я не имею в виду, что не могу его использовать, но это неудобно, если расширить и продолжить. Я уверен, что это просто опыт, но мне еще предстоит прочитать все примеры паттернов магистрали.
Типичная проблема, с которой я столкнулся - хотел иметь специальное свойство Model, которое говорит ему использовать localStorage для выборки / сохранения. Непонятно как - примеры показывают, что вы можете направить Backbone.sync к одному или другому, но не к обоим одновременно. Я должен был на самом деле украсить функцию и расширить ее, сохраняя исходную ссылку на случай, если модель не требует localStorage. НЕ лучший / самый очевидный шаблон для поддержания и оставляет меня зависимым от их изменений, не нарушая мой код.
В MooTools я бы просто расширил свой класс Model и мог бы определить собственное свойство Class Mutator (например, Binds или Implements). Готово. Пиши, что знаешь, мол, и не зря ...
Другая проблема - она тесно связана с данными, и вы не можете повторно использовать модели, такие как классы - например, модель User загружает пользователя и визуализирует через представление User Edit. Затем вы хотите создать нового клиента, и внезапно вы не можете повторно использовать старый объект, который легко и просто отображает то же представление, но с пустыми значениями. Я думаю, что это также будет связано с неопытностью с моей стороны или плохой архитектурой.
Ember.js Я нашел немного больше интерфейса в качестве интерфейса, хотя и не совсем щелкнул. Честно говоря, позвоночник был меньше проблем с настройкой.
Есть и другие попытки. Composer - один из них - еще раз для mootools, но он слишком старается, чтобы быть основой, и написан людьми, которые являются относительно новыми для фреймворка, поэтому я бы не назвал его зрелым. Нокаут и т. Д. Каждый день, буквально, появляется новый.
Гаррик Чунг выпустил фреймворк под названием Neuro , который обладает огромным потенциалом.
Я написал Epitome - полная реализация MVP, основанная на классах и событиях и заключенная в модули AMD, смело проверяйте ее. Он также поставляется с компоновщиком документации и многими мелочами, которые помогут вам начать работу.
SeanMonstar выпустил верфь, которая используется Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/. В то время как это не нативные mootools, это mootools-ish с классом mootools и т. Д. - только без расширения нативных, поэтому отличная альтернатива.
Кстати, попробуйте irc.freenode.net #mootools или список рассылки, и вы всегда получите хороший ответ.
Во всяком случае, достаточно на MVC. Пункты о MooTools были сделаны бесчисленное количество раз. Ненавистники будут ненавистниками. Те, кто любит это, не оглядываются назад. Если вы программист из ООП-фона или ищете что-то, что хорошо подходит для шаблонов, сделайте себе одолжение и придерживайтесь этого. Впереди захватывающие времена. Дорожная карта для 1.5: AMD, для 2.0 (иначе, Prime ). Прототипирование хост-объекта необязательно. Это были две самые большие проблемы в глазах критиков. Больше нет «грязных» прототипов, чтобы люди могли неправильно использовать циклы for ... in для необъектов и без проверок hasOwnProperty. Во всяком случае ...
Другие вещи, о которых нужно беспокоиться, могут иметь важное значение. Мол, размер «сообщества». Я думаю, что иметь здоровое сообщество - это здорово, но даже если вы посмотрите на jquery, количество реальных участников по сравнению с пользователями невелико. Соотношение качества CODE и хорошо выглядящих эффектов плохое. Плагины, которые вы можете использовать - многие из них написаны плохо, не работают и не поддерживаются. Когда вы рисуете линию, это гораздо менее эффектно, чем вы думаете!
Я не говорю, что у mootools или других фреймворков таких проблем нет. Справедливо будет сказать, что люди из MooTools, и особенно разработчики ядра, довольно приватны и менее откровенны в том, что они делают. Это может послать неправильные впечатления, я не знаю. Это конечно не jQuery.
В конечном итоге - если у вас есть ресурсы и ноу-хау, используйте то, что работает лучше всего, а что будет масштабироваться. Есть даже те, которые используют coffeescript и клянутся им. Кто я такой, чтобы судить ...
В интересах полного раскрытия информации - вам будет НАМНОГО сложнее найти достойного разработчика mootools при наборе персонала. Нельзя игнорировать ...