Come convincere il mio capo (e altri sviluppatori) a usare / considerare JavaScript discreto

Sono abbastanza nuovo nel nostro team di sviluppatori.

Ho bisogno di argomenti forti e / o esempi di "trabocchetto", quindi il mio capo comprenderà finalmente i vantaggi di JavaScript discreto, in modo che lui e il resto del team smettano di fare cose del genere:

<input type="button" class="bow-chicka-wow-wow" 
       onclick="send_some_ajax(); return false;" value="click me..." />

e

<script type="text/javascript">

function send_some_ajax()
{
  // bunch of code ... BUT using jQuery !!!
}
</script>

Ho suggerito di utilizzare un modello abbastanza comune:

<button id="ajaxer" type="button">click me...</button>

e

<script type="text/javascript">

// since #ajaxer is also delivered via ajax, I bind events to document 
//  -> not the best practice but it's not the point....

$(document).on('click', '#ajaxer', function(ev) {
var $elem = $(this);
ev.preventDefault();

});

Il motivo per cui il mio capo (e altri) non vogliono usare questo approccio è che Event-Inspection in FireBug (o Chrome Dev Tools) non è più semplice, ad es. Con

<input type="text" name="somename" id="someid" onchange="performChange()">

può immediatamente vedere quale funzione viene eseguita su change-event e saltare direttamente ad essa in un enorme file JS pieno di spaghetti-code .

Nel caso di JavaScript discreto l'unica cosa che vedrebbe è:

<input type="text" name="somename" id="someid" />

e non ha idea se alcuni eventi, se presenti, fossero legati a questo elemento e quale funzione verrà attivata.

Stavo cercando una soluzione e l'ho trovata:

$(document).data('events') // or .. $(document).data('events').click

ma, questo "approccio" ha richiesto che impiegasse "troppo tempo ..." per scoprire quale funzione si attiva su quale evento, quindi mi è stato detto di smettere di associare eventi del genere.

Ti sto chiedendo alcuni esempi o forti vantaggi o qualsiasi altro tipo di suggerimenti per "Perché dovremmo usare UJS"

AGGIORNAMENTO: il suggerimento di "cambiare lavoro" non è una soluzione ideale.

AGGIORNAMENTO 2: Ok, non ho solo suggerito di usare l'associazione eventi jQuery, ma l' ho fatto . Dopo aver scritto tutte le delegazioni degli eventi, il capo è venuto da me e mi ha chiesto, perché sto facendo una delegazione di eventi con approccio e approccio diversi che non conosce

Ho citato alcuni ovvi benefici, come - Ci sono 15 campi di input e tutti hanno un onchangeevento (non solo, alcuni hanno anche onkeyup) Quindi è più pragmatico scrivere questo tipo di delega di eventi per TUTTI i campi di input, invece di farlo 15 volte, specialmente se tutto l'HTML sarà reso con l'eco di PHP ->echo '... <input type="text" id="someid" ... />...'

1. Smetti di usare parole d'ordine e prova invece a fare argomenti forti. Anche la pagina di Wikipedia per JavaScript discreto afferma che il termine non è definito formalmente. Potrebbe essere un termine generale per una serie di buone idee, ma se sembra una mera moda o moda il tuo capo e colleghi non presteranno molta attenzione. Peggio ancora, se continui a parlare di qualcosa che considerano inutile, potrebbero iniziare a scartare idee completamente indipendenti che tu sostenga.

2. Capire perché si pensa che le idee JavaScript discreto sono importanti. È perché hai letto che sono considerate le migliori pratiche? Hai riscontrato problemi che puoi attribuire a non seguire queste idee? Quanto avrà l'adozione di queste idee sui profitti dell'azienda?

3. Entra nella testa del tuo capo. Perché fa le cose come fa e perché ha rifiutato le tue modifiche? Probabilmente non è stupido, ed è probabilmente più esperto di te, quindi probabilmente ha delle buone ragioni per fare le cose a modo suo. Hai già accennato ad alcuni di essi: segui quel thread fino alla fine. Quindi scopri se e come i tuoi suggerimenti miglioreranno le cose di cui lui è più preoccupato.

4. Suggerimento 1: ai manager piace il denaro. Più direttamente puoi associare i tuoi suggerimenti a un aumento del reddito o alla riduzione della spesa, maggiore sarà l'impatto della tua discussione. Suggerimento 2: il tempo è denaro. Suggerimento 3: Di per sé, il fascino estetico del codice non fa soldi. Al contrario, in effetti - ci vuole tempo per far sembrare bello il codice. Il brutto codice che funziona bene va bene con la maggior parte dei manager.

5. Non limitarti a parlarne, fallo . Se sei abbastanza fortunato da avere un piccolo progetto autonomo sulla tua strada, chiedi al tuo manager se puoi farlo usando lo stile "UJS" come una sorta di dimostrazione. Quando sei pronto, tieni una revisione del codice in cui puoi spiegare come funziona tutto e perché pensi che sia migliore dello stile attuale.

6. L'idealismo è fantastico, ma non lasciarlo intralciare. È più importante essere visto come qualcuno che fa le cose piuttosto che come dilettante che si lamenta dello stile di codifica non vero. Questo è particolarmente vero se sei il nuovo ragazzo. Se non riesci a ottenere la trazione con UJS ora, fai un buon lavoro e costruisci lentamente un caso per le modifiche che desideri apportare man mano che acquisisci credibilità.

7. Leggi interruttore: come cambiare le cose quando il cambiamento è difficile . Ti darà molte più buone idee su come costruire il tuo caso in modo efficace.

Quello che puoi fare è fornire loro una demo del debug di un html USJ usando gli strumenti FireQuery e Chrome Query .

FireQuery è un'estensione firebug e fa un ottimo lavoro. Per quanto riguarda Chrome Query, non posso garantire quanto sia buono, ma è sicuramente utilizzato da alcuni degli sviluppatori ( un post su StackOverflow ).

Sappi anche che la .datafunzione viene rimossa per restituire i dati degli eventi interni da jQuery 1.8.0 e sostituita con la $._data(element, "events")quale può essere instabile, come da log delle modifiche ufficiale

Questo è stato rimosso in 1.8, ma è ancora possibile accedere ai dati degli eventi a scopo di debug tramite $ ._ dati (elemento, "eventi"). Si noti che questa non è un'interfaccia pubblica supportata; le strutture dati effettive potrebbero cambiare in modo incompatibile da una versione all'altra.

AGGIORNAMENTO:
Quando ho iniziato a lavorare ho avuto lo stesso dilemma. Ma al momento della creazione di una demo con GUI completamente funzionale (applicazione a pagina singola) che includeva schede ad apertura dinamica (anche chiudibili), menu Fisarmonica (creato dinamicamente da db), hanno finalmente capito che è meglio usare USJ fino in fondo.

Inoltre il vantaggio dell'uso di USJ è che puoi minimizzare l'intera applicazione in un piccolo script (illeggibile). Mostra anche loro gli script per google.com / github.com (come esempio) e fai notare che anche loro hanno il codice compresso, il che è sempre meglio, poiché lo spettatore del sito avrà difficoltà a decodificare i difetti di sicurezza e utilizzali per iniziare un attacco a tutti gli effetti sul tuo sito (spaventali), anche se improbabile.

AGGIORNAMENTO 2 : A
proposito, non sapevo che stavo facendo USJ fino a quando non ho visto questa domanda, quindi grazie in un modo.

I gestori di eventi inline puzzano perché:

• Nessuna delega di eventi, il che è fantastico quando vuoi essere in grado di rippare elementi dinamicamente dentro e fuori una pagina senza dover ricollegare.

• Hai associato il comportamento ai tag HTML anziché agli attributi di classe / ID dei tag HTML. Supponiamo che tu abbia una classe di "combo_box" in tutta la tua app. Improvvisamente, su metà delle tue vecchie pagine, vuoi una leggera variazione sulle caselle combinate quando si trovano in un contenitore diverso. Legato a una classe, puoi modificare quel comportamento in base al contesto del contenitore, ad es "#special_container .combo_box". Rilegato all'interno del dannato codice HTML, potresti ritrovarti a rintracciare ogni piccola casella di selezione con una classe .combo_box in qualsiasi numero di pagine per modificare i riferimenti di un gestore uno per uno anziché modificare o scrivere un paio di nuove righe di codice per filtrare da una singola posizione del file .

• Se si desidera più gestori, è necessario includerli in una funzione, quindi collegarli inutilmente a file HTML specifici. Quanto è sostenibile?

• Un punto più sottile è che è molto più facile / più gestibile / flessibile e robusto per gestire il comportamento con più di una mentalità del pannello di controllo. Legando da una posizione centrale, hai un posto in cui puoi ottenere una panoramica di tutti i comportamenti che si verificano sulla pagina allo stesso tempo, il che è utile quando, ad esempio, devi capire perché alcune pagine vengono eseguite occasionalmente in un certo bug difficile da capire ma non in altri.

• Questo è il lato client. Abbiamo più browser che interpretano tutti una grande complessità nei loro modi di rendere conto. Slop-it-all-together e lascia che l'IDE lo risolva per te le mentalità non funzionano bene qui. Mantenere il codice stretto, minimo, accoppiato liberamente e pulito non è alla moda, è assolutamente essenziale per stabilire un front-end mantenibile che sia facile da modificare e aggiornare e sì, è qui che arrivano i $$$ assumendo che il tuo manager abbia effettivamente lungimiranza .

• Non è più! @ # $ Ing 2002. Questo argomento è vecchio quanto le tabelle come il layout. Superalo e inizia a fidarti di uno sviluppatore specializzato sul lato client che tu stesso hai assunto espressamente perché mancava la loro competenza (non che io stia canalizzando qualsiasi rabbia dall'esperienza personale o altro).

E per confutare l'argomento del tuo capo, non è davvero così difficile rintracciare quale classe o ID viene utilizzato nella delega di eventi o nell'associazione di gestori con CTRL + F e uno strumento che ti consente di visualizzare tutti i JS sulla pagina come il mio personale jabery imbarazzante / Versione solo per il prototipo di bookmarklet Mi sono affrettato a mettermi insieme quando la barra degli strumenti di sviluppo web ha iniziato a saltar fuori su di me (maledetto codice colore). Aggiungi il segnalibro dal link nella pagina di violino js o copia il JS e creane uno tuo.

Un collegamento per violino JS che presumibilmente scadrà alla fine

Un grande vantaggio della tua tecnica suggerita è che devi associare una volta che il gestore eventi a un genitore come "documento" e questo gestore sarà in grado di catturare gli eventi provenienti da tutti i bambini che hanno soddisfatto il selettore dato come "button.anyclass ". Salva memoria e gestibile in modo tale da richiedere solo un'istanza di modifica e influisce su tutti gli elementi.

Per quanto riguarda il fatto di non essere in grado di riconoscere immediatamente la funzione associata, il tuo team potrebbe semplicemente standardizzare un modo per dichiarare tali funzioni probabilmente nella parte inferiore della pagina. Quindi tutti sapete dove guardare, anche la convenzione di denominazione è molto importante: i commenti sarebbero estremamente utili, ma assicuratevi che venga rimosso dal server prima di servirlo come risposta al browser.

Inoltre, se vuoi fornire offuscamento e minimizzazione di javascript per motivi di sicurezza, la tua tecnica lo renderebbe possibile, a differenza del vecchio stile che il tuo team sta ancora usando.

La risposta ovvia è che puoi associare una sola funzione al tuo pulsante con l'attributo onclick, mentre l'evento JQuery ti consente di associare più funzioni. Un problema comune con l'evento onload: se il documento è composto da più di un file, spesso si verificano collisioni.

Un'altra soluzione che potrebbe satsificare sia te che il tuo capo è l'uso dell'associazione dei dati, con una libreria come Knockout o Angular, che terrebbe traccia delle modifiche sulla vostra vista e sopprime la necessità di gran parte dei gestori di eventi.