Empat era rangka kerja JavaScript

Pada tahun 2012, saya mula mengekod terutamanya dalam JavaScript. Saya pernah membina aplikasi PHP, CMS asas dan tapak web dari awal hingga akhir untuk perniagaan tempatan, dan syarikat memutuskan mereka mahu menulis semula dan menambah beberapa fungsi.

Pengurus projek mahu saya menggunakan .NET, sebahagiannya kerana itu yang dia tahu, tetapi juga kerana dia mahu apl itu berasa seperti orang asli Program aplikasi - Tidak menunggu lama untuk muat semula halaman atau tindakan operasi. Selepas beberapa penyelidikan dan prototaip, saya meyakinkan pengurus saya bahawa saya boleh melakukan perkara ini menggunakan rangka kerja JS baharu yang baru mula muncul pada masa itu.

Rangka kerja pertama yang saya pilih sebenarnya Angular 1. Setelah membina aplikasi yang agak besar dan menggunakan bahagian belakang FuelPHP sebelum saya menghadapi beberapa masalah dengan penghala - ia akan berkelip apabila laluan/outlet kanak-kanak dipaparkan semula dan ia benar-benar merasakan ia sedang direka Senario ini tidak dipertimbangkan pada masa itu .

Kemudian, seseorang mengesyorkan Ruby on Rails + Ember kepada saya Selepas mencubanya, saya fikir ia sangat berkesan. Saya juga suka idea kedua-dua rangka kerja, saya suka ekologi komuniti ini, dan secara keseluruhan ia sangat produktif berbanding dengan alternatif pada masa itu.

Banyak yang telah berubah sejak itu - rangka kerja telah muncul satu demi satu dan telah banyak berkembang. Idea bahawa anda boleh membina aplikasi dengan JavaScript dalam penyemak imbas berubah dari sedikit kepada amalan biasa. Infrastruktur yang kami bina telah berubah sepenuhnya, membolehkan satu set kemungkinan baharu.

Pada masa ini, terdapat juga sedikit persaingan dan konflik antara pelbagai idea. Rangka kerja JavaScript mana yang hendak digunakan, cara menulis CSS, pengaturcaraan berorientasikan fungsi lwn. berorientasikan objek, cara mengurus keadaan terbaik, sistem atau alat binaan mana yang paling fleksibel dan pantas, dsb. Melihat ke belakang, sungguh melucukan bagaimana kita sering berhujah tentang perkara yang salah dan mengabaikan beberapa pertimbangan yang berpandangan ke hadapan.

Jadi saya ingin melakukan retrospektif, melihat kembali beberapa dekad pembangunan JavaScript yang lalu dan melihat sejauh mana kita telah melangkah. Secara kasar kita boleh membahagikannya kepada empat era utama. :

• Era asal
• Rangka kerja pertama
• Lapisan paparan berpusatkan komponen
• Rangka kerja tindanan penuh

Setiap era mempunyai tema dan konflik terasnya sendiri Pada masa yang sama, mereka juga ingin mempelajari pelajaran penting dan bergerak ke hadapan dengan mantap.

Hari ini, perbahasan diteruskan. Adakah web menjadi terlalu kembung? Adakah rata-rata tapak web benar-benar perlu ditulis dalam React? Patutkah kita menggunakan JavaScript? Sudah tentu, masa kini tidak boleh mewakili masa depan, dan rangka kerja yang sedia ada kemungkinan besar akan diganti pada masa hadapan Walau bagaimanapun, ia juga berdasarkan beberapa perspektif sedia ada untuk membantu kami bergerak ke hadapan.

Tahun Asal

JavaScript pertama kali dikeluarkan pada tahun 1995. Seperti yang saya nyatakan di atas, saya mula menulis JS pada tahun 2012, hampir 20 tahun kemudian, berhampiran permulaan apa yang saya panggil era rangka kerja pertama. Anda boleh mengandaikan bahawa saya mungkin menyingkap banyak sejarah di sini, dan bahawa era ini mungkin dipecahkan kepada banyak sub-era, masing-masing dengan corak, perpustakaan, alat binaan, dsb.

Dalam erti kata lain, saya tidak boleh menulis tentang perkara yang belum saya alami. Apabila saya mula menulis aplikasi bahagian hadapan, rangka kerja generasi baharu baru mula matang. Angular.js, Ember.js, Backbone dan banyak lagi.

Sebelum ini, teknologi paling canggih ialah perpustakaan seperti jQuery dan MooTools. Perpustakaan ini penting pada zaman mereka - ia membantu melancarkan perbezaan dalam cara pelayar melaksanakan JavaScript yang penting.

Sebagai contoh, cara IE melaksanakan acara adalah berbeza sepenuhnya daripada Netscape - acara menggelegak dan menangkap acara. Itulah sebabnya standard kami hari ini akhirnya melaksanakan kedua-duanya, tetapi sehingga itu kami perlu menggunakan perpustakaan untuk menulis kod yang berfungsi pada kedua-dua penyemak imbas.

Perpustakaan ini digunakan terutamanya untuk membuat komponen antara muka pengguna yang kecil dan bebas. Kebanyakan logik perniagaan aplikasi masih dilakukan melalui borang dan permintaan HTTP standard - HTML diberikan pada pelayan dan disampaikan kepada pelanggan.

Tiada alat binaan pada zaman ini, sekurang-kurangnya yang saya tahu. JavaScript pada masa itu tidak mempunyai modul (sekurang-kurangnya bukan modul standard), jadi tiada cara untuk mengimport kod. Segala-galanya adalah global, dan sangat sukar untuk mengaturnya.

Dalam persekitaran ini, dapat difahami bahawa JS sering dilihat sebagai bahasa mainan dan bukannya sesuatu yang anda gunakan untuk menulis aplikasi lengkap. Perkara yang paling biasa yang kami lakukan ketika itu ialah membuang dalam jQuery, menulis beberapa skrip untuk beberapa widget UI, dan kemudian itu sahaja.

Seiring dengan berlalunya masa dan XHR diperkenalkan dan dipopularkan, orang ramai mula meletakkan sebahagian daripada proses UI mereka ke dalam halaman, terutamanya untuk proses kompleks yang memerlukan berbilang interaksi bolak-balik antara pelanggan dan pelayan aplikasi kekal pada pelayan.

Ini sangat berbeza dengan apabila apl mudah alih mula muncul. Sejak awal, apl mudah alih pada iOS dan Android telah menjadi aplikasi lengkap yang ditulis dalam bahasa bukan karut™ seperti Objektif C dan Java. Selain itu, ia didorong sepenuhnya oleh API - semua logik UI ada pada peranti dan komunikasi dengan pelayan adalah semata-mata dalam format data. Ini membawa kepada pengalaman pengguna yang lebih baik dan letupan apl mudah alih, yang membawa terus kepada perdebatan yang kita ada hari ini tentang sama ada mudah alih atau web adalah lebih baik.

Melakukan semua ini dalam JavaScript pada mulanya dianggap tidak masuk akal. Tetapi lama kelamaan, aplikasi mula menjadi lebih bercita-cita tinggi. Rangkaian sosial menambahkan sembang, DM dan ciri masa nyata yang lain, Gmail dan Google Docs menunjukkan bahawa aplikasi desktop yang setara boleh ditulis dalam penyemak imbas dan semakin banyak syarikat beralih kepada menulis aplikasi web kerana web berfungsi di mana-mana dan lebih Mudah panjang. -penyelenggaraan jangka masa. Ini mendorong seluruh industri ke hadapan - kini jelas bahawa JS boleh digunakan untuk menulis aplikasi bukan remeh.

Pada masa itu JavaScript tidak mempunyai semua ciri yang ada pada hari ini, semuanya bersifat global dan biasanya memerlukan memuat turun dan menambah setiap pustaka luaran secara manual pada folder statik. NPM belum wujud lagi, modul belum wujud dan JS tidak mempunyai separuh fungsi yang ada padanya hari ini.

Dalam kebanyakan kes, setiap aplikasi disesuaikan, setiap halaman mempunyai tetapan pemalam yang berbeza dan setiap pemalam mempunyai sistem yang berbeza untuk mengurus kemas kini keadaan dan pemaparan. Untuk menyelesaikan masalah ini, rangka kerja JavaScript terawal mula muncul.

Rangka Kerja Pertama

Sekitar akhir 2000-an dan awal 2010-an, rangka kerja JS pertama yang direka khusus untuk menulis aplikasi sisi klien yang lengkap mula muncul. Beberapa rangka kerja terkenal dalam era ini:

1. Backbone.js
2. Angular 1
3. Knockout.js
4. SproutCore
5. Ember .js
6. Meteor.js

Sudah tentu, terdapat banyak lagi, dan mungkin ada yang lebih besar dalam sesetengah kalangan. Ini adalah yang saya ingat, terutamanya kerana Xiao Ming menggunakannya untuk kod dan ia agak popular.

Ini ialah rangka kerja generasi yang memasuki wilayah yang belum dipetakan. Di satu pihak, apa yang mereka cuba lakukan adalah sangat bercita-cita tinggi, dan ramai yang menyangka ia tidak akan berjaya.

Terdapat ramai penentang yang berpendapat bahawa Aplikasi JS Halaman Tunggal (SPA) pada asasnya lebih teruk, dan dalam banyak cara ia betul - pemaparan sebelah pelanggan bermakna robot tidak boleh merangkak halaman ini dengan mudah dan Pengguna perlu menunggu beberapa saat sebelum aplikasi boleh mula melukis. Kebanyakan apl ini adalah mimpi ngeri kebolehaksesan dan tidak berfungsi sama sekali jika JavaScript dimatikan.

Sebaliknya, kami tidak mempunyai pengalaman membina aplikasi lengkap dalam JS, jadi terdapat banyak idea yang bersaing tentang pendekatan terbaik. Kebanyakan rangka kerja cuba meniru apa yang popular pada platform lain, jadi hampir kesemuanya akhirnya menjadi beberapa lelaran Model-View-*. Model-View-Controller, Model-View-Producer, Model-View-ViewModel dan sebagainya. Tetapi dalam jangka panjang, ini tidak benar-benar berjaya - mereka tidak begitu intuitif, dan ia menjadi sangat rumit dengan cepat.

Ini juga merupakan era apabila kami benar-benar mula bereksperimen dengan cara menyusun aplikasi JavaScript. Node.js telah dikeluarkan pada tahun 2009, dan NPM diikuti pada tahun 2010, memperkenalkan pakej untuk JavaScript (sebelah pelayan).

CommonJS dan AMD memperjuangkan cara terbaik mentakrifkan modul JS, sementara membina alatan seperti Grunt, Gulp dan Broccoli memperjuangkan cara menggabungkan modul ini menjadi produk akhir yang boleh dihantar.

Sebagian besar, ini adalah alat gaya pelari tugas yang sangat umum yang benar-benar boleh membina apa sahaja yang kebetulan sedang membina JavaScript -- tetapi juga HTML, CSS/SASS/LESS dan banyak perkara lain yang digunakan ke dalam aplikasi web.

Walau bagaimanapun, kami telah belajar banyak daripada era ini:

• Penghalaan berasaskan URL ialah asasnya. Aplikasi tanpa penghalaan ini memecahkan web, jadi ini perlu diambil kira dalam rangka kerja dari awal.
• Melanjutkan HTML melalui bahasa templat ialah lapisan abstraksi yang berkuasa. Walaupun kadang-kadang ia boleh menjadi agak kikuk, ia memudahkan untuk memastikan antara muka pengguna selari dengan keadaan.
• Prestasi SPA sangat lemah, dan web mempunyai banyak had tambahan yang tidak ada pada aplikasi asli. Kami perlu menerbitkan semua kod melalui web, mempunyai JIT, dan kemudian menjalankannya untuk melancarkan aplikasi kami sementara aplikasi tempatan telah dimuat turun dan disusun, yang merupakan tugas yang sukar.
• Sebagai bahasa, JavaScript mempunyai banyak masalah dan ia benar-benar perlu dipertingkatkan untuk menjadikan sesuatu lebih baik - rangka kerja tidak boleh melakukannya bersendirian.
• Kami sememangnya memerlukan alat binaan, modul dan pembungkusan yang lebih baik untuk menulis aplikasi pada skala.

Secara keseluruhannya, era ini telah produktif. Walaupun terdapat kelemahan, apabila kerumitan aplikasi bertambah, faedah menyahgandingan pelanggan daripada API adalah besar, dan dalam banyak kes, pengalaman pengguna yang terhasil adalah menakjubkan. Melainkan terdapat keadaan khusus, era ini mungkin berterusan dan kami masih meneruskan idea gaya MV*.

Tetapi kemudian asteroid tiba-tiba muncul, menghancurkan paradigma sedia ada menjadi kepingan, menyebabkan peristiwa kepupusan berskala kecil, dan mendorong kita ke era seterusnya - asteroid ini dipanggil React.

Lapisan paparan tertumpu komponen

Saya tidak fikir React rekaan komponen, tetapi sejujurnya, saya tidak pasti dari mana asalnya. Tetapi ia kembali sekurang-kurangnya kepada XAML dalam .NET, dan ketika itulah komponen web mula berkembang sebagai spesifikasi. Akhirnya ia tidak penting - sebaik sahaja idea itu muncul, setiap rangka kerja utama mengguna pakainya dengan cepat.

Jika difikirkan semula, ini benar-benar masuk akal - lanjutkan HTML, kurangkan keadaan jangka panjang, ikat logik perniagaan JS terus ke templat (sama ada JSX atau Bar Hendal atau Arahan).

Aplikasi berasaskan komponen menghapuskan kebanyakan abstraksi yang diperlukan untuk menyelesaikan kerja dan memudahkan kitaran hayat kod dengan ketara - semuanya terikat pada kitaran hayat komponen berbanding kitaran hayat aplikasi Bersama-sama, ini bermakna anda mempunyai lebih sedikit perkara untuk fikirkan sebagai pemaju.

Walau bagaimanapun, terdapat juga peralihan pada masa itu: rangka kerja itu mula menggembar-gemburkan dirinya sebagai "lapisan pandangan" dan bukannya rangka kerja penuh. Daripada menyelesaikan semua masalah yang diperlukan untuk aplikasi bahagian hadapan, mereka menumpukan pada menyelesaikan masalah rendering.

Isu lain seperti penghalaan, komunikasi API dan pengurusan keadaan diserahkan kepada pengguna untuk membuat keputusan. Rangka kerja yang terkenal pada era ini termasuk:

1. React.js
2. Vue.js
3. Svelte
4. Polymer.js

Ada banyak lagi. Mengimbas kembali sekarang, saya rasa ini adalah rangka kerja yang popular di kalangan rangka kerja generasi kedua kerana ia benar-benar melakukan dua perkara utama.

• Ia mengecilkan skop secara mendadak. Daripada cuba menyelesaikan semua masalah ini secara awal, teras rangka kerja tertumpu pada pemaparan, dan banyak idea serta hala tuju berbeza boleh diterokai untuk ciri lain dalam ekosistem yang lebih luas. Terdapat banyak penyelesaian yang tidak baik, tetapi terdapat juga penyelesaian yang baik, membuka jalan kepada generasi akan datang untuk memilih idea terbaik daripada krim.
• Ini memudahkan kita menerimanya. Mengguna pakai rangka kerja lengkap untuk mengambil alih keseluruhan halaman web anda bermakna menulis semula kebanyakan aplikasi anda, yang tidak boleh dilakukan dengan monolit sebelah pelayan sedia ada. Menggunakan rangka kerja seperti React dan Vue, anda boleh menggugurkan cebisan kecilnya ke dalam aplikasi sedia ada satu widget atau komponen pada satu masa, membolehkan pembangun memindahkan kod sedia ada mereka secara berperingkat.

Kedua-dua faktor ini membawa kepada perkembangan pesat rangka kerja generasi kedua, mengatasi rangka kerja generasi pertama Dari jauh, semuanya kelihatan masuk akal dan merupakan evolusi yang munasabah. Tetapi berada di dalamnya pada masa itu adalah pengalaman yang cukup mengecewakan.

Pertama sekali, apabila kita membahaskan rangka kerja yang hendak digunakan di tempat kerja, atau sama ada kita perlu menulis semula aplikasi kita, kita jarang menghadapi rangka kerja sedemikian. Sebaliknya, banyak kali ia adalah "Ia lebih cepat!" atau "Ia lebih kecil!".

Terdapat juga perdebatan tentang Pengaturcaraan Fungsian dan Pengaturcaraan Berorientasikan Objek, dengan ramai orang menunjuk kepada FP sebagai penyelesaian kepada semua masalah kami. Untuk bersikap adil, perkara-perkara ini adalah benar. Bingkai lapisan lihat sahaja adalah lebih kecil (pada mulanya), lebih pantas (pada mulanya) dan semua yang anda perlukan (jika anda membina atau menjahit sendiri banyak bahan).

Sudah tentu, corak pengaturcaraan berfungsi menyelesaikan banyak masalah yang melanda JavaScript, dan saya fikir, secara purata, JS lebih baik kerana mereka.

Namun, realitinya tiada peluru ajaib. Aplikasi masih besar, kembung dan kompleks, keadaan masih sukar untuk diurus, dan isu asas seperti penghalaan dan SSR masih perlu diselesaikan.

Bagi kebanyakan kita, apa yang orang mahukan ialah meninggalkan penyelesaian yang cuba menyelesaikan semua masalah ini dan menggantikannya dengan penyelesaian yang membuatkan pembaca memikirkannya sendiri.

Menurut pengalaman saya, ini juga merupakan amalan biasa di kalangan kumpulan kejuruteraan yang dengan senang hati akan menerima perubahan ini untuk menyampaikan produk atau ciri baharu dan kemudian tidak membiayai pembangunan penuh semua ciri tambahan yang memerlukan masa.

Hasilnya ialah rangka kerja buatan sendiri yang dibina di sekeliling lapisan paparan ini, yang dengan sendirinya membengkak, kompleks dan sangat sukar untuk digunakan.

Saya rasa banyak masalah yang dihadapi oleh orang ramai dengan SPA datang daripada ekosistem yang berpecah-belah ini, yang telah muncul ketika penggunaan SPA semakin meletup. Saya masih sering menjumpai tapak web baharu yang tidak melakukan penghalaan dengan betul atau mengendalikan butiran kecil lain dengan baik, dan ia benar-benar mengecewakan.

Tetapi sebaliknya, rangka kerja perkhidmatan penuh generasi pertama yang sedia ada tidak berfungsi dengan baik dalam menyelesaikan masalah ini. Sebahagian daripada ini adalah disebabkan oleh banyak bagasi hutang teknikal. Rangka kerja generasi pertama telah dibina sebelum ES6, sebelum modul, sebelum Babel dan Webpack, sebelum kami mengetahui banyak perkara.

Evolusi berulang adalah sangat sukar, dan menulis semula sepenuhnya, seperti Angular lakukan dengan Angular 2, membunuh momentum komuniti mereka.

Jadi apabila ia berkaitan dengan rangka kerja JavaScript, pembangun berada dalam dilema - sama ada memilih penyelesaian semua-dalam-satu yang mula menunjukkan usianya, atau melompat ke separuh percuma untuk semua dan DIY rangka kerja dengan harapan mendapat hasil yang terbaik.

Ini sangat mengecewakan pada masa itu, tetapi akhirnya membawa kepada banyak inovasi. Ekosistem JavaScript telah berkembang dengan sangat cepat, dan beberapa perubahan penting lain telah berlaku apabila rangka kerja ini mengetahui amalan terbaik mereka.

• Transpiler seperti Babel menjadi kebiasaan dan membantu memodenkan bahasa. Daripada menunggu bertahun-tahun untuk ciri diseragamkan, ia boleh digunakan hari ini, dan bahasa itu sendiri mula menambah ciri pada kadar yang lebih pantas dan lebih berulang.
• Modul ES telah diseragamkan supaya kami akhirnya mula membina alat binaan moden di sekelilingnya, seperti Rollup, Webpack dan Parcel. Himpunan berasaskan import perlahan-lahan menjadi kebiasaan, walaupun untuk sumber bukan JS seperti gaya dan imej, yang sangat memudahkan konfigurasi alat binaan, menjadikannya lebih ramping, lebih pantas dan lebih komprehensif.
• Memandangkan semakin banyak API diseragamkan, jurang antara piawaian Node dan web semakin perlahan tetapi berterusan. SSR mula menjadi kemungkinan sebenar dan kemudian sesuatu yang dilakukan oleh setiap aplikasi serius, tetapi setiap kali ia adalah persediaan tersuai.
• Pengkomputeran Edge dilancarkan, memberikan aplikasi pelayan berasaskan JavaScript faedah pengedaran/masa tindak balas SPA (Spas sebelum ini biasanya mula memuatkan lebih cepat kerana menjadi fail statik pada CDN, Walaupun ia mengambil masa yang lebih lama untuk memuatkan sepenuhnya dan akhir).

Pada penghujung era ini, beberapa persoalan masih kekal. Pengurusan negeri dan responsif adalah (dan masih) isu yang sukar, walaupun kita mempunyai model yang lebih baik daripada sebelumnya.

Prestasi masih menjadi isu yang sukar dan walaupun keadaan bertambah baik, masih terdapat banyak, banyak SPA yang membengkak di luar sana.

Situasi kebolehcapaian juga telah bertambah baik, tetapi bagi kebanyakan organisasi kejuruteraan, ia masih sering difikirkan semula. Tetapi perubahan ini membuka jalan untuk rangka kerja generasi akan datang, yang saya katakan kita sedang memasukinya.

Rangka kerja tindanan penuh

Secara peribadi, era rangka kerja terakhir telah tiba dengan senyap. Saya fikir ia adalah kerana saya telah menghabiskan 4 tahun yang lalu atau lebih mendalami bahagian dalaman lapisan pemaparan Ember, cuba menyelesaikan hutang teknikal yang disebutkan di atas yang menjejaskannya sebagai rangka kerja generasi pertama (masih). Tetapi ini juga kerana ia lebih halus kerana semua rangka kerja generasi ketiga ini dibina di sekeliling rangka kerja lapisan paparan generasi sebelumnya. Rangka kerja ini termasuk:

1. Next.js (React)
2. Nuxt.js (Vue)
3. Remix (React)
4. SvelteKit (Svelte )
5. Gatsby (React)
6. Astro (Any)

Rangka kerja ini bermula apabila lapisan paparan matang dan disatukan. Sekarang kita semua bersetuju bahawa komponen dibina di atas teras, masuk akal untuk mula menyeragamkan bahagian lain aplikasi - penghala, sistem binaan, struktur folder, dsb.

Perlahan-lahan, rangka kerja meta ini mula membina keupayaan yang sama di luar kotak sebagai penyelesaian semua-dalam-satu generasi pertama, memilih corak terbaik dari ekosistem masing-masing dan berkembang apabila ia matang Dan menggabungkannya.

Kemudian mereka pergi selangkah lebih jauh.

Sebelum ini SPA hanya fokus kepada pelanggan sahaja. SSR ialah sesuatu yang ingin diselesaikan oleh setiap rangka kerja, tetapi hanya sebagai pengoptimuman, cara untuk diberikan dan akhirnya diganti apabila megabait JS akhirnya dimuatkan.

Hanya satu rangka kerja generasi pertama yang berani berfikir lebih jauh, Meteor.js, tetapi idea JS isomorfiknya tidak pernah benar-benar menjadi kenyataan.

Tetapi apabila aplikasi berkembang dalam saiz dan kerumitan, idea itu telah dikaji semula.

Kami mendapati bahawa ia sebenarnya sangat berguna untuk menggandingkan bahagian belakang dan bahagian hadapan bersama-sama supaya anda boleh melakukan perkara seperti menyembunyikan rahsia API untuk permintaan tertentu, mengubah suai fail pengepala apabila mengembalikan halaman, permintaan API Proksi. Memandangkan Node dan Deno melaksanakan semakin banyak piawaian web, dan jurang antara JS bahagian pelayan dan JS pihak pelanggan semakin mengecil setiap tahun, ia mula kelihatan seperti idea yang tidak gila. Gabungkan itu dengan pengkomputeran tepi dan alatan yang menakjubkan, dan terdapat beberapa potensi yang luar biasa.

Rangka kerja generasi terbaharu memanfaatkan sepenuhnya potensi ini, menggabungkan pelanggan dan pelayan dengan lancar, dan saya tidak boleh menekankan betapa hebatnya perasaan ini. Sepanjang 9 bulan yang lalu bekerja dengan SvelteKit, saya tidak dapat memberitahu anda berapa kali saya duduk dan berkata kepada diri saya sendiri, "Inilah yang harus kita lakukan sepanjang masa."

Ini beberapa tugasan yang saya temui baru-baru ini, Dengan persediaan ini, tugasan ini menjadi sangat mudah.

• Menambahkan OAuth sebelah pelayan pada aplikasi kami supaya token pengesahan tidak pernah meninggalkan pelayan, serta proksi API yang menambahkan token apabila membuat permintaan kepada API kami.
• Proksi laluan tertentu terus ke CDN kami supaya kami boleh mengehoskan halaman HTML statik yang dibina dalam mana-mana rangka kerja lain, membenarkan pengguna membuat halaman tersuai mereka sendiri (perkhidmatan yang kami sediakan untuk sesetengah pelanggan).
• Tambahkan beberapa laluan API sekali yang berbeza apabila kami perlu menggunakan perkhidmatan luaran yang memerlukan kunci (tidak perlu menambah laluan baharu sepenuhnya pada API kami dan berkoordinasi dengan orang bahagian belakang).
• Mengalihkan penggunaan LaunchDarkly kami ke bahagian pelayan supaya kami boleh memuatkan lebih sedikit JS, sekali gus mengurangkan kos keseluruhan.
• Proksi permintaan Sentry kami melalui penghalaan bahagian belakang supaya kami dapat menangkap ralat yang tidak dilaporkan disebabkan oleh penyekat iklan.

Dan ini hanyalah puncak gunung ais. Terdapat banyak perkara menarik tentang corak ini, yang terbesar ialah bagaimana ia menyegarkan semula idea peningkatan progresif, memanfaatkan gabungan ciri pelayan dan pelanggan untuk membolehkan pelanggan kembali ke asas jika pengguna melumpuhkan JavaScript HTML + HTTP.

Apabila saya mula bekerja di spa, saya sendiri telah berputus asa sepenuhnya dengan amalan ini memikirkan ia adalah trend masa depan, tetapi sungguh menarik bahawa kita berpotensi melihat dunia di mana ia membuat kemunculan semula.

Ini adalah ciri baharu daripada pengalaman, saya mengklasifikasikan rangka kerja ini sebagai rangka kerja generasi baharu. Masalah yang sebelum ini sukar atau mustahil untuk diselesaikan kini menjadi remeh, hanya memerlukan sedikit perubahan dalam logik pemprosesan tindak balas.

Prestasi yang boleh dipercayai dan pengalaman pengguna keluar dari kotak dan tidak memerlukan sebarang konfigurasi tambahan. Daripada membina keseluruhan perkhidmatan baharu, kami boleh menambah beberapa titik akhir tambahan atau perisian tengah mengikut keperluan. Ini telah mengubah hidup.

Saya rasa generasi ini turut menyelesaikan beberapa perkara utama konflik antara rangka kerja generasi pertama dan kedua dan penggunanya.

Ia bermula dengan peralihan ke arah terminologi konfigurasi sifar, tetapi saya fikir ia akhirnya didorong oleh kematangan dan kestabilan ekosistem di sekitar rangka kerja generasi kedua, yang juga merupakan anjakan budaya.

Rangka kerja generasi ketiga kini cuba untuk menjadi penyelesaian semua-dalam-satu sekali lagi, cuba menyelesaikan semua masalah asas yang perlu kami selesaikan oleh pembangun bahagian hadapan - bukan hanya rendering.

Kini, lebih daripada sebelumnya, rasanya masyarakat sejajar dengan semua isu yang melanda SPA dan, yang penting, menyelesaikannya bersama-sama.

Kita hendak ke mana seterusnya?

Secara keseluruhan, saya rasa komuniti JavaScript sedang bergerak ke arah yang betul. Kami akhirnya telah membangunkan penyelesaian matang untuk membina aplikasi lengkap dari awal yang bukan "sekadar lapisan paparan".

Kami akhirnya mula bersaing pada garis permulaan yang sama seperti SDK apl asli, menyediakan kit alat lengkap di luar kotak.

Kami masih mempunyai banyak kerja untuk dilakukan di kawasan ini. Kebolehcapaian telah lama menjadi pertimbangan dalam dunia SPA, dan di luar GraphQL saya masih berpendapat cerita data boleh menggunakan beberapa kerja (suka atau tidak, kebanyakan web masih berjalan pada REST).

Tetapi trendnya betul, dan jika kita terus bergerak ke arah penyelesaian bersama, saya fikir kita boleh menyelesaikan masalah ini dengan cara yang lebih baik daripada sebelumnya.

Saya juga teruja dengan potensi di sebalik meningkatkan lagi corak ini ke dalam platform web itu sendiri. Komponen web masih diulang secara senyap-senyap, mengusahakan isu seperti SSR dan menyingkirkan pendaftaran global, yang akan menjadikannya lebih serasi dengan rangka kerja generasi ketiga ini.

Di arah lain, WebAssembly boleh mengulangi corak ini dengan cara yang luar biasa. Bayangkan anda boleh menulis rangka kerja timbunan penuh dalam mana-mana bahasa.

Bahasa isomorfik seperti Rust, Python, Swift, Java, dsb. akhirnya boleh mengurangkan halangan antara bahagian hadapan dan bahagian belakang kepada hampir sifar -- hanya sedikit templat HTML di tepi sistem anda (yang ironisnya menjadikan Kami hampir mencapai bulatan penuh, walaupun dengan pengalaman pengguna yang lebih baik).

Harapan terbesar saya di sini ialah kita melangkah melepasi era pemecahan dan era rangka kerja JS baharu setiap hari. Kebebasan dan fleksibiliti menjana inovasi, tetapi ia juga membawa kepada pengalaman yang mengelirukan, terputus hubungan dan sering rosak secara asasnya di web.

Apabila pembangun perlu memilih antara 50+ pilihan dan menggabungkannya bersama-sama dengan sumber yang terhad dan tarikh akhir yang ketat, ini adalah pengalaman yang kami lihat dan ia masuk akal. Sesetengah apl adalah pantas, konsisten, boleh dipercayai dan menyeronokkan untuk digunakan, manakala yang lain mengecewakan, mengelirukan, perlahan dan rosak.

Jika kami boleh memberikan alat pembangun yang lebih mudah digunakan dan melakukan perkara yang betul secara lalai, mungkin tapak web secara umum akan menjadi lebih baik dan pengalaman secara amnya akan menjadi lebih lancar.

Ia tidak akan membetulkan setiap tapak web – tiada jumlah kod boleh membetulkan reka bentuk UX yang lemah. Tetapi ia akan meletakkan asas yang sama, jadi setiap tapak web bermula dengan lebih baik sedikit dan setiap pembangun mempunyai lebih banyak masa untuk memberi tumpuan kepada perkara lain.

Atas ialah kandungan terperinci Empat era rangka kerja JavaScript. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!