Termenul limită pentru postările de blog # EmberJS2019 se apropie foarte repede, dar ca întotdeauna am nevoie de termene pentru a-mi termina lucrurile.

trimite-i

La început, vreau să ofer câteva informații despre mine și compania pentru care lucrez. La Roomle folosim Ember, deoarece este foarte devreme. Primul nostru angajament în proiectul Ember datează de la începutul anului 2013. De-a lungul acestui timp am acumulat multă experiență și am cunoscut părțile bune și rele ale Ember. De asemenea, am lansat aplicații web de producție care utilizează Glimmer.js ca cadru de interfață UI. Chiar acum rescriem părți ale aplicației noastre principale în Ember Octane cu TypeScript, astfel încât să știm și cum este să fii un adoptator timpuriu.

Deoarece suntem un startup mic și ne-am concentrat pe construirea propriului nostru produs, nu am contribuit cu suplimente sau cu o cantitate mare de cod, dar am ajutat la rezolvarea unor probleme și am creat, de asemenea, PR-uri mici pentru mai multe proiecte ale ecosistemului Ember.

Înainte de a începe, vreau să adaug un disclaimer: ne place foarte mult Ember și nu vreau să creez impresia că nu ne place. Această postare de blog este despre domenii de îmbunătățit și nu despre lucrurile frumoase 😉

🤔 Recapitularea Roadmap 2018

Înainte să mă scufund în viitor, vreau să fac o recapitulare rapidă pe Foaia de parcurs din 2018. Vreau să menționez că fac recapitularea ca un outsider care nu face parte din nicio echipă de bază. Deci, rețineți că este foarte probabil să îmi fie dor de unele lucruri importante. Cu toate acestea, cred că pot oferi feedback bun, deoarece acesta este și modul în care alți contribuabili nu pot vedea progresul cadrului. Să vedem subiectele pe care noi, ca comunitate, am vrut să le îmbunătățim anul trecut:

🗣 Îmbunătățirea comunicării și eficientizarea procesului decizional

S-au înregistrat multe îmbunătățiri cu privire la acest subiect. De asemenea, trecerea la Discord a fost bună și a decurs fără probleme. Dar cred că comunicarea în jurul lui Ember Octane nu a fost super ideală. Oamenii rețineau proiectul pentru că nu doreau să înceapă cu Ember „moștenit”. Deoarece Ember Octane încă nu este livrat (doar previzualizare) unii dintre colegii mei s-au uitat în jur la alte cadre și unii dintre ei au părăsit Ember în favoarea Vue și Vue-CLI (mai ales din cauza instrumentelor de construcție superioare).

Din punctul meu de vedere, comunicarea în jurul lui Octane a avut două mari probleme

Peste comunicare: a fost greu să ții cont de ceea ce se întâmplă și de ceea ce are sens să adopți. Desigur, toată lumea ar fi putut rămâne pe „calea fericită”, dar când începeți un proiect nou nu doriți să utilizați vechiul mod de a face lucrurile. De asemenea, am început un nou proiect Ember cu puțin timp înainte de Ember Conf 2019 și ne-am temut, de asemenea, că vom lansa o aplicație complet nouă într-un mod moștenit de a face lucrurile. Sentimentul meu a fost că comunicarea în jurul lui Octane a creat o oarecare incertitudine.

Peste promițătoare și sub realizare: când ne uităm la obiectivele stabilite pentru Octane, multe dintre ele au fost amânate (în special îmbunătățirile mult așteptate pentru construcție, voi intra în detalii despre construcție în secțiunea următoare). Nu mă înțelege greșit. Îmi place foarte mult Ember Octane, dar cea mai mare parte a muncii depuse este pentru experiența dezvoltatorului. Știu că lucruri precum clasele native pregătesc terenul pentru îmbunătățiri suplimentare, dar chiar acum aceste lucruri nu sunt cu adevărat pârghiate. Ember are o istorie de lucruri promițătoare, de exemplu: componente rutabile, unificare de module etc. care nu aterizează niciodată, prin urmare, cred că trebuie să fim foarte atenți la ceea ce promitem și la modul în care comunicăm aceste promisiuni publicului.

Tldr; comunicarea s-a îmbunătățit masiv, dar, în unele cazuri, ar trebui să fim mai sensibili la ce și cum comunicăm

🏋‍♂ Termină ce am început și Ship Ember Octane

Ambele obiective ale foii de parcurs s-au suprapus mult. Cred că comunitatea Ember a reușit să termine o mulțime de lucruri care au fost începute. În ceea ce privește Ember Octane, nu am reușit să-l livrăm în timpul foii de parcurs 2018 (cred că este încă o versiune de previzualizare). De asemenea, vreau să subliniez câteva dintre obiectivele Ember Octane care nu au fost livrate și cred că ar trebui să facă parte din foaia de parcurs din 2019, prin urmare încep cu câteva citate ale foii de parcurs din 2018:

Aplicații de conținut, în care paginile sunt foarte grele în text și unde prima încărcare este critică. În mediile cu performanță limitată, convențiile puternice ale Ember pot ajuta dezvoltatorii să construiască în mod implicit aplicații mai rapide.

Expresia cheie aici este prima încărcare. Dacă faceți inițierea și creați o aplicație simplă „Hello World”, pachetele JS însumează aproximativ 700KB. Primele mele experimente cu Brodare au fost mai bune, dar totuși nu au dat rezultate satisfăcătoare. Pachetul avea încă aproximativ 400 KB de JavaScript. Este prea mult. Deși îmi place foarte mult Ember, a trebuit să îl părăsim pe Ember pentru anumite proiecte din cauza dimensiunii pachetului JS. Nu fiecare proiect este o interfață de administrare pentru introducerea datelor pentru un backend. În special pentru proiectele noastre de comerț electronic, Ember nu a fost o opțiune viabilă doar din cauza dimensiunii pachetului. Mi-ar plăcea să văd îmbunătățiri masive în acest domeniu 💖

Treeshaking pentru a elimina automat codul neutilizat de aplicație

Acest lucru este foarte legat de punctul de sus. Ember trebuie să devină de primă clasă și lider în industrie în ceea ce privește scuturarea copacilor. Întrucât Ember este un cadru „cu baterii incluse”, pachetele noastre vor fi întotdeauna uriașe dacă nu avem o agitare excelentă a copacilor.

Construcții Svelte, unde caracteristicile depreciate sunt eliminate din codul cadru. Vom deveni mai agresivi în ceea ce privește deprecierea codului care nu este utilizat pe scară largă.

Cred că un instrument modern de construcție, cum ar fi Embroider, ar trebui să elimine tot ceea ce nu este necesar. Indiferent dacă o caracteristică este depreciată sau nu.

DIN NICI OBIECTIVE: Alte optimizări Glimmer VM. Performanța Glimmer este lider în industrie și nu este un obstacol în majoritatea aplicațiilor Ember.js. În acest moment, sarcina utilă Ember.js este principalul blocaj de performanță și ar trebui să ne îndreptăm atenția spre a permite performanțe mai bune acolo.

Pentru a rezuma, echipa de bază este conștientă că dimensiunea sarcinii utile este un subiect important și a fost abordată în consecință în foaia de parcurs din 2018, dar nu am atins acest obiectiv.

Trebuie cu adevărat să reducem dimensiunile încărcăturii utile și să livrăm doar ceea ce este necesar pentru randarea inițială!

Orice altceva trebuie încărcat la cerere și leneș. Deoarece Ember are convenții puternice, am putea face aceste lucruri complexe destul de plăcute pentru dezvoltatori.

Tldr; recapitularea mea din 2018 este: te rog te rog te rog remediați dimensiunea sarcinii utile a Ember pentru a o face o opțiune pentru mai multe tipuri de proiecte 🚀

🎁 Urări pentru 2019

Cred că ar trebui să ne concentrăm asupra pierderilor din 2018, dar am și dorințe pentru 2019

Lansați din nou inovația

Cu ani în urmă, Ember era lider în industrie în multe aspecte. Să ne gândim la marele router, adoptarea ES6 și ES-Module, utilizarea Promisiunilor, CLI etc. În ultimii ani, se pare că Ember se află în spatele marilor cadre și are probleme să țină pasul.

Nu cred că ar trebui să încercăm să inovăm mai repede decât ceilalți, dar ar trebui să începem din nou să dezvoltăm inovația în spațiul Ember. Poate că ar fi o idee bună să creăm o echipă de „inovație”, ca și cum am avea o echipă de bază, o echipă de învățare etc. Echipa de inovare s-ar putea concentra pe lucruri care sunt unice pentru Ember. Unele lucruri pe care nu le-am văzut în niciun alt cadru:

  • Șabloane binare
  • Redați motorul ca modul WebAssembly
  • nu este legat direct de Ember, dar ceva de genul css-block ar fi minunat

Primele două caracteristici au fost deja prezentate la Ember Conf 2018, dar încă nu sunt livrate. Ember ar trebui să aibă din nou câteva caracteristici care să o deosebească de toate celelalte. Numai „Convenția asupra configurării” va fi prea puțin pentru a rămâne relevantă.

👷 Construirea și brodarea

Mulți alții au subliniat deja că Embroider este cel mai important proiect din 2019. Sunt de acord în totalitate, deoarece va permite Ember să utilizeze instrumente standard pentru industrie pentru ambalare. Câteva dorințe de Brodat și sistemul de construcție îmbunătățit:

  • creați diferite versiuni din pachetele JavaScript, astfel încât să putem livra coduri mici și moderne browserelor moderne și pachetelor vechi pentru browserul vechi
  • includeți doar ceea ce este necesar aka scuturarea copacilor
  • ușurează încărcarea leneșă. În vremuri de HTTP2, server push, preîncărcare etc și primitive JavaScript cum ar fi async/await ar trebui să începem să folosim încărcarea leneșă pe scară largă

Dacă avem un instrument extraordinar de construcție și pachet, am putea îndeplini, de asemenea, promisiunea că npm vă va instala drumul către Ember. Cred că ar trebui să redenumim această expresie, deoarece un init ember ar putea instala toate pachetele în folderul node_modules, dar dezvoltatorul adaugă ceva la sarcina utilă doar dacă o importă la un moment dat al aplicației. Îmi place această idee pentru că am putea livra totuși un set de instrumente organizate și nu vom pedepsi utilizatorii care au nevoie doar de părți mici ale cadrului.

Dacă continuăm să folosim Broccoli, trebuie să documentăm mai bine cum să scriem pluginuri. Dacă într-adevăr trebuie să scriu un plugin de compilare, ajung întotdeauna să copiez pluginuri similare pentru Broccoli și să elimin lucruri de care nu am nevoie. Adesea trebuie să depan cu nodul --inspect-brk. Dezvoltarea pluginurilor de compilare nu este deloc distractivă

👵 Regândiți „stabilitatea fără stagnare”

Îmi place foarte mult Ember pentru că face upgrade-uri ușoare și nu rupe compatibilitatea înapoi. Dar întotdeauna când încep un nou proiect Ember cred:

„De ce trebuie să port tot acest bagaj de acum ani”

De asemenea, simțim că concentrarea pe compatibilitatea inversă ne încetinește foarte mult. Nu știu cum să rezolv această problemă și cred că este foarte greu să atingi locul dulce între „spargerea” lucrurilor și lăsarea totul așa cum este. Poate că am putea oferi polifenituri pentru aplicații vechi și putem elimina codul vechi din baza de cod Ember. Uneori am senzația că suntem mai mult pe partea de stagnare, în special pe subiecte mari, cum ar fi construirea, controlerele, aspectul nou al sistemului de fișiere etc.

YpeTypeScript

Lucrăm cu ember-cli-typescript din februarie 2019 și funcționează ca un farmec. Ne place impulsul de productivitate pe care ni-l oferă TypeScript. De asemenea, facilitează descoperirea codului pentru toți dezvoltatorii din proiect. Cu TypeScript este mult mai puțin probabil ca cineva să implementeze ceva care există deja. În special pentru biblioteci și programe de completare, este minunat să ai lucruri precum completarea codului și IntelliSense.

În ciuda faptului că TypeScript și Ember joacă frumos împreună, cred că ar trebui să îmbunătățim în continuare suportul TypeScript în ecosistemul Ember. Ar fi minunat dacă primii 100 de addon-uri ar avea definiții TypeScript și ar fi codate pentru a funcționa cu TypeScript.

Recent am avut câteva probleme cu decoratorii TypeScript și cu noua specificație pentru decoratorul TC39. Nu sunt sigur care este problema, dar ar trebui să luăm întotdeauna în considerare și utilizatorii TypeScript.

În afară de asta, ar fi minunat să vezi lucruri precum șabloane tastate etc.

✨ Glimmer.js

Folosim Glimmer.js într-unul dintre proiectele noastre și funcționează excelent, dar se simte cumva ca pe un teren mort. La început s-au întâmplat atât de multe dezvoltări, dar în acest moment se pare că toate forțele sunt puse la pachet pentru ca Ember Octane să fie expediat. Avem nevoie de o modalitate de a readuce utilizatorii Glimmer.js în „calea fericită” a Ember. Poate că noul sistem de construcție și Embroider ar putea ajuta aici, dar acum ne simțim pierduți cu Glimmer.js ☠

🚚 Ember-Data

Când am început ultimul nostru proiect Ember, a trebuit să încorporăm noi dezvoltatori. Iar principalele concepte Ember au fost ușor de înțeles pentru ei. Dar adesea a apărut confuzie atunci când au avut vreo întrebare în combinație cu Ember-Data. Din perspectiva învățării, cred că există trei provocări principale

  • Ce este Ember-Data și ce este Ember? Liniile sunt foarte neclare.
  • De ce avem nevoie de metode speciale precum objectAt uneori și alteori nu? De ce trebuie să aranjăm înainte de a aplica metode native array etc.
  • Îmbunătățiți documentele și explicați ce este Ember-Data, furnizați cele mai bune practici și rețete și comparați-le cu instrumentele din alte cadre. Unii dintre dezvoltatorii noștri care au trecut de la React au crezut întotdeauna că Ember-Data este Redux în Ember

Mai mult, trebuie să luăm în considerare și modul de a reduce dimensiunea sarcinii utile a Ember-Data

🌃 Mono-Repo

Avem câteva mono-repos și nu este întotdeauna banal să includem proiecte Ember în aceste mono-repos. Ar fi frumos să aveți câteva documente sau cele mai bune practici despre cum să configurați un mono-repo cu mai multe proiecte Ember. De asemenea, ar fi minunat să faceți mai ușor să partajați codul din mono-repo. Poate că este deja posibil, dar nu am găsit un tutorial bun pentru asta. Deci, cred că ar fi benefic dacă un cadru pentru aplicații web ambițioase ar acoperi acest subiect undeva în ghidurile avansate. De exemplu, avem următoarea configurare:

Nu am găsit o modalitate ușoară de a importa dintr-un dosar obișnuit. Ar fi grozav dacă aș putea face un import .