DOMANDA Opinioni sul paradigma "Javascript ovunque"

Edmund Blackadder

Utente Attivo
186
98
Salve, nell'ultimo periodo sto scoprendo il mondo Node.js che, tra le tante cose, consente di usare Javascript anche lato server. Ho visto che in giro ci sono molti framework e quelli ai cui ho dato un'occhiata sono Express e Fastify.

Io per il lato server so utilizzare le servlet di Java (con un approccio REST like) quindi la domanda è: ha senso usare Javascript anche per il server? Quello che faccio con le servlet (prendere le richieste, smistarle, fare query al db e inviare JSON) posso farlo anche con questi web framework?

Ho visto qualche benchmark in giro e Javascript non si comporta male, Java vince quasi solo per i task CPU intensive e mi piace l'idea di un linguaggio che fa un po tutto, sia lato client che server.

P.S. Ho visto anche che c'è Actix, scritto in Rust ed è veramente veloce.
 
Ultima modifica:

Moffetta88

Moderatore
Staff Forum
8,165
5,512
CPU
i5-4690
Dissipatore
DEEPCOOL CAPTAIN 240EX
Scheda Madre
MSI Z97 U3 PLUS
Hard Disk
KINGSTON SSD KC400 240GB
RAM
24GB BALLISTIX SPORT @2133MHz
Scheda Video
STRIX GTX980 DC2OC
Scheda Audio
INTEGRATA
Monitor
AOC G2590VXQ
Alimentatore
BEQUIET! System Power 7 500W
Case
DEEPCOOL MATREXX 55
Periferiche
NESSUNA
Internet
FTTC FASTWEB
Sistema Operativo
UBUNTU/WINDOWS10
Node.js è ormai quasi il futuro.
dico quasi perchè io preferisco il mio bel php, visto che basta un aggiornamento di qualsiasi cosa e si rompe tutto magicamente essendo ancora molto giovane.

Per quello che fai, secondo me, non avresti alcun beneficio nel passaggio a node.js.
Anche io faccio le mie api ( prendo richiesta, controllo paramtri, query sul db e sputo fuori un json/xml ) ho preferito usare il buon vecchio e robusto php.

Unica cosa è che essendo un linguaggio in continua cresita, è cosa buona e giusta iniziare a metterci dentro il naso per qualche progetto, per non rimanere "arretrati"
 
  • Mi piace
Reactions: Edmund Blackadder

Edmund Blackadder

Utente Attivo
186
98
Node.js è ormai quasi il futuro.
dico quasi perchè io preferisco il mio bel php, visto che basta un aggiornamento di qualsiasi cosa e si rompe tutto magicamente essendo ancora molto giovane.
Si è una cosa che ho notato anche io. Non solo con Node, c'è questo trend ad usare decine di librerie per velocizzare lo sviluppo.

Per quello che fai, secondo me, non avresti alcun beneficio nel passaggio a node.js.
Il motivo iniziale per cui ho considerato il passaggio erano le prestazioni. Le servlet le ho provate sulla mia rete e nonostante fossi in "locale" (su Tomcat) non vedevo tutta questa grande velocità in caricamento e scaricamento.

Purtroppo non sono riuscito a trovare un confronto tra le classiche servlet e i moderni web framework. In compenso ho trovato questi benchmark per valutare i vari web framework. Ce ne sono veramente troppi tanti: quelli Javascript mi interessano perché conosco il linguaggio e perché mi piace programmarci (inizialmente lo odiavo), quelli in Rust sono interessanti perché sono veramente veloci.

Come dici tu il PHP è robusto, e mi piace anche perché è molto piacevole da usare (la curva di apprendimento è molto alta) ma non so come va lato prestazioni. Per esempio da quel che so le servlet di base sfruttano il multi-threading, anche il PHP lo fa?

Unica cosa è che essendo un linguaggio in continua cresita, è cosa buona e giusta iniziare a metterci dentro il naso per qualche progetto, per non rimanere "arretrati"
Esatto, anche grazie ad Electron che sta unificando sviluppo desktop e web prima o poi bisognerà metterci mano.
 

DispatchCode

Utente Attivo
793
506
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Internet
30Mbps/3Mbps con Eolo
Sistema Operativo
Windows 10 64bit
Come dici tu il PHP è robusto, e mi piace anche perché è molto piacevole da usare (la curva di apprendimento è molto alta) ma non so come va lato prestazioni. Per esempio da quel che so le servlet di base sfruttano il multi-threading, anche il PHP lo fa?
PHP ha una curva di apprendimento molto bassa, è semplice.
Il multithreading in PHP è da abilitare, e se non erro in compilazione. Di solito c'è la cache degli opcode che è forse ormai attiva di default.
Le prestazioni... meh, insomma. Non è sicuro tra i più prestanti. Con PHP 7 ci sono state migliorie.

C'è anche Go che sta prendendo piede comunque. Non so se Node diventerà davvero il più utilizzato... questa volta la concorrenza non manca, almeno lato backend.

Mi sentirei di consigliarti di rimanere con Java, visto che lo utilizzi (e nel mondo del lavoro le richieste non mancano). Io più che da Node sono attratti da Go... gli hai mai dato uno sguardo?
 
  • Mi piace
Reactions: Edmund Blackadder

Edmund Blackadder

Utente Attivo
186
98
Mi sentirei di consigliarti di rimanere con Java, visto che lo utilizzi (e nel mondo del lavoro le richieste non mancano). Io più che da Node sono attratti da Go... gli hai mai dato uno sguardo?
Di Go ne ho sentito parlare molto ma non ho mai l'ho mai serieamente preso in considerazione. Javascript, invece, lo conosco e mi piace.

A questo punto credo che rimarrò su Java e sulle servlet mentre i web framework li utilizzerò per progetti personali/hobby.
 

Moffetta88

Moderatore
Staff Forum
8,165
5,512
CPU
i5-4690
Dissipatore
DEEPCOOL CAPTAIN 240EX
Scheda Madre
MSI Z97 U3 PLUS
Hard Disk
KINGSTON SSD KC400 240GB
RAM
24GB BALLISTIX SPORT @2133MHz
Scheda Video
STRIX GTX980 DC2OC
Scheda Audio
INTEGRATA
Monitor
AOC G2590VXQ
Alimentatore
BEQUIET! System Power 7 500W
Case
DEEPCOOL MATREXX 55
Periferiche
NESSUNA
Internet
FTTC FASTWEB
Sistema Operativo
UBUNTU/WINDOWS10
Golang è l'acerrimo nemico di tutti i linguaggi lato server.
Creato dalla grande G ha molto da offrire.
Testato per giocherellare in casa, non l'ho ancora usato in produzione.

Ecco, più che altro nodejs et simila usali prima in casa per fare test, prima di cimentarti nella produzione.
Noi abbiamo persino migrato socket.io, progetto fatto per nodejs, totalmente in php perchè ci siamo stancati di aver così tante dipendenze.
 

Edmund Blackadder

Utente Attivo
186
98
Che voi sappiate Go e Rust soffrono anche loro il problema di tante dipendenze? La mia unica esperienza con Rust è su Linux quando mi capita di compilare qualche applicativo (tipo greetd), vedo che Rust le dipendenze le scarica e non mi sembrano poche. Go non saprei proprio.
 

DispatchCode

Utente Attivo
793
506
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Internet
30Mbps/3Mbps con Eolo
Sistema Operativo
Windows 10 64bit
Io con Rust non ci ho smanettato moltissimo, lo stavo studiando ma ho dovuto rallentare un po'. Una delle cose che ho scritto è questa https://forum.tomshw.it/threads/cod...ente-la-vecchia-cpu-8086.782915/#post-7668144

Con cargo scarichi le dipendenze, ma fa tutto lui. Una volta messo li il crate, ti scarica tutto ciò che ti serve (le sue dipendenze).

Una pecca secondo me è che ci si ritrova a dover utilizzare dipendenze mantenute da terzi, non c'è tantissimo di "ufficiale", diciamo così. Questo in base alla mia esperienza, poi non escludo che la mia prima impressione possa mutare :)
 
  • Mi piace
Reactions: Edmund Blackadder

pabloski

Utente Èlite
2,427
636
Che voi sappiate Go e Rust soffrono anche loro il problema di tante dipendenze? La mia unica esperienza con Rust è su Linux quando mi capita di compilare qualche applicativo (tipo greetd), vedo che Rust le dipendenze le scarica e non mi sembrano poche. Go non saprei proprio.
Beh almeno le gestiscono, a differenza di altri linguaggi. C++ è un grande linguaggio, ma soffre proprio della mancanza di una soluzione per gestire le dipendenze.

Questo per dire, che gli altri due, che invece offrono una soluzione e molto buona direi, sono una spanna sopra gli altri.

Poi è naturale, per un programma medio-grande, avere centinaia di dipendenze. Tanto per dire, che senso ha costruirsi un parser JSON se puoi usare Serde ( Rust )? E lo stesso discorso vale per Go.

I crate ( quelli più grossi e importanti almeno ) sono il naturale completamento di Rust. E il team di sviluppo mantiene volutamente alcune funzionalità fuori dalla standard library.

Ma a chi importa? Alla fine il codice o lo scrivi tu o usi quello scritto da qualcun'altro. C'è poco da fare. E se è contenuto nella standard library, t'ingrossa le dimensioni della prima installazione. Insomma, non si sfugge!

Riguardo il discorso su Javascript. Capisco che abbia preso piede e ormai ce lo dobbiamo sorbire. Ma lo stesso inventore ( Brendan Eich ) lo definì un "hack realizzato in un fine settimana". E infatti la comunità si è smazzata per migliorarlo. Esistono una dozzina di alternative ( tra cui il famoso Typescript e il neo-famoso Dart, anche se quest'ultimo è diventato famoso per lo sviluppo mobile ).

Soffre del limite di tutti i linguaggi della sua classe, ovvero l'essere single thread. In un mondo con 8-16 core su pc e workstation ( figuriamoci sui server ), mi pare un grosso limite.

E' il tipico linguaggio "fat", che arriva alla folle soluzione di wrappare pure i tipi integrali come int, bool, ecc... in oggetti ( come fa Python ). E' un miracolo che V8 performi in quel modo ( unwrappa i tipi integrali, tra le altre cose )!!

Per cui, Nodejs è una buona soluzione lato server, perchè in genere si tratta di servire file. Il grosso dell'attività è centrata sull'I/O. Ma per quei casi in cui bisogna fare tanti calcoli, non è proprio una brillante idea usarlo.

E vale, in parte, pure per Go, che pasticcia coi numeri e le prestazioni vanno giù. Però Go c'ha dalla sua un'implementazione del meccanismo CSP ( per la concorrenza ) favoloso. Realizzare in poco tempo e con pochi bug un programma che spawna migliaia di goroutine, che comunicano senza race condition grazie ai canali...non ha prezzo! E non lo paghi nemmeno in termini di consumi stellari di memoria. Cosa rara per i linguaggi basati su garbage collector.

Rust è un discorso a parte, perchè introduce parecchie innovazioni ( molte prese dal mondo della programmazione funzionale ). Aldilà della difficoltà di apprendimento, rimane il fatto che spezza le gambe ad intere classi di bug.

Possiamo far finta di niente? Se io dovessi, oggi, progettare un dispositivo edge per l'IoT, potrei scegliere tra C++ e Rust. E, a meno di una seria e mostruosa mancanza di librerie lato Rust, non ritengo saggio scegliere C++, rinunciando ai vantaggi di Rust. E l'elemento poco notato ma importantissimo, è la disciplina che la comunità di è data. Cioè, da un lato il modello di programmazione del linguaggio elimina certe classi di bug. Dall'altro, pure i crate esterni seguono le best practises del linguaggio, tra cui quella di eliminare qualsiasi tipo di comportamento non definito. Per esempio, non è una cosa che può gestire il borrow checker, ma il tipo String controlla che il suo buffer contenga solo sequenze UTF-8 valide. Perchè? Perchè altrimenti quel contenuto potrebbe produrre comportamenti non definiti ( i famigerati undefined behaviour del C e figli ).

Oppure, esite il tipo OsStr, stringa fatta per contenere i nomi dei file. Uh!?! Embè, Unix ( e non solo ) ha il brutto vizio di accettare qualsiasi sequenza Unicode come nome dei file, anche quelle che contengono simboli che riservati o che non rappresentano nessun carattere. Usare direttamente String per simili oggetti, implicherebbe avere delle stringhe contenenti caratteri non validi, violando quella best practice di sopra.

Altra cosa sono le differenze tra le piattaforme. Che fa una funzione/metodo che setta i permessi su un file, sotto Windows? Niente. Windows non supporta i permessi Unix. Go, per esempio, te la fa eseguire e, di nascosto, non fa niente. COMPORTAMENTO NON DEFINITO!!! Male!!!

A Rust non piace nascondere la polvere sotto il tappeto. E imho, è meglio, per il programmatore, se la polvere è ben visibile in fase di progettazione e compilazione. Cioè Rust è tutto questo. Mica pizza e fichi!

Ma lo stesso discorso si può fare per i web services. Non è che siano meno importanti, per cui possiamo lasciarli agli hacker.

Imho la situazione è questa: Go ( sost: Java/Kotlin e C# ), Python, Rust ( sost: C/C++ ), Javascript/Typescript, Dart.

Go lo metto sullo stesso piano di Java, Kotlin e tutta la roba che gira intorno a JVM e C#/CLR. A parte la quantità di librerie, che ovviamente pende a favore di Java e C#, ma a Go non manca niente. Anzi, sulla concorrenza se la cava molto meglio.

Python è il linguaggio della prototipazione e del deep learning. E se non si ha a che fare con machine learning, data science in generale, big data e compagnia, non è sicuramente obbligatorio conoscerlo.

Rust è imho fondamentale per la sicurezza. E sta sullo stesso piano di C e C++. Ma è agli esordi e c'è tempo per studiarlo.

Javascript e fratelli/cugini sono purtroppo lo standard de facto in certi ambiti e hanno dalla loro legioni di programmatori. Puoi ovviamente restare fuori dal giro e puntare a lavori di "più alto livello". C'è gente che stracampa realizzando software embedded in C++ ( e talvolta in C ). E non toccherebbe Javascript nemmeno con un bastone.

E c'è Dart, il linguaggio del mobile cross-platform. Visto il boom di Flutter, far finta che non esista è sciocco. Voglio dire, Flutter è quasi arrivato ai livelli di popolarità di React Native ( che spadroneggia in ambito cross-platform ) e l'ha fatto in meno di 5 anni. E poi il team ha lavorato tantissimo alle prestazioni, tant'è che Dart si comporta molto bene pure su carichi cpu-bound e, in generale, sta sempre sopra Nodejs/V8.
 
Ultima modifica:
  • Mi piace
Reactions: Edmund Blackadder

Edmund Blackadder

Utente Attivo
186
98
Una pecca secondo me è che ci si ritrova a dover utilizzare dipendenze mantenute da terzi, non c'è tantissimo di "ufficiale", diciamo così. Questo in base alla mia esperienza, poi non escludo che la mia prima impressione possa mutare :)
Potrei anche starci ad usare dipendenze di terzi, l'importate però è che non si rompano. Avevo letto da qualche parte che tempo fa moltissimi applicativi che usano Node ebbero problemi per una dipendenza fatta da una singola riga di codice (non riesco più a trovare la notizia quindi non posso confermarla).

Poi è naturale, per un programma medio-grande, avere centinaia di dipendenze. Tanto per dire, che senso ha costruirsi un parser JSON se puoi usare Serde ( Rust )? E lo stesso discorso vale per Go.

I crate ( quelli più grossi e importanti almeno ) sono il naturale completamento di Rust. E il team di sviluppo mantiene volutamente alcune funzionalità fuori dalla standard library.

Ma a chi importa? Alla fine il codice o lo scrivi tu o usi quello scritto da qualcun'altro. C'è poco da fare. E se è contenuto nella standard library, t'ingrossa le dimensioni della prima installazione. Insomma, non si sfugge!
Innanzitutto grazie per la risposta veramente esaustiva! Il problema è che queste dipendenze potrebbero rompersi, per questo prima facevo il discorso della convenienza ad avere poche dipendenze, meno ce ne sono minore è la possibilità di guasti.

Riguardo il discorso su Javascript. Capisco che abbia preso piede e ormai ce lo dobbiamo sorbire. Ma lo stesso inventore ( Brendan Eich ) lo definì un "hack realizzato in un fine settimana". E infatti la comunità si è smazzata per migliorarlo.
Non credi che con ECMA 6 sia migliorato parecchio?

Rust è un discorso a parte, perchè introduce parecchie innovazioni ( molte prese dal mondo della programmazione funzionale ). Aldilà della difficoltà di apprendimento, rimane il fatto che spezza le gambe ad intere classi di bug.
Rust mi attira tanto, ma come hai detto inizialmente è difficile da apprendere.

Tutti questi discorsi sulle dipendenze sono colpa di Arch che mi ha insegnato la religione del minimalismo. 😬
 

pabloski

Utente Èlite
2,427
636
Potrei anche starci ad usare dipendenze di terzi, l'importate però è che non si rompano. Avevo letto da qualche parte che tempo fa moltissimi applicativi che usano Node ebbero problemi per una dipendenza fatta da una singola riga di codice (non riesco più a trovare la notizia quindi non posso confermarla).
Npm ha avuto problemi con dipendenze malevole, buggate e soprattutto è un continuo dependency hell. Non è raro che un programma non giri perchè una dipendenza è stata aggiornata.

Innanzitutto grazie per la risposta veramente esaustiva! Il problema è che queste dipendenze potrebbero rompersi, per questo prima facevo il discorso della convenienza ad avere poche dipendenze, meno ce ne sono minore è la possibilità di guasti.
E questo non succede nel mondo Rust. Puoi imporre l'uso di specifiche versioni delle dipendenze. Puoi imporre l'uso di determinate major release. In generale, la comunità Rust segue regole ferree sulla retrocompatibilità e il versioning. E il file Cargo.lock sta lì proprio per lockare le dipendenze. Cioè, la prima volta decide quale versione di ogni crate usare e poi si fissa su quelle versioni. L'aggiornamento dev'essere fatto in maniera esplicita, dal programmatore.

Non credi che con ECMA 6 sia migliorato parecchio?
Così come C++ con C++11, 14, 17, 20....ma sono hack. Il modello di programmazione non è bypassabile. JS è single thread e lo sono tutte le sue implementazioni. E questo non è risolvibile con un hack.

Rust mi attira tanto, ma come hai detto inizialmente è difficile da apprendere.
E' difficile entrare nella sua logica, la prima volta. Ma poi risulta più logico degli altri. Come quando si usava Pascal. La sua ferrea logica era fastidiosa all'inizio, ma risultava piacevole nel lungo periodo.

Tutti questi discorsi sulle dipendenze sono colpa di Arch che mi ha insegnato la religione del minimalismo. 😬
Se installi il metapacchetto Gnome, vedrai che il minimalismo va a farsi friggere.

E vale lo stesso per la programmazione. Non è che non puoi creare programmi Rust senza dipendenze. Tanto c'è già la standard library, che contiene parecchie cose. Ma perchè reinventare la ruota?
 

Edmund Blackadder

Utente Attivo
186
98
Se installi il metapacchetto Gnome, vedrai che il minimalismo va a farsi friggere.
Infatti non installo più nulla di Gnome. Ora Arch sembra una Ubuntu, due o tre pacchetti che si aggiornano ogni paio di giorni. Nulla di più.

Tanto c'è già la standard library, che contiene parecchie cose. Ma perchè reinventare la ruota?
In fondo hai ragione.

Ringrazio tutti quelli che hanno risposto, mi avete fornito molti spunti su cui riflettere. 😁
 

icox

Utente Attivo
384
168
Io spezzo una lancia a favore di Node/Javascript o meglio ancora Typescript.
Concordo in parte sulla questione che qualcuno ha sollevato sull'essere single thread ma imho non e' una limitazione cosi importante, ti solleva dal dover gestire/sincronizzare i processi e per quelle operazioni molto cpu-bound esistono i worker che sono stabili gia' da qualche versione di node. Chiaro che si tratta poi sempre di scegliere lo strumento giusto in base al lavoro da svolgere...

IMHO due valori aggiunti importanti sono l'enorme mole di librerie disponibili, molte delle quali scritte veramente bene, e la possibilita' di utilizzare lo stesso linguaggio sia sul frontend che sul backend (il che non e' da sottovalutare sopratutto per i team piu' piccoli). Tra l'altro a proposito di librerie non so quali abbiate usato per avere problemi di stabilita', una volta scritti i test e freezate le versioni delle lib in produzione non abbiamo mai avuto problemi... Anche adottando ci/cd si va sempre ad usare la stessa versione anche se un update viene rilasciato.

Se vuoi continuare su node/javascript io ti consiglio caldamente di dare un occhiata a Typescript, se usato bene e con un linter bello "strict" da belle soddisfazioni.
Un altro progetto interessante che sembra stia crescendo bene e' Deno, dagli uno sguardo se ti capita.
 

Entra

oppure Accedi utilizzando

Discussioni Simili

Hot del momento