Chrome, import, local file
0 
Rolf B
0 0 Rolf B
0 0 
Felix Riesterer
0 0 Felix Riesterer
0 Rolf B
0 dedlfix
0 
JürgenB
Chrome, import, local file
Hallo,
ich habe ein paar einfache Scripte in auf dem PC im gleichen Ordner gespeicherten Dateien ausprobiert, es geht um (wohl eher statischen) einfachen import, export und module.
Dabei gibt es -anscheinend grundsätzlich bekannte- Probleme mit Chrome, einmal wohl CORS, dann womöglich mime-type.
Mit dem Zusatz --allow-file-access-from-files kann offenbar ein Problem umgangen werden, allerdings mag Chrome offline dann immer noch nicht:
Failed to load module script: The server responded with a non-JavaScript MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec
Versuche mit "crossorigin" brachten nichts, und request.mode hat mich bislang nicht weiter inspiriert.
Abgesehen von der Frage nach einer möglichen einfachen Lösung, die die eigentlichen Scripte nicht verschlimbessern sollte, interessiert mich auch grundsätzlich die Frage, ob Chrome sich hier irgendwie "richtig" verhält, oder nur nicht unbedingt völlig falsch.
LG Karolinger
-
Hallo Karolinger_,
ich habe es gerade nicht selbst probiert, aber
meint jemand, dass man das MIME-Type Problem lösen könne, indem man nicht "foo" importiert, sondern "foo.js".
Rolf
--
sumpsi - posui - clusi-
Hallo Rolf,
danke, aber man schreibt doch ohne zusäzliche Bibliotheken o.ä. sowieso z.B. 'import foo from "./bar.js"'
Das Problem mag auch doch schon beim ersten Script mit type="module" anfangen, und nicht erst beim import.
Auch mit Suffix mjs ändert sich nichts. Und:
https://developers.google.com/web/fundamentals/primers/modules
On the Web, the file extension doesn’t really matter, as long as the file is served with the JavaScript MIME type text/javascript. The browser knows it’s a module because of the type attribute on the script element.
Und offline klappt es bislang nicht, vermutlich weil der MIME type leer oder null ist. Vielleicht geht etwas mit Blob oder Ajax, aber das wollte ich eigentlich vermeiden.
-
Hallo Karolinger_,
ja, sehe ich jetzt auch.
Mit Data-URLs kann man wohl auch was hacken - letztlich ist es aber wohl so, dass file:/// URLs von den Designern des modernen Web nicht wirklich beachtet werden. Ohne MIME-Typ kein Modul, so steht's in der Spec. PUNKT. file:-URLs? Wasndas?
Chrome hält sich dran, der Fuchs nicht.
Lösung ist dann wohl: Webserver aufsetzen oder einen Standlone-webserver verwenden. Da gibt's mehrere (sogar PHP kann weiterhelfen :) ).
Rolf
--
sumpsi - posui - clusi-
Hallo Rolf,
es sollte gerade eine Art offline-Anwendung werden.
Ein paar Sachen kan ich noch versuchen, aber die Lösung wird dann wahrscheinlich auf entweder nur Edge und FF, oder eher noch den Verzicht auf import hinauslaufen, schade.
LG
-
Liebe(r) Karolinger_,
es sollte gerade eine Art offline-Anwendung werden.
dagegen ist nichts einzuwenden.
Verzicht auf import hinauslaufen, schade.
Wieso schade? Wenn es eine Anwendung werden soll, dann darf die im Auslieferungszustand gerne gepackt sein, also alles in einer Datei enthalten (HTML/CSS/JS). Wo ist das Problem? Das Zusammenfügen?
Liebe Grüße
Felix Riesterer
-
Hallo Felix,
Wieso schade?
weil ich bei der Sache gerne, soweit mit JavaScript möglich, "modernen" und sauberen Code ausprobieren bzw. anwenden wollte. Z.B. auch, falls es sich nicht als zu unsinnig herausstellt oder das Ganze zu aufgeblasen wird, OOP, Vererbung, Klassen. Und import bietet sich da eigentlich sehr gut an.
LG
-
Liebe(r) Karolinger_,
dann mach doch! Und am Ende packst Du alles in ein HTML-Dokument und fertig. Alles tut. Alles gut. Wo ist Dein Problem?
Liebe Grüße
Felix Riesterer
-
Hallo Felix,
Und am Ende packst Du alles in ein HTML-Dokument und fertig /* */ Wo ist Dein Problem?
ich möchte das Projekt per JavaScript offline-tauglich unter Einsatz von import etc. realisieren. "alles in ein HTML-Dokument" entspricht dem nunmal gar nicht und würde dazu auch nicht die gewünschte und nötige Funktionalität ermöglichen.
Bei Verzicht auf import kann ich Scripte alternativ relativ unschöner und umfangreicher dynamisch per JavaScript einbinden, das wesentliche Problem ist aber einfach der Verzicht auf import. Dessen Notwendigkeit ich trotz aller Specs nicht so ganz nachvollziehen kann, da offline alles aus einem Verzeichnis kommt und das "eigene" HTML-Dokument bzw. der Browser eine spezifische JS-Datei vom OS anfordert und auch bekommt. Bei der Verbreitung von Chrome kann ich das Verhalten allerdings nicht ignorieren. Vielleicht schau ich mir nochmal an, ob Chrome eine vom Browser selbst gespeicherte komplette Seite anders behandelt. Aber ich fürchte, das wird auch nicht klappen.
LG
-
Hallo Karolinger_,
du musst unterscheiden zwischen Sourcecode und Objectcode.
Sourcecode ist das, was du schreibst. HTML, CSS, JS, schön alles in einzelnen Dateien, mit vielen Kommentaren.
Objectcode ist das, was dem Anwender ausgeliefert wird. Das kann komprimiert sein, uglifiziert, gebündelt, die ganze Palette. Für's Debugging generiert der Bundler/Uglifier eine .map Datei. Es gibt eine Menge Tools für solche Transformationen.
Es ist, vor allem wenn die Webseite auf einem hochbelasteten Server liegt, ineffizient, alle ES6-Module aus einzelnen Dateien zu laden. Da gehört ein Bundling-Tool in den Toolstack, das für den Produktionsserver alles in einen Topf schmeißt.
Für Dich als Entwickler ist es etwas anderes. Du möchtest viele Dateien, um die Übersicht zu behalten, um die ES6-Module zu isolieren, um granular in die Sourcecodeverwaltung einchecken zu können und um nur wenig nachladen zu müssen wenn sich was ändert.
"alles in ein HTML-Dokument" (...) würde dazu auch nicht die gewünschte und nötige Funktionalität ermöglichen.
Welche Funktionalität ist es, die Du damit nicht bekommst?
Rolf
--
sumpsi - posui - clusi-
Hallo Rolf,
unterscheiden zwischen Sourcecode und Objectcode.
egal
Es ist, vor allem wenn die Webseite auf einem hochbelasteten Server liegt, ineffizient, alle
offline
Welche Funktionalität ist es, die Du damit nicht bekommst?
dynamischer Seitenaufbau, geänderte Daten etc.
Du möchtest viele Dateien, um die Übersicht zu behalten
grundsätzlich kann ich wohl Sachen, die nicht in eine Sammlung allgemeinerer Funktionen gehören, zum Teil sinnvoll über Klassen zusammenpacken.
Ansonsten geht oder ging es mir tasächlich um den offline Einsatz von import bei Chrome.
LG
-
Hallo Karolinger_,
egal
was geht nicht
dynamischer Seitenaufbau, geänderte Daten
Ok, du willst meine Argumente nicht verstehen und hast nicht wirklich drüber nachgedacht. Bundling nimmt Dir davon nichts. Kritisch wird es nur wenn du Module per Design dynamisch nachladen musst.
Fakt bleibt, dass Chrome den mime Typ erzwingen will. Also brauchst du einen Webserver, Bundling oder streichst Chrome aus der Liste der unterstützten Browser.
ich wollte dir nur erklären, warum Bundling eine Option ist.
Rolf
--
sumpsi - posui - clusi-
Hallo,
ich wollte dir nur erklären, warum Bundling eine Option ist.
wenn bei der Auslieferung import nicht möglich ist, kann eigentlich auch gleich drauf verzichtet werden, Kommentare filtern ist mir hier nicht so wichtig sonst würde ich das per PHP machen. Aber ich kann ja nochmal schauen ob sich mit import genug Vorteile bei der Programmierung ergeben, Struktur, Übersichtlichkeit.
LG
-
Tach!
wenn bei der Auslieferung import nicht möglich ist, kann eigentlich auch gleich drauf verzichtet werden,
Das ist in ungefähr das gleiche wie: Wenn die Hochsprache nicht vom Prozessor verstanden wird, kann ich gleich in Maschinencode programmieren. - Lieber auf Komfort zu verzichten, obwohl es Tools gibt, die Komfort und die Anforderungen der Maschine verbinden können, sehe ich nicht gerade als die beste Variante an.
dedlfix.
-
Hallo,
ein gerade bei statischem import um den es hier geht hinkender Vergleich, denn es bedeutet bei dem Projekt zusätzlichen Aufwand und wohl nicht so viele Vorteile gegenüber anderen "modularen" Methoden. Bleibt neben der hier fehlenden Zeitersparnis vielleicht, ob der Code üblichen Konventionen enspricht, wartbar, nachvollziehbar, zukunftssicher ist.
Grundsätzlich bleibt es sowieso bei
Aber ich kann ja nochmal schauen ob sich mit import genug Vorteile bei der Programmierung ergeben
LG
-
Liebe(r) Karolinger_,
ein gerade bei statischem import um den es hier geht hinkender Vergleich, denn es bedeutet bei dem Projekt zusätzlichen Aufwand und wohl nicht so viele Vorteile gegenüber anderen "modularen" Methoden.
Beweis? Du machst schön Deine Import-Dinger wie üblich und beabsichtigt, und schmeißt vor dem Ausrollen einen Packer drüber. Wo ist das Problem?
Bleibt neben der hier fehlenden Zeitersparnis vielleicht, ob der Code üblichen Konventionen enspricht, wartbar, nachvollziehbar, zukunftssicher ist.
Beweis? Welche Zeitersparnis siehst Du verloren?
Liebe Grüße
Felix Riesterer
-
-
-
-
-
-
-
-
-
-
Hallo Felix,
das Ergebnis eines ES6-module fähigen Bundlers/Uglifiers ist eigentlich wieder eine .js Datei.
Dass man ein Module dann direkt ins HTML schreiben kann und nicht extern speichern muss, wusste ich gar nicht. Ist das ein Weiterentwicklungsschritt, der erst in bestimmten Browsern geht? (nein, vom IE rede ich nicht)
Gibt es Bundler bzw. Uglifier, die einen für die wohlorganisierte Entwicklung extern gehaltenen .js Schwarm vollautomatisch ins HTML einbetten?
Rolf
--
sumpsi - posui - clusi
-
-
-
-
-
-
Tach!
Dabei gibt es -anscheinend grundsätzlich bekannte- Probleme mit Chrome, einmal wohl CORS, dann womöglich mime-type.
Mit dem Zusatz
--allow-file-access-from-fileskann offenbar ein Problem umgangen werden, allerdings mag Chrome offline dann immer noch nicht:Wenn du sowieso solche "Online-Dinge" wie CORS beachten musst oder den Browser auf speziele Weise starten musst, damit der überhuapt mitspielt, kannst du auch gleich einen Mini-Webserver nehmen und den starten. Damit verhalten sich dann die Browser nicht anders als bei anderen HTTP-Zugriffen.
dedlfix.
-
Hallo,
Wenn du sowieso solche "Online-Dinge" wie CORS beachten musst oder den Browser auf speziele Weise starten musst, damit der überhuapt mitspielt, kannst du auch gleich einen Mini-Webserver nehmen und den starten.
könnte relativ zukunftssicher sein. Oder doch aktuellen FF oder Edge empfehlen, FF ginge immerhin auch als "portable". Bei Chrome frage ich mich auch, ob es sich um konsequente und sicherheitsbewußte Umsetzung der Specs handelt oder ob es auch einen 'politischen' Aspekt haben könnte, offline-Möglichkeiten etc. einzuschränken.
Grundsätzlich soll das Ganze komfortabel sein, also bleibt offenbar nur auf import zu verzichten.
LG
-
Mahlzeit,
Edge empfehlen,
Einen Browser, der in dieser Form abgekündigt ist und von Standards von allen Browsern am weitesten weg ist, als mehr zukunftssicher als Chrome anzusehen, ist recht sportlich 😉
--
42
-
-
-
Hallo,
ich habe eine Seite, die dynamisch Inhalte und Javascripte nachlädt. Für die Inhalte (XML) nehme ich XMLHttpRequests. Das funktioniert offline nur noch im Firefox.
Die Scripte lade ich (asynchron) nach, indem ich ein Script-Element erzeuge. Das funktioniert auch offline browserübergreifend.
Da meine Seite schon älter ist, kam Import nicht in Frage.
Gruß
Jürgen