5 Mitos Mengenai Jamstack

Jamstack bukan perkara baru. Walaupun istilah itu secara rasmi muncul pada tahun 2016, teknologi dan seni bina yang diterangkannya telah lama wujud. Baru -baru ini, Jamstack telah mendapat perhatian yang meluas, dan laman web dan penerbitan utama telah menerbitkan laporan yang berkaitan, dan banyak aktiviti, surat berita, podcast, dan lain -lain muncul yang memberi tumpuan kepada Jamstack. Sebagai pemaju yang mengikuti Jamstack, saya juga melihat peningkatan yang ketara dalam perbincangan yang berkaitan di Twitter, yang kebanyakannya terdedah kepada konsep itu.

Perbincangan panas juga disertai dengan kritikan. Beberapa kritikan dibenarkan, dan saya akan bercakap tentang beberapa daripada mereka kemudian, tetapi yang lain nampaknya berdasarkan beberapa kesalahpahaman umum yang berterusan mengenai Jamstack, dan itulah yang akan saya selesaikan terlebih dahulu. Oleh itu, mari kita lihat lima kesalahpahaman umum tentang jamStack yang saya temui dan menyangkal mereka satu demi satu. Seperti banyak kesalahpahaman, mereka biasanya berdasarkan beberapa situasi sebenar, tetapi membawa kepada kesimpulan palsu.

Salah faham 1: Jamstack hanyalah pembungkusan pengganti untuk laman web statik

Jamstack 99.9% adalah pemasaran jenama dan 0.1% adalah kandungan sebenar. ? https://www.php.cn/link/33f976eca39ccccf5a14627fc9f6cf1b9

- Nicole Sullivan - Black Lives Matter (@stubbornella) 9 Februari 2020

Ya, seperti yang saya nyatakan sebelum ini, istilah "jamStack" boleh dikatakan pembungkusan semula apa yang kami sebut "laman web statik". Ini tidak dimaksudkan untuk menyesatkan atau menjual produk yang belum dibentuk sepenuhnya -sebaliknya. Istilah "laman web statik" telah lama tidak dapat menggambarkan apa yang orang sedang membina. Laman web yang dibina dengan penjana laman web statik (SSG) sering mengandungi pelbagai kandungan dan ciri dinamik.

Laman web statik terutamanya dianggap blog dan dokumen, dan antara muka pengguna mereka ditetapkan terutamanya. Skop interaksi mungkin hanya memberi komen dan borang hubungan. Sebaliknya, laman web Jamstack termasuk fungsi seperti pengesahan pengguna, kandungan dinamik, e-dagang, kandungan yang dihasilkan oleh pengguna, dll.

Perlukan bukti? Beberapa syarikat dan laman web yang terkenal yang dibina dengan Jamstack termasuk Smashing Magazine, Sphero, Postman, Prima, Makanan Mustahil, dan TriNet untuk menamakan beberapa.

Salah faham 2: Laman web Jamstack rapuh

Jay Freestone, dalam artikel "Tanya Mengenai Jamstack: Anda Mungkin Perlu Backend"

Membaca senarai ketergantungan majalah Smashing adalah seperti node_modules pada pelayan, termasuk Algolia, GoCommerce, Gotrue, Gotell dan pelbagai perkhidmatan Netlify, untuk menamakan beberapa. Ia adalah nilai yang sangat baik untuk mengetahui apa yang boleh menjadi penyumberan luar (dan kapan) tetapi perlu diperhatikan bahawa kerumitan diperkenalkan dalam percubaan yang jelas untuk "kembali ke yayasan." Itu tidak perlu mengatakan potensi kelemahan yang datang dengan bergantung kepada banyak perkhidmatan pihak ketiga yang berbeza.

Ya, untuk melaksanakan fungsi dinamik yang membezakan Jamstack dari laman web statik, projek jamStack biasanya bergantung pada pelbagai perkhidmatan, termasuk perkhidmatan pihak pertama atau pihak ketiga. Ada yang percaya ini menjadikan laman web Jamstack sangat terdedah kerana dua sebab. Pertama, mereka mengatakan bahawa jika mana -mana bahagian gagal, fungsi seluruh laman web akan terhempas. Kedua, infrastruktur anda terlalu bergantung kepada alat dan perkhidmatan yang anda tidak mempunyai.

Mari selesaikan hujah pertama. Kebanyakan kandungan laman web Jamstack harus diberi pra-diberikan. Ini bermakna apabila pengguna melawat laman web, halaman dan kebanyakan kandungannya akan dihantar dari CDN sebagai sumber statik. Itulah sebabnya Jamstack mendapat sebahagian besar kelajuan dan keselamatan. Ciri-ciri dinamik-seperti keranjang belanja, pengesahan, kandungan yang dihasilkan oleh pengguna, dan carian-bergantung pada gabungan fungsi tanpa pelayan dan API untuk berfungsi.

Secara umum, aplikasi akan memanggil fungsi tanpa pelayan yang bertindak sebagai backend untuk menyambung ke API. Sebagai contoh, jika keupayaan e-dagang kami bergantung pada API Stripe untuk bekerja dan Stripe turun, maka, ya, keupayaan e-dagang kami tidak akan berfungsi. Walau bagaimanapun, adalah penting untuk diperhatikan bahawa Laman Web tidak akan turun. Ia boleh mengendalikan isu ini dengan anggun dengan memberitahu pengguna masalah. Halaman rendering sisi pelayan yang bergantung pada API Stripe untuk e-dagang akan menghadapi masalah yang sama. Dengan mengandaikan bahawa halaman rendering sisi pelayan masih memanggil kod back-end secara asynchronously untuk pembayaran, ia tidak akan lebih terdedah atau kurang rapuh daripada versi Jamstack. Sebaliknya, jika rendering sisi pelayan sebenarnya bergantung pada panggilan API, pengguna mungkin terjebak menunggu respons atau menerima mesej ralat (sesiapa yang menggunakan rangkaian sangat akrab dengan ini).

Bagi hujah kedua, sukar untuk mengukur sejauh mana aplikasi Web Jamstack dan aplikasi penyampaian sisi pelayan bergantung kepada pihak ketiga. Banyak aplikasi penyampaian pelayan hari ini masih bergantung kepada API untuk melaksanakan banyak fungsi, kerana ini membolehkan pembangunan yang lebih cepat, bidang kepakaran spesifik penyedia leverage, tanggungjawab pemuatan untuk isu-isu pematuhan undang-undang dan lain-lain, dan banyak lagi. Dalam kes ini, versi yang diberikan oleh pelayan akan sekali lagi tidak bergantung atau kurang bergantung daripada versi Jamstack. Diakui, jika permohonan anda bergantung terutamanya kepada penyelesaian dalaman atau buatan sendiri, maka perkara mungkin berbeza.

Salah faham 3: sukar untuk mengedit kandungan

Kev Quirk, dalam artikel "Mengapa Saya Tidak Menggunakan Penjana Laman Web Statik":

Mempunyai SSH ke dalam kotak Linux dan kemudian mengedit artikel di Vim kelihatan seperti halangan yang sangat tinggi untuk masuk ketika datang ke penulisan mudah alih. Sama ada anda suka atau tidak, dunia hari ini adalah mudah alih pertama, jadi penulisan mudah alih harus mudah.

Masalah ini terasa seperti warisan laman web statik pada masa lalu. Untuk menjadi jelas, anda tidak perlu SSH untuk memasukkan kotak Linux untuk mengedit kandungan laman web anda. Terdapat pelbagai pilihan CMS tanpa kepala, dari sumber bebas dan terbuka sepenuhnya kepada produk komersial yang menyediakan kandungan untuk perusahaan besar. Ciri -ciri penyuntingan yang mereka tawarkan adalah setanding dengan mana -mana CMS tradisional (saya telah bercakap tentang ini sebelum ini). Intinya ialah tidak ada alasan untuk mengedit fail Markdown, Yaml, atau JSON secara manual, walaupun di projek sampingan blog anda. Tidak pasti bagaimana untuk menyambungkan semua bahagian ini? Kami juga mempunyai penyelesaian!

Kritikan yang munasabah ialah CMS tanpa kepala dan proses membina boleh menyebabkan pemotongan antara kandungan yang diedit dan perubahan di laman web. Sukar untuk pratonton dengan tepat kesan perubahan di laman web secara langsung sebelum menerbitkan, atau tanpa proses pratonton membina kompleks. Ekosistem menyelesaikan masalah ini. Syarikat -syarikat seperti Stackbit (di mana saya bekerja) adalah alat bangunan yang menjadikan proses ini lancar.

Kami bukan satu -satunya yang komited untuk menyelesaikan masalah ini. Penyelesaian lain termasuk pratonton TinACMS dan Gatsby. Saya fikir kita akan melaksanakan kesederhanaan penyuntingan WYSIWYG pada alat seperti Wix on Jamstack.

Salah faham 4: SEO pada jamStack sukar

Kym Ellis, dalam artikel "What Jamstack Means For Marketing":

Memberi konsep plugin dan memilih laman web "Just HTML" Jamstack tidak bermakna anda perlu menyerah pada ciri-ciri atau tiba-tiba perlu belajar pengekodan seperti pemaju front-end untuk menguruskan laman web dan kandungannya.

Saya tidak pernah melihat isu ini sering berlaku dalam beberapa tahun kebelakangan ini, dan saya fikir ia kebanyakannya kritikan warisan dari era laman web statik, ketika menguruskan metadata yang berkaitan dengan SEO yang melibatkan penyuntingan manual dari frontmatters berasaskan YAML. Orang bimbang bahawa melakukan SEO dengan betul boleh menjadi membosankan dan sukar untuk dikekalkan, terutamanya jika anda ingin menyuntik metadata yang berbeza ke dalam setiap halaman unik yang dihasilkan, atau membuat data berstruktur seperti JSON-LD, yang penting untuk meningkatkan senarai carian anda.

Kemajuan Jamstack dalam pengurusan kandungan sering menangani kerumitan mengekalkan metadata SEO. Selain itu, kerana halaman itu telah ditetapkan, menambah sitemap dan JSON-LD agak mudah, dengan syarat metadata yang diperlukan wujud. Pre-rendering menjadikannya mudah untuk mencipta sumber yang enjin carian (iaitu Google) yang memerlukan laman web pengindeksan, dan mereka juga digabungkan dengan CDN, menjadikannya lebih mudah untuk mencapai tanda aras prestasi yang meningkatkan kedudukan laman web.

Pada asasnya, Jamstack adalah baik di "SEO Teknikal" sementara juga menyediakan editor kandungan dengan kata kunci dan metadata lain yang mereka perlukan. Untuk pemahaman yang lebih komprehensif mengenai Jamstack dan SEO, saya sangat mengesyorkan untuk memeriksa panduan Jamstack SEO Bejamas.

Salah faham 5: Jamstack memerlukan banyak kerangka JavaScript

Sebuah laman web yang indah yang menggalakkan kelebihan "Jamstack" sangat berguna jika anda cuba menjual laman web biasa kepada pengurusan yang terobsesi dengan rangka kerja terkini.

- Jdietrich, Berita Hacker

Baru-baru ini, Jamstack nampaknya telah menjadi sinonim dengan kerangka JavaScript front-end. Sesungguhnya, banyak penyelesaian yang paling terkenal bergantung kepada rangka kerja front-end, termasuk Gatsby (React), Next.js (React), Nuxt (Vue), Vuepress (Vue), GridSome (Vue), dan Scully (Angular). Ini seolah -olah diburukkan lagi dengan kekeliruan tentang "J" di Jamstack. Walaupun ia bermaksud JavaScript, ini tidak bermakna bahawa semua penyelesaian Jamstack adalah berasaskan JavaScript, dan tidak bermakna mereka semua memerlukan kerangka NPM atau JavaScript.

Sebenarnya, banyak alat yang paling banyak digunakan tidak dibina dengan JavaScript, terutamanya Hugo (Go), Jekyll (Ruby), Pelican (Python) dan Bridgetown (Ruby) yang baru dikeluarkan. Pada masa yang sama, alat seperti Eleventy dibina dengan JavaScript, tetapi tidak bergantung pada kerangka JavaScript. Tiada alat ini menghalang penggunaan kerangka JavaScript, tetapi mereka tidak memerlukannya.

Titik di sini bukan untuk meninggalkan rangka kerja JavaScript atau menggunakan alat mereka. Ini adalah alat yang hebat yang berjaya digunakan oleh banyak pemaju. Rangka kerja JavaScript boleh menjadi alat yang sangat kuat yang dapat memudahkan beberapa tugas yang sangat kompleks. Titik di sini adalah bahawa idea memerlukan rangka kerja JavaScript untuk menggunakan Jamstack adalah salah - Jamstack mempunyai 460 gaya!

Di mana kita dapat memperbaiki

Adakah itu benar? Jamstack adalah dunia yang ideal dalam pembangunan web di mana segala -galanya bukan sahaja sempurna, tetapi sangat mudah. Malangnya, tidak. Jamstack mempunyai banyak kritikan yang munasabah.

Kesederhanaan

Sebastian de Deyne, dalam artikel "Perkara untuk berfikir (dan soalan) selepas berurusan dengan Jamstack":

Dalam pengalaman saya, Jamstack (JavaScript, API, dan Tags) hebat sehingga ia tidak hebat lagi. Apabila suatu hari saya perlu menambah beberapa kandungan dinamik -dan hari ini selalu datang -saya mula menggaru kepala saya.

Sejujurnya: Tidak mudah untuk memulakan dengan Jamstack. Sudah tentu, ia mungkin tidak sukar untuk membina blog atau laman web mudah menggunakan penjana laman web statik. Tetapi, cuba membina laman web yang sebenar dengan sebarang fungsi dinamik, perkara -perkara dengan cepat menjadi rumit.

Anda biasanya melihat banyak pilihan untuk menyelesaikan tugas, yang membuat berat dan keburukan sukar. Salah satu aspek terbaik Jamstack ialah ia tidak preskriptif, tetapi ia boleh menjadikannya kelihatan tidak boleh diakses, meninggalkan kesan bahawa ia mungkin tidak sesuai untuk tugas -tugas yang kompleks.

Perkhidmatan mengikat

Apabila anda benar -benar mula membina ciri -ciri dinamik tersebut, laman web anda mungkin bergantung pada pelbagai perkhidmatan dan API. Anda mungkin memanggil CMS tanpa kepala untuk mendapatkan kandungan, hubungi fungsi tanpa pelayan untuk API untuk melakukan transaksi pembayaran, perkhidmatan carian seperti Algolia, dan lain -lain. Meletakkan semua bahagian ini bersama -sama boleh menjadi tugas yang sangat kompleks. Menambah fakta bahawa setiap bahagian biasanya mempunyai papan pemuka sendiri dan kemas kini API/SDK, perkara menjadi lebih rumit.

Itulah sebabnya saya fikir perkhidmatan seperti stackbit dan alat seperti Redwoodjs adalah penting kerana mereka menyatukan bahagian -bahagian yang berlainan di belakang laman web Jamstack dan menjadikan bahagian -bahagian itu lebih mudah untuk membina dan mengurus.

Terlalu banyak kerangka kerja

Pada pendapat saya, pergantungan kita terhadap kerangka JavaScript dalam pembangunan front-end moden telah banyak diperlukan untuk dipersoalkan baru-baru ini. Seperti yang dinyatakan oleh artikel Tim Kadlec, terdapat perdagangan. Seperti yang saya katakan sebelum ini, anda tidak memerlukan rangka kerja JavaScript untuk bekerja di Jamstack.

Walau bagaimanapun, kesan ini timbul kerana banyak alat Jamstack bergantung kepada kerangka JavaScript, dan cara kami mengajar Jamstack terutamanya tertumpu pada penggunaan kerangka. Saya faham sebabnya - banyak pemaju jamStack yang biasa dengan kerangka JavaScript dan mustahil untuk mengajar setiap alat, jadi anda memilih yang anda suka. Walau bagaimanapun, saya secara peribadi berfikir bahawa kejayaan jangka panjang Jamstack bergantung kepada fleksibiliti, yang (walaupun saya menyebut kesederhanaan di atas) bermakna kita perlu mempamerkan pelbagai penyelesaian yang ditawarkannya-sama ada menggunakan kerangka JavaScript atau tidak.

Ke mana hendak pergi seterusnya

Wow, awak buat! Saya tahu saya banyak mengatakan, mungkin lebih daripada yang saya sedar ketika saya mula menulis, jadi saya tidak akan mengganggu anda dengan kesimpulan yang panjang, selain mengatakan, jelas, saya telah membentangkan salah faham ini dari perspektif seseorang yang sangat yakin tentang nilai Jamstack, walaupun kekurangannya!

Sekiranya anda mencari artikel yang baik tentang kapan dan ketika tidak memilih Jamstack melalui penyampaian sisi pelayan, lihat artikel Chris Coyier baru-baru ini Statik atau tidak? 》.

Atas ialah kandungan terperinci 5 Mitos Mengenai Jamstack. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!