Reddit - javascript - Cadrul JavaScript care pune paginile web pe o dietă

+1
Sunt tentat de sinuos și solid, dar lipsa ecosistemului m-a făcut să mă aplec spre Preact.

care

FWIW, multe dintre cele din partea stângă a acelei mese sacrifică corectitudinea și chiar experiența dezvoltatorului în numele performanței. Nu sunt foarte sigur ce sens are posibilitatea de a revendica o implementare este „rapid” dacă lipsește aproape orice altă dimensiune.

Mai ales dacă „performanța” este pur și simplu un număr de referință și nu se traduce deloc în experiența utilizatorului. Care IMO este cea mai mare parte a acestora.

Care este cadrul dvs. de alegere?

pentru propriile lucruri, folosesc unul pe care l-am scris [1], dar nu l-aș recomanda pentru echipe mari, sau echipe cu diferite abilități/specializări sau pentru oricine nu este pregătit să-și lanseze propriile opinii/componente.

în general, îmi place să rămân la js pur, așa că sunt un fan mai mare al hiperscriptului peste JSX sau chiar și DSL-uri mai grele. unele dintre noile cadre observabile fără vdom bazate pe idei din S.js (excedent, solid, sinuos, vella) sunt interesante, deși majoritatea din această paradigmă luptă pentru rehidratarea unui DOM SSR, ceea ce cred că este important dacă construiți un site web care are nevoie de o bună capacitate SEO.

un lucru pe care îl văd din cadrele populare este cât de multă umflătură tind să crească. poate că acest lucru se datorează doar faptului că componentele acestui ecosistem tind să nu fie minime, dar tind să fie mari și să susțină multe cazuri, ceea ce le face pe amândouă populare, dar și încărcate de caracteristici. poate că acest lucru se datorează naturii de a avea echipe uriașe care dezvoltă aplicații sau experienței variate a vastei baze de utilizatori. este prea ușor să împărțiți 20 de componente populare aprobate de ecosistem împreună pentru a ajunge la un MVP care are 500 MB de dependențe de componente și apoi crește doar de acolo. Am cerut înainte ca cineva să mă indice către un site web public construit cu React sau Vue, care este de fapt rapid (măsurat în mod obiectiv de către devtools, nu subiectiv de oameni ca „încărcări în reflectiveSingleton · 255d

pentru lucrurile mele, folosesc una pe care am scris-o

Odată am făcut asta eu însumi. cu câțiva ani în urmă: http://footworkjs.com/

. pe baza knockout-ului din acel moment.

Vă sugerez cu tărie oricui să nu-și folosească propriul cadru. chiar și pentru proiecte personale.

Dacă doriți să scrieți unul pentru a vă extinde setul de abilități, atunci minunat, asta funcționează (și a ajuns să fie ceea ce am obținut din experiență). Dar dacă sunteți ca mine, petreceți cantități excesive de timp pe un cadru care în cele din urmă este folosit doar de dvs. sau poate unul sau doi. pur și simplu nu. există utilizări mai bune ale timpului tău.

acesta este un punct valid. dar contrapunctul este că dacă toată lumea ar folosi doar cadrele existente/populare, atunci toată lumea ar fi încă pe jQuery.

Footwork pare să extindă Knockout și se vinde ca un cadru mai complet. chiar knockout-ul în sine este la nivel mai înalt decât domvm, deoarece oferă legarea datelor și analiza șabloanelor.

domvm este mai aproape de React, în sensul că este pur și simplu un strat vdom care oferă izolarea componentelor, starea privată opțională și vdom. de asemenea, nu este o nouă lib, și a fost scris când DX-ul pe care îl căutam a fost furnizat doar de Mithril (mic, pur-js, drop-in ca jQuery fără a necesita nod, Babel și 500MB de node_modules). domvm a renunțat la rutare, a adăugat SSR cu rehidratare, starea componentelor private, a retras izolat și a fost mai mic și mai rapid decât atât Mithril, cât și React (și încă este).

dacă aș începe astăzi, ar fi destul de o prostie să îmi creez propriul strat de vdom, deoarece există acum multe opțiuni bune care îndeplinesc cerințele pe care le doream, atât atunci, cât și acum.

dar contrapunctul este că dacă toată lumea ar folosi doar cadrele existente/populare, atunci toată lumea ar fi încă pe jQuery.

Asta nu înseamnă că toată lumea ar trebui să fugă și să își scrie propriul cadru.

De asemenea, am considerat că implementarea componentelor mele care permite încărcarea automată a modulelor și soluția mea de gestionare a stării a fost nouă și „mai bună” decât ceea ce era și acolo.

Ce am ajuns să realizez mai târziu. a fost câteva lucruri:

  • Nu vă aduceți prejudecăți față de alte cadre/biblioteci înainte de a le înțelege profund. Este nevoie de investiții efective în învățarea a ceva, scrierea unui fragment bun de cod cu acesta (nu doar o lume de salut/etc), pentru a ști dacă merită sau nu.
  • Să lucrezi cu alți dezvoltatori înseamnă să nu scrii propriile tale soluții unice 99,9999% din timp. Veți fi dificil să adunați o echipă în jurul cadrului/bibliotecii dvs. preferate de preparare a casei.