> Jika kode TypeScript tidak lagi ditulis dengan TypeScript, tim tidak akan lagi menggunakan TypeScript secara langsung, yang dalam jangka panjang dapat memengaruhi pengalaman pengembangan.
Ada istilah dogfooding, yaitu menggunakan sendiri apa yang kita buat. Tetapi untuk bahasa pemrograman, rasanya ini memang sedikit mengundang pertimbangan.
Namun, untuk mengadopsi teknologi terbaru(?), JUnit4 cukup sering menjadi penghambat, jadi secara pribadi saya punya harapan kecil agar bisa bermigrasi ke JUnit5. https://docs.gradle.com/develocity/test-distribution/
Kalau memakai junit-vintage-engine, test JUnit4 bisa dijalankan di JUnit5 tanpa perubahan besar, tetapi overhead-nya cukup besar. (kurang lebih menjadi 20% lebih lambat)
Sebagai seseorang yang entah bagaimana akhirnya menetap sebagai build engineer aplikasi Android, kalau saya meninggalkan pendapat..
Build: gradle
Kalau proyeknya sangat besar atau kompleks pun, tetap harus pakai gradle... (tatapan jauh)
Untuk meningkatkan performa build gradle pada proyek yang sangat besar atau kompleks, proyek-proyek berikut sedang dikembangkan, jadi kalau Anda memakai gradle di proyek besar, sebaiknya siapkan migrasi dari jauh-jauh hari.
Secara pribadi, saya rasa tidak ada alasan untuk sengaja mengekspos layer arsitektur ke build system.
Untuk aplikasi yang saya kelola, saya membuat modul feature-api / feature-impl terekspos ke build system.
feature-app :
model data, atau interface yang terhubung dengan modul lain
feature-impl:
implementasi nyata dari feature tersebut
Kalau disusun seperti ini, perubahan kode di feature-impl tidak memengaruhi modul lain yang mereferensikan feature-api (isolasi dependensi), sehingga sangat membantu incremental build maupun peningkatan build cache hit rate.
Unit test - junit 4
Sepertinya keputusan Google berperan besar dalam hal ini.
Akhir-akhir ini layanan yang membatasi jumlah penggunaan atau waktu tampaknya kembali tren, tapi saya merasa jangan-jangan ini akan cepat bersinar lalu meredup seperti aplikasi yang sempat populer beberapa waktu lalu—saya tidak ingat persis namanya—yang rasanya mirip siaran sambil ngobrol itu.
Hmm.. sebagai selingan, dalam beberapa tahun terakhir terlihat fenomena aneh di mana sebagian besar startup memakai Flutter, sementara perusahaan besar seperti META dan OpenAI memilih native..
Kabar yang menggembirakan! Menariknya, bahasa TypeScript dari MS tampaknya benar-benar banyak mengambil pilihan yang tidak terduga, berbeda dari perkiraan. Dari sudut pandang MS, ini bisa dibilang hampir proyek open source pertamanya, dan tidak seperti Dart dari Google yang dulu ingin menggantikan JS, pilihan untuk melengkapi JS terasa sangat bijak. Kali ini pun, meski mereka punya banyak bahasa sendiri untuk dipakai dalam porting native ini, tetap mengejutkan bahwa mereka memilih Go dari Google.
Saya pernah mengalami saat menggunakan tipe generik yang disusun secara rekursif, performanya jadi lambat sehingga terpaksa memakai alternatif lain. Kalau memang 10 kali lebih cepat, saya berharap bagian seperti ini juga bisa membaik.
Sepertinya yang dimaksud itu runtime seperti Node, sedangkan yang dibicarakan di sini adalah compiler untuk bahasa TS itu sendiri.
> Jika kode TypeScript tidak lagi ditulis dengan TypeScript, tim tidak akan lagi menggunakan TypeScript secara langsung, yang dalam jangka panjang dapat memengaruhi pengalaman pengembangan.
Ada istilah dogfooding, yaitu menggunakan sendiri apa yang kita buat. Tetapi untuk bahasa pemrograman, rasanya ini memang sedikit mengundang pertimbangan.
Namun, untuk mengadopsi teknologi terbaru(?), JUnit4 cukup sering menjadi penghambat, jadi secara pribadi saya punya harapan kecil agar bisa bermigrasi ke JUnit5.
https://docs.gradle.com/develocity/test-distribution/
Kalau memakai
junit-vintage-engine, test JUnit4 bisa dijalankan di JUnit5 tanpa perubahan besar, tetapi overhead-nya cukup besar. (kurang lebih menjadi 20% lebih lambat)Sebagai seseorang yang entah bagaimana akhirnya menetap sebagai build engineer aplikasi Android, kalau saya meninggalkan pendapat..
Kalau proyeknya sangat besar atau kompleks pun, tetap harus pakai gradle... (tatapan jauh)
Untuk meningkatkan performa build gradle pada proyek yang sangat besar atau kompleks, proyek-proyek berikut sedang dikembangkan, jadi kalau Anda memakai gradle di proyek besar, sebaiknya siapkan migrasi dari jauh-jauh hari.
Secara pribadi, saya rasa tidak ada alasan untuk sengaja mengekspos layer arsitektur ke build system.
Untuk aplikasi yang saya kelola, saya membuat modul feature-api / feature-impl terekspos ke build system.
Kalau disusun seperti ini, perubahan kode di feature-impl tidak memengaruhi modul lain yang mereferensikan feature-api (isolasi dependensi), sehingga sangat membantu incremental build maupun peningkatan build cache hit rate.
Sepertinya keputusan Google berperan besar dalam hal ini.
Namun, screenshot testing plugin yang baru dirilis belakangan ini justru berbasis JUnit5.
Sepertinya seperti Clubhouse, saya juga langsung teringat itu.
Akhir-akhir ini layanan yang membatasi jumlah penggunaan atau waktu tampaknya kembali tren, tapi saya merasa jangan-jangan ini akan cepat bersinar lalu meredup seperti aplikasi yang sempat populer beberapa waktu lalu—saya tidak ingat persis namanya—yang rasanya mirip siaran sambil ngobrol itu.
Wah, ini sungguh sebuah kehormatan bagi keluarga.
Traffic kemungkinan akan sangat terkonsentrasi hanya pada jam tersebut, jadi pemrosesan yang efisien akan diperlukan.
Saya khawatir nantinya pengelolaan codebase TypeScript yang sudah ada akan terabaikan.
Pengembangan untuk bahasa C# memang tidak berhenti, tetapi terlalu sering terasa seperti framework yang menggunakan C# dibiarkan terbengkalai.
Saya sedang mencobanya, dan rasanya seperti paket lengkap.
Tulisan serupa terus berulang, tetapi keserakahan manusia tak ada habisnya dan kita mengulangi kesalahan yang sama.
Beban CPU komputer 100% bukanlah kondisi normal,
tetapi untuk beban kerja manusia, malah muncul kesimpulan bahwa kita harus bekerja lebih keras..
Hmm.. sebagai selingan, dalam beberapa tahun terakhir terlihat fenomena aneh di mana sebagian besar startup memakai Flutter, sementara perusahaan besar seperti META dan OpenAI memilih native..
Begitulah, tapi saya juga bisa memahami perasaan para developer .NET...
Kabar yang menggembirakan! Menariknya, bahasa TypeScript dari MS tampaknya benar-benar banyak mengambil pilihan yang tidak terduga, berbeda dari perkiraan. Dari sudut pandang MS, ini bisa dibilang hampir proyek open source pertamanya, dan tidak seperti Dart dari Google yang dulu ingin menggantikan JS, pilihan untuk melengkapi JS terasa sangat bijak. Kali ini pun, meski mereka punya banyak bahasa sendiri untuk dipakai dalam porting native ini, tetap mengejutkan bahwa mereka memilih Go dari Google.
Para pengembang .NET dan Rust tampaknya sangat marah.
Brother, pembaruan firmware paksa yang membuat kartrid tinta printer pihak ketiga tidak bisa digunakan
Lho, bukannya di kubu Deno sudah ada toolchain berbasis Rust yang dibuat... kenapa tiba-tiba Go?
Saya pernah mengalami saat menggunakan tipe generik yang disusun secara rekursif, performanya jadi lambat sehingga terpaksa memakai alternatif lain. Kalau memang 10 kali lebih cepat, saya berharap bagian seperti ini juga bisa membaik.
Thread diskusi tentang kenapa Go cukup menarik.
https://github.com/microsoft/typescript-go/discussions/411
Ada banyak hal yang perlu dipertimbangkan juga...