Nykyinen web vs. se web, jota tarvitsemme

Muistatko ajan, kun web-kehitys oli suoraviivaista? Kun specit mahtuivat päähän. Nyt HTML-spesifikaatio on yli 18 megatavua tiivistä tekstiä, joka päivittyy viikoittain. Selainten tuki vaihtelee. Kaikki rakentavat korjauksia outoihin reunaehtoihin.

Tulee mieleen: entä jos web rakennettaisiin alusta asti toisin?

Ongelman ydin: Monimutkaisuus suojamuurina

Tässä ikävä totuus: webin liiallinen monimutkaisuus ei ole vahinko. Kun speksit ovat ylivoimaisen sekavia, vain isot firmat pystyvät tekemään selaimia. Kilpailu kuihtuu, innovaatiot hidastuvat. Suuret pelaajat muokkaavat webiä rahavaikutteiden mukaan.

Ajattele peliteoriaa. Turvonnut spesifikaatio sadoilla erikoisominaisuuksilla tarkoittaa:

• Uuden selaimen kehitys vaatii tuhansia insinöörejä
• Pienet tiimit putoavat pelistä
• Istuvat pelaajat sanelevat säännöt
• Kehitys matelee

Se on tarkoituksellista – jos olet jo voitolla.

Miltä yksinkertainen web näyttäisi?

Kuvittele spesifikaatio, joka mahtuu zip-tiedostoon. Jopa tulostettavaksi. Tarkka semanttinen versiointi (1.2.3, ei "elävä standardi"). Julkaistu versio ei muutu. Ota versio 1.2.0, lähde erämaasaarelle ja rakenna toimiva selain pelkällä sillä.

Tiukka kielioppi anteeksiantavuuden sijaan

Nykyinen "virheiden korjaus" -ajattelu on parsijoiden painajainen. Selaimet tulkitsevat rikki menneen HTML:n, koska "web vaatii". Entä jos käännettäisiin tämä?

Speksi muodollisella, yksiselitteisellä kieliopilla. Sivut joko kelpaavat tai eivät. Ei tulkintoja. Speksit pakotetaan tarkoiksi. Kehittäjät siirtyvät helppoihin formaatteihin kuten Markdowniin tai YAML:iin, jotka kääntävät validiksi merkkaukseksi. Työkalut kevenevät. Kaikki hyötyvät.

Semanttinen versiointi sopimuksena

Viikoittaiset muutokset tekevät kehityksestä mahdotonta. Semanttinen versiointi korjaa:

• Patch-päivitykset korjaavat vain kirjoitusvirheet – kielioppi ennallaan
• Minor-päivitykset lisäävät yhteensopivia ominaisuuksia
• Major-päivitykset tuovat rikkovia muutoksia

Kirjoita koodi versiolle 1.2.0. Se toimii 1.2.0–1.3.x-selaimissa, ei 1.1.x:ssä. Voit suunnitella.

Teksti ensin: tappiominaisuus

Rikkaan median ja skriptauksen palvonta on monimutkaistanut webin turhaan. Entä jos keskitytään tekstiin ja semanttiseen rakenteeseen?

Teksti on kannettava, käännettävä, saavutettava ja kevyt. Tekstiin perustuva sivu:

• Mukautuu mihin tahansa näyttöön
• Toimii screen readereissa ilman kikkailua
• Luetaan ilman CSS:ää
• Pakkaantuu naurettavan pieneksi

Ei askel taaksepäin. Paluu webin voimaan: tiedonvaihtoon ihmisten välillä.

Skriptauskysymys

Käy peruskysymys: skriptaus oli virhe.

Älä sulje välilehteä. En väitä, että interaktiivisuus on huonoa. Ongelma on täyden ohjelmointikielen upottaminen joka sivuun. Koodi mille tahansa sivustolle lähes täydellä järjestelmätasolla on hullua.

Entä jos dynaamisuus tulisi rajoitetusta deklaratiivisesta järjestelmästä? Monimutkaiset appit erillisinä ohjelmina, ei selaimessa?

Miksi tämä merkitsee nyt

Et ehkä rakenna webiä uudelleen, mutta periaatteet vaikuttavat työhösi:

Domain-rekisteröijille ja hosting-alustoille: Yksinkertaisempi web tuo parempaa turvallisuutta, selkeitä vaatimuksia ja helpompaa optimointia. Me NameOceanissa tuhlaamme insinööritunteja webin outouksiin. Puhdas speksi keventää kuormaa.

Kehittäjille: Selkeät speksit vähentävät bugeja, nopeuttavat kehitystä ja helpottavat debuggausta. Voit tähdätä versioihin luottavaisin mielin.

Startupille: Alempi kynnys tuo kilpailua, innovaatioita ja parempia työkaluja.

Käyttäjille: Pienemmät tiedostot, nopeat lataukset, parempi saavutettavuus ja turvallisuus.

Standardien valtaanpito

Tärkein oivallus: standardit kehittyvät vallan mukaan, ei pelkällä teknisyydellä. Kun turvotus on suojamuuri, webin korjaaminen on vaikeaa.

Uudelleenajattelu vaatii peliteoriaa: miten pidetään speksit avoimina ja yksinkertaisina, kun monimutkaisuus maksaa?

Vastaus: rajoitukset kuten tiedostokoot, selkeä hallinto, yhteensopivuustakuut ja yhteisön valvonta. Ei teknistä. Poliittista.

Mitä voimme tehdä tänään

Et haarukoi koko webiä, mutta voit:

• Rakenna yksinkertaista. Rajoita JavaScriptiä. Käytä semanttista HTML:ää. Testaa ilman CSS:ää.
• Tähtää tiettyihin versioihin. Dokumentoi yhteensopivuutesi.
• Painota tekstiä. Tee sivut luettaviksi pelkkänä tekstinä. Käytä Markdownia.
• Kyseenalaista turhat vendor-ominaisuudet. Ei kaikkea tarvitse käyttää.
• Tue avoimia standardeja ja vaihtoehtoja. Pienet selaimet, open source ja yhteisöhankkeet tarvitsevat periaatteellisia kehittäjiä.

Todellinen kysymys

Web ei tarvitse tätä monimutkaisuutta. Sen olemassaolo kertoo standardien kehityksestä kapitalismissa. Tekninen ratkaisu on simppeli; poliittinen vaikea.

Ei väliä, syntyykö "haaruweb". Tärkeää on kysyä. Se pitää meidät rehellisinä. Peritty web ei ole väistämätön – se on valittu. Ja valittu voidaan valita uudelleen.

Seuraavalla kerralla kun taistelet selainongelmien kanssa tai kopioit monimutkaista featuria kilpailijoilta, muista: ei tarvitse olla näin.