Diskusi hasil tahun di frontend tiba-tiba menjadi bahan diskusi . Saya akan menambahkan pendapat saya, dan saya akan senang mendengar pendapat orang lain.
Sepertinya saya masuk akal untuk berbicara tentang apa yang terjadi di web modern, yang dirasakan dari luar dan dalam sama sekali berbeda. Ya, dan "di dalam" memiliki beberapa tingkatan. Pandangan "mereka memperumit tata letak lagi" benar-benar benar di satu sisi dan keliru serta bejat di sisi lain, tetapi pandangan "jangan menghalangi kita membangun abstraksi" juga tidak efektif.
Ketika seseorang mengeluh bahwa web modern telah menjadi terlalu rumit, setiap kali saya ingin mengingatkan orang ini bahwa web modern ini dia mempercayai uangnya di bank online dan formulir pembelian, korespondensi pribadi dalam jejaring sosial dan versi web dari pengirim pesan instan, dan file pribadi di awan. Dan kemungkinan besar dia benar-benar ingin proses pengembangan sistem ini menjadi kompleks, sulit, tetapi dapat diandalkan dan tidak gagal.
sumber gambar
Di bawah frontend modern dan teman-temannya sekarang mereka mengerti lebih dari yang terlihat dari luar. Ini adalah situs web klasik dan SPA, dan aplikasi pada elektron, dan aplikasi seluler pada cordova, NativeScript, React Native, dan bahkan pada Flutter. Ini adalah infrastruktur yang kompleks dengan CDN, layanan geo-desentralisasi, chatbots di JS, dan bahkan alat pembelajaran mesin untuk mengoptimalkan perakitan dan bahkan pembuatan tata letak .
Dan di web itu sendiri, muncul solusi yang sangat rumit yang sebelumnya dapat bekerja secara eksklusif dalam mode desktop. Saya sendiri punya beberapa tahun yang lalu untuk menyentuh pengembangan peramban genom lengkap di peramban - saya terlibat dalam memberikan kinerja dan 60FPS, yang merupakan masalah yang cukup besar tetapi dapat dipecahkan. Bahkan 5 tahun yang lalu, tidak ada yang bisa berpikir bahwa browser genom tidak dapat menjadi sesuatu yang diinstal pada komputer yang kuat, dan solusi ini memungkinkan dokter dan peneliti untuk bekerja dengan genom bahkan dari tablet atau laptop yang ringan.
Mengapa
Saat ini, bundel HTML + CSS + JS adalah salah satu yang paling kuat dalam hal membangun antarmuka - tidak hanya karena kemampuannya, tetapi juga sejumlah solusi yang dibangun di atasnya - kerangka css, perpustakaan komponen visual, antarmuka ke sejumlah besar layanan dan SAAS . Dalam hal efisiensi dalam jam pengembangan untuk potensi audiens dan aksesibilitas, teknologi web lebih unggul dari solusi mobile dan desktop. Dan sekarang telah dibagi menjadi tiga area:
- Pengembangan situs yang sepenuhnya statis dan hampir-statis dengan konten yang sebagian dinamis (galeri, munculan, dan sebagainya)
- Pengembangan aplikasi web "klasik" pada kerangka kerja server (Django, rails)
- Pengembangan klien web
Dan masing-masing dari mereka memiliki kekhususan yang sangat berbeda.
Pengembangan JS benar-benar menyakitkan, jadi solusi mulai muncul yang mengatasi rasa sakit ini.
Jika Anda melihatnya, Anda dapat melihat sesuatu yang sangat menarik: pertama, solusi seperti jQuery dan CoffeeScript mulai muncul, mengurangi redundansi dan verbositas bahasa. Tetapi mereka dengan cepat menghilang, dan sebagai gantinya datang alat yang memungkinkan untuk menggunakan kembali kode seefisien mungkin, mendeteksi kesalahan secara statis, dan membangun abstraksi yang efektif, "menyembunyikan" tingkat kompleksitas individu di balik antarmuka yang sederhana dan dijelaskan dengan baik.
GraphQL muncul, yang memecahkan masalah dengan kompleksitas menggambarkan, mendokumentasikan, dan memelihara REST. TypeScript dan Flow muncul, yang memecahkan masalah kurangnya pengetikan. Entitas bahasa baru telah muncul yang memungkinkan Anda untuk bekerja secara efektif dengan operasi, kelas, dan aliran data yang tidak sinkron. WebAssembly telah muncul, memungkinkan Anda untuk menggunakan kembali kode dari bahasa lain, dan melakukannya dengan cepat.
Semua solusi ini ditujukan untuk hal yang sama: menggunakan kembali kode dan potensi untuk membangun tim "flat". Mereka memecahkan masalah untuk mengambil kode orang lain dan mulai menggunakannya.
Ini adalah bukti nyata bahwa web berkembang menuju bekerja dalam tim besar, ia telah menjadi platform untuk solusi "dewasa".
Serangkaian peristiwa yang terjadi semakin menjadi bukti yang lebih jelas: React Native, NativeScript, Dart + Flutter dan solusi lain untuk menggunakan kembali kode pada platform asli muncul. Ini adalah poin yang sangat penting: karena kurangnya kemampuan untuk menggunakan bahasa lain di web, perusahaan mulai menyempurnakan proses mereka dalam mencari "peluru perak" yang akan memungkinkan mereka untuk mengurangi dengan tidak sedikit biaya pengembangan dan waktu untuk memberikan fungsionalitas baru kepada semua pelanggan. Penting bagi setiap proyek untuk menjadi cepat, dan spesialis tingkat tinggi mulai bersatu dalam mencari peluang untuk bekerja secara efektif di JS.
Ngomong-ngomong, untuk alasan yang sama, mesin templat mulai mati sebagian: penggunaan satu lagi semantik terbukti kurang efektif daripada menggunakan HTML yang dikenal dengan ekstensi kecil di JS (Angular, Vue) atau hanya menggunakan bahasa untuk menggambarkan tata letak (Bereaksi, Flutter). Ketidakmampuan untuk memperluas, kebutuhan untuk memperkenalkan pengembang ke bahasa baru, risiko sekarat platform, desentralisasi mengarah pada fakta bahwa mereka mulai lebih menyukai kerangka templator yang berusaha sedekat mungkin dengan platform HTML / DOM.
Namun, selain menulis kode secara efisien, ada juga "koefisien" untuk menyinkronkan perintah. Jika bahasa ini memungkinkan Anda untuk bekerja dengan sangat cepat, tetapi pada saat yang sama menyinkronkan fungsional individu antara dua pengembang menciptakan rasa sakit yang hebat, kemungkinan besar itu akan tetap menjadi niche. Oleh karena itu, banyak fitur dan solusi bahasa yang ditujukan khusus untuk mengurangi masalah dengan sinkronisasi dan tidak adanya masalah. Mereka mengurangi "koefisien" ini, yang menunjukkan berapa banyak junior yang secara simultan dapat mengontrol tengah, dan berapa banyak middle yang dapat dikontrol oleh pengembang utama. Dari contoh-contoh terbaru fitur-fitur tersebut, impor es6 menyelesaikan sebagian masalah ketergantungan siklik, sementara yang lebih cantik memungkinkan Anda untuk mendapatkan gabungan yang diharapkan, cocok dalam kode git, terlepas dari bagaimana pengembang menulisnya. Seharusnya tidak cantik, harus disinkronkan dengan baik.
Dan sebagai hasilnya, hanya dalam beberapa tahun, web sebagai platform telah diambil alih oleh perusahaan besar dan tim yang serius, itulah sebabnya mayoritas mengalami "kelelahan javascript . " Ngomong-ngomong, klaim utama atas hampir-monopoli Google di web yang diwakili oleh Chromium terletak pada kenyataan bahwa mereka mendorong apa yang mereka butuhkan ke dalam kemampuan platform web dan JS (meskipun ini biasanya bertepatan dengan apa yang dibutuhkan sebagian besar perusahaan).
Akibatnya, di satu sisi, kami mendapatkan platform yang benar-benar menyenangkan untuk kode yang digunakan kembali di mana-mana, sintaks yang memungkinkan Anda untuk bekerja dengan perintah flat besar. Tapi ...
Semuanya menjadi rumit dan semua orang menjadi bingung
Dan tidak ada yang mengerti apa yang harus dilakukan. Sebenarnya apa masalahnya? Dalam tiga kategori berbeda itu.
- Pengembangan situs yang sepenuhnya statis dan hampir-statis dengan konten yang sebagian dinamis: jenis aplikasi ini ditandai oleh HTML sebagai titik masuk, kecepatan unduh maksimum dan JS opsional
- Pengembangan aplikasi web "klasik" pada kerangka kerja server (Django, rails): solusi ini saat ini ditandai dengan memuat dengan HTML sebagai titik masuk, tetapi alih-alih kecepatan unduh maksimum, mereka berfokus pada penggunaan kembali kode, KERING dan integrasi backend. Kode JS sebagian dihasilkan oleh kerangka kerja (pemberitahuan, formulir, tautan turbo, dan sebagainya), sebagian Anda perlu menulis sendiri
- Pengembangan aplikasi klien web. Di sini hal yang tidak terduga terjadi: HTML alih-alih titik masuk menjadi manifes aplikasi dan platform render, dan JS menjadi "titik masuk".
Apa yang saya maksud dengan titik masuk: ini adalah entitas tertentu, yang memuatnya sama dengan pengiriman minimum ke pengguna produk. Jika pengguna perlu menunjukkan informasi, maka kita perlu HTML + CSS, jika kita menjalankan aplikasi, kita perlu JS yang dijalankan dari HTML.
Dan untuk membingungkan semua orang, kategori keempat muncul:
Aplikasi Isomorfik
Di bawah "isomorfik" dalam pengembangan web biasanya berarti sesuatu yang berfungsi baik pada server maupun pada klien. Dalam mode ini, aplikasi pada react, angular, vue.js dapat bekerja, ada kerangka kerja siap pakai - Berikutnya dan Nuxt , misalnya.
Kedua tugas itu relevan untuk mereka: aplikasi web harus mengirimkan keadaan awalnya kepada pengguna secepat mungkin, dan bertindak sebagai aplikasi. Dengan kata lain, mereka harus memberikan HTML dan JS sebagai dua titik masuk, satu untuk konten dan satu untuk aplikasi. Ini menciptakan dua paragraf yang saling bertentangan: di satu sisi, jumlah data yang dikirim harus minimal, di sisi lain, penggunaan kembali kode diperlukan. Untuk JS, ini diselesaikan dengan potongan webpack, pemecahan kode dan pemuatan kode dinamis, template tersisa untuk JS, tetapi CSS masih tetap. Dan yang paling penting - kami ingin tidak mengirimkan byte tambahan tunggal kepada pengguna. Dan kemudian seseorang datang dengan ide: aplikasi semacam itu benar-benar memiliki dua titik masuk. Mereka dapat diproses sebagai dua entitas otonom.
Dari sini, konsep CSS-in-JS lahir, dengan fokus pada dua proses terpisah: menghasilkan file CSS untuk konten statis, dan menyimpan gaya di sebelah komponen.
Semuanya tersisa untuk JS.
Sekarang di JS Anda dapat menemukan gaya, tata letak, dan kode aktual.
Sekarang semuanya ada di js dan itu bagus
Perlu melakukan penyimpangan lain - sekarang ke sisi belanjaan.
Penting bagi setiap produk dalam pengembangan atau pengembangan untuk dapat "bergerak" ke arah lain. Kerjanya pada salah satu level:
Kemampuan untuk mengubah komponen visual menjadi komponen dengan logika minimal dengan menambahkan sebaris kode sangat keren. Kebutuhan untuk menulis ulang dari awal tidak keren.
Membuatnya menjadi murah untuk menjadi aplikasi SPA atau sisi server benar-benar keren, tetapi sangat jarang mungkin. Lebih bijaksana, jika tidak membebankan biaya, untuk memulai dari awal dengan platform semacam itu.
Oleh karena itu, hampir semua proyek web yang memiliki risiko perlu dirender di server, risiko diperlukan komponen refactor, pindah dari satu mesin templat ke yang lain, mencoba menghindari risiko.
Ketika ada satu platform di mana beberapa entitas dapat berubah menjadi yang lain dengan cukup murah, pengembangan sangat cepat.
Dalam kasus aplikasi pada angular / react / vue, ini persis seperti itu. Mereka sulit dimengerti. Tidak serumit Angular 1, tentu saja, tapi bagaimanapun - jalan untuk memahami mereka panjang, dan kursus online enam bulan tidak cukup untuk memahaminya. Tetapi mereka memberikan kesempatan untuk melakukan dalam beberapa jam apa yang telah dilakukan beberapa minggu sebelumnya, dan dalam beberapa hari - apa yang biasanya memakan waktu beberapa bulan.
Namun, kebalikannya juga benar - banyak yang tidak membutuhkannya, tetapi mereka digunakan karena "modis".
Ketika arsitek infrastruktur grup aplikasi web dan seluler dan perancang tata letak berbicara, itu akan sangat sulit bagi mereka. Sekarang ini adalah arah yang sangat berbeda sehingga mereka tidak akan memiliki persimpangan dalam pengetahuan, kecuali untuk JS.
Lain kali Anda ingin mengatakan "web menjadi sangat kompleks dan membengkak" - pikirkan betapa sulitnya mendesain dan membuat klien email inbox google (dengan entitas cerdas yang disertakan tergantung pada surat itu), IDE Web seperti Cloud9 atau Internet banking .
Tetapi jika seorang koder datang kepada Anda dan mulai berbicara tentang fakta bahwa ia perlu bereaksi, karena ia membutuhkan pengetikan dan dekorator yang ketat untuk tata letak laman landas, jangan menyerah pada persuasi.