Evolusi Teknologi Web dan Penyemak Imbas

Hei, sana! Pernahkah anda terfikir bagaimana sebenarnya web berfungsi dan apa yang sebenarnya berlaku apabila anda memasukkan URL dalam pelayar misteri anda itu? Jangan risau, anda tidak bersendirian — kebanyakan daripada kami menganggap web sebagai sejenis kotak hitam. Tetapi oleh kerana anda telah mengklik pada blog ini, saya rasa anda mungkin ingin mengintip ke dalam. Itu hebat! Rasa ingin tahu mungkin telah membunuh kucing itu, tetapi bagi pembangun, ia adalah sos rahsia.

Walaupun anda tahu sedikit tentang cara ia berfungsi, anda mungkin masih mempersoalkan mengapa ia berkembang dengan cara ini. Saya percaya bahawa "untuk memahami masa kini dan meramalkan atau mempengaruhi masa depan, kita perlu mengetahui masa lalu". Atau seperti yang dicadangkan oleh sesetengah pihak, hum kronologi samajhna chahiye! Jadi mari kita menelusuri evolusi teknologi web dan penyemak imbas, membahagikannya kepada empat fasa yang dipermudahkan untuk kejelasan. Pada penghujung perjalanan ini, anda akan memahami bukan sahaja cara teknologi web berkembang, tetapi juga perkara yang berlaku di bawah hud, sebab perubahan ini berlaku dan maksudnya untuk masa depan web.

Nota : Ini bukan garis masa yang tepat tetapi lebih kepada fasa yang dipermudahkan untuk membantu pemahaman.

Fasa Sifar: Web Prasejarah

Mari kita undur ke masa sebelum 1980-an

Bayangkan sekumpulan penyelidik berkeliaran di sekitar universiti di A.S., meletakkan wayar fizikal antara komputer untuk memindahkan atau berkongsi data. Perintis teknologi ini menubuhkan protokol seperti FTP (Protokol Pemindahan Fail) dan SMTP (Protokol Pemindahan Mel Mudah) untuk berkongsi fail dan menghantar e-mel — kebanyakannya mengenai eksperimen terobosan mereka dan mungkin gosip pejabat sekali-sekala. Dahulu terdapat pelayan yang boleh kami sambungkan melalui klien jauh dan menyimpan atau mengambil fail pada cakera menggunakan arahan bertulis.

Ini bagus untuk jumlah data yang kecil, tetapi apabila data berkembang lebih cepat dan lebih pantas, mencari maklumat khusus menjadi sakit kepala. Mendapatkan semula data diperlukan mengetahui laluan yang tepat, alamat pelayan, dan mungkin melakukan sedikit tarian untuk menenangkan tuhan komputer. Maklumat berharga berisiko hilang dalam shuffle digital, bertaburan di seluruh pelayan seperti stoking hilang dalam pusaran dobi.

Fasa Pertama: Kelahiran Web

Masuk akhir 1980-an dan awal 1990-an

Along datang seorang rakan British yang cemerlang bernama Sir Tim Berners-Lee. Beliau menulis cadangan yang dipanggil Pengurusan Maklumat: Cadangan. Di mana beliau bercakap tentang menggunakan sistem teks bukan linear yang dikenali sebagai "hiperteks", yang bermaksud teks yang merangkumi pautan kepada maklumat berkaitan yang disambungkan seperti sarang labah-labah gergasi. Jadi menavigasi dan meneroka melalui data berkaitan adalah lebih mudah dan kehilangan maklumat akan diminimumkan!

Dalam cadangan ini, beliau juga merujuk komputer yang saling berkaitan sebagai "web". Dan seperti itu, World Wide Web dilahirkan! Dia tidak berhenti di situ; dia terus mencipta HyperText Transfer Protocol (HTTP), membangunkan penyemak imbas pertama, dengan nama yang menawan WorldWideWeb (kemudian dijenamakan semula sebagai Nexus), pelayan web HTTP pertama dan tapak web pertama. Bercakap tentang pencapaian yang melampau!

• HTTP (HyperText Transfer Protocol): Satu set peraturan, sintaks dan semantik yang digunakan untuk pemindahan maklumat antara klien (cth., pelayar web anda) dan pelayan web (the komputer jauh mengehos tapak web). Jika anda tertanya-tanya tentang nama itu, pada mulanya ia hanya bertujuan untuk pemindahan fail HTML. Tetapi ia berkembang untuk menyokong pemindahan semua jenis data dalam versi kemudian, selepas pengenalan pengepala, terutamanya pengepala Jenis Kandungan.
  
  

• Pelayan Web HTTP : Komputer yang boleh memahami protokol HTTP ini. Tugas utama ini adalah untuk menghuraikan permintaan dan menyampaikan respons yang diminta, pada masa ini kebanyakannya fail HTML, CSS, JPG statik.

Ini adalah apabila HTML (Hypertext Markup Language) mula dimainkan, menggabungkan idea hiperteks dengan SGML (Standard Generalized Markup Language), yang kemudiannya digunakan untuk memformat dokumen. Versi pertama HTML adalah agak asas — ia menyokong tajuk, perenggan, senarai dan pautan. Tiada fon mewah atau animasi mencolok — hanya yang penting.

Untuk beberapa tahun pertama, web adalah seperti kelab eksklusif untuk penyelidik dan ahli akademik. Kemudian beberapa orang bijak membangunkan penyemak imbas yang dipanggil Mozek, yang boleh memaparkan imej. Ya, imej! Ini menjadikan web lebih mudah diakses oleh orang awam kerana, mari kita hadapi, gambar bernilai seribu baris (tiada gambar dalam blog ini?)!

Di bawah Hud Pelayar

Jadi, mari kita lihat apa yang berlaku dalam penyemak imbas ini dengan keupayaan yang lebih tinggi

Antara Muka Pengguna : Setiap penyemak imbas mempunyai bar navigasi di bahagian atas tempat semua tab terbuka anda (atau tetingkap ketika itu) kelihatan. Di bawahnya ialah bar alamat tempat anda memasukkan alamat tapak web. Di bawah itu adalah tempat (viewport) di mana kandungan laman web yang anda masukkan akan dipaparkan. Ingat, ini sebelum enjin carian, jadi jika anda tidak mengetahui alamat yang tepat, anda tidak bernasib baik — seperti cuba mencari tempat tanpa GPS atau peta.

Mengambil Data : Apabila anda memasukkan alamat tapak web, Modul Rangkaian penyemak imbas akan mengambil data dengan melaksanakan tugas seperti resolusi DNS dan mewujudkan sambungan selamat dengan pelayan untuk memulakan komunikasi. Penyemak imbas kemudiannya akan menerima data dalam bentuk HTML daripada pelayan.

Enjin Rendering : Enjin rendering akan mula menghuraikan HTML. Jika ia menemui teg yang memerlukan sumber tambahan, seperti imej () atau gaya (

Kemudian ia akan membina pepohon Model Objek Dokumen (DOM) daripada HTML, di mana setiap teg menjadi nod dalam pepohon. Selepas mengambil dan menghuraikan CSS, ia akan membina Model Objek CSS (CSSOM). Kedua-dua model ini digabungkan untuk mencipta Pokok Render, yang akan digunakan untuk mengetahui perkara yang hendak dipaparkan dan cara untuk memaparkannya.

• Reka Letak dan Lukisan : Seterusnya ialah fasa susun atur, di mana Enjin Rendering mengira saiz dan kedudukan setiap elemen pada halaman. Bermula dari teg relatif kepada viewport (kawasan kelihatan halaman web), ia akan berfungsi melalui Pokok Render. Akhir sekali, dalam fasa mengecat, Enjin Render berkomunikasi dengan API pemaparan sistem pengendalian masing-masing untuk melukis segala-galanya pada skrin.

Hidup dengan Keterbatasan

Menjelang akhir fasa ini, pengguna boleh melihat tapak web statik dan menavigasi halaman. Borang membenarkan interaksi pengguna asas seperti memasukkan teks dan mengklik butang, dan data borang ini biasanya dipindahkan melalui e-mel kepada pembangun. Tetapi inilah tangkapannya: tiada cara untuk menukar kandungan secara dinamik berdasarkan interaksi pengguna. Pengguna hanya boleh mengklik dan menavigasi antara pautan yang disediakan.

Perlu mengemas kini sesuatu? Ambil keseluruhan HTML baharu sekali lagi daripada pelayan. Ingin memaparkan kandungan yang berbeza untuk pengguna yang berbeza? Maaf, tidak berlaku. Anda tidak boleh menaburkan sebarang logik pengaturcaraan — tiada gelung, tiada syarat, tiada apa-apa. Jika anda mahukan menu navigasi pada berbilang halaman, anda perlu menyalin dan menampal kod yang sama di mana-mana sahaja.

Fasa Kedua: Kebangkitan Skrip Bahagian Pelayan

Sekarang mari kita teruskan ke pertengahan hingga akhir 1990-an

Pembangun mula berfikir, "Bagaimana jika kita boleh mencampurkan bahasa pengaturcaraan dengan HTML untuk menambah logik dan menjadikan hidup kita lebih mudah?" Ini membawa kepada kemunculan skrip sisi pelayan. Bahasa seperti Java, PHP dan Python telah dibenamkan ke dalam HTML, membolehkan pembangun menulis kod yang boleh memproses data, membuat keputusan dan menjana HTML secara dinamik. Daripada menyajikan fail HTML statik, pelayan kini boleh menyesuaikan kandungan untuk setiap pengguna.

Bagaimana Ini Mengubah Perkara?

Dari Perspektif Penyemak Imbas : Penyemak imbas masih mengambil dan memaparkan HTML, tetapi kandungan yang diterimanya lebih dinamik. Borang menjadi lebih berkuasa, mampu menghantar data ke titik akhir pelayan menggunakan permintaan POST.

• Caching dan Cookies : Caching menjadi lebih canggih pada penyemak imbas. Mereka menyimpan sumber seperti imej dan helaian gaya secara setempat, mengurangkan keperluan untuk mengambilnya berulang kali. Kuki telah diperkenalkan untuk mengekalkan keadaan melalui protokol HTTP tanpa kewarganegaraan. Mereka membenarkan pelayan menyimpan cebisan kecil data pada bahagian klien, yang dihantar semula dengan permintaan berikutnya. Ini penting untuk perkara seperti mengekalkan sesi, pilihan pengguna, memastikan pengguna dilog masuk — supaya anda tidak perlu memasukkan kata laluan anda setiap kali anda berkelip.

Di Bahagian Pelayan : Pelayan semakin sibuk. Sebelum ini, kami hanya mempunyai Pelayan Web, yang digunakan untuk menyampaikan fail statik. Tetapi pada ketika ini, beberapa lagi perkara telah diperkenalkan seperti Pelayan Aplikasi, Pelayan Pangkalan Data (yang boleh menyimpan katalog produk data pengguna, dan banyak lagi ), dsb. Mereka kini mengendalikan skrip yang boleh memproses input pengguna, berinteraksi dengan pangkalan data dan menjana HTML tersuai . Ini adalah era apabila e-dagang mula berkembang. Syarikat seperti Amazon dan eBay boleh memaparkan produk secara dinamik berdasarkan carian, pilihan dan gelagat pengguna.

• Pelayan Aplikasi : Pelayan web sememangnya tidak boleh menjalankan sebarang skrip, jadi untuk melakukan kerja ini Pelayan aplikasi telah diperkenalkan. Pada asasnya, jenis Pelayan Aplikasi terletak di belakang Pelayan Web. Setiap kali permintaan datang, Pelayan Web menyemak sama ada ini perlu pergi ke Pelayan Aplikasi berdasarkan konfigurasi dan menghantar permintaan itu kepada Pelayan Aplikasi. Pelayan Aplikasi kemudian memproses permintaan, melaksanakan skrip dan menghasilkan fail HTML, yang kemudiannya dipindahkan ke Pelayan Web untuk melayani klien. Jadi pelayan web bertindak seperti proksi terbalik kepada pelayan aplikasi.

Contoh dengan JSP (JavaServer Pages)

Pada zaman kolej saya, saya masih ingat bermain-main dengan projek JSP lama. Skrip ini biasanya mengikut struktur biasa: ia terdiri daripada HTML, dan di mana sahaja logik perlu ditambah, ia dibenamkan menggunakan pengecam khas seperti (tutup) dalam kes JSP. Berikut ialah contoh mudah:

salam.jsp

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

Dalam contoh ini, apabila pengguna menyerahkan nama mereka, pelayan menerima permintaan HTTP yang mengandungi data borang, memproses maklumat dan menjana ucapan yang diperibadikan secara dinamik untuk pengguna. Tiada lagi generik "Hello, World!" Kini "Helo, [Nama Anda]!" — peningkatan ego segera.

Penjanaan Kandungan Dinamik : Daripada senarai pengekodan keras atau kandungan, anda boleh mengambil data daripada pangkalan data dan menggelungkannya atau menggunakannya untuk menjana elemen HTML. Contohnya, memaparkan senarai buah-buahan:

Ini boleh dikembangkan dengan mudah untuk mengambil buah-buahan daripada pangkalan data, menjadikan kandungan anda lebih dinamik dan segar!

Cabaran Baru

Walaupun skrip sebelah pelayan merupakan pengubah permainan, ia bukan tanpa cabarannya.

Muat Semula Halaman Penuh : Setiap kali anda berinteraksi dengan pelayan, seperti menyerahkan borang atau mengklik pautan, seluruh halaman perlu memuat semula kerana sebarang logik hanya boleh dilaksanakan pada pelayan aplikasi, yang dihasilkan HTML baharu. Pengguna terpaksa menunggu pelayan membalas sebelum melihat hasil tindakan mereka. Ini menyebabkan pengalaman pengguna yang tidak begitu hebat.

Muatan Pelayan : Pelayan perlu mengendalikan semua pemprosesan, daripada menjalankan skrip kepada pangkalan data pertanyaan. Apabila tapak web menjadi lebih popular, pelayan bergelut di bawah beban yang meningkat, mengakibatkan peningkatan masa muat dan kelewatan untuk pengguna. Kami tahu bahawa kesabaran adalah satu kebaikan, tetapi ia bukanlah satu yang banyak dimiliki oleh pengguna. Dengan penyemak imbas dan komputer sisi pelanggan menjadi semakin berkebolehan, ia menimbulkan persoalan: mengapa mereka tidak boleh mengambil sebahagian daripada beban kerja untuk meningkatkan prestasi dan responsif?

Fasa Ketiga: Revolusi Sebelah Pelanggan

Masukkan masa apabila pembangun semakin bosan dengan muat semula halaman penuh tersebut. Sudah tiba masanya untuk perubahan, dan perubahan itu datang dalam bentuk skrip sisi klien atau Rendering Sisi Pelanggan (CSR).

JavaScript, yang telah diperkenalkan secara senyap oleh Netscape pada tahun 1995, kini mula mendapat perhatian. Ia membolehkan pembangun melaksanakan kod terus dalam penyemak imbas pengguna, bermakna tidak setiap interaksi perlu melibatkan pelayan. Ini membawa kepada pengalaman web yang lebih lancar dan lebih responsif. Beberapa faktor utama terlibat dalam revolusi ini:

Meningkatkan Keupayaan Penyemak Imbas: Setelah masa berlalu, peranti pengguna menjadi semakin berkuasa — dan begitu juga penyemak imbas. Oleh itu, menjadi jelas untuk memuat turun beberapa kerja dari pelayan ke penyemak imbas, yang meningkatkan pengalaman pengguna secara drastik. Pelayar bukan lagi sekadar penonton dokumen pasif; mereka berkembang menjadi platform yang mampu menjalankan aplikasi yang kompleks.

API Web: Untuk memanfaatkan kuasa baru ditemui ini, penyemak imbas mula menawarkan API Web — satu set fungsi yang membenarkan JavaScript berinteraksi dengan keupayaan penyemak imbas. Beberapa API Web utama yang membantu JavaScript berkembang ialah:

• DOM API menyediakan cara untuk berinteraksi dan memanipulasi struktur dan kandungan halaman web secara dinamik dalam penyemak imbas. Ia juga membenarkan penambahan pendengar acara seperti klik, gerakan tetikus, dsb., pada mana-mana elemen, membolehkan pembangun bertindak balas terhadap interaksi pengguna dengan serta-merta. Ingin menambah perenggan baharu apabila pengguna mengklik butang? Jangan jana keseluruhan HTML lagi, ia mudah.

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

• XMLHttpRequest ialah pengubah permainan. Ia membolehkan pembangun membuat permintaan HTTP tak segerak tanpa menyekat terus daripada kod yang dijalankan dalam penyemak imbas dan mengambil data daripada pelayan. Pada zaman dahulu, data biasanya dipindahkan dalam format XML — oleh itu namanya — tetapi JSON kemudiannya mengambil alih kerana ia kurang bertele-tele dan lebih mudah untuk digunakan. Akhirnya, API pengambilan datang, menawarkan ciri lanjutan dan sintaks yang lebih bersih.

AJAX (JavaScript dan XML Asynchronous): AJAX ialah salah satu teknologi penting di sebalik revolusi ini. Ia menerangkan cara halaman web boleh berkomunikasi dengan pelayan di latar belakang untuk mendapatkan data yang diperlukan dan mengemas kini kandungan terus dalam penyemak imbas menggunakan API DOM dan XMLHttpRequest, tanpa memerlukan muat semula halaman penuh. Tiba-tiba, web mula terasa… interaktif! Sekali lagi nama itu berasal dari XML, yang digunakan untuk pemindahan data.

Bagaimana Ini Mengubah Perkara?

Dari Perspektif Penyemak Imbas: tag telah diperkenalkan dalam HTML, membenarkan pembangun menambah kod JavaScript terus dalam HTML. Apabila enjin pemaparan penyemak imbas menghuraikan HTML dan menemui tag, ia akan mengambil dan melaksanakan skrip (tertib bergantung async dan menangguhkan prop), membenarkan kandungan dinamik dan ciri interaktif.

• Enjin JavaScript: Untuk menilai skrip ini, enjin JavaScript telah diperkenalkan dalam penyemak imbas. Enjin awal agak mudah dan lebih perlahan, tetapi enjin moden seperti V8 Google dan SpiderMonkey Mozilla telah berkembang dengan ketara, membolehkan logik pihak pelanggan yang lebih kompleks.
  
  

• Gelung Acara: JavaScript telah direka bentuk sebagai bahasa skrip satu utas untuk memastikan bahasa itu mudah dan ringan. Pilihan reka bentuk ini juga dipengaruhi oleh faktor seperti sumber pengkomputeran yang terhad dan mengekalkan DOM (Document Object Model) thread-safe, menghalang keadaan perlumbaan apabila memanipulasi DOM.
  
  

  Disebabkan semua pelaksanaan skrip dan tugas pemaparan berkongsi satu urutan, JavaScript memerlukan cara untuk mengendalikan operasi tak segerak tanpa menyekat urutan utama. Untuk mencapai matlamat ini, JavaScript bergantung pada konsep Gelung Acara.
  
  

  Mari lihat cara ia berfungsi secara dalaman:
  
  

  Apabila enjin pemaparan menghuraikan HTML dan menemui tag, ia mengambil skrip dan menyerahkannya kepada enjin JavaScript. Enjin JavaScript mula melaksanakan skrip dengan menolak konteks pelaksanaan ke Tindanan Panggilan.
  
  

  JavaScript bergantung pada API Web yang disediakan oleh penyemak imbas untuk mengendalikan tugas tak segerak tanpa menyekat urutan utama. Ini termasuk API untuk pemasa (setTimeout, setInterval), permintaan HTTP (fetch, XMLHttpRequest), acara DOM dan banyak lagi. Apabila operasi tak segerak digunakan, enjin JavaScript menyerahkannya kepada API Web, bersama-sama dengan fungsi panggil balik dan terus melaksanakan kod yang lain. Setelah tugas tak segerak ini selesai, penyemak imbas menolak panggilan balik ke baris gilir tugas masing-masing (Microtask Queue atau Macrotask Queue).
  
  

  Berikut ialah cara gelung acara mengurus baris gilir ini bersama-sama dengan pemaparan
  
  

  1. Microtask Queue: Promises, panggilan balik MutationObserver, dsb masuk di sini. Barisan gilir ini mempunyai keutamaan tertinggi. Selepas timbunan panggilan kosong, Gelung Acara menyemak baris gilir microtask. Ia memproses semua tugasan mikro dalam baris gilir, satu demi satu, dengan menolaknya ke tindanan panggilan untuk dilaksanakan. Jika mana-mana tugasan mikro menambah tugasan mikro baharu pada baris gilir, tugasan tersebut juga diproses sebelum meneruskan.
  
  

  2. Rendering: Setelah baris gilir microtask kosong, enjin rendering mungkin mengambil alih thread utama dan melakukan rendering jika perlu. Ini termasuk mengemas kini UI untuk mencerminkan sebarang perubahan DOM yang dibuat semasa pelaksanaan skrip dan pemprosesan microtasks. Ini dilakukan berdasarkan kadar bingkai peranti, sekali setiap bingkai, untuk mengoptimumkan prestasi.
  
  

  3 . Macrotask Queue: Panggilan balik daripada setTimeout, setInterval, acara DOM, acara I/O, dll masuk ke sini. Barisan ini sebagai keutamaan terendah. Gelung Acara menarik satu tugasan daripada baris gilir ini dan melaksanakannya. Selepas melaksanakan tugas ini, ia memproses semua tugasan mikro dan rendering sebelum menarik tugasan makro seterusnya.
  
  

  [Panggil Tindanan Kosong] → [Proses Semua Tugasan Mikro] → [Render jika perlu] → [Lakukan Satu Tugasan Makro] → Ulang

Di Bahagian Pelayan: Dengan pihak klien mengendalikan lebih banyak antara muka pengguna dan interaksi pengguna, pelayan mula mengalihkan tumpuan mereka. Pelayan mula menyediakan data dan logik perniagaan melalui API. Mereka berkembang daripada menyediakan fail HTML statik kepada menjadi enjin berkuasa yang memproses permintaan, berinteraksi dengan pangkalan data dan melakukan pengiraan kompleks untuk menyediakan data. Daripada hanya berkhidmat untuk penyemak imbas, mereka mula menyediakan pelbagai jenis pelanggan (Aplikasi Mudah Alih atau Desktop, pelayan lain dll).

REHAT: Konsep REST menjadi popular. REST (Representational State Transfer) ialah gaya seni bina yang menyediakan set garis panduan dan kekangan untuk mereka bentuk perkhidmatan web. Untuk meringkaskan, setiap sumber dikenal pasti secara unik oleh URL dan kaedah HTTP standard seperti GET, POST, PUT dan DELETE digunakan untuk memanipulasi sumber ini dalam interaksi pelanggan-pelayan tanpa negara. Ini membantu pelayan menjadi mudah, berskala dan cekap.

Apabila aplikasi menjadi lebih popular, pelayan terpaksa mengendalikan lebih banyak pemprosesan data dan logik perniagaan. Pelayan aplikasi dan pelayan pangkalan data diperlukan untuk memproses data dengan sangat cekap. Pelayan terpaksa melaksanakan beberapa teknik baharu untuk mengatasi beban berat ini, seperti Caching Sisi Pelayan, Pengimbangan Beban dan Kebolehskalaan, Seni Bina Perkhidmatan Mikro, dsb.

JavaScript EveryWhere: Dengan pengenalan NodeJS (persekitaran masa jalan JavaScript), kini Javascript boleh dijalankan di luar penyemak imbas, membawa konsep "JavaScript EveryWhere" (sebelah klien dan bahagian pelayan ). Bersama-sama dengan itu, npm (pengurus pakej nod) diperkenalkan yang membantu pembangun berkongsi kod JavaScript dengan mudah. Dengan ini, ekosistem JS berkembang pesat, menyediakan semua alatan yang diperlukan (rangka kerja, pengikat, pengkompil, transpiler, dll) yang diperlukan untuk projek itu.

Aplikasi Halaman Tunggal: Dengan JavaScript kini melakukan penciptaan dan manipulasi DOM pada sisi klien, terdapat keperluan untuk rangka kerja untuk membina aplikasi kompleks dengan lebih cekap. Masukkan rangka kerja seperti Angular, React dsb. Ini ialah kemuncak skrip sebelah klien. Pada asasnya, dalam SPA, hanya satu fail HTML kecil diambil daripada pelayan, yang terdiri daripada Javascript yang digabungkan bagi keseluruhan aplikasi dalam satu tag. Dan skrip ini mengurus semua interaksi pengguna dan kemas kini UI dengan sendirinya termasuk pemaparan awal.

Masih Cabaran

Walaupun fasa ini menyelesaikan cabaran fasa sebelumnya, ia mencipta cabaran baharu seperti:

• Masa Muatan Awal yang Lebih Lama: SPA selalunya bermaksud himpunan JavaScript permulaan yang besar, yang boleh melambatkan masa muat awal — terutama pada rangkaian atau peranti yang lebih perlahan. Walaupun pengguna hanya mahukan beberapa bahagian sahaja , mereka perlu mendapatkan keseluruhan skrip — seperti memuat turun keseluruhan filem hanya untuk menonton treler. Pembangun terpaksa menggunakan teknik seperti pemisahan kod, pemuatan malas, goncangan pokok, pengurangan, dll untuk mengoptimumkan ini.
  
  

• Kebimbangan SEO: Memandangkan kebanyakan kandungan dijana secara dinamik, enjin carian bergelut untuk mengindeks tapak web ini. Sukar untuk diperhatikan apabila perangkak Google tidak dapat melihat tapak anda. Teknik seperti Perenderan Sisi Pelayan (SSR) dan prapemarahan boleh menangani isu ini.
  
  

• JavaScript Keletihan: Dengan rangka kerja, alatan dan pustaka baharu muncul setiap hari, pembangun menjadi bosan cuba mengejar ketinggalan. Mengikuti trend terkini adalah seperti berlari di atas treadmill yang tidak berkesudahan! Dan juga memilih timbunan yang betul menjadi sangat sukar dengan begitu banyak pilihan.
  
  

• Lebih pantas, namun lebih perlahan: Prestasi kedua-dua bahagian pelayan dan bahagian pelanggan telah meningkat tetapi tidak sebanyak yang pembangun mahu menarik perhatian pengguna. Juga walaupun pelayar adalah pantas dan berkebolehan, ia tidak sepantas atau berkemampuan seperti aplikasi asli. Contohnya, anda tidak boleh membina aplikasi kompleks seperti permainan atau editor video.
  
  

Fasa Keempat: Web Moden dan Seterusnya

Selamat datang ke era moden pembangunan web — ketika web lebih dinamik, berkuasa dan mengutamakan pengguna berbanding sebelum ini. Mari kita bincangkan beberapa perkara sedia ada yang sedang berlaku pada masa ini, yang mungkin menyelesaikan cabaran fasa sebelumnya.

Tiada Penyelesaian Rendering Sempurna Tunggal

Selepas fasa sebelumnya, kami mendapati bahawa tiada satu strategi pemaparan yang sempurna untuk semua orang. Kami perlu memilih strategi pemaparan hibrid yang betul, kadangkala berdasarkan keperluan dan kekangan kami. Berikut ialah beberapa strategi pemaparan sedemikian

1. Penjanaan Tapak Statik (SSG): Tidak seperti Rendering Sebelah Klien (CSR), di mana JavaScript mencipta HTML dalam penyemak imbas pengguna, SSG menjana keseluruhan fail HTML pada masa bina dan menyediakan statik pra-jana ini Fail HTML, CSS, JS kepada pengguna atas permintaan. Kita juga boleh menggunakan CDN untuk mempercepatkan respons.

   Ia menyelesaikan isu seperti masa muat awal yang lebih lama dan kebimbangan SEO. Ia juga mempunyai First Contentful Paint yang sangat pantas. Kami tidak perlu terlalu risau tentang isu penskalaan kerana fail statik boleh disampaikan dengan mudah melalui CDN. Kami boleh memilih strategi ini jika kebanyakan kandungan dalam laman web kami adalah statik. Walau bagaimanapun, jika kandungan lebih dinamik dan khusus pengguna, maka ini tidak akan berfungsi dengan baik. Dalam kes tersebut, kita boleh memilih pendekatan hibrid menggunakan SSG dan CSR dengan Penghidratan seperti yang dijelaskan di bawah. Anda juga boleh menyemak JAMStack yang menerangkan lebih lanjut tentang menggunakan SSG dengan API tanpa Pelayan dan fungsi Edge.

2. Rendering Sisi Pelayan (SSR): Ia agak serupa dengan fasa kedua, tetapi di sini, logik perniagaan dipisahkan daripada skrip sisi pelanggan. Pada asasnya, bukannya penyemak imbas menjalankan skrip dan menjana HTML, kami menjalankan skrip pada pelayan untuk menjana HTML dan menyampaikannya kepada penyemak imbas pada setiap permintaan pengguna.

   Sekali lagi, walaupun ia menyelesaikan isu seperti masa muat awal yang lebih lama dan kebimbangan SEO, ia meningkatkan beban pelayan. Juga kebanyakan daripada kita tidak mahu halaman dimuat semula setiap kali pengguna berinteraksi, jadi kita perlu menggunakan pendekatan hibrid termasuk CSR dengan penghidratan.

Penghidratan: Pada asasnya, kami menyediakan fail HTML statik terlebih dahulu untuk memaparkan dan menambah interaktiviti pengguna dengan menjalankan JavaScript selepas pemaparan awal. Proses menukar halaman web statik kepada halaman web dinamik ini dipanggil Penghidratan. Selepas penghidratan, aplikasi berkelakuan serupa dengan aplikasi CSR.

Penghidratan membawa beberapa isu dengannya, pengguna tidak boleh berinteraksi dengan kandungan sebaik sahaja mereka melihatnya. Mereka perlu menunggu sehingga skrip ini dimuat turun dan dijalankan, yang sekali lagi menambah masa overhed yang sama seperti CSR. Untuk mengurangkan masalah ini, terdapat pendekatan penghidratan baharu seperti Penghidratan Progresif dan Penghidratan Separa, tetapi ini sukar untuk dilaksanakan.

Rangka kerja moden seperti Next.js, Nuxt.js, Gatsby dan React menyediakan pelbagai strategi pemaparan ini, bersama-sama dengan teknik baharu seperti Incremental Static Regeneration dan Streaming SSR.

---

Agak meletihkan betul! Ya saya tahu, tetapi ia hampir selesai. Terdapat juga banyak API Web sedia ada yang telah ditambah atau dicadangkan. Walaupun kami tidak dapat merangkumi kesemuanya, tetapi lihat beberapa API yang terkenal termasuk seperti Pekerja Web, IndexedDB dan Storan Dikongsi.

Tetapi inilah dua Teknologi Web utama yang boleh kami teruja

WebAssembly (Wasm)

Walaupun enjin JavaScript moden sedang berusaha untuk menjadikan JS lebih pantas, kesesakan utama terletak pada hakikat bahawa JS ialah bahasa yang ditaip secara dinamik dan tidak dihimpun. Ini bermakna kita tidak boleh bergantung pada JS untuk pengiraan yang sangat berprestasi. Di sinilah WebAssembly melangkah masuk. WebAssembly ialah format arahan binari yang dijana oleh kod yang ditulis dalam bahasa seperti C, C dan Rust, dll, yang boleh berjalan pada kelajuan hampir asli pada semua penyemak imbas moden tanpa pemalam.

Wasm berfungsi bersama JavaScript, membenarkan fungsi dipanggil di antara mereka. Ia belum lagi menyokong manipulasi langsung DOM atau penggunaan API Web lain, tetapi pembangunan berterusan bertujuan untuk menambah fungsi ini tidak lama lagi. Wasm boleh digunakan untuk sebarang aplikasi web intensif prestasi, seperti permainan, pemprosesan imej, penyuntingan video dan banyak lagi.

Apl Web Progresif (PWA)

Dengan ekosistem web yang luas ini, mengapa kita tidak boleh membina aplikasi web seperti asli? Apl Web Progresif ialah aplikasi web yang boleh dipasang terus daripada penyemak imbas dan berfungsi serupa dengan apl asli, menyediakan sokongan luar talian, pemberitahuan tolak, dll. Dan ia menyampaikan pengalaman yang pantas, menarik dan boleh dipercayai merentas platform dengan satu pangkalan kod.

Satu komponen utama PWA ialah Service Worker , yang menjalankan skrip latar belakang secara berasingan daripada urutan penyemak imbas utama. Ia boleh bertindak sebagai proksi antara apl web, penyemak imbas dan pelayan. Pekerja Perkhidmatan boleh mengawal cara permintaan dikendalikan dan menangguhkan tindakan tertentu sehingga pengguna mempunyai sambungan yang stabil. Ini membolehkan kami meng-cache sumber menggunakan API Cache, jadi kandungan boleh disampaikan walaupun peranti di luar talian atau pada rangkaian yang perlahan, dan kemudian disegerakkan dengan pelayan setelah kembali ke dalam talian.

Walau bagaimanapun, tidak semua ciri disokong secara seragam merentas penyemak imbas. Dan membina PWA memerlukan perancangan teliti strategi caching dan kelakuan luar talian. PWA juga mungkin belum mengakses semua keupayaan peranti berbanding apl asli, tetapi ini semakin berkembang.

---

Web masih belum sempurna, tetapi apabila kita melihat ke hadapan, garisan antara aplikasi web, asli dan desktop terus kabur. Dengan begitu banyak teknologi baru muncul, kemungkinannya tidak terhad.

Ini membawa kami ke penghujung blog kami. Tolong beritahu saya jika saya salah tentang sesuatu atau jika saya terlepas apa-apa. Teruskan meneroka dan terus belajar. Selamat tinggal!

Atas ialah kandungan terperinci Evolusi Teknologi Web dan Penyemak Imbas. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!