Supporta più framework in una libreria JavaScript

Non lo fai. Non si costruiscono librerie su framework. Devi solo supportare gli standard, come il DOM e ES5.1

Questi standard funzionano nei browser moderni, se gli utenti delle biblioteche vogliono supportare i browser legacy e dire loro di usare uno qualsiasi dei polyfill standard.

Il tuo problema è come se ti venisse chiesto di fare un'app che può utilizzare .NET Framework o Java o un componente del sito web che funziona con Silverlight o con Flash, a seconda di ciò che l'utente ha.

È possibile tecnicamente, ma porta a codice duplicato e difficoltà di manutenzione . Non ha niente a che fare con questo .

Ecco perché la maggior parte delle librerie JavaScript utilizza solo uno e un solo framework.

Questo è anche il motivo per cui la maggior parte dei framework è in grado di lavorare fianco a fianco : consente di utilizzare diverse librerie che utilizzano diversi framework su uno stesso sito¹¹, evitando collisioni in nomi di metodi come $() .

Nota sul consiglio dato in altre due risposte: "non creare librerie su framework" . È, beh, troppo idealista. Questo consiglio potrebbe essere applicato a forse l'1% delle librerie , probabilmente molto meno: le librerie che sono scritte da team di sviluppatori in grado di costruire una libreria che funzionerà su qualsiasi browser, che sarà comunque manutenibile e che richiedono, per qualche ragione, nessun quadro.

Questo potrebbe essere il caso, per esempio, se stai scrivendo una libreria che verrà utilizzata nella home page del sito web Amazon²: devi minimizzare la dimensione del codice JavaScript a tutti i costi per motivi di prestazioni / larghezza di banda, e hai abbastanza sviluppatori competenti per non utilizzare alcun framework.

Al di fuori di Amazon / Google / siti web in scala Apple, non seguire mai "non creare librerie su framework" consiglio , a meno che la tua libreria sia troppo semplice per richiedere un struttura. Invece:

• Riutilizza, invece di reinventare la ruota,
• Trascorrere del tempo facendo qualcosa di utile e interessante, ovvero scrivendo la tua libreria, invece di scrivere qualcosa già disponibile in ogni framework,
• Fidati dei framework: sono scritti da persone competenti che sanno cose che potresti non sapere o dimenticare,
• Affidati alle astrazioni: quando utilizzo un'animazione JQuery, so che funzionerà con Chrome, Firefox, Safari, Opera e persino con Internet Explorer. Quando creo il mio, devo testarlo in quei cinque browser (fino a dieci se conti le loro versioni principali), e sono abbastanza sicuro che fallirò la prima volta almeno in un browser.

^{¹ Questa è la cosa che non vuoi fare se ti interessa la qualità del tuo sito web. Tuttavia, molti siti Web no e non è raro trovare due, a volte persino tre framework JavaScript su uno stesso sito Web affiancati.}

^{² Si noti che, in base al sito Web di jQuery, Google, Dell, NBC, ecc. lo stanno utilizzando, quindi non è perché si sta lavorando su un sito Web su larga scala che non è possibile utilizzare un framework. In pratica, le grandi aziende finiranno per inventare la propria, che si adatta meglio alle loro esigenze. Questo è il caso ad esempio di Google e della sua Biblioteca di chiusura .}

Sono d'accordo con Raynos qui; non creare librerie su framework.

Non mi è chiaro perché prototype.js sia un "framework" e jQuery è una "libreria", comunque. Sembrano estremamente simili per scopo e scopo.

O sono entrambi framework, implicando che sono pensati per la creazione di applicazioni piuttosto che di librerie, o sono entrambe le librerie ... ma, come librerie, sono entrambi abbastanza generali; probabilmente non è la migliore idea per costruire altre librerie su una delle due, dato che hai introdotto una dipendenza per il tuo utente con un po 'di extra cruft non utile per realizzare qualunque cosa sia la tua libreria.

In altre parole, la maggior parte delle librerie (a parte le librerie "general purpose") hanno lo scopo di fornire alcune funzionalità specifiche e presumo che ciò includa la tua libreria. Diciamo per la discussione che la tua libreria è per il drag-and-drop di modifica delle pagine, quindi hai fatto uso di alcuni dei codici di astrazione di gestione degli input del mouse in una delle librerie GP ... Ok, ma a causa della progettazione delle librerie GP, ciò significa che è necessario includere l'intera cosa solo per la gestione del mouse. Questo potrebbe essere accettabile in un'applicazione, ma per una libreria non è davvero accettabile.

Se scrivessi una libreria in C ++ e dovessi includere ogni singola libreria nel framework boost come dipendenza, sarebbe enorme e nessuno la userebbe. Fortunatamente il boost è progettato in modo modulare, come librerie separate, quindi nessuno lo fa.

Al contrario, le popolari librerie GP JS sono state progettate come offerte in un unico pezzo. Hai bisogno di gestire l'input del mouse? Ottimo, devi anche includere la gestione della tastiera, i selettori di query, i wrapper XHR, lo zucchero DOM, ecc. Ancora una volta, puoi ignorarlo in un'applicazione, ma in una libreria fatta per altri sviluppatori da usare, questo è pazzesco. Non ha senso introdurre dipendenze in cui il 95% del codice è irrilevante per la tua libreria e non verrà mai eseguito.