È mootools alternativa di jquery + backbone / spine / sprouteCore

4

Ero uno sviluppatore Java a tempo pieno, ora sto lavorando anche con JavaScript e Android. Un paio di anni fa, quando ho iniziato a imparare JavaScript, la prima libreria che ho provato era jQuery. Ma ha reso la mia vita più difficile, e dopo qualche tempo ho iniziato a scrivere un'app JavaScript di dimensioni abbastanza grandi. Non stava venendo insieme per me usando jQuery. Ho avuto un enorme codice base senza molto di una struttura. Il metodo blocca l'aggiornamento dei blocchi HTML usando selettori.

Poi ho provato MooTools e ovviamente come sviluppatore Java mi piaceva molto. E sono stato in grado di scrivere app web gestibili con un'enorme base di codice.

Per quanto ne so, MooTools non è considerato un modo preferito per scrivere JavaScript perché imita il linguaggio OO convenzionale basato sul prototipo OO convenzionale. Quindi ora per capire veramente Javascript e il desiderio di camminare con il mondo, ho deciso di provare altri approcci, quindi di nuovo mi sono voltato verso jQuery e ho capito che solo jQuery non è sufficiente.

Quindi abbiamo iniziato a esaminare i framework di tendenza attuali come backbone, spine, ember.js, sprouteCore. Stranamente ho scoperto che questi framework imitano il convenzionale OO come MooTools solo avendo costruttori e creando un oggetto di classe e riutilizzando questo oggetto di classe per creare oggetti di istanza. Quindi

  • Mi manca qualcosa?
  • MooTools ha davvero torto?
  • Il progetto MooTools è molto vivo e rilascia nuove versioni / funzionalità, ma io no vedo molte persone che ne parlano su internet, inoltre non ci sono confronti vs spina dorsale / colonna vertebrale ecc.
posta Nachiket 22.02.2012 - 19:54
fonte

2 risposte

4

Non ti manca nulla.

Il metodo pseudo-classico di JavaScript orientato agli oggetti è una tecnica accettata da molto tempo. Non c'è sicuramente alcun motivo per cui non puoi usarlo.

Ci sono un paio di motivi per cui alcune persone lo rifuggono, anche se (me compreso):

  • È una direzione sbagliata - il modello pseudo-classico, per necessità, utilizza l'eredità prototipale, ma questo non è ovvio. Le persone a cui piace sapere cosa succede a un livello basso (leggi: io) non amano le astrazioni non ovvie.
  • Purismo - onestamente non è un grande motivo, ma sapere come funziona JavaScript è buono.

Ci sono anche diversi motivi per cui le persone evitano i framework in generale:

  • Overhead
  • Misdirection (astrazioni non ovvie)
  • API scadenti (che ovviamente dipende dal framework)
  • Mancanza di modularità (hanno bisogno di una parte del framework, ma non si vuole caricare tutto)

La tendenza, per le persone che vogliono evitare i framework, è usare le micro-librerie, in modo che non debbano reinventare la ruota. XHR cross-browser può essere scritto in meno di 20 righe (forse molto meno). L'interazione DOM è allo stesso modo facile. Le animazioni sono meno così, ma ci sono ancora piccole librerie che possono fare animazioni. Questo è un approccio modulare che segue il concetto di YAGNI e mantiene bassi i tempi di caricamento.

jQuery in particolare ha un sacco di problemi. Alcuni dei quali sono risolti da MooTools (che sto appena iniziando a esplorare da solo). Personalmente, non ho familiarità con molti framework JS, ma li sto esplorando semplicemente per esplorarli.

Trovo che siccome conosco JavaScript abbastanza bene e come costruire correttamente il codice orientato agli oggetti nel linguaggio, non ho bisogno di molte delle strutture che ho da offrire. Non ho problemi a utilizzare l'API DOM nativa. Non ho alcun problema nell'usare modelli di ereditarietà prototipali nativi. E non ho problemi a usare i CSS per i bit di presentazione (in particolare le transizioni).

Quindi, dato che sono diventato più esperto nei modi di JavaScript, le strutture sono diventate meno belle e più pesanti. Tengo d'occhio il codice semplice e modulare che è in linea con YAGNI e DRY, e penso che le mie applicazioni siano migliori per questo.

    
risposta data 22.02.2012 - 22:57
fonte
0

Se ti manca qualcosa, penso che sia solo il gran numero di framework / librerie JS ti dà la possibilità di scegliere quello che funziona meglio per te. Non sono personalmente un appassionato di tecniche che cercano di forzare il peg rotondo di JavaScript nel buco quadrato del classico OOP, ma la mia preferenza personale è ben servita dall'incredibile serie di alternative a mooTools che sono più prototipali.

Diamo un'occhiata a Google Web Toolkit : ti permette di scrivere il tuo codice in Java e lo traduce in JavaScript da eseguire nel browser. È molto improbabile che il codice JavaScript risultante abbia una certa purezza o correttezza JavaScript. Probabilmente non andrà bene con JSLint, ma perché ti interessa se la tua applicazione funziona nel modo desiderato.

Allo stesso modo, il linguaggio CoffeeScript viene compilato su JavaScript e offre un'esperienza di programmazione completamente diversa. Alcune persone lo giurano e non potrebbero farne a meno. Altre persone sviluppano app web grandiose e non hanno passato cinque minuti a guardarle.

Quindi se mooTools o qualche altro framework presenta un classico OOP su JavaScript, perché ti interesserebbe fintanto che sei produttivo e la tua applicazione funziona?

Scott Hansleman ha chiamato JavaScript Assembly Language del Web . Dopo averlo fatto, naturalmente, è stato immediatamente d'accordo e insultato da un gran numero di sostenitori e oppositori altrettanto convinti, ma c'è un nocciolo duro di verità che ogni ingegnere dalla mente aperta vedrà. È (secondo me) a credito di JavaScript che è abbastanza flessibile da essere sia una lingua principale che un target per i compilatori.

Finché l'approccio funziona per te e per chiunque tu stia sviluppando e fa funzionare la tua applicazione, seguila. Tutto il resto è solo un predicatore che grida le loro credenze speciali.

    
risposta data 22.02.2012 - 21:57
fonte

Leggi altre domande sui tag