Там, вроде бы, не все так просто с обратной совместимостью, заявленной еще в далеком 2010. Это только пока версия 0.1.5, и нет гарантий что она не зачахнет еще на несколько лет как версия до этого.
В чем смысл минусовать, ведь вопрос по существу. Как можно построить конструктивный диалог если меньшинство не будет выражать свое мнение из за опасения быть заминусовоным?
Cobol, vbscript, etc тоже отличные инструменты, они прекрасно справляются со своими задачами зачем с них слазить.
Вопрос, скажите а как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта. Результат плачевен, мувен не справляется со своей прямой задачей, да и никогда с ней не справлялся.
Он устарел морально и физически, в нем еще куча неудобностей, таких как иерархия проектов или централизация.
Ну а как же, его много кто использует, только вот слезть с него не так то просто, история с коболом повторяется. Если вы в здравом уме и у вас есть выбор для нового проекта между gradle/sbt и maven, вы скорее всего выберете что то из первых двух(даже если они совместимы с репозиториями мувена), ван Зил наверное тоже.
Я с 2010 года слышу о революции в мувене о проекте полиглот, но никакой революции не было и быть не могло.
Вы не упомянули о варианте использования анти-капчи, это когда есть скрытое поле например с именем email и вы решаете что при использовании формы человеком это поле всегда будет пустым. Тупой бот конечно-же заполнить это поле и тогда вы сможете его определить. Успех тоже весьма сомнителем но такая методика существует.
Печально конечно, но с другой стороны что вы хотели от vb/winform IDE, которого за уши изо всех сил пытаются притянуть к Web. Однако надежда есть, это VS Code.
Если я не ошибаюсь, то по тестируемости веб приложений, подход AMD уступает CommonJS. AMD приходится тестировать в браузере или при помощи phantomjs тогда как CommonJS можно тестировать как обычные node.js модули.
Релиз манагер выглядит неплохо но это он только так выглядит. Пока у него под капотом лежит Xaml, как и в tfs, а это такой один сплошной огромный геморрой. Может RM 2015 тоже будет без Xaml кто знает.
Спасибо вам за статью. Должен с вами не согласится по поводу выбора coffeescript'а. С виду данный язык хорош но вот когда начинаешь использовать его на настоящих проектах тут и ползут непонятки, Поль там поставил пробел, Жак здесь забыл запятую и пошло поехало. Мне кажется с такими неясностями в дизайне кофий скриптовский на роль функционального языка ну никак не тянет, его можно попрововать притянуть или натянуть но из этого ничего путного не выйдет. Кстати вы не упомятули о FunScript и Scala.js которые не просто подмоножества но они являются настоящими закоренелыми функциональными языками транслируеммыми в js.
Вопрос, скажите а как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта. Результат плачевен, мувен не справляется со своей прямой задачей, да и никогда с ней не справлялся.
Он устарел морально и физически, в нем еще куча неудобностей, таких как иерархия проектов или централизация.
Я с 2010 года слышу о революции в мувене о проекте полиглот, но никакой революции не было и быть не могло.
Здесь позвольте заметить, задержка имеется не из за самого REST а из за того подхода с которым вы используете стэк HTTP.