Viime aikoina lähinnä käyttökokemuksen ja suorituskyvyn suhteen.
Haluan esitellä 7 toimivaa periaatetta verkkosivustoille, jotka haluavat käyttää JavaScriptiä käyttöliittymänsä ohjaamiseen. Nämä periaatteet ovat tulosta työstäni web-suunnittelijana, mutta myös pitkäaikaisena WWW:n käyttäjänä.
JavaScriptistä on kiistatta tullut korvaamaton työkalu etupään kehittäjille. Nyt sen soveltamisala laajenee muille alueille, kuten palvelimiin ja mikro-ohjaimiin. Arvostetut yliopistot ovat valinneet tämän ohjelmointikielen opettamaan opiskelijoille tietojenkäsittelytieteen perusteita.
Samaan aikaan sen rooliin liittyy useita kysymyksiä erityiseen käyttöön, johon monien on vaikea vastata, mukaan lukien viitekehysten ja kirjastojen kirjoittajat.
- Pitäisikö JavaScriptiä käyttää selaimen ominaisuuksien korvikkeena: historia, navigointi, renderöinti?
- Onko backend kuolemassa? Pitääkö minun hahmontaa HTML-koodia ollenkaan?
- Onko totta, että yhden sivun sovellukset (SPA) ovat tulevaisuutta?
- Pitäisikö JS:n luoda sivuja verkkosivustossa ja hahmontaa sivuja verkkosovelluksissa?
- Pitääkö minun käyttää tekniikoita, kuten PJAX tai TurboLinks?
- Mikä on tarkka ero verkkosivuston ja verkkosovelluksen välillä? Pitäisikö yksi olla jäljellä?
Seuraava on yritykseni vastata näihin kysymyksiin. Yritin tutkia JavaScriptin käyttöä käyttäjän näkökulmasta (UX). Erityisesti hän kiinnitti huomiota ajatukseen minimoida aika, joka käyttäjältä kuluu häntä kiinnostavien tietojen hankkimiseen. Perusasioista alkaen verkkoteknologiat ja päättyen ennustukseen käyttäjän tulevasta käyttäytymisestä.
1. Sivujen renderöiminen palvelimella on valinnaista
tl;DR: Renderöintiä palvelimella ei tehdä hakukoneoptimoinnin, vaan suorituskyvyn vuoksi. Harkitse komentosarjoja, tyylejä ja myöhempiä API-pyyntöjä koskevia lisäpyyntöjä. Harkitse jatkossa käyttöä HTTP-menetelmä 2.0 työntö.
Ensinnäkin minun on huomautettava yleisestä virheestä erottaa "palvelimen tuottamat sovellukset" "yksisivuisista sovelluksista". Jos haluamme saavuttaa parhaan kokemuksen käyttäjän näkökulmasta, meidän ei pitäisi rajoittua sellaisiin rajoihin ja hylätä yksi vaihtoehto toisen hyväksi.
Syyt ovat varsin ilmeiset. Sivut välitetään Internetin kautta, jolla on fyysisiä rajoituksia, kuten Stuart Cheshire ikimuistoisesti havainnollistaa kuuluisassa esseessään "It's latency, stupid":
Stanfordin ja Bostonin välinen etäisyys on 4320 km.
Valon nopeus tyhjiössä on 300 x 10^6 m/s.
Valon nopeus optisessa kuidussa on noin 66 % valon nopeudesta tyhjiössä.
Valon nopeus optisessa kuidussa on 300 x 10^6 m/s * 0,66 = 200 x 10^6 m/s.
Yksisuuntaisen lähetyksen viive Bostoniin 4320 km / 200 x 10^6 m/s = 21,6 m/s.
Meno-paluuviive on 43,2 m/s.
Ping Stanfordista Bostoniin nykyaikaisessa Internetissä on noin 85 ms (…)
Joten nykyaikaiset Internet-laitteet lähettävät signaalin nopeudella 0,5 valon nopeudesta.
Ilmoitettua 85 ms:n tulosta voidaan parantaa (ja on jo hieman parempi), mutta on tärkeää ymmärtää, että tiedonsiirron viiveellä Internetin kautta on fyysinen raja riippumatta siitä, kuinka paljon kaistanleveyttä käyttäjien tietokoneilla lisätään. .
Tämä on erityisen tärkeää JavaScript-sovellusten kasvavan suosion vuoksi, koska ne sisältävät yleensä vain merkintöjä.
