Sono confuso dal tuo requisito SVN. Non ho mai sentito di un framework, uno strumento o una libreria JS che causa problemi per il controllo della versione. Solitamente sono solo file statici.
Lo strumento più importante in qualsiasi arsenale di front-end è uno strumento per eliminare i problemi dei crossbrowser e l'API DOM cruft all'origine. jQuery è una scelta eccellente su questo fronte.
jQ, si basa su una filosofia di progettazione che dovrebbe seguire tutto sul front end, IMO. Rimane fuori dalla tua strada quando lo vuoi fuori dalla tua strada e gioca bene con gli altri.
Tendo ad essere meno impressionato dalle librerie e dai plug-in di JQ ma lascerei quelle scelte ai tuoi sviluppatori.
EXTJS, è l'esatto opposto diametrale. È un framework pesante che è molto difficile da decodificare a causa di un ottuso schema di ereditarietà a cascata, fa cose terribili al DOM e getta CSS assolutamente a tutto, fino a ridefinire il CSS di ridimensionamento della scatola per TUTTO sulla pagina e aggiungendo gli ID a quasi tutto ciò che non ne ha già uno. Non consiglio EXT. Da un anno desideriamo togliere l'ultima traccia dalla nostra app, ma è stato troppo doloroso per dargli il giusto impegno nel tempo. Mi viene in mente che i ragazzi che volevano creare una libreria JS meno che open source hanno scritto la peggiore per goderne la popolarità.
La mia impressione di bootstrap è che si tratti di uno strumento di progettazione. Lascia che i tuoi sviluppatori e progettisti decidano se lo desiderano. I componenti JS che fornisce non sono niente di speciale ed è scritto da persone che gestiscono livelli di complessità decisamente inferiori a quelli che sembra abbiano intenzione di affrontare. Ciò che non mi piace è che si basa eccessivamente su attributi HTML non standard (ora considerati validi in HTML5, ma rendono ancora più difficile l'HTML da leggere nel mio libro) e si aggancia a classi predefinite che descrivono stili piuttosto che tipi di componenti o gerarchia dei contenuti. Va bene avere degli hook nell'HTML, ma trovo che sia meglio quando il framework o la libreria ti permettono di impostarli.
Non ho usato il backbone, ma è molto popolare. Il turn-off per me è stato vedere come descritto come un quadro di lock-in con il quale l'autore dell'articolo voleva dire che se decidessi di voler andare avanti e usare qualcosa di diverso, sarà difficile trasferire le tue funzionalità esistenti al di fuori di esso. Ho avuto troppi mal di testa di quella natura con lo smantellamento EXT per vederlo come un compromesso accettabile per qualsiasi beneficio.
Ciò che raccomanderei seriamente è che il team sul lato client venga assemblato per primo, quindi decidere gli strumenti nel contesto di ciò che si sta utilizzando nel back-end e quali sono gli esperti di front end che considerano una buona idea per la creazione un'app facilmente estensibile con codice scritto per lungo anziché a breve termine. Nonostante la pletora di architetture architettoniche JS, widget UI e librerie HTML pre-disegnate là fuori oggigiorno, la mia scelta personale, quando ho la possibilità, è di scrivere la mia interfaccia utente, e avvolgere la zuppa jQuery negli schemi di oggetti architettonici fai-da-te con facilità di implementazione e debug in mente. Inoltre, trovo che il pattern MVC mi piace più per i suoi principi generali che per l'implementazione esatta in un contesto strettamente lato client.
In uno scenario complesso di applicazioni front-end, qualsiasi strumento che produce componenti che non sono facili da modificare, imposta restrizioni o altrimenti inquina l'ambiente lato client nel suo complesso, o pone la prospettiva di renderlo davvero difficile da abbandonare il quadro in futuro è grande no-no nel mio libro. Ma prendilo con un barile di sale. Sono un po 'moccioso e difficile da accontentare quando si tratta dei miei strumenti, in parte perché ho dovuto sopportare alcuni veramente cattivi (CMS in particolare).
Alla fine della giornata però, nulla di cui sono a conoscenza ha la stessa flessibilità del fai-da-te (eccetto jQuery che in realtà elimina solo la piastra di interfaccia utente) ma assicurati di avere un team di sviluppo che può ottenere una sorta di architettura coerente oppure potrebbero essere meglio con backbone o knockout, o JS MVC.