Kokia yra internetinio tinklalapio kūrimo ateitis?
Kitą dieną manęs paprašė tai padaryti. Sakyčiau, kad esu nepakankamai kvalifikuotas, kad galėčiau atsakyti į šį klausimą, kaip ir kiekvienas žmogus. Jei jums tikrai reikėjo atsakymų į šį klausimą, tikriausiai turėtumėte sujungti daugelio kūrėjų apklausos rezultatų duomenis.
aš esu mažai kvalifikuotas. Be to, kad valdau šią svetainę, kuri reikalauja manęs kiekvieną dieną galvoti apie „front end“ kūrimą ir kelia daugybę pokalbių apie „front end“ kūrimą, aš pats esu aktyvus kūrėjas. Aš dirbu prie „CodePen“, kuris yra gana avinų kūrėjų avilys. Taip pat kiekvieną savaitę apie tai kalbu „ShopTalk Show“ su įvairiausiais svečiais ir keliauju į konferencijas, daugiausia skirtas „front end“ plėtrai.
Taigi leisk man į tai durti.
Vėlgi, atsisakymai:
- Tai nėra išsami
- Tai tik palaidi spėjimai
- Aš tik vienas bičiulis
Vartotojų lūkesčiai didėja.
Tai nustato etapą:
Didėja tai, ko prašoma svetainių. Kūrėjų prašoma labai greitai sukurti labai sudėtingus dalykus, kad jie veiktų labai gerai ir labai greitai.
Nauja „JavaScript“ yra čia.
Kad ir koks nuostabus mums buvo „jQuery“, jis baigėsi naujam kūrimui. Aš turiu omenyje ne tik ES6 +, kurį dabar aprėpėme, bet tai tiesa. Susidūrėme su bėda dirbdami su DOM per tiesiogiai ir elgdamiesi su ja kaip su valstybine parduotuve. Kai atidariau, vartotojų lūkesčiai, taigi ir sudėtingumas, auga. Turime suvaldyti tą sudėtingumą.
Valstija yra didelė koncepcija, apie kurią kalbėjome. Internetinės svetainės bus kuriamos galvojant, kokią valstybę reikia valdyti, tada sukūrus tinkamas parduotuves šiai valstybei.
Naujos sistemos yra čia. Žmogus, „React“, „Vue“, kampinis, „Svelte“, bet kas. Jie pritaria idėjai dirbti su valstybe, komponentais ir tvarkyti DOM mums.
Dabar jie gali varžytis dėl greičio, funkcijų ir API malonumo.
„TypeScript“ taip pat atrodo kaip ilgalaikis nugalėtojas, nes jis gali dirbti su bet kuo ir suteikia stabilumo bei geresnę redaktoriaus patirtį kūrėjams.
Mes nekuriame puslapių, mes kuriame sistemas.
Stiliaus vadovai. Projektavimo sistemos. Rašto bibliotekos. Šie dalykai tampa standartine interneto projektų proceso dalimi. Jie tikriausiai taps pagrindiniu rezultatu. Sistema gali sukurti viską, ko reikia. „Puslapių“ sąvoka nebelieka. Komponentai yra sudedami kartu, kad sukurtų tai, ką mato vartotojai. Tai gali sudaryti UX žmonės, sąveikos dizaineriai, net rinkodara.
Naujas „JavaScript“ tai puikiai pritaiko.
Riba tarp savojo ir žiniatinklio yra neryški.
Kas yra geriau, eskizas ar figma? Mes juos vertiname pagal jų ypatybes, o ne pagal tai, kad viena yra gimtoji programa, o kita – žiniatinklio programa. Ar turėčiau naudoti „Slack“ ar „TweetDeck“ gimtąją programą, ar tiesiog atidaryti skirtuką? Bet kuriuo atveju tai identiška. Kartais interneto programa yra tokia gera, norėčiau, kad ji būtų gimtoji, kad ji galėtų būti piktograma mano doke ir turėti nuolatinį prisijungimą, todėl naudoju tokius dalykus kaip „Mailplane“, skirtas „Gmail“, ir „Paws“, skirtas „Trello“.
Aš reguliariai naudoju programas, kurios atrodo taip, kaip būtų reikia būti gimtosiomis programomis, bet paversti tokiomis pat geromis ar geresnėmis žiniatinklyje. Tiesiog žiūrėdamas į garso / vaizdo programas, „Skype“ turi visų funkcijų programą, „Lightstream“ yra pilna tiesioginio srauto studija, o „Zencaster“ gali įrašyti kelių takelių aukštos kokybės garsą. Visa tai yra teisinga naršyklėje.
Tai tik pavyzdžiai dirbdamas gerą darbą žiniatinklyje. Pati interneto technologija čia taip pat labai stiprėja. Aptarnavimo darbuotojai pateikia mums svarbių dalykų, pvz., Galimybę naudotis neprisijungus ir tiesioginius pranešimus. „Web Audio“ API. „Web Payments“ API. Žiniatinklis turėtų tapti dominuojančia programų kūrimo platforma.
Vartotojai naudos daiktus, kurie yra geri, ir nesvarstys, ar jiems svarbu, kaip jie buvo pastatyti.
URL vis dar yra žudikų funkcija.
Žiniatinklis iš tikrųjų tai teisingai suprato. Turėti universalų būdą pereiti tiesiai į konkretų dalyką yra neįtikėtina. URL leidžia paieškos sistemas, tai yra viena iš svarbiausių žmogaus naujovių. URL leidžia dalytis ir žymėti. URL yra vienodos rinkodaros sąlygos. Kiekvienas gali apsilankyti URL, nėra vartininko.
Našumas yra pagrindinis žaidėjas.
Tolerancija blogai veikiančioms svetainėms mažės. Visi tikėsis, kad viskas bus beveik akimirksniu. Svetainės, kurios nėra, bus gėdingos.
CSS gaus daug modulinį.
Rašydami stilius, visada pasirinksime. Ar tai pasaulinis stilius? Ar aš tyčia skleidžiu šį stilių visoje svetainėje? Arba aš rašau CSS, skirtą šiam komponentui? CSS bus padalintas per pusę tarp šių dviejų. Konkretiems komponentams būdingi stiliai bus aprėpti, susieti su komponentu ir naudojami pagal poreikį.
CSS išankstinis apdorojimas lėtai išnyks.
Daugelis žudikinių išankstinių procesorių funkcijų jau pateko į CSS (kintamieji) arba jas galima geriau valdyti pažangesniais kūrimo procesais (importu). Įrankiai, kuriuos galiausiai naudosime savo CSS moduliavimui ir aprėpimui, tam tikra prasme vis dar yra CSS pirminiai procesoriai, todėl jie gali perimti darbą, kas lieka dėl išankstinio apdorojimo būtinybės. Iš standartinio dabartinių išankstinių procesorių rinkinio manyčiau, kad pagrindinis, kurio mes praleisime, yra miksinai. Jei gimtoji CSS paspartins diegti mišinius (galbūt @apply) ir išplės (galbūt @extend), tai pagreitins šiandieninio išankstinių procesorių pasenimą.
Gerai mokėti HTML ir CSS išlieka gyvybiškai svarbu.
HTML konstravimo būdas ir jo patekimas į DOM ir toliau keisis. Bet vis tiek turėsite žinoti, kaip atrodo geras HTML. Turėsite žinoti, kaip susisteminti HTML taip, kad tai būtų naudinga jums, prieinama vartotojams ir pritaikyta stiliui.
CSS nusileidimas naršyklėje ir jo taikymas ir toliau keisis, tačiau vis tiek reikės, kaip juo naudotis. Turėsite žinoti, kaip atlikti maketus, valdyti tarpus, koreguoti tipografiją ir būti skoningiems, kaip visada.
Sukūrimo procesai taps konkurencingi.
Kadangi našumas turi tiek daug reikšmės ir yra labai daug galimybių išmintingai atlikti našumą, pamatysime naujoves, kaip sukurti savo kodų bazes. Tokie įrankiai, kaip „webpack“ (medžio purtymas, kodo padalijimas), čia jau daro daug, tačiau yra daug vietos leisti automatiniams įrankiams magiškai suprasti, kaip mūsų kodas galiausiai patenka į naršykles. Pirmųjų naudingų krovinių optimizavimas. Turto gabenimas pagal jų kritiškumą. Sprendimas, kas kur ir kaip siunčiamas. Nieko nesiunčiant, kas nenaudojama.
Tobulėjant interneto platformai (pvz., Kliento patarimai), kūrimo procesai bus pritaikyti ir geriausia praktika vystysis kartu su ja, kaip visada.