(Satu-satunya Alternatif Semasa: JavaScript Vanila

Saya telah melihat pembangun yang telah lama bekerja dengan C, masih membangun dengan MFC (Microsoft Foundation Classes). Sebabnya mudah: tiada alternatif sebenar untuk membina UI dalam C . Walaupun Qt wujud, ia memerlukan lesen komersial untuk kegunaan profesional, menjadikan MFC satu-satunya pilihan.

MFC menyediakan komponen UI asas, tetapi ia masih mampu mencipta program peringkat pengeluaran seperti perisian CAD atau aplikasi untuk hospital.

Keadaan semasa ekosistem JavaScript agak serupa.

Tiada rangka kerja yang telah dibina khusus untuk menangani matlamat HPSE. Walaupun terdapat enjin permainan seperti Babylon.js, ini hanya menawarkan ciri untuk grafik 3D dan tidak menyediakan struktur menyeluruh seperti yang dilakukan oleh React.

Jadi, pada akhirnya, semuanya kembali kepada JavaScript Vanilla dan TypeScript. Bukannya pembangun menggunakan JavaScript Vanila kerana mereka menyukainya; mereka menggunakannya kerana tiada pilihan lain. Sama seperti pada hari-hari awal apabila pembangun terpaksa membina segala-galanya dari awal dalam C kerana kekurangan rangka kerja komersial, kami kini menghadapi situasi yang sama dalam JavaScript. Tiada rangka kerja sedia ada yang memenuhi sepenuhnya permintaan HPSE, jadi kami dibiarkan untuk membangunkan secara manual dengan JavaScript Vanila.

Dan terus terang, ini bukan eksklusif untuk JavaScript. Ia juga berlaku untuk kebanyakan bahasa lain.

Ada pepatah, "Tiada perkara seperti makan tengah hari percuma."

Banyak program yang bermula dengan cita-cita besar untuk memecahkan sempadan baharu akhirnya bergantung sepenuhnya pada ciri tersuai yang dibina terus dalam bahasa pengaturcaraan. HPSE juga bermula dengan visi satu hari menjalankan program asli dalam penyemak imbas, dan buat masa ini, ia mesti ditulis sekeping demi sekeping dalam JavaScript Vanila.

Sesetengah mungkin berpendapat, "Mengapa tidak tinggalkan JavaScript sahaja dan gunakan C atau Rust untuk mencipta modul WebAssembly (WASM) dan sebaliknya menjalankannya dalam penyemak imbas?"

Ada cerita bagus yang menjawab soalan ini.

Pemimpin Babylon.js dan Three.js pernah ditanya dalam ulasan sama ada teknologi WASM akan menjadi masa depan enjin mereka. Jawapan mereka ialah "Tidak."

Alasannya mudah: Kod C /Rust tidak dijalankan secara langsung dalam persekitaran web, yang menjadikan penyahpepijatan lebih sukar. Dan terima kasih kepada kemajuan enjin V8, JavaScript kini boleh mencapai prestasi tinggi. JavaScript ialah bahasa skrip yang berjalan terus dalam penyemak imbas dan menawarkan produktiviti yang tinggi—tidak perlu meninggalkan kekuatan ini.

Pada masa lalu, pengaturcara bersaing dengan membangunkan sistem pengendalian mereka sendiri. Tetapi selepas Windows, Mac dan Linux menjadi standard, tumpuan beralih kepada cara membina program yang berjalan di atas sistem ini. Begitu juga, penyemak imbas hari ini telah berkembang ke tahap yang munasabah untuk memikirkan cara membina program yang berjalan di dalamnya.

Jika terdapat garisan yang jelas tentang JavaScript yang patut dan tidak patut digunakan, dan jika tugasan mewah benar-benar tidak sesuai untuk JavaScript, maka Microsoft tidak akan pernah memulakan projek Babylon.js dan Three.js tidak akan pernah telah dicipta. Perkara yang sama berlaku untuk WebGPU, yang sedang ditubuhkan sebagai standard web baharu.

Baru-baru ini, saya telah memikirkan identiti saya sebagai pembangun, mempersoalkan maksud "frontend" dan sama ada istilah itu benar-benar boleh merangkumi skop pembangunan pelanggan web.

Saya pasti terdapat banyak maklumat salah dalam fikiran saya, tetapi saya akan menyiarkan ini sebagai entri blog pertama saya untuk menyatukan apa yang saya fikirkan.

Atas ialah kandungan terperinci (Satu-satunya Alternatif Semasa: JavaScript Vanila. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!