Jakie są zalety i wady Coffeescript? [Zamknięte]

Oczywiście jednym dużym pro jest ilość cukru syntaktycznego, co w wielu przypadkach prowadzi do skrócenia kodu. Na http://jashkenas.github.com/coffee-script/ są imponujące przykłady. Z drugiej strony mam wątpliwości, czy te przykłady reprezentują kod złożonych aplikacji w świecie rzeczywistym. Na przykład w moim kodzie nigdy nie dodam funkcji do nagich obiektów, a raczej do ich prototypów. Ponadto funkcja prototypu jest ukryta przed użytkownikiem, co sugeruje klasyczny OOP zamiast idiomatycznego Javascript.

Przykład zrozumienia tablic wyglądałby w moim kodzie prawdopodobnie tak:

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

Jestem autorem nadchodzącej książki na temat CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

Byłem przekonany, że warto korzystać z CoffeeScript po około tygodniu zabawy z nim, mimo że język miał wtedy zaledwie kilka miesięcy i miał znacznie więcej ostrych krawędzi niż teraz. Oficjalna strona świetnie spisuje (większość) funkcji języka, więc ich tu nie powtórzę. Powiem raczej, że zaletami tego języka są:

1. Zachęca do korzystania z dobrych wzorców JavaScript
2. Zniechęca anty-wzory JavaScript
3. Sprawia, że ​​nawet dobry kod JavaScript jest krótszy i bardziej czytelny

Trzecie miejsce zajmuje dużo więcej uwagi niż pierwsze dwa (nawet w mojej książce), ale im więcej o tym myślę, tym bardziej zdaję sobie sprawę, że nie wykonałem skoku tylko ze względu na ładną składnię; Skoczyłem, ponieważ język skłonił mnie do lepszego, mniej podatnego na błędy JavaScript. Aby podać kilka szybkich przykładów:

• Ponieważ zmienne mają zakres automatyczny, nie można przypadkowo zastąpić globalizacji przez pominięcie var, cień tej zmiennej o tej samej nazwie (oprócz nazwanych argumentów) lub mieć zmienne w różnych plikach, które wchodzą w interakcje (patrz https://stackoverflow.com/questions / 5211638 / pattern-for-coffeescript-modules / 5212449 ).
• Ponieważ ->jest to o wiele łatwiejsze do napisania niż function(){}, łatwiej jest używać wywołań zwrotnych. Wcięcie semantyczne wyraźnie określa zagnieżdżanie wywołań zwrotnych. I =>ułatwia zachowanie w thisrazie potrzeby.
• Ponieważ angielski unless xjest łatwiejszy do przeanalizowania niż if (!x)i if x?tylko if (x != null)do podania tylko dwóch przykładów, możesz poświęcić mniej cykli mózgowych na składnię logiczną, a więcej na samą logikę.

Świetna biblioteka, taka jak Underscore.js, może rozwiązać niektóre z tych problemów, ale nie wszystkie.

Teraz dla wad:

1. Kompilacja może być uciążliwa. Błędy składniowe generowane przez kompilator CoffeeScript są często niejasne. Spodziewam się, że w przyszłości na tym torze zrobi się postęp. (W obronie kompilatora często wychwytuje rzeczy, które - jeśli napisałeś je w JavaScript - nie odkryłbyś jako błędu, dopóki nie uruchomi się ten wiersz kodu. Lepiej złapać te błędy wcześniej niż później.)
2. W związku z tym debugowanie może być uciążliwe. Nie ma jeszcze sposobu na dopasowanie skompilowanych wierszy JS do oryginalnego CoffeeScript (choć ludzie Firefoksa obiecali, że to nastąpi).
3. Jest podatny na zmiany. Twój kod może działać inaczej lub wcale nie działać w przyszłej wersji CoffeeScript. Oczywiście dzieje się tak w przypadku większości języków - przejście na nową wersję Ruby lub Pythona jest podobne - ale nie jest tak w przypadku JavaScript, gdzie można zasadnie oczekiwać, że kod, który działa poprawnie w głównych przeglądarkach, będzie działał dobrze w głównych przeglądarkach przeglądarki tak długo, jak wiemy, że istnieje.
4. To nie jest tak dobrze znane. JavaScript to lingua franca . CoffeeScript stał się bardzo popularny w krótkim czasie, ale jest mało prawdopodobne, aby kiedykolwiek cieszył się tak ogromną społecznością jak JavaScript.

Oczywiście uważam, że zalety przewyższają wady dla mnie osobiście, ale nie będzie tak w przypadku każdej osoby, zespołu lub projektu. (Nawet Jeremy Ashkenas pisze dużo JavaScript.) CoffeeScript najlepiej postrzegać jako doskonałe uzupełnienie JavaScript, a nie zamiennik.

Mamy dość dużą bazę kodów JavaScript i około miesiąca temu postanowiliśmy wypróbować CoffeeScript. Jeden z naszych programistów rozpoczął migrację jednego z naszych modułów z JS do CS przy użyciu http://js2coffee.org/ . To narzędzie było raczej przydatne i zajęło około dwóch lub trzech godzin przeniesienie 1000-wierszowych wierszy JavaScript. Kilka spostrzeżeń, które zauważyliśmy w tym momencie:

1. Wynikowy kod CoffeeScript był dość czytelny.

2. Skompilowaliśmy go z powrotem do JavaScript i było dość łatwe w nawigacji i debugowaniu. Podczas przenoszenia tego modułu inny programista z naszego zespołu znalazł w nim błąd. Ci dwaj programiści naprawili ten błąd w naszym starym kodzie JavaScript i nowym kodzie JavaScript, który wyszedł z kompilatora CS. Pracowali niezależnie i zajęło im to tyle samo czasu (15-20 minut).

3. Ze względu na fakt, że był to port, wynikowy kod nie korzystał z funkcji specyficznych dla kawy, które były odpowiednie lub pożądane. Gdybyśmy pisali w CoffeeScript od zera, kod byłby bardziej idiomatyczny. Z tego powodu zdecydowaliśmy później, że nie przeniesiemy istniejącego kodu.

4. Ogólnie zwiększono do pewnego stopnia czytelność krótszej funkcji i mniejszego obiektu. Jednak w przypadku dłuższych metod wcale tak nie było. Największe oszczędności na wzdęciach pochodzą ->i są wyraźne return, ale poza tym nasz kod nie był znacznie krótszy ani prostszy. Niektóre elementy składni wydawały się dość mylące, zwłaszcza literały obiektowe. CS pomija nawiasy klamrowe wokół definicji elementów i łączy się z „wszystko-jest-wyrażeniem” i niejawnym, returnco sprawia, że ​​niektóre fragmenty kodu są dość trudne do odczytania.

   Oto 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
   }

   Oto, jak wyglądałby odpowiedni kod CoffeeScript:

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

   W tej chwili dość trudno jest stwierdzić, że instrukcja return zaczyna się od (*)wiersza. W naszym projekcie mocno polegamy na literałach obiektów: przekazujemy je jako parametry funkcji i zwracamy z innych funkcji. W wielu przypadkach obiekty te bywają dość złożone: z elementami różnych typów i kilkoma poziomami zagnieżdżenia. W naszym przypadku ogólne wrażenie było takie, że kod CoffeeScript był trudniejszy do odczytania niż zwykły kod JavaScript.

5. Chociaż debugowanie CoffeeScript okazało się łatwiejsze, niż się spodziewaliśmy, doświadczenie edycji znacznie się pogorszyło. Nie mogliśmy znaleźć dobrego edytora / IDE dla tego języka. Nie znormalizowaliśmy edytora / IDE dla kodu po stronie klienta dla naszego projektu i w rzeczywistości wszyscy używamy różnych narzędzi. W rzeczywistości wszyscy w zespole zgadzają się, że po przejściu na CoffeeScript otrzymują raczej słabe wsparcie ze strony swojego narzędzia. Wtyczki IDE i edytora są w bardzo wczesnej formie, a w niektórych przypadkach nie mogą nawet zapewnić właściwego podświetlania składni lub obsługi wcięć. Nie mówię o fragmentach kodu ani refaktoryzacji. Używamy WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ i SublimeText2.

6. Mówiąc o narzędziach, powinienem wspomnieć, że sam kompilator CoffeScript jest pakietem Node JS. Jesteśmy głównym sklepem Java / .NET, więc wszyscy rozwijają się na Windowsach. Do niedawna obsługa systemu Windows prawie nie istniała w węźle. Nie mogliśmy uruchomić kompilatora CoffeeScript w systemie Windows, więc na razie postanowiliśmy pozostać przy <script type="text/coffeescript">tagach i kompilatorze działającym w trybie przeglądarki.

   Kompilator jest dość szybki i nie wydłuża znacznie czasu uruchamiania. Minusem jest to, że powstały JavaScript jest evaledytowany i trochę trudno jest umieścić w nim punkty przerwania w narzędziach programistycznych przeglądarek (szczególnie w IE8). Jeśli mamy trudności z debugowaniem, kompilujemy kod CoffeeScript za pomocą tego samego narzędzia do migracji, które wymieniłem powyżej, ale nadal nie jest to zbyt wygodne.

7. Inne obietnice związane z CoffeeScript, takie jak automatyczne varwstawianie lub półprzezroczyste zarządzanie za thispomocą operatora fat arrow ( =>) okazały się nie dawać tak dużego zysku, jak się spodziewaliśmy. Już teraz używamy JSLint jako części naszego procesu kompilacji i piszemy kod w ES3 x ES5-Strictpodzbiorze języka. W każdym razie fakt, że Kawa wytwarza ten sam „czysty” kod, jest dobrą rzeczą . Chciałbym, aby każda platforma po stronie serwera produkowała również prawidłowe znaczniki HTML5 i CSS3!

   To powiedziawszy nie powiedziałbym, że CoffeeScript oszczędza dużo czasu, umieszczając vardla mnie słowa kluczowe. Brakujące elementy varsą łatwo wychwytywane przez JSLint i można je łatwo naprawić. Co więcej, po poprawieniu przez jakiś czas i tak zaczynasz pisać dobry JavaScript . Tak więc nie powiedziałbym Kawa jest naprawdę , że pomocne w tym względzie.

Ocenialiśmy CoffeeScript przez około tydzień. Wszyscy członkowie zespołu pisali w nim kod i dzieliliśmy się naszymi doświadczeniami. Napisaliśmy z nim nowy kod i przenieśliśmy istniejący kod, gdy uznaliśmy to za stosowne. Nasze odczucia dotyczące języka były mieszane.

Ogólnie powiedziałbym, że nie przyspieszyło to naszego rozwoju, ale też nas nie spowolniło. Niektóre przyrosty prędkości spowodowane mniejszym pisaniem i mniejszą powierzchnią błędu zostały zrównoważone przez spowolnienia w innych obszarach, głównie w obsłudze narzędzi. Po tygodniu zdecydowaliśmy, że nie będziemy wymagać używania CoffeeScript, ale nie zabraniamy go również . Biorąc pod uwagę wolny wybór, w praktyce nikt go nie używa, przynajmniej na razie. Od czasu do czasu myślę o prototypowaniu jakiejś nowej funkcji, a następnie przekonwertowaniu kodu na JavaScript przed integracją z resztą projektu, aby uzyskać szybszy start, ale jeszcze tego nie próbowałem.

Plusy

zobacz odpowiedź Trevora Burnhama .

a ponadto możesz myśleć o sobie jak o hip-hopie, który robi modne rzeczy, zamiast bawić się w brud javascript.

Cons

CoffeeScript to nic innego jak cukier składniowy i różowe szklanki.

Dla łatwych rzeczy - CoffeeScript jest zbędny, ponieważ wykonywanie łatwych rzeczy jest łatwe w dowolnym języku. A jQuery jest prawdopodobnie jeszcze prostszy niż CoffeeScript.

Trudne rzeczy - musisz zrozumieć swoje medium. A Twoim medium jest HTML, DOM i CSS, JavaScript jest jedynie narzędziem do ich łączenia, a jednak - wszystkie interfejsy API są napisane specjalnie dla Javascript. Używanie innego języka, który byłby następnie kompilowany do „prawdziwego” - jest dość ryzykowne, czy to Java (GWT), Dart czy CoffeeScript.

Anty-wzorce lub banalna nieznajomość reguł językowych można naprawić, czytając dwie dobre książki. I jestem całkiem pewien, że Coffeescript ma swoje własne anty-wzory.

Obsługa IDE dla Coffeescript jest jeszcze gorsza niż dla JS.

Moim zdaniem największym profesjonalistą jest:

Prosty coffescript kompiluje się w javascript, który powinieneś był napisać, ale nie zrobił tego, ponieważ nie był prosty.

Jest kilka nieprzyjemnych kątów javascript, których można uniknąć tylko dzięki czujności - przykłady z mojej głowy:

• prawidłowe ustawienie prototypu
• używając === zamiast ==
• sprawdzanie wartości null
• deklarowanie wszystkich zmiennych za pomocą var
• zawijanie wszystkiego w samo-wykonującą się funkcję anonimową.

Jeśli napiszesz coffeescript, wszystkie są obsługiwane automatycznie .

Wady, IMO, w większości niewielkie:

• Debugowanie jest uciążliwe
• Jest mniej programistów do parzenia kawy
• Musisz tłumaczyć dokumentację z javascript na coffeescript.

profesjonaliści

1. CoffeeScript pomógł mi dowiedzieć się więcej o JavaScript
2. jest dość łatwy do odczytania, nawet w przypadku złożonych zagnieżdżonych wywołań zwrotnych
3. zapewnia bezpieczeństwo wokół niektórych trudnych do wyśledzenia problemów językowych w javascript

Powyższy działający przykład Andrzeja I okazał się pouczający. Wierzę, że czytelność ich istniejących zwrotów literału obiektu zostałaby poprawiona poprzez prostą ręczną identyfikację zwrotu

powrót

// dosłowny obiekt tutaj

Narzędzia IDE zostały ulepszone, TextMate i Cloud9 obsługują CoffeeScript. Trzeba przyznać, że obsługa systemu Windows jest opóźniona (czy nie jest to prawda w przypadku tworzenia stron internetowych w ogóle?)

Cons

Interpretacja przeglądarki CoffeeScript może być trudna do debugowania.

Jest to dodatkowa warstwa na JavaScript, która wymaga pewnego zrozumienia i rozważenia ze strony programistów.

profesjonaliści

1. naprawdę zoptymalizowali typowe przypadki syntaktycznie, w rzeczywistości CoffeeScript jest jednym, jeśli nie najbardziej zwięzłym językiem, który jest „powszechnie” używany http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- wyrazistość /
2. ukrywa złe części JavaScript (auto-przymus ==, niejawne globały, bardziej tradycyjny system klasowy ułatwia wspólne rzeczy)
3. niezwykle łatwy do nauczenia się dla programistów Python / Ruby
4. wieloliniowe funkcje anonimowe + składnia białych znaków

Cons

1. usunięcie var oznacza, że ​​nie można zmienić zmiennej zakresu zewnętrznego w zakresie wewnętrznym bez użycia obiektu lub `var fall_back_to_js;` hacks [dlaczego nie inna instrukcja przypisania ': =', która tylko ponownie przypisuje wartość, więc obj.naem: = 5 literówek łatwiejszych do debugowania]
2. musisz poinformować o tym każde narzędzie, chyba że chcesz debugować JavaScript :(; btw: możesz debugować CoffeeScript z Chrome, dodając obsługę map źródłowych; yeoman (npm install yeoman) może pomóc Ci napisać plik konfiguracyjny łyka lub pomruku dla CoffeeScript
3. brak opcjonalnego pisania statycznego (trzeba czekać na następny standard EcmaScript)
4. nadal potrzebują bibliotek innych firm do systemu modułów
5. pułapki składniowe, na które należy uważać: niejawne zwroty, abgo oznacza a (b (g (o))) , fp, b: 2, c: 8 oznacza f (p, {b: 2, c: 8}) zamiast f (p, {b: 2}, {c: 8})
6. nie zmienia zepsutego systemu numerów / typów JavaScript