PASAL DITERIMA OLEH KOMUNITAS HABRA SEBAGAI DISINFORMASI DAN TIDAK DIREKOMENDASIKAN UNTUK BACAAN!

Di salah satu perusahaan sosial saya, peran pengembang front-end dibandingkan dengan pemain bass dalam kelompok musik: begitu mereka bermimpi menjadi gitaris solo dengan elektronik enam senar di tangan mereka, atau, menarik "peretas" paralel, nyata, seorang guru teknologi informasi, tetapi tersandung pointer dipaksa untuk mengambil langkah mundur dan tetap coders. Terserah Anda untuk memutuskan seberapa benar ide ini, tetapi secara pribadi kenalan saya, vendor front-end, benar-benar pernah mencoba untuk belajar hampir assembler dan kadang-kadang masih menyesal bahwa mereka tidak dapat mengatasi segmentasi memori. Pada artikel ini, kami akan mempertimbangkan kasus sebaliknya - ketika seorang programmer sistem atau aplikasi yang berpengalaman tiba-tiba memutuskan untuk menjadi seorang webmaster. Alasannya mungkin berbeda. Mungkin ini adalah siswa seperti saya, yang belum menerima diploma yang dengannya Anda bisa mendapatkan pekerjaan di bidang spesialisasi, tetapi Anda perlu mendapatkan uang sekarang. Atau bos memerintahkan administrator sistem untuk membuat situs web perusahaan, karena tidak ada orang lain. Ya, atau mungkin Anda tertarik dengan ide untuk berhenti bekerja untuk paman dan menjadi freelancer mandiri, dan di bursa lepas, seperti yang Anda tahu, barang yang paling populer adalah situs web. Salah satu cara atau yang lain, ketika melakukan tugas-tugas dari tutorial dalam HTML, CSS dan JavaScript, Anda tanpa disadari sebagian bergantung pada pengalaman masa lalu Anda dalam mengembangkan aplikasi dan perangkat lunak sistem, sedangkan tutorial dirancang untuk pemula yang mahir dalam dunia teknologi informasi. Akibatnya, para pendatang baru ini mendapatkan situs pertama mereka lebih cepat dan lebih banyak peramban silang daripada milik Anda. Dan semua itu karena mereka tidak pergi ke biara seseorang dengan piagam mereka. Saya akan memberi tahu Anda tentang beberapa kesalahan yang diidentifikasi oleh pengalaman saya sendiri yang menghantui penyedia front-end pemula yang memiliki portofolio besar dengan algoritma C ++.

Menunggu untung mudah

Kesalahan pertama adalah ekonomi. Jika Anda datang ke ujung depan dengan tujuan mendapatkan lebih dari yang diizinkan bos Anda, saya akan segera mengecewakan Anda, Anda tidak bisa lagi membaca. Permintaan pendaratan, tata letak, dan kartu bisnis turnkey di bursa sangat besar, tetapi tawarannya tinggi. Alih-alih 8 jam kerja di kantor, di mana Anda melakukan pekerjaan yang ditugaskan kepada Anda, Anda harus menghabiskan sebagian besar hari untuk pencarian independen untuk pekerjaan ini. Ingatlah bahwa sebagian besar pengusaha hanya mau bekerja sama jika Anda memberi mereka contoh terkait pesanan dari portofolio Anda, yang berarti bahwa bulan pertama Anda dijamin bekerja untuk shisha, karena Anda harus terlebih dahulu mengumpulkan portofolio ini, menangkap setiap peluang untuk bekerja secara gratis . Dan bahkan dengan dia puluhan freelancer seperti Anda akan merespons proyek yang sama dengan Anda. Di antara mereka akan ada desainer tata letak yang sangat berpengalaman yang akan menyelesaikan setengah dari pesanan segera dan menyediakannya sebagai versi demo, dan hanya pemula yang, seperti Anda, yang pernah akan menawarkan untuk menyelesaikan semuanya secara gratis. Kemungkinan besar, majikan akan memilih salah satu dari dua legiun ini, dan sisanya harus duduk di monitor selama beberapa jam tanpa hasil, menekan F5. Situasi ini dapat dibandingkan dengan pasar pengacara di CIS - begitu mereka disobek dengan tangan mereka, segera setelah mereka melampaui ambang almamater, tetapi sekarang tawaran itu jauh lebih tinggi dari permintaan. Pada saat yang sama, freelance berbeda dari bekerja di yurisprudensi dalam bahaya yang meningkat: jika Anda tidak memiliki wiraswasta pribadi, uang yang Anda hasilkan dari freelance dapat dianggap ilegal menurut hukum, dan kemudian Anda pasti akan menyesal bahwa Anda tidak tinggal di kantor yang nyaman itu di mana Anda bisa 8 jam sehari lakukan hal favoritmu dan dapatkan gaji putih untuk itu. Jika saya masih belum meyakinkan Anda, kami akan beralih ke kesalahan berikut.

Kode pencar pada file yang berbeda

Kami melakukan ini dalam bahasa sistem tingkat tinggi - masing-masing kelas - dalam file terpisah. Tutorial penyusunan huruf yang baik segera mengajarkan Anda cara menyimpan HTML dan CSS dalam file yang berbeda. Tampaknya teknik ini berlaku untuk semuanya. Berhenti Ya, lebih baik untuk menyimpan kode CSS secara terpisah dari HTML, tetapi, misalnya, menjaga gaya ulang atau template terpisah dari sebagian besar aturan CSS situs adalah kesalahan yang mematikan. Hal yang sama berlaku untuk JavaScript - Anda tidak perlu memecah skrip menjadi ratusan file berdasarkan kelas, cukup kelompokkan menjadi dua file: apa yang termasuk dalam header halaman (kepala) dan apa yang ditambahkan ke akhir konten (tubuh). Kami terbiasa dengan fakta bahwa program dalam bahasa yang dikompilasi sepenuhnya terhubung sebelum dimulainya eksekusi. Semuanya berbeda di sini. Setiap tautan dalam kode situs adalah permintaan tambahan ke server. Tentunya Anda memperhatikan betapa lambatnya jejaring sosial Vkontakte mulai bekerja baru-baru ini. Buka panel pengembang di browser apa pun, perbarui vk.com dan lihat seberapa besar permintaan GET dan POST ke server jaringan sosial. Satu permintaan semacam itu membutuhkan waktu beberapa mikrodetik, tetapi karena jumlahnya, proses pemuatan halaman sepenuhnya tertunda selama beberapa detik. Ingat: jumlah minimum permintaan adalah metode utama untuk meningkatkan kecepatan situs. Di server lokal, ini tidak terlihat, tetapi menjadi jelas ketika bekerja dengan hosting jarak jauh. Tidak ada yang mengganggu Anda untuk menyimpan pelepasan, templat gaya, kelas, pustaka dalam file terpisah, tetapi sebelum menerbitkan semua ini harus "dilem", meninggalkan satu file HTML dan CSS sumber, dan beberapa file JS dari sumbernya. Untuk merakit semua file JS menjadi satu file, "bundel", ada prosesor webpack, browserify, SASS dan KURANG dirancang untuk perakitan CSS serupa. Ada metode optimasi lain, misalnya, menggabungkan beberapa gambar (paling sering daftar ikon atau avatar) dalam satu file, tetapi ini adalah topik dari artikel terpisah.

Enumerasi dengan kelas dan pengidentifikasi

Tutorial menyarankan menambahkan atribut class dan identifier ke semua elemen pada halaman sehingga mereka dapat dengan mudah dipilih dengan pemilih CSS. Ini adalah saran yang bagus, sampai batas tertentu. Ketika saya baru mulai belajar mengeset huruf, semuanya hanya bertebaran kelas-kelas untuk saya. Ini sebuah kesalahan. Saya akan memberi contoh.



Ini adalah kode yang saya tulis ketika masih baru di web. Sekarang pertimbangkan semua kesalahan. Pertama, dalam ToR tidak diindikasikan untuk menghias tab navigasi dalam warna berbeda dan tidak direncanakan untuk mengindikasikannya, dan oleh karena itu semua pengidentifikasi tab hanya membuang-buang beban pada prosesor pengguna situs. Merasa bebas untuk dibersihkan. Kedua, semua elemen dari kelas "topnav" adalah elemen <li> dan tertanam di dalam <ul>, apalagi, elemen <ul> hanya dapat mengandung elemen <li>, oleh karena itu kelas "topnav" kami identik dengan pemilih "#topnav li" . Hapus kelas topnav. Dan ketiga, di TOR, satu-satunya bilah navigasi ditunjukkan, yang berarti bahwa seharusnya hanya ada satu elemen <nav> di seluruh halaman. Ya, TK mungkin berubah, tetapi menambahkan pengenal jauh lebih mudah daripada membaca kode orang lain untuk mencari kata yang tepat. Selain itu, elemen-elemen dari kelas <nav> yang kami dapatkan juga identik dengan pemilih "nav ul". Kami menghapus semuanya.

Inilah hasil akhirnya:



Bukan kelas tunggal atau pengidentifikasi! Tetapi pada saat yang sama, semua yang Anda butuhkan disorot oleh pemilih.

Dua kode berikut menerapkan aturan yang sama:



Tetapi yang kedua kurang memberatkan baik untuk Anda dan prosesor, dan orang yang akan membaca kode Anda, karena Anda tidak perlu mencari pengenal atau kelas pada halaman dan memikirkan apa namanya.
Semuanya benar. Informasi dicoret di atas tidak benar dan juga merupakan contoh kesalahan. Berlawanan dengan tutorial, pada tahap pemahaman tata letak tertentu, mulai terlihat bahwa kelas tambahan dan pengidentifikasi tidak berguna, dan contoh kedua memuat prosesor pengguna situs lebih sedikit, karena browser tidak perlu melewati pohon DOM untuk mencari semua elemen dari kelas ".topnav". Namun, penyederhanaan seperti itu, sebaliknya, akan menyebabkan peningkatan waktu pencarian dan tidak optimal. Ini karena penyeleksi gaya berkembang dari kanan ke kiri: pada kode kedua, semua elemen <a> pada seluruh halaman ditemukan terlebih dahulu, dan kemudian orang tua mereka akan diperiksa untuk kepatuhan dengan elemen <li>, kemudian orang tua dari elemen <li>, dll. Akan diperiksa. Akibatnya, pengungkapan pemilih yang diinginkan akan mengambil seluruh hierarki pohon ditambah tiga pemeriksaan daftar pilihan alih-alih satu pass untuk mencari elemen dari kelas ".topnav". Selain itu, penolakan kelas dan pengidentifikasi bertentangan dengan prinsip "HTML - untuk penataan, CSS - untuk presentasi", karena pemilih CSS tidak harus bergantung pada jenis elemen yang dipilih. Yaitu, saat mengganti <ul> dan <li> dengan <div> dan <span> mereka harus tetap tidak berubah. Jangan abaikan kelas dan pengidentifikasi. Mungkin solusi terbaik dalam contoh kita adalah:

Ngomong-ngomong, soal nama. Tidak peduli seberapa dalam Anda telah terjun ke tata letak, jika Anda masih tidak tahu Microformats - sekarang google dan belajar agar tidak menciptakan nama-nama kelas mewah dan memfasilitasi pekerjaan mesin pencari.

Menghindari Fungsi Anonim

Kita terbiasa dengan fakta bahwa ketika menulis program, nama fungsi, variabel, dan objek kita hanya memiliki tiga batasan: mereka harus mulai dengan huruf, hanya berisi huruf dan angka dan tidak boleh bertepatan dengan kata kunci dari bahasa pemrograman. Nama-nama perpustakaan pihak ketiga biasanya terlampir dalam ruang nama yang nyaman, jadi kami biasanya tidak menggunakan fungsi lambda dalam program aplikasi kami. Di web, dengan nama, segalanya menjadi lebih rumit. Di sini, JavaScript hanya memiliki satu ruang global - ruang halaman yang dimuat. Tidak ada yang akan terjadi jika Anda menulis semua skrip untuk situs secara pribadi. Tetapi untuk proyek besar dan serius Anda membutuhkan solusi pihak ketiga. Dan kemudian mereka benar-benar dapat "merusak" ruang nama ini saja, dengan serius membatasi Anda dalam memilih pengidentifikasi baru. Jalan keluarnya adalah fungsi lambda anonim, yang, walaupun membutuhkan waktu sedikit lebih lama, membutuhkan sedikit lebih banyak sumber daya, tetapi mereka memiliki ruang pribadi sendiri di dalam, independen dari global global eksternal.

Menggunakan perpustakaan yang kompleks untuk memecahkan masalah sederhana

jQuery, React, Vue, Angular, Backbone ... Daftarnya berlanjut. Hal umum tentang semua pustaka JavaScript ini adalah bahwa mereka digunakan untuk bekerja dengan proyek kompleks ketika ukuran kode benar-benar penting. Untuk memilih elemen pada halaman dengan pengenalnya, lebih baik menggunakan getElementById () yang biasa. Ini tidak hanya bekerja lebih cepat, tetapi pada dasarnya bekerja pada browser yang lebih lama. Jika skrip Anda mengakses dua atau tiga elemen pada halaman selama masa kerja, pikirkan, mungkin masuk akal untuk tidak memuat browser dan jaringan pengguna dengan perpustakaan yang berat.

Materi pembelajaran yang sudah usang

Ini untuk para pengembang C ++ karya-karya Straustrup akan tetap relevan setelah beberapa dekade. Alat web berkembang hanya dengan kecepatan luar biasa. HTML, CSS, JavaScript, tata letak, kerangka kerja, perpustakaan - saat Anda membaca artikel ini, semuanya keluar dengan versi baru, sering mencoret buku teks lama. Kesimpulan - ketika memilih materi pelatihan untuk front-end, penting untuk melihat tanggal rilis dan versi alat yang digunakan (HTML setidaknya 5,1, CSS setidaknya 3,0, ECMAScript setidaknya 6). Mungkin tata letak HTML belum berjalan jauh sejak rilis HTML 5, tetapi sudah terlambat untuk menonton kursus video JS 2016 pada tahun 2019. Pilih 2018. Bahkan lebih baik jika Anda berbicara bahasa Inggris setidaknya pada tingkat terjemahan teks teknis dengan kamus. Maka saya akan segera merekomendasikan buku online Eloquent JavaScript .

Kurangnya dukungan untuk browser lama

Paradoksnya, jika Anda beruntung menemukan pilihan buku teks terbaru di frontend, Anda dapat jatuh ke dalam jebakan lain - kurangnya dukungan untuk browser lama. Meskipun elemen <video> dan <audio> memang didukung oleh semua, bahkan versi browser yang sangat kuno, banyak efek CSS menyebabkan masalah, dan ini bukan hanya tentang Internet Explorer absolut. Hanya ada satu jalan keluar dari perangkap - baca TK dengan seksama di tempat di mana browser yang didukung ditunjukkan, dan bandingkan tag HTML yang digunakan, aturan CSS dan metode JS dengan versi mereka.

Artikel ini adalah semacam rake notebook dan akan diperbarui dengan pengalaman penulis.