- Home
- Categorie
- Coding e Sistemistica
- Javascript & Framework
- Deno vs Node.js: riuscirà a decollare il nuovo arrivato?
-
Deno vs Node.js: riuscirà a decollare il nuovo arrivato?
Progetto ambizioso quello del creatore di Node.js, che sulla base degli errori e punti deboli della sua precedente creazione ha pensato un a #Deno per superarli.
Un articolo interessante dal punto di vista del primo utilizzo
https://blog.bitsrc.io/node-to-deno-first-impression-d2b41b920c1f
Voi lo avete provato?
A 1 Risposta -
Ciao Andrea, non ancora provato, per ora ho solo guardato un video per capire di cosa si tratta, al max visto che ora mi funziona docker potrei sperimentare un po'.
-
Ancora non l'ho provato neanche io, avevo visto un paio di articoli un paio di settimane fa ma non ho ancora approfondito.
Appena riesco faccio qualche test!
-
@juanin a distanza di poco meno di un anno dalla sua disponibilità, sì lo uso, non seriamente perché la quantità di progetti e soluzioni disponibili su node è molto elevata, poi perché senza npm o yarn (far partire un progetto react per esempio) non si fa molto
per me i punti di forza sono:
- unico eseguibile
- compila i moduli al primo avvio
- usa typescript senza dover preparare degli script d'avvio progetto
diventa comodo anche come linguaggio di scripting non necessariamente legato alle applicazioni WEB (se uno desidera un unico linguaggio anche per quel scopo)
Penso decollerà, ma ci vorrà tempo prima che possa attrarre seriamente sviluppatori che hanno una grossa codebase in PHP o node (già nel rapporto tra PHP-node-Java-Python fa capire la fatica che un nuovo strumento possa avere quando si presenta alla comunità)
-
@juanin non l'ho provato ma non ho ancora capito come fanno a gestire le dipendenze.
- Se non usi un sistema di "packaging" alla npm come fai a gestire le versioni sull'intero progetto?
- Altra cosa, se l'import del package non è pubblico come gestisci la sicurezza? Con un basic auth?
Questa cosa qua sotto per progetti medio-grandi secondo me va gestita in modo diversa:
Qualcuno ne sa di più?
Lato backend ho visto che tranne per il fatto del discorso "sistema asincrono" non sto notando tutti questi vantaggi del Javascript rispetto a Go, Python o PHP
-
Per il versionamento dei moduli impiegati, c'è la sfumatura impiegata nello statement d'import
import { serve } from 'https://deno.land/[email protected]/http/server.ts' @v0.42.0
Questo permette di fissare la versione da impiegare nel proprio progetto, anche se a volte durante gli aggiornamenti di deno, è necessario rivedere queste (come si fa con node d'altronde).
I moduli pubblici, a differenza di node, anziché essere salvati nella cartella locale al progetto './node_modules', vanno direttamente nella cache dell'installazione locale di deno. Si tratta solo di una diversa collocazione che ha comunque dei vantaggi.
Per i moduli (package) privati, si usa il file locale
import { serve } from './privatelibrary/http/server.ts'
Questa pratica ovviamente è necessaria anche per organizzare un progetto
import { user } from './model/user.ts' import { getUser, updateUser, newUser, deleteUser } from './controller/user.ts' ...
Per i vantaggi rispetto ad altri linguaggi, difficile rispondere perché è anche un fatto di abitudini e preferenze e la comprensione delle logiche dell'architettura offerta che fa sempre da ostacolo perché è necessario studiarla e dedicare diverso tempo.
Ancora oggi mi trovo meglio col PHP perché sequenziale, fa uso di paradigmi tradizionali ben assimilati e non ho abbastanza allenamento nell'uso delle logiche async del JS.
E' anche per quello che guardo con attenzione 'deno', più per l'uso del TypeScript che non del JavaScript che mi sembra più affine ad i linguaggi tradizionali a classi dove invece riscontro difficoltà con 'node', o volendo usare TypeScript, nella configurazione di un progetto 'node'.
Decollerà nel momento che viene usato per progetti importanti, le premesse ci sono, per l'adozione solo il tempo potrà dare una risposta.
1 Risposta -
@andyj115 grazie della risposta
Il problema non è tanto di scegliere la versione in un singolo modulo, ma è se questo viene usato in più punti.
Quando vuoi fare un upgrade, sarà necessario cambiare la versione in tutti i punti (si va bene che puoi fare un cerca/sostituisci ma rimane una operazione "a mano")Stessa storia con la libreria privata: in ogni caso "qualcuno" dovrà pur piazzare i file nella
./privatelibrary
e non capisco questa ostilità nei package managerDiscorso Typescript sono d'accordo anche io che è un miglioramento non indifferente ma non mi sembra così impossibile al configrazione nei progetti node, quindi Deno al momento (mia opinione personale) non sta dando questi vantaggi.
A 1 Risposta -
@giuseppemorelli in effetti è una giusta osservazione... mi sembra d'aver visto un video su YT si possa fare includendo tutti i moduli in un unico file per poi esportare quanto serve ed usando questo come riferimento in tutti i file di progetto
al momento i miei 1000+1 "hello word" in tutte le salse sparsi nel computer non avevano ancora messo in evidenza questa necessità...