SWC berfokus pada pembuatan kode JavaScript yang kompatibel seperti Babel serta hingga proses bundling, sedangkan ini berfokus pada mengonversi kode TypeScript menjadi JavaScript atau memeriksa error.
Saat menulis kode yang sederhana tetapi sulit dihafal (seperti penanganan input/output file, mengelola container, dan sebagainya)
Saat muncul error kompilasi atau runtime, untuk mengetahui error apa itu dan kode mana yang menjadi penyebabnya
Saat ingin menulis ulang fungsi yang mirip dengan fungsi yang sudah ada, tetapi dengan fitur yang sedikit berbeda
Saat ingin mengganti kode yang bergantung pada library tertentu dengan library lain atau menggantinya dengan fungsi buatan sendiri
Saat perlu panduan tentang bagaimana sebaiknya mengembangkan sesuatu untuk mengimplementasikan fitur tertentu, atau saat harus bekerja di lingkungan tertentu
Dalam kasus-kasus seperti di atas, waktu yang dihemat cukup banyak. Dengan kombinasi Google + Stack Overflow pun sering kali tidak mudah ditemukan, dan khususnya di Stack Overflow, kalau ada satu jawaban biasanya selalu banyak sanggahan di komentar, atau ternyata itu cara implementasi versi lama sehingga tidak boleh dipakai lagi, dan hal-hal seperti itu sering kali sangat menjengkelkan...
Jika dibagi menjadi 1–2 minggu, tampaknya secara alami hanya orang-orang tertentu yang akan mengetahui gambaran tentang satu fitur. Seperti perbedaan antara proses dan thread. Produktivitas ditingkatkan dengan membatasi fokus.
Bahkan jika gambaran itu dibagikan, ini memang berangkat dari asumsi bahwa orang akan mempertanyakannya, tetapi tampaknya saya juga secara alami membuat asumsi bahwa saya tidak bisa mengikuti bagaimana gambaran besarnya dilacak sesuai arah yang sedikit demi sedikit berubah di setiap sprint planning.
Kalau dipecah menjadi task sekecil ini, pemimpin yang memegang gambaran besar jadi punya wewenang yang besar. Para engineer yang bekerja bersama justru kehilangan motivasi dan menjadi berpikir, "sebenarnya kita ini menuju ke mana?" Ini salah satu kelemahan paling khas dari agile berbasis sprint.
Tulisan ini rasanya terlalu ditulis hanya dari sudut pandang pemimpin, persis seperti judulnya.
Momentum engineer juga sangat dipengaruhi oleh ke arah mana pemimpin mengibarkan benderanya. Perlu dipikirkan lebih jauh juga tentang bagaimana cara menunjukkan nilai seperti apa yang ingin diberikan kepada pelanggan, serta apa output dan delivery outcome di setiap sprint. Tentu ini soft skill yang sulit, jadi memang jarang melihat pemimpin yang benar-benar melakukannya dengan baik, dan tulisan tentang ini juga tidak banyak.
Saya paham soal .NET, tapi menurut saya Rust posisinya sama seperti Go. Bagaimanapun juga, proyek dan library Go terkait JS yang sudah ada tampaknya ikut memengaruhi keputusan tersebut.
> 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)
Tidak ada pembahasan tentang performa bahasa Korea, tetapi setelah saya coba hasilnya tampak tidak buruk.
Kalau dilengkapi fitur untuk menghindari pencegahan macro, sepertinya akan jadi pemenang di pasar.
Sepertinya perdebatan soal ini cukup panas sampai Anders Hejlsberg sendiri meninggalkan komentar.
https://github.com/microsoft/typescript-go/…
Ya, benar, yang itu!
Saya termasuk orang yang berharap hasil kompilasi dari TypeScript bisa langsung keluar sebagai biner.
Terima kasih telah memperkenalkan materi yang bagus.
SWC berfokus pada pembuatan kode JavaScript yang kompatibel seperti Babel serta hingga proses bundling, sedangkan ini berfokus pada mengonversi kode TypeScript menjadi JavaScript atau memeriksa error.
Rasanya mirip dengan pengalaman saya.
Dalam kasus-kasus seperti di atas, waktu yang dihemat cukup banyak. Dengan kombinasi Google + Stack Overflow pun sering kali tidak mudah ditemukan, dan khususnya di Stack Overflow, kalau ada satu jawaban biasanya selalu banyak sanggahan di komentar, atau ternyata itu cara implementasi versi lama sehingga tidak boleh dipakai lagi, dan hal-hal seperti itu sering kali sangat menjengkelkan...
Jika dibagi menjadi 1–2 minggu, tampaknya secara alami hanya orang-orang tertentu yang akan mengetahui gambaran tentang satu fitur. Seperti perbedaan antara proses dan thread. Produktivitas ditingkatkan dengan membatasi fokus.
Bahkan jika gambaran itu dibagikan, ini memang berangkat dari asumsi bahwa orang akan mempertanyakannya, tetapi tampaknya saya juga secara alami membuat asumsi bahwa saya tidak bisa mengikuti bagaimana gambaran besarnya dilacak sesuai arah yang sedikit demi sedikit berubah di setiap sprint planning.
Bukankah kuncinya adalah membagikan gambaran besar, memastikan semua orang memahaminya, lalu memecah pekerjaan menjadi tugas-tugas kecil??
Terima kasih atas tulisannya yang bagus.
Kalau dipecah menjadi task sekecil ini, pemimpin yang memegang gambaran besar jadi punya wewenang yang besar. Para engineer yang bekerja bersama justru kehilangan motivasi dan menjadi berpikir, "sebenarnya kita ini menuju ke mana?" Ini salah satu kelemahan paling khas dari agile berbasis sprint.
Tulisan ini rasanya terlalu ditulis hanya dari sudut pandang pemimpin, persis seperti judulnya.
Momentum engineer juga sangat dipengaruhi oleh ke arah mana pemimpin mengibarkan benderanya. Perlu dipikirkan lebih jauh juga tentang bagaimana cara menunjukkan nilai seperti apa yang ingin diberikan kepada pelanggan, serta apa output dan delivery outcome di setiap sprint. Tentu ini soft skill yang sulit, jadi memang jarang melihat pemimpin yang benar-benar melakukannya dengan baik, dan tulisan tentang ini juga tidak banyak.
Saya kurang paham soal frontend.. apakah ini berbeda dengan swc?
Sekarang jam 8:40 pagi, dan pas saya lihat tanpa sengaja ternyata tepat menunjukkan 7:40:28 PM EST... menarik juga
Mengunjungi McDonald's sepertinya akan mudah. Ini tampaknya akan menjadi pengalaman yang menyenangkan.
Saya paham soal .NET, tapi menurut saya Rust posisinya sama seperti Go. Bagaimanapun juga, proyek dan library Go terkait JS yang sudah ada tampaknya ikut memengaruhi keputusan tersebut.
Ini benar-benar ide yang segar, tetapi seperti komentar lain saya juga penasaran bagaimana mereka akan mengatasi lonjakan trafik.
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)