JavaScript invadente è mai ok?


9

Stavo pensando che se tutti gli utenti di un sito Web devono avere JavaScript abilitato, è ok usare JavaScript invadente?

Sono tutto per il miglioramento progressivo, ma qual è il punto in cui un'applicazione Web avanzata rimbalza gli utenti alla porta se hanno un vecchio browser o JavaScript disabilitato?

Abbiamo un pubblico di destinazione molto ridotto e possiamo dire al nostro pubblico di destinazione quale browser e plug-in / funzionalità devono avere. Quindi la mia domanda è: mescolare JS e HTML va bene in quel caso? Come usare gli attributi onclick.


1
"Se tutti gli utenti di un sito Web devono avere JavaScript abilitato ... se hanno ... JavaScript disabilitato?" <- Questa è una contraddizione e non sono sicuro di come dare una risposta utile irrisolta.
HedgeMage,

3
Tieni presente che, a seconda del tuo pubblico di destinazione e del mercato, potrebbero esserci leggi sull'accessibilità che richiedono che i tuoi siti Web siano accessibili a tutti gli utenti, inclusi i disabili. Cosa significhi in pratica per JS non lo so. AFAIK (IINAL) dove sono io abbiamo tali leggi ma non ci sono ancora casi di prova per elaborare i dettagli.
James,

16
Cosa intendi con JavaScript "invadente"? Non ho familiarità con il termine.
Macke,

2
Quindi la tua domanda in sostanza è: scrivere codice scadente è mai ok? Sì, per prototipi e progetti sufficientemente piccoli e che non richiedono manutenzione / aggiornamenti una volta terminati. Altrimenti ti affronterai solo sei mesi dopo, perché ti ci vuole un'ora per capire cosa sarebbe stato plausibile se avessi investito qualche secondo in più quando l'hai messo in atto.
back2dos

3
Ho pensato che questa domanda avrebbe posto se fosse finita per ridimensionare la finestra del browser di qualcuno o avere tonnellate di popup.
whatsisname

Risposte:


17

Questa è una decisione aziendale piuttosto che una decisione di progettazione.

C'è un costo per fornire una versione del sito Web che funziona senza JavaScript (o Flash o Silverlight). L' azienda deve decidere se valga la pena la perdita di entrate / visitatori.

Quindi, se costa $ 10.000 scrivere questa versione (il numero potrebbe essere piuttosto ampio, ma è lì solo per questo esempio), il business recupererà tale esborso nel corso della vita del sito? In caso contrario, non fornire quella versione.

Tuttavia, se scrivere questa versione costa solo $ 100, sarebbe logico fornire un grazioso degrado.

Dopo aver preso la decisione aziendale di scegliere come target solo i browser abilitati per JavaScript e aspettarsi che i tuoi utenti dispongano di JavaScript abilitato, è perfettamente logico che la tua applicazione sfrutti le funzionalità ora disponibili. L'unica cosa che dovrai fare è (come fa Stack Overflow stesso) è mettere in guardia che il sito non funzionerà correttamente se l'utente non lo ha abilitato.


2
Penso che tu mi fraintenda.
Petah,

5
Dovresti gentilmente dirci che WTF "invadente JS" significa evitare l'incomprensione. Ti è già stato chiesto di farlo (votato 7 volte)!
maaartinus,

1
In passato ho creato pagine degradanti con grazia e ho riscontrato che html e javascript sono molto meno trasparenti, se vuoi comunque offrire ai visitatori abilitati a JS la migliore esperienza utente. Le pagine sono state MOLTO più difficili da costruire e credo che il ragazzo che mantiene la pagina avrà delle difficoltà nel seguire il tuo codice. Quindi c'è sicuramente un costo di manutenibilità a lungo termine da tenere presente quando si stima il costo per rendere il tuo sito elegantemente degradante. Ho trovato molto allettante scendere a compromessi sulla UX abilitata per JS ..
Thomas Stock

1
@maaartinus, javascript invadente è l'opposto di javascript discreto en.wikipedia.org/wiki/Unobtrusive_JavaScript
Petah,

1
OK, quindi posso solo dire ... html + js è una piaga (implementazioni rotte che ignorano strani standard) e minimizzerei lo sforzo proprio come ha scritto Thomas Stock. Cerca di farlo funzionare perfettamente nel browser scelto (e non scegliere IE6: D) a e di essere sopportabile negli altri. Invece di risolvere tutti i problemi, dedica il tuo tempo alla funzionalità.
maaartinus,

20

Qualcosa che nessun altro ha ancora sollevato ...

Il 99% dei siti Web accoglie un visitatore in particolare, uno con poco o nessun JavaScript. Quel visitatore ha un nome: Googlebot .

Un grande motivo per cui a tutti dovrebbe interessare anche i visitatori non vedenti ...

Se sei uno dei pochissimi a cui non interessa affatto il traffico dei motori di ricerca, beh, questa è la tua prerogativa, ma certamente non costituisce una regola generale.


4
Infatti. Abbiamo migliorato uno dei nostri siti per renderlo più accessibile ai non vedenti e come conseguenza (non intenzionale) il traffico ottenuto da Google si è moltiplicato per quasi un fattore 10 in un anno.
Kris

1
Sì, ma il sito web non è per il pubblico. Quindi le classifiche di ricerca non si applicano.
Petah,

3
@Petah: Hai considerato di indicare chiaramente e in modo sintetico quali sono i tuoi requisiti, le situazioni e le restrizioni precise nella domanda piuttosto che peppare piccoli frammenti di informazioni qua e là nei commenti?
SOLO IL MIO OPINIONE corretta,

1
Non hai più ragione. Da un po 'di tempo, Googlebot esegue bene javascript (nessuna sorpresa, dato che Google funziona sia sul motore V8 che su angularjs).
maaartinus,

8

Le persone che scrivono cose per specifici ambienti interni sono un grande motivo per cui IE6 è ancora in circolazione.

Pensaci


4

Se stai facendo un sito solo per JS (forse "applicazione" in questo caso è una parola migliore) la cosiddetta "discrezione" di JS non importa tanto come nel caso, quando devi degradare con grazia a non- Versione JS.

Tuttavia: JavaScript scritto in modo discreto è generalmente più facile da scrivere (e almeno lo trovo così) e da mantenere. È più semplice introdurre modifiche al layout HTML che non interrompono JS e modifiche a JS senza preoccuparsi di interrompere l'HTML.


4

Se stai costruendo un sito web, manterrei JavaScript discreto. Tuttavia, se stai creando una forma di applicazione (come Google Docs), JavaScript sarà piuttosto invadente.

JavaScript e HTML5 sono ottimi per la creazione di applicazioni se è necessario, ma è davvero una scelta aziendale.


Sì, è più simile ai documenti di Google che a un sito Web. E usiamo pesantemente HTML5.
Petah,

Correggimi se sbaglio, ma penso che puoi ancora utilizzare la maggior parte dei concetti in JavaScript discreto senza creare necessariamente un pasticcio nel codice? Questo è il concetto che si distingue e fa più rumore per me. Forse ti riferisci ad alcuni altri aspetti di JavaScript discreto che dovresti evitare utilizzando HTML5, come la retrocompatibilità con utenti non JavaScript? Devi scegliere ciò che è meglio per te e il progetto, purché tu possa giustificare in modo intelligente le ragioni e analizzare il rischio, quindi penso che sia tutto a posto :) +1
jmort253

Quello di cui sto parlando è come funzionerà il sito se Javascript è disattivato. Ci sono alcune volte in cui sarà completamente funzionale (se non forse altrettanto piacevole) e altre in cui fallirà completamente. Non sono preoccupato per i vecchi browser che non supportano JavaScript (Netscape 1). Naturalmente in ogni caso non c'è motivo di scrivere BAD javascript
Zachary K

2

La maggior parte degli utenti (i miei utenti, non conosco i tuoi utenti) hanno JavaScript disponibile e abilitato. Diamo a quegli utenti una grande esperienza utente. Tuttavia, devi comunque fornire una versione del tuo sito che funzioni senza Javascript. So che creare 2 versioni è una seccatura, ma è così che va nello sviluppo web. (In realtà potresti dover creare più versioni, una terza potrebbe essere una versione mobile del tuo sito).

Quello che non vuoi fare è progettare per il minimo comune denominatore: "Bene, ci sono alcuni utenti che hanno Javascript disabilitato, quindi progetteremo il nostro sito affinché funzioni bene per loro - niente Javascript, colpisci il server per tutto ". Questo penalizza solo la maggior parte dei tuoi utenti che hanno Javascript.


Quello che sto dicendo è che nessuno degli utenti ha JavaScript disabilitato. In tal caso, non possono accedere al sito.
Petah,

@Petah, beh, neanche questo è fantastico. Non vuoi far rimbalzare gli utenti senza Javascript. Quindi è quello che mi stai chiedendo, dato che sto eliminando gli utenti senza Javascript, posso inserire JS nello stesso file con il mio HTML?
Marcie,

Abbiamo un pubblico di destinazione molto ridotto e possiamo dire al nostro pubblico di destinazione quale browser e plug-in / funzionalità devono avere. Quindi la mia domanda è, mescolando bene JS e HTML in quel caso. Come usare gli attributi onclick.
Petah,

4
@Petah, ci sono altri motivi per evitare di mescolare JS e HTML. Sono gli stessi motivi per cui evitiamo di mescolare stili e HTML - separazione delle preoccupazioni. Se il tuo stile è mescolato con la tua struttura, che è mescolata con il tuo comportamento, hai qualcosa di molto difficile da mantenere. Dopo averlo fatto nel modo "discreto" per un po ', vedrai quanto sono eleganti i tuoi file e quanto è più semplice apportare modifiche.
Marcie,

2
@Petah, hai un enorme file JS per tutto il tuo sito e tutto va bene? Ho circa un file JS per pagina, e per me funziona bene. Roba veramente "comune" è tutto ciò che va nel file JS condiviso.
Marcie,

2

Hai menzionato usando gli attributi onlick. Stai pensando di utilizzare un gestore di eventi JavaScript per la navigazione della pagina?

Lo sconsiglio per un solo motivo: interrompe il clic centrale .

Per un normale clic sui collegamenti, supponendo che JavaScript sia abilitato, questi saranno funzionalmente equivalenti:

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

Se provi a fare clic centrale nel primo esempio, otterrai una pagina vuota anziché myPage.htm.

A parte questo esempio, penso che sia ok usare JavaScript invadente se ha senso per te. Ci vuole meno tempo per scrivere (ma non necessariamente mantenere) JavaScript incorporato, e la perdita di miglioramenti progressivi potrebbe non essere importante nella tua situazione.


In questo caso non è per la navigazione, ma per pulsanti come "Aggiorna", "Elimina", "Crea", ecc.
Petah

In tal caso, suggerirei che è stile personale. Trovo il metodo invadente più rapido / più semplice per iniziare, ma il modo "corretto" di essere più pulito e più facile da mantenere. C'è sicuramente un fattore confuso nel fare la cosa giusta.
GavinH,

+1: è più semplice mantenere pulito il codice dall'inizio se non è invadente. Trovo che se divento troppo disordinato all'inizio, può essere troppo difficile provare a risolvere i problemi in seguito. Mi sento sopraffatto. Preferisco fare il miglior lavoro possibile in modo che quando torno, non è poi così male fare il refactoring.
jmort253,

2

JavaScript invadente andava bene 10 anni fa. Va bene anche se sei un dilettante, o se stai costruendo un prototipo usa e getta, o se ci sono delle circostanze che lo rendono necessario, come la dipendenza dal codice legacy o dal codice basato sui dati e sarebbe semplicemente un modo economico troppo per sistemare al

Se stai costruendo qualcosa da zero, segui gli standard, scrivi un codice buono, pulito e gestibile. Scrivi qualcosa di cui sarai orgoglioso e che non ti farà star male tra un anno da quando un povero schmuck ti chiede aiuto perché non capiscono un hackjob che hai fatto. Scrivi qualcosa che assicuri che i tuoi web designer possano facilmente scambiare CSS senza dover scavare tra disordinati HTML e JavaScript.

Costruisci l'applicazione in modo che abbia spazio per crescere, in modo che qualsiasi sviluppatore possa entrare e mantenerla. Il tempo investito ora farà risparmiare tempo in futuro, se non il tuo tempo, quello di qualcun altro.

Assicurarsi che JavaScript possa essere riutilizzato in un altro contesto. Assicurati che una riprogettazione completa del sito web possa essere proprio questa, una riprogettazione, e non una ricostruzione completa di qualcosa che esiste già ma che non è stato costruito duramente.

Immagina quanto sarebbe imbarazzante dover dedicare la stessa quantità di tempo a una riprogettazione rispetto alla costruzione originale.

Fidati dell'esperienza, JavaScript discreto ti impedirà di commettere errori costosi.


2

D'accordo, chiamami custode della cripta per tutto il necro che faccio, ma non ho mai sentito che il vero valore di questo sia stato compreso correttamente. Storicamente, è stato affermato che "JavaScript discreto" o, mantenendo il tuo JS fuori dall'HTML tramite gli attributi del gestore di eventi HTML in linea e i tag di script che non si collegavano a un file il più possibile è un elemento chiave enorme di:

  • Problemi di accessibilità
  • SEO
  • E miglioramento progressivo

BUGIE! (beh, ora lo sarebbero)

La verità della questione è che potresti fare JavaScript tecnicamente invadente e comunque tirare fuori i tre elementi precedenti. A meno che tu non stia creando dinamicamente contenuti HTML, il che è stato un grande no-no SEO nel corso della giornata.

Ma fermati e pensa ... a te!

In realtà, il grande vantaggio, la vittoria maggiore e più sottovalutata del mantenimento della separazione è sempre stato il vantaggio diretto che lo sviluppatore ne ricava. Puoi avere tutti i gestori di eventi che desideri sullo stesso elemento html per lo stesso evento che è conveniente. Ciò significa che se un tag con class="some_class"ottiene sempre un determinato comportamento ma ottiene anche un comportamento bonus quando si trova all'interno di un id="bonus_behavior"div, non dobbiamo iniziare a scherzare con la logica all'interno del nostro gestore di eventi con un permesso per ramificarlo. Possiamo semplicemente aggiungere o non aggiungere gestori a seconda del contesto.

Facile da leggere anche

Un altro vantaggio è la leggibilità. Questa era una preoccupazione più critica quando gli strumenti del browser consistevano nel messaggio di errore esclusivo di IE che ti diceva che c'era qualcosa di sbagliato [object]ma IMO, è ancora un grosso problema. CSS qui, JS lì e HTML è il luogo in cui si incontrano sia loro che il server. Con tutte queste cose che si uniscono in un unico posto, ha senso fare affidamento sugli hook (ID, classi e gerarchia) per creare un livello di astrazione che ogni cosa utilizza per connettersi all'HTML.

IMO, più PUOI separare HTML, CSS e JS, più è facile non solo leggere ma anche modificare e capire cosa sta succedendo. Vedo un div vuoto con "dynamic_combo_box" come classe e ho una buona idea che qualcosa stia facendo una selezione elaborata che carica i dati in modo dinamico. Ho un indizio su come trovarlo in JS e CSS e se mi imbatto nella classe in quelle preoccupazioni, avrò una buona idea di cosa si tratta e come trovarlo nell'HTML.

Troppo facile da rendere ancora più sloppier

E naturalmente la leggibilità tende ad andare di pari passo con la manutenibilità. Quando fai semplicemente le cose scaricando tutto nei tag di script in cui si trova l'HTML pertinente, il più delle volte diventa più facile per le persone semplicemente tagliare e incollare quello script nell'HTML di un'altra pagina su cui stanno lavorando quando vogliono funzionalità simili, il che significa che ora hai una cosa che molto probabilmente alla fine diventerà due cose fastidiosamente simili ma non uguali al 100% il cui comportamento può diventare problematico nel tempo sfidando le aspettative e richiede l'aggiunta di ramificazioni più inutili per gestire le eccezioni di cui hai bisogno un altro no.

Pertanto, il comportamento di rigging di questi hook HTML incoraggia il riutilizzo del codice in modo intelligente. Se hai bisogno di ramificare il comportamento per un'implementazione alternativa, vai semplicemente alla stessa funzione e gestiscila lì con gerarchia HTML o forse un att-data che innesca un comportamento alternativo. È uno stop-shopping per chiunque voglia capire come funzionano gli elementi dell'interfaccia utente di un certo tipo e quei tipi di taglia e incolla spregevolmente pigri in un modo cattivo faranno la cosa giusta / più gestibile solo perché è la cosa più semplice da fallo ora ed è il modo migliore per far sì che la manutenibilità avvenga. Rendi la cosa più semplice da fare anche per qualcuno a cui non potrebbe importare di meno se per panico o apatia.

Ma per quanto riguarda il 2014?

Potrebbe essere un punto legittimo che nelle moderne applicazioni a pagina singola, alcune di queste cose pignole forse non dovrebbero essere confuse come dogmaticamente come sono state ma credetemi quando dico che non penso di essere l'unico che è stato venduto perché alla fine semplifica il lavoro. Sono pigro in un modo (spero) per lo più buono. Mi piace quando devo solo cambiare le cose in un posto per ottenere cambiamenti in tutta un'app, quando devo solo cercare in un posto per capire qual è il bug e quando faccio fatica a capire cosa diavolo è e come riutilizzare al meglio quel codice per fare qualcosa di molto simile.

È buono come dividere un DB o un livello dati è buono. Alla fine è un perché-non-ho-solo-fatto-quel risparmio di tempo come impiegare tutti e cinque i minuti a fare il bucato la sera prima piuttosto che spendere 10 minuti a far rabbrividire i tuoi pugili e condurre controlli paranoici sull'odore la mattina successiva.

Per me, sono quelle motivazioni egoistiche che sono sempre state il punto principale del motivo per cui mi aggrappo non solo alla JS discreta, ma alla separazione di stile / comportamento / contenuto il più possibile, anche se WHAT-freaking-WG fa del loro meglio confondere queste preoccupazioni in modi comprensibilmente fantastici e interessanti.

Ora che tutti stanno facendo SPA ed è quasi sciocco cercare di convincere gli affari che dovremmo preoccuparci delle persone che gestiscono senza JS (l'accessibilità può ora essere, presumibilmente, gestita con contenuti generati da JS), sembra che la prossima generazione di sviluppatori JS si preoccupi di meno su questo, ma IMO, c'è ancora una vittoria lì ed è principalmente per te, lo sviluppatore che scrive e mantiene queste cose. E davvero, quella vittoria avrebbe dovuto essere sempre il punto più sottolineato, ma non lo è mai stato per qualche motivo, perché alla fine avvantaggia te e il prodotto in caso di incidente felice grazie alla modifica / modifica / debug più facile.

Va mai bene?

Beh sì, immagino. In un'app usa e getta usa e getta per un concorso o qualcosa del genere. Ma lo farei comunque solo perché ne ho l'abitudine e in realtà non è più difficile da fare.


1

Se conosci il tuo ambiente operativo di destinazione Javascript e framework come jQuery possono essere una vera manna dal cielo. Ad esempio in un ambiente aziendale in cui SOE ha Javascript e IE8 rispetto alle sue applicazioni browser più lato client più che sicure.


1

Rendere più facile il grazioso degrado è solo uno dei tanti fattori che rendono JavaScript discreto una scelta attraente e, a mio avviso, non è il più importante.

Per esperienza personale, direi che se stai parlando di un progetto più grande, che probabilmente si evolverà molto nel tempo, l'uso di uno stile discreto renderà l'applicazione MOLTO più facile da mantenere, eseguire il debug e refactor. Questo è il motivo principale per cui utilizziamo sempre uno stile discreto, anche su siti che richiedono l'attivazione di JavaScript per tutti i visitatori.


+1 a Shang per questo gioiello "Rendere più semplice il grazioso degrado è solo uno dei tanti fattori che rendono JavaScript discreto una scelta attraente e, a mio avviso, non è il più importante." L'implementazione di Javascript a volte può essere
un'arma

1

In generale, se si sta sviluppando un "sito Web" tradizionale disponibile in modo anonimo, indicizzato dai motori di ricerca e in cui le entrate vengono generate dagli annunci, è necessario fornire un gradevole degrado. L'idea è che questo tipo di sito vive e muore a causa dell'accessibilità, limitando così l'accessibilità significa perdere un sacco di visualizzazioni di pagina e quindi entrate pubblicitarie.

Un "sito" (applicazione web) ad accesso limitato, generalmente non indicizzabile e non basato sulle entrate pubblicitarie, può essere molto più flessibile. Si tratta di una decisione tra ampiezza di supporto, profondità delle funzionalità e costi di sviluppo. Pensalo come sviluppare un'applicazione tradizionale: quale piattaforma supporti e quali sono le specifiche minime? Se scegli come target una sola piattaforma e specifiche limitate, puoi concentrarti sulla fornitura di un prodotto superiore con minori costi di sviluppo e supporto, a scapito della perdita di potenziali quote di mercato.

Esempio: Ricerca Google è un sito Web. Google Docs è un'applicazione web. La ricerca di Google è semplice e può funzionare in modo identico senza JavaScript, CSS e / o immagini, ecc ...: funziona nei browser in modalità testo così come negli ultimi browser GUI. Google Docs semplicemente non funziona con JavaScript disabilitato e non si degrada neppure con garbo, nemmeno un avvertimento per abilitare JavaScript.


1

Preferisco avere la maggior parte del layout e della navigazione gestiti nei CSS. Sì, Lynx potrebbe non supportarlo, ma tutti i browser con funzionalità complete di cui sono a conoscenza non possono disattivarlo. Quindi JavaScript può essere usato per cose più appariscenti ma non obbligatorie. Mi piace anche Ruby on Rails per questo scopo. Può fare molto di ciò che JavaScript sarebbe richiesto per il lato server purché non siano necessari aggiornamenti dinamici della pagina.

Più mirato alla risposta alla domanda: non mi piace JavaScript richiesto, ma esiste un caso aziendale in cui è richiesto, come notato da ChrisF.


0

Javascript è lo standard defecto quando si tratta di qualsiasi tipo di contenuto dinamico distribuito lato client, se non hanno JS probabilmente non avranno Silverlight.

Quindi devi pensare al tuo mercato / pubblico sei programmers.stackexchcange o bbc.co.uk/news? un pubblico molto diverso.


0

Dato che puoi guardarti attorno e vedere "JavaScript invadente" su molti siti, la tua domanda di base ha una risposta, sì, è ok, e molti siti popolari lo fanno, anche Google.

Più importante, tuttavia, è il grazioso degrado delle funzionalità, anche se insisti sul fatto che i tuoi utenti dovrebbero avere Javascript abilitato, devi fornire un livello decente di esperienza per gli utenti non js, altrimenti non torneranno mai volentieri.


Non saranno nemmeno ammessi oltre la prima pagina in primo luogo.
Petah,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.