L’ambiente è stato completamente rivoluzionato. Per alcune cose (poche) in meglio, per altre (molte) in peggio. In generale si nota una spiccatissima tendenze ad assomigliare più possibile a OSX. Per non dire che lo stanno copiando a man bassa.

I pregi

Partiamo con i pregi che, come ho detto, non sono molti. Il più importante, e forse quello di cui pochi si sono accorti, è la possibilità di trascinare una finestra verso uno dei bordi destro o sinistro, e automaticamente la finestra si ridimensiona a metà schermo e si aggancia al bordo. Rende molto semplice affiancare due finestre, per esempio per copiare file o per tenere un editor su una e una shell (per compilare) o un browser (per testare un sito) sull’altra.

Utile anche lo stesso effetto sul bordo superiore, che massimizza la finestra.

Sarebbe stato bello se trascinandola contro il bordo inferiore occupasse la parte di mezzo dello schermo, rimpicciolendo le parti destra e sinistra, in modo da averne tre affiancate, o occupasse la parte inferiore dello schermo, simulando di fatto il layout di molti programmi di posta.

Altro “wish” sarebbe stato che tenendo cliccato, dopo aver raggiunto il lato dello schermo, un movimento verso l’alto o il basso avesse permesso di decidere la dimensione della finestra (metà, 1/3, 1/4, ecc. di schermo).

L’altro pregio notevole è una maggiore sensazione di velocità. Principalmente è dovuta agli effetti di fading, che fanno sembrare più fluido il tutto, ma non ci stanno male.

Il dialog che appare premendo Alt-F2 (sulle impostazioni standard) o Menu (sulle mie) è molto più veloce rispetto al precedente, ma ha il difetto di non mostrare le alternative sull’auto-complete, quindi o si conosce il nome completo dell’applicazione o si rischia di dover ricorrere al menu Attività (che è lentissimo).

I “neutri”

Ad alcune novità probabilmente ci si può abituare.

Mi riferisco soprattutto alla posizione della barra, forzatamente in alto (io la preferisco in basso).

Sempre riguardo la barra, non si possono posizionare le “applet” (qui chiamate estensioni) come si preferisce. Per spostare un elemento bisogna installare un’altra estensione o modificare il codice di quella che c’è (che è in javascript). Mi potrebbe anche andare bene se ci fosse un manuale con le API scritto bene.

Le impostazioni di sistema sono più ordinate e hanno meno opzioni. Mi andrebbe benissimo, se ci fosse un modo per impostare quelle più avanzate. C’è solo gconf-editor, ma a trovarne alcune è un terno al lotto, e altre semplicemente sembrano non esistere.

E` sparita completamente la gestione dei temi. C’è solo quello di default. Che sarebbe carino se non avesse i titolo delle finestre attive e inattive troppo simili tra loro (è solo più sbiadito il testo). Per fortuna almeno mi lasciano mettere i bottoni sulla barra come voglio io (close:minimize,maximize,menu)

I difetti

Ma veniamo alla parte più corposa di questa “mini recensione”. Non saprei quale sia il più grave, quindi li elenco nell’ordine in cui mi vengono in mente.

Non esiste una scorciatoia per la funzione “cicla tra le finestre di questo workspace”, che era lo standard di Gnome 2. Si può ciclare tra tutte le finestre dell’applicazione attuale, o tra tutte le applicazioni del workspace corrente, ma non tra le finestre. Io tengo 4-5 finestre di Chrome nel workspace 10, e altre sparse nei workspace 4, 5 e 6. Tengo Evolution e Pan nel 9, Skype e Pidgin nell’8. Ogni tanto l’alt-tab mi cambia workspace e non capisco dove sono, anche perché (difetto numero 2) non ci sono indicazioni visuali. Non c’è più l’indicatore di workspace nella barra.

Non c’è più (difetto 3) nemmeno la lista delle finestre del workspace corrente. E quindi (difetto 2+3=4) non c’è più nessun tipo di anteprima (anche statica) delle finestre. Quindi pidgin che mette un asterisco sul titolo della finestra con nuovi messaggi, evolution che mette il numero di mail non lette, Chrome che mette il titolo del sito, ecc. non si vedono più.

E (difetto 5) non ci sono più aree di notifica persistenti, quindi non vedo a colpo d’occhio se ho ricevuto un IM o un’email, o se ho finito un download. E il menu “personalizzato” in alto a destra fa intuire un’integrazione con gli IM, ma l’impressione è che non funzioni. O almeno, finché non ho aperto pidgin, i miei amici non mi vedevano online su GTalk, e io non sapevo come vedere loro e come mandargli messaggi.

Non essendoci la lista di workspace (difetto 6) non posso nemmeno spostare velocemente le finestre da un workspace all’altro.

La finestra attività (difetto 7), spudoratamente copiata da OSX come effetto, mi sembra inutile. Posso intuire le intenzioni vista la lista dei difetti precedenti, ma ne ha uno grossissimo: è inutilizzabile senza mouse. La lista delle applicazioni è disorganizzata. Ci sono le categorie a destra, ma trovo enormemente più veloce il vecchio sistema ad albero. E si può usare solo col mouse. La barra delle applicazioni preferite è inutile quando ne usi più di una decina.

E passiamo alla barra inferiore. Perché c’è, ma non si vede (difetto 8)! Basta spostare il mouse sul lato inferiore dello schermo e appare. E qui ci sono le icone di notifica! Con tanto di aggiornamento in tempo reale, quindi pidgin annuncia un nuovo messaggio e evolution una nuova mail. Ma li vedi sono se sposti il mouse lì. Quindi sono inutili. Faccio prima a fare Alt-F8 (rimappato a “go to workspace 8″ da me), sbirciare le finestre, e rifare Alt-doveeroprima per tornare a lavorare. Ma devi ricordarmi di farlo, mentre prima lo vedevo con la coda dell’occhio.

E il fatto che questa bella barra appaia sopra il resto significa che se sei su Chrome in maximize, su un sito lunghissimo, e vuoi prendere il knob dello scroller per tornare in cima, non puoi. O almeno devi stare attento a non avvicinarti troppo al bordo inferiore dello schermo, altrimenti la barra si sovrappone (difetto 9).

Ma torniamo ai workspace: sono dinamici (difetto 10)! Non posso decidere di averne 10 e di posizionare le finestre come mi trovo meglio per passare tra i workspace con una combinazione di tasti. Dovrei aprire le finestre nel workspace corrente e poi, da Attività, spostarle manualmente dove mi trovo meglio. Il risultato finale è un semplice “fuori dalle balle, mi serve questo workspace libero” che incasina tutto e non permette di avere un ordine.

Il difetto 11 probabilmente è un bug che verrà risolto. Se lascio il PC incustodito per qualche ora (acceso di notte) parte il salvaschermo. Lo schermo diventa nero, nella barra in alto c’è il mio nome con un lucchetto di fianco e al centro un orologio con l’ora sbagliata (alle 10 di stamattina segnava l’una di notte). E questo nonostante abbia disattivato il blocco dello schermo dalle impostazioni.

Il problema è che non sembra ci sia un modo razionale e deterministico per uscirne. Muovere il mouse, cliccare sul lucchetto, sul nome, sull’ora o da qualsiasi altra parte non serve a niente. Qualche volta, dopo 5-6 MINUTI, si sveglia e mostra il desktop. Altre volte devo andare in console e killare gnome-session (e con lei tutte le applicazioni aperte).

I palliativi

Per alcuni difetti ci sono palliativi.

Per esempio per il 6 basta andare nelle Attività (premendo il tasto Windows di sinistra) e trascinare le finestre da lì.

Per il 3 c’è un’estensione che mostra la lista delle finestre aperte, ma non si aggiorna in tempo reale (bisogna cambiare workspace e tornarci) e soprattutto mostra solo il nome dell’applicazione, e non il titolo impostato dalla stessa. Quindi quasi completamente inutile. Serve solo a sapere che ci sono altre finestre aperte lì.

Per il 2 c’è un’estensione che mostra il numero di workspace in cui ci si trova, ma senza preview. Anche questo poco utile.

Per il 10 c’è un’estensione che permette di averne un numero fisso. Ho dovuto modificarla un po’ (il codice era pessimo), ma funziona.

Commenti finali

Insomma, sembra tutto pensato per dover per forza usare il mouse, per farti perdere tempo e per somigliare più possibile a OSX.

Ma se volevo OSX compravo un Mac. E io non voglio OSX. Voglio un ambiente personalizzabile, che mi consenta di toccare il mouse meno possibile, che non si metta in mezzo quando cerco di lavorare. E Gnome 3 non va nella direzione giusta. Nei prossimi giorni (ri-)proverò XFCE e KDE e prenderò una decisione.

Il PHPday quest’anno si sposta a Verona, e cerca di dare un taglio ancora più ampio all’evento, allungando la durata a due giorni e introducendo il canale “community” per la presentazione di prodotti opensource. Ci saranno inoltre dei lightning talk, dei “dibattiti” improvvisati dai partecipanti.

Consultate il sito per il programma completo, tuttora non definitivo, ma già con diversi argomenti interessanti sul piatto, almeno per me. Inoltre sarà una buona occasione per incontrare sviluppatori preparati e competenti, merce abbastanza rara, purtroppo.

La novità mal recepita (al punto da generare un post molto risentito del presidente del GrUSP, il gruppo organizzatore) dai partecipanti, invece, è il prezzo di iscrizione, fissato in € 100 per la partecipazione a entrambe le giornate (60 per una sola), che aumenta a 160 (e 90) se ci si iscrive dopo il 16 aprile.

Secondo me, visto quello che viene offerto (soprattutto il pranzo e due buffet per ogni giornata) non è per niente alto, ma posso capire che, per chi è abituato a parteciparvi gratis dagli eventi precedenti, rappresenti un po’ un trauma.

Probabilmente l’affluenza sarà inferiore agli anni scorsi, ma di contro il pubblico sarà più mirato e interessato.

Credo che farò il possibile per partecipare.

Oggi, dopo un mese di sviluppo di un sito, lo metto in produzione e mi accorgo che con Galeon le textarea non vengono “trasformate” in editor wysiwyg da FCKeditor.

Subito penso che sia un bug nel plugin per jquery che integra FCK e vado sul suo sito ( http://www.fyneworks.com/jquery/FCKEditor/ ), e infatti nemmeno lì la demo funziona. Ma prima di scavare nel javascript, vado anche sul sito di FCK ( http://www.fckeditor.net/ ) . E nemmeno lì funziona.

E, naturalmente, la persona che deve usare quel sito usa sempre Galeon…

La cosa strana è che Epiphany (che usa la stessa versione di libnspr e di xulrunner) e Firefox/Iceweasel funzionano perfettamente. E che (Tiny)MCE funziona senza problemi anche in Galeon, visto che lo sto usando per scrivere questo post.

Toccherà scrivere un plugin per Zend Framework anche per MCE…

Nel frattempo, se qualcuno ha suggerimenti su come integrare FCK in Galeon, sono i benvenuti.

Ormai la percentuale di SPAM nelle mail ricevute ha raggiunto il 90% e gli spammer, non contenti, da alcuni anni sfruttano anche i Blog e i CMS per impestare la rete con le loro schifezze.

Per quanto riguarda le mail è un continuo inseguimento: blacklist, filtri bayesiani, OCR sulle immagini, ecc. Ma anche i siti hanno dovuto rincorrere le continue innovazioni da parte degli spammer.

CAPTCHA

Sono quindi nati i CAPTCHA di vario tipo, che si basano sulla (presunta) incapacità dei bot di spam di “leggere” il testo contenuto in un’immagine. Il sistema ha funzionato per un po’, finché i sistemi si sono evoluti e hanno iniziato a usare tecniche di OCR sui CAPTCHA stessi, facendone perdere efficacia: sono diventati via via più difficili da decodificare, ma anche per l’occhio umano oltre che per i bot.

Ne sono nati quindi nuovi tipi: dal CAPTCHA matematico (che potete ammirare nel form dei commenti di questo Blog ) a quello “sexy”, che si basa sulla capacità di una persona di distinguere un rappresentante bello del sesso opposto da uno brutto.

Purtroppo hanno tutti lo stesso problema: una persona con problemi di vista o qualcuno che naviga con browser testuali non li può utilizzare. Sono allora nati gli aiuti sonori ai CAPTCHA (che “pronunciano” le lettere nel CAPTCHA, per esempio), ma si scontrano col problema dell’audio sui siti: se l’utente sta ascoltando musica in sottofondo deve spegnerla, ascoltare il CAPTCHA, compilare il form, quindi riaccendere la musica

In un periodo in cui bisogna rendere la vita più semplice possibile all’utente, tutte queste complicazioni sono anacronistiche, e allontanano gli utenti.

Vediamo quindi alcune alternative, magari non perfette, ma con una buona percentuale di sicurezza.

Il campo nascosto nel form

Una prima tecnica consiste nell’aggiungere un campo di testo normale in un form, quindi di nasconderlo tramite CSS. Questa tecnica si basa sul presupposto che i bot, per sfruttare il maggior numero possibile di form, non guardano quali campi compilare, e invece li compilano tutti.

Si può quindi usare un codice come questo:

<style>
 .nascosto { display: none; }
</style>

...

<form ...>
 ...
 <div class="nascosto">
  <label for="codicesegreto">Non scrivere nulla in questo campo</label>
  <input type="text" name="codicesegreto" />
 </div>
 ...
</form>

In questo modo i browser che supportano i CSS nasconderanno l’intero div (è un esempio, naturalmente. Va adattato a come stilizzate i vostri form) e l’utente non vedrà nemmeno il campo. I browser che non supportano i CSS lo mostreranno, ma con il messaggio all’utente di non compilarlo. I bot non avranno idea di cosa si trovano davanti e lo compileranno senza pensarci (pensare? un bot??).

Lato server basta controllare che il campo “codicesegreto” del form non contenga nulla. Per esempio, in PHP:

<?php
 if (isset($_POST["codicesegreto"]) && $ POST["codicesegreto"] != "") {
  print("Ciao, bot! PRRRRRRRRRRR");
  exit;
 }
 // Normale processo di verifica degli altri campi
?>

Il codice nascosto nel form

Un’altra tecnica consiste nel nascondere un codice segreto nel form, e modificarlo via Javascript appena il form viene visualizzato:

<form...>
 ...
 <input type="hidden" id="codice" name="codicesegreto" value="1000" />
 <script type="text/javascript">
  <!--
   document.getElementById("codice").value = "mille";
  -->
 </script>
 ...
</form>

Questa tecnica si basa sul presupposto che il bot non esegua il codice javascript contenuto nel form. I browser che supportano Javascript avranno quindi codicesegreto=”mille”, mentre quelli che non lo supportano avranno codicesegreto=”1000″. I valori, naturalmente, sono di pura fantasia, potete mettere quello che volete, anche valori casuali calcolati server-side prima di presentare il form, e salvati in sessione per una verifica successiva.

Lato server, al ricevimento dei dati dal form, basta appunto controllare cosa contiene quel campo. Se contiene “mille” si procede normalmente con l’analisi degli altri campi del form. Se contiene “1000″ si può presentare all’utente un nuovo form, chiedendogli solo “Sei davvero una persona o sei un bot?” con un tasto submit: “Sono una persona”. Solo le persone (che hanno disattivato javascript nel browser) dovrebbero clickare su questo nuovo form, e quindi procedere al submit del form.

In PHP si può fare una cosa del genere:

<?php
 session_start();

 if (isset($_POST["codicesegreto"]) && $_POST["codicesegreto"] != "mille") {

  $_SESSION["datiform"] = $_POST;
  ?>
   <form ...>
    <label>Sei davvero una persona o un bot?</label>
    <input type="submit" name="chidicicheiosia" value="Sono una persona!" />
   </form>
  <?php
  exit;

 } else {
  // Normale procedura di controllo dei campi e di submit del form
 }
?>

Questo “giro” è un po’ più oneroso per gli utenti che disabilitano Javascript, ma non gli preclude la possibilità di scrivere commenti o comunque di compilare il form. Se Javascript è attivo la procedura è totalmente automatica. Naturalmente bisogna predisporre anche la pagina aggiuntiva per il controllo della conferma, oppure modificare la logica di questa in modo da gestire sia il submit diretto che quello con conferma.

Vantaggi e svantaggi

Il vantaggio più evidente è la semplicità, sia per il programmatore che per l’utente.

L’utente non deve compilare campi aggiuntivi, non deve cercare di interpretare strane immagini deformate o fare calcoli matematici. Tutte operazioni che, spesso, non capisce nemmeno a cosa possano servire.

Il programmatore non dovrà più fare i salti mortali per distorcere il testo in modi astrusi, complicarsi la vita con le libgd, o cercare font non “OCR-izzabili”. Non dovrà nemmeno fare funzioni aggiuntive per rigenerare l’immagine al volo (via AJAX, magari) nel caso l’altra sia illeggibile. Il codice, sia HTML che PHP, è molto più pulito.

Inoltre il traffico sulla rete è molto ridotto: non c’è un’immagine che comunque occupa una decina di KiB, e c’è anche una richiesta HTTP in meno. In generale il sito è più leggero.

Altro vantaggio è che questi due sistemi possono essere combinati per raddoppiare l’efficacia.

Lo svantaggio è totalmente dipendente dall’intelligenza dei bot. Se i bot riusciranno ad adeguarsi a queste tecniche, queste perderanno d’efficacia. Per farlo, naturalmente, dovranno imparare ad interpretare sia i CSS che il Javascript, ma basterebbe adeguare un po’ gli stili e il codice JS facendo le cose in modo un po’ più complesso (richiamando funzioni o metodi di oggetti in JS, o usando selettori in CSS). A quel punto dovrebbero diventare veri e propri browser. Non escludo possa succedere, ma nel frattempo si potranno inventare nuove soluzioni.

Per ora dovrebbero essere più che sufficienti.

Dopo il post per gli auguri di Natale sicuramente non ve ne aspettavate uno per gli auguri di buon anno, vero?

Voevo postarlo poco dopo mezzanotte, ma la baldoria prima e la stanchezza poi mi hanno fatto desistere. Non credo sareste comunque stati lì a quell’ora a leggerlo, quindi non penso vi cambi molto la vita.

Siccome a capodanno si elencano i buoni propositi per l’anno che sta arrivando, ho pensato di raccogliere qui i miei. Magari qualcuno è d’ispirazione anche per voi. Sono in ordine sparso, man mano che mi vengono in mente.

Studiare il D (e altri linguaggi)

Da quello che leggo in giro, D è un ottimo linguaggio di programmazione, e in realtà ho già dato un’occhiata alle specifiche del linguaggio e agli esempi sul sito ufficiale. Quello che ho visto mi ha favorevolmente impressionato. In pratica è un linguaggio che cerca di prendere le parti migliori di C/C++ e di Python/Ruby. Molto flessibile, dinamico (non del tutto, naturalmente) e soprattutto compilato. Le prestazioni dei programmi scritti in D sono ottime e, a giudicare dagli esempi, è anche semplice scrivere programmi. Mi ricorda vagamente il linguaggio E che esisteva sull’Amiga, anche se in quel caso derivava da Pascal e Oberon, quindi con una sintassi più rigida.

Una delle sorprese più gradite è stato scoprire che ci si potevano fare cose come Torus Trooper e TUMIKI Fighters (non fatevi ingannare dalla grafica, sono molto divertenti ) in modo quasi completamente cross-platform.

Anche Vala sembra interessante. Si tratta di un linguaggio inventato dal team di Gnome, ispirato a C#, e molto orientato a scrivere applicazioni per Gnome (anche se, dagli esempi, sembra adatto un po’ per tutto). Lo stanno già usando per scrivere Scratchpad e anche Mickeyl per riscrivere openmoko-terminal2. Il vantaggio principale rispetto a C# stesso è che è completamente compilato, quindi non ha bisogno di virtual machine o di ambienti di runtime, o anche solo di librerie aggiuntive. A detta degli stessi sviluppatori è ancora acerbo, e molte cose sono in via di sviluppo, ma quello che c’è ha già un bell’aspetto.

Tornare in Giappone

Questo probabilmente è un proposito che non riuscirò a portare a termine entro il 2008, ma ci spero comunque. Mi mancano l’ordine e la cortesia dei giapponesi, mi manca Akihabara, mi manca il cibo giapponese. Insomma, non vedo l’ora di tornarci.

Mi sono messo come limite la primavera del 2009. Ce la posso fare! Ganbatte!

Finire i programmi e i siti che ho in corso

Questa forse è la parte più difficile di questi buoni propositi. Purtroppo la parte che mi “prende” di più di un progetto è la preparazione, le prime fasi di stesura del codice, l’organizzazione dei moduli, mentre odio totalmente e profondamente la fase di debug. Di solito il dover debuggare un software è motivo sufficiente per abbandonarlo a sé stesso. Probabilmente aspetterò l’uscita della quarta edizione di D&D per rimettere mano (e riscrivere per la terza volta) il mio Mastertools, software (in Python+Gtk+SQLite) di gestione delle campagne, con annesso database di magie (già funzionante), talenti e oggetti magici (non ancora funzionanti).

Spero di riuscire nei prossimi giorni a buttare giù almeno le basi di due siti che ho in testa da almeno un paio di mesi e di un altro paio di programmini che sto progettando da altrettanto tempo. Ma non voglio rivelare niente, anche per scaramanzia.

Comprare l’Asus Eee

In realtà sto aspettando la versione con schermo a 8, 9 o 10 pollici. Mi andrebbero bene anche i 7″ della versione attuale, ma con risoluzione almeno 1024×600. Meglio ancora 1280×768. Una bella formattata alla flash, una bella Debian con Gnome al posto della Xandros, una SDHC da 16-32 Gb montata come /home e via!

Se non sarà l’Eee sarà sicuramente un altro subnotebook di caratteristiche analoghe: 1 Kg di peso, dimensioni molto ridotte. Gradirei molto anche una durata maggiore della batteria.

Mi sono accorto che il notebook che ho ora (Dell Inspiron 8600) non lo uso mai (praticamente solo per masterizzare partite di D&D): troppo pesante (3.5 Kg), troppo ingombrante (schermo 15,4″, quindi notebook di oltre 17″), e relativamente fragile, avendo un HD al posto di una flash. E la tastiera è comunque ridotta rispetto al fisso, quindi difficile da usare. In proporzione uso di più lo Zaurus, sia per leggere e-book sia per scrivere.

Migliorare la conoscenza di PHP, Javascript e Python

Programmando in PHP per lavoro, la prima parte di questo proposito è abbastanza semplice da portare a termine, basterà continuare a lavorare . Ci sono comunque diversi argomenti che mi piacerebbe approfondire. Per esempio ho l’impressione di star usando poco e male lo Zend Framework, e che abbia ancora molte qualità nascoste da esplorare. Per di più, sta uscendo la nuova versione 1.5 con supporto per View estese e Layout!

Javascript è ridiventato molto interessante (per me, naturalmente) di recente, grazie all’arrivo di librerie e framework come jQuery che nascondono abbastanza bene le differenze più ostiche tra i browser e permettono di concentrarsi meglio sul lavoro da svolgere, più che sulle incompatibilità tra le varie versioni. Spero di poterlo approfondire maggiormente.

Purtroppo ho un po’ lasciato in disparte Python per motivi di tempo, e comunque non ero un esperto nemmeno prima. Devo impormi di riprenderlo in mano e di studiarmi bene le caratteristiche della nuova 2.5 (decoratori e compagnia cantante).

Lo nascondo qui ma non fateci caso: mi piacerebbe anche studiare un po’ Ruby. Tra l’altro è appena uscita la 1.9 che sembra abbia prestazioni molto superiori alla precedente. Tutti ne parlano, ma ora che l’hype iniziale dato da Rails si sta esaurendo, forse è il momento giusto per vedere cosa offre di veramente vantaggioso rispetto agli altri (rails a parte).

Postare più frequentemente sul blog

Questo non sarà proprio facilissimo. A volte un argomento mi pare troppo scontato o trito per parlarne qui, e voglio evitare di parlare di politica o cose del genere (che sono una flame-bait non da poco). Per scrivere post tecnici preferisco informarmi bene ed evitare di scrivere porcherie non verificate, anche se a volte devo fidarmi di quello che trovo in giro, non avendo la possibilità di provarlo direttamente.

Ciononostante, cercherò di trovare qualche argomento di cui parlare. Magari portare avanti i propositi di cui sopra mi darà anche qualche spunto interessante.

Dulcis in fundo…

Ah, naturalmente riportare la pace nel mondo! (Ecco il link diretto al sito. O una variante, se la preferite, in fondo i gusti sono gusti).

jQuery è una libreria in javascript per semplificare lo sviluppo client-side di siti, che offre in pochissimo spazio (20 Kb compressa, meno di 100 non compressa) funzioni utilissime per la navigazione e la modifica del DOM, per le richieste AJAX e per alcune animazioni di base (fading, folding, ecc.).

Per mantenere minimo l’impatto sui download è stato scelto di lasciare a plugin esterni la gestione di funzionalità aggiuntive, e di inglobare solo le più usate nel core. Uno dei plugin più famosi è UI, per la realizzazione di interfacce interattive.

Koller Juenger, nel suo blog, ha raccolto una lista di più di 240 plugin per jQuery, suddivisi anche per categoria e uso. Un lavoro titanico e molto utile.