Decaffeinate

CoffeeScript in, JSNext out.

таргетом которого - ES6

Если что, ES7 (ECMAScipt2016) уже вышел, скоро будет ES8 (ECMAScipt2017).

И да, без поддержки синтаксиса async/await точно ненужно.

Твой проект? =)

Всем let, посоны

А нафик он посанам нужен? Может ты с педиками попутал?

кофескрипт как язык хуже джаваскрипта. Он дает небольшой сахарок, экономию на спичках, но в итоге порождает больше проблем.

Движок хорошо оптимизирует
Порой V8 так разгоняется, что false с true путает ;-)

А какие проблемы? Реально интересно посмотреть
Лично мне не хватает пока 4 вещей:
* Декораторы из TypeScript
Очень хорошо сокращает boilerplate код, если применять с Redux
* .catch для промисов
Приходится костылить: Promise.then(null, (err) -> new Error err)
где null - это fullfilled
Хвалала MDN, что рассказали про .then(fullfilledCb, catchCb)
* async/await
Есть вообще-то IcedCoffeeScript, уж вынести асинхронный кусок в .iced-файлы и собирать их не сложно, но как-то глупо так делать
* Нативная иммутабельность
Какой-нибудь бы сахар а-ля Rust
Жалко вот автор кофескрипта окончательно выгорел
Надеюсь, CoffeeScript6 таки начнет развиваться

.catch для промисов

их что в JS нет чтоли?

Декораторы из TypeScript

какая то клоунская туфта

Нативная иммутабельность

Зачем это нужно? Кстати, в JS уже несколько лет как можно запрешать изменения, причем несколькими способами, только вот кто этим пользуется, хз.

А проблемы там, основные, в том, что, насколько я понял, там дубовая ООП-модель, а-ля жаба. Очень многословно все в итоге получаться будет, и коряво

для обычных декораторов есть legacy плагины, или в тс нечто особенное?

кстати о let: у меня чаще почему-то const получается, а в repl это вообще не работает..

декораторы для babel: "plugins": ["transform-decorators-legacy"]

1. В JS то есть, а в Кофе ошибки дает, приходится вот так вот делать
2. Удобная штука
3. Object.method.method.method... Я про сахар, типа mut var = value
4. Ты про JS? Меня постоянно this писать раздражает
В кофе @ = this
Ну и еще в кофе толстая стрелка прокидывает this - удобно же
Да и в жава все очень даже понятно

Ну и еще в кофе толстая стрелка прокидывает this - удобно же

В JavaScript уже давно добавили “толстую стрелку” (arrow functions) с lexical this.

Кстати, не особо понятно, зачем они эту х*ню сделали, переменные в JS и так по дефолту лексические. Нужен лексический скоп — пиши замыкания.

Для этих ваших кофескриптов хотя бы автодополнение завезли уже?

Кстати, не особо понятно, зачем они эту х*ню сделали

В основном из-за этого.

Ну так там чушь собачья написана. Строго наоборот, arrow-functions не совместимы с объектно-ориентированным программированием.

TheClass = {
  foo: function(){console.log(this.a)},
  bar: () => {console.log(this.a)}
}

SubClass = Object.create(TheClass)

instanse = Object.create(SubClass)

instanse.a = 10
instanse.foo() // 10
instanse.bar() // undefined

Похоже, у анонiмуса новое имя и он начал дорогу к очередному бану.

Похоже, у анонiмуса новое имя

Тоже так подумал.

Atom все умеет

https://gist.github.com/yogurt1/58870a601ff783e4da1ed089b166f5be

А вот так на коффе что будет

TheClass = {
  bar: function(){console.log(this.a)},
}

SubClass = Object.create(TheClass)

instance = Object.create(SubClass)

instance.a = 10
instance.bar() // 10

TheClass.bar = function(){console.log(this.a + 1)}

instance.bar() // 11

То же что на JS?

Это ты фактически на JS написал, коффе тут не при чем

Это наследование:

var Class, SubClass, inst,
  extend = function(child, parent) { for (var key in parent) { if (hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; },
  hasProp = {}.hasOwnProperty;

Class = (function() {
  function Class() {}

  Class.prototype.bar = function() {
    return console.log(this.a);
  };

  return Class;

})();

SubClass = (function(superClass) {
  extend(SubClass, superClass);

  function SubClass() {
    return SubClass.__super__.constructor.apply(this, arguments);
  }

  return SubClass;

})(Class);

inst = new SubClass;
inst.a = 10;
inst.bar();

var SubClass, TheClass, instance;

TheClass = {
  bar: function() {
    return console.log(this.a);
  }
};

SubClass = Object.create(TheClass);
instance = Object.create(SubClass);
instance.a = 10;
instance.bar();
TheClass.bar = function() {
  return console.log(this.a + 1);
};
instance.bar();

Кофе - это сахар, не более
Так или иначе будет поведение как в ЖС
Просто таргет кофе - ES5, со страрыми классами
И эти классы не совместимы с классами ES6
Если я сделаю class CoffeeClass extends ES6Class, то будет ошибка
Если наоборот - то все норм
Кофе потому и появился, что писать myClass = function(){} и
myClass.prototype.method = function(){} утомляет

А такой сахарок как в кофе, чтоб раскрывал стрелки в функции, я и так тебе на коленке напишу за 5 минут, но будут постоянные прблемы с такими вот вещами

fu = function(expression){eval(expression)}
//versus
fu = function(expression){
  if(coffeSyntax(expression))  return eval(expand(expression))
  eval(expression)
}

и не просто, а тебе еще надо в этот код все транслировать если ты пишешь на препрооцессорном языке, дальшще в лес, больше дров, короче. Ради чего? Ради экономии на спичках? Слово function долго написать? Смешно.

В IDEA лучшая поддержка JS что я видел. У атома хромает пока поддержка расширений. Хотя сам я лично предпочитаю именно Atom.

child[key] = parent[key]

то что ты называешь наследованием, кстати, это не наследование в динамических языках, это миксин, это наследование только в смысле жаба-like. В динамическом ООП наследование реализуется только делегированием. И Алан Кей под наследованием не подразумевал сраное копирование, естественно, это потом появились дегенераты, которые стали называть это «наследованием»

Мля, после тысячи слов function -> и => просто рай
Я никогда не буду писать на чистом ЖС что-то сложнее document.body.innerHTML = «<h1>Hello, world</h1>»

Для кофе у атома все идеально
Да и для ЖС норм
Я вообще автокомплитом не пользуюсь, ну и параллельно у меня открыта документация по API

Это я знаю, просто привычка уже
Я вообще в ООП не шарю, скажу больше - терпеть его не могу
Если только на Java, где он реально хорошо сделан
Мне больше по душе прототипный подход JS, от которого я получаю лютое удовольствие)

Краткость кода достигается не синтаксическим сахаром, а выразительными возможностями языка и правильной архитектурой. В мужских языках эта экономия на спичках наоборот считается моветоном, никогда даже названия переменных не сокращается.

Мне больше по душе прототипный подход JS, от которого я получаю лютое удовольствие)

Вот как раз коффе и новые ES6-классы — это отход от прототипного ООП.

Кофе это скрывает, но все равно есть доступ к прототипам через :: (сахар для Object.prototype)

Если очень большой и сложный проект, то это нормально
А в своем маленьком куске говна я хочу поизвращаться
Когда встанет задача разработки масштабного проекта, то да, надо думать о организации проекта и т.д.

«Прототипный» и ООП это не противоположности. Javascript - он и ооп и прототипный :)

я тоже использовал кофе, тянул его в рабочие проекты, ты еще подрастешь, никогда не говори никогда, часто затраты на поддержку кода и проблемы с низкоквалифицированными сотрудниками перевешивают легкость, даже если это god-object-module на 10к строк, было дело..

а я вот с атома на вим пересел, жизнь есть и без автокомплита, зато думаешь больше

Atom хорош из-за подсветки кода, нескольких директорий в дереве, поиску по дереву и легкой расширяемости
Vim тоже крутой, но если попытаться сделать из него Atom, то получится какая-то дичь
Порой нужно в консоли быстро подправить файл, тут то вим и рулить
У меня для него плагины CoffeeScript и Sass, благодаря которым работает автоиндентация
Нет смысла сравнивать эти два редактора

Когда нужно написать простой скрипт, то лучше CoffeeScript ничего нету, а для сложных вещей лучше TypeScript

когда потом коллеги сделают несколько правок в откомпилированный js файл, растиражируют по десятку проектов, ну ты понял, а через год он вернется к тебе на доработку - так что все зависит, если комманда просто не знает коффе а работать надо сегодня

все редакторы хороши по-своему, это да

и коффе и айсед тоже пробовал, несмотря на кошмарный вывод, на свое время - лучшая альтернатива колбеков для серверсайда

На серверсайде проблем практически нету, хоть TypeScript, хоть Coffee, хоть Clojure - проблем особо нету, все будет работать хорошо
А для клиента обычно используется webpack, вывод которого редактировать моветон
Если нужны правки - новый бранч и там уже изменения, а собранное трогать нельзя

Я вообще бекендер и мне как бы всеравно на js. Но свой код я люлю писать с комфортом. Если тебе удобнее писать на VIM - вперёд. Я не привязан к чему-то конкретному и готов работать на чем угодно, что удовлетворяет моим предпочтениями.

часто фронтендом занимаются не шибко квалифицированные люди, что им наш вебпак

Есть люди, для которых норма php-файлы на тысячи строк с помесью HTML, JS и CSS
Но ведь из-за этого php не становится говном
php я не люблю из-за другого, но это отдельная история
суть в том, что коротенький скрипт лучше на кофе сделать, а если сложный фронтенд-проект, то TypeScript
P.S.: Я код для ноды собираю webpack-ом, что бы не тащить все исходники, которые могут состоять из сотен файлов

суть моего послания: поговорим через лет 5, я когда-то тоже заморачивался, а смысла нет

Суть моего послания: для простого говнокода рулит кофе, для серьезных проектов TypeScript
Писать на чистом JavaScript изврат