Chi usa ancora jQuery?

[andreacanton]

Ciao a tutti,

Sono un utente relativamente nuovo in questo forum e questo è il mio primo thread!
Dal sondaggio fatto da State Of Javascript sembra che jQuery sia completamente sparito, mentre da quello di StackOverflow sembra che jQuery sia ancora il più usato. Personalmente credo sia più valido il secondo sondaggio.

Volevo capire tra voi chi usa ancora jQuery e chi no.
Inoltre mi piacerebbe sapere cosa ne pensate di questa storica libreria js e a quale futuro possa avere.

La mia opinione:
Penso che jQuery sia stato un ottimo alleato per avere una libreria che ti facesse da polifiller quando ancora veniva richiesto il supporto a IE6. Ormai per questioni soprattutto di sicurezza le aziende cominciano a supportare solo browser "evergreen" che si auto-aggiornano e supportano la maggior parte delle feature di javascript (ovviamente ci sono ancora delle eccezioni), quindi jQuery secondo me non è più così indispensabile. Più che altro credo ci siano modi migliori di strutturare il proprio frontend al giorno d'oggi.

L'ultima volta che ho toccato jQuery è stato più di tre anni fa e penso non tornerò più indietro. Credo però che c'è ancora un sacco di codice legacy o comunque ci sono "programmatori legacy" che fanno fatica ad abbandonare la tecnologia. Non troppo tempo fa ho letto su un gruppo facebook di sviluppatori web che uno facesse formazione aziendale interna su jQuery, quindi direi che per qualcuno jQuery è vivo più che mai.

[alka]

Volevo capire tra voi chi usa ancora jQuery e chi no.
Inoltre mi piacerebbe sapere cosa ne pensate di questa storica libreria js e a quale futuro possa avere.

Io lo uso ancora, soprattutto per quelle implementazioni "spicciole" che richiedono una modifica molto semplice e immediata del DOM (es. visualizzare un HTML generato lato server in un DIV, oppure fare una chiamata AJAX, ecc.), essendo più abituato alle funzioni di questa libreria piuttosto che a quelle "native" del DOM stesso.

Come futuro, credo sarà difficile vederla sparire completamente in breve tempo, anche se le feature del DOM moderne sopperiscono abbastanza alle sue funzioni, sempre parlando di applicazioni Web tendenzialmente semplici o con generazione principalmente lato server delle viste che le costituiscono, mentre per SPA e altre app più complesse, fanno da padrone Angular, React e altre librerie affini.

Ciao!

[ciro78]

Francamente ho visto la "spazzatura" che produce Angular rispetto al classico jQuery.

Finchè sarò io a scegliere jquery tutta la vita.

[alka]

Francamente ho visto la "spazzatura" che produce Angular rispetto al classico jQuery.

Parliamo di "ranghi" di applicazioni completamente differenti: al netto che non so bene a cosa ci si riferisca con il termine "spazzatura", se l'obiettivo è realizzare una SPA di dimensione medio/grande o un'applicazione Web lato client di una certa complessità, che includa autenticazione, colloqui con protocolli aggiornati e lo sfruttamento delle potenzialità concrete della piattaforma, protocolli di sicurezza, una estrema modularità, ecc. JQuery non offre alcun tipo di supporto in questo senso o, quantomeno, per ottenere lo stesso risultato richiede un quantitativo di tempo esageratamente superiore rispetto a quello che si ottiene con framework progettati appositamente allo scopo e che lavorano con versioni più recenti, se non le più recenti, del linguaggio JavaScript e/o di suoi derivati (es. TypeScript), assieme al loro ecosistema di package e di tool.

Si tratta di scenari completamente diversi e come tali non comparabili.

[SoloWiFi]

Mai usato. Lo conosco solo a titolo informativo e di studio
Uso solo js ed Ajax.
Quello che puoi fare con jQuery lo fai, ovviamente, in puro js ... sempre se vuoi scrivere codice e se sei un programmatore vero e non un assemblatore di script.

[alka]

Quello che puoi fare con jQuery lo fai, ovviamente, in puro js ... sempre se vuoi scrivere codice e se sei un programmatore vero e non un assemblatore di script.

Quella del "programmatore vero" è una vecchia storia che si trascina ormai da 30 anni, un po' come dire che scrive software realmente solo chi usa assembly al posto di qualsiasi altro linguaggio di livello più alto.

La libreria JQuery è un tool come un altro: anche se di terze parti, lo si usa così come si riutilizzerebbe qualsiasi altra libreria (o script) scritta di proprio pugno.

Un "assemblatore di script" può essere qualcuno che importa codice senza sapere realmente cosa sta facendo, ma se lo fa con cognizione di causa e conosce lo strumento che sta utilizzando, questa definizione è quantomeno riduttiva e inopportuna, frutto di una percezione altamente errata o comunque settoriale, che valuta le capacità della persona dal fatto che non riscriva codice inutilmente confondendola con qualcuno che di buon grado accetta passivamente tutto ciò che può raccattare, e pur esistendo ambo le figure al mondo, la prima condizione non implica assolutamente e necessariamente la seconda (e mi ci metto "in primis" nella categoria, per esperienza pluriennale).

Un'altra percezione errata è quella di ritenersi "real programmers" solo perché ci si scrive da soli tutto il codice, quando vi sono ambiti - uno fra tutti la sicurezza, ad esempio - dove librerie prese da terze parti sono ben più sicure, funzionali, collaudate e protette rispetto al miglior codice che uno sviluppatore possa scrivere in autonomia, poiché spesso dietro vi sono più persone, intere community, curate da esperti, orde di tester, fondazioni, finanziatori privati e tutta una serie di risorse a supporto dei progetti che rifiutarli a prescindere, solo per sentirsi più ganzi o per essere "programmatori veri", oltreché poco professionale mi pare un approccio estremamente infantile.

Se si deve sviluppare un'applicazione, si conosce JQuery bene e si ritiene di essere più produttivi rispetto all'uso del DOM tradizionale, tanto vale usare JQuery e concentrarsi sulle esigenze di business che si devono implementare per il cliente di turno affinché il prodotto sia di qualità e manutenibile, lasciando le fisime sui "programmatori veri" a chi piace divertirsi con queste etichette.

[ciro78]

Parliamo di "ranghi" di applicazioni completamente differenti: al netto che non so bene a cosa ci si riferisca con il termine "spazzatura", se l'obiettivo è realizzare una SPA di dimensione medio/grande o un'applicazione Web lato client di una certa complessità, che includa autenticazione, colloqui con protocolli aggiornati e lo sfruttamento delle potenzialità concrete della piattaforma, protocolli di sicurezza, una estrema modularità, ecc. JQuery non offre alcun tipo di supporto in questo senso o, quantomeno, per ottenere lo stesso risultato richiede un quantitativo di tempo esageratamente superiore rispetto a quello che si ottiene con framework progettati appositamente allo scopo e che lavorano con versioni più recenti, se non le più recenti, del linguaggio JavaScript e/o di suoi derivati (es. TypeScript), assieme al loro ecosistema di package e di tool.

Si tratta di scenari completamente diversi e come tali non comparabili.

ma il concetto di SPA è anche esso, a mio avviso, sopravvalutato. non credo che esista una reale necessità di fare una singola pagina piuttosto che n pagine.

per la modularità e la sicurezza sarebbe da ampliare il discorso. cosa vieta in jQuery aggiungere un blocco? in merito alla sicurezza confesso che ne so poco ma, ho letto, che jQuery consente di interagire con WSO2..

[ciro78]

Quella del "programmatore vero" è una vecchia storia che si trascina ormai da 30 anni, un po' come dire che scrive software realmente solo chi usa assembly al posto di qualsiasi altro linguaggio di livello più alto.

La libreria JQuery è un tool come un altro: anche se di terze parti, lo si usa così come si riutilizzerebbe qualsiasi altra libreria (o script) scritta di proprio pugno.

Un "assemblatore di script" può essere qualcuno che importa codice senza sapere realmente cosa sta facendo, ma se lo fa con cognizione di causa e conosce lo strumento che sta utilizzando, questa definizione è quantomeno riduttiva e inopportuna, frutto di una percezione altamente errata o comunque settoriale, che valuta le capacità della persona dal fatto che non riscriva codice inutilmente confondendola con qualcuno che di buon grado accetta passivamente tutto ciò che può raccattare, e pur esistendo ambo le figure al mondo, la prima condizione non implica assolutamente e necessariamente la seconda (e mi ci metto "in primis" nella categoria, per esperienza pluriennale).

Un'altra percezione errata è quella di ritenersi "real programmers" solo perché ci si scrive da soli tutto il codice, quando vi sono ambiti - uno fra tutti la sicurezza, ad esempio - dove librerie prese da terze parti sono ben più sicure, funzionali, collaudate e protette rispetto al miglior codice che uno sviluppatore possa scrivere in autonomia, poiché spesso dietro vi sono più persone, intere community, curate da esperti, orde di tester, fondazioni, finanziatori privati e tutta una serie di risorse a supporto dei progetti che rifiutarli a prescindere, solo per sentirsi più ganzi o per essere "programmatori veri", oltreché poco professionale mi pare un approccio estremamente infantile.

Se si deve sviluppare un'applicazione, si conosce JQuery bene e si ritiene di essere più produttivi rispetto all'uso del DOM tradizionale, tanto vale usare JQuery e concentrarsi sulle esigenze di business che si devono implementare per il cliente di turno affinché il prodotto sia di qualità e manutenibile, lasciando le fisime sui "programmatori veri" a chi piace divertirsi con queste etichette.

ho modificato un verbo.... un po' troppo hot

[U235]

Quella del...

Mi hai tolto le parole dalla tastiera.

@ciro78
L'utilita piu grossa nel fare SPA la trovo piu che altro nel modo di programmare codice e template, dividendo la logica dall'interfaccia usando MVVM, per cui non serve avere piu pagine se tanto la dinamicita sta nello stato stesso del programma, anzi dovrei riprenderlo ad ogni caricamento. A riprova infatti penso che un "sito vetrina" inteso come tale non abbia senso farlo come SPA, mentre un sistema di gestione si, perche ci lavori un po come fai con un "gestionale" installato, non lo devi sfogliare ma usare e quindi deve avere uno stato e non ha molto senso spostarlo da una pagina all'altra.
Oltre tutto passare per una SPA significa avere anche piu facilita se si vuole passare al webassembly, che ancor piu del discorso SPA, credo sia assolutamente inutile per un sito che l'utente non usa per "lavoro".
Poi ovviamente questo è un mio parere.

[alka]

ma il concetto di SPA è anche esso, a mio avviso, sopravvalutato. non credo che esista una reale necessità di fare una singola pagina piuttosto che n pagine.

Io sono perfettamente d'accordo sulla sopravvalutazione, ma sta di fatto che i requisiti che le applicazioni Web devono avere oggi non è la stessa di quindici anni fa, che l'interattività anch'essa non è la stessa e che, soprattutto quando entrano in gioco "cloud" e altre architetture di questo tipo, diventa quasi imprescindibile, oltre al fatto che per determinati framework la conversione per i device mobili è quasi automatica.

per la modularità e la sicurezza sarebbe da ampliare il discorso. cosa vieta in jQuery aggiungere un blocco? in merito alla sicurezza confesso che ne so poco ma, ho letto, che jQuery consente di interagire con WSO2..

Non c'è nulla che non si possa fare con JQuery, così come con il DOM nativo, tant'è che tutti i framework vi fanno riferimento: io mi riferivo all'agevolezza che fornisce un framework che consente di lavorare ad esempio con concetti di "binding" piuttosto che con modalità "imperative" di gestione del DOM, ossia tramite chiamate di funzioni esplicite. E' una questione che riguarda la produttività.