2009-08-07 4 views
5

La nostra azienda costruisce siti web e applicazioni web. Siamo una piccola azienda e il nostro team di sviluppatori sta sempre costruendo le funzioni javascript da zero o copiando da altri siti web creati da noi. Ogni volta che portare al tavolo la parola di standardizzazione e utilizzando un framework JS come JQuery, Prototype o di qualsiasi altro, sto Frameworks raccontate hanno i tre punti qui di seguito come argomenti contro di loro:Quali sono gli argomenti contro l'utilizzo di un framework JavaScript per una società di sviluppo di siti Web?

  • Soprattutto per le persone che non lo fanno Conoscere abbastanza JS
  • Limiti di struttura Gli sviluppatori di Javascript
  • I framework gonfiano il codice di sviluppo effettivo con molte cose che non vengono utilizzate.
  • Noi non usiamo abbastanza Javascript nelle nostre applicazioni per noi ad avere bisogno di JS quadro

Nella mia mente sembra che quadri, danno la nostra squadra un buon punto di partenza, la documentazione, una comunità e sempre la possibilità di crescere in cima alla struttura. Alcuni utenti di Framework potrebbero elaborare ulteriormente?

EDIT 1:

Grazie a tutti voi per le vostre grandi risposte. Non pensavo davvero che sarebbe stato un argomento così caldo. Sono contento di aver fatto la domanda. Ho postato un'altra domanda simile nel seguente link nel caso in cui potessi pensare di voler aggiungere qualcosa. L'argomento della nuova domanda è relativo a CSS. Grazie.

+16

I tuoi colleghi preferiscono tagliare e incollare utilizzando una libreria testata e in evoluzione? Hai pensato di cercare lavoro altrove? –

+0

Che davvero non ha senso, si finisce per scrivere molto codice (a causa dell'astrazione che si perde sul tipo di browser), se Opera fa questo altrimenti se Chrome lo fa, elsif FF lo faccia altrimenti se IE fa un diferente cosa = P. – JOBG

+1

Geo, mostra al tuo team le risposte a questo post, ma prefiguralo dicendo che StackOverflow è una raccolta dei migliori sviluppatori del mondo, la maggior parte dei quali difende i framework come a dir poco buonsenso. Quindi guarda cosa dicono. –

risposta

7

Argomenti contro:

  • quadri impediscono di re-inventare la ruota
  • Frameworks codice contengono generalmente ben testato
  • quadri sono ben supportate dalla comunità
  • quadri ti costringono a concentrarsi su il problema commerciale che stai cercando di risolvere

</sa rcasm>

  • quadri possono avere una licenza non sei d'accordo/non può funzionare con
13

Con i colleghi punto di vista, .NET e Java sono per le persone che non conoscono a sufficienza montaggio.

I quadri esistono per una ragione. Ti permettono di concentrarti sul problema invece di occuparti di codice ripetitivo. Ti permettono di essere sicuro (supponendo che tu usi framework ben testati) che certi pezzi del tuo codice siano affidabili e ben testati.

Se i tuoi colleghi sono contro le strutture, prenderei seriamente in considerazione l'idea di andare avanti.

+0

Accetto. Questo dovrebbe essere un commento ... invece di rispondere? – Surya

+0

@Cody: Sono d'accordo con te al 100%, sto cercando gli argomenti contrari per ottenere l'intera immagine delle monete a due lati. Sono davvero tentato di scegliere la risposta come risposta, ma speravo in punti contro l'idea. – Geo

1

Mi è piaciuta la risposta di pb +

Soprattutto per le persone che non conoscono abbastanza JS

Credo che sia troppo complicato per loro, in modo da utilizzare questa scusa.FW ti permette di costruire applicazioni molto più complesse.

Frameworks limitare gli sviluppatori di Javascript

stronzate

quadri bloat il codice effettivo sviluppo con un sacco di cose che non vengono utilizzati.

cos'è oggi extra 100k-200k? specialmente se usi le versioni CDN (su google per esempio). E questo presume che tu non usi nulla nel FW.

+0

100-200 k? jq è a 26k solo quando utilizzi la versione min insieme a gzip. – redsquare

+0

Questo è il massimo, non tutti usano le versioni min. –

6

Alcuni aspetti positivi per i framework javascript (come JQuery).

  1. Forniscono la standardizzazione negli elementi ui .
  2. Ridurre i tempi di sviluppo di interfacce ed effetti complessi .
  3. Normalizza gli sforzi fornendo le funzioni già compatibili con il browser crossover .
  4. Grazie agli sforzi in croce documentazione compatibilità è più utile in un quadro di come si può usare API del framework, come Canon invece di cercare oscura il supporto per vari proprietaria /javascript funzioni.
  5. Curva di apprendimento ridotta per i nuovi sviluppatori che li rendono produttivi su il software più veloce.

Sono completamente in disaccordo sul fatto che un framework limiti gli sviluppatori javascript. Al contrario, in realtà. La maggior parte dei framework fornisce estesi meccanismi di plug-in in cui il framework può essere esteso utilizzando javascript raw utilizzando gli hook nel framework stesso.

+3

jQuery rende piacevole lavorare in JavaScript. La capacità per la costruzione di alto livello di manipolazioni, effetti, ecc. Consente al programmatore di concentrarsi sull'interazione desiderata piuttosto che sulle minuzie di JS e sulla compatibilità del browser. –

+0

Esattamente. Ben detto. –

2

Un argomento contro le librerie è SUPPORTO BROWSER la maggior parte delle librerie supporta solo un sottoinsieme di browser. Here è un esempio di BBC che lancia il proprio invece di usare qualcosa come jquery.

+0

hai un esempio? –

+0

perfettamente un valido motivo .. perché downvote? – Surya

+0

Sono d'accordo, se hai bisogno di supportare qualche browser veramente fuori strada, i framework potrebbero non essere la scelta migliore. Detto questo, spesso supportano realisticamente solo i browser giusti. – deceze

7

Dal momento che nessuno lo ha menzionato, un framework Javascript diventa rapidamente un'ulteriore dipendenza del progetto e, in termini generali, le dipendenze sono negative in quanto rappresentano punti di errore.

Per quanto riguarda questo:

  • Soprattutto per le persone che non conoscono abbastanza JS

senza elaborare, devo dire che se uno dei nostri team ha detto qualcosa di simile in mia presenza , Proverei a scrollarmelo di dosso come uno scherzo. Se pensassi che fossero seri, probabilmente dovrei ucciderli.

E per quanto riguarda questo:

  • Frameworks limitare Javascript sviluppatori

Questo potrebbe tradursi in "Frameworks rendono leggermente più difficile da scrivere spaghetti code, ed è quello che so fare meglio"

Questi non sono argomenti, sono scuse.

+0

Vero come potrebbe essere il tuo punto, una libreria js non è più una dipendenza che un foglio di stile o un'immagine. Questo non dovrebbe mai diventare un problema con un progetto che è stato organizzato per trattare i file js come una risorsa simile a immagini e css. solo i miei 2 centesimi. –

+0

@Ikarii Warrior - Non sono in alcun modo contrario alle librerie JS ma secondo me (ed essendo un po 'pedante) rappresentano un punto di fallimento. Ad esempio, ieri è stato rilasciato un browser nuovo di zecca e oggi la gestione necessita di essere supportato. Affidarsi a una comunità (o un venditore) per scrivere in supporto è, a rigore, un punto di rottura. – karim79

+2

Dal punto di vista del supporto, quindi sì, potrebbe essere considerato un altro punto di errore ed è certamente un punto valido: non sto cercando di screditare il tuo contributo. :) Detto questo, la crescita del proprio javascript non ti protegge dai nuovi problemi di compatibilità del browser. –

1

Ci sono molte buone ragioni per essere sospettosi dei quadri in generale, bilanciati naturalmente da molte ragioni per cui valgono la pena.

Ora uso jquery e, francamente, entro un'ora dall'apprendimento, ho capito che si adattava così bene al lavoro che se non esistesse avrei finito solo a reimplementare qualcosa di molto simile, solo che non sarebbe stato buono o come multipiattaforma.

Non c'è molto gonfio lì, è molto piccolo e ben progettato e non fa nulla che ti impedisce di scrivere qualsiasi javascript che desideri per casi specifici che non soddisfano le tue esigenze.

3

Mi sorprende che nessuno abbia già parlato:

  • Un sacco di sviluppatori web predefinito utilizzando jQuery senza considerare le alternative
  • e finiscono per includerlo in una pagina web per fare un paio di compiti banali che potrebbe essere fatto facilmente in puro JavaScript
  • il risultato è che gli utenti devono attendere per l'intera libreria di scaricare e rallenta la navigazione sul web

anche:

  • Alcuni sviluppatori web prendere la mano con la progettazione di pagine web, e finiscono per lo sviluppo di pagine web inutilmente complessa a causa della potenza di JQuery
  • Solo perché JQuery consente di creare script con buona compatibilità cross-browser non significa che il risultato finale è utilizzabile su diversi dispositivi/interfacce
  • Discuterei anche la compatibilità cross-browser perché ho visto istanze di webkit non giocare bene con JQuery
  • JQuery incoraggia "veloce" scripting - ma se lo affretti probabilmente ti mancherà qualcosa
  • Scrivere in JavaScript da zero è più lento - ma credo che si finisca con una soluzione più completa che corrisponda maggiormente alle esigenze degli utenti
  • Utilizzando JQuery si può spostare l'attenzione dello sviluppatore web nella creazione di siti web che sono altamente grafici e visivamente accattivante, mentre ci si dovrebbe concentrare sulle funzionalità e l'usabilità
  • JQuery non è una pallottola d'argento per lo sviluppo web

io sono di parte qui perché io non uso JQuery, ma è perché mi rifugio' ne ho ancora trovato la necessità - forse perché mi concentro maggiormente sull'usabilità e sulla funzionalità piuttosto che sull'aspetto dell'interfaccia utente (scusate So che JQuery può fare di più.

+0

Non ho potuto fare un centesimo delle cose che faccio se ho scaricato 70KB di dipendenza da framework su uno o tutti i miei progetti. Grazie per avere l'integrità di parlare contro jQuery. – John

5

Userò jQuery come esempio, ma quello che sto dicendo qui potrebbe applicarsi alla maggior parte dei framework JavaScript.

Molti framework (in particolare jQuery) sono troppo monolitici e non abbastanza modulari.

Mentre a seconda del collaudato software di terze parti è spesso più che giustificato, i "framework" tendono a fornire molte più funzionalità di quelle necessarie al momento.

In molti progetti, mi piace molto la comodità offerta da jQuery per la selezione di insiemi di elementi (utilizzando $ (". Nomeclassifica"), ad esempio). Ma, se non sto usando una quantità significativa di AJAX, non ho bisogno delle utilità AJAX fornite da jQuery.

Il software dovrebbe fare una cosa e farlo bene, e il software scritto in JavaScript non fa eccezione. La maggior parte dei framework cui si fa riferimento tenta di fare di tutto, risultando in una complessità non necessaria.

Un posto che questo ti può mordere è quando stai pensando di passare alla versione successiva del framework. Ciò comporta la scansione attraverso i changelog di jQuery per le modifiche incompatibili all'indietro e la ricerca nel tuo progetto per le aree in cui viene utilizzato quel codice. Questo può essere un vero incubo, specialmente se non si dispone necessariamente di un elenco completo delle funzionalità di jQuery che si utilizzano e di quelle che non si utilizzano.

Inoltre, jQuery (e altri framework) tende a far sì che gli sviluppatori inizino a dipendere dalle nuove funzionalità di jQuery senza nemmeno pensarci, rendendo più difficile determinare quali funzionalità di jQuery vengono utilizzate dal progetto e quali no.

Se si utilizza un'utilità che fa una cosa, allora si conosce esattamente quali funzionalità di tale utilità si sta utilizzando. Ce n'è solo uno. (Se non si utilizza affatto quell'utilità, è facile da determinare: una determinazione del genere significherebbe che è possibile rimuoverla dal progetto.)

Sono tutto per l'utilizzo di codice di terze parti ben testato. Ma se cerca di fare troppo, (se è un quadro piuttosto che un'utilità), probabilmente dovresti cercare un'alternativa. Se prova a fare troppo (come jQuery cerca di fare troppo), allora ha alcuni difetti di progettazione fondamentali che probabilmente torneranno a morderti.

Problemi correlati