Ойролцоогоор 15 жилийн өмнө би аялал жуулчлалын агентууд, нисэх онгоцны буудлын ажилчид, агаарын тээврийн компаниудад зориулсан программуудыг бүтээдэг компанид ажиллаж байсан. Мөн бид UI бүрэлдэхүүн хэсгүүд болон нэг хуудасны програмын чадавхид зориулан өөрийн дотоод тогтолцоог бий болгосон. Бид бүх зүйлд зориулсан бүрэлдэхүүн хэсгүүдтэй байсан: талбарууд, товчлуурууд, табууд, мужууд, өгөгдлийн хүснэгтүүд, цэсүүд, огноо сонгогчид, сонголтууд, олон сонголтууд. Бидэнд div бүрэлдэхүүн хэсэг ч байсан. Дашрамд хэлэхэд, манай div бүрэлдэхүүн хэсэг нь маш сайн байсан бөгөөд энэ нь бүх хөтөч дээр дугуйрсан булангуудыг хийх боломжийг бидэнд олгосон бөгөөд энэ нь тухайн үед хийхэд тийм ч хялбар биш байсан.
JS, Ajax болон динамик HTML нь биднийг ирээдүйд авчирсан хувьсгал гэж үзэж байсан түүхэн дэх бидний ажил өрнөсөн. Гэнэт бид хуудсыг динамикаар шинэчилж, серверээс өгөгдөл авч, бусад хуудсууд руу шилжихээс зайлсхийх боломжтой байсан нь удаан гэж үзэгдэж, хоёр хуудасны хооронд дэлгэцэн дээр том цагаан дөрвөлжин харагдах болно. Жефф Атвудын (StackOverflow-ийн үүсгэн байгуулагч) алдартай хэллэг байсан бөгөөд үүнд: "JavaScript дээр бичиж болох аливаа програмыг эцэст нь JavaScript дээр бичих болно." - Жефф Атвуд
Тэр үед бидний хувьд энэ нь үнэхээр явж, тэдгээр апп-уудыг бүтээх зүрхлэх мэт санагдаж байсан. JS-тэй бүх зүйлийг хийх нь зүгээр л зөвшөөрөл юм шиг санагдав. Тиймээс бид JS-тэй бүх зүйлийг хийсэн бөгөөд бусад зүйлийг хийх арга замыг судлахад үнэхээр цаг зарцуулаагүй. Бид HTML болон CSS юу хийж чадахыг зохих ёсоор сурах урам зоригийг үнэхээр мэдэрсэнгүй. Бид вэбийг бүхэлд нь хөгжиж буй програмын платформ гэж ойлгоогүй. Бид үүнийг ихэвчлэн, ялангуяа хөтөчийн дэмжлэгтэй холбоотой ажиллах шаардлагатай гэж үзсэн. Бид ажлаа дуусгахын тулд илүү олон JS шидэж болно. Вэб хэрхэн ажилладаг, платформ дээр байгаа зүйлсийн талаар илүү ихийг мэдэхийн тулд цаг гаргавал надад тусалсан болов уу? Мэдээжийн хэрэг, би үнэхээр шаардлагагүй олон тооны кодыг хуссан байж магадгүй юм. Гэхдээ тэр үед тийм ч их биш байж магадгүй. Тэр үед хөтөчийн ялгаа нэлээд их байсныг та харж байна. Энэ бол Internet Explorer хөтөч хэвээр байсан бөгөөд Firefox хоёрдугаарт бичигдэж байсан ч Chrome хурдацтай алдартай болсноор зах зээлд эзлэх хувийг алдаж эхэлсэн үе байсан. Хэдийгээр Chrome болон Firefox нь вэб стандартын талаар нэлээд сайн тохирдог байсан ч манай програмууд ажиллаж байсан орчин нь бид IE6-г удаан хугацаанд дэмжих шаардлагатай болсон гэсэн үг. Бид IE8-ийг дэмжихийг зөвшөөрсөн ч хөтчүүдийн хооронд маш их ялгааг даван туулах шаардлагатай болсон. Үүгээр ч зогсохгүй тухайн үеийн вэб нь платформ дээр тийм олон чадамжгүй байсан.
Өнөөдрийг хурдан урагшлуулаарай. Бүх зүйл асар их өөрчлөгдсөн. Бид урьд өмнөхөөсөө илүү олон боломжуудтай болоод зогсохгүй, ашиглах боломжтой болох хурд нь ч нэмэгдсэн. Дараа нь би дахин асуулт асууя: Вэб хэрхэн ажилладаг, платформ дээр юу байгаа талаар илүү ихийг мэдэхийн тулд цаг гаргавал өнөөдөр танд туслах болов уу? Үнэхээр тийм. Өнөөдөр вэб платформыг ойлгож, ашиглаж сурах нь таныг бусад хөгжүүлэгчдээс асар их давуу талтай болгодог. Гүйцэтгэл, хүртээмж, хариу үйлдэл, бүгдийг нь хамтад нь ашиглах эсвэл зүгээр л UI функцуудыг илгээх эсэхээс үл хамааран хэрэв та хариуцлагатай инженерийн хувьд үүнийг хийхийг хүсч байвал өөрт байгаа хэрэгслүүдийг мэдэх нь зорилгодоо илүү хурдан, илүү сайн хүрэхэд тусална. Номын сан танд хэрэггүй байж магадгүй зарим зүйлс Өнөөдөр ямар хөтчүүд дэмждэгийг мэдэхийн тулд асуулт гарч ирнэ: Бид юуг орхиж чадах вэ? 2025 онд дугуйрсан булангуудыг хийхэд div бүрэлдэхүүн хэрэгтэй юу? Мэдээжийн хэрэг, бид тэгэхгүй. Border-radius шинж чанарыг одоо ашиглаж байгаа бүх хөтчүүд 15-аас дээш жил дэмжсэн. Мөн илүү сонирхолтой булангуудад зориулсан булангийн хэлбэр тун удахгүй гарах болно. Одоо бүх томоохон хөтчүүдэд байгаа харьцангуй сүүлийн үеийн боломжуудыг харцгаая, мөн та өөрийн кодын санд байгаа хамаарлыг солиход ашиглаж болно. Гол нь бүх хайртай номын сангуудыг шууд хаяад кодын баазаа дахин бичих биш юм. Бусад бүх зүйлийн хувьд та эхлээд хөтчийн дэмжлэгийг анхаарч, төсөлдөө хамаарах бусад хүчин зүйлс дээр үндэслэн шийдэх хэрэгтэй. Дараах функцууд нь хөтчийн гурван үндсэн хөдөлгүүрт (Chromium, WebKit, Gecko) хэрэгждэг боловч танд өөр өөр хөтчийн дэмжлэг шаардлагууд байж болох бөгөөд энэ нь таныг шууд ашиглахаас сэргийлдэг. Одоо ч гэсэн эдгээр функцуудын талаар мэдэхэд тохиромжтой цаг хэвээр байгаа бөгөөд магадгүй тэдгээрийг хэзээ нэгэн цагт ашиглахаар төлөвлөж магадгүй юм. Поповер ба харилцан яриа Popover API,
Мэдээжийн хэрэг, таны интернетийн хурд нэмэгдсэн байх, гэхдээ энэ нь хүн бүрт тийм биш юм. Мөн хүн бүр ижил төхөөрөмжийн чадвартай байдаггүй. Платформ ашиглан хийж болох зүйлсийн хувьд гуравдагч этгээдийн кодыг татах нь та илүү их код илгээж, ердийнхөөсөө цөөхөн хэрэглэгчтэй болно гэсэн үг юм. Вэб дээр ачааллын муу гүйцэтгэл нь их хэмжээний орхигдоход хүргэж, брэндийн нэр хүндэд сөргөөр нөлөөлдөг. Төхөөрөмжүүд дээр бага код ажиллуулах Цаашилбал, таны үйлчлүүлэгчдийнхээ төхөөрөмж дээр илгээдэг код нь платформ дээр цөөн JavaScript хийсвэрлэл ашигладаг бол илүү хурдан ажиллах магадлалтай. Энэ нь өгөгдмөлөөр илүү мэдрэмжтэй, илүү хүртээмжтэй байх магадлалтай. Энэ бүхэн нь илүү олон, аз жаргалтай үйлчлүүлэгчдэд хүргэдэг. Баялгийн тэгш бус байдлын улмаас олон тэрбум хэрэглэгчтэй зах зээлд дээд зэрэглэлийн төхөөрөмжүүд бараг байдаггүйг харуулсан миний хамтран зүтгэгч Алекс Расселын жил бүр гаргадаг гүйцэтгэлийн тэгш бус байдлын зөрүүг шалгана уу. Мөн энэ ялгаа зөвхөн цаг хугацааны явцад нэмэгдсээр байна.
Баригдсан өрлөгийн зохион байгуулалт Удахгүй гарах вэб платформын нэг онцлог бөгөөд миний сэтгэл хөдөлж байгаа зүйл бол CSS Masonry юм.
Өрлөг гэж юу болохыг тайлбарлаж эхэлье. Өрлөг гэж юу вэ Өрлөг нь олон жилийн өмнө Pinterest-ээс алдартай болсон зохион байгуулалтын нэг төрөл юм. Энэ нь агуулгын бие даасан трекүүдийг үүсгэдэг бөгөөд тэдгээрийн дотор зүйлс нь замын эхлэлд аль болох ойртдог.
Олон хүмүүс өрлөгийг портфолио, гэрэл зургийн галерей хийхэд тохиромжтой сонголт гэж үздэг бөгөөд үүнийг хийх нь гарцаагүй. Гэхдээ өрлөг нь Pinterest дээр харж байгаагаас илүү уян хатан бөгөөд зөвхөн хүрхрээ шиг зохион байгуулалтаар хязгаарлагдахгүй. Өрлөгийн зохион байгуулалтад:
Замууд нь багана эсвэл мөр байж болно:
Агуулгын бичлэгүүд бүгд ижил хэмжээтэй байх албагүй:
Зүйлс нь олон замд багтаж болно:
Эд зүйлсийг тодорхой зам дээр байрлуулж болно; Тэд үргэлж автомат байршуулах алгоритмыг дагаж мөрдөх шаардлагагүй:
Демо Chromium-д удахгүй хэрэгжих CSS Masonry програмыг ашиглан хийсэн цөөн хэдэн энгийн үзүүлбэрүүд энд байна. Зургийн цомгийн демо нь эд зүйлс (энэ тохиолдолд гарчиг) хэрхэн олон замыг хамарч болохыг харуулсан:
Өөр өөр хэмжээтэй замуудыг харуулсан зургийн цомог:
Мэдээллийн сайтын бүдүүвч зарим хэсэг нь бусдаасаа илүү өргөн, зарим зүйл нь байршлын бүхэл бүтэн өргөнийг хамарсан:
Эд зүйлсийг тодорхой зам дээр байрлуулж болохыг харуулсан канбан самбар:
Жич: TheӨмнөх үзүүлэнгүүд нь ихэнх вэб хэрэглэгчдэд хараахан болоогүй байгаа Chromium-ийн хувилбараар хийгдсэн, учир нь CSS Masonry нь хөтчүүдэд дөнгөж хэрэгжиж эхэлж байна. Гэсэн хэдий ч вэб хөгжүүлэгчид олон жилийн турш өрлөгийн зохион байгуулалтыг бий болгохын тулд номын сангуудыг аз жаргалтайгаар ашиглаж ирсэн. Өнөөдөр өрлөг ашиглаж буй сайтууд Үнэн хэрэгтээ, өрлөг өнөөдөр вэб дээр нэлээд түгээмэл байдаг. Pinterest-ээс гадна миний олсон хэдэн жишээ энд байна:
Бас тодорхой бус цөөн хэдэн жишээ:
Тэгэхээр, эдгээр зохион байгуулалтыг хэрхэн бүтээсэн бэ? Товчлох арга замууд Миний харсан нэг заль мэх бол оронд нь Flexbox-ын байршлыг ашиглаж, чиглэлийг багана болгон өөрчилж, боож өгөхөөр тохируулах явдал юм. Ингэснээр та өөр өөр өндөртэй зүйлсийг хэд хэдэн бие даасан баганад байрлуулж, өрлөгийн зохион байгуулалттай мэт сэтгэгдэл төрүүлэх боломжтой.
Гэсэн хэдий ч энэ тойрон гарах арга замд хоёр хязгаарлалт бий:
Зүйлүүдийн дараалал нь жинхэнэ өрлөгийн зохион байгуулалттай байхаас өөр юм. Flexbox-ийн тусламжтайгаар зүйлүүд эхлээд эхний баганыг дүүргэж, дүүрсэн үед дараагийн багана руу очно. Өрлөгийн тусламжтайгаар эд зүйлсийг аль замд (эсвэл энэ тохиолдолд багана) илүү зайтай байхаар овоолох болно. Гэхдээ бас, магадгүй хамгийн чухал нь энэ тойрч гарах арга зам нь Flexbox контейнерт тогтмол өндрийг тохируулахыг шаарддаг; эс бөгөөс ямар ч боодол үүсэхгүй.
Гуравдагч талын өрлөгийн номын сангууд Илүү дэвшилтэт тохиолдлуудын хувьд хөгжүүлэгчид номын санг ашиглаж ирсэн. Үүний хамгийн алдартай бөгөөд алдартай номын сан нь өрлөг гэж нэрлэгддэг бөгөөд NPM-ийн дагуу долоо хоногт 200,000 удаа татагддаг. Squarespace нь мөн өрлөгийн зохион байгуулалтыг кодгүй хувилбараар гаргах байршлын бүрэлдэхүүн хэсгийг өгдөг бөгөөд олон сайт үүнийг ашигладаг. Эдгээр хоёр сонголт хоёулаа JavaScript кодыг байршилд байрлуулахдаа ашигладаг. Баригдсан өрлөг Өрлөг одоо хөтчүүдэд суулгасан CSS функц болж гарч ирж байгаад би үнэхээр баяртай байна. Цаг хугацаа өнгөрөхөд та Grid эсвэл Flexbox шиг өрлөгийг ашиглах боломжтой болно, өөрөөр хэлбэл ямар ч тойрон гарах арга зам эсвэл гуравдагч талын код шаардлагагүй болно. Майкрософт дахь миний баг Edge, Chrome болон бусад олон хөтчүүд дээр суурилсан Chromium нээлттэй эхийн төсөлд өрлөгийн суулгасан дэмжлэгийг хэрэгжүүлж байна. Mozilla нь 2020 онд өрлөгийн туршилтын хэрэгжилтийг санал болгосон анхны хөтөч үйлдвэрлэгч байсан юм. Мөн Apple энэ шинэ вэб зохион байгуулалтыг анхдагч болгохыг маш их сонирхож байсан. Энэ функцийг стандартчилах ажил ч урагшилж байгаа бөгөөд CSS-ийн ажлын хэсэг ерөнхий чиглэл, тэр ч байтугай шинэ дэлгэцийн төрөл болох grid-lanes-ийн талаар тохиролцож байна. Хэрэв та өрлөгийн талаар илүү ихийг мэдэж, ахиц дэвшлийг хянахыг хүсвэл миний CSS өрлөгийн нөөцийн хуудсыг үзнэ үү. Цаг хугацаа өнгөрөхөд өрлөг нь Grid эсвэл Flexbox-ын нэгэн адил үндсэн функц болох үед бид үүнийг зүгээр л ашиглаж, ашиг тусыг нь авах боломжтой болно:
Илүү сайн гүйцэтгэл, Илүү сайн хариу үйлдэл үзүүлэх, Хэрэглэхэд хялбар, энгийн код.
Эдгээрийг нарийвчлан авч үзье. Илүү сайн гүйцэтгэл Өрлөг шиг өөрийн зохион байгуулалтын систем хийх эсвэл оронд нь гуравдагч талын номын санг ашиглах нь дэлгэцэн дээр зүйлсийг байрлуулахын тулд JavaScript кодыг ажиллуулах шаардлагатай болно гэсэн үг юм. Энэ нь мөн энэ кодыг блоклох болно гэсэн үг юм. Үнэхээр JavaScript кодыг ажиллуулж дуустал юу ч харагдахгүй, эсвэл зүйл зөв газар эсвэл зөв хэмжээтэй байх болно. Өрлөгийн бүдүүвчийг вэб хуудасны үндсэн хэсэгт ихэвчлэн ашигладаг бөгөөд энэ нь код нь таны үндсэн агуулгыг байж болохоосоо хожим гаргаж, таны LCP буюу хамгийн том контент бүхий будгийн хэмжигдэхүүнийг доройтуулж, гүйцэтгэл болон хайлтын системийг оновчтой болгоход чухал үүрэг гүйцэтгэдэг гэсэн үг юм. Би Masonry JS номын санг энгийн зохион байгуулалттай, DevTools дээр удаан 4G холболтыг загварчлах замаар туршиж үзсэн. Номын сан тийм ч том биш (24KB, 7.8KB gzipped), гэхдээ миний туршилтын нөхцөлд ачаалахад 600 мс зарцуулсан. Өрлөгийн номын санд 600 мс ачаалах хугацаа урт байсныг харуулсан гүйцэтгэлийн бичлэгийг энд оруулав, мөн энэ үед өөр ямар ч дүрслэх үйл ажиллагаа болоогүй байна:
Нэмж дурдахад, эхний ачаалсны дараа татаж авсан скриптийг задлан шинжилж, эмхэтгэж, дараа нь ажиллуулах шаардлагатай болсон. Өмнө дурьдсанчлан энэ бүхэн хуудасны дүрслэлийг хааж байсан. Хөтөч дээр суурилуулсан өрлөгийн хэрэгжилтийн ачаар бид ачаалах, ажиллуулах скриптгүй болно. Хөтчийн хөдөлгүүр нь хуудасны эхний үе шатанд л хийх болно. Илүү сайн хариу үйлдэл Хуудсыг анх ачаалахтай адил хөтчийн цонхны хэмжээг өөрчлөх нь тухайн хуудасны байршлыг дахин гаргахад хүргэдэг. Энэ үед хэрэв хуудас нь Masonry JS номын санг ашиглаж байгаа бол скриптийг дахин ачаалах шаардлагагүй, учир нь энэ нь аль хэдийн байна.энд. Гэсэн хэдий ч зүйлсийг зөв газарт шилжүүлэх кодыг ажиллуулах шаардлагатай. Одоо энэ номын сан нь хуудсыг ачаалах үед үүнийг хийхэд маш хурдан байх шиг байна. Гэсэн хэдий ч энэ нь цонхны хэмжээг өөрчлөхөд өөр газар шилжих шаардлагатай үед эд зүйлсийг хөдөлгөөнтэй болгодог бөгөөд энэ нь ихээхэн өөрчлөлтийг бий болгодог. Мэдээжийн хэрэг, хэрэглэгчид бид хөгжүүлэгчид шиг хөтчийн цонхны хэмжээг өөрчлөхөд цаг зарцуулдаггүй. Гэхдээ энэ хүүхэлдэйн киноны хэмжээг өөрчлөх туршлага нь нэлээд төвөгтэй байж болох бөгөөд хуудсыг шинэ хэмжээнд дасан зохицоход шаардагдах хугацааг нэмэгдүүлдэг. Хэрэглэхэд хялбар, энгийн код Вэб функцийг ашиглах нь хэр хялбар, код нь хэр энгийн харагдах нь танай багт томоохон өөрчлөлт авчрах чухал хүчин зүйлүүд юм. Мэдээжийн хэрэг тэд эцсийн хэрэглэгчийн туршлага шиг чухал байж чадахгүй, гэхдээ хөгжүүлэгчийн туршлага нь засвар үйлчилгээ хийхэд нөлөөлдөг. Суурилуулсан вэб функцийг ашиглах нь энэ тал дээр чухал ач холбогдолтой:
HTML, CSS болон JS-ийг аль хэдийн мэддэг хөгжүүлэгчид энэ функцийг хялбархан ашиглах боломжтой, учир нь энэ нь бусад вэб платформтой сайн уялдаж, нийцтэй байхаар бүтээгдсэн. Энэ функцийг хэрхэн ашиглах талаар өөрчлөлт оруулах эрсдэл байхгүй. Энэ функцийг ашиглахаа больсон эсвэл засвар үйлчилгээ хийгээгүй болох эрсдэл бараг байхгүй.
Баригдсан өрлөгийн хувьд, энэ нь энгийн загвар учраас та үүнийг Grid эсвэл Flexbox шиг CSS-ээс ашигладаг бөгөөд JS оролцдоггүй. Мөн цоорхой гэх мэт байршилтай холбоотой бусад CSS шинж чанарууд нь таны бодож байсан шиг ажилладаг. Мэдэх ямар ч заль мэх, тойрон гарах арга зам байхгүй бөгөөд таны сурсан зүйлсийг MDN дээр баримтжуулсан болно. Masonry JS lib-ийн хувьд эхлүүлэх нь бага зэрэг төвөгтэй байдаг: багана болон зайны хэмжээг тохируулахын тулд далд HTML элементүүдийн хамт тодорхой синтакс бүхий өгөгдлийн атрибут шаардлагатай. Дээрээс нь, хэрэв та багануудыг хооронд нь холбохыг хүсвэл асуудлаас зайлсхийхийн тулд зайны хэмжээг өөрөө оруулах хэрэгтэй:
<загвар> .track-sizer, .зүйл { өргөн: 20%; } .sutter-sizer { өргөн: 1 рем; } .зүйл { өндөр: 100px; маржин-блок-төгсгөл: 1rem; } .зүйл:n-р хүүхэд(сондгой) { өндөр: 200px; } .зүйл--өргөн2 { өргөн: calc(40% + 1rem); }
Үүнийг суурилуулсан өрлөгийн хэрэгжилт ямар харагдахтай харьцуулж үзье: <загвар> .контейнер { дэлгэц: сүлжээний эгнээ; сүлжээний эгнээ: давтах (4, 20%); цоорхой: 1 цаг; } .зүйл { өндөр: 100px; } .зүйл:n-р хүүхэд(сондгой) { өндөр: 200px; } .зүйл--өргөн2 { сүлжээ багана: хүрээ 2; }
Илүү энгийн, илүү авсаархан код нь цоорхой гэх мэт зүйлсийг ашиглаж болох ба торных шиг 2-р дамжсан замуудыг ашиглах боломжтой бөгөөд зайны хэмжээг багтаасан зөв өргөнийг тооцоолох шаардлагагүй. Юу бэлэн, хэзээ бэлэн болохыг яаж мэдэх вэ? Ерөнхийдөө асуулт бол та JS номын сан дээр суурилагдсан өрлөгийг ашиглах эсэх биш, харин хэзээ юм. Masonry JS номын сан нь гайхалтай бөгөөд олон жилийн турш вэб платформ дахь цоорхойг нөхөж ирсэн бөгөөд олон аз жаргалтай хөгжүүлэгчид болон хэрэглэгчдийн хувьд. Мэдээжийн хэрэг та үүнийг суурилуулсан өрлөгийн хэрэгжилттэй харьцуулах юм бол энэ нь хэд хэдэн сул талуудтай боловч хэрэв энэ хэрэгжилт бэлэн болоогүй бол эдгээр нь чухал биш юм. Би хөтөч борлуулагч дээр ажилладаг учраас эдгээр шинэ вэб платформын онцлогуудыг жагсаахад хялбар байдаг, тиймээс би юу болохыг мэдэх хандлагатай байдаг. Гэхдээ хөгжүүлэгчид шинэ зүйлийг хянах нь хэцүү гэдгийг санал асуулгын дараа байнга хуваалцдаг. Мэдээлэлтэй байх нь хэцүү бөгөөд компаниуд суралцахыг тэр бүр чухалчилдаггүй. Үүнд туслахын тулд танд хэрэгтэй мэдээллээ хурдан авах боломжтой энгийн бөгөөд авсаархан аргаар шинэчлэлтүүдийг хангадаг цөөн хэдэн эх сурвалжийг энд оруулав.
Вэб платформ нь судлаач сайтын онцлогтой: Та түүний хувилбарын тэмдэглэлийн хуудсыг сонирхож магадгүй юм. Хэрэв та RSS-д дуртай бол хувилбарын тэмдэглэл, түүнчлэн Шинээр ашиглах боломжтой, өргөн ашиглах боломжтой мэдээллийн хангамжийг үзээрэй.
ВэбПлатформын төлөвийн хяналтын самбар: Танд түүний янз бүрийн үндсэн жилийн хуудаснууд таалагдаж магадгүй.
Chrome платформын статусын замын газрын зургийн хуудас.
Хэрэв танд бага зэрэг хугацаа байгаа бол хөтөч үйлдвэрлэгчдийн гаргасан тэмдэглэлийг сонирхож магадгүй юм:
Chrome Ирмэг Firefox Сафари
Илүү их эх сурвалжийг авахыг хүсвэл миний Вэб платформ дээр ажиллах Cheatsheet-ийг шалгана уу. Миний зүйл одоо болтол хэрэгжээгүй байна Энэ бол асуудлын нөгөө тал юм. Хэдийгээр та цаг хугацаа, эрч хүч, дагаж мөрдөх арга замыг олсон ч дуу хоолойгоо сонсох, дуртай функцээ хэрэгжүүлэхэд сэтгэл дундуур байдаг. Магадгүй та тодорхой нэг алдаа шийдэгдэхийг эсвэл ямар нэгэн функц байхгүй хэвээр байгаа хөтөч рүү илгээхийг олон жилийн турш хүлээж байсан байх. Миний хэлэх зүйл бол хөтөч үйлдвэрлэгчид сонсдог. Би хөгжүүлэгчийн дохио, санал хүсэлтийн талаар байнга ярилцдаг хэд хэдэн байгууллага хоорондын багуудын нэг хэсэг юм. Бид хөтөч бүрийн дотоод болон гадаад/олон нийтийн форум, нээлттэй эхийн төсөл, блог, санал асуулгын олон янзын эх сурвалжуудыг авч үздэг. Мөн бид хөгжүүлэгчдэд өөрсдийн хэрэгцээ, хэрэглээний тохиолдлуудыг хуваалцах илүү сайн арга замыг бий болгохыг үргэлж хичээдэг. Тиймээс, хэрэв боломжтой бол хөтөч үйлдвэрлэгчдээс илүү ихийг шаардаж, шаардлагатай функцуудыг хэрэгжүүлэхийн тулд бидэнд шахалт үзүүлээрэй. Үүнд цаг хугацаа шаардагдахаас гадна айлган сүрдүүлэх (ороход гарах өндөр саад тотгорыг дурдахгүй өнгөрч болохгүй), гэхдээ энэ нь бас үр дүнтэй гэдгийг би ойлгож байна. Та өөрийн (эсвэл танай компанийн) дуу хоолойг сонсох хэд хэдэн арга зам байна: Жил бүрийн JS-ийн төлөв, CSS-ийн төлөв, HTML-ийн төлөвийн судалгааг авна уу. Хөтөч үйлдвэрлэгчид ажлаа хэрхэн эрэмбэлэх талаар тэд чухал үүрэг гүйцэтгэдэг. Хэрэв танд стандартад суурилсан API-г хөтчүүдэд тогтмол хэрэгжүүлэх шаардлагатай бол дараагийн Interop төслийн давталт дээр санал оруулах талаар бодож үзээрэй. Үүнд илүү их цаг хугацаа шаардагдах боловч Shopify болон RUMvision нь Interop 2026-д зориулсан хүслийн жагсаалтаа хэрхэн хуваалцсаныг анхаарч үзээрэй. Энэ мэт дэлгэрэнгүй мэдээлэл нь хөтөч үйлдвэрлэгчдэд чухал ач холбогдолтой байж болох юм. Хөтөч үйлдвэрлэгчдэд нөлөөлөх илүү хэрэгцээтэй холбоосуудыг авахыг хүсвэл миний "Вэб платформын навигаци" Cheatsheet-ийг үзнэ үү. Дүгнэлт Энэ нийтлэлийг дуусгахын тулд танд хэдэн зүйлийг бодож үлдээсэн гэж найдаж байна:
Өрлөг болон бусад удахгүй гарах вэб функцүүдийн талаархи сэтгэл хөдлөл. Таны ашиглаж эхлэх хэдэн вэб функцууд. Захиалгат эсвэл гуравдагч талын кодуудын цөөн хэдэн хэсгийг та суулгасан функцуудыг ашиглахын тулд устгаж болно. Ирж буй зүйлийг хянаж, хөтөч үйлдвэрлэгчдэд нөлөөлөх хэд хэдэн арга замууд.
Хамгийн гол нь вэб платформыг бүрэн хэмжээгээр ашиглахын ач тусыг би танд ойлгуулсан гэдэгт итгэлтэй байна.
