[Linuxtrent] Re: Node.js ecosystem
- From: Mario Alexandro Santini <alexmario74@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Fri, 10 Feb 2017 10:41:13 +0100
2017-02-09 21:59 GMT+01:00 Daniele Nicolodi <daniele@xxxxxxxxxx>:
Ciao,
Ciao Daniele,
Non sono uno sviluppatore Javascript (e se queste sono le premesse
continuerò a starne il più possibile alla larga), ma questo sembra il
modello di sviluppo incoraggiato all'interno della comunità Node.je e
compagnia. Che cosa ne pensa chi sviluppa in Javascript del proliferare
di queste librerie banali e per la maggior parte inutili che richiedono
più righe di codice per dichiarare la dipendenza che per
re-implementarle? È questo un modello di sviluppo accettabile?
Ciao,
Daniele, perplesso.
--
Ti confermo che si tratta di uno dei temi aperti su Javascript.
Il grosso problema e limite del linguaggio fino alle specifiche ES6 era
quello di non avere un sistema per definire moduli/package separati dal
namespace globale.
Lato client questo lo si e' risolto con il workaround di inglobare
all'interno di una funzione il codice del "modulo" e poi dato che era
conveniente mettere tutto in un unico file si e' puntato su sistemi di
build che hanno permesso di sviluppare separando i moduli in diversi file
organizzati, per poi riportarli in ordine all'interno di un unico file
"minificato" e compresso.
Oggi con HTTP2 questo modello non e' piu' cosi' vantaggioso.
Lato serve, Node.js ha avuto il pregio di introdurre un sistema di moduli e
di incoraggiare gli sviluppatori a modularizzare il proprio codice.
E questo e' un bene, perche' puoi organizzare i sorgenti in diversi file.
Tuttavia, il sistema di moduli di Node.js e' tutt'altro che comparabile a
quello di altri linguaggi....
Quelle che chiami librerie, in realta' sono poco piu' che l'equivalente
delle "classi" in Java. O meglio sono l'insieme di classi e package,
facendo il paragone con Java.
Uno dei grossi problemi oggi in Node.js e nelle librerie/framework e' il
controllo delle dipendenze.
Il package manager npm, disponibile di default con Node.js e' molto
limitato, anche se si sta evolvendo sempre piu' rapidamente.
Ci sono molti problemi, sia nelle performance (tempi per installare le
dipendenze) sia nelle dipendenze di dipendenze.
In progetti che non sono proprio banali si ha la quasi perdita del
controllo delle librerie fra duplicazioni e versioni differenti....
Una soluzione sembra essere YARN che va a sostituire proprio npm.
E' piu' veloce e rende tutte le dipendenze piatte in modo da averne maggior
controllo.
Il problema e' che ora Node.js deve decidere come implementare le
specifiche ES6 e poi le ES7 e queste specifiche hanno introdotto per la
prima volta il concetto di moduli.
Cio implica che la situazione potrebbe cambiare nei prossimi mesi con un
interregno caotico di moduli pre ES6 e post ES6.
Concordo sui problemi legati a Node.js, ma avendo lavorato anche su web
application in Java, posso dire che e' un problema delle web application
piu' che dei linguaggi.
Anche con Java c'e' proliferazione di librerie e dipendenze incrociate.
Recentemente mi sono imbattuto in un problema proprio con Spring -
Hibernate - Jetty e Tomcat.
Dove Spring, inspiegabilmente caricava una libreria di Tomcat per la JPA,
nonostante io usassi Jetty.
Il problema e' che Jetty e Tomcat utilizzano una libreria di logging
comune, dove hanno customizzato una classe... la stessa... diventando cosi'
incompatibili.
--
Mario
Other related posts: