Penerapan Async/Await di ClojureScript

 (clojurescript.org)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • ClojureScript 1.12.145 mengubah compiler agar menghasilkan fungsi yang diberi hint ^:async sebagai JavaScript async function
  • Kini dimungkinkan menulis fungsi ClojureScript yang menunggu nilai Promise dengan await, sehingga interoperabilitas dengan JavaScript meningkat
  • ^:async juga bisa digunakan dalam pengujian, dan hasil pemanggilan fungsi asinkron dapat diverifikasi dengan await
  • Dalam survei Clojure terbaru, dukungan async functions menempati porsi tertinggi di antara permintaan peningkatan ClojureScript terkait interoperabilitas JavaScript
  • Untuk kasus umum yang melibatkan API browser terbaru dan library populer, kebutuhan untuk menambahkan dependensi tambahan berkurang, dan daftar perubahan lengkap dapat dilihat pada entri 1.12.145 di changelog ClojureScript

Penggunaan ^:async dan await

  • ClojureScript 1.12.145 mengubah compiler agar menghasilkan fungsi yang diberi hint ^:async sebagai JavaScript async function
  • Dengan ClojureScript kini menargetkan ECMAScript 2016, area peningkatan interoperabilitas JavaScript dapat dipilih dengan lebih cermat
  • Kini dimungkinkan menulis fungsi ClojureScript yang menunggu nilai Promise menggunakan await 
    (refer-global :only '[Promise])

(defn ^:async foo [n]
  (let [x (await (Promise/resolve 10))
        y (let [y (await (Promise/resolve 20))]
            (inc y))
        ;; not async
        f (fn [] 20)]
    (+ n x y (f))))
  • ^:async juga dapat digunakan dalam pengujian, dan hasil pemanggilan fungsi asinkron bisa diverifikasi dengan await 
    (deftest ^:async defn-test
  (try
    (let [v (await (foo 10))]
      (is (= 61 v)))
    (let [v (await (apply foo [10]))]
      (is (= 61 v)))
    (catch :default _ (is false))))

Latar belakang dan daftar perubahan

  • Dalam survei Clojure terbaru, dukungan async functions menempati porsi tertinggi di antara permintaan peningkatan ClojureScript terkait interoperabilitas JavaScript
  • Peningkatan ini mengurangi kebutuhan untuk menambahkan dependensi tambahan dalam kasus umum yang melibatkan API browser terbaru dan library populer
  • Daftar lengkap perbaikan, perubahan, dan peningkatan dapat dilihat pada entri 1.12.145 di changelog ClojureScript
  • Michiel Borkent, anggota komunitas, berkontribusi pada ClojureScript 1.12.145

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Opini Hacker News

  • borkdude yang memposting thread ini, dan saya juga lihat namanya tercantum sebagai kontributor rilis kali ini
    Sejak lama, argumen yang menentang dukungan async/await pada dasarnya ada dua: perlu perubahan mendalam di seluruh kompiler CLJS, dan makro dari pustaka seperti Promesa sudah memberi kemudahan yang mirip
    Selain itu ada juga yang bilang cukup pakai core.async, atau bahwa bahasa yang berorientasi ekspresi kurang cocok dengan async/await, tapi itu lebih merupakan pendapat pribadi ketimbang argumen utama yang berulang di forum
    Di Clojurians Slack, borkdude pernah bilang dia tidak yakin penambahan dukungan ini mustahil dilakukan, dan tampaknya akhirnya dia benar-benar meluangkan waktu untuk mengimplementasikannya, jadi saya sangat berterima kasih

    • Borkdude sebelumnya lebih dulu mengimplementasikan async/await di Squint, implementasi alternatif ClojureScript buatannya, untuk menunjukkan bahwa ini memungkinkan, lalu tampaknya membawa pelajaran dari situ ke kompiler inti CLJS

  • Fakta menariknya, ClojureScript sudah mendukung paradigma asinkron lewat pustaka core.async jauh sebelum async/await masuk ke JavaScript itu sendiri
    Ini sama sekali bukan untuk meremehkan nilai rilis ini; maksudnya justru keren bahwa dengan hanya menambahkan satu pustaka ke dependensi, kita bisa memakai fitur bahasa baru yang bahkan belum ada di bahasa host. Clojure memang hebat

    • Memang begitu. Saya cukup banyak memakainya, hasilnya bagus, dan meski ada sedikit kekhasan, pada praktiknya kita sudah punya async/await selama lebih dari 10 tahun
      Sepertinya saya tahu ini setelah menonton presentasi David Nolen
      Setelah itu saya cenderung beralih ke pendekatan yang meminimalkan JavaScript di frontend, dan SSE itu indah karena sifatnya satu arah. Senang melihat belakangan ini banyak developer dari berbagai bahasa mulai tertarik pada SSE
      Presentasi terbaru David Nolen, “A ClojureScript Survival Kit”, juga bagus: https://youtu.be/BeE00vGC36E
      Sebesar apa pun rasa terima kasih kita kepada David “Swannodette” Nolen atas pekerjaannya sejak masa awal ClojureScript dan core.async, rasanya tetap belum cukup. Yang terutama mengejutkan dari presentasi ini adalah bahwa ia tampak benar-benar antusias pada arah yang meninggalkan ClojureScript dan lebih memilih Clojure murni di sisi server, server-sent events, dan hanya sedikit sekali JavaScript
      Demo sebenarnya mulai sekitar menit 26:30. Setelah menunjukkan penggunaan sumber daya webapp yang berjalan di klien, ia lalu memperlihatkan webapp yang sama dijalankan di server dan didorong ke klien secara satu arah lewat SSE; penggunaan sumber dayanya turun nyaris mendekati 0, cukup mengesankan
      Ini tentu tidak cocok untuk semua kasus, tetapi dengan pustaka manipulasi DOM yang sangat minimal, jadi lebih mudah menalar webapp dan statusnya. Dulu saya harus menjalankan REPL untuk Clojure dan REPL untuk ClojureScript sekaligus, serta menangani banyak lalu lintas dua arah dan status yang sulit direproduksi; sekarang jauh lebih cepat dan lebih mudah direproduksi
    • Benar, tetapi pada 2026 juga ada banyak alasan untuk menghindari core.async
      Hasil keluaran JavaScript jadi besar, tidak ada model error yang melekat, dan ketika ada masalah, kodenya diubah menjadi state machine yang sulit dibaca dan di-debug
      Selain itu, makro go tidak bisa mengubah kode di luar S-expression miliknya sendiri, sehingga mendorong fungsi menjadi terlalu besar
      Seperti kata seseorang dari Cognitect, “core.async adalah omong kosong yang indah”

  • Agak mengejutkan melihat Clojure/ClojureScript belakangan ini tiba-tiba lebih sering muncul di media sosial
    Saya memakainya untuk kerja selama beberapa tahun sekitar 2012, tapi seperti banyak orang lain, kemudian meninggalkan JVM dan pindah ke bahasa fungsional yang bertipe
    Apakah meningkatnya minat sekarang karena coding berbasis agen? Karena tidak ada pemeriksaan tipe dan lebih sedikit kesalahan sintaks atau kata kunci terlarang, jadi lebih cepat saat menelusuri kode? Apakah kebangkitan S-expression sedang datang?

    • Secara pribadi, saya pindah dari bahasa fungsional bertipe ke ClojureScript, lalu ke Clojure sekitar 10 tahun lalu
      Codebase Clojure yang serius yang saya kenal biasanya sangat berinvestasi pada test suite, jadi kalau kita cukup menambahkan teknik untuk mengajari AI memakai test suite seefektif mungkin, hasilnya bisa melaju cukup baik
      Ada juga rekan saya yang membiarkan agen berinteraksi dengan REPL, dan katanya itu lebih cepat karena tidak perlu membayar biaya awal tiap kali. Saya sendiri terlalu malas untuk sampai sejauh itu, tapi sekarang pun sudah cukup cepat
      Clojure punya sedikit sekali hal yang mengganggu. Selain false dan nil, semuanya bernilai benar; tidak ada tabel prioritas operator; bahasa intinya mendukung struktur data immutable dan persistent secara bawaan
      Semuanya adalah ekspresi, bukan struktur campuran operator dan ekspresi. map, reduce, filter sudah bawaan dan memang lazim dipakai di kode biasa
      Kode Clojure yang saya tulis 10 tahun lalu masih sangat mungkin tetap berjalan hari ini, dan ekosistem serta perancang bahasanya memperlakukan tindakan yang merusak kode lama seperti sesuatu yang tabu
      Dari semua bahasa yang pernah saya pakai, ini yang paling bebas untuk mengekspresikan ide dan paling sedikit bikin pusing. Flowstorm, yang pada dasarnya debugger mundur de facto, juga alat yang terasa seperti mimpi dalam pemrograman
      Ini bahasa yang sangat baik jika Anda ingin merasa puas. Sebaliknya, kebanyakan penggunanya menganggap itu hal biasa saja, jadi mereka tidak terlalu ribut membicarakannya
      Di antara programmer yang memakai Clojure secara komersial, banyak juga yang tidak terlalu bahagia karena belum benar-benar memahami bahasanya. Sering kali itu bukan pilihan mereka sendiri, atau mereka belum siap, dan menurut saya sebelum memakai Clojure, seseorang sebaiknya sudah mengalami sekitar 10 tahun berbagai hal yang tidak disukai dari bahasa lain
      Video-video Rich Hickey, pencipta Clojure, tentang perangkat lunak memang terkenal dan berpengaruh, tapi itu tidak berarti rekan kerja saya pernah menontonnya atau peduli padanya
    • Kenaikan minat belakangan ini tampaknya banyak dipengaruhi oleh rilis dokumenter Clojure: https://clojure.org/about/documentary
    • Fitur lain yang cocok dengan coding berbasis agen adalah pengembangan yang dipandu REPL. Secara teori bahasa lain juga bisa mendukung, tapi saya tidak tahu kenapa pendekatan ini tidak lebih luas dipakai di sana
    • Saya sudah mencoba coding berbasis agen dalam berbagai bahasa, dan bahasa bertipe jauh lebih cocok. Sistem tipe pada dasarnya mengoreksi banyak kesalahan hasil halusinasi agen, terutama saat refactoring besar
      Menangani codebase Python besar yang tidak bertipe bersama AI terasa berat. Untuk bagian yang tidak tercakup tes, mengecek apakah benar-benar tidak rusak itu terlalu membosankan
      Semakin kuat sistem tipenya, semakin baik. Selain itu, model AI dilatih dengan kode, jadi makin populer suatu bahasa, kemungkinan performanya juga makin baik. ClojureScript bagus, tapi bukan bahasa arus utama, jadi saya menduga performa AI di sana akan kalah dibanding JavaScript
      Pada akhirnya, jika memikirkan AI, lebih baik pilih bahasa bertipe, atau kalau pun dinamis, pilih yang punya type hint
    • Seingat saya dokumenternya baru dirilis atau diumumkan, jadi mungkin itu pengaruhnya

  • Ini benar-benar besar. Sejak Jank diumumkan, rasanya belum ada hal di ekosistem Clojure yang semenantikan ini

  • Saya berharap alternatif JavaScript di frontend bisa benar-benar mapan, bukan sekadar sesuatu yang terlalu niche
    Saya ingin mencoba sesuatu seperti ClojureScript, tetapi sulit membayangkan akan memakainya di mana selain proyek sampingan pribadi. Mungkin lebih mudah diadopsi jika organisasinya memang sudah memakai Clojure di backend

    • Saya penasaran apakah kekhawatirannya soal bahasa ini bukan arus utama sehingga rekan kerja tidak mengenalnya, atau khawatir bahasanya akan ditinggalkan atau ternyata buruk
      Saya memang belum memakainya di production, tapi saya sudah men-deploy beberapa side project dan beberapa hal untuk keluarga. Reagent, pembungkus React untuk ClojureScript, terus terang terasa lebih masuk akal daripada React itu sendiri
      HTML dibuat dengan Hiccup, dan komponen hanyalah fungsi di dalam DSL Hiccup itu, yang pada dasarnya juga berupa list, jadi hasilnya sangat rapi. Hal yang statis terlihat statis, hal yang dinamis terlihat jelas dinamis, dan rasanya jauh lebih sedikit sihir dibanding React biasa
      Yang terasa kurang enak adalah saat mencoba memakai komponen nonfungsional dari NPM. Tidak fatal, tapi kodenya jadi jelek. Bisa diperbaiki dengan wrapper, tetapi beberapa pustaka JS memang terasa sangat berantakan di cljs secara default
    • Tidak perlu takut, ini benar-benar bagus. Selama 10 tahun saya memakainya untuk mengompilasi aplikasi kompleks menjadi kode klien yang sangat dioptimalkan, dan saya tidak akan menyebutnya obscure
      Komunitasnya juga sangat ramah dan matang
    • Daripada cuma membayangkan, mulai saja dari hal kecil. Kalau tim Anda punya skrip bash, coba tulis ulang dengan Babashka
      Mulailah dari skrip pribadi dulu untuk membiasakan diri dan merasakan manfaatnya. Memang tidak selalu lebih baik untuk semua kasus, tetapi nantinya orang bisa datang meminta saran, jadi Anda sendiri perlu cukup yakin
      Saat memperkenalkan teknologi yang belum dikenal, strategi yang bagus adalah memilih sesuatu yang kurang penting, menulis ulang, lalu membiarkannya begitu saja. Jika bermasalah mudah dikembalikan, dan kalau orang mulai suka, tinggal diperluas sedikit demi sedikit
      Dulu saat diam-diam memasukkan F# ke organisasi .NET, saya juga memulainya dari tes yang tidak terlalu penting
    • Coba Gleam. Saya memakainya di production dan sangat puas
      https://blisswriter.app/
      https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and
    • Setelah membaca https://hypermedia.systems/, saya sampai pada kesimpulan bahwa frontend terbaik adalah tidak ada frontend sama sekali

  • Saya sudah lama tidak mengikuti cljs, tapi saya ingat dulu ia diperkenalkan kurang lebih sebagai “Clojure di atas JavaScript”. Setidaknya seingat saya Rich dulu menjelaskannya seperti itu
    Saya memahaminya sebagai niat untuk membuatnya sedekat mungkin dengan runtime lain
    Tetapi perubahan kali ini tampak seperti penambahan fitur yang hanya ada di cljs, dan await sendiri sudah merupakan keyword di clojure.core, jadi bahkan berbenturan dengan Clojure itu sendiri
    Saya jadi penasaran, apakah kedua implementasi ini memang makin lama makin bercabang, atau fitur ini memang cukup penting bagi pengguna sampai layak menerima perbedaan itu

  • Ini penting karena memungkinkan menangani interoperabilitas JavaScript tanpa menambahkan pustaka tambahan
    Ini fitur yang sudah lama kurang, jadi rilis kali ini terasa cukup menyenangkan

  • Rasanya lebih baik membungkus fungsi async/await dengan CSP. Clojure sebenarnya sudah punya pola yang lebih baik

    • Rilis kali ini adalah soal mengekspos fitur asli host language ke ClojureScript
      core.async tidak ke mana-mana, dan kalau async/await ternyata lebih cocok daripada implementasi berbasis Promise, bagian .cljs dari core.async juga bisa diperbarui
    • Itu tetap bisa dilakukan. Di dunia ClojureScript, ini sebenarnya sudah bisa selama bertahun-tahun, dan pada akhirnya semua itu hanyalah Promise
      Bahkan dengan hint fungsi baru ini masuk, saya rasa pendekatan itu tidak akan hilang
      https://clojurescript.org/guides/promise-interop#using-promi...

  • Saya tidak terlalu yakin bagaimana harus menyikapi ini. Salah satu inti dari core.async bukannya memang mendorong semua hal seperti ini ke channel?
    Saya tidak yakin memiliki keyword async ala JavaScript ini benar-benar sebuah peningkatan

    • Ini untuk memakai fitur JS tanpa membawa dependensi tambahan seperti core.async
      Tidak wajib dipakai, dan Anda tetap bisa memakai core.async. Ini juga merupakan fitur yang paling banyak diminta dalam survei ClojureScript terbaru