Membandingkan alat pembina generasi baru

Sekumpulan alat pemaju baru telah mendarat pada tahun lalu dan mereka menggigit pada tumit alat-alat yang telah menguasai pembangunan front-end sejak beberapa tahun kebelakangan ini, termasuk Webpack, Babel, Rollup, Parcel, Create-REACT-App.

Alat baru ini tidak direka untuk melaksanakan fungsi yang sama, dan masing -masing mempunyai perkara yang berbeza yang mereka cuba capai dan ciri -ciri untuk sampai ke sana. Walaupun perbezaan mereka, alat ini berkongsi matlamat yang sama: meningkatkan pengalaman pemaju.

Jadual Kandungan

1. Mengapa alat ini tiba sekarang?
2. Bagaimanakah ini berbeza dengan alat yang ada?
3. Percubaan
4. Ciri -ciri yang boleh dibandingkan
5. Esbuild
6. Snowpack
7. Vite
8. wmr
9. Perbandingan ciri
10. Membungkus

Khususnya, saya ingin menilai setiap orang, menggariskan apa yang mereka lakukan, mengapa kita memerlukannya, dan kes penggunaannya. Saya menyedari bahawa perbandingan tidak selalu adil. Sekali lagi, ia tidak seperti mana -mana perkara yang kita lihat dalam artikel ini adalah pesaing langsung. Malah, salji dan Vite sebenarnya menggunakan esbuild di bawah tudung untuk tugas -tugas tertentu. Matlamat kami adalah lebih untuk mendapatkan pandangan yang lebih baik mengenai landskap alat pemaju yang menjalankan tugas untuk menjadikan pekerjaan kami lebih mudah. Dengan cara ini, kita melihat apa pilihan di luar sana dan bagaimana mereka menyusun, jadi kita boleh membuat pilihan terbaik apabila kita memerlukannya.

Sudah tentu, semua ini akan berwarna oleh pengalaman saya menggunakan React dan Preact. Saya lebih akrab dengan perpustakaan rangka kerja ini, tetapi kami akan melihat sokongan mereka untuk rangka kerja depan yang lain juga.

Terdapat banyak artikel, aliran, dan podcast yang hebat mengenai alat pemaju baru ini. Terdapat beberapa episod Shoptalk Show yang saya cadangkan untuk lebih banyak konteks: Episode 454 membincangkan Vite dan Episode 448 mempunyai pencipta WMR dan Snowpack. Sesuatu yang menonjol dari episod ini adalah bahawa sejumlah besar kerja telah membina alat -alat ini untuk memodenkan persekitaran pemaju kami.

Mengapa alat ini tiba sekarang?

Sebahagiannya, saya fikir alat -alat ini tiba sebagai tindak balas kepada keletihan alat JavaScript - sesuatu yang ditangkap dengan baik dalam artikel ini mengenai pembelajaran JavaScript kembali pada tahun 2016. Mereka datang bateri-termasuk tanpa senarai ketergantungan, dan merupakan sebahagian daripada trend lapisan runtuh dalam ekosistem JavaScript.

Snowpack, Vite, dan WMR semuanya telah diaktifkan oleh modul JavaScript asli dalam penyemak imbas. Kembali pada tahun 2018, Firefox 60 dikeluarkan dengan modul ECMAScript 2015 yang didayakan secara lalai. Sejak itu, semua enjin penyemak imbas utama telah menyokong modul JavaScript asli. Node.js juga dihantar dengan modul JavaScript asli pada bulan November 2019. Kami masih mengetahui kemungkinan modul JavaScript asli dibuka hari ini pada tahun 2021.

Bagaimanakah ini berbeza dengan alat yang ada?

Sama ada kami menggunakan Webpack, Rollup, atau Parcel untuk pelayan pembangunan, alat ini menggabungkan keseluruhan kod kami dari kod sumber kami dan folder node_modules, menjalankannya melalui proses membina - seperti Babel, Typescript, atau PostCSS - kemudian menolak kod bundel ke pelayar kami. Ini semua mengambil kerja, dan boleh melambatkan pelayan pembangunan untuk merangkak dalam kod yang lebih besar, walaupun selepas semua kerja yang telah dimasukkan ke dalam caching dan mengoptimumkan.

Snowpack, Vite, dan WMR Development Servers tidak mengikuti model ini. Sebaliknya, mereka menunggu sehingga penyemak imbas mendapati pernyataan import dan membuat permintaan HTTP untuk modul. Hanya selepas permintaan ini dibuat, alat ini memohon transformasi ke modul yang diminta dan mana -mana nod daun dalam pokok import modul, kemudian berkhidmat kepada penyemak imbas. Ini mempercepatkan banyak perkara kerana kurang kerja dalam proses menolak ke pelayan dev.

Anda akan melihat Esbuild hilang dari gambar ini. Ia adalah bundler yang pertama dan paling utama. Ia tidak mengikat sampingan cara alat lain. Sebaliknya, Esbuild memproses kod dengan sangat cepat dengan mengelakkan transformasi mahal, memanfaatkan selaras dan menggunakan bahasa Go.

Percubaan

Saya mengambil salah satu aplikasi contoh dari dokumen React dan membina semula dengan setiap alat yang diliputi dalam artikel ini. Projek yang saya jalankan adalah Snap Shot oleh Yogita Verma. Berikut adalah pautan ke repo asal, dan pautan ke repo saya dengan empat versi Snap Shot, masing -masing menggunakan alat binaan yang berbeza. Kami akan membandingkan output setiap langkah membina kemudian. Membina semula aplikasi ini membolehkan saya menguji pengalaman pemaju untuk menarik beberapa kebergantungan reaksi standard ke dalam alat, termasuk Router React dan Axios.

Ciri -ciri yang boleh dibandingkan

Sebelum kita masuk ke dalam spesifik setiap alat individu, mereka semua menyokong ciri -ciri berikut dari kotak (hingga pelbagai darjah):

• Sokongan kelas pertama untuk modul JavaScript asli
• Penyusunan TypeScript (tetapi tidak menaip pemeriksaan)
• JSX
• Plugin API untuk Extensibility
• Pelayan pembangunan terbina dalam
• CSS Bundling dan Sokongan untuk Perpustakaan CSS-In-JS

Semua alat ini boleh menyusun TypeScript ke JavaScript, tetapi akan berbuat demikian walaupun terdapat kesilapan jenis . Untuk pemeriksaan jenis yang betul, anda perlu memasang TypeScript dan menjalankan TSC -noemit pada fail JavaScript root anda, atau secara alternatif, gunakan plugin editor untuk menonton ralat jenis.

Ok, mari kita lihat setiap alat.

Esbuild

Esbuild dicipta oleh Evan Wallace (CTO of Figma). Ciri utamanya ialah ia menyediakan Build Langkah 10 × -100 × lebih cepat daripada bundlers berasaskan nod (oleh penanda aras mereka sendiri). Ia tidak menyediakan banyak kemudahan pemaju yang mungkin anda dapati dalam sesuatu seperti create-react-app. Tetapi terdapat semakin banyak pemula esbuild yang muncul yang mengisi jurang-jurang itu, termasuk Create-React-App-Esbuild, Estrella dan Snowpack, yang menggunakan Esbuild untuk langkah membina.

Esbuild sangat baru. Ia belum mencapai versi 1.0 dan tidak cukup bersedia untuk kegunaan pengeluaran - tetapi ia tidak jauh. Ia memberi anda API JavaScript dan Command Line Intuitif dengan lalai pintar.

Gunakan kes

Esbuild adalah penukar permainan lengkap di dunia Bundler. Ia akan menjadi paling berguna dalam kod besar di mana perbezaan kelajuan antara esbuild dan nod bundlers mendapat didarab. Apabila Esbuild mencecah 1.0 ia akan menjadi sangat berguna di tapak pengeluaran besar dan akan menjimatkan pasukan banyak masa menunggu binaan untuk diselesaikan. Malangnya, tapak pengeluaran besar perlu menunggu sehingga Esbuild menjadi stabil. Sementara itu, ia akan menjadi baik untuk menambah kelajuan untuk bundling anda dalam projek sampingan.

Kelajuan kilat cepat Esbuild akan menjadi bonus untuk apa-apa jenis kerja yang anda lakukan. Kurang masa yang dihabiskan untuk menunggu Builds to Run sentiasa menjadi baik untuk pengalaman pemaju! Ini dipertimbangkan, jika anda prototaip aplikasi cepat, anda mungkin ingin memulakan dengan sesuatu yang lebih tinggi daripada Esbuild - jika tidak, anda perlu meluangkan masa untuk menarik kebergantungan dan mengkonfigurasi persekitaran anda sebelum anda mendapat kemudahan yang kami harapkan dalam ekosistem JavaScript. Juga, jika anda ingin meminimumkan saiz bundle anda sebanyak mungkin, anda mungkin mahu menggunakan rollup dan terser, yang akan menghasilkan saiz bundle yang lebih kecil.

Persediaan

Saya memutuskan untuk memulakan projek React di Esbuild dengan cara naif: NPM memasang Esbuild, React dan Reactdom. Saya membuat fail src/app.jsx dan fail dist/index.html. Kemudian, saya menggunakan arahan berikut untuk menyusun aplikasi ke dalam fail dist/bundle.js:

 ./node_modules/.bin/esbuild src/app.jsx --bundle --platform = penyemak imbas --outfile = dist/bundle.js

Apabila saya menganjurkan dan membuka index.html dalam penyemak imbas, saya ditemui dengan "Skrin Putih Kematian" dan kesilapan konsol "tidak ditakrifkan". Kedua -dua dokumen dan CLI menerangkan dengan tepat apa yang perlu anda lakukan untuk mencegahnya tetapi mungkin sedikit "gotcha" untuk pemula, kerana ia memerlukan hujah tambahan ketika mengikat reaksi:

 --define: process.env.node_env = \ "Production \"

Atau, jika anda termasuk Esbuild dalam skrip NPM yang ditulis seperti ini untuk melepaskan petikan:

 --define: process.env.node_env = \\\ "Pengeluaran \\\"

Ini menentukan hujah diperlukan untuk mana -mana perpustakaan yang dibundel untuk penyemak imbas yang mengharapkan pembolehubah persekitaran nod. Vue 2.0 juga menjangkakan ini. Anda tidak akan mempunyai masalah yang sama dengan Preact kerana ia tidak mengharapkan pembolehubah dan kapal persekitaran bersedia untuk penyemak imbas secara lalai.

Selepas saya menjalankan arahan dengan hujah Define, aplikasi "Hello World" saya berfungsi dengan sempurna. JSX berfungsi keluar dari kotak dengan fail .jsx. Yang mengatakan, React perlu diimport secara manual dan kemudian JSX ditukar kepada react.createelement. Walau bagaimanapun, ada cara untuk menambah import auto di JSX dan/atau mengkonfigurasi JSX untuk Preact.

Penggunaan

Esbuild menyediakan pilihan -serve untuk pelayan pembangunan. Ini memintas sistem fail dan menyajikan modul terus dari ingatan, memastikan penyemak imbas tidak menarik versi modul yang lebih lama. Walau bagaimanapun, ia tidak termasuk tambah nilai hidup/panas, jadi anda akan mendapati diri anda menyegarkan penyemak imbas selepas menjimatkan yang bukan pengalaman yang ideal.

Saya memutuskan untuk menggunakan ciri Watch yang baru dikeluarkan. Ini memberitahu Esbuild untuk menyusun semula kod setiap kali fail sumber disimpan. Tetapi kami masih memerlukan pelayan untuk melihat perubahan yang disimpan. Kami boleh menarik pakej pelayan pembangunan, seperti Servor Luke Jackson:

 NPM Pasang Servor--Save-Dev

Kemudian kita boleh menggunakan API Esbuild JavaScript untuk memulakan sebagai pelayan dan menjalankan mod menonton Esbuild pada masa yang sama. Mari buat fail di akar projek kami yang dipanggil Watch.js:

 // watch.js
const esbuild = memerlukan ("esbuild");
const servor = memerlukan ("servor");

esbuild.build ({
  // lulus sebarang pilihan untuk membangun di sini ...
  Kemasukan: ["src/app.jsx"],
  Outhir: "Dist",
  Tentukan: {"Process.env.node_env": '"Production"'},
  Tonton: Benar,
});

fungsi async berkhidmat () {
  Console.log ("Running Server dari: http: // localhost: 8080/");
  menunggu servor ({
    // lulus sebarang pilihan ke Servor di sini ...
    Penyemak imbas: Benar,
    Root: "Dist",
    port: 8080,
  });
}

berkhidmat ();

Sekarang jalankan node watch.js dalam baris arahan. Ini memberi kami pelayan dev yang bagus, walaupun sekali lagi, ia tidak memberi kami penggantian modul panas atau penyegaran cepat (iaitu, keadaan sisi klien anda tidak akan dipelihara). Tetapi ini sudah cukup untuk keperluan ujian saya.

Walaupun kami menghidupkan seluruh permohonan kami setiap kali kami menyimpan fail, kami perlu mempunyai aplikasi yang cukup besar sebelum Esbuild melambatkan. Selepas saya menyediakan perkakas ini, saya mendapat maklum balas segera dari perubahan. Komputer saya menggunakan Intel i7 dari tahun 2012, jadi pastinya bukan mesin teratas.

Sekiranya anda memerlukan versi Esbuild yang telah dikonfigurasikan dengan Live Reload dan beberapa lalai React, anda boleh mengklon repo ini.

Fail yang disokong

Esbuild boleh mengimport CSS dalam JavaScript jika itu gaya anda. Ia akan menyusun CSS ke dalam fail output dengan nama yang sama dengan fail JavaScript output utama anda. Ia juga boleh membungkus pernyataan CSS @import secara lalai. Tiada sokongan untuk modul CSS, tetapi ada rancangan untuknya.

Terdapat komuniti plugin yang semakin meningkat untuk Esbuild. Sebagai contoh, terdapat plugin yang tersedia untuk komponen fail tunggal Vue, dan komponen Svelte.

Esbuild berfungsi dengan fail JSON dan boleh membungkusnya ke dalam modul JavaScript tanpa sebarang konfigurasi.

Ia juga boleh mengimport imej dalam JavaScript dengan pilihan sama ada menukarnya ke dalam URL data atau menyalinnya ke dalam folder output. Tingkah laku ini tidak diaktifkan secara lalai, tetapi anda boleh menambah yang berikut dalam objek Esbuild Config anda untuk membolehkan pilihan sama ada:

 loader: {'.png': 'dataurl'} // menukar ke url data dalam bundle js
loader: {'.png': 'file'} // salinan ke folder output

Pemisahan kod nampaknya merupakan kerja yang sedang berjalan, tetapi kebanyakannya ada dalam format output ESM, dan ia kelihatan seperti itu adalah keutamaan untuk projek itu. Ia juga bernilai menyebutkan bahawa pohon gemetar dibina ke dalam esbuild secara lalai dan tidak boleh dimatikan.

Pengeluaran membina

Menggunakan pilihan "Minify" dan "Bundle" dalam perintah esbuild anda tidak akan membuat satu bundle agak kecil seperti saluran paip Rollup/Terser. Ini kerana Esbuild mengorbankan beberapa pengoptimuman saiz bundle untuk mendapatkan kod anda dalam beberapa pas mungkin. Walau bagaimanapun, perbezaannya mungkin agak diabaikan, dan berbaloi untuk peningkatan kelajuan bundling, bergantung kepada projek anda. Dalam klon saya aplikasi snap shot, Esbuild mencipta satu bundle 177 kb yang tidak lebih banyak daripada 165KB yang dihasilkan oleh Vite, yang menggunakan Rollup dan Terser.

Keseluruhan

Esbuild adalah alat yang sangat kuat. Tetapi mungkin sukar jika anda digunakan untuk persediaan sifar-config. Jika anda memerlukan lebih banyak, maka anda mungkin ingin melihat alat seterusnya, Snowpack, yang menggunakan Esbuild.

Snowpack

Snowpack adalah alat binaan oleh pencipta Skypack dan Pika. Ia menyediakan pelayan pembangunan yang hebat dan dicipta dengan falsafah "pembangunan yang tidak dibatalkan". Untuk mengutip dokumentasi: "Anda sepatutnya dapat menggunakan bundler kerana anda mahu, dan bukan kerana anda perlu."

Secara lalai, langkah membina Snowpack tidak membungkus fail ke dalam satu pakej tetapi menyediakan esmodul yang tidak terkawal yang dijalankan di penyemak imbas. Esbuild sebenarnya termasuk di sana sebagai kebergantungan, tetapi idea itu adalah menggunakan modul JavaScript dan hanya bundle dengan Esbuild apabila diperlukan.

Snowpack mempunyai beberapa dokumentasi yang licin, termasuk senarai panduan untuk menggunakannya dengan kerangka JavaScript, dan sekumpulan templat untuk mereka. Sesetengah panduan masih merupakan kerja yang sedang berjalan, tetapi yang lain seperti yang reaksi adalah bagus dan jelas. Ia juga kelihatan seperti Snowpack merawat Svelte sebagai warganegara kelas pertama. Saya sebenarnya mula-mula mendengar tentang Snowpack dari "Pembangunan Web Futuristik" Rich Harris di Svelte Summit 2020. Yang mengatakan, Svelt-rangka kerja Sveltekit yang akan datang sepatutnya dikuasakan oleh Snowpack tetapi sejak itu beralih ke Vite (yang akan kami semak semula).

Gunakan kes

Snowpack adalah pilihan yang baik jika anda ingin menggandakan penggunaan yang tidak dibatalkan. Anda mungkin menulis kod sumber dengan sebilangan kecil modul. Ini bermakna anda tidak mencipta air terjun permintaan besar dengan binaan yang tidak dibatalkan. Sekiranya anda tidak memerlukan kerumitan tambahan dan hutang teknikal, maka Snowpack adalah pilihan yang hebat. Kes penggunaan yang baik adalah jika anda secara bertahap mengadopsi rangka kerja front-end ke dalam aplikasi yang diberikan pelayan atau statik. Anda akan menarik sedikit alat yang mungkin dari ekosistem nod tetapi anda masih akan mendapat manfaat kerangka frontend deklaratif.

Kedua, saya berhujah bahawa Snowpack adalah pembungkus hebat di sekitar Esbuild. Jika anda ingin mencuba Esbuild tetapi juga mahukan pelayan pembangunan dan templat pra-ditulis untuk rangka kerja front-end, maka anda tidak boleh salah dengan Snowpack. Dayakan Esbuild dalam langkah membina konfigurasi salji anda dan anda baik untuk pergi.

Sebagai perkara yang kini berdiri, saya akan berhujah bahawa Snowpack tidak akan menjadi pengganti terbaik untuk alat konfigurasi sifar seperti Create-react-app kerana anda perlu menarik plugin dan mengkonfigurasi mereka sendiri jika anda mempunyai aplikasi besar dan memerlukan langkah membina siap sedia yang dioptimumkan.

Persediaan

Mari mulakan projek dengan snowpack dengan melompat ke baris arahan:

 Mkdir Snowpackproject
CD SnowpackProject
npm init #fill dengan lalai 
NPM Pasang Snowpack

Sekarang, mari tambahkan yang berikut ke Package.json:

 // Package.json
"Skrip": {
  "Mula": "Snowpack Dev",
  "Bina": "Snowpack Build"
},

Seterusnya, kami akan membuat fail konfigurasi:

 // mac atau linux
sentuh snowpack.config.js
// Windows
New-item snowpack.config.js

Saya fikir bahagian yang paling ajaib dari Snowpack datang apabila menetapkan satu pasangan nilai utama yang tidak bersalah dalam fail konfigurasi. Tampal ini ke dalam fail konfigurasi, sebagai contoh:

 // snowpack.config.js
modul.exports = {
  PackageOptions: {
    "Sumber": "Jauh",
  }
};

Sumber: Jauh membolehkan sesuatu yang dipanggil import streaming . Import streaming membolehkan Snowpack untuk memintas pemasangan NPM dengan menukar import kosong (contohnya, import bertindak balas dari 'bertindak balas';) ke dalam import CDN dari Skypack.

Melangkah ke hadapan, mari buat fail index.html:

 



  <meta charset="UTF-8">>
  <tirtle> Snowpack Streaming Import 


  <div> </div>
  
  <skrip jenis="modul" src="app.js"> 

</skrip></tirtle>

Dan, akhirnya, kami akan menambah fail app.jsx:

 // app.jsx
Import React dari 'React'
Import Reactdom dari 'React-Dom'
const app = () => {
  Kembali <h1 id="Selamat-Datang-ke-Snowpack-Streaming-Import"> Selamat Datang ke Snowpack Streaming Import! </h1>
}
ReactDom.render (<app></app>,document.getElementById('root ')); 0

Ambil perhatian bahawa kami tidak memasang NPM React atau Reactdom di mana -mana peringkat. Tetapi jika kita memulakan pelayan pemaju salji seperti ini:

 ./node_modules/.bin/snowpack dev

... Aplikasi kami masih berfungsi!

Daripada menarik dari folder Node_modules, Snowpack menarik pakej NPM dari Skypack, CDN yang menjadi tuan rumah pendaftaran NPM, dan ia dioptimumkan untuk bekerja di pelayar. Snowpack kemudian menghidangkannya dalam url ./_snowpack/pkg.

Penggunaan

Ini adalah langkah besar dari aliran kerja berasaskan nod/NPM. Apa yang sebenarnya kita lihat ialah aliran kerja berasaskan modul CDN/JavaScript baru.

Jika, bagaimanapun, kami menjalankan aplikasi kami kerana ia adalah dan menjalankan pengeluaran pengeluaran, Snowpack melemparkan kesilapan. Ini kerana ia perlu mengetahui versi React dan Reactdom yang digunakan semasa membina. Anda boleh membetulkannya dengan menulis ke snowpack.deps.json yang secara automatik boleh dibuat dengan menjalankan yang berikut:

 ./node_modules/.bin/snowpack Tambah React
./node_modules/.bin/snowpack Tambah React-Dom

Itu tidak akan memuat turun pakej dari npm, tetapi ia akan merakam versi pakej yang digunakan untuk membina salji.

Satu kaveat ialah kita terlepas mesej ralat pemaju, kerana Skypack akan menghantar versi pengeluaran pakej.

Walaupun kita tidak menggunakan import streaming, pelayan pembangunan salji mengikat setiap kebergantungan dari node_modules ke dalam satu fail JavaScript setiap ketergantungan, menukar fail tersebut ke modul JavaScript asli, kemudian berfungsi kepada penyemak imbas. Ini bermakna penyemak imbas boleh cache skrip ini dan hanya memohon semula mereka jika mereka telah berubah. Pelayan pembangunan secara automatik menyegarkan pada SAVE, tetapi tidak mengekalkan keadaan sisi klien. Semua kebergantungan dari nod seolah -olah bekerja dari kotak tanpa mengira sama ada mereka menggunakan format modul warisan atau API nod (seperti proses yang terkenal.

Memelihara keadaan sisi klien dalam React memerlukan reaksi-refresh, yang memerlukan beberapa pakej babel sendiri sebagai kebergantungan. Ini tidak termasuk secara lalai, tetapi boleh didapati menggunakan templat React Maksimum. Template menarik dalam reaksi-refresh, prettier, chai, dan reaksi perpustakaan ujian, untuk pakej ketergantungan nod total yang beratnya pada 80 MB:

 NPX CREATE-SNOWPACK-APP MY-REACT-PROJEK --Template @Snowpack/App-Template-React

Fail yang disokong

JSX disokong, tetapi sekali lagi, hanya dengan fail .jsx secara lalai. Snowpack secara automatik mengesan sama ada bertindak balas atau preact sedang digunakan, dan memutuskan dengan sewajarnya yang berfungsi untuk digunakan untuk transformasi JSX. Walau bagaimanapun, jika kita mahu menyesuaikan JSX lebih jauh daripada ini, kita perlu menarik Babel melalui plugin mereka. Terdapat juga plugin snowpack yang tersedia untuk komponen fail tunggal Vue dan, tentu saja, untuk komponen svelte. Selanjutnya, Snowpack menyusun jenis -jenis, tetapi untuk pemeriksaan jenis kami memerlukan plugin TypeScript.

CSS boleh diimport ke JavaScript dan dilemparkan ke dalam dokumen pada runtime. Modul CSS juga disokong keluar dari kotak untuk scoping selagi mereka mempunyai lanjutan .module.css.

Fail JSON yang diimport akan dimasukkan ke dalam modul JavaScript dengan objek sebagai eksport lalai. Snowpack menyokong imej dan menyalinnya ke dalam folder pengeluaran. Melangkah bersama dengan falsafah yang tidak dibebankan, Snowpack tidak termasuk imej sebagai URL data dalam bundle.

Pengeluaran membina

Perintah binaan salji lalai pada dasarnya menyalin struktur fail sumber yang tepat ke dalam folder output. Untuk fail yang disusun kepada JavaScript (contohnya Typescript, JSX, JSON, .vue, .svelte), ia mengubah setiap fail individu menjadi modul JavaScript mesra penyemak imbas yang berasingan.

Ini berfungsi dengan baik, tetapi tidak bagus untuk pengeluaran, kerana ia boleh menyebabkan air terjun yang besar jika kod sumber dibahagikan kepada banyak fail. Dalam aplikasi snap Shot saya berakhir dengan 184KB fail sumber yang kemudiannya akan meminta 105 kb lagi dependensi dari Skypack yang dibuat untuk air terjun yang cukup besar.

Walau bagaimanapun, Snowpack menarik Esbuild sebagai kebergantungan dan kami boleh membolehkan Esbuild untuk membungkus, meminimumkan dan menyusun kod kami dengan menambahkan objek "mengoptimumkan" ke konfigurasi salji:

 // snowpack.config.js
modul.exports = {
  Optimumkan: {
    Bundle: Benar,
    Minify: Benar,
    Sasaran: 'ES2018',
  },
};

Ini menjalankan kod menggunakan ciri -ciri pengoptimuman yang disediakan oleh Esbuild, jadi dengan hanya menambah pilihan ini, kami dapat mendapatkan binaan yang sama yang kami telah tadi dengan Esbuild.

Oleh kerana Esbuild belum mencapai 1.0 lagi, Snowpack mengesyorkan menggunakan sama ada Webpack atau Rollup plugin untuk pengeluaran pengeluaran, yang kedua -duanya perlu dikonfigurasikan.

Keseluruhan

Snowpack menyediakan pengalaman pemaju ringan dengan pelayan pembangunan penuh, dokumentasi terperinci, dan templat yang mudah dipasang. Anda dibiarkan memutuskan sama ada anda ingin membungkus aplikasi anda dan bagaimana anda mahu melakukannya. Jika anda mahukan alat yang menyediakan kedua -dua pelayan dev dan langkah membina yang lebih berpandangan, anda mungkin mahu melihat Vite, alat seterusnya dalam senarai kami.

Vite

Vite dibangunkan oleh Vue Creator (dan Hades Speedrunner) Evan anda. Di mana Esbuild menumpukan pada langkah binaan dan salji yang menumpukan pada pelayan pembangunan, Vite menyediakan kedua -duanya: pelayan pembangunan penuh dan arahan binaan yang dioptimumkan menggunakan rollup.

Gunakan kes

Sekiranya anda mahukan pesaing Create-App-App atau Vue CLI yang serius, Vite adalah yang paling dekat dalam sekumpulan kerana ia datang dengan ciri-ciri yang termasuk bateri. Pelayan pembangunan yang ringan dan sifar-config yang dioptimumkan pengeluaran membina bermakna anda boleh mendapatkan dari sifar ke pengeluaran tanpa sebarang konfigurasi. Vite adalah alat yang boleh digunakan dalam kedua-dua projek sampingan kecil atau aplikasi pengeluaran besar. Kes penggunaan yang baik untuk Vite akan menjadi aplikasi halaman tunggal yang besar.

Mengapa anda tidak menggunakan Vite? Vite adalah alat pendapat dan anda mungkin tidak bersetuju dengan pendapatnya. Anda mungkin tidak mahu menggunakan Rollup untuk membina anda (kami telah bercakap tentang berapa cepat Esbuild), atau anda mungkin mahu perkakas anda memberi anda kuasa penuh Babel, Eslint, dan ekosistem pemuat webpack keluar dari kotak.

Selain itu, jika anda mahukan kerangka meta-kerangka rendering pelayan sifar, anda akan lebih baik tinggal dengan rangka kerja berasaskan webpack, seperti nuxt.js dan next.js sehingga cerita untuk rendering sisi pelayan Vite lebih lengkap.

Persediaan

Vite mempunyai mungkir lebih banyak pendapat daripada Esbuild dan Snowpack. Dokumentasinya jelas dan terperinci. Kami mendapat sokongan penuh untuk Vue dengan Evan menjadi pencipta dan semua, jadi Vite adalah jalan gembira yang pasti untuk pemaju Vue. Yang mengatakan, Vite boleh digunakan dengan mana-mana rangka kerja front-end dan juga menyediakan senarai templat untuk memulakan anda.

Penggunaan

Pelayan pembangunan Vite cukup kuat. Vite Pre-bundles semua kebergantungan projek bersama-sama ke dalam modul JavaScript asli tunggal dengan esbuild, kemudian melayani ia dengan header HTTP yang banyak cache. Ini bermakna tiada masa yang dibazirkan untuk menyusun, melayani atau meminta kebergantungan yang diimport selepas beban halaman pertama. Vite juga menyediakan pemesejan ralat yang jelas, mencetak blok tepat kod dan nombor garis untuk menyelesaikan masalah. Sekali lagi dengan Vite, saya tidak mempunyai sebarang masalah yang menarik kebergantungan yang menggunakan format API atau warisan nod. Mereka semua seolah-olah diletakkan ke dalam esmodule yang boleh diterima oleh penyemak imbas.

Templat React dan Vue Vite kedua -dua tarik plugin yang membolehkan penggantian modul panas. Templat Vue menarik dalam plugin Vue untuk komponen fail tunggal, dan plugin Vue untuk JSX. Templat React menarik dalam plugin React-Refresh. Sama ada cara, kedua-duanya akan memberi anda penggantian modul panas dan pemeliharaan keadaan klien. Pasti, mereka menambah beberapa lagi kebergantungan, termasuk pakej Babel, tetapi, Babel sebenarnya tidak perlu apabila menggunakan JSX dalam Vite. Secara lalai, JSX berfungsi dengan cara yang sama seperti Esbuild - ia ditukar kepada React.Createelement. Ia tidak akan mengimport reaksi secara automatik, tetapi tingkah lakunya boleh dikonfigurasikan.

Dan semasa kami berada di situ, Vite tidak menyokong import streaming seperti Snowpack dan WMR. Ini bermakna NPM-memasang ketergantungan seperti biasa.

Satu perkara yang sejuk ialah Vite termasuk sokongan eksperimen untuk penyampaian sisi pelayan. Pilih kerangka pilihan anda dan menjana HTML statik yang dihantar terus kepada pelanggan. Pada masa ini, ia kelihatan seperti kita perlu membina seni bina ini sendiri, tetapi masih, ini kelihatan seperti peluang yang baik untuk meta-rangka kerja yang akan dibina di atas Vite. Evan Anda sudah mempunyai kerja yang sedang dijalankan yang dipanggil Vitepress, pengganti untuk Vuepress dengan faedah menggunakan Vite. Dan Sveltekit juga telah menambah Vite ke senarai ketergantungannya. Ia kelihatan seperti kod pemisahan kod CSS adalah sebahagian daripada sebab Sveltekit membuat suis ke Vite.

Fail yang disokong

Untuk CSS, Vite menyediakan ciri -ciri yang paling banyak daripada semua alat yang kita cari. Ia menyokong import CSS dan modul CSS serta modul CSS. Tetapi kami juga boleh memasang plugin PostCSS NPM dan membuat fail POSTCSS.CONFIG.JS, dan VITE secara automatik akan mula menggunakan transformasi ini ke CSS.

Kami boleh memasang dan menggunakan preprocessors CSS - hanya NPM memasang preprocessor dan menamakan semula fail ke lanjutan yang betul (misalnya .filename.scss) dan Vite akan mula memohon preprocessor yang sepadan. Dan, seperti yang kita katakan dalam gambaran keseluruhannya, Vite menyokong kod CSS-splitting.

Import imej lalai ke URL awam, tetapi kami juga dapat memuatkannya ke dalam bundle sebagai rentetan dengan menggunakan parameter mentah pada akhir rentetan URL.

Fail JSON boleh diimport di sumber dan ditukar menjadi esmodul yang mengeksport objek tunggal. Kami juga boleh menyediakan Import dan Vite yang dinamakan akan melihat di medan akar fail JSON untuk mencari import dan treeshake yang lain.

Pengeluaran membina

Vite menggunakan rollup untuk membina pengeluaran yang telah dikonfigurasikan dengan sekumpulan pengoptimuman. Ia sengaja menyediakan binaan sifar-config yang sepatutnya cukup untuk kebanyakan kes penggunaan.

Binaan ini dilengkapi dengan ciri -ciri rollup yang kami harapkan: bundling, minifikasi dan pohon berjabat. Tetapi kami juga mendapat tambahan, seperti import dinamik yang dipisahkan kod dan sesuatu yang dipanggil "pemuatan chunk asynchronous" yang merupakan cara mewah untuk mengatakan bahawa jika kami meminta modul JavaScript yang mengimport modul lain, binaan itu akan dioptimumkan untuk memuatkan kedua-duanya pada masa yang sama (asynchronously).

Membina lalai Vite dengan aplikasi Snap Shot saya berakhir dengan satu fail 5kb JavaScript dan satu fail 160kb JavaScript (untuk sejumlah besar 165kb) dan semua CSS dalam projek itu secara automatik dikurangkan ke fail 2.71kb kecil.

Keseluruhan

Sifat Vite yang berpendapat menjadikannya pesaing yang serius dengan perkakas semasa kami. Banyak kerja telah dilakukan untuk menjadikan pengalaman pemaju benar-benar lancar dan membuat pengeluaran siap pengeluaran keluar dari kotak.

wmr

Seperti Vite, WMR adalah alat binaan lain yang menyediakan kedua -dua pelayan pembangunan dan langkah membina. Ia dibina oleh pencipta Preact, Jason Miller, jadi ia pasti jalan gembira untuk pemaju yang sudah praktik. Jason Miller menjelaskan pemikiran di sebalik WMR ketika dia muncul sebagai tetamu di podcast Parti JS:

Preact adalah kecil dan ia benar -benar baik jika anda ingin melakukan projek yang ringan. Di manakah alat kami untuk itu? Kami mempunyai alat berasaskan webpack yang digunakan dalam pengeluaran oleh sekumpulan tapak berprofil tinggi, tetapi itulah alat kelas berat. Di mana alat prototaip? Itulah satu tangan. Sebaliknya saya dan sekumpulan orang lain yang kebetulan berada di pasukan yang sudah praktik; Kami telah menjadi jenis di luar ekosistem Bundler untuk seketika, mendorong orang, cuba mendapatkan konsensus mengenai arah yang boleh kita masuk untuk meneruskan idea ini untuk menulis kod moden dan penghantaran kod moden.

Ini memberitahu kita bahawa WMR adalah mengenai menulis dan menghantar kod moden, membolehkan alat yang lebih ringan dalam projek.

Anda mungkin tertanya -tanya apa yang dikatakan oleh WMR? Tiada apa -apa! Nama -nama "Runtime Modul Web" dan "Penggantian Modul Basah" telah diapungkan, tetapi ia adalah singkatan palsu, sama dengan NPM.

WMR dibina dengan saiz bundle yang sama dengan saiz pembersihan yang sama, jadi ia adalah kecil - seberat hanya 2.6 MB - dan mengandungi ketergantungan NPM yang tepat. Namun, ia berjaya mengemas dalam banyak ciri yang sangat hebat termasuk pelayan pembangunan yang menggegarkan modul dan membina pengeluaran yang dioptimumkan.

Gunakan kes

Saya akan menggunakan WMR jika saya ingin membuat prototaip menggunakan Preact secepat mungkin. Tidak ada konfigurasi dan hanya mengambil masa beberapa saat untuk dimuat turun. Rasanya seperti menggunakan pelayan fail statik supercharged. Dengan TypeScript, langkah yang dioptimumkan, dan rendering HTML statik, WMR menawarkan segala yang diperlukan untuk menghantar aplikasi bersaiz kecil ke sederhana. Saiznya yang kecil juga hebat untuk mencuba perpustakaan atau demo dengan cepat.

WMR mungkin bukan alat untuk anda jika anda tidak menggunakan JavaScript Preact, React atau Vanilla. Pasukan Preact masih belum menyediakan templat untuk rangka kerja lain. Dokumentasi ini juga tidak terperinci sebagai alat lain yang telah kita lihat. Ini bermakna lebih jauh anda tersesat dari jalan gembira, semakin banyak anda akan menggali sumber. Jadi, saya tidak boleh mengesyorkannya jika banyak penyesuaian diperlukan.

Persediaan

Sekiranya anda menggunakan Preact, ada persediaan sifar yang diperlukan kecuali untuk pemasangan NPM cepat. Untuk menggunakan React dengan WMR dan bukannya Preact, kini terdapat dua langkah untuk diambil. Pertama, alias htm/preact ke htm/react, dan bertindak balas terhadap ES-react dalam pakej.json anda:

 "alias": {
  "htm/preact": "htm/react",
  "React": "ES-react"
},

Kemudian tambahkan import dari ES-react ke komponen anda:

 // Reactdom hanya diperlukan pada render root
import {react, reactdom,} dari 'es-react';

Ini bermakna kita sebenarnya tidak menggunakan pakej React Normal yang mungkin anda gunakan, tetapi sebaliknya menarik React dari ES-react. Ini kerana WMR bergantung pada pakej yang serasi dengan modul JavaScript asli. React tidak menggunakan modul asli secara lalai, sebaliknya menggunakan gaya modul yang lebih lama yang dipanggil modul UMD. ES-React adalah pakej yang menarik dalam React tetapi menyediakan eksport yang serasi dengan platform web.

Ini menggambarkan falsafah WMR menggunakan primitif asli platform web berbanding menggunakan alat untuk menghindari dan abstraknya.

Pilihan lain ialah menggunakan import Skypack dalam aplikasi kami, yang juga dioptimumkan untuk bekerja dalam penyemak imbas:

 Import React dari 'https://cdn.skypack.dev/react';
import reactdom dari 'https://cdn.skypack.dev/react-dom';

WMR menjangkakan bahawa anda menulis kod moden yang berjalan di penyemak imbas, yang mungkin bermakna anda perlu melakukan beberapa konfigurasi jika anda menarik kebergantungan yang menggunakan API node atau sistem modul warisan. Untuk mendapatkan aplikasi Snap Shot yang berfungsi, saya perlu menyelam ke dalam modul nod dan menukar perpustakaan atau dua untuk menggunakan sintaks modul JavaScript asli. Ini mungkin melambatkan anda jika anda menggunakan perpustakaan yang lebih tua. Ekosistem yang sudah preact semuanya dioptimumkan untuk dijalankan dalam penyemak imbas dan tidak memerlukan sebarang pengurut. Ini adalah satu lagi sebab untuk melekat dengan jalan gembira yang sudah lama di WMR.

Terdapat plugin untuk WMR. Ia mendedahkan API plugin yang menyokong plugin rollup untuk langkah membina. Terdapat lebih banyak contoh WMR khusus pada DOCS, termasuk plugin yang meminimumkan HTML, dan satu yang mempunyai penghalaan berasaskan sistem fail.

WMR menyokong rangka kerja yang berbeza, tetapi tidak ada template pra-dibina untuk mereka. And at first I found it rather difficult to configure the JSX transform. All that said, Jason has confirmed there are plans to make JSX more configurable and that wmr is intended to be framework-agnostic. JSX is planned to work out of the box in regular JavaScript files.

Penggunaan

To get started you can either run this command in the command line:

 npm init wmr your-project-name

Or alternatively, you can run these commands to manually build up your application:

 npm init -y
npm install wmr
mkdir public
touch public/index.html
touch public/index.js

Then add an script import in the body of your index.html (again make sure to use type="module"):

 <script type="module" src="./index.js"></script>

Now you can write a Preact hello world into your index.js file:

 import { render } from 'preact';
render(<h1 id="Hello-World">Hello World!</h1>, document.body);

And finally start your development server:

 node_modules/.bin/wmr

Now we have a full hot module replacement development server which will immediately respond to any changes to our source-code.

wmr uses a tool called htm when transforming JSX, which provides some awesome benefits. Let's say we're writing a counter using Preact in wmr and make a mistake:

 import { render } from 'preact';
import { useState } from 'preact/hooks';
function App() {
  const [count,setCount] = useState(0)
  return 
  <button onclick="{()=">{setCount(cout 5)}}>Click to add 5 to count</button> // HIGHLIGHT
  <p>count: {count}</p>
  >
}
render(<app></app>, document.body);

count is misspelled in the onClick handler function, so running this results in an error. Usually, we would have to rely on our tooling and a source map to gather information about where the bug is located, but wmr takes a different solution. With htm, this gets as close as you can get to native JSX in the browser by using tagged template literals. So, where writing React or Preact code usually looks like this:

 <mycomponent>I am JSX. I am not actually valid Javascript</mycomponent>

…htm looks more like this:

 html`I am about as close as it gets to JSX as you can get while being able to run in the browser`

Now, if we're debugging our code and open the “Sources” panel in DevTools, we should see a script that's almost identical to what the source code looks like in the editor.

This way, we can properly investigate where bugs are located in the browser without having to use sourcemaps. Sure, this specific example is pretty contrived, but you can see how this could be really useful because it means wmr doesn't need source maps in your developer environment.

wmr supports streaming imports by default, so bare imports will be pulled down from the npm registry. This is done through a complex process which examines all of the source in the npm package, removes all the tests and metadata, and converts it to a single native JavaScript import. Similar to Snowpack, it's possible to build a complex app without using npm to install anything. In fact, wmr is the first tool to support this idea.

Supported files

As far as the other types of files wmr supports, CSS files can be imported in JavaScript, and CSS modules are supported as well.

There isn't any built-in support for either Vue single file components or Svelte components. However, wmr's build step works with Rollup plugins and the development server can be configured with Polka/Express middleware, so it's possible to use these to convert imports into Vue and Svelte components. In fact, I wrote a small plugin for Vue Single file Components to show how this might be done.

We can't import images into JavaScript as data URLs in wmr without a plugin. Instead, we need to import them using a syntactically correct JavaScript method. So, if we have, say, a picture of a dog in our public folder we might include it in a Preact component like this:

 function Dog() {
  return <img src="%7Bnew" url import.meta.url alt="dog hanging out">
}

And once the build step runs, the image is copied and accessible from the distribution folder. There is hot module replacement for images in the development server, so changes with images are immediately reflected in the browser.

One more note on file support: JSON can be imported, and is converted into a JavaScript object for use. But when actually building an application, we'd need the Rollup JSON plugin.

Production build

wmr provides a production build step that includes bundling, minification and tree-shaking without any additional dependencies. Having a look at the source of wmr, it looks like rollup and terser are used under the hood, and minified versions of these are included in the wmr package. The wmr bundle for the Snap Shot app was 164KB so it created a bundle just a tiny bit smaller than total size of the two JavaScript files created by Vite.

There is also a way to configure wmr is such a way that it renders an application to static HTML and hydrates on the browser using preact-iso. This means wmr can be used as a meta-framework for Preact, similar to Next.js.

Overall

I love the experience of using wmr to prototype both React and Preact applications. It feels great to get started with a tool that is ridiculously small but provides developer conveniences that get close to matching heavyweight bundlers.

Feature comparison

We have just covered a lot of ground! Rather than scroll up and down this article to compare results, I've compiled everything here to see how the tools stack up when they're side-by-side. I've even included additional comparisons for features that we didn't explicitly cover.

Use cases

Persediaan

Development server

Production build

Other features

Membungkus

I'm super excited about building JavaScript applications with any and all of the tools we just looked at. Whether we're writing a small side project or a big production site, all these tools speed up feedback loops and increase productivity. They've opened up the gates to ask what's necessary for the JavaScript ecosystem and whether we can start losing the cruft brought by legacy modules and browsers. These tools are going to lower the barrier to entry for new developers by providing a leaner, faster developer environment with fewer abstractions between the code that gets written and the code that runs in the browser.

If you're getting sick of waiting for your dependencies to download and your build steps to run, I'd recommend giving this new generation of tooling a try.

Further reading

• “Comparisons with Other No-Bundler Solutions” (Vite)
• “Let's Learn esbuild! (with Sunil Pai)” (Jason Lengstorf)
• Through the pipeline: an exploration of frontend bundlers (Andrew Walpole)

Other new JavaScript tooling to check out

• Rome – A full toolchain including linting, compiling, bundling, test-running and formatting
• SWC – A rust-based JavaScript/TypeScript compiler
• Deno – A runtime for JavaScript and TypeScript (similar to Node.js)

Atas ialah kandungan terperinci Membandingkan alat pembina generasi baru. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!