Glød. Din bedste indsats.

Hvis du overvejer, hvilket værktøj du skal bruge til at hjælpe dig med at opbygge din næste applikation, skal du overveje Ember.js. At bygge en frontend-applikation er ekstremt kompleks og omfatter en række forskellige problemer. Det er et eventyr, som du ikke ønsker at tage alene, og du vil være forberedt på ethvert scenarie, der dukker op. Ember har din ryg, og jeg vil kaste lys over, hvorfor du skal overveje det til dit næste projekt.

Biblioteker er ikke rammer.

Biblioteker er værktøjer. De gør det muligt for dig at gøre en bestemt ting. Overvej en pensel, den gør kun et job og kun et job. Rammer omfatter flere værktøjer. I Ember er disse værktøjer blevet samlet af et samfund for at være de bedste løsninger på nogle af de mest komplicerede og almindelige problemer i frontend-udvikling.

Ember er en godt kurateret værktøjskasse

Problemet, jeg ser, er, at frontend-samfundet som helhed har forvirret de to ganske lidt. For eksempel er Glimmer.js, Vue.js og React.js værktøjer til visning af lag - de hjælper dig med at administrere gengivelseselementer på en side. Der er dog værktøjer, der tackle andre problemer, såsom React-Router og router.js til routing support samt create-react-app og ember-cli til tooling.

Rammer omfatter disse værktøjer, så du kan komme i gang med at opbygge din app. Min første ramme var Rails, et fremragende eksempel på en ramme sammensat af nogle fremragende biblioteker. Problemet er, at en backend-ramme ikke mentalt kan oversættes til frontend, fordi frontend trods alt er bare UI - ikke?

Nej. Frontend-udvikling omfatter support af web-api, værktøj, installation, test og mere. Disse individuelle stykker er forbedret af mange biblioteker, men at have en ramme i lommen er afgørende - det giver dig mulighed for at levere software hurtigere og minimere træthed i beslutningen.

Levering af software.

Det er mit hovedansvar at sikre, at stor software bliver sendt. Som softwareingeniør bygger jeg ting. Disse ting står over for kunden, og alt, hvad der kommer i vejen for dette mål, er en distraktion.

Nogle kan sige, at det at oprette en ramme påhviler en softwareingeniør. Og det er. Vi er imidlertid også nødt til at afbalancere omkostningerne ved pligter i forhold til værdien af ​​brugeren.

De teams, jeg elsker, arbejder mest med forsendelse af software. De erkender, at der er en delikat balance og tydelig forskel mellem behovet for at løse almindelige udviklingsproblemer med kundens behov.

Ember gør dette ud af boksen. Det er oprettet et samfund, der arbejder sammen for at løse almindelige problemer, mens de leverer de funktioner, du har mest brug for i din app. Hvis det ikke har det, du har brug for, har det omfattende addon-økosystem helt sikkert en løsning til dig. Hvis det i sidste ende ikke fungerer, er jeg sikker på, at du finder andre, der er villige til at hjælpe dig.

Fordele ved at vælge Ember.

Et enklere liv.

Da jeg har valgt Ember, har jeg ikke bekymret mig for værktøj, web-api-support, sikkerhedsoverholdelse og mere. Hvorfor det? Fordi samfundet består af eksperter på disse områder, der har viet deres liv til at hjælpe dig, mig og alle andre.

Testning i Ember er et perfekt eksempel på, hvordan livet er blevet lettere. Enhed, integration og fuld ved accept af test er en del af rammen. Du skal kun vælge, hvilken testløber (f.eks. Qunit [2], mokka osv.), Du vil bruge. Alt andet kommer sammen, og du kan hurtigt begynde at skrive og udføre dine test.

At styrke ingeniører til smertefrit at skrive accepttest kan fjerne kravet om en separat QA-afdeling, især for små teams og stramme budgetter. Og du får alt dette gratis.

Et venligt samfund.

Samfundet er sandsynligvis et af de bedste aspekter ved at vælge Ember. Fordi samtaler er gennemsigtige og åbne for offentligheden, er årsagerne til, at et mønster implementeres over en anden, eller hvorfor en bestemt teknik er bedre - alt sammen dokumenteret på nettet [3]. Klar til at gennemgå, kritisere, undgå eller implementere.

Bemærk også, at Ember ikke går væk. Det fundament, som Ember-samfundet har oprettet, er bygget af en koalition af enkeltpersoner og virksomheder. Alle i samfundet kommer fra forskellige baggrunde med forskellige problemer og masser af meninger. Men det er her kernestyrken i rammen ligger - i en sund diskussion, implementering og levering af testede løsninger.

Dokumentation.

Biblioteket er ekstremt veldokumenteret [4]. Fra kildekode, guider eller slakke kanalsamtaler - du kan finde svaret på dit spørgsmål. Og endnu bedre - det er taget alvorligt. Dokumentation er versioneret, samfundsbaserede samtaler om Github er grundige, og kerneteamet har implementeret retningslinjer, der hjælper med denne standardprocedure, der implementeres i dets omfattende addon-system.

Almindelig kritik af Ember.

Det er ikke cool.

Nå, det er - der er en række funktioner inden for rammerne, som jeg ved, at du ville elske at bruge. F.eks. Fungerer kildekort ud af boksen - hvilket betyder, at du kan bruge Chromes udviklerværktøjer til at bygge din app i vid udstrækning.

At favorisere stabilitet er muligvis ikke prangende, hvis du starter, og det kan forstyrre dig, at Ember ikke lader dig ødelægge ting. Vi gjorde det, og det var ikke så sjovt.

Den gode nyhed er, at din stemme kan høres. Ember har en organiseret RFC-proces for at diskutere større ændringer i rammen. Du kan lære om ændringer, før de forekommer, give dine to cent eller oprette din egen RFC til feedback.

Læringskurven er stejl.

Ember består af forskellige vigtige stykker, der hjælper med at lette applikationsudviklingsprocessen. For eksempel bages routing, implementeringer og automatiseret test i. Hvilket betyder, at du ikke kun bliver nødt til at lære om Embers anbefalede designmønstre - men du bliver nødt til at lære om andre aspekter til levering af god fungerende software.

Dette gør læringskurven lidt stejl, fordi der er mere end bare at lære at komponere komponenter til det visuelle lag. Argumentet om Embers stejle indlæringskurve er blevet brugt imod den, men jeg vil udfordre det med det faktum, at du til sidst bliver nødt til at lære disse andre aspekter af udvikling, når dine behov vokser ud over synslaget.

Bemærk, at dette har fået kerneholdets opmærksomhed, og at der er en stor bevægelse til at forenkle tingene for at sikre, at adgangsbarrieren forenkles. For eksempel at flytte til JavaScript-klasser, fjerne behovet for this.get og this.set med mere er blevet foreslået for at fjerne de største forvirringskilder for JavaScript-udviklere.

Indfødt er ikke en primær borger.

Ember er en ramme, der er forpligtet til SPA-arkitekturen (Single Page Application). Fordelene du får fra SPA er fordelene ved Ember. Da SPA ikke er et koncept til indbyggede apps, er Ember dårligt egnet til indfødt.

Husk, at Ember går foran med progressive webapps. Så hvis det er en mulighed, du gerne vil overveje, så tjek Byg en progressiv webapp med Ember af mixonic.

Hvorfor du skal vælge Ember.

Ember bruges i opstartverdenen og på virksomhedsniveau. Der er forskellige applikationer derude, der har vist sig at være modstandsdygtige over for tid. Det bruges i mange brancher og har vist sig at skalere hurtigt og effektivt. Ember har hjulpet virksomheder med at sende værdi og stabilisere udviklingshold.

Fra et softwareteknisk perspektiv er stabilisering af et team mere værd end noget andet, jeg har arbejdet på. Når du kan arbejde på et team og dele det samme sprog med lidt eller ingen forvirring over teknikker, vokser teamet og bliver mere værdifuldt end det egentlige produkt.

Fra et produktperspektiv kan du se hurtige fremskridt. Faktisk, hvis det værktøj, du har valgt, giver dig muligheden for at iterere hurtigt på funktioner og implementere feedback på kort tid - synes det for mig at være det rigtige værktøj til jobbet.

Og i sidste ende set fra et forretningsmæssigt perspektiv, jo før jeg kan tilføje værdi til mit produkt desto bedre.

Hvis du ønsker, at dit team skal være mere produktivt og tilfreds, mens det leverer værdi, skal du overveje at vælge Ember. Hvis du stadig er tøvende, er du velkommen til at nå ud til mig på Twitter på @alvincrespo, er jeg mere end glad for at hjælpe dig med at finde ud af det bedste værktøj til jobbet.

Tak.

Tak til alle, der hjalp mig med at skrive dette indlæg. Din tid og kræfter er meget værdsat, og jeg håber, at mine ord her korrekt afspejler din anmeldelse.

Noter.

[1] create-react-app (CRA) er lidt baseret på den samme filosofi som ember-cli. CRA giver en begyndende oplevelse med at oprette en app, men når dine behov overstiger målene for det projekt - er du alene. På den anden side giver ember-cli et addon-økosystem, der giver dig muligheden for at koble dig ind i cli for at tilpasse dine builds.

[2] ember-qunit er standard testløber, der ikke kræver nogen konfiguration foran

[3] Eksempler på gennemsigtige samtaler:

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

[4] Eksempler på dokumentation:

  • 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