Viktige hensyn når du bygger websider på en enkel side

Enkelttside webapplikasjoner - eller SBOer, som de ofte refereres til - blir raskt de facto-standarden for webapputvikling. Det faktum at en stor del av appen kjøres inne i en enkelt nettside, gjør det veldig interessant og tiltalende, og den akselererte veksten av nettleseregenskaper skaper oss nærmere dagen, når alle appene kjører helt i nettleseren.

Teknisk sett er de fleste nettsider allerede SBOer; Det er kompleksiteten til en side som skiller en nettside fra en webapp. Etter min mening blir en side en app når du inkorporerer arbeidsflyter, CRUD-operasjoner og statlig ledelse rundt bestemte oppgaver. Du jobber med et SPA når hver av disse oppgavene foregår på samme side (ved hjelp av AJAX for klient / serverkommunikasjon, selvfølgelig).

La oss starte med denne felles forståelsen, og dykke inn i noen av de viktigere tingene som bør vurderes når du bygger SBO.


Det er mange poeng å vurdere før du bygger en ny app; For å gjøre saken verre, kan det ekspansive webutviklingslandskapet skremme fra begynnelsen. Jeg har vært i de forstyrrende skoene, men heldigvis har de siste årene kommet til enighet om de verktøyene og teknikkene som gjør applikasjonsutviklingsopplevelsen så hyggelig og produktiv som mulig.

De fleste appene består av både klient og server-side brikker; Selv om denne artikkelen hovedsakelig fokuserer på klientsiden av en app, gir jeg noen server-sidepoeng mot slutten av denne artikkelen.

Det er en fargerik blanding av teknologier på klientsiden, samt flere biblioteker og praksiser som muliggjør en produktiv apputviklingserfaring. Dette kan oppsummeres ved hjelp av følgende ordsky.

Jeg vil utvide på hvert av punktene ovenfor i de følgende avsnittene.


Velger en applikasjonsramme

Det er en overflod av rammer å velge mellom. Her er bare en håndfull av de mest populære:

  • Backbone
  • CanJS
  • SpineJS
  • BatmanJS
  • EmberJS
  • AngularJS
  • Meteor

Å velge et rammeverk er lett et av de viktigste valgene du vil gjøre for appen din. Sikkert, vil du velge det beste rammeverket for teamet ditt og din app. Hver av de ovennevnte rammene innlemmer MVC-mønsteret (i en eller annen form). Som sådan er det ganske vanlig å referere til dem som MVC-rammer. Hvis vi måtte bestille disse rammene på en skala av kompleksitet, læringskurve og funksjonssett, fra venstre til høyre, det kan se ut som:

Selv om de er forskjellige i implementeringen og nivået av raffinement, gir alle de ovennevnte rammene noen vanlige abstraksjoner, for eksempel:

Bare se på de siste fem årene har det vært en eksplosiv vekst i biblioteker, verktøy og praksis.

  • Modell: En omslag rundt en JSON datastruktur med støtte for eiendomsmeglere / setters og varselmelding.
  • Samling: en samling av modeller. Gir merknader når en modell er lagt til, fjernet eller endret i samlingen.
  • arrangementer: Et standardmønster for å abonnere på og publisere varsler.
  • Utsikt: En baksideobjekt for et DOM-fragment med støtte for å lytte til DOM-hendelser i forhold til DOM-fragmentet. Visningen har tilgang til tilsvarende modelleksempel. I noen rammer er det også a Controller som orkestrerer endringer mellom visningen og modellen.
  • routing: Navigering i en app via nettadresser. Avhenger av nettleserhistorikk-API.
  • synkronisering: Vedvarende modellendringer via Ajax-anrop.

Mer avanserte rammer, som CanJS, BatmanJS, EmberJS og AngularJS, utvider disse grunnleggende funksjonene ved å gi støtte for automatiske data-bindende og kundeside-maler. Malerne er data-bundet og beholder visningen synkronisert med eventuelle endringer i modellen. Hvis du bestemmer deg for å velge et avansert rammeverk, vil du sikkert få mange funksjoner utenom boksen, men det forventer også at du bygger appen din på en bestemt måte.

Av alle de tidligere nevnte rammene er Meteor det eneste fullstabelige rammeverket. Det gir verktøy ikke bare for utvikling av klientsiden, men gir deg også et server-side-stykke, via NodeJS, og end-to-end-modellsynkronisering via MongoDB. Dette betyr at når du lagrer en modell på klienten, vedvarer den automatisk i MongoDB. Dette er et fantastisk alternativ, hvis du kjører en Node-backend og bruker MongoDB for utholdenhet.

Basert på kompleksiteten til appen din, bør du velge rammen som gjør deg mest produktive. Det vil sikkert være en læringskurve, men det er en engangsavgift du betaler for ekspedisjonsutvikling. Sørg for å gi deg tid til å evaluere disse rammene, basert på et representativt brukstilfelle.

Merk: Hvis du vil lære mer om disse rammene fra sine skapere, kan du høre på disse videoene fra ThroneJS.


Klient-side maler

De mest populære JavaScript-baserte templeringssystemene er Underscore maler og håndtak.

Noen av de avanserte rammene fra den forrige delen tilbyr innebygde templeringssystemer.

EmberJS har for eksempel innebygd støtte for håndtak. Imidlertid må du vurdere en templerende motor hvis du bestemmer deg for å bruke et mager rammeverk, for eksempel Ryggrad. Underscore er et utmerket utgangspunkt hvis du har begrensede krav til templering. Ellers fungerer håndtakene bra for mer avanserte prosjekter. Den tilbyr også mange innebygde funksjoner for mer ekspressive maler.

Hvis du finner ut at du trenger et stort antall kundeside maler, kan du spare litt beregningstid ved å forhåndskompilere malene på serveren. Pre-compilation gir deg enkle JavaScript-funksjoner som du påberoper for å forbedre belastningstiden på siden. Handlebars støtter pre-compilation, noe som gjør det verdt tid og krefter å fullt ut utforske.

ExpressJS-brukere kan til og med bruke den samme templerende motoren på klienten som på serveren, og gir deg fordelene ved å dele maler mellom både klienten og serveren.


Modulær utvikling

Bruk av en forprosessor krever et ekstra trinn i byggeprosessen.

JavaScript-kode er tradisjonelt lagt til siden, via >