Pada 2017-2019, ada peningkatan yang signifikan dalam TypeScript. Ini terjadi karena alasan yang jelas. Ada banyak hal baik dalam bahasa ini. Hampir setengah
dari 2018 responden survei
Negara JavaScript sudah mencoba TypeScript dan berencana untuk menulisnya di masa depan. TypeScript cukup populer, tetapi apakah itu layak digunakan dalam proyek perangkat lunak skala besar?
Dalam materi ini, upaya dilakukan agak ketat, berdasarkan indikator numerik dan pengalaman praktis penulis, untuk menganalisis efek menggunakan TypeScript dalam pengembangan proyek besar.
Tentang Pertumbuhan TypeScript
TypeScript adalah salah satu bahasa dengan pertumbuhan tercepat. Saat ini, ini adalah bahasa utama dari yang dikompilasi dalam JavaScript. Berikut adalah data TypeScript dari Google Trends.
2014-2019 Google Trends data tentang dinamika popularitas TypeScriptBerikut ini adalah
informasi dari GitHub yang mencerminkan minat programmer dalam bekerja mengembangkan berbagai bahasa pemrograman.
Data GitHub tentang pertumbuhan bahasa pemrograman dalam hal jumlah kontributorDi atas adalah indikator yang sangat mengesankan yang menunjukkan semakin populernya TypeScript, yang tidak boleh diremehkan. Tetapi perlu dicatat bahwa TS masih jauh dari diakui sebagai bahasa utama ekosistem JavaScript. Jika ekosistem JavaScript dibandingkan dengan lautan, maka TypeScript akan menjadi gelombang besar di lautan ini. Berikut ini adalah perbandingan JavaScript (garis merah) dan TypeScript (garis biru) menurut Google Trends.
Data dari Google Trends untuk 2014-2018 tentang dinamika popularitas JavaScript dan TypeScriptDan di sini adalah
informasi dari GitHub tentang bahasa pemrograman terkemuka yang digunakan untuk membuat repositori pada 2008-2018.
Data GitHub pada jumlah repositori yang dibuat menggunakan berbagai bahasa pemrogramanAnda dapat melihat bahwa, dengan jumlah repositori, TypeScript tidak termasuk dalam lima bahasa teratas.
Perlu dicatat bahwa pada 2018 ada titik balik dalam sejarah TypeScript, dan pada 2019 bahasa ini akan digunakan dalam banyak proyek nyata. Jika Anda adalah pengembang JavaScript, maka, dalam kondisi seperti itu, Anda tidak akan punya pilihan. Keputusan untuk menggunakan TypeScript dalam proyek yang harus Anda kerjakan sudah akan dibuat tanpa mempertimbangkan pendapat Anda. Anda tidak perlu takut untuk belajar dan menggunakan TypeScript.
Namun, jika Anda adalah orang yang memutuskan bahasa mana yang akan digunakan dalam suatu proyek, maka Anda perlu memiliki pemahaman yang realistis tentang kekuatan dan kelemahan TypeScript. Saat membuat keputusan, Anda perlu memahami apakah pilihan TypeScript akan memiliki efek baik atau buruk pada proyek.
Pengalaman saya menunjukkan bahwa TypeScript memiliki pro dan kontra, tetapi tidak dapat dikatakan bahwa penggunaannya, secara umum, memiliki dampak positif pada proyek. TypeScript menarik bagi banyak pengembang, dan banyak hal yang terhubung dengan bahasa ini yang saya, yang telah mengujinya dalam praktek, sangat menyukainya. Tetapi Anda harus membayar semuanya.
Latar belakang
Saya datang ke JavaScript dari dunia bahasa yang diketik secara statis - seperti C / C ++ dan Java. Awalnya sulit bagi saya untuk beradaptasi dengan pengetikan dinamis yang diadopsi dalam JavaScript, tetapi begitu saya terbiasa, saya merasa seperti orang yang mencapai pintu keluar terowongan gelap yang panjang dan melihat cahaya. Mengetik statis memiliki banyak fitur positif, tetapi hal yang sama dapat dikatakan tentang pengetikan dinamis.
Dalam beberapa tahun terakhir, saya secara berkala terjun langsung ke pengembangan TypeScript. Sebagai hasilnya, saya memperoleh lebih dari satu tahun latihan TypeScript. Saya memimpin beberapa tim besar menggunakan TypeScript sebagai bahasa utama mereka. Ini memungkinkan saya untuk mengevaluasi dampak dari TypeScript pada pengembangan proyek besar dan membandingkan proyek serupa dengan proyek serupa yang menggunakan JavaScript biasa.
Pada 2018, aplikasi yang terdesentralisasi bisa
lepas landas . Sebagian besar aplikasi ini menggunakan kontrak pintar dan solusi open source. Saat mengembangkan aplikasi untuk Internet yang bernilai, kesalahan dalam program dapat membuat pengguna kehilangan uang. Sekarang, lebih dari sebelumnya, penting untuk menulis kode yang andal. Karena proyek seperti itu biasanya open source, saya pikir apa yang kami gunakan dalam pengembangan TypeScript adalah baik, karena ini akan memudahkan tim TypeScript lain untuk bekerja dengan solusi kami, dan pada saat yang sama, ini memastikan kompatibilitas kode kami dengan proyek yang menggunakan JavaScript.
Selama penggunaan praktis dari TypeScript, saya mulai lebih memahami kelebihan dan kekurangan bahasa ini. Juga menjadi jelas bagi saya apa jenis pilihan yang bisa dimiliki TypeScript pada proyek perangkat lunak. Saya menyesal mengatakan bahwa pengalaman dengan TypeScript tidak sesukses yang saya inginkan. Jika TypeScript tidak meningkat secara signifikan, maka saya tidak akan memilih bahasa ini untuk proyek skala besar lainnya.
Kekuatan TypeScript
TypeScript, dalam jangka panjang, menurut saya masih merupakan perkembangan yang positif. Saya ingin menyukai bahasa ini, dan saya masih pasti menyukai beberapa fiturnya. Saya berharap bahwa pengembang TypeScript dan pendukungnya akan melihat kritik yang membangun dalam materi ini, dan bukan serangan yang tidak berdasar pada bahasa ini. Pengembang TypeScript dapat memperbaiki beberapa kekurangannya, dan jika itu terjadi, saya dapat mengulangi analisis saya tentang keefektifan bahasa ini dan menghasilkan hasil yang berbeda.
Mengetik statis bisa sangat berguna karena membantu mendokumentasikan fungsi, membuat kode lebih mudah dipahami, dan mengurangi kelebihan kognitif programmer. Sebagai contoh, saya biasanya menemukan sistem tipe Haskell untuk bekerja, tidak memerlukan terlalu banyak waktu dan usaha, nyaman, tidak mengganggu. Tetapi kadang-kadang bahkan sistem tipe Haskell yang fleksibel dan tipe yang lebih tinggi membuatnya sulit untuk bekerja. Misalnya, coba ketikkan transduser menggunakan Haskell atau TypeScript. Ini tidak mudah dilakukan, dan mungkin hasilnya akan sedikit lebih buruk daripada padanannya yang tidak diketik.
Saya suka fakta bahwa anotasi TypeScript, jika mereka mengganggu, bisa opsional. Saya suka fakta bahwa TypeScript menggunakan pengetikan struktural, dan bahwa ada beberapa dukungan untuk inferensi tipe (walaupun ada banyak peluang untuk perbaikan di area ini).
TypeScript mendukung antarmuka yang dapat digunakan kembali (sebagai lawan dari deklarasi tipe bawaan). Antarmuka dapat digunakan dengan berbagai cara untuk membubuhi keterangan API dan tanda tangan fungsi. Antarmuka tunggal dapat memiliki banyak implementasi. Antarmuka adalah salah satu fitur TypeScript terbaik dan saya ingin sesuatu yang mirip muncul di JavaScript biasa.
Salah satu kekuatan dari TypeScript adalah toolkit-nya. Misalnya, menggunakan editor yang sesuai (seperti Atom atau Visual Studio Code), yang untuk itu plug-in TS berkualitas tinggi dibuat, memberikan alat terbaik pada ekosistem JavaScript kepada pengembang. Pengembang plug-in lain harus mempelajari TS-plugins dan berpikir tentang bagaimana, menggunakan ide-ide yang terkandung di dalamnya, mereka dapat meningkatkan perkembangan mereka.
Analisis Kinerja TypeScript
Sekarang saya akan mengevaluasi TypeScript untuk beberapa indikator, menetapkan nilai mulai dari -10 hingga 10. Ini akan membantu Anda lebih memahami seberapa baik (atau buruk) dampak yang dapat ditimbulkan TypeScript pada proyek besar.
Jika skor pada indikator melebihi 0 - ini menunjukkan dampak positif dari TypeScript pada proyek. Jika skornya kurang dari 0, ini menunjukkan dampak negatif. Nilai peringkat 3-5 poin menunjukkan efek yang cukup kuat. 2 poin menunjukkan paparan rata-rata. 1 poin adalah efek yang relatif lemah.
Angka-angka yang akan terus saya operasikan sulit diukur secara akurat. Dalam penilaian saya, saya akan, sampai batas tertentu, subjektif. Tapi saya mencoba membuat perkiraan ini sehingga mereka se-realistis mungkin mengungkapkan pro dan kontra menggunakan TypeScript dalam proyek nyata.
Semua proyek yang saya analisis, memberikan nilai, berisi lebih dari 50 ribu baris kode. Mereka adalah hasil kerja beberapa programmer selama beberapa bulan. Salah satu proyek ini didasarkan pada Angular 2, menggunakan TypeScript. Itu dibandingkan dengan proyek serupa yang ditulis menggunakan Angular 1 dan JavaScript biasa. Semua proyek lain didasarkan pada Bereaksi dan Node menggunakan TypeScript. Mereka dibandingkan dengan proyek serupa yang menggunakan JavaScript biasa. Beberapa indikator, seperti kepadatan bug, diperkirakan hanya sekitar. Semua tim yang mengerjakan proyek terdiri dari pengembang TypeScript yang berpengalaman dan pemula. Semua anggota tim tersebut memiliki kesempatan untuk berinteraksi dengan mentor yang lebih berpengalaman yang membantu mereka beradaptasi di bidang pengembangan TypeScript.
Karena ukuran sampel yang kecil, data objektif yang saya miliki terlalu heterogen, ada terlalu banyak suara di dalamnya, oleh karena itu, berdasarkan pada mereka, tidak mungkin untuk membuat penilaian obyektif tertentu yang dapat dibuat berdasarkan angka yang cukup akurat dan tanpa risiko terlalu banyak mengambil risiko membuat kesalahan besar. Satu proyek JavaScript menunjukkan kepadatan kesalahan dalam produksi yang 41% lebih rendah dari proyek TypeScript yang sebanding. Dalam perbandingan lain, proyek TypeScript menunjukkan kepadatan kesalahan 4% lebih rendah daripada proyek JavaScript yang sebanding. Dalam kasus ini, jelas bahwa jumlah kesalahan yang mencapai tahap peluncuran produk jauh lebih terpengaruh bukan dengan menggunakan TypeScript dalam proyek, tetapi oleh ada atau tidak adanya langkah-langkah lain untuk memastikan kualitas kode. Ini mengubah indikator sedemikian rupa sehingga tidak mungkin untuk menggunakannya.
Berbagai indikator obyektif seperti itu mengarah pada fakta bahwa saya memutuskan untuk tidak menggunakannya, dengan fokus pada kecepatan pelaksanaan peluang proyek dan pada pengamatan yang menunjukkan area siklus hidup proyek di mana sebagian besar waktu dihabiskan. Di bawah ini, menganalisis indikator, kita akan membicarakan ini secara lebih rinci.
Karena analisis saya memiliki komponen subjektif yang kuat, Anda perlu mempertimbangkan kemungkinan ketidakakuratan dalam interpretasi indikator (ini tercermin dalam diagram). Tetapi kesimpulan umum dari analisis ini dapat memberikan gambaran realistis tentang apa yang dapat Anda harapkan dari menggunakan proyek TypeScript.
Analisis Kinerja TypeScriptSaya sudah bisa mendengar keberatan tentang peringkat rendah manfaat TypeScript, dan terus terang, saya tidak bisa sepenuhnya menolak keberatan ini. TypeScript, pada kenyataannya, memberi programmer beberapa fitur yang sangat berguna dan kuat. Tidak ada keraguan tentang ini.
Untuk memahami alasan peringkat positif yang relatif rendah dan langka dalam analisis saya, Anda harus memahami dengan baik apa yang saya bandingkan dengan TypeScript. Ini bukan "hanya JavaScript," tetapi JavaScript dan alat yang dirancang untuk pengembangan yang efektif dalam bahasa ini.
Pertimbangkan indikator yang ditunjukkan dalam diagram.
▍ Perangkat Pengembang
Toolkit adalah fitur TypeScript favorit saya, yang mungkin merupakan keuntungan praktis terkuat dari penggunaan bahasa ini. Berkat alat berkualitas tinggi, beban kognitif pada pengembang berkurang. Yang ada padanya adalah tip tentang jenis antarmuka, dalam proses, secara real time, kesalahan potensial tertangkap. Jika tidak ada yang seperti ini terjadi ketika mengembangkan JavaScript biasa menggunakan plugin yang baik, saya akan memberikan TypeScript peringkat positif yang lebih tinggi. Tetapi dalam kasus kami, 0 poin adalah sesuatu yang sudah dapat Anda gunakan saat memprogram dalam JavaScript, yaitu, yang kami gunakan untuk membandingkan TypeScript, itu sudah pada tingkat yang cukup tinggi.
Kebanyakan pendukung TypeScript tampaknya tidak memahami dengan baik apa yang bersaing dengan TypeScript. Intinya adalah bahwa pilihan alat bukanlah keputusan apakah akan menggunakan TypeScript atau JavaScript tanpa alat bantu apa pun. Ini tentang memilih antara TypeScript dan seluruh ekosistem alat pengembangan JavaScript yang kaya. Penyempurnaan kode dan alat deteksi kesalahan untuk JavaScript umum menyediakan 80-90% dari apa yang biasanya dianggap sebagai kekuatan TypeScript. Ini terjadi, misalnya, ketika menggunakan alat untuk
melengkapi kode, alat untuk
menghasilkan tipe, dan
linter . Saat menggunakan sistem inferensi tipe dan ketika menerapkan parameter fungsi default yang muncul di ES6, pengembang memiliki kiat yang sangat mirip dengan yang tersedia saat bekerja pada kode TypeScript dengan anotasi tipe.
Contoh pelengkapan otomatis kode JS biasa dengan inferensi tipeJujur, jika Anda menggunakan pengaturan default untuk memberikan petunjuk jenis, maka Anda benar-benar tidak perlu membubuhi keterangan kode TypeScript. Ini adalah teknik yang sangat baik untuk mengurangi jumlah konstruksi sintaks tambahan, yang merupakan salah satu kelemahan dari TypeScript.
Alat yang digunakan untuk menulis kode TypeScript mungkin sedikit lebih baik, mereka terlihat lebih holistik, tetapi semua ini tidak cukup untuk memberi TypeScript peringkat yang jauh lebih tinggi dan untuk menutupi kekurangan bahasa ini.
▍ Dokumentasi API
Manfaat utama lain dari TypeScript adalah dokumentasi API yang lebih baik. Bahkan, kita dapat mengatakan bahwa dokumentasi untuk API selalu sesuai dengan keadaan kode sumber. Dokumentasi bahkan dapat dihasilkan berdasarkan kode TypeScript. Untuk indikator TypeScript ini, seseorang juga dapat memberikan tanda yang lebih tinggi - jika, ketika memprogram dalam JavaScript, seseorang tidak dapat menggunakan sesuatu seperti
JSDoc ,
Tern.js dan banyak alat untuk menghasilkan dokumentasi. Secara pribadi, saya bukan penggemar JSDoc, jadi TypeScript dalam analisis saya pada indikator ini cukup dihargai.
Perlu dicatat bahwa, bahkan menggunakan dokumentasi terbaik yang dibangun ke dalam kode di dunia, seseorang tidak dapat melakukannya tanpa dokumentasi nyata, oleh karena itu wajar untuk mengatakan bahwa kemampuan TypeScript lebih mungkin untuk memperluas kemampuan kompilasi dokumentasi yang ada daripada menggantinya.
▍ Jenis Keamanan
Ketika membandingkan jenis keamanan TS dan JS, ternyata, tidak mungkin untuk mengungkapkan perbedaan khusus. Para pendukung TypeScript sering berbicara tentang manfaat dari keamanan tipe, tetapi tidak dapat dikatakan bahwa
keamanan tipe secara signifikan mengurangi kepadatan kesalahan dalam produksi. Ini adalah poin penting, karena penggunaan tinjauan kode dan TDD memiliki dampak serius pada pemecahan masalah (hanya menggunakan teknik
TDD mengurangi kesalahan sebesar 40-80%). Jika Anda menggabungkan TDD dengan analisis arsitektur proyek, dengan verifikasi spesifikasi dan dengan tinjauan kode, Anda dapat mencapai lebih dari 90% pengurangan dalam kepadatan kesalahan. Banyak dari teknik ini (khususnya TDD) dapat membantu Anda menemukan kesalahan yang sama yang dapat dideteksi dengan TypeScript, serta banyak kesalahan yang tidak dapat dideteksi TypeScript.
Di sini kami memberikan beberapa perhitungan dari
penelitian ini . Maksimum teoritis dari kesalahan "tersedia untuk umum" yang dapat dideteksi oleh TypeScript adalah sekitar 15%. Kesalahan "Publik" adalah kesalahan yang bertahan pada fase pengembangan proyek dan berakhir di repositori publik.
Studi tersebut memantau kesalahan yang diketahui sebelumnya. Ini termasuk mengetahui baris kode mana yang diubah untuk memperbaiki kesalahan, sementara masalah dan potensi solusinya diketahui sebelum kode tersebut diketik. Ini berarti bahwa bahkan pengetahuan tentang keberadaan kesalahan tidak memungkinkan, menggunakan TypeScript, untuk mendeteksi 85% dari kesalahan "publik".
Mengapa TypeScript tidak dapat mendeteksi begitu banyak kesalahan? Mengapa saya mengatakan bahwa 15% kesalahan yang terdeteksi adalah maksimum teoritis dari TypeScript? Untuk memulainya, perlu dicatat bahwa, sesuai dengan penelitian yang bersangkutan, kesalahan dalam spesifikasi menyebabkan sekitar 78% kesalahan dalam repositori GitHub publik. Ketidakmampuan untuk merumuskan dengan jelas spesifikasi program atau ketidakmampuan untuk mengimplementasikan spesifikasi dengan benar mengarah pada jenis kesalahan yang paling umum. Ini secara otomatis mengarah pada fakta bahwa sebagian besar kesalahan dalam proyek perangkat lunak TypeScript tidak dapat dideteksi atau dicegah. Para penulis penelitian, antara lain, mengidentifikasi dan mengklasifikasikan kesalahan yang tidak terdeteksi oleh TypeScript. Berikut adalah grafik batang dengan informasi tentang kesalahan tersebut.
Kesalahan yang tidak terdeteksi oleh TypeScriptContoh "StringError" adalah kesalahan yang terjadi jika string digunakan di mana string diperlukan, yaitu, kesalahan dalam jenis tidak terjadi, tetapi isi string ini sendiri menyebabkan kesalahan (misalnya, mungkin ada URL yang salah). Menggunakan analisis statis, Anda dapat mengidentifikasi beberapa kesalahan ini dengan memeriksa konten string dan menggunakan deskripsi konten ini. Tetapi ini hanya akan memberikan prospek untuk memperbaiki sebagian kecil dari persentase kesalahan yang kecil. Sebagai hasilnya, kami mengatakan bahwa tidak mungkin TypeScript dapat mendeteksi lebih dari 15-18% kesalahan.
Di sini mungkin terlihat bahwa 15% sudah cukup banyak. Mengapa TypeScript tidak dapat mendeteksi persentase kesalahan yang jauh lebih besar?
Karena ada banyak kesalahan yang tidak dapat dideteksi dengan cara mengetik statis, itu akan menjadi tidak bertanggung jawab untuk menolak menggunakan metode kontrol kualitas lain seperti tinjauan kode dan TDD. Oleh karena itu, tidak adil bergantung pada fakta bahwa TypeScript akan menjadi satu-satunya alat dari beberapa proyek yang digunakan untuk menangani kesalahan. Untuk melihat secara realistis indikator yang dipertimbangkan dari analisis kami tentang efektivitas TypeScript, perlu menghitung potensi jumlah kesalahan yang terdeteksi oleh TypeScript, setelah kesalahan yang terdeteksi oleh metode lain dikecualikan dari jumlahnya.
Misalkan proyek Anda akan mengandung 1000 kesalahan jika Anda tidak mengambil tindakan apa pun untuk mengatasi kesalahan. Setelah proyek telah diuji dengan benar, potensi jumlah kesalahan yang dapat mencapai produksi telah berkurang menjadi 100. Sekarang, untuk melihat kemungkinan nyata dari TypeScript, mari kita lihat berapa banyak kesalahan ini dapat dideteksi menggunakannya. Karena sekitar 80% kesalahan tidak dapat dideteksi menggunakan TypeScript, dan mengingat bahwa, secara teori, semua kesalahan yang terdeteksi menggunakan TypeScript dapat dideteksi menggunakan metode lain, seperti menggunakan metodologi TDD, kami akan tiba dengan cukup murah hati dan menganggap bahwa TypeScript akan mendeteksi 8% kesalahan lainnya. Di sini, sebagai tambahan, kami melanjutkan dari asumsi bahwa kami tidak menemukan sekitar setengah dari kesalahan yang terdeteksi oleh TypeScript dengan cara lain. Hasilnya adalah sebagai berikut:
- Sebuah proyek di mana langkah-langkah pengendalian kesalahan tidak diterapkan mengandung 1000 kesalahan.
- Menggunakan langkah-langkah untuk memerangi kesalahan non-TypeScript, 900 kesalahan terdeteksi.
- Setelah memeriksa proyek menggunakan TypeScript, 92 kesalahan tetap. Ini berarti bahwa berkat penerapan TypeScript, 8 kesalahan lain terdeteksi.
, , TDD, , TypeScript- , , . . TypeScript . TypeScript, .
, TypeScript, TypeScript 15% . — 150 1000. , , TypeScript, 900 . , , , TypeScript - . TypeScript , , , 908 1000 (, , , , TypeScript).
. , 30-80% . :
, , , , , , , TypeScript. : TypeScript . , . .
, , - TypeScript. TypeScript, ?
▍ JavaScript - (New JS Features, Compile to Cross-Browser JS)
TypeScript 0, JavaScript. , Babel JavaScript , , , .
TypeScript JavaScript. , . JavaScript , , , , TypeScript , . , , TypeScript «».
▍ (Recruiting)
, State of JavaScript, TypeScript , 33.7% TypeScript. 5.4% TS , , 13.7% , . TS- 20%, , . — , (, , , ).
, - , TypeScript . . , TypeScript .
▍ , (Setup, Initial Training)
, . , JavaScript, TypeScript- 2-3 , 6-8 . , , , , , , TypeScript, , .
▍ (Missing Features)
, , . TypeScript JavaScript. TypeScript , . , JavaScript- , , . , , , TypeScript .
TypeScript TypeScript. , , , . , , TypeScript- . , , , , .
▍ (Ongoing Mentorship)
TypeScript, . , , , . TypeScript -. , , , , , .
, TypeScript- , , , , . , , , , , .
. . , TypeScript-, - , . « » — , , . , — , TypeScript .
▍ , (Typing Overhead)
, , , . — TypeScript, . . , , .
, , . , , , . , , , .
, . , , .
, TypeScript « ». Haskell , . TypeScript, , , , , .
, TypeScript- . — , TypeScript- , , , , . TypeScript- , , . , , — .
« » . , .
« » — , . « » — .
« » — TypeScript. :
- . «» ( — Haskell).
- , , , . TypeScript- , , , , , , . , , TypeScript-, Stack Overflow.
TypeScript, , . , , .
, TypeScript , , .
TypeScript , . TypeScript , , , . TypeScript, TypeScript- , TypeScript.
, TypeScript , , « » TypeScript . , TypeScript-, .
Saya pasti akan menggunakan TypeScript, dalam keadaan seperti sekarang, ketika mengembangkan proyek open source kecil, terutama untuk membuat hidup lebih mudah bagi programmer TypeScript lainnya. Tetapi saya tidak akan menerapkan versi TypeScript saat ini dalam proyek skala besar berikutnya. Masalahnya adalah bahwa semakin besar proyek, semakin mahal, dalam segala hal, penggunaan TypeScript akan sesuai untuk itu.Saya akan selesai dengan catatan ironis. Situs web resmi TypeScript mengatakan bahwa kita memiliki "JavaScript yang diskalakan." Akan lebih jujur untuk menambahkan satu kata lagi ke slogan ini dan membuatnya seperti ini: "JavaScript yang tidak skala dengan baik."Pembaca yang budiman! Silakan bagikan tayangan Anda dari TypeScript.