Salvate il soldato View Source

Lunedì 11 Gennaio 2010 - 08:15

di Cesare Lamanna

Web Standards

In un’audio-intervista rilasciata a suo tempo da Tim Berners Lee e che è possibile ascoltare (o scaricare) su questa pagina, l’inventore del World Wide Web evidenziava, tra l’altro, la scelta consapevole di inserire tra le funzionalità di base del primo browser quella che consentiva di visualizzare il codice HTML della pagina. Lo scopo di quella scelta non sfugge a nessuno: guardare cosa c’era sotto il cofano è stato per molti, all’epoca, il modo più semplice per imparare a scrivere pagine web.

Ora, l’alba del nuovo decennio si apre proprio all’insegna di un sentito appello nella community degli sviluppatori web: salvare il View Source. L’amico fedele, l’alleato più prezioso di chiunque abbia messo mano alla produzione di codice per il web è in pericolo? Sembrerebbe di sì, almeno stando ai ragionamenti di Alex Russell (Dojo e Google) e altri intervenuti al dibattito.

Due, in sintesi, i potenziali killer individuati: la minificazione del codice (soprattutto Javascript, ma in parte anche CSS) in vista del miglioramento delle performance di caricamento delle pagine e le varie tecniche per l’offuscamento tendenti a tenere nascosto il codice per non fare vedere come abbiamo fatto quella cosa.

Le implicazioni e le sfumature del discorso sono tante, coinvolgono la natura stessa del web per come è stato concepito alle sue origini (una natura che a molti piace definire giustamente open), ma anche il valore che ha avuto e ha la visualizzazione del codice di un documento come strumento per l’apprendimento.

Insomma, va salvato o no il soldato View Source?

Tags:

Categoria: Web Standards | Permalink

Commenti

1

E’ probabile che le persone che oggi vogliono condannare a morte il view source nei loro dibattiti siano state le prime ad imparare parecchie cose “leggendo” il codice altrui e sviluppandolo di conseguenza.

Da sempre è così: si guarda il lavoro degli altri per migliorare il proprio e portare avanti nuove scoperte.

Credo basti per capire l’importanza del “view source”

# - postato da saibal - 11 Gennaio 2010 - 09:39

2

Verrebbe meno la condivisione ai fini di apprendimento ma anche di miglioramento del codice. Il mio voto è contrario!

# - postato da Nico - 11 Gennaio 2010 - 10:16

3

A parte i motivi scritti nel post, un ulteriore motivo per mantenere questa funzionalità potrebbe essere quello di un minimo di debug per gli sviluppatori.

# - postato da Mattia - 11 Gennaio 2010 - 11:57

4

assolutamente si salvi il ctrl+u,,
però mi sembra tutto un po’ una bufala…

dalla minificazione e dall’offuscamento non si può tornare indietro s e m p r e ?
mi sembra prorpio di sì…

allora per gli sviluppatori non salterà subito fuori un bell’ADDone per ff…

che tanto solo gli sviluppatori guardano il codice…

madicosastannoparlando?

# - postato da EsseZeta - 11 Gennaio 2010 - 12:05

5

Finchè i browser saranno aperti (e penso a FF) ci saranno sempre le estensioni come Firebug, che non mostrano il sorgente così come ci arriva dalla rete (Ctrl+U) ma come viene interpretato dal browser per generare la pagina. E in questo caso compressione e offuscamento sono inutili, no?

# - postato da Lorenzo S. - 11 Gennaio 2010 - 12:28

6

È da anni che si pone il problema del javascript offuscato, ne avevano già parlato Stallman e la FSF, ma non mi sembra che ci siano add-on deoffuscatori per Firefox.

Il problema c’è: anche le persone che non hanno nessuna intenzione di nascondere niente spesso usano compressori js per motivi di performance.

Immagino che chi ha intenzione di mostrare come ha ottenuto un certo effetto scriverà un post sul blog oppure pubblicherà a parte il javascript, css ecc. in formato leggibile.

Gli altri saranno un po’ l’analogo di quelli che scrivono software proprietario. Software proprietario e libero hanno sempre convissuto senza troppi problemi, e non vedo perché lo stesso non potrebbe accadere con i siti web.

# - postato da Andrea - 11 Gennaio 2010 - 12:34

7

Come al solito la gente propone cosa assurde… Anche i codici PHP possone essere emulati, quelli javascript possono essere copiati, è vero, ma se uno è in grado di usare javascript se li riadatta (e chi non è capace a usare javascript non se ne fa nulla di un codice copiato)

# - postato da Cristiano - 11 Gennaio 2010 - 12:48

8

@EsseZeta (commento 4): tu guardi al lato ‘pratico’ della faccenda e quello che dici è anche giusto, ma magari c’è pure in ballo una questione, come dire, di ‘principio’ :) Rendere il codice illeggibile e ‘inusabile’ con le pratiche di cui si parla nel post è cosa buona, giusta, utile, etc, ? Mi pare che il discorso sia tutto in questi termini. È immaginabile pensare a dei meccanismi per cui di fronte a un codice minificato e compresso ci sia la possibilità di attingere comunque ad una versione ‘normale’?

# - postato da Alex - 11 Gennaio 2010 - 13:07

9

Io sono dell’idea che la differenza fra chi vuole offuscare (non per le performance ma per timore di essere copiato) il codice e chi vuole lasciarlo disponibile è a livello di evoluzione.
Chi ha paura del codice aperto, di essere copiato etc è una persona piccola, timorosa ed insicura.
Personalmente io mi sento molto appagato quando qualcuno mi copia una routine o un blocco di codice perché significa che è utile.

# - postato da lordmax - 11 Gennaio 2010 - 13:52

10

esistono casi in cui il “view source” è già morto e da un pezzo, quando l’applicazione supera un certo grado di complessità quel approccio diventa totalmente inutile a capire come funziona, tantomeno a riprodurre e modificare, si fa molto prima a cercare un equivalente opensource realizzato con uno dei molti e ottimi framework opensource e leggere il relativo manuale e codice.
php e tutti i linguaggi lato server oltre a tutti i linguaggi tradizionali non espongono i sorgenti ma li si può imparare ugualmente cercando altrove.
è nella natura dell’evoluzione di html/css/js, html è stato pensato per essere un formato per lo scambio di articoli scientifici che gli scienziati potevano apprendere i 3/4 tag necessari al loro lavoro guardando il sorgente di altri documenti, oggi parliamo di applicazioni web sviluppate da team di professionisti…
e per chi ha la necessità di pubblicare autonomamente, cms e blogs hanno risolto il problema da un pezzo.

# - postato da devsmt - 11 Gennaio 2010 - 14:06

11

Per favore non confondiamo html/css/js con linguaggi lato server, sono due cose COMPLETAMENTE diverse…

# - postato da Alien - 12 Gennaio 2010 - 00:59

12

Le pagine generalmente sono fatte per gli utenti, non per gli apprendisti del web. Questo punto è fondamentale.

Un tempo le guide per imparare erano poche e il codice da scrutare era molto semplice e lineare.
Ora è esattamente il contrario, c’è materiale di studio a volontà che semplifica molto la vita degli apprendisti. Mentre il codice delle tecniche più “moderne” (Ajax, ecc.) è difficile da comprendere anche senza alcuna compressione. É più facile ed istruttivo studiare delle guide e degli esempi documentati anzichè perdere ore a cercare di capire il flusso del codice altrui.

# - postato da Claudio - 12 Gennaio 2010 - 04:26

13

La funzionalità per vedere il sorgente la uso ogni giorno su quasi ogni sito che vedo per analizzarne la qualità del codice o per vedere che ciofeca di cms hanno utilizzato.

Rimuovere questa funzionalità sarebbe comunque inutile: salvando la pagina web in locale verrebbe salvato il codice e buona parte dei file associati quali css js immagini ecc…

Inoltre chi sa programmare non utilizza il view source per copiare. Però in fase di testing dei siti è spesso fondamentale poter vedere il sorgente generato per capire dove ci sono errori.

In defnitiva mi sembra assurdo che si possa pensare di rimuovere questa funzionalità anche in fatto della mancata compatibilità di resa/funzionalità tra browser diversi.

# - postato da Paolo - 12 Gennaio 2010 - 07:54

14

Paolo, in verità non è che qualcuno ha pensato o proposto di rimuovere questa funzionalità. Il fatto è che certe pratiche (quelle indicate nel post e a cui si è fatto riferimento nei commenti) potrebbero renderla inutile. Una cosa è avere a che fare con codice ben strutturato e leggibile, altra è doversi districare in un JS compresso/minificato.

# - postato da SteF - 12 Gennaio 2010 - 12:55

Inserisci il tuo commento:





(puoi usare i seguenti tag HTML per formattare il testo -
a href, b, i, br/, p, strong, em, ul, ol, li, blockquote, pre):

 

Anteprima del commento