Visualizza i risultati del sondaggio: javascript non intrusivo estremo o moderato?

Chi ha votato
0. Non puoi votare questo sondaggio
  • estremo

    0 0%
  • moderato

    0 0%
Visualizzazione dei risultati da 1 a 9 su 9
  1. #1

    Javascript non intrusivo...facciamo il punto!

    Noto con un po di perplessità che la mania di seguire le mode coinvolge anche e soprattutto il mondo del web con la non trascurabile conseguenza della nascita di vere e proprie "sette" fondate sull'enfatizzazione di un concetto.
    Ora io posso anche comprendere la corsa dei novizi a diventare adepti della setta di tendenza (tutti a fare richieste asincrone... :master: ) ma sinceramente non approvo le crociate per imporre il proprio culto e/o discriminare quello altrui.

    Prendiamo ad esempio la definizione di javascript non intrusivo: usando una metafora politica,abbiamo un'ala estremista e una moderata,col risultato che, proprio come in politica,si è creata un po di confusione IMHO;

    L'ala estremista sostiene che javascript deve comparire solo in un modo:
    <script type="text/javascript" src="url_script.js"></script>
    PUNTO!STOP!
    Niente eventi inline,niente document.write(),niente codice tra <body> e </body>,niente di niente! Tutto quello che riguarda javascript deve essere eseguito con window.onload...e basta!
    Penso che per questi signori il significato di intrusività non riguardi solo i concetti di degradabilità,accessibilità,usabilità ma anche IL MARKUP del documento (x)html.
    Ora la mia domanda è: ma non staremo un po esagerando?


    Io francamente mi schiero con l'ala moderata,cioè preferisco illustrare l'idea di javascript non intrusivo con una frase molto semplice: "se io faccio un sito chiunque deve poter accedere a suoi contenuti anche se non ha javascript o lo ha disabilitato",il che non significa necessariamente la drasticità di cui sopra.

    E voi,da che parte vi schierate?

  2. #2
    Moderatore di JavaScript L'avatar di br1
    Registrato dal
    Jul 1999
    Messaggi
    19,998
    Ok alla raccolta di pareri, punti di vista, osservazioni, che puo' essere utile per farsi un'idea di cio' che ne pensano gli altri, un sondaggio non ci sta: a chi potrebbe essere utile sapere che i moderati vincono (perdono) per 100 a 99 senza conoscere le ragioni?

    ciao
    Il guaio per i poveri computers e' che sono gli uomini a comandarli.

    Attenzione ai titoli delle discussioni: (ri)leggete il regolamento
    Consultate la discussione in rilievo: script / discussioni utili
    Usate la funzione di Ricerca del Forum

  3. #3
    il sondaggio in realtà è una specie di "ballottaggio" inserito nel contesto della metafora politica quindi l'inutilità intrinseca ne è la diretta conseguenza ;
    scherzi a parte mi aspetto che chi risponde motivi la sua scelta, anche se comunque una bozza dei "programmi elettorali" l'ho già scritta io.

  4. #4
    Utente di HTML.it
    Registrato dal
    Jun 2007
    Messaggi
    4
    Ciao,
    mi interessa molto questo argomento perchè è parte della mia tesi di laurea. Io sono un "estremista", ritengo il codice Javascript come un terzo livello dei siti web (azione che si aggiunge a struttura html e presentazione css) che deve agire dall'esterno secondo la regola: cerca l'elemento tramite metodi DOM e applica comportamento con JavaScript.

    Applicando questa separazione si otterebbero gli stessi benefici che si sono ottenuti introducendo i css (ricordate come si applicava lo stile prima?). Per esempio se volessimo applicare lo stesso gestore di un evento a più elementi dell'html potremmo farlo con una sola assegnazione senza doverlo ripetere ogni volta...ma potrei fare molti altri esempi.
    Ciao a tutti.
    Ste

  5. #5
    Ciao kurto80 in linea di massima potrei anche essere daccordo con te, ma per agevolare questa separazione i browser dovrebbero includere delle API SAX per serializzare la costruzione dell'albero del DOM ed esporre degli eventi sullo status di ogni nodo.
    Invece con il parsing attuale dei documenti html ,se hai degli script complessi trovo piu efficente un binding asincrono con codice inline piuttosto che attendere il fatidico window.onload per unificare la partenza di tutti gli script.

  6. #6
    Utente di HTML.it
    Registrato dal
    Jun 2007
    Messaggi
    4
    hai pienamente ragione, per me, l'uso di window.onload è solo un modo semplificato di risolvere il problema, ma dal mio punto di vista è la cosa migliore per ora visto che d'altro lato ha alcuni vantaggi importanti per gli sviluppatori. Sarebbe interessante analizzare le possibilità di SAX, che non conosco molto, o se esisto altre possibilità.
    Kurto

  7. #7
    Frontend samurai L'avatar di fcaldera
    Registrato dal
    Feb 2003
    Messaggi
    12,924
    onestamente non capisco come puoi definire i due concetti che hai esposto come una contrapposizione tra uso estremista e uso moderato del concetto di non intrusività.

    Il fatto di avere una pagina funzionante anche senza javascript è, dal mio personale punto di vista, un elemento cardine nello sviluppo delle pagine.

    Il fatto di non scrivere codice js dentro una pagina (x)html non ha nulla a che vedere con l'estremismo, ma è una semplice e pulita separazione tra azione e descrizione del contenuto che ha, tra i suoi scopi, quello di avere pagine più manutenibili.
    Vuoi aiutare la riforestazione responsabile?

    Iscriviti a Ecologi e inizia a rimuovere la tua impronta ecologica (30 alberi extra usando il referral)

  8. #8
    Originariamente inviato da fcaldera
    onestamente non capisco come puoi definire i due concetti che hai esposto come una contrapposizione tra uso estremista e uso moderato del concetto di non intrusività.

    Il fatto di avere una pagina funzionante anche senza javascript è, dal mio personale punto di vista, un elemento cardine nello sviluppo delle pagine.

    Il fatto di non scrivere codice js dentro una pagina (x)html non ha nulla a che vedere con l'estremismo, ma è una semplice e pulita separazione tra azione e descrizione del contenuto che ha, tra i suoi scopi, quello di avere pagine più manutenibili.
    Non sono io che faccio questa contrapposizione,bensi molti "puristi" che disseminano per il web post e tutorial in cui identificano nella "pulizia" del markup html un requisito accessorio per la non intrusività del codice js,in tal senso l'attributo estremista va inteso come classificazione estemporanea;d'altronde quando ho titolato "facciamo il punto" ed ho usato il termine "confusione" non l'ho fatto a caso.

    Per il discorso della manutenzione delle pagine,anche qui potremmo dibattere con argomentazioni analoghe: infatti secondo me l'applicazione di un design pattern cosi radicato per ottenere un markup "js-less" rappresenta di più un esercizo di stile il cui fine ultimo è l'autocompiacimento piuttosto che la consapevolezza di aver apportato reali migliorie in merito alla complessità di gestione.

    In altri termini,una pagina puo essere degradabile e manutentibile anche da "moderati". Il tutto ovviamente IMHO.

  9. #9
    Preferisco l'approccio "estremista" visto che rende il codice molto più pulito e semplice da gestire; non ci vedo ragioni per usare eventi inline, apparte quello di doversi sbrigare perchè si ha un cliente alle calcagna

    Comunque, generalizzando il discorso, condivido l'opinione che spesso le mode siano troppo influenti se non insensate... ad esempio si parla di accessibilità quando a saperne davvero qualcosa sono pochi; oppure si creano librerie non intrusive che usano un namespace per poi mandare tutto all'aria con l'uso di funzioni che iniziano per $, praticamente utilizzate da tutti.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.