Takriban miaka 15 iliyopita, nilikuwa nikifanya kazi katika kampuni ambapo tulitengeneza programu za mawakala wa usafiri, wafanyakazi wa viwanja vya ndege na kampuni za ndege. Pia tulijenga mfumo wetu wa ndani wa vipengele vya UI na uwezo wa programu ya ukurasa mmoja. Tulikuwa na vipengee vya kila kitu: sehemu, vitufe, vichupo, safu, jedwali la data, menyu, vichagua tarehe, teuzi, na chaguzi nyingi. Tulikuwa na sehemu ya div. Sehemu yetu ya div ilikuwa nzuri kwa njia, ilituruhusu kufanya pembe za mviringo kwenye vivinjari vyote, ambavyo, amini usiamini, halikuwa jambo rahisi kufanya wakati huo.
Kazi yetu ilifanyika wakati fulani katika historia yetu wakati JS, Ajax, na HTML thabiti zilionekana kama mapinduzi ambayo yalituleta katika siku zijazo. Ghafla, tunaweza kusasisha ukurasa kwa nguvu, kupata data kutoka kwa seva, na kuepuka kuelekeza kwenye kurasa zingine, ambazo zilionekana kuwa polepole na kuwaka mstatili mkubwa mweupe kwenye skrini kati ya kurasa hizo mbili. Kulikuwa na maneno, yaliyofanywa maarufu na Jeff Atwood (mwanzilishi wa StackOverflow), ambayo yalisomeka: “Programu yoyote ambayo inaweza kuandikwa katika JavaScript hatimaye itaandikwa katika JavaScript.”— Jeff Atwood
Kwetu wakati huo, hii ilionekana kama kuthubutu kwenda kuunda programu hizo. Ilionekana kama idhini kamili ya kufanya kila kitu na JS. Kwa hivyo tulifanya kila kitu na JS, na hatukuchukua wakati kutafiti njia zingine za kufanya mambo. Hatukuhisi motisha ya kujifunza vizuri kile HTML na CSS zinaweza kufanya. Hatukutambua mtandao kama jukwaa la programu linalobadilika kwa ujumla wake. Mara nyingi tuliiona kama jambo ambalo tulihitaji kufanyia kazi, hasa linapokuja suala la usaidizi wa kivinjari. Tunaweza tu kutupa JS zaidi ili kufanya mambo. Je, kuchukua muda wa kujifunza zaidi kuhusu jinsi mtandao ulivyofanya kazi na kile kilichokuwa kikipatikana kwenye jukwaa kungenisaidia? Hakika, labda ningeweza kunyoa rundo la nambari ambayo haikuhitajika sana. Lakini, wakati huo, labda sio sana. Unaona, tofauti za kivinjari zilikuwa muhimu sana wakati huo. Huu ulikuwa wakati ambapo Internet Explorer ilikuwa bado kivinjari kikuu, huku Firefox ikiwa ya pili, lakini ilianza kupoteza sehemu ya soko kutokana na Chrome kupata umaarufu haraka. Ingawa Chrome na Firefox walikuwa wazuri kabisa katika kukubaliana juu ya viwango vya wavuti, mazingira ambayo programu zetu zilikuwa zikifanya kazi yalimaanisha kwamba tulilazimika kuunga mkono IE6 kwa muda mrefu. Hata tuliporuhusiwa kuunga mkono IE8, bado tulilazimika kukabiliana na tofauti nyingi kati ya vivinjari. Sio hivyo tu, lakini mtandao wa wakati huo haukuwa na uwezo mwingi kama huo uliojengwa kwenye jukwaa.
Songa mbele hadi leo. Mambo yamebadilika sana. Sio tu kwamba tuna zaidi ya uwezo huu kuliko hapo awali, lakini kiwango cha kupatikana kwao kimeongezeka pia. Acha niulize swali tena, basi: Je, kuchukua muda wa kujifunza zaidi kuhusu jinsi mtandao unavyofanya kazi na kile kinachopatikana kwenye jukwaa kitakusaidia leo? Ndiyo kabisa. Kujifunza kuelewa na kutumia jukwaa la wavuti leo kunakuweka kwenye faida kubwa zaidi ya wasanidi programu wengine. Iwe unafanyia kazi utendakazi, ufikiaji, uwajibikaji, vyote kwa pamoja, au unasafirisha tu vipengele vya UI, ikiwa ungependa kufanya hivyo kama mhandisi anayewajibika, kujua zana ambazo unapatikana kwako hukusaidia kufikia malengo yako kwa haraka na bora zaidi. Baadhi ya Mambo Huenda Usihitaji Maktaba Kwa Ajili Ya Tena Kujua ni vivinjari vipi vinavyounga mkono leo, swali, basi, ni: Tunaweza kuacha nini? Je, tunahitaji kijenzi cha div kufanya pembe zilizo na mviringo mnamo 2025? Bila shaka, hatufanyi hivyo. Mali ya radius ya mpaka imeungwa mkono na vivinjari vyote vinavyotumika sasa kwa zaidi ya miaka 15 katika hatua hii. Na umbo la kona pia linakuja hivi karibuni, kwa pembe za mashabiki zaidi. Hebu tuangalie vipengele vya hivi majuzi ambavyo sasa vinapatikana katika vivinjari vyote vikuu, na ambavyo unaweza kutumia kuchukua nafasi ya vitegemezi vilivyopo kwenye msingi wako wa msimbo. Jambo kuu sio kuacha mara moja maktaba zako zote unazopenda na kuandika upya msingi wako wa kanuni. Kuhusu kila kitu kingine, utahitaji kuzingatia usaidizi wa kivinjari kwanza na uamue kulingana na vipengele vingine maalum kwa mradi wako. Vipengele vifuatavyo vinatekelezwa katika injini kuu tatu za kivinjari (Chromium, WebKit, na Gecko), lakini unaweza kuwa na mahitaji tofauti ya usaidizi wa kivinjari ambayo yanakuzuia kuzitumia mara moja. Sasa bado ni wakati mzuri wa kujifunza kuhusu vipengele hivi, ingawa, na labda kupanga kuvitumia wakati fulani. Popovers na Dialogs API ya Popover,
Hakika, kasi ya muunganisho wako wa mtandao labda imeongezeka, pia, lakini sivyo ilivyo kwa kila mtu. Na sio kila mtu ana uwezo sawa wa kifaa ama. Kuvuta msimbo wa watu wengine kwa mambo unayoweza kufanya ukitumia jukwaa, badala yake, pengine inamaanisha unasafirisha msimbo zaidi, na kwa hivyo kufikia wateja wachache kuliko kawaida. Kwenye wavuti, utendaji mbaya wa upakiaji husababisha viwango vikubwa vya kuachwa na kuumiza sifa ya chapa. Inaendesha Nambari Ndogo Kwenye Vifaa Zaidi ya hayo, nambari ya kuthibitisha unayotuma kwenye vifaa vya wateja wako huenda itafanya kazi haraka zaidi ikiwa itatumia vifupisho vichache vya JavaScript juu ya jukwaa. Pia pengine inasikika zaidi na inapatikana zaidi kwa chaguomsingi. Yote hii husababisha wateja wengi na wenye furaha. Angalia blogu ya kila mwaka ya pengo la ukosefu wa usawa wa utendaji wa mwenzangu Alex Russell, ambayo inaonyesha kuwa vifaa vinavyolipishwa kwa kiasi kikubwa havipo kwenye masoko yenye mabilioni ya watumiaji kutokana na ukosefu wa usawa wa mali. Na pengo hili linakua tu kwa wakati.
Mpangilio wa Uashi uliojengwa ndani Kipengele kimoja cha jukwaa la wavuti ambacho kinakuja hivi karibuni na ambacho ninafurahiya sana ni Uashi wa CSS.
Nianze kwa kueleza Uashi ni nini. Uashi ni Nini Uashi ni aina ya mpangilio ambayo ilifanywa maarufu na Pinterest miaka iliyopita. Huunda nyimbo huru za maudhui ambayo bidhaa hujipakia karibu na mwanzo wa wimbo kadri wawezavyo.
Watu wengi wanaona Uashi kama chaguo bora kwa portfolios na matunzio ya picha, ambayo kwa hakika inaweza kufanya. Lakini Uashi ni rahisi kunyumbulika kuliko unavyoona kwenye Pinterest, na hauzuiliwi tu na mipangilio inayofanana na maporomoko ya maji. Katika mpangilio wa uashi:
Nyimbo zinaweza kuwa safu au safu:
Nyimbo za yaliyomo sio lazima ziwe saizi sawa:
Vipengee vinaweza kujumuisha nyimbo nyingi:
Vitu vinaweza kuwekwa kwenye nyimbo maalum; sio lazima kila wakati kufuata algorithm ya uwekaji kiotomatiki:
Maonyesho Hapa kuna maonyesho machache rahisi niliyotengeneza kwa kutumia utekelezaji ujao wa Uashi wa CSS katika Chromium. Onyesho la matunzio ya picha, linaloonyesha jinsi vipengee (kichwa katika kesi hii) vinaweza kutumia nyimbo nyingi:
Matunzio mengine ya picha yanayoonyesha nyimbo za saizi tofauti:
Mpangilio wa tovuti ya habari na baadhi ya nyimbo pana kuliko nyingine, na baadhi ya vipengee vinavyochukua upana mzima wa mpangilio:
Ubao wa kanban unaoonyesha kuwa vitu vinaweza kuwekwa kwenye nyimbo maalum:
Kumbuka: Themaonyesho ya awali yalitengenezwa kwa toleo la Chromium ambalo bado halipatikani kwa watumiaji wengi wa wavuti, kwa sababu Uashi wa CSS ndio kwanza unaanza kutekelezwa katika vivinjari. Walakini, watengenezaji wa wavuti wamekuwa wakitumia maktaba kwa furaha kuunda mipangilio ya Uashi kwa miaka tayari. Maeneo Yanayotumia Uashi Leo Hakika, uashi ni kawaida sana kwenye wavuti leo. Hapa kuna mifano michache niliyopata kando na Pinterest:
Na mifano michache zaidi, isiyo wazi kabisa:
Kwa hivyo, mipangilio hii iliundwaje? Mazoezi Ujanja mmoja ambao nimeona ukitumika ni kutumia mpangilio wa Flexbox badala yake, kubadilisha mwelekeo wake kuwa safu, na kuiweka kuifunga. Kwa njia hii, unaweza kuweka vitu vya urefu tofauti katika safu wima nyingi, zinazojitegemea, na kutoa taswira ya mpangilio wa uashi:
Walakini, kuna mapungufu mawili na suluhisho hili:
Mpangilio wa vitu ni tofauti na utakavyokuwa na mpangilio halisi wa Uashi. Kwa Flexbox, vipengee vinajaza safu ya kwanza kwanza na, wakati imejaa, kisha uende kwenye safu inayofuata. Kwa Uashi, vitu vinaweza kupangwa katika wimbo wowote (au safu wima katika kesi hii) inayo nafasi zaidi. Lakini pia, na labda muhimu zaidi, kazi hii inahitaji kuweka urefu uliowekwa kwenye chombo cha Flexbox; la sivyo, hakuna kufungana kutatokea.
Maktaba za Uashi za wahusika wengine Kwa matukio mahiri zaidi, wasanidi programu wamekuwa wakitumia maktaba. Maktaba inayojulikana zaidi na maarufu kwa hii inaitwa Uashi, na inapakuliwa kama mara 200,000 kwa wiki kulingana na NPM. Squarespace pia hutoa sehemu ya mpangilio ambayo hutoa mpangilio wa Uashi, kwa njia mbadala isiyo na nambari, na tovuti nyingi huitumia. Chaguo hizi zote mbili hutumia msimbo wa JavaScript kuweka vipengee kwenye mpangilio. Uashi uliojengwa ndani Nimefurahiya sana kwamba Uashi sasa unaanza kuonekana kwenye vivinjari kama kipengele cha CSS kilichojengwa. Baada ya muda, utaweza kutumia Uashi kama vile unavyofanya Gridi au Flexbox, yaani, bila kuhitaji marekebisho yoyote au msimbo wa mtu mwingine. Timu yangu katika Microsoft imekuwa ikitekeleza usaidizi wa Uashi uliojengewa ndani katika mradi wa chanzo huria wa Chromium, ambao Edge, Chrome, na vivinjari vingine vingi hutegemea. Mozilla ilikuwa mchuuzi wa kwanza wa kivinjari kupendekeza utekelezaji wa majaribio wa Uashi mnamo 2020. Na Apple pia imekuwa na nia ya kufanya mpangilio huu mpya wa wavuti ufanyike. Kazi ya kusawazisha kipengele pia inaendelea, kukiwa na makubaliano ndani ya kikundi kazi cha CSS kuhusu mwelekeo wa jumla na hata onyesho jipya la aina ya onyesho: njia za gridi. Ikiwa unataka kujifunza zaidi kuhusu Uashi na kufuatilia maendeleo, angalia ukurasa wangu wa rasilimali za Uashi wa CSS. Baada ya muda, uashi unapokuwa kipengele cha Msingi, kama vile Gridi au Flexbox, tutaweza kuitumia na kufaidika nayo:
Utendaji bora, Mwitikio bora, Urahisi wa kutumia na kanuni rahisi.
Hebu tuyaangalie haya kwa karibu. Utendaji Bora Kutengeneza mfumo wako wa mpangilio unaofanana na uashi, au kutumia maktaba ya wahusika wengine badala yake, inamaanisha itabidi utekeleze msimbo wa JavaScript ili kuweka vipengee kwenye skrini. Hii pia inamaanisha kuwa nambari hii itatoa kizuizi. Hakika, hakuna kitakachoonekana, au vitu havitakuwa katika sehemu zinazofaa au saizi zinazofaa, hadi msimbo huo wa JavaScript ufanyike. Mpangilio wa uashi mara nyingi hutumiwa kwa sehemu kuu ya ukurasa wa wavuti, ambayo ina maana kwamba msimbo utakuwa ukifanya maudhui yako kuu kuonekana baadaye kuliko vile yangeweza kuonekana, ikishusha hadhi ya LCP yako, au kipimo kikubwa cha Rangi ya Kuridhika, ambayo ina jukumu kubwa katika utendaji unaotambulika na uboreshaji wa injini ya utafutaji. Nilijaribu maktaba ya Uashi JS na mpangilio rahisi na kwa kuiga muunganisho wa polepole wa 4G kwenye DevTools. Maktaba sio kubwa sana (24KB, 7.8KB gzipped), lakini ilichukua 600ms kupakia chini ya hali yangu ya jaribio. Hapa kuna rekodi ya utendakazi inayoonyesha muda mrefu wa upakiaji wa milisekunde 600 kwa maktaba ya Uashi, na kwamba hakuna shughuli nyingine ya uwasilishaji iliyofanyika wakati hiyo ikiendelea:
Kwa kuongeza, baada ya muda wa awali wa kupakia, hati iliyopakuliwa basi ilihitaji kuchanganuliwa, kukusanywa, na kisha kukimbia. Yote ambayo, kama ilivyotajwa hapo awali, yalikuwa yanazuia utoaji wa ukurasa. Kwa utekelezaji wa Uashi uliojengwa ndani katika kivinjari, hatutakuwa na hati ya kupakia na kuendesha. Injini ya kivinjari itafanya tu mambo yake wakati wa hatua ya awali ya kutoa ukurasa. Mwitikio Bora Sawa na wakati ukurasa unapopakia kwa mara ya kwanza, kubadilisha ukubwa wa dirisha la kivinjari husababisha kutoa mpangilio katika ukurasa huo tena. Kwa wakati huu, ingawa, ikiwa ukurasa unatumia maktaba ya Uashi JS, hakuna haja ya kupakia hati tena, kwa sababu tayari iko.hapa. Hata hivyo, msimbo unaohamisha vipengee katika maeneo sahihi unahitaji kutekelezwa. Sasa maktaba hii inaonekana kuwa haraka sana katika kufanya hivi wakati ukurasa unapakia. Hata hivyo, huhuisha vipengee vinapohitaji kuhamia mahali tofauti kwenye kubadilisha ukubwa wa dirisha, na hii inaleta tofauti kubwa. Bila shaka, watumiaji hawatumii muda kubadilisha ukubwa wa madirisha ya vivinjari vyao kama vile sisi wasanidi programu tunavyofanya. Lakini uzoefu huu wa kubadilisha ukubwa uliohuishwa unaweza kuwa wa kustaajabisha na kuongeza muda unaotambulika kwamba inachukua kwa ukurasa kukabiliana na ukubwa wake mpya. Urahisi wa Kutumia Na Msimbo Rahisi Jinsi ilivyo rahisi kutumia kipengele cha wavuti na jinsi msimbo unavyoonekana rahisi ni mambo muhimu ambayo yanaweza kuleta mabadiliko makubwa kwa timu yako. Haziwezi kamwe kuwa muhimu kama uzoefu wa mwisho wa mtumiaji, bila shaka, lakini uzoefu wa wasanidi huathiri udumishaji. Kutumia kipengele cha wavuti kilichojengewa ndani huja na manufaa muhimu kwa upande huo:
Wasanidi programu ambao tayari wanajua HTML, CSS, na JS kuna uwezekano mkubwa wa kuwa na uwezo wa kutumia kipengele hicho kwa urahisi kwa sababu kimeundwa ili kuunganishwa vyema na kuendana na jukwaa lingine la wavuti. Hakuna hatari ya kuvunja mabadiliko kuanzishwa katika jinsi kipengele kinatumika. Kuna karibu sifuri hatari ya kipengele hicho kuacha kutumika au kutodumishwa.
Kwa upande wa Uashi uliojengwa ndani, kwa sababu ni muundo wa zamani, unaitumia kutoka kwa CSS, kama Gridi au Flexbox, hakuna JS inayohusika. Pia, sifa nyingine za CSS zinazohusiana na mpangilio, kama vile pengo, hufanya kazi unavyotarajia. Hakuna hila au suluhisho za kujua kuzihusu, na mambo unayojifunza yameandikwa kwenye MDN. Kwa Uashi JS lib, uanzishaji ni ngumu kidogo: inahitaji sifa ya data iliyo na sintaksia mahususi, pamoja na vipengee vya HTML vilivyofichwa ili kuweka safu na saizi za pengo. Zaidi, ikiwa unataka kupanua safu wima, unahitaji kujumuisha saizi ya pengo mwenyewe ili kuzuia shida: