Я не понял, как ES6 должен сломать coffeescript. Все спецификации ecmascript обратно совместимы, и уже это гарантирует, что с кодом на coffeescript ничего не случится.
Ну а в целом странный пост. Язык завоевал популярность, по читаемости сгенерированного js-кода он один из лучших, там нечего расшифровывать. И как бы ни хотелось автору или кому-то еще, coffeescript есть и будет. Постить скомпилированный coffeescript — тоже не самая хорошая идея, т.к. не очень красиво будет, и уж тем более не очень понятно, т.к. наружу вылезет куча внутренних переменных.
По поводу «не заставляйте меня учить ваш язык». Возможно и стоило поучить, благо спецификация у языка миниатюрная, заодно стало бы понятно, почему другие программисты его использовать любят.
Хочу пройтись по последней категории — single page applications.
Начну с конца:
Безопасность — 0
Какая логика вынесена в клиент? Любое такое приложение, если оно правильно спроектировано, представляет собой всего лишь сложный фронтенд к данным, которые хранятся на сервере, и если разумно подойти в организации серверного апи (токены и пр.), то с безопасностью все будет с порядке. И я не вижу в посте подтверждений, что организация такого вида безопасности сильно сложнее, чем в других типах приложений.
Оффлайн 5. До сих пор не видно тучи полностью рабочих в офлайне приложений.
Тестируемость 3 Странный параметр. Код надо тестировать, там где его пишут. Javascript — не космический язык, там тесты такие же, как писались бы для других языков.
Linkability 1 — очень странный параметр. При использовании любого распространенного фреймворка (хотя бы backbone) добиться этого не просто, а очень просто.
Скорость разработки 2 — как вы меряли этот параметр? Субъективно? Сейчас уже очень много полновесных фреймворком для SPA, хотя бы тот же AngularJS, Ember.js, Backbone и т.д.
Поддерживаю, у них и апи богаче значительно, и логики больше.
Например, каждая из библиотечных функций может принимать на вход как значения, так и промисы, а в цепочке обработчиков каждая пользовательская функция может возвращать как значение, так и промис, и все это будет корректно обработано.
Еще, не совсем понял, зачем нужно именно синхронное апи? Подобные библиотеки как раз пишут для того, чтобы упростить работу с апи синхронным.
Пример с calculate в обычном виде можно записать так:
Я в свое недавно делал презентацию о внутреннем строении jQuery — dpetroff.ru/slides/jquery_extension/
Начиная со слайда 19. Я не касался манипуляций с DOM или разборкой html дерева, но разобрал все остальное — css. ajax, события
Про live события уже написали, не написали про пространства имен. Почему вы назвали этот код jQuery-плагином? Только потому, что он использует jQuery в работе? Лучше код модуля оформить в другом пространстве имен.
Еще лучше было бы хранить копию внутреннего состояния корзины в localStorage и при необходимости ее валидировать вместо того, чтобы поллить сервер. В этом случае данные будут замечательно синхронизироваться между вкладками.
Один из самых интересных моментов в этой задаче — общение между доменами, вы скинули на отдельную библиотеку, остальное достаточно просто, и задачу эту не раз уже решали в любом сервисе, который так или иначе держит у себя внешние приложения. См, например метод gadgets.window.adjustHeight в opensocial вообще и в apache shindig в частности. Интереснее было бы, если бы вы предложили архитектуру для предоставления API фреймам внутри сайта для общения с контейнером.
Про jossy jossy что-что сказать трудно, т.к. не вижу примеров, как его можно даже минимально использовать.
Про документацию для coffeescript аля jsDoc задача очень интересная.
Спонсировать планируете только web-ориентируемые проекты?
Я немного не понял, где писать идею, на осуществление которой буду передавать деньги. Или деньги передаем просто, а реализуются именно выигрывшие идеи. Еще совет ссылку на фейсбук дать здесь еще, а не только постом в жж.
Исходный код должен прилагаться, если вы распространяете свое ПО. Не знаю, распространяется ли это на случай, если модифицировання библиотека используется на одном конкретном сайте.
Да, поводу авторизации вопрос — не было желания сделать авторизацию типа oauth, которая бы проходила в новом окне? Тогда было бы четко видно, кому отдаешь реквизиты учетной записи.
В node.js, например npm install, и все наглядно
Ну а в целом странный пост. Язык завоевал популярность, по читаемости сгенерированного js-кода он один из лучших, там нечего расшифровывать. И как бы ни хотелось автору или кому-то еще, coffeescript есть и будет. Постить скомпилированный coffeescript — тоже не самая хорошая идея, т.к. не очень красиво будет, и уж тем более не очень понятно, т.к. наружу вылезет куча внутренних переменных.
По поводу «не заставляйте меня учить ваш язык». Возможно и стоило поучить, благо спецификация у языка миниатюрная, заодно стало бы понятно, почему другие программисты его использовать любят.
Хочу пройтись по последней категории — single page applications.
Начну с конца:
Безопасность — 0
Какая логика вынесена в клиент? Любое такое приложение, если оно правильно спроектировано, представляет собой всего лишь сложный фронтенд к данным, которые хранятся на сервере, и если разумно подойти в организации серверного апи (токены и пр.), то с безопасностью все будет с порядке. И я не вижу в посте подтверждений, что организация такого вида безопасности сильно сложнее, чем в других типах приложений.
Оффлайн 5. До сих пор не видно тучи полностью рабочих в офлайне приложений.
Тестируемость 3 Странный параметр. Код надо тестировать, там где его пишут. Javascript — не космический язык, там тесты такие же, как писались бы для других языков.
Linkability 1 — очень странный параметр. При использовании любого распространенного фреймворка (хотя бы backbone) добиться этого не просто, а очень просто.
Скорость разработки 2 — как вы меряли этот параметр? Субъективно? Сейчас уже очень много полновесных фреймворком для SPA, хотя бы тот же AngularJS, Ember.js, Backbone и т.д.
Например, каждая из библиотечных функций может принимать на вход как значения, так и промисы, а в цепочке обработчиков каждая пользовательская функция может возвращать как значение, так и промис, и все это будет корректно обработано.
Еще, не совсем понял, зачем нужно именно синхронное апи? Подобные библиотеки как раз пишут для того, чтобы упростить работу с апи синхронным.
Пример с calculate в обычном виде можно записать так:
console.log(0 + 5 + 10);
Я конечно могу ошибаться, но мо-моему так проще.
Начиная со слайда 19. Я не касался манипуляций с DOM или разборкой html дерева, но разобрал все остальное — css. ajax, события
Еще лучше было бы хранить копию внутреннего состояния корзины в localStorage и при необходимости ее валидировать вместо того, чтобы поллить сервер. В этом случае данные будут замечательно синхронизироваться между вкладками.
#= require joosy/core/modules/filters
Это просто комментарий, или есть препроцессор, который склеивает весь коффескрипт, как надо?
Про jossy jossy что-что сказать трудно, т.к. не вижу примеров, как его можно даже минимально использовать.
Про документацию для coffeescript аля jsDoc задача очень интересная.
Спонсировать планируете только web-ориентируемые проекты?