nicht angemeldet
Gunnar Bittersmann
Rolf b
dedlfix
JürgenB
JürgenB
JürgenB
Matthias Apsel
Julius
Matthias Apsel
Hallo an alle, ich brauche ein bißchen hilfe, danke im voraus für die Hilfe.
<html>
<head>
<title>Index Datei</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0" />
<link rel="stylesheet" href="css/style.css" type="text/css" />
<script src="js/jquery-3.1.1.js"></script>
<script language="JavaScript" type="text/javascript" src="js/header.js"></script>
<script>
var tag=["header","article","footer"];
var datei=["header.html","article.html","footer.html"];
$(function(){
$(tag[0]).load(datei[0]);
});
$(function(){
$(tag[1]).load(datei[1]);
});
$(function(){
$(tag[2]).load(datei[2]);
});
</script>
</head>
<body>
<header></header>
<article></article>
<footer></footer>
</body>
</html>
ich habe versucht das Script in eine Schleife umzuwandeln und auf eine externe js Datei (mit übergabe von Parameter) zu speichern.
vielen dank.
matb9899
var tag=["header","article","footer"]; var datei=["header.html","article.html","footer.html"]; $(function(){ $(tag[0]).load(datei[0]); }); $(function(){ $(tag[1]).load(datei[1]); }); $(function(){ $(tag[2]).load(datei[2]); });
$() ist eine Kurzschreibweise für $(document).ready() und das heißt, dass die Reihenfolge in der dein Code ausgeführt wirst, nicht die gleiche ist, in der man den Code auch liest. Folgendes geht zum Beispiel schief:
var tag=["header","article","footer"];
var datei=["header.html","article.html","footer.html"];
for (var i = 0; i < tag.length; i++) {
$(function(){
$(tag[i]).load(datei[i]);
});
}
Wenn die Zeile $(tag[i]).load(datei[i]) ausgeführt wird, ist die for-Schleife bereits durchgelaufen und i ist dann immer 2.
Mit einem let-Binding ließe sich das Problem beheben:
var tag=["header","article","footer"];
var datei=["header.html","article.html","footer.html"];
for (let i = 0; i < tag.length; i++) {
$(function(){
$(tag[i]).load(datei[i]);
});
}
Aber eleganter wäre es, die Vorschleife in den $-Block mit hinein zu nehmen:
var tag=["header","article","footer"];
var datei=["header.html","article.html","footer.html"];
$(function(){
for (let i = 0; i < tag.length; i++) {
$(tag[i]).load(datei[i]);
}
});
Als Sahnehäubchen würde ich auch die Arrays tag und datei zu einem Array zusammenfassen, damit du sie nicht über die Index-Variable i miteinander korrelieren musst:
const content = [
{ tag: "header", datei: "header.html" },
{ tag: "article", datei: "artcile.html" },
{ tag: "footer", datei: "footer.html" },
];
$(function() {
for (let {tag, datei} of content) {
$(tag).load(datei);
}
});
Mit der Kurzschreibweise für Funktionen könntest du die Leserlichkeit noch zusätzlich erhöhen:
const content = [
{ tag: "header", datei: "header.html" },
{ tag: "article", datei: "artcile.html" },
{ tag: "footer", datei: "footer.html" },
];
$(() => content.forEach(({tag, datei}) => $(tag).load(datei)));
@@1unitedpower §
const content = [ { tag: "header", datei: "header.html" }, { tag: "article", datei: "artcile.html" }, { tag: "footer", datei: "footer.html" }, ]; $(function() { for (let {tag, datei} of content) { $(tag).load(datei); } });Mit der Kurzschreibweise für Funktionen könntest du die Leserlichkeit noch zusätzlich erhöhen:
const content = [ { tag: "header", datei: "header.html" }, { tag: "article", datei: "artcile.html" }, { tag: "footer", datei: "footer.html" }, ]; $(() => content.forEach(({tag, datei}) => $(tag).load(datei)));
Um das besser lesbar zu finden, muss man da ein Nerd mit einem Faible für funktionale Programmiersprachen sein?
LLAP 🖖
Rolf <<<- Nerd
Hallo Gunnar,
$(() => content.forEach(({tag, datei}) => $(tag).load(datei)));Um das besser lesbar zu finden, muss man da ein Nerd mit einem Faible für funktionale Programmiersprachen sein?
Ich bin ein „Nerd mit einem Faible für funktionale Programmiersprachen” und ich finde die Kurzschreibweise von Funktionen beschissen lesbar… damit hat es also nichts zu tun.
LG,
CK
Um das besser lesbar zu finden, muss man da ein Nerd mit einem Faible für funktionale Programmiersprachen sein?
Nö, ich glaube das ist einfach eine Sache der Geschmäcker.
Hier ist, was bei mir im Kopf passiert, wenn ich bestimmte Konstrukte lese:
(function(/*...*/){/*...*/})
... hoffentlich kommt da kein this mehr drin vor[1]
for (/*...*/) {/*...*/}
... oh ein for-Loop – wie nützlich[2]
und mit einer gewissen Latenz
... hoffentlich passiert jetzt nichts Asynchrones im Inneren
Denn sonst muss ich mir auch noch alle dynamischen Scoping-Regeln ins Gedächtnis rufen und mit berücksichtigen. Das ist etwas, dass ich bei der Pfeil-Syntax ignorieren kann. Außerdem finde ich x => y schlicht suggestiver als function (x) { return y }. ↩︎
Ein for-Loop teilt mir nicht mit, was während der Iteration eigentlich passiert. Die Array-Methoden .map, .filter, .reduce, etc. tun das. Bei .forEach weiß ich, dass der Zweck einzig und allein ist, Nebenwirkungen herbeizuführen. In diesem Fall die Manipulation des DOM. ↩︎
Tach!
$()ist eine Kurzschreibweise für$(document).ready()
Nicht ganz. Das stimmt so nur, wenn man eine Funktion übergibt. Für andere Typen hat es andere Auswirkungen. Präziser gesagt:
$(function() {…}) ist eine Kurzschreibweise für $(document).ready(function() {…})
Mit der Kurzschreibweise für Funktionen könntest du die Leserlichkeit noch zusätzlich erhöhen:
$(() => content.forEach(({tag, datei}) => $(tag).load(datei)));
Kommt drauf an. Wenn man das für Javascript ziemlich neue Konstrukt () => {} kennt, dann vielleicht. Es verkürzt zumindest den Code. Ansonsten verschlechtert es eher die Lesbarkeit wegen Noch-nicht-Verständlichkeit.
dedlfix.
Hallo,
Kommt drauf an. Wenn man das für Javascript ziemlich neue Konstrukt
() => {}kennt, dann vielleicht. Es verkürzt zumindest den Code. Ansonsten verschlechtert es eher die Lesbarkeit wegen Noch-nicht-Verständlichkeit.
wobei hier das Wissen über dieses „ziemlich neue Konstrukt“ bei den Browsern ähnlich schlecht ist, wie bei den Programmierern. (http://caniuse.com/#search=%3D>). Bei let sieht es nicht wirklich besser aus. (http://caniuse.com/#search=let).
Gruß
Jürgen
wobei hier das Wissen über dieses „ziemlich neue Konstrukt“ bei den Browsern ähnlich schlecht ist, wie bei den Programmierern. (http://caniuse.com/#search=%3D>). Bei
letsieht es nicht wirklich besser aus. (http://caniuse.com/#search=let).
Alle Evergreen-Browser unterstützen diese beiden Features, was wirklich keine schlechte Bilanz ist. Für den Produktiveinsatz reicht das wohl eher nicht, aber dafür haben wir ja Transpiler wie Babel und TypeScript, die uns Code erzeugen, der sogar noch in Browsern laufen dürfte, die zur Jahrtausendwende aktuell waren.
Bis der IE11 und einige der exotischeren Browser von caniuse, entweder von der Bildfläche verschwunden sind, oder nachgerüstet haben, dürften (schlecht geschätzt) vielleicht noch 5 bis 10 Jahre vergehen. Man hat also die Wahl: entweder man wartet das ab und schreibt bis dahin brav ECMAScript5 Code (und ist in 5 Jahren vermutlich abgehängt) oder man geht den Zwischenschritt über einen Transpiler und schreibt tagesaktuellen Code.
Ich würde mir auch wünschen, dass man heute wie damals JavaScript-Code für den Browser hackt und dieser einfach läuft. Das verfehlt aber leider die berufliche Praxis. Dort gehören Build-Zwischenschritte wie Minifizierung, Bundling, Treeshaking, etc. bereits zum täglich Brot und da macht es nicht mehr viel Unterschied auch noch einen Transpiler in die Kette zu integrieren. Für manche unprofessionelle Hobby-Seiten, Prototypen oder Lern-Projekte braucht man das sicher nicht, aber dann kann ich auch auf die Unterstützung von Browser-Exoten verzichten.
Hallo,
… oder man geht den Zwischenschritt über einen Transpiler und schreibt tagesaktuellen Code.
der Zusatz hat mit gefehlt. Anfänger testen z.B. im FF und merken dann garnicht, wo es nicht geht. Und garade so etwas wie 'let' oder => führen ja zum Abbruch des Scripts.
Gruß
Jürgen
PS Welchen Transpiler würdest du empfehlen?
PS Welchen Transpiler würdest du empfehlen?
Das kommt ganz auf den Zweck an, den man verfolgt: Will man einfach mit neuen JavaScript-Features experimentieren, dann reicht meist schon ein moderner Browser ohne Transpiler. kangax' Kompatibilitätstabelle liefert da übrigens eine bessere Übersicht als http://caniuse.com/.
Für Experimente mit brandneuen oder Transpiler-spezfischen Sprachfeatures eignen sich die jeweiligen Spielwiesen recht gut: https://babeljs.io/repl/ https://www.typescriptlang.org/play/index.html
Das ist auch der einfachste Einstieg, den man mit Transpilern machen kann.
Für den Einsatz im Produktivbetrieb muss man weitere Fragen für sich beantworten:
Alle mir bekannten Transpiler lassen sich ohne viel Aufsehens in die oben genannten Buildsysteme integrieren, aber es ist definitiv hilfreich auch das Kommandozeilen-Interface bedienen zu können. Wenn man noch keine Erfahrungen mit einem dieser Systeme gemacht hat, dann ist Webpack2 vermutlich der einfachste Einstieg.
Babel ist eher konservativ, standardkonform - kann aber modular erweitert werden und erlaubt sozusagen eigene JavaScript-Dialekte zusammenzuschustern. Es eignet sich hervorragend als Kompatibilitätsschicht, kann aber unhandlich werden, sobald man vom Standard abweichende Features nutzen will.
TypeScript ist deutlich voreingenommener und definiert eine reichhaltige Supermenge von JavaScript. Als Kompatibilitätsschicht definitiv auch geeignet, aber darauf beschränkt, würde man viel Potenzial vergeuden. TypeScript hat eine außerordentlich gute Editor-Integration und ermöglicht zum Beispiel intelligente Autovervollständigung und Fehlersuche. Außerdem ist TypeScript die primäre Programmiersprache, in der Angular2-Apps geschrieben werden.
Emscripten wäre ein Beispiel für einen Transpiler, der nicht JavaScript oder einen Dialekt als Eingabe nimmt, sondern C/C++. Das Ausgabeformat ist auch nicht direkt JavaScript, sondern eine optimierte Teilmenge ASM.js bzw. WebAssembly. Letztere sind speziell als Compiler-Ziele vor dem Hintergrund besserer Performance entwickelt worden. Emscripten eignet sich also vor allem für Performance-kritische und rechenintensive Anwendungen wie 3D-Spiele oder Simulationen.
Malt man eine Linie zwischen highlevel und lowlevel Sprachen, befände sich Elm vermutlich am anderen Ende von C/C++. Das ist (meiner sehr subjektiven Meinung nach) JavaScript, wie es aussähe, wenn wir es heute neu machen könnten ohne Rücksicht auf Abwärtskompatibilität − eine highlevel Architektursprache zum Bau komplexer Anwendungen.
Babel und TypeScript wären etwas, mit dem man jederzeit anfangen kann. Emscripten füllt eine Nische für Performance-kritische Anwendungen. Elm erfordert das Lernen einer völlig neuen Programmiersprache und ist etwas, das man eher mittel- bis langfristig anstreben könnte.
hallo
kangax' Kompatibilitätstabelle liefert da übrigens eine bessere Übersicht als http://caniuse.com/.
Danke für den Link.
Hallo,
danke.
Gruß
Jürgen
Hallo 1unitedpower,
kangax' Kompatibilitätstabelle liefert da übrigens eine bessere Übersicht als http://caniuse.com/.
Sie mag vollständiger oder auch detaillierter sein. Übersichtlicher gar benutzerfreundlicher ist sie nicht. Ich verstehe zum Beispiel nicht, warum man das alles in eine Tabelle packt.
Bis demnächst
Matthias
Hallo Matthias,
Ich verstehe zum Beispiel nicht, warum man das alles in eine Tabelle packt.
... diese Seite hat außerdem einen dermaßen hohen Ressourcenverbrauch, dass Firefox auf meinem (zugegebenermaßen etwas altmodischen) Rechner starke Probleme beim Laden und Rendern bekommt, wenn ich noch ein paar Tabs mehr geöffnet habe...
Gruß
Julius
Ich verstehe zum Beispiel nicht, warum man das alles in eine Tabelle packt.
... diese Seite hat außerdem einen dermaßen hohen Ressourcenverbrauch, dass Firefox auf meinem (zugegebenermaßen etwas altmodischen) Rechner starke Probleme beim Laden und Rendern bekommt, wenn ich noch ein paar Tabs mehr geöffnet habe...
Das stimmt leider, ich glaube das liegt daran, dass die Seite alle Feature-Tests live durchführt, um die erste Spalte der Tabelle zu berechnen.
Hallo matb9899,
ein paar weitere Hinweise:
Es fehlt der doctype. Verwende <!doctype html>
<html>
Hier sollte die Angabe der Sprache des Dokuments erfolgen, z.B. <html lang="de">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0" />
Es ist keine gute Idee, das Zoomen zu unterbinden.
<link rel="stylesheet" href="css/style.css" type="text/css" />
type="text/css" ist der default, kann weg.
<script language="JavaScript" type="text/javascript" src="js/header.js"></script>
type="text/javascript" ist der default, kann weg
language="javascript" war noch nie sinnvoll.
Bis demnächst
Matthias
Danke Matthias für die Hinweise, ich habe sie schon angewendet und ohne die Änderungen von 1unitedpower hat alles immer noch funktioniert :-)
1unitedpower, danke für die ausführliche Beispiele, ich habe sie so angewendet und leider hat nicht funtioniert, vielleicht habe ich ein Fehler übersehen:
header.js: zur Zeit so eingetragen
var tag=["header","article","footer"];
var datei=["header.html","article.html","footer.html"];
$(function(){
for (let i = 0; i < tag.length; i++) {
$(tag[i]).load(datei[i]);
}
});
index.html:
<!DOCTYPE html>
<html lang="de">
<head>
<title>Index Datei</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="css/style.css" />
<script src="js/jquery-3.1.1.js"></script>
<script src="js/header.js"></script>
</head>
<body>
<header></header>
<article></article>
<footer></footer>
</body>
</html>
danke wieder im voraus
Was steht denn im Netzwerk-Trace des Browsers? Sprich: was VERSUCHT er zu laden?
Abgesehen davon möchte ich die Grundsatzfrage stellen: WTF[1]? Warum lädt man seine HTML-Seite in 3 Ajax-Calls dynamisch nach, statt die 3 HTMLs serverseitig zu includen? Kannst oder willst Du serverseitig keine dynamischen Komponenten verwenden?
Rolf
Warum Tiese Ferrenkung? ↩︎
Hallo bin kein Profi, ich habe immer mit CMS (Wordpress und Contao) gearbeitet, leider kein Core Programmierer. Programmieren kann ich ein bißchen, bis jetzt hat gereicht, aber ich möchte jetzt alles selbst programmieren und wenn moglich kein CMS verwenden (wenn keine Datenbank brauche).
Ich habe die Möglichkeit gesucht das Code zu klein wie möglich zu halten so wie ein Template und deswegen habe ich versucht, in diesem Fall, z. B., kein PHP zu benutzen, die 3 Seiten sind ganz normales Webseiten.
Habt Ihr andere Meinung, was wäre die richtige Methode eine Webpräsenz zu erschaffen, möglich weniger Sicherheitslücke.
Es ist natürlich deine Entscheidung, was Du tun willst. Es hängt auch davon ab, was Du erreichen willst.
Wenn Du die Startseite mit Header, Main-Teil und Footer auf diese Weise lädst, hast Du im Prinzip nichts weiter als eine statische HTML Seite, nur eben mit vier Ladevorgängen statt einem.
Du kannst auf diese Weise erreichen, dass Du deine Webseite aus statischen Elementen zusammenbaust, gesteuert durch JavaScript im Browser. Für ein einfaches CMS-artiges Gebilde mag das reichen, d.h. du hast eine Navigation, mit der Du diversen Content abrufen kannst. Was Du damit nicht erreichen kannst, sind Datenbankabfragen und Zugriffschutzmechanismen. Und deine Programmlogik ist für jeden offensichtlich (weil heute jeder Browser Entwicklerwerkzeuge hat, mit der man das JavaScript anschauen kann). Wenn das für Dich ok ist, kannst Du so sicherlich ein paar Gehversuche mit JavaScript machen.
Es bleibt also die Frage: warum geht's nicht. Die Frage, was der Netzwerktracer im Browser sagt, bleibt bestehen. Ich vermute, dass man dort Fehlermeldungen sehen wird. Weißt Du, wo Du den findest?
Rolf
Danke für die Antwort, und du hast recht, ich werde die möglichkeiten wieder betrachten. Danke für Eure Tipps und Hinweise.