[Ajax] einfache Uhr mit serverseitiger Zeit

[SteelWheel]

Mein Standpunkt ist ein ganz anderer - damit habe ich aber auch gar kein Problem (und soll hier auch keines darstellen). Denn ich gehe gar nicht konform mit "Optimierung nur in Spezialfällen" oder "bei nicht relevantem Code sinnlos". Auch ist der Minimizer eher was zum Einsparen von Leerzeichen, unnötigen Zeilenumbrüchen etc. - davon sprach ich aber nicht (der hat keinen Kontakt mit besagter Schreibweise; oder mein Minifier kann es nicht bzw. Du meinst was anderes). Ich für meinen Teil baue meinen Quellcode nicht "mal so" ("dreckig", da vermeintlich unrelevant) und einmal "high performant", da es vermeintlich Sinn ergibt. Allein hier wären es bereits zwei Handschriften - von einer Person. Stellt man sich dies nun in einer Agentur vor, ist man schnell bei Sätzen wie "wer hat denn den Mist zuletzt gebaut?!". (ohne Versionierung)

Die "Anzahl Requests" ist was, da begegnen wir uns zumindest (erneut) auf einem Nenner. Und da gibt es noch mehr, worauf man - für gewöhnlich - zu achten hätte. Ob man's macht, ist jedem Dienstleister bzw. Freelancer oder Hobby-Coder selbst überlassen.

Lass uns, hesst, also im gewohnt Guten auseinander gehen aus diesem Thread! Ich wollte niemanden Bekehren, sondern erwähnte nur die - zumindest für mich - empfohlene Schreibweise. Wir werden uns demnach einig mit dem Satz, dass viele Weg nach Rom führ(t)en ...

Beste Grüße.

 

[tsseh]

Auch ist der Minimizer eher was zum Einsparen von Leerzeichen, unnötigen Zeilenumbrüchen etc. - davon sprach ich aber nicht (der hat keinen Kontakt mit besagter Schreibweise; oder mein Minifier kann es nicht bzw. Du meinst was anderes).

ein minimizer ersetzt funktionsnamen und variablennamen durch andere im idealfall 1 zeichen, entfern alle unnötigen leerzeichen. damit fallen deine paar zeichen überhaupt nicht mehr ins gewicht.
und so entwickelt man ja auch nicht um zeichen zu sparen.

Ich für meinen Teil baue meinen Quellcode nicht "mal so" ("dreckig", da vermeintlich unrelevant)

was ist daran dreckig?

und einmal "high performant", da es vermeintlich Sinn ergibt. Allein hier wären es bereits zwei Handschriften - von einer Person.

nochmal, wenn es grund zur optimierung gibt, wird an der stelle optimiert, die optimierungspotential hat, nicht auf verdacht an stellen, die das nicht haben.

Lass uns, hesst, also im gewohnt Guten auseinander gehen aus diesem Thread!

das ist ein forum, da diskutiert man, da hat man auch mal unterschiedliche meinungen, jede seite versucht seine meinung darzulegen.
warum sollte ich da nicht im guten mit dir auseinander gehen, selbst wenn ich deine meinung nicht teile?

Ich wollte niemanden Bekehren, sondern erwähnte nur die - zumindest für mich - empfohlene Schreibweise.

ich verwende die auch, aber nicht wegen der zeiten, sondern weil diese üblicher ist.

Wir werden uns demnach einig mit dem Satz, dass viele Weg nach Rom führ(t)en ...

ja sicher, aber mir ging es hier um das optimieren als solches, nicht um schreibweisen. wann und wo wird optimiert und wann und wo nicht.

 

[kkapsner]

Ich hab' jetzt meinen Test mal auf Number, String und RegExp erweitert (hatte vorher nur Array getestet). Und die sind wirklich signifikant langsamer. Bei Object ist der Unterschied nicht so stark, aber der Konstruktor ist langsamer. Bei Array sehe ich so gut wie keinen Unterschied - mal ist das Eine, mal ist das Andere schneller.

@SteelWheel: Das mit "den": da hab' ich dich einfach falsch verstanden.

Was mir jetzt als Beispiel für dynamische RegExp einfällt ist ein Polyfil für das pattern-Attribut in <input>s.

Eigene Fehlermeldungen kannst du auch mit den nativen Error-Konstruktoren erstellen. Dann hast du im catch auch noch Informationen, die du sonst nur mit viel Arbeit in dein Fehlerobjekt reinbekommst (z.B. Zeilennummer):

try {
	var e = new Error();
	e.name = "MyErrorType";
	e.message = "oops"; 
	e.extra = "This was rather embarrassing";
	e.remedy = function(){alert(1);}
	throw e;
}
catch (e){
	console.log(e);
	e.remedy();
}

Und JS ist im Browser extrem selten der Flaschenhals (das Erzeugen einer Zahl bewegt sich im ns Bereich). Die Zugriffe auf das DOM sind meistens viel langsamer.

@hesst: Ich meine sowas wie:

var a = Array(1, 2);
// vs.
var a = Array(1);

und

(typeof 3) !== (typeof new Number(3))

Ich finde ja generell Schreibweisen, die kürzer, schneller und üblicher sind prinzipell eine gute Sache.

 

[tsseh]

Ich meine sowas wie:

var a = Array(1, 2);
// vs.
var a = Array(1);

2 verschiedene konstruktoren. und da ein array mit einem entry wenig sinn macht, sieht man, dass sie sich durchaus was dabei gedacht haben. du verbietest ja auch keine funktionen, weil man diesen argumenten mit unterschiedlichen bedeutungen übergeben kann. man muss schon wissen, was man wie verwendet.
und schreib das mal als literal
var a = Array(1000);
das sieht auch nicht schön aus
a = [];
a[999] = undefined;
wobei ich auch nicht wüsste wo man das mal benötigt.

(typeof 3) !== (typeof new Number(3))

du meintest

(typeof 3) != (typeof new Number(3))

wo ist der grüne?

du vergleichst einen primitiven datentyp mit einem komplexen. ist doch richtig.
das beispiel kann ich sonst auch für die verwendung von konstruktoren bringen.

(typeof new Number(3) != (typeof 3))

so, ätsch

Ich finde ja generell Schreibweisen, die kürzer, schneller und üblicher sind prinzipell eine gute Sache.

ich auch, habe aber auch nichts gegen andere. sonst sind for schleifen besser als do-while, if {} else if {} else{} besser als switch, === besser als == und und und. alles hat seine berechtigung, das eine benötigt man häufiger, das andere nicht so häufig.

 

[j-l-n]

Könnte jemand dann vielleicht noch die endgültige, optimierte Version posten?

 

[mikdoe]

Ich bin bei Version aus #28 plus Änderung aus #33 geblieben.

 

[kkapsner]

2 verschiedene konstruktoren.

... die aber sehr ähnlich aussehen und für Verwirrung sorgen können. V.A. wenn man den JS-Code dynamishc erzeugt.

und da ein array mit einem entry wenig sinn macht

Natürlich ergibt das Sinn. Das ist ja nur die initiale Belegung. Auch leere Arrays ergeben Sinn.

wobei ich auch nicht wüsste wo man das mal benötigt.

Wollte ich gerade schon sagen...

wo ist der grüne?

hier: - ist aber leider nicht das Original.

du vergleichst einen primitiven datentyp mit einem komplexen. ist doch richtig.

Mir ist schon klar, dass da ein Unterschied ist. Aber wenn ich z.B. eine Funktion schreibe, die irgendwo testen muss, ob ein Parameter eine Zahl ist, muss ich

if (typeof param === "number" || param instanceof Number){...}

testen - das ist unübersichtlich und nervig. Wenn man aber in der Codekonvention festlegt, dass da immer die Literalschreibweise benutzt wird, kann man sich das hintere sparen.

das beispiel kann ich sonst auch für die verwendung von konstruktoren bringen.

Äh wie willst du einen selbst definierten Konstruktor über Literalschreibweise aufrufen? Bzw. da gibt typeof immer "object" zurück.

ich auch, habe aber auch nichts gegen andere.

Jeder kann schreiben, wie er will. Aber man kann die Leute darauf hinweisen, wenn sie eine verwenden, die Nachteile hat, oder eine nicht verwenden, die Vorteile hat.

=== besser als ==

Jaja - da werden wir nie zusammen kommen...

alles hat seine berechtigung, das eine benötigt man häufiger, das andere nicht so häufig.

Das würde ich so nicht sagen. Es gibt in JS einfach Dinge, die nicht gut designed sind, die man umgehen sollte. Und die meisten davon braucht man auch nie (also ich hab' den Number-Konstruktor noch nie verwendet).