Які плюси і мінуси Coffeescript? [зачинено]


48

Звичайно, одна велика ціна - це кількість синтаксичного цукру, що призводить до скорочення коду у багатьох випадках. На http://jashkenas.github.com/coffee-script/ є вражаючі приклади. З іншого боку, я сумніваюся, що ці приклади представляють код складних реальних програм. Наприклад, у своєму коді я ніколи не додаю функції до оголених об'єктів, а до їхніх прототипів. Крім того, функція прототипу прихована від користувача, що пропонує класичний OOP, а не ідіоматичний Javascript.

Приклад розуміння масиву виглядатиме в моєму коді, мабуть, так:

cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...

7
Це не розуміння масиву. Це JQuery.map ().
Рейн Генріхс

1
Звичайно, тому я не маю на увазі саме "розуміння масиву", а "приклад розуміння масиву [на веб-сайті]".
Філіп

Досить справедливо. Моє зауваження було, що foldl (карта) певним чином є виродженим випадком розуміння списку (який, як правило, є більш потужним).
Рейн Генріхс

Ну в основному я задаю це питання, бо мені цікаво, чи дурніше рішення використовувати Javascript, а не Coffeescript. Я погоджуюся, розуміння масиву набагато потужніше, з іншого боку, ніхто не заперечує, що Python є більш потужним, ніж Ruby через розуміння масиву та розмітки блоків відступом, а не початком / кінцем.
Філіп

Rails зробив сценарій кави дорогоцінним каменем. Це спровокувало "дискусію" github.com/rails/rails/commit/…
generalhenry

Відповіді:


53

Я автор майбутньої книги про CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

Я був переконаний, що CoffeeScript варто було використати приблизно через тиждень гри з ним, навіть незважаючи на те, що мові було лише кілька місяців у той час і було набагато більш грубих країв, ніж зараз. Офіційний сайт робить велику роботу з переліком (більшості) мовних особливостей, тому я не повторюю їх тут. Я скоріше скажу, що плюси мови:

  1. Заохочує використовувати хороші шаблони JavaScript
  2. Заперечує анти-шаблони JavaScript
  3. Робить навіть хороший код JavaScript коротшим і читабельнішим

№3 привертає набагато більше уваги, ніж перші два (навіть у моїй книзі), але чим більше я думаю про це, тим більше я усвідомлюю, що не зробив стрибок лише для симпатичного синтаксису; Я здійснив стрибок, оскільки мова підштовхнула мене до кращого, менш схильного JavaScript. Щоб навести кілька швидких прикладів:

  • Оскільки змінні проходять автоматичний діапазон, ви не можете випадково перезаписати глобали, опустивши var, затінюйте змінну з тим самим іменем (за винятком названих аргументів) або змінні в різних файлах, які взаємодіють (див. Https://stackoverflow.com/questions / 5211638 / шаблон-для-coffeescript-модулі / 5212449 ).
  • Оскільки писати ->набагато простіше, ніж писати function(){}, простіше використовувати зворотні дзвінки. Семантичне відступ дає зрозуміти, коли зворотні виклики вкладені. І =>полегшує збереження, thisколи це доречно.
  • Тому що unless xпростіше для носіїв англійської мови , щоб розібрати , ніж if (!x)та if x?простіше , ніж if (x != null), щоб дати тільки два приклади, ви можете витрачати менше циклів мозку на логічному синтаксисі і більше на самій логіки.

Велика бібліотека на зразок Underscore.js може піклуватися про деякі з цих проблем, але не всі.

Тепер про мінуси:

  1. Компіляція може бути болем. Помилки синтаксису, які кидає компілятор CoffeeScript, часто нечіткі. Я очікую прогресу на цьому шляху в майбутньому. (На захист компілятора він часто ловить речі, які - якби ви їх написали в JavaScript - ви не виявили б помилку, доки цей рядок коду не запустився. Краще пізніше вилучити ці помилки.)
  2. Крім того, налагодження може бути болем. Ще немає жодного способу зіставити складені рядки JS з оригінальним CoffeeScript (хоча люди Firefox пообіцяли, що це буде).
  3. Це схильне до змін. Ваш код може працювати інакше або взагалі не працювати в майбутній версії CoffeeScript. Звичайно, це стосується більшості мов - перехід на нову версію Ruby або Python схожий - але це не так з JavaScript, де ви можете обґрунтовано очікувати, що код, який працює добре в основних браузерах сьогодні, буде добре працювати на великих браузери стільки, скільки існує Інтернет, наскільки ми знаємо, що він існує.
  4. Це не так відомо. JavaScript - це lingua franca . CoffeeScript став дуже популярним за короткий проміжок часу, але навряд чи він коли-небудь сподобається такій спільноті, як JavaScript.

Очевидно, я думаю, що плюси переважають проти мене особисто, але це не стосується кожної людини, команди чи проекту. (Навіть Джеремі Ашкенас пише багато JavaScript.) CoffeeScript найкраще розглядати як прекрасне доповнення до JavaScript, а не заміну.


2
Вау Вау Вау, як в світі я не пропустити =>в документації? Це приголомшливо . (Інші пункти теж були гарні - дуже хороша неупереджена відповідь з чесним списком мінусів.)
Мішель Тіллі

Дякую за детальну відповідь. Хоча я трохи зачекаю, щоб прийняти це, було б цікаво мати плюси / мінуси, враховуючи різні підходи до ООП.
Філіп

2
Я б сказав, що модель класу CoffeeScript є більш доступною для новачків, ніж модель-прототип JavaScript і підтримує добрі практики (зокрема, визначення ваших прототипів в одному місці, а не розсіювання Foo.prototype.bar = ...ліній по всьому, що є безумством!). Це прекрасний спосіб чистої організації коду. З іншого боку, це може змусити людей використовувати OOP навіть тоді, коли функціональний підхід набагато елегантніший.
Тревор Бернхем

Деякі логіки відступу зовсім не так поводяться, як очікувалося, ви повинні подивитися на базовий JS, щоб побачити, що зроблено щось дивно. Це може бути частиною набору правил tbh, але це не завжди очевидно проти інших чутливих мов, таких як Py, і я виявив, що це може генерувати більш тонкі помилки, ніж ті, які призначені для запобігання. Я все ще використовую CoffeeScript
sa93,

1
Точки 1 і 2 потребують детальної інформації. Я думаю, що відповідь Ендрю дає хороший приклад №3 як змішаний мішок. Я не погоджуюся з кулями: забути вар - це нерозумно, і ти не повинен мати багато глобальних варіантів, щоб зіткнутися, в першу чергу, "функція" не є складною - попередньо визначені названі методи, тим більше, "якщо (! X ) "Короткий і солодкий і" якщо тільки "не робить його більш багатослівним (див. вашу попередню кулю і пункт № 3), а схожість людської мови - це насправді не мета дизайну, яка історично стикалася з великим успіхом у мовах програмування. Нам потрібно бути на зв’язку з людиною та машиною.
Ерік Реппен

30

У нас є кілька великих кодів JavaScript, і близько місяця тому ми вирішили спробувати CoffeeScript. Один з наших розробників почав з міграції одного з наших модулів з JS до CS за допомогою http://js2coffee.org/ . Цей інструмент був досить зручним, і знадобилося близько двох-трьох годин, щоб перенести 1000 рядків JavaScript. Деякі спостереження, які ми помітили в цей момент:

  1. Отриманий код CoffeeScript був досить читабельним.

  2. Ми склали його назад до JavaScript, і це було досить просто переміщатися та налагоджувати. Поки ми переносили цей модуль, інший розробник з нашої команди знайшов помилку в ньому. Ці два розробники виправили цю помилку в нашому старому коді JavaScript та в новому коді JavaScript, який вийшов із компілятора CS. Вони працювали самостійно, і це зайняло у них приблизно стільки ж часу (15-20 хвилин).

  3. Через те, що це був порт, отриманий код не використовував специфічні для кави функції, які були б відповідними або бажаними. Якби ми писали в CoffeeScript з нуля, код був би ідіоматичнішим. Через це пізніше ми вирішили, що не будемо переносити існуючий код.

  4. Загалом читабельність коротших функцій та менших об'єктів збільшилася до деякого розширення. Однак для довших методів це взагалі не було. Найбільша економія, що випливає, була ->явною return, але крім того, що наш код не став значно коротшим чи простішим. Деякі фрагменти синтаксису здавалися досить заплутаними, особливо об'єктні літерали. CS пропускає фігурні дужки навколо визначень членів і поєднується з "все-є-вираження" і неявно, returnщо зробило деякі біти коду досить важкими для читання.

    Ось JavaScript:

    var rabbitGenerator = {
        makeRabbit: function(rabbitName, growCarrots) {
            if (growCarrots) {
                carrots.growMore(10);
            } else {
                carrots.ensureSupply();
            }
            return {
                name: rabbitName, 
                height: 0,
                actions: {
                    jump: function (height) {
                        this.height += height;
                    },
                    eatCarrot: function () {
                        // etc
                    }
                }
            };
        },
        // more members
    }
    

    А ось як би виглядав відповідний код CoffeeScript:

    rabbitGenerator = 
      makeRabbit: (rabbitName, growCarrots) ->
        if growCarrots
          carrots.growMore 10
        else
          carrots.ensureSupply()
        name: rabbitName // (*)
        height: 0
        actions: 
          jump: (height) ->
            @height += height
    
          eatCarrot: ->
    

    Оскільки зараз досить складно зрозуміти, що заява про повернення починається в (*)черзі. У нашому проекті ми сильно покладаємось на об’єктні літерали: передаємо їх як параметри функцій та повертаємо їх з інших функцій. У багатьох випадках ці об'єкти, як правило, досить складні: з членами різного типу та кількома рівнями гніздування. У нашому випадку загальне відчуття полягало в тому, що код CoffeeScript насправді важче читати, ніж звичайний код JavaScript.

  5. Незважаючи на те, що налагодження CoffeeScript виявилося простішим, ніж ми очікували, досвід редагування дещо погіршився. Не вдалося знайти хорошого редактора / IDE для цієї мови. Ми не стандартизували редактор / IDE для кодового коду для нашого проекту, і фактично всі ми використовуємо різні інструменти. Насправді всі в команді погоджуються, що при переході на CoffeeScript вони отримують досить погану підтримку від свого інструменту. Плагіни IDE та редактора дуже ранні, і в деяких випадках вони навіть не можуть надати нам належного підкреслення синтаксису або відступу. Не кажучи про фрагменти коду чи рефакторинг. Ми використовуємо WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ та SublimeText2.

  6. Говорячи про інструменти, я повинен зазначити, що компілятор CoffeScript сам по собі виступає як пакет Node JS. Ми є первинним магазином Java / .NET, тому всі розвиваються у вікнах Windows. Донедавна підтримка Windows майже не існувала в Node. Ми не змогли зробити компілятор CoffeeScript під керуванням в Windows, тому на даний момент ми вирішили дотримуватися <script type="text/coffeescript">тегів та компілятора на основі браузера, який базується на льоту.

    Компілятор досить швидкий і не збільшує часу запуску. Недоліком є ​​те, що отриманий JavaScript стає evalредагуваним, і його важко поставити точки переривання в інструментах для розробників браузерів (особливо в IE8). Якщо нам важко працювати з налагодженням, ми попередньо компілюємо код CoffeeScript з тим же інструментом міграції, який я перераховував вище, але це все ще не дуже зручно.

  7. Інші обіцянки CoffeeScript, такі як автоматична varвставка або напівпрозоре управління за thisдопомогою оператора жирової стрілки ( =>), виявилися не так сильно, як ми сподівалися. Ми вже використовуємо JSLint як частину нашого процесу збирання і пишемо код на ES3 x ES5-Strictпідмножині мови. У всякому разі, те, що кава виробляє один і той же "чистий" код, - це добре . Я також бажаю, щоб усі рамки на сервері виробляли дійсну розмітку HTML5 та CSS3!

    Це означає, що я не скажу, що CoffeeScript економить багато часу, додаючи varдля мене ключові слова. JSLint, varщо відсутній , легко вловлює і легко виправляється. Більше того, як тільки ви будете виправлені ним деякий час, ви все одно автоматично починаєте писати хороший JavaScript . Таким чином , я б не сказав , Кава дійсно , що корисний в цьому відношенні.

Ми оцінювали CoffeeScript близько тижня. Усі члени команди писали в ній код, і ми ділилися досвідом один з одним. Ми написали з ним якийсь новий код і перенесли якийсь існуючий код, коли вважали за потрібне. Наші почуття щодо мови були неоднозначними.

Взагалі я б сказав, що це не прискорило наш розвиток, але й не сповільнило нас. Деякі прискорення швидкості через менше набору тексту та меншої кількості помилок компенсувались уповільненнями в інших областях, переважно підтримка інструментів. Через тиждень ми вирішили, що не будемо наказувати використання CoffeeScript, але і заборонити його не будемо . З урахуванням вільного вибору, на практиці його ніхто не використовує, принаймні поки що. Час від часу я замислююсь про те, щоб прототипувати якусь нову функцію в ньому, а потім перетворити код у JavaScript, перш ніж інтегруватися з рештою проекту, щоб швидше почати, але я ще не пробував такого підходу.


10

Плюси

переглянути відповідь Тревора Бернхема .

плюс, ви можете думати про себе як про хіп-хлопця, який займається модними штучками, замість того, щоб возитися з брудом javascript.

Мінуси

CoffeeScript - це не що інше, як синтаксичний цукор та рожеві келихи.

Для легких речей - CoffeeScript є надлишковим, оскільки робити будь-які речі легко будь-якою мовою. А jQuery, мабуть, навіть простіший, ніж CoffeeScript.

Що стосується важких речей - ви повинні зрозуміти своє середовище. А ваш носій - HTML, DOM і CSS, Javascript - це лише інструмент для їх з'єднання, але все - API створені спеціально для Javascript. Використовувати іншу мову, яку потім можна було б скласти до "справжньої" - досить ризиковано, будь то Java (GWT), Dart або CoffeeScript.

Анти-зразки або банальне незнання мовних правил можна виправити, прочитавши одну-дві хороші книги. І я впевнений, що у Coffeescript є свої анти-шаблони.

Підтримка IDE для Coffeescript навіть гірша, ніж для JS.



JavaScript - це набагато більше, ніж просто "інструмент для з'єднання їх" у великих масштабних, дуже динамічних веб-додатках. Обсяг JS в таких бібліотеках, як React або Angular, навіть jQuery, є конкретним випадком.
Енді

6

Найбільший профі, на мій погляд, це:

Прямий перелік кофескриптів збирається в JavaScript, який ви повинні були написати, але не став, тому що це було не просто.

Є кілька неприємних куточків JavaScript, яких уникати лише з пильністю - приклади вгорі голови:

  • встановлення прототипу правильно
  • використовуючи === замість ==
  • перевірка нуля
  • декларування всіх змінних за допомогою var
  • загортаючи все у самостійно виконуючу анонімну функцію.

Якщо ви пишете coffeescript, всі вони обробляються автоматично .

Мінуси, IMO, в основному незначні:

  • Налагодження - це біль
  • Програмістів для створення кофе є менше
  • Вам потрібно перекласти документацію з javascript у coffeescript.

3

плюси

  1. CoffeeScript допомогла мені дізнатися більше про JavaScript
  2. досить легко читати навіть для складних вкладених зворотних викликів
  3. забезпечує безпеку навколо деяких складних javascript у пошуку мовних проблем

Наведений вище робочий приклад Андрія I виявив просвітницький. Я вважаю, що читабельність існуючих об'єктних буквальних повернень буде покращена шляхом простого виявлення повернення вручну

повернення

// об'єкт буквально тут

Інструменти IDE були вдосконалені, TextMate та Cloud9 підтримують CoffeeScript. Справді, підтримка Windows відстає (хіба це не правда для веб-розробки взагалі?)

мінуси

Інтерпретований браузером CoffeeScript може бути складним завданням налагодження.

Це додатковий шар поверх JavaScript, який вимагає певного розуміння та розгляду з боку розробників.


0

плюси

  1. вони справді синтаксично оптимізували поширені випадки, насправді CoffeeScript є однією, якщо не найбільш стислою мовою, яка "зазвичай" використовується http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- по-експресивність /
  2. приховує погані частини JavaScript (автоматичний примус ==, неявні глобали, більш традиційна система класів полегшує звичайні речі)
  3. надзвичайно просто навчитися програмістам Python / Ruby
  4. багаторядкові анонімні функції + синтаксис пробілів

мінуси

  1. видалення var означає, що ви не можете змінити змінну зовнішньої області у внутрішньому діапазоні, не використовуючи об'єкт, або `var pad_back_to_js;` хакі [чому б не інше завдання присвоєння ': =', яке лише переназначає значення так obj.naem: = 5 помилок друку простіше]
  2. ви повинні повідомити про це кожен інструмент, якщо ви не хочете налагоджувати JavaScript :(; btw: ви можете налагоджувати CoffeeScript від Chrome, додаючи підтримку вихідних карт; yeoman (npm встановити yeoman) може допомогти вам написати конфігураційний файл із глоткою чи грунтом CoffeeScript
  3. немає необов'язкового статичного набору тексту (потрібно чекати наступного стандарту EcmaScript)
  4. ще потрібні сторонні бібліотеки для модульної системи
  5. синтаксичні пастки, на які слід бути обережними: неявна повернення, abgo означає a (b (g (o))) , fp, b: 2, c: 8 означає f (p, {b: 2, c: 8}), а не f (p, {b: 2}, {c: 8})
  6. не змінює зламану систему номерів / типів JavaScript
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.