Bagaimana Situs Web Berkembang Kembali ke File HTML / CSS / JS StatisHow Websites Evolved Back to Static HTML/CSS/JS Files

Semua orang suka berbicara tentang masa lalu yang indah hanya dengan bisa membuat file baru dengan ekstensi .html dan mulai membuat situs web alih-alih bagaimana kita melakukannya hari ini - menyiapkan sistem pembangunan yang sangat kompleks untuk mendekati dasar. halo proyek dunia.

Era HTML

HTML (Hyper-text Mark-up Language) itu sendiri hanyalah cara untuk menandai teks dan menentukan gaya dan perlakuan teks. Anda secara teknis dapat mempublikasikan teks seperti online. Tetapi Anda dapat benar-benar pergi ke suatu tempat dengan menandai bagian tertentu dari teks Anda sebagai jangkar dan kemudian dapat mengkliknya dan membuka dokumen lain!

Kami tidak puas dengan kemampuan dasar seperti huruf tebal dan huruf miring sehingga kami membangun CSS. Sekarang, kami ingin memodifikasi beberapa bagian dari HTML / CSS sebagai tanggapan terhadap hal-hal seperti mengklik sesuatu, jadi kami menerapkan bahasa scripting untuk dengan cepat menentukan hubungan seperti itu dan kemudian berjalan di dalam browser itu sendiri alih-alih pulang pergi ke server.

Tetapi poin utama di sini adalah bahwa cara kami mengembangkan situs kami masih tentang membuka banyak file dan menulis HTML / CSS dan JS secara terpisah. Bahkan penyebaran diperluas lebih jauh dengan hanya meng-hosting file-file ini di server file statis seperti Apache.

Era PHP

Lembur, kami masih tidak senang dengan kemampuan untuk markup teks (HTML), kemampuan untuk gaya markup ini (CSS) dan bahkan dapat skrip perilaku kecil untuk ini (JS) - kami ingin menyajikan HTML yang berbeda untuk orang yang berbeda!

Dan begitu lahir PHP, rasanya seperti ekstensi alami untuk HTML itu sendiri. Anda menulis kode di antara file HTML itu sendiri dan kemudian dapat menjalankan bagian-bagian itu di server, yang selanjutnya menghasilkan HTML dan HTML akhir akan dikirim ke browser.

Ini sangat kuat. Kami dapat melayani halaman yang sama sekali berbeda untuk pengguna yang berbeda meskipun semuanya mengakses URL yang sama seperti Facebook. Kami dapat menggunakan database di server dan menyimpan beberapa data di sana, kemudian berdasarkan pada beberapa kondisi, gunakan data ini untuk memodifikasi HTML yang dihasilkan dan secara teknis memiliki jumlah halaman tak terbatas yang tersedia untuk dilayani (e-commerce).

Zaman Kegelapan

Di suatu tempat di jalur ini untuk membuat halaman on the fly (SSR) dan membuat halaman pada klien (SPA) kami lupa tentang kinerja halaman web kami. Kami mencoba membangun aplikasi. Tetapi web adalah tentang menyajikan konten terlebih dahulu dan terutama!

Kami membangun kerangka kerja front-end yang besar untuk melakukan segalanya pada klien itu sendiri. Tapi kemudian kami juga mem-porting mesin JS tersebut ke server sehingga kami bisa menjalankan kode yang sama di server juga.

Kami membangun alat membangun dan transpilasi bahasa yang rumit untuk memastikan bahwa perbedaan dari begitu banyak lingkungan diabstraksi sehingga kami dapat menjalankan kode yang sama di mana-mana.

Di satu sisi kami macet skala server ini sementara di sisi lain kami menunjukkan pengguna halaman putih kosong sampai semua JS telah diunduh dan mereka siap untuk melihat konten.

Untuk mengatasi ini, kami memutuskan untuk melakukan keduanya! Kami akan membuat halaman di server terlebih dahulu, lalu melayani JS, lalu JS akan mengambil alih dan berjalan hanya pada klien. Bagus! Selamat - Anda sekarang telah mengirimkan kode sisi server Anda ke setiap pengguna untuk menjalankannya di browser mereka.

Bahkan jika sebagian kecil halaman Anda bersifat interaktif, logika untuk membuat seluruh halaman dikirimkan ke klien dan halaman berikutnya yang akan di-render.

Tumpukan JAM

Javascript, API dan Markup - tumpukan ini adalah tentang menemukan jalan tengah dari kekacauan SSR + SPA. Ini tentang melangkah mundur dan bertanya pada diri sendiri, bagian halaman mana yang berubah dan bagian mana yang tidak berubah?

Bagian-bagian yang tidak berubah sering dipra-render di server dan disimpan ke file HTML statis. Hal lain diimplementasikan dalam JS dan dijalankan pada klien menggunakan panggilan API.

Ini bermanfaat untuk menghindari transfer data yang terlalu banyak (seperti data hidrasi untuk RSK) dan menemukan tradeoff yang baik untuk mengirimkan konten di web.

Tetapi yang lebih penting lagi, ini memungkinkan Anda untuk meningkatkan kekuatan dan biaya CDN untuk melayani konten Anda secara efektif. Dan dengan aplikasi tanpa server, API Anda tidak akan memerlukan server untuk masuk dan dikelola SSH.

Kesimpulan

Saya merasa menarik bahwa kita kembali menghasilkan file HTML / CSS dan JS yang terpisah dan kemudian meletakkannya di server file statis - CDN. Ini merupakan upaya yang panjang selama satu dekade dan ketika kami kembali ke tempat kami mulai, saya merasa seperti berada pada level yang berbeda (spiral?).

Pada akhirnya, hasilnya tetap sama, tetapi kami memiliki perangkat yang jauh lebih canggih, mirip dengan banyak hal lain dalam kehidupan. Bayangkan kerumitan yang terlibat dalam mengubah suara Anda menjadi bit dan mentransmisikannya melalui kombinasi kabel dan spektrum udara untuk menjangkau orang lain yang bertentangan dengan masa lalu di mana kita hanya akan bepergian dan bertemu orang-orang. Seiring waktu hasilnya tetap sama, tetapi dengan memperkenalkan kompleksitas dan kemudian secara efektif memisahkannya, kita dapat mencapai hal-hal yang tidak dapat dipisahkan dari sihir.