Regole per un javascript più efficiente

[Linusss]

Devo ottimizzare al massimo del codice javascript.

1) Il mio principale dubbio è se scrivere codice OOP lo rende più performante o ne peggiora la situazione(soprattutto nell'utilizzo di memoria).
Ad esempio:
OOP

function MyObject(dom){
      this.dom=dom;
      this.move=function(x,y){
         //code
      }
}

var a=new MyObject(div1);
a.move(4,5);

var b=new MyObject(div2);
b.move(40,50);

Con un approccio OOP risulta sensibilmente più pulito, ma in termini di efficienza?
Viene replicata la funzione per ogni oggetto, e così anche le variabili che si usano immagino...

Procedurale

function move(dom,x,y){
    //code
}

move(div1,4,5);
move(div2,40,50);

Qual'è da preferire?
Ovviamente sto parlando di grandi progetti.

2) Le variabili dichiarate(e non) all'interno di una funzione che ciclo di vita hanno?
Per ciclo di vita non intendo se le posso riutilizzare anche all'esterno ma se vengono distrutte dal garbagecollector a fine funzione, cioè se la memoria viene effettivamente rilasciata.
Esempio:

var y=0;
function test1(){
     var x=3;
     y+=x;
     return y;
}

function test2(){
     var x=3;
     y+=x;
     x=null;
     return y;
}

function test3(){
     x=3;
     y+=x;
     return y;
}

x viene distrutta al termine delle funzioni?
C'è differenza fra le 3 funzioni in termini di memoria utilizzata?


3) Quando devo creare dei cicli temporizzati(dove magari all'interno sposto un oggetto DOM) è meglio che utilizzo setInterval, o che creo una funzione ricorsiva con setTimeout?
setInterval è fatto apposta per i cicli, ma è una funzione "ottimizzata" bene?

4) Se devo creare elementi DOM sul momento, ai quali devo applicare regole CSS, è meglio che i css li applico direttamente con javascript, o che assegno un id all'oggetto il quale avrà le sue belle regolette in un foglio di stile?
C'è differenza per i browser in termini di velocità nel renderizzarlo e successivamente muoverlo/ridimensionarlo ecc ecc?

5) Ho notato che i browser(soprattutto firefox) fanno fatica nel gestire un fadeIn/fadeOut(opacizzare gradualmente un elemento dom) se questo è di grandi dimensioni...
L'utilizzo di CPU è sostanzioso, c'è qualche trucchetto da utilizzare per caso che non conosco?
In più fanno fatica anche a spostare e ridimensionare un elemento con opacità inferiore al 100%...

6) Mettiamo che devo spostare un elemento DOM che ha al suo interno altri vari elementi.
I browser fanno più fatica a reinderizzare l'elemento se gli elementi al suo interno sono posizionati in modo assoluto, o se seguono il normale flusso dei dati?
Esempio:

<div id="toMove" style="position:absolute; top:0px; left:0px">
    <div class="inner">
         <img class="inner"/>
         <label class="inner">blabla bla</label>
         <p class="inner">bvla bla valjeiklfnelkfnekfde </p>
    </div>
    <h3 class="inner"></h3>
</div>

Ecco, se devo spostare "toMove", è meglio se al suo interno posiziono tutto in modo assoluto(quindi con riferimento a toMove) o se lascio tutto normale?
Oppure non c'è nessuna differenza?



Per ora direi che può bastare, scusate se vi sembrano delle cazzate ma io sono fissato per cercare di ottimizzare al meglio e credo che differenze ce ne siano.
Mi piacerebbe una conferma/smentita.

[fcaldera]

1) OOP soprattutto se il progetto è grande

2) Non conosco il garbage collector nei dettagli però ci sono alcune issue da considerare quando si utilizza Explorer 6 e alcuni accorgimenti (ad esempio prestare attenzione alle closures, alla manipolazione dei nodi del dom... devi cercare)

3) Usa setTimeout perchè puoi gestire le chiamate ricorsive

4) Meglio assegnare una classe/id, così se cambia lo stile cambi solo il CSS. Applicare effetti di spostamento a oggetti grandi comporta un degradamento dell'effetto stesso (su Firefox soprattutto, rallentamenti, ritardi e lievi scatti diventano quasi inevitabili)

5) vedi risposta 4. Usando Mootools ho lo stesso problema. Mi accodo alla domanda

6) Probabilmente un'effetto su un elemento posizionato sarà più performante che non su uno statico, però ho l'impressione che ciò non incida in modo determinante nell'efficienza dello script.
Di sicuro spostare elementi che hanno molti sottoelementi annidati (per molti intendo centinaia, migliaia), diventa più gravoso, ma non è il tuo caso

[Linusss]

Ok grazie mille, quindi continuo con l'OOP.
Già che ci siamo per quanto riguarda l'OOP.
Mettiamo che io abbia un oggetto:

function MyObject(dom){
      this.dom=dom;
      //var self=this;
      this.move=function(x,y){
         this.dom.style.left=x+"px";
         this.dom.style.top=y+"px";
      }
      this.dom.onclick=function(){
         this.move(10,20);
         //self.move(10,20);
      };
}

In una situazione del genere quando clicco su dom darebbe errore perchè "this" si riferisce all'elemento dom stesso e non all'oggetto "MyObject".
Per ovviare uso la parte che è commentata, volevo chiedere, utilizzare "var self=this" che effetti provoca?
Mi spiego, self contiene tutto l'oggetto, quindi in pratica avrei una occupazione doppia della memoria per ogni oggetto che utilizza "var self=this" ?

[andr3a]

quanta confusione in questo post ...

1) esiste l'uso di prototype che è solitamente favorito proprio per non dover creare N funzioni per ogni istanza

function MyObject(dom){
	this.dom=dom;
}
MyObject.prototype.move=function(x,y){
	//code
	this.dom.move(x, y);
}

2) le variabili ovviamente se dichiarate con var appartengono a quello scope e se non assegnate ad altre appartenenti a scope globale vengono cancellate ... test1 va bene, test2 fa un'operazione inutile, test3 è tutt'altra cosa, crea una variabile globale (o proprietà del window) perchè non usa var, ergo non è paragonabile ... è un'altra funzione.

3) ... non ho capito cosa intende fcaldera quando dice che con setTimeout puoi gestire le chiamate ricorsive ... setTimeout e ricorsione sono cose diverse, ma in generale puoi gestire quello che vuoi anche col setInterval e proprio per movimenti è consigliato perchè il setTimeout, come il setInterval, crea un id univoco tramite un int32 e prima o poi questi intervalli finiscono ... quindi setTimeout è da usare senza problemi, ma solo quando serve veramente, opinione personale.

4) per i CSS esistono le classi, se usi solo ID ti ritrovi chili di CSS ridondanti .... il JS prevale sulle classi e gli id, ma puoi anche affiancare JS e CSS senza problemi.

5) dipende da che lib usi primo, e da quanto contenuto c'è nell'opacizzato due. Un browser difficilmente potrà sfruttare OpenGL o DirectX che sia per ottimizzare il rendering grafico ... ma lo faranno, prima o poi ^_^

6) l'assoluto è più semplice da gestire per te, per il browser credo ci siano poche differenze ma in generale io preferisco il relativo, dentro l'assoluto, così muovo uno e tutto il resto è ok (come fanno il 99% delle lib, non si occupano degli elementi interni e muovono in assoluto i contenitori)

scusate se vi sembrano delle cazzate ma io sono fissato per cercare di ottimizzare al meglio e credo che differenze ce ne siano.

non sono cavolate per il semplice motivo che JavaScript è il linguaggio più mal compreso che ci sia ... ma ti consiglio qualche approfondimento in più prima di progettare lo shuttle



P.S. sull'uso di var self = this ... è logico che non duplichi niente, gli oggetti in JS sono tutti per riferimento altrimenti i nostri PC ssarebbero già esplosi

[Linusss]

Ciao, ti ringrazio per tutti i chiarimenti che mi hai dato.
Volevo tirare fuori il discorso del prototype, ma visto che ci hai pensato tu ne approfitto.

Volendo rendere javascript OOP ho ovviamente la necessità di stanziare nuovi oggetti, e per ora utilizzo questa sintassi:

function MyObject(){
      var privateVariable=null;
      this.publicVariable=null;
      var privateMethod=function(){
         //code
      }
      this.publicMethod=function(){
         //code
      }
}

var o=new MyObject();

Questo, a parte essere molto leggibile come codice, crea a tutti gli effetti una nuova classe, con una variabile e un metodo private, e una variabile e un metodo pubblico.

Leggendo in giro ho notato che molti utilizzano il prototype(come mi hai fatto notare anche te):

function MyObject(){
      var privateVariable=null;
      var privateMethod=function(){
         //code
      }
}

MyObject.prototype.publicVariable=null;
MyObject.prototype.publicMethod=function(){
         //code
}

var o=new MyObject();

Che differenza c'è tra queste due sinstassi? Il risulatato è lo stesso, ma il primo,almeno per quanto mi riguarda, è più leggibile.
La prima cosa che mi salta in mente, è che "forse" con classi che contengono molti metodi ci vorrebbe più tempo ad istanziarle nel primo caso, mentre con prototype la classe risulterebbe più leggera, sbaglio?

Eredità
Dovendo usare l'eredità, mi sono accorto che anche qui esistono vari metodi per realizzarla:

		function Person(name){
			this.name=name;
			this.showMyName=function(){
				alert(this.name);
			}
		}
		
		//Girl1 estende Person: metodo senza prototype
		function Girl1(name){
			this.extends=Person;
			this.extends(name);
			var gender="female";
			this.showMyGender=function(){
				alert(gender);
			}
		}

		//Girl2 estende Person: metodo con prototype
		function Girl2(name){
			Person.call(this,name);
			var gender="female";
			this.showMyGender=function(){
				alert(gender);
			}
		}
		Girl2.prototype=new Person();
		Girl2.prototype.constructor=Girl2;
		
		var p1=new Girl1("Anna");
		p1.showMyName();	//>Anna
		p1.showMyGender();	//>female
		
		var p2=new Girl2("Anna");
		p2.showMyName();	//Anna
		p2.showMyGender();	//female

Il risultato è identico, ma anche questa volta la sintassi senza prototype mi sembra più leggibile.
Quale bisogna usare?

5) dipende da che lib usi primo, e da quanto contenuto c'è nell'opacizzato due. Un browser difficilmente potrà sfruttare OpenGL o DirectX che sia per ottimizzare il rendering grafico ... ma lo faranno, prima o poi ^_^

Non uso nessuna lib, le sto facendo io le librerie.

[andr3a]

Originariamente inviato da Linusss
Volendo rendere javascript OOP

JavaScript e' gia' OO ... non puoi renderlo OO visto che nasce OO

Originariamente inviato da Linusss
ho ovviamente la necessità di stanziare nuovi oggetti, e per ora utilizzo questa sintassi:
...
Questo, a parte essere molto leggibile come codice, crea a tutti gli effetti una nuova classe, con una variabile e un metodo private, e una variabile e un metodo pubblico.

se usi metodi privati hai poche chances ... i metodi in prototype non possono accedere al private scope del costruttore se non tramite un bridge pubblico e creato per ogni istanza.

Originariamente inviato da Linusss
Leggendo in giro ho notato che molti utilizzano il prototype ...
Che differenza c'è tra queste due sinstassi? Il risulatato è lo stesso, ma il primo,almeno per quanto mi riguarda, è più leggibile.
La prima cosa che mi salta in mente, è che "forse" con classi che contengono molti metodi ci vorrebbe più tempo ad istanziarle nel primo caso, mentre con prototype la classe risulterebbe più leggera, sbaglio?

un solo metodo pubblico nel costruttore (si chiama metodo privilegiato, capace di overloadare la prototype) ... 10 istanze, 10 nuove funzioni per ogni istanza.

1 solo metodo pubblico in prototype, 10 istanze, 1 sola funzione per tutte assegnata per riferimento.

Originariamente inviato da Linusss
Eredità
Dovendo usare l'eredità, mi sono accorto che anche qui esistono vari metodi per realizzarla:

errato, ne esiste uno ed uno solo, il prototype.
Eredita' significa che classe B che stende A e' sia instanceof A che instanceof B

Nel tuo esempio nessuno e' istanceof parent, quindi il risultato non e' identico.

Originariamente inviato da Linusss
la sintassi senza prototype mi sembra più leggibile.
Quale bisogna usare?

dipende se vuoi estendere o fare altro ... per estendere hai bisogno delle prototypes, per fare altro no, ma non stai estendendo un granche'.

Originariamente inviato da Linusss
Non uso nessuna lib, le sto facendo io le librerie.

bene, approfondisci bene pero' il tutto perche' continuo a pensare ci sia un po' di confusione.
In bocca al lupo per la lib

[Linusss]

Originariamente inviato da andr3a
un solo metodo pubblico nel costruttore (si chiama metodo privilegiato, capace di overloadare la prototype) ... 10 istanze, 10 nuove funzioni per ogni istanza.

1 solo metodo pubblico in prototype, 10 istanze, 1 sola funzione per tutte assegnata per riferimento.

Si ma anche con l'utilizzo di "call" vale lo stesso discorso?

errato, ne esiste uno ed uno solo, il prototype.
Eredita' significa che classe B che stende A e' sia instanceof A che instanceof B

Nel tuo esempio nessuno e' istanceof parent, quindi il risultato non e' identico.

Nei miei due esempi si ha erdità in entrambi i casi, perchè dici di no?

[Linusss]

Ah ho capito perchè non c'è ereditarietà come faccio io:

		alert(p1 instanceof Person); //>false
		alert(p2 instanceof Person); //>true

Sto cercando di sviluppare una classe base, che mi metta a disposizione dei metodi per creare, estendere ed implementare altre classi.
Ma la cosa non è affatto banale.

[Linusss]

Ho trovato questo http://dean.edwards.name/weblog/2006/03/base
che utilizza una classe base per crare ed estendere altre classi.
E' proprio quello che sto cercando di fare io, ma se devo essere sincere non mi convince tanto il metodo che usa, mi pare molto "sporco".

In giro ci sono molti framewrok javascript, ad esempio mootool, ho controllato e anche quella si appoggia tutta su una classe base che chiama "Class"(che fantasia ) molto simile a quella del link, anche se forse è scritta in un modo più leggibile.

A questo punto mi sorge un dubbio, faccio bene a cercare di creare una classe base, o è meglio se estendo, implemento nei classici modi tutte le mie classi che andrò a creare?

[Linusss]

Ti volevo chidere, è possibile assegnare metodi direttamente alla classe?
Ad esempio:

function A(){
     A.test=function(){
        alert("test");
     }
}

A.test(); //>test

Sembra a tutti gli effetti un metodo "statico", ma è davvero così? E' sbagliato fare una cosa del genere?

Inoltre, si riesce ad ereditare una situazione simile? Cioè:

function B(){
}
B.prototype=new A();
B.test(); // errore