Apa pro dan kontra Coffeescript? [Tutup]

Tentu saja satu pro besar adalah jumlah gula sintaksis yang mengarah ke kode pendek dalam banyak kasus. Pada http://jashkenas.github.com/coffee-script/ ada contoh yang mengesankan. Di sisi lain saya ragu bahwa contoh-contoh ini mewakili kode aplikasi dunia nyata yang kompleks. Dalam kode saya misalnya, saya tidak pernah menambahkan fungsi ke objek telanjang melainkan ke prototipe mereka. Selain itu fitur prototipe disembunyikan dari pengguna, menyarankan OOP klasik daripada Javascript idiomatik.

Contoh pemahaman array akan terlihat dalam kode saya mungkin seperti ini:

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

Saya penulis buku yang akan datang tentang CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

Saya yakin bahwa CoffeeScript layak digunakan setelah sekitar seminggu bermain dengannya, meskipun bahasanya hanya beberapa bulan pada waktu itu dan memiliki banyak sisi yang lebih kasar daripada sekarang. Situs resmi melakukan pekerjaan yang baik untuk mendaftarkan (sebagian besar) fitur bahasa, jadi saya tidak akan mengulanginya di sini. Sebaliknya, saya hanya akan mengatakan bahwa kelebihan bahasa adalah:

1. Mendorong penggunaan pola JavaScript yang baik
2. Mencegah JavaScript anti-pola
3. Membuat kode JavaScript yang bagus menjadi lebih pendek dan mudah dibaca

Nomor 3 mendapat lebih banyak perhatian daripada dua yang pertama (bahkan dalam buku saya), tetapi semakin saya memikirkannya, semakin saya sadar bahwa saya tidak melakukan lompatan hanya untuk sintaks yang cantik; Saya melakukan lompatan karena bahasa tersebut mendorong saya ke arah JavaScript yang lebih baik dan lebih rawan kesalahan. Untuk memberikan beberapa contoh cepat:

• Karena variabel dicakup secara otomatis, Anda tidak dapat secara tidak sengaja menimpa global dengan menghilangkan var, membayangi variabel dengan nama yang sama (kecuali dengan argumen bernama), atau memiliki variabel dalam file yang berbeda yang berinteraksi (lihat https://stackoverflow.com/questions / 5211638 / pattern-for-coffeescript-modules / 5212449 ).
• Karena ->jauh lebih mudah untuk menulis daripada function(){}, lebih mudah untuk menggunakan panggilan balik. Lekukan semantik membuatnya jelas ketika callback bersarang. Dan =>membuatnya lebih mudah untuk diawetkan thissaat yang tepat.
• Karena unless xlebih mudah bagi penutur bahasa Inggris untuk menguraikan daripada if (!x), dan if x?lebih mudah daripada if (x != null), untuk memberikan hanya dua contoh, Anda dapat menghabiskan lebih sedikit siklus otak pada sintaksis logika dan lebih banyak pada logika itu sendiri.

Pustaka hebat seperti Underscore.js dapat menangani beberapa masalah ini, tetapi tidak semua.

Sekarang untuk yang kontra:

1. Kompilasi bisa jadi menyebalkan. Kesalahan sintaks yang melempar kompiler CoffeeScript sering kabur. Saya berharap ada kemajuan di jalur itu di masa depan. (Dalam pertahanan kompiler, sering menangkap hal-hal yang — jika Anda menulisnya dalam JavaScript — Anda tidak akan menemukan kesalahan sampai baris kode itu berjalan. Lebih baik menangkap bug itu lebih cepat daripada nanti.)
2. Terkait dengan itu, debugging bisa menjadi masalah. Belum ada cara untuk mencocokkan baris JS terkompilasi dengan CoffeeScript asli (meskipun orang-orang Firefox telah berjanji bahwa ini akan datang).
3. Ini cenderung berubah. Kode Anda dapat berjalan secara berbeda, atau tidak berjalan sama sekali, di bawah versi CoffeeScript mendatang. Tentu saja, ini adalah kasus di mana sebagian besar bahasa — pindah ke versi baru Ruby atau Python serupa — tetapi tidak demikian halnya dengan JavaScript, di mana Anda dapat dengan wajar berharap bahwa kode yang berjalan dengan baik di seluruh peramban utama hari ini akan berjalan dengan baik di seluruh penjuru browser selama web seperti yang kita tahu itu ada.
4. Itu tidak terkenal. JavaScript adalah lingua franca . CoffeeScript telah menjadi sangat populer dalam waktu singkat, tetapi sepertinya tidak akan pernah menikmati komunitas seluas JavaScript.

Jelas saya pikir pro lebih besar daripada kontra untuk saya secara pribadi, tetapi itu tidak akan menjadi kasus untuk setiap orang, tim, atau proyek. (Bahkan Jeremy Ashkenas menulis banyak JavaScript.) CoffeeScript paling baik dilihat sebagai pelengkap yang baik untuk JavaScript, bukan pengganti.

Kami memiliki basis kode JavaScript yang agak besar dan sekitar sebulan yang lalu kami memutuskan untuk mencoba CoffeeScript. Salah satu pengembang kami mulai dengan memigrasi salah satu modul kami dari JS ke CS menggunakan http://js2coffee.org/ . Alat ini agak berguna dan butuh sekitar dua atau tiga jam untuk port 1000-garis JavaScript. Beberapa pengamatan yang kami perhatikan pada saat itu:

1. Kode CoffeeScript yang dihasilkan cukup mudah dibaca.

2. Kami mengkompilasinya kembali ke JavaScript dan cukup mudah dinavigasi dan debug. Ketika kami porting modul itu pengembang lain dari tim kami menemukan bug di dalamnya. Kedua pengembang ini memperbaiki bug itu di kode JavaScript lama kami dan kode JavaScript baru yang keluar dari kompiler CS. Mereka bekerja secara mandiri dan butuh waktu yang kira-kira sama (15-20 menit).

3. Karena itu adalah port, kode yang dihasilkan tidak menggunakan fitur khusus Kopi yang sesuai atau diinginkan. Jika kita akan menulis dalam CoffeeScript dari awal kode akan lebih idiomatis. Karena itu kemudian kami memutuskan bahwa kami tidak akan mem-porting kode yang ada.

4. Secara umum keterbacaan fungsi yang lebih pendek dan objek yang lebih kecil meningkat hingga batas tertentu. Namun, untuk metode yang lebih lama itu tidak terjadi sama sekali. Penghematan terbesar berasal dari ->dan eksplisit return, tetapi selain itu kode kami tidak menjadi lebih pendek atau lebih sederhana. Beberapa sintaks sepertinya cukup membingungkan, terutama objek literal. CS menghilangkan kurung kurawal di sekitar definisi anggota dan dikombinasikan dengan "semuanya-adalah-ekspresi" dan tersirat returnyang membuat beberapa bit kode cukup sulit dibaca.

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

   Dan inilah yang akan terlihat seperti kode CoffeeScript:

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

   Seperti sekarang, cukup sulit untuk mengetahui bahwa pernyataan pengembalian dimulai pada (*)baris. Dalam proyek kami, kami sangat bergantung pada objek literal: kami meneruskannya sebagai parameter fungsi dan mengembalikannya dari fungsi lain. Dalam banyak kasus, objek-objek ini cenderung sangat kompleks: dengan anggota dari berbagai jenis dan beberapa tingkat sarang. Dalam kasus kami, perasaan keseluruhannya adalah bahwa kode CoffeeScript sebenarnya lebih sulit dibaca daripada kode JavaScript biasa.

5. Meskipun debugging CoffeeScript ternyata lebih mudah dari yang kami duga, pengalaman mengedit telah sedikit menurun. Kami tidak dapat menemukan editor / IDE yang bagus untuk bahasa ini. Kami belum menstandarkan editor / IDE untuk kode sisi klien untuk proyek kami dan bahkan kami semua menggunakan alat yang berbeda. Bahkan semua orang dalam tim setuju bahwa ketika mereka beralih ke CoffeeScript mereka mendapatkan dukungan yang agak buruk dari alat mereka. Plugin IDE dan editor berada dalam kondisi yang sangat awal dan dalam beberapa kasus mereka bahkan tidak dapat memberi kita sintaks yang tepat atau dukungan indentasi. Tidak berbicara tentang cuplikan kode atau refactoring. Kami menggunakan WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++, dan SublimeText2.

6. Berbicara tentang alat saya harus menyebutkan bahwa kompiler CoffeScript itu sendiri datang sebagai paket JS Node. Kami adalah utama toko Java / .NET sehingga semua orang mengembangkan pada kotak Windows. Sampai saat ini dukungan Windows hampir tidak ada di Node. Kami tidak dapat membuat kompiler CoffeeScript berjalan di Windows sehingga untuk saat ini kami memutuskan untuk tetap menggunakan <script type="text/coffeescript">tag dan kompiler on-the-fly berbasis browser.

   Kompilernya cukup cepat dan tidak banyak menambah waktu startup. Kelemahannya adalah bahwa JavaScript yang dihasilkan menjadi evaled dan agak sulit untuk menempatkan breakpoint di dalamnya di alat pengembang browser (terutama di IE8). Jika kita mengalami kesulitan dengan debugging, kita pra-kompilasi kode CoffeeScript dengan alat migrasi yang sama seperti yang saya sebutkan di atas tetapi itu masih sangat tidak nyaman.

7. Janji-janji lain dari CoffeeScript seperti varpenyisipan otomatis atau manajemen semi-transparan thisdengan operator panah gemuk ( =>) ternyata tidak memberikan keuntungan sebanyak yang kami harapkan. Kami sudah menggunakan JSLint sebagai bagian dari proses build kami dan kami menulis kode dalam ES3 x ES5-Strictsubset bahasa. Bagaimanapun, fakta bahwa Kopi menghasilkan jenis kode "bersih" yang sama adalah hal yang baik . Saya berharap setiap kerangka kerja sisi server menghasilkan markup HTML5 dan CSS3 yang valid juga!

   Yang mengatakan saya tidak akan mengatakan bahwa CoffeeScript menghemat banyak waktu dengan meletakkan varkata kunci untuk saya. Hilang varmudah ditangkap oleh JSLint dan mudah diperbaiki. Selain itu, begitu Anda dikoreksi olehnya untuk beberapa waktu Anda mulai menulis JavaScript yang baik pula secara otomatis. Jadi saya tidak akan mengatakan kopi adalah benar-benar yang membantu dalam hal ini.

Kami mengevaluasi CoffeeScript selama sekitar satu minggu. Semua anggota tim menuliskan kode di dalamnya dan kami saling berbagi pengalaman. Kami menulis beberapa kode baru dengan itu dan porting beberapa kode yang ada ketika kami melihatnya cocok. Perasaan kami tentang bahasa itu beragam.

Secara umum saya akan mengatakan bahwa itu tidak mempercepat perkembangan kami tetapi juga tidak memperlambat kami. Beberapa peningkatan kecepatan karena lebih sedikit pengetikan dan lebih sedikit permukaan kesalahan diimbangi oleh perlambatan di area lain, sebagian besar dukungan alat. Setelah satu minggu kami memutuskan bahwa kami tidak akan mengamanatkan penggunaan CoffeeScript tetapi kami juga tidak akan melarangnya . Diberi pilihan bebas, dalam praktiknya tidak ada yang menggunakannya, setidaknya untuk saat ini. Dari waktu ke waktu saya berpikir untuk membuat prototipe beberapa fitur baru di dalamnya dan kemudian mengonversi kode ke JavaScript sebelum diintegrasikan dengan proyek lainnya untuk mendapatkan permulaan yang lebih cepat tetapi saya belum mencoba pendekatan itu.

Pro

lihat jawaban Trevor Burnham .

ditambah, Anda dapat menganggap diri Anda sebagai pria yang hip, yang melakukan hal-hal yang trendi, bukannya mengacaukan kotoran javascript.

Cons

CoffeeScript tidak lebih dari gula sintaksis dan kacamata merah muda.

Untuk hal-hal yang mudah - CoffeeScript berlebihan, karena melakukan hal-hal yang mudah itu mudah dalam bahasa apa pun. Dan jQuery bahkan mungkin lebih sederhana daripada CoffeeScript.

Untuk hal-hal yang sulit - Anda harus memahami media Anda. Dan media Anda adalah HTML, DOM dan CSS, Javascript hanyalah alat untuk menghubungkan mereka, namun - semua API ditulis khusus untuk Javascript. Menggunakan bahasa lain, yang kemudian akan dikompilasi menjadi "nyata" - cukup berisiko, baik itu Java (GWT), Dart atau CoffeeScript.

Anti-pola atau ketidaktahuan dangkal aturan bahasa, dapat diperbaiki dengan membaca satu-dua buku bagus. Dan saya cukup yakin Coffeescript memiliki anti-polanya sendiri.

Dukungan IDE untuk Coffeescript bahkan lebih buruk daripada untuk JS.

Pro terbesar, dalam pikiran saya adalah:

Mengkompilasi coffescript langsung ke javascript yang seharusnya Anda tulis, tetapi tidak, karena itu tidak mudah.

Ada beberapa sudut buruk javascript yang hanya dihindari dengan kewaspadaan - contoh dari atas kepala saya:

• pengaturan prototipe dengan benar
• menggunakan === daripada ==
• memeriksa nol
• mendeklarasikan semua variabel dengan var
• membungkus semuanya dengan fungsi anonim yang dijalankan sendiri.

Jika Anda menulis naskah kopi, semua itu ditangani untuk Anda secara otomatis .

Kontra adalah, IMO, sebagian besar kecil:

• Debugging itu menyakitkan
• Ada lebih sedikit programmer kopi
• Anda harus menerjemahkan dokumentasi dari javascript ke coffeescript.

pro

1. CoffeeScript telah membantu saya belajar lebih banyak tentang JavaScript
2. cukup mudah dibaca, bahkan untuk panggilan balik bersarang yang rumit
3. memberikan keamanan di sekitar beberapa javascript sulit untuk melacak masalah bahasa

Contoh kerja Andrew di atas yang saya temukan mencerahkan. Saya percaya pembacaan objek yang ada secara literal akan ditingkatkan dengan secara manual mengidentifikasi pengembalian

kembali

// objek literal di sini

Alat IDE telah ditingkatkan, TextMate dan Cloud9 mendukung CoffeeScript. Harus diakui, dukungan windows masih lambat (bukankah itu benar untuk pengembangan web secara umum?)

kontra

CoffeeScript yang diinterpretasikan oleh peramban bisa jadi menantang untuk di-debug.

Ini adalah lapisan tambahan di atas JavaScript yang membutuhkan pemahaman dan pertimbangan dari pengembang.

pro

1. mereka benar-benar mengoptimalkan kasus umum secara sintaksis, pada kenyataannya, CoffeeScript adalah salah satu, jika bukan bahasa yang paling ringkas yang "biasa" digunakan http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- oleh-ekspresif /
2. menyembunyikan bagian buruk dari JavaScript (pemaksaan otomatis ==, global tersirat, sistem kelas yang lebih tradisional membuat hal-hal umum menjadi lebih mudah)
3. sangat mudah dipelajari untuk programmer Python / Ruby
4. fungsi anonim multi-baris + sintaks spasi putih

kontra

1. penghapusan var berarti Anda tidak dapat mengubah variabel lingkup luar dalam lingkup internal tanpa menggunakan objek, atau `var fall_back_to_js;` hacks [mengapa bukan pernyataan penugasan lain ': =' yang hanya menetapkan ulang nilai jadi obj.naem: = 5 kesalahan pengetikan lebih mudah]
2. Anda harus memberi tahu setiap alat tentang hal itu, kecuali jika Anda ingin men-debug JavaScript :(; btw: Anda dapat men-debug CoffeeScript dari Chrome dengan menambahkan dukungan untuk peta sumber; yeoman (npm install yeoman) dapat membantu Anda menulis file konfigurasi teguk atau mendengus untuk CoffeeScript
3. tidak ada pengetikan statis opsional (harus menunggu untuk standar EcmaScript berikutnya)
4. masih membutuhkan perpustakaan pihak ketiga untuk sistem modul
5. sintak jebakan yang harus diperhatikan: pengembalian implisit, abgo berarti a (b (g (o)))) , fp, b: 2, c: 8 berarti f (p, {b: 2, c: 8}) daripada f (p, {b: 2}, {c: 8})
6. tidak mengubah sistem nomor / jenis JavaScript yang rusak