Ember. Det beste alternativet.

Hvis du vurderer hvilket verktøy du skal bruke for å hjelpe deg med å bygge ut din neste applikasjon, må du vurdere Ember.js. Å bygge ut en frontend-applikasjon er ekstremt kompleks og omfatter en rekke problemer. Det er et eventyr du ikke vil ta alene, og du vil være forberedt på et hvilket som helst scenario som dukker opp. Ember har ryggen og jeg skal belyse hvorfor du bør vurdere det for neste prosjekt.

Biblioteker er ikke rammer.

Biblioteker er verktøy. De lar deg gjøre en spesifikk ting. Tenk på en pensel, den gjør en jobb og bare en jobb. Rammer omfatter flere verktøy. I Ember har disse verktøyene blitt kuratert av et fellesskap for å være de beste løsningene på noen av de mest kompliserte og vanlige problemene i frontend-utvikling.

Ember er en godt kuratert verktøykasse

Problemet jeg ser er at frontend-samfunnet som helhet har forvirret de to ganske mye. For eksempel er Glimmer.js, Vue.js og React.js visningslagsverktøy - de hjelper deg med å administrere gjengivelseselementer på en side. Imidlertid finnes det verktøy som takler andre problemer, for eksempel React-Router og router.js for rutingstøtte samt create-react-app og ember-cli for tooling.

Rammer omfatter disse verktøyene slik at du kan komme i gang med å bygge appen din. Mitt første rammeverk var Rails, et utmerket eksempel på et rammeverk sammensatt av noen utmerkede biblioteker. Problemet er at et backend-rammeverk ikke oversetter mentalt på frontenden, fordi frontend tross alt er bare UI - ikke sant?

Nei. Frontend-utvikling inkluderer støtte for nett-api, verktøy, distribusjon, testing og mer. Disse individuelle brikkene er forbedret av mange biblioteker, men å ha et rammeverk i lommen er avgjørende - det gjør at du kan levere programvare raskere, og minimere beslutningsutmattethet.

Leverer programvare.

Det er mitt hovedansvar å sikre at god programvare blir sendt. Som programvareingeniør bygger jeg ting. Disse tingene står overfor kunden, og alt som kommer i veien for det målet er en distraksjon.

Noen vil kanskje si at å etablere et rammeverk er ansvaret til en programvareingeniør. Og det er. Imidlertid må vi også balansere kostnadene for gjøremål kontra brukerens verdi.

Lagene jeg elsker å jobbe med mest omsorg for fraktprogramvare. De erkjenner at det er en delikat balanse og tydelig forskjell mellom behovet for å løse vanlige utviklingsproblemer med kundens behov.

Ember gjør dette utenfor boksen. Det er etablert et fellesskap som jobber sammen for å løse vanlige problemer og samtidig levere funksjonene du trenger mest i appen din. Hvis det ikke har det du trenger, har det omfattende addon-økosystemet definitivt en løsning for deg. Hvis det til slutt ikke fungerer, er jeg sikker på at du finner andre som vil være villige til å hjelpe deg.

Fordeler for å velge Ember.

Et enklere liv.

Siden jeg har valgt Ember, har jeg ikke bekymret for verktøy, støtte til nett-api, overholdelse av sikkerhet og mer. Hvorfor det? Fordi samfunnet består av eksperter på disse feltene som har viet livet til å hjelpe deg, meg og alle andre.

Testing i Ember er et perfekt eksempel på hvordan livet har blitt enklere. Enhet, integrasjon og full på akseptstesting er en del av rammene. Du må bare velge hvilken testløper (f.eks. Qunit [2], mokka, osv.) Du vil bruke. Alt annet kommer sammen, og du kan raskt begynne å skrive og utføre testene dine.

Å gi ingeniører muligheten til å smertefritt skrive akseptstester kan fjerne kravet om en egen QA-avdeling, spesielt for små team og trange budsjetter. Og du får alt dette gratis.

Et vennlig samfunn.

Samfunnet er sannsynligvis et av de beste aspektene ved å velge Ember. Fordi samtaler er gjennomsiktige og åpne for publikum, er grunnene bak hvorfor et mønster implementeres over en annen eller hvorfor en viss teknikk er bedre - alt dokumentert på nettet [3]. Klar for deg til å gjennomgå, kritisere, unngå eller implementere.

Legg også merke til at Ember ikke går bort. Stiftelsen som Ember-samfunnet har opprettet, er bygget av en koalisjon av enkeltpersoner og selskaper. Alle i samfunnet kommer fra forskjellige bakgrunner, med forskjellige problemer og massevis av meninger. Men det er her kjernestyrken i rammene ligger - i en sunn diskusjon, implementering og levering av testede løsninger.

Dokumentasjon.

Biblioteket er ekstremt godt dokumentert [4]. Fra kildekode, guider eller slakk kanalsamtaler - du kan finne svaret på spørsmålet ditt. Og enda bedre - det er tatt på alvor. Dokumentasjon er versjonert, samfunnsbaserte samtaler på Github er grundige og kjerneteamet har implementert retningslinjer som hjelper med denne standardprosedyren å bli implementert i det omfattende addon-systemet.

Vanlige kritikker av Ember.

Det er ikke kult.

Det er vel det - det er en mengde funksjoner i rammene jeg satser på at du gjerne vil bruke. For eksempel fungerer kildekart ut av boksen - noe som betyr at du kan bruke Chromes utviklerverktøy til å bygge appen din omfattende.

Å favorisere stabilitet er kanskje ikke prangende hvis du begynner, og det kan plage deg at Ember ikke lar deg ødelegge ting. Vi pleide å gjøre det, og det var ikke så gøy.

Den gode nyheten er at stemmen din kan bli hørt. Ember har en organisert RFC-prosess for å diskutere store endringer i rammene. Du kan lære om endringer før de skjer, gi dine to øre eller lage din egen RFC for tilbakemelding.

Læringskurven er bratt.

Ember består av forskjellige viktige brikker som hjelper til med å lette applikasjonsutviklingsprosessen. For eksempel er ruting, distribusjon og automatisert testing bakt i. Hvilket betyr at du ikke bare trenger å lære om Embers anbefalte designmønstre - men du må lære om andre aspekter for å sende god fungerende programvare.

Dette gjør læringskurven litt bratt, fordi det er mer enn bare å lære om å komponere komponenter for det visuelle laget. Argumentet om Embers bratte læringskurve har blitt brukt mot den, men jeg vil utfordre det med det faktum at du til slutt vil trenge å lære deg disse andre aspektene av utviklingen når dine behov vokser utover synslaget.

Merk at dette har fått oppmerksomheten til kjerneteamet, og det er en stor bevegelse for å forenkle ting for å sikre at inngangsbarrieren blir forenklet. For eksempel å flytte til JavaScript-klasser, fjerne behovet for this.get og this.set og mer har blitt foreslått for å fjerne de største forvirringskildene for JavaScript-utviklere.

Innfødt er ikke en primær innbygger.

Ember er et rammeverk forpliktet til Single Page Application (SPA) -arkitekturen. Fordelene du får fra SPA er fordelene med Ember. Siden SPA ikke er et konsept for native apps, er Ember en dårlig passform for native.

Husk at Ember går foran med progressive webapper. Så hvis det er et alternativ du vil vurdere, sjekk ut å bygge en progressiv webapp med Ember av mixonic.

Hvorfor du bør velge Ember.

Ember blir brukt i oppstartverdenen og på bedriftsnivå. Det er forskjellige applikasjoner der ute som har vist seg å være motstandsdyktige overfor tid. Det brukes i mange bransjer og har vist seg å skalere raskt og effektivt. Ember har hjulpet bedrifter med å sende verdi og stabilisere utviklingsteam.

Fra et programvareteknisk perspektiv er stabilisering av et team verdt mer enn noe annet jeg har jobbet med. Når du kan jobbe på et team og dele det samme språket med liten eller ingen forvirring over teknikker, vokser teamet og blir mer verdifullt enn det faktiske produktet.

Fra et produktperspektiv kan du se rask fremgang. Hvis verktøyet du har valgt, gir deg muligheten til å iterere raskt på funksjoner og implementere tilbakemeldinger på kort tid - virker det for meg som det rette verktøyet for jobben.

Og til syvende og sist fra et forretningsperspektiv, jo før jeg kan tilføre produktet mitt produkt desto bedre.

Hvis du vil at teamet ditt skal være mer produktivt og fornøyd mens du leverer verdi, bør du vurdere å velge Ember. Hvis du fortsatt er nølende, kan du kontakte meg på Twitter på @alvincrespo, så hjelper jeg deg med å finne ut det beste verktøyet for jobben.

Takk.

Takk til alle som hjalp meg med å skrive dette innlegget. Din tid og krefter blir satt veldig pris på, og jeg håper at ordene mine her gjenspeiler din anmeldelse.

Notater.

[1] create-react-app (CRA) er litt basert på den samme filosofien som ember-cli. CRA gir en begynnelsesopplevelse med å lage en app, men når dine behov overstiger målene for det prosjektet - er du alene. På den annen side gir ember-cli et addon-økosystem som gir deg muligheten til å koble deg inn i cli for å tilpasse byggene dine.

[2] ember-qunit er standard testløper, og krever ingen konfigurasjon foran

[3] Eksempler på gjennomsiktige samtaler:

  • https://github.com/emberjs/rfcs/pull/176
  • https://github.com/emberjs/rfcs/pull/240

[4] Eksempler på dokumentasjon:

  • https://github.com/emberjs/ember.js/blob/v2.15.0/packages/ember-runtime/lib/mixins/observable.js#L96
  • https://github.com/emberjs/ember.js/blob/v2.15.0/packages/ember-routing/lib/system/route.js#L1458