Fragen zum erstellen moderner Webseiten

[Christian Wansart]

Guten Abend,

nach dem ich die letzten 2 Tage recht viel Zeit damit verbracht habe, Beiträge von Gunnar Bittersmann zu lesen, da er mir auf eine andere Frage sehr kompetent geantwortet hat. Mir sind allerdings beim Lesen der Antworten – speziell mit dem Fokus auf Accessibility – einige Fragen gekommen, die ich so nicht selbst beantworten kann.

Nehmen wir an, ich entwickle eine REST-Webanwendung und ich möchte eine moderne Webseite entwickeln, dann wird heutzutage ja gerne nach Frameworks wie Angular gegriffen. Seiten werden beim Klicken eines Links nicht vollständig neu geladen, sondern immer nur Teile, in dem die gewünschten Daten per AJAX über die REST-Schnittstelle abgefragt werden und anschließend in den DOM eingefügt.

Wenn ich mir die Beiträge zu Herzen nehme, ist dann eine solche Umsetzung überhaupt möglich? Habt ihr Tipps und Anregungen, wie man da vorgehen kann?

Ich vermute, dass ich durch das ganze Lesen etwas durcheinander gekommen bin, ich bin aber für jeden Tipp offen. Dankeschön.

Freundliche Grüße
Christian

[dedlfix]

Tach!

Nehmen wir an, ich entwickle eine REST-Webanwendung und ich möchte eine moderne Webseite entwickeln, dann wird heutzutage ja gerne nach Frameworks wie Angular gegriffen. Seiten werden beim Klicken eines Links nicht vollständig neu geladen, sondern immer nur Teile, in dem die gewünschten Daten per AJAX über die REST-Schnittstelle abgefragt werden und anschließend in den DOM eingefügt.

Das klingt sehr pauschal. Nicht jede moderne Website muss eine Single Page Application werden. Wenn man das, wofür man früher ein Prgramm geschrieben hat, als Anwendung im Browser laufen lassen möchte, dann bietet sich eine SPA an. Aber für Informationsportale à la Zeitung oder Blog reicht nach wie vor der klassische Webseitenansatz. Es kommt immer drauf an, was man erreichen möchte.

Wenn ich mir die Beiträge zu Herzen nehme, ist dann eine solche Umsetzung überhaupt möglich? Habt ihr Tipps und Anregungen, wie man da vorgehen kann?

Für welche konkrete Aufgabenstellung? "Moderne Website" reicht für die Beantwortung der Frage nicht. Da musst du schon genauer definieren, was das Ziel sein soll.

dedlfix.

[Christian Wansart]

Guten Abend,

Das klingt sehr pauschal. Nicht jede moderne Website muss eine Single Page Application werden. Wenn man das, wofür man früher ein Prgramm geschrieben hat, als Anwendung im Browser laufen lassen möchte, dann bietet sich eine SPA an. Aber für Informationsportale à la Zeitung oder Blog reicht nach wie vor der klassische Webseitenansatz. Es kommt immer drauf an, was man erreichen möchte.

Ja, das stimmt natürlich, da habe ich nicht darüber nachgedacht. Ich entwickle gerade an der Hochschule eine Software mit Laravel im Hintergrund und entsprechender REST-Schnittstelle. Da zur Synchronisation der Clients ein WebSocket offen ist, welcher nicht geschlossen werden sollte, bietet sich da eine SPA natürlich an.

Ich hatte mein Szenario im Kopf und habe andere Anwendungsfälle ganz außer Acht gelassen.

Für welche konkrete Aufgabenstellung? "Moderne Website" reicht für die Beantwortung der Frage nicht. Da musst du schon genauer definieren, was das Ziel sein soll.

Die aktuelle Aufgabenstellung die ich in dem zuvor genannten Projekt verfolge, ist eine Software zu entwickeln, welche den Professoren die Möglichkeit gibt, den Wissensstand der Studenten mittels Quizze abzufragen.

Die Professorenseite (Backend) ist nur bedingt responsive, während das Frontend für die Studenten es ist. Das Backend ist keine SPA mit Ausnahme des Starten eines Quiz, da hier ebenfalls ein WebSocket geöffnet wird.

Wichtig war es, dass der Client möglichst auf vielen Geräten funktioniert, sind dank WebSocket aber schnell an die Grenzen gestoßen, da Android erst ab 4.1 meine ich WebSockets unterstützt.

Mehr fällt mir gerade nicht ein, aber es gab noch mehr Probleme, die wir auf die eine oder andere Weise gelöst haben.

Vielen Dank für deine Antwort.

Freundliche Grüße
Christian

[dedlfix]

Tach!

Die aktuelle Aufgabenstellung die ich in dem zuvor genannten Projekt verfolge, ist eine Software zu entwickeln, welche den Professoren die Möglichkeit gibt, den Wissensstand der Studenten mittels Quizze abzufragen.

Also etwas, das mehr oder weniger in begrenztem Rahmen stattfinden soll. Ich nehme weiterhin an, das da auch keine Suchmaschinen drüberlaufen sollen. Sonst wäre der Einsatz von Javascript, vor allem zur Navigation, noch deutlich stärker zu hinterfragen.

Die Professorenseite (Backend) ist nur bedingt responsive, während das Frontend für die Studenten es ist.

Beim Backend ist es wegen des nochmal geringeren Personenkreises auch deutlich weniger ein Problem, Systemvoraussetzungen vorzuschreiben.

Wichtig war es, dass der Client möglichst auf vielen Geräten funktioniert, sind dank WebSocket aber schnell an die Grenzen gestoßen, da Android erst ab 4.1 meine ich WebSockets unterstützt.

Da gibts aber auch Projekte, die diese Kommunikation kapseln und bei Nichtvorhandensein von WebSockets auf andere Techniken zurückfallen. Jedenfalls kommt man bei einer solchen geforderten Echtzeitkommunikation kaum umhin, eine SPA zu verwenden.

Zur Frage nach der Zugänglichkeit. Man muss ja nicht alle guten Grundsätze ignorieren, aber wenn absehbar ist, dass der Zielpersonenkreis es nicht benötigen wird, dann muss man sich da auch nicht vergolden.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Zur Frage nach der Zugänglichkeit. Man muss ja nicht alle guten Grundsätze ignorieren, aber wenn absehbar ist, dass der Zielpersonenkreis es nicht benötigen wird, dann muss man sich da auch nicht vergolden.

So einfach ist das nicht. Für Einrichtungen öffentlichen Rechts (Hochschule) gilt die BITV bzw das Landes-Gleichstellungsgesetz, dass allerdings in den meisten Ländern sich am BITV orientiert. Dort ist die Barrierefreiheit/Zugänglichkeit nach Vorbild des WAI vorgeschrieben.

LG,
CK

[dedlfix]

Tach!

Für Einrichtungen öffentlichen Rechts (Hochschule) gilt die BITV bzw das Landes-Gleichstellungsgesetz, dass allerdings in den meisten Ländern sich am BITV orientiert. Dort ist die Barrierefreiheit/Zugänglichkeit nach Vorbild des WAI vorgeschrieben.

Gilt das für sämtliche Software, also auch die, die ein Fachbereich für einen berenzten Anwendungsfall aus eigener Kasse in Auftrag gib oder mit eigenen Kräften entwickelt und die nicht öffentlich ausgeschrieben werden muss?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Gilt das für sämtliche Software, also auch die, die ein Fachbereich für einen berenzten Anwendungsfall aus eigener Kasse in Auftrag gib oder mit eigenen Kräften entwickelt und die nicht öffentlich ausgeschrieben werden muss?

Die BITV (und deren Äquivalente) gelten für alle öffentlich zugänglichen Inter- und Intranet-Anwendungen - und damit trifft das m.E.n. auch auf dieses Projekt zu, die Studierenden sind ja kein geschlossener Nutzerkreis im Sinne des Gesetzestextes.

Wer das Angebot entwickelt ist irrelevant.

LG,
CK

[Christian Wansart]

Hallo Christian – toller Name grins

Die BITV (und deren Äquivalente) gelten für alle öffentlich zugänglichen Inter- und Intranet-Anwendungen - und damit trifft das m.E.n. auch auf dieses Projekt zu, die Studierenden sind ja kein geschlossener Nutzerkreis im Sinne des Gesetzestextes.

Das ist sehr interessant, denn über das Thema wurden wir nicht aufgeklärt. In keiner der Vorlesungen – trotz Fachrichtung Medieninformatik.

Freundliche Grüße
Christian

[Christian Kruse]

Hallo Namensvetter ;-)

Das ist sehr interessant, denn über das Thema wurden wir nicht aufgeklärt. In keiner der Vorlesungen – trotz Fachrichtung Medieninformatik.

Nicht böse gemeint, aber ich bin nicht überrascht…

LG,
CK

[Christian Wansart]

Hallo Christian,

Nicht böse gemeint, aber ich bin nicht überrascht…

das nehme ich dir nicht böse, wenn du wüsstest was noch so alles passiert oder eben nicht passiert. ;-)

Freundliche Grüße
Christian

[marctrix]

Hej Christian,

Gilt das für sämtliche Software, also auch die, die ein Fachbereich für einen berenzten Anwendungsfall aus eigener Kasse in Auftrag gib oder mit eigenen Kräften entwickelt und die nicht öffentlich ausgeschrieben werden muss?

Die BITV (und deren Äquivalente) gelten für alle öffentlich zugänglichen Inter- und Intranet-Anwendungen - und damit trifft das m.E.n. auch auf dieses Projekt zu, die Studierenden sind ja kein geschlossener Nutzerkreis im Sinne des Gesetzestextes.

BITV steht für Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung - BITV 2.0) und es handelt sich dabei um eine Bundesverordnung. Ihr Geltungsbereich erstreckt sich somit auch auf Bundesbehörden und nicht auf Einrichtungen der Länder.

Der genaue Wortlaut:

§ 1 Sachlicher Geltungsbereich Die Verordnung gilt für folgende Angebote der Behörden der Bundesverwaltung:

1. Internetauftritte und -angebote,
2. Intranetauftritte und -angebote, die öffentlich zugänglich sind, und
3. mittels Informationstechnik realisierte grafische Programmoberflächen, die öffentlich zugänglich sind.

Dazu gehören auch mittelbare Bundeseinrichtungen, wie z. B. Krankenkassen (unter bestimmten Voraussetzungen).

Was in den Ländern gilt, ist für jedes Bundesland extra geregelt.

Die BITV 2.0 hat mit der WAI erst mal nichts zu tun - sie ist zwar zu weiten Teilen eine fast wörtliche Übersetzunng der WCAG, es handelt sich aber dabei nicht um die offizielle Übersetzung der WCAG 2.0 (diese gibt es nämlich auch). So ist es nicht verwunderlich, dass sich begrifflich, in verschiedenen Details aber auch inhaltlich von der WCAG 2.0 unterscheidet. Außerdem fehlen ihr sämtlichen erläuternden Dokumente.

Wer das Angebot entwickelt ist irrelevant.

Richtig. Entscheidend ist, für wen etwas entwickelt wurde (öffentlich oder nicht) - bei nicht öffentlichen Angeboten mit Defiziten bei der Zugänglichkeit kann es aber arbeitsrechtliche Probleme geben - schließlich sollen Menschen mit Behinderungen auch eine online-Erfassung bedienen können. Schließlich schreiben Bundesbehörden in jede Stellenausschreibung, dass sich auch Menschen mit Behidnerungen bewerben dürfen.

Das klingt dann z. B. so:

"Schwerbehinderte Menschen werden bei gleicher Eignung, Befähigung und fachlicher Leistung besonders berücksichtigt (SGB IX)."

Marc

[Christian Kruse]

Hallo marctrix,

Gilt das für sämtliche Software, also auch die, die ein Fachbereich für einen berenzten Anwendungsfall aus eigener Kasse in Auftrag gib oder mit eigenen Kräften entwickelt und die nicht öffentlich ausgeschrieben werden muss?

Die BITV (und deren Äquivalente) gelten für alle öffentlich zugänglichen Inter- und Intranet-Anwendungen - und damit trifft das m.E.n. auch auf dieses Projekt zu, die Studierenden sind ja kein geschlossener Nutzerkreis im Sinne des Gesetzestextes.

BITV steht für Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung - BITV 2.0) und es handelt sich dabei um eine Bundesverordnung. Ihr Geltungsbereich erstreckt sich somit auch auf Bundesbehörden und nicht auf Einrichtungen der Länder.

Bitte immer alles lesen, was ich schreibe. Ich schrieb „die BITV (und deren Äquivalente)” und bezog mich dabei auf mein vorhergehendes Posting, in dem ich eklärte: „für Einrichtungen öffentlichen Rechts (Hochschule) gilt die BITV bzw das Landes-Gleichstellungsgesetz, dass allerdings in den meisten Ländern sich am BITV orientiert.” BITV - öffentliche Einrichtungen des Bundes, Landes-Gleichstellungsgesetz - öffentliche Einrichtungen des Landes.

Die BITV 2.0 hat mit der WAI erst mal nichts zu tun

Bitte lesen, was ich schrieb und keine Worte in den Mund legen: „nach Vorbild des WAI.”

Wer das Angebot entwickelt ist irrelevant.

Richtig. Entscheidend ist, für wen etwas entwickelt wurde (öffentlich oder nicht) - bei nicht öffentlichen Angeboten mit Defiziten bei der Zugänglichkeit kann es aber arbeitsrechtliche Probleme geben - schließlich sollen Menschen mit Behinderungen auch eine online-Erfassung bedienen können. Schließlich schreiben Bundesbehörden in jede Stellenausschreibung, dass sich auch Menschen mit Behidnerungen bewerben dürfen.

Richtig.

LG,
CK

[marctrix]

Hej Christian,

Die BITV 2.0 hat mit der WAI erst mal nichts zu tun

Bitte lesen, was ich schrieb

Habe ich - wenn ich mich recht erinnere standen da so Formulierungen wie mMn o.ä.

und keine Worte in den Mund legen: „nach Vorbild des WAI.”

War aus dem Kopf "zitiert", wollte mit meinem posting deines nur bekräftigen und ergänzen. Hätte man so vielleicht auch verstehen können, aber nicht müssen, daher mal der Hinweis: wenn du mir Wohlwollen unterstellst, wirst du in den meisten Fällen richtig liegen

;-)

Marc

[Christian Kruse]

Hallo marctrix,

War aus dem Kopf "zitiert", wollte mit meinem posting deines nur bekräftigen und ergänzen.

Klang nicht so 😉

Hätte man so vielleicht auch verstehen können, aber nicht müssen, daher mal der Hinweis: wenn du mir Wohlwollen unterstellst, wirst du in den meisten Fällen richtig liegen

Ich habe dir keine Böswilligkeit unterstellt, allerdings kann ich es sehr schlecht haben wenn man mir Worte in den Mund legt. Seis drum, hat sich ja aufgeklärt 😀

LG,
CK

[marctrix]

Hej Christian,

Hallo marctrix,

War aus dem Kopf "zitiert", wollte mit meinem posting deines nur bekräftigen und ergänzen.

Klang nicht so 😉

Glaube ich - aber wenn du noch mal nachliest, glaube ich, findest du keine Stelle, wo ich dir widerspreche. Auch das mit WAI. Wollte nur noch mal deutlich machen, dass BITV und WCAG trotz ihrer Verwandschaft zwei Paar Schuhe sind. Du weißt das, das weiß ich. Aber für jemand anders schien mir Deine Formulierung zu knapp/nicht eindeutig genug.

Hätte man so vielleicht auch verstehen können, aber nicht müssen, daher mal der Hinweis: wenn du mir Wohlwollen unterstellst, wirst du in den meisten Fällen richtig liegen

Ich habe dir keine Böswilligkeit unterstellt, allerdings kann ich es sehr schlecht haben wenn man mir Worte in den Mund legt. Seis drum, hat sich ja aufgeklärt 😀

Gut, dass wir drüber geredet haben! Ich fände es schade, wenn ich bei Dir in die Schublade mit dem Aufkleber "Nörgler" kommen würde. ;-)

Marc

[Christian Kruse]

Hallo marctrix,

Aber für jemand anders schien mir Deine Formulierung zu knapp/nicht eindeutig genug.

Das ist nachvollziehbar für mich, danke für die Erklärung.

Gut, dass wir drüber geredet haben! Ich fände es schade, wenn ich bei Dir in die Schublade mit dem Aufkleber "Nörgler" kommen würde. ;-)

Da musst du keine Angst haben!

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Ich fände es schade, wenn ich bei Dir in die Schublade mit dem Aufkleber "Nörgler" kommen würde. ;-)

Da musst du keine Angst haben!

Ich hab davor keine Angst. SCNR.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Ich hab davor keine Angst. SCNR.

Wäre mir gar nicht aufgefallen, wenn du das nicht erwähnt hättest duck 😉

LG,
CK

[Linuchs]

Seiten werden beim Klicken eines Links nicht vollständig neu geladen, sondern immer nur Teile, in dem die gewünschten Daten per AJAX ...

Noch vor zwei, drei Jahren hat man hier regelmäßig die Mahnung eingefangen, dass der Leser Javascript (JS) abgeschaltet haben könnte. Also (auch) AJAX als luxuriöses "nice to have".

Doch Javascript scheint nun zur Pflicht geworden zu sein, ich kann auch im FF und in der Opera nicht mehr die Stelle finden, um JS abzuschalten.

Ich als "uralter Hase" habe noch die uralten Hemmungen und Warnungen in den Knochen und verwende Javascript als Luxus für geschlossene Benutzergruppen.

Da die Browser aber nicht mehr erlauben, JS abzuschalten, kann ich meine Seiten nicht mehr "ohne" testen und so mancher Ausrutscher gegen meine Prinzipien mögen durchrutschen.

Früher wurden hier auch Warnungen gegen das angeblich abschaltbare CSS ausgestoßen. Also nicht immer zukunfstorientiert und sehr furchtsam, die Ratschläge hier...

Hat sich inzwischen extrem gewandelt, die neuesten Features werden empfohlen. Da darf kein Leser mehr einen Browser haben, der älter ist als ein paar Monate. Von der Web-Steinzeit ins UFO-Zeitalter sozusagen.

Nach meinem "uralten" Empfinden wäre ja die Übertragung von möglichst wenig traffic zu bevorzugen. Scheint aber - trotz Funk-Engpässe - kein Kriterium mehr zu sein.

Konkret: Der Begriff "modern" deckt sich sprachlich mit "modern", also dem Dahinsiechen. Finde deinen eigenen Stil ständig neu. Wer will schon eine Webseite, die aussieht wie alle anderen?

Linuchs

[Christian Wansart]

Guten Abend Linuchs,

wo du es gerade ansprichst, mein Projekt würde ohne JavaScript nicht funktionieren. Das ist natürlich ärgerlich, aber ganz ohne ginge es nicht.

Ja du hast Recht, der Firfox hat das vor einigen Versionen entfernt. Etwas fraglich, wenn du mich fragst, aber mit Addons wie NoScript ist es noch tastbar. Ich bin mir bei sowas aber nicht sicher, was für Funktionen ich drin lasse, und welche nicht, da es manches gibt, was ohne JS einfach nicht geht. 😕

Freundliche Grüße
Christian

[Robert B.]

Moin,

wo du es gerade ansprichst, mein Projekt würde ohne JavaScript nicht funktionieren. Das ist natürlich ärgerlich, aber ganz ohne ginge es nicht.

Es sagt ja (mittlerweile) auch keiner etwas, wenn es sinnvoll eingesetzt ist.

Ja du hast Recht, der Firfox hat das vor einigen Versionen entfernt.

In about:config gibt es den Punkt javascript.enabled.

Etwas fraglich, wenn du mich fragst, aber mit Addons wie NoScript ist es noch tastbar. Ich bin mir bei sowas aber nicht sicher, was für Funktionen ich drin lasse, und welche nicht, da es manches gibt, was ohne JS einfach nicht geht. 😕

Deshalb habe ich in meinem Firefox NoScript durch RequestPolicy (Continued) ersetzt.

Viele Grüße
Robert

[Christian Wansart]

Guten Abend,

Es sagt ja (mittlerweile) auch keiner etwas, wenn es sinnvoll eingesetzt ist.

Das sieht in meinem IT-Bekanntenkreis etwas anders aus. Mich hat JavaScript auch lange gestört, weil es häufig mehr genervt hat, aber mittlerweile ist es eben nicht mehr umgänglich.

Ja du hast Recht, der Firfox hat das vor einigen Versionen entfernt.

In about:config gibt es den Punkt javascript.enabled.

Oh, dann muss ich mich entschuldigen, ich hatte gedacht, sie haben es vollständig entfernt. Danke für die Information. Ich habe dazu noch einen Artikel gefunden.

Freundliche Grüße
Christian

[Der Martin]

Hallo,

Es sagt ja (mittlerweile) auch keiner etwas, wenn es sinnvoll eingesetzt ist. Das sieht in meinem IT-Bekanntenkreis etwas anders aus. Mich hat JavaScript auch lange gestört, weil es häufig mehr genervt hat, aber mittlerweile ist es eben nicht mehr umgänglich.

das sehe ich anders: Es gibt zwar ein paar wenige Internet-Auftritte, bei denen man ohne JS ziemlich alt aussieht. Aber dennoch ist "Javascript aus" bei mir immer noch die Standardeinstellung, und nur für ein paar wenige Sites gibt's eine Ausnahme.
Das trägt wesentlich zu einem entspannteren Surf-Erlebnis bei.

In about:config gibt es den Punkt javascript.enabled.

Die Mozilla Foundation verfolgt wohl schon lange den Trend, die wirklich sinnvollen Einstellungen nicht mehr übers GUI, sondern nur noch über about:config zugänglich zu machen. Wenn ich da nur an browser.urlbar.trimURLs denke, damit die Adresszeile nicht verunstaltet wird.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Aber dennoch ist "Javascript aus" bei mir immer noch die Standardeinstellung, und nur für ein paar wenige Sites gibt's eine Ausnahme.
Das trägt wesentlich zu einem entspannteren Surf-Erlebnis bei.

Willst du nicht lieber JavaScript anlassen und einen Ad-Blocker verwenden?

LLAP 🖖

PS: Ich glaube, ich kenne die Antwort. ;-)

[Der Martin]

Moin,

Aber dennoch ist "Javascript aus" bei mir immer noch die Standardeinstellung, und nur für ein paar wenige Sites gibt's eine Ausnahme.
Das trägt wesentlich zu einem entspannteren Surf-Erlebnis bei.

Willst du nicht lieber JavaScript anlassen und einen Ad-Blocker verwenden?

das sind doch zwei grundverschiedene Dinge. Einen Ad-Blocker habe ich selbstverständlich auch, und zwar auf DNS-Basis: Mein lokaler DNS löst anhand einer Liste mit Hunderten von Einträgen die Domain- und Hostnamen, die als Ad-Server bekannt sind, zu 127.0.0.1 auf. Außerdem auch alle, die mir im Zusammenhang mit Google Analytics und ähnlichen Schnüffeldiensten bekannt sind.

Oder meintest du so ein Schweizer Messer wie etwa die bekannte Firefox-Extension NoScript, die ja auf Wunsch auch viele andere aktive Inhalte blockiert (Sound, Video, Flash)? Das wäre in der Tat eine Alternative. Aber warum?

So long,
 Martin

[Gunnar Bittersmann]

@@Linuchs

Noch vor zwei, drei Jahren hat man hier regelmäßig die Mahnung eingefangen, dass der Leser Javascript (JS) abgeschaltet haben könnte. Also (auch) AJAX als luxuriöses "nice to have".

Doch Javascript scheint nun zur Pflicht geworden zu sein, ich kann auch im FF und in der Opera nicht mehr die Stelle finden, um JS abzuschalten.

Es geht gar nicht mal um die paar wenigen, die JavaScript deaktivieren. Jeder ist ohne JavaScript, solange das Script nicht geladen wurde.^[1]

Serverseitiges Rendern als Grundfunktionalität und AJAX als progressive enhancement ist durchaus sinnvoll.

Früher wurden hier auch Warnungen gegen das angeblich abschaltbare CSS ausgestoßen.

Eine Webseite sollte auch ohne CSS funktionieren. Andernfalls wäre sie wohl auch nicht barrierefrei.

Nach meinem "uralten" Empfinden wäre ja die Übertragung von möglichst wenig traffic zu bevorzugen. Scheint aber - trotz Funk-Engpässe - kein Kriterium mehr zu sein.

Für manche schon. offline first ist ein Ansatz, der mit Dingen wie progressive web apps (Service Workers) und Hoodie verfolgt wird.

LLAP 🖖

---

1. Ist mir glatt entfallen, von wem ich das gehört habe. Jake Archibald? Tim Kadlec? ↩︎

[marctrix]

Hej Christian,

@Gunnar Bittersmann schrieb:

Früher wurden hier auch Warnungen gegen das angeblich abschaltbare CSS ausgestoßen.

Eine Webseite sollte auch ohne CSS funktionieren. Andernfalls wäre sie wohl auch nicht barrierefrei.

So isses. Webseiten müssen sowohl bei abgeschaltetem CSS, als auch mit einem User-CSS (z. B. geänderte Farben bei Blendempfindlichkeit) Sinn machen.

Für Viele große Webseiten gibt es ja eine ganze Reihe an User-Stylesheets, die das Aussehen ändern - z. B. als Browser-PlugIns.

CSS ist immer nur ein Design-Vorschlag für Menschen, die sich nicht für jede Webseite ihr eigenens CSS schreiben wollen. De facto fast jeder - aber auf das "fast" kommt es eben an. Sollte man sich immer wieder mal bewusst machen.

Marc

[Auge]

Hallo

Seiten werden beim Klicken eines Links nicht vollständig neu geladen, sondern immer nur Teile, in dem die gewünschten Daten per AJAX ...

Noch vor zwei, drei Jahren hat man hier regelmäßig die Mahnung eingefangen, dass der Leser Javascript (JS) abgeschaltet haben könnte. Also (auch) AJAX als luxuriöses "nice to have".

Meinem Empfinden nach ist es zwar um einiges länger als zwei oder drei Jahre her, dass diese Warnung hier oft kam. Ja, es gab eine Zeit, in der JS meist für unnützen und nervenden Mumpitz genutzt und wurde, heute ist dieser Anteil gesunken. Neben den heute in den Vordergrund getretenen Privacy-Bedenken ist der nicht mehr so starke, aber immer noch vorhandene Nervfaktor wohl der Grund, dessentwegen Nutzer JS abschalten. Andererseits gibt es Clients, die schlicht und ergreifend kein JS ausführen können und so von der Nutzung eines Angebots ausgeschlossen sind. Um diese Nutzergruppen (zu denen z.B. auch Bots, z.B. von Suchmaschinen, gehören) nicht auszuschließen, sollte eine Website auch ohne JS benutzbar sein. Das gilt auch heute noch.

Dass das für eine webbasierte Anwendung nur bedingt bis garnicht gilt, steht auf einem anderen Blatt. Und hier, so hat sich ja herausgestellt, geht es um eine webbasierte Anwendung, neudeutsch auch „Webapp“. Also steht das Thema wohl nicht mehr zur Debatte.

Doch Javascript scheint nun zur Pflicht geworden zu sein, ich kann auch im FF und in der Opera nicht mehr die Stelle finden, um JS abzuschalten.

In einem solchen Fall kann man JS als Voraussetzung definieren und kommt hetuzutage nur noch selten drum herum.

Da die Browser aber nicht mehr erlauben, JS abzuschalten, kann ich meine Seiten nicht mehr "ohne" testen und so mancher Ausrutscher gegen meine Prinzipien mögen durchrutschen.

Mit Addons und Einstellungsmöglichkeiten abseits der GUI geht das (zumindest bei Firefox) auch heute noch, wie schon gesagt wurde.

Früher wurden hier auch Warnungen gegen das angeblich abschaltbare CSS ausgestoßen. Also nicht immer zukunfstorientiert und sehr furchtsam, die Ratschläge hier...

Es gibt Clients, die mit CSS nichts anfangen können. Eine Website so aufzubauen, dass sie ohne CSS nicht zugänglich ist, also nicht funktioniert, ist ein No Go. Das hat nichts mit „nicht … zukunfstorientiert“ oder „sehr furchtsam“ zu tun. Auch hier gelten, abgesehen von den hier vorhandenen gesetzlichen Vorgaben, für Programme etwas andere Maßstäbe.

Hat sich inzwischen extrem gewandelt, die neuesten Features werden empfohlen. Da darf kein Leser mehr einen Browser haben, der älter ist als ein paar Monate. Von der Web-Steinzeit ins UFO-Zeitalter sozusagen.

Wo werden die neuesten Features empfohlen, ohne zumindest, wenn es denn notwendig ist, auf nicht umfassende Unterstützung hinzuweisen?

Nach meinem "uralten" Empfinden wäre ja die Übertragung von möglichst wenig traffic zu bevorzugen. Scheint aber - trotz Funk-Engpässe - kein Kriterium mehr zu sein.

Die Vermeidung unnötigen Traffics – was auch immer das im Einzelfall heißt – ist hier fast täglich Thema. Wenn du das nicht mitbekommst, scheinst du hier nur sehr selektiv zu lesen.

Es ist ja nicht so, dass hier immer wieder zu Optimierungen und zur Verwendung moderner Techniken zur Minimierung von Traffic geraten wird oder z.B. ich mich nicht alle X Monate ^[1] über megabyteweise nachzuladende JS-Dateien aus den unterschiedlichsten Quellen aufrege, ohne die verschiedene Websites selbst die grundlegenden Informationen nicht herausrücken, also schlicht vollflächig weiß bleiben. Gerne Fälle, in denen mit JS nachgebaut wird, was HTML von sich aus macht (Stichwort: unnötiger Traffic).

Tschö, Auge

---

1. Setze bitte eine niedrige einstellige Zahl für X ein. ↩︎

[Der Martin]

n'Abend,

Noch vor zwei, drei Jahren hat man hier regelmäßig die Mahnung eingefangen, dass der Leser Javascript (JS) abgeschaltet haben könnte. Also (auch) AJAX als luxuriöses "nice to have".

Meinem Empfinden nach ist es zwar um einiges länger als zwei oder drei Jahre her, dass diese Warnung hier oft kam. Ja, es gab eine Zeit, in der JS meist für unnützen und nervenden Mumpitz genutzt und wurde, heute ist dieser Anteil gesunken.

ja, das ist er wohl, aber noch lange nicht auf ein Niveau nahe Null. Ich finde, dass JS immer noch oft für Effekte genutzt wird, die den Nutzer eher nerven als ihm helfen.

Neben den heute in den Vordergrund getretenen Privacy-Bedenken ist der nicht mehr so starke, aber immer noch vorhandene Nervfaktor wohl der Grund, dessentwegen Nutzer JS abschalten.

Exakt.

Doch Javascript scheint nun zur Pflicht geworden zu sein, ich kann auch im FF und in der Opera nicht mehr die Stelle finden, um JS abzuschalten.

Mag sein, dass man die Einstellmöglichkeit aus dem GUI entfernt hat; in den Einstellungen unter about:config (Firefox) oder opera:config (Opera) gibt es sie aber noch.

In einem solchen Fall kann man JS als Voraussetzung definieren und kommt hetuzutage nur noch selten drum herum.

Nein. Veto.

Früher wurden hier auch Warnungen gegen das angeblich abschaltbare CSS ausgestoßen. Also nicht immer zukunfstorientiert und sehr furchtsam, die Ratschläge hier...

Nicht immer zukunftsorientiert, aber oft auch bewusst konservativ.

Hat sich inzwischen extrem gewandelt, die neuesten Features werden empfohlen. Da darf kein Leser mehr einen Browser haben, der älter ist als ein paar Monate. Von der Web-Steinzeit ins UFO-Zeitalter sozusagen.

Das ist Unsinn.

So long,
 Martin

[Auge]

Hallo

In einem solchen Fall kann man JS als Voraussetzung definieren und kommt hetuzutage nur noch selten drum herum.

Nein. Veto.

Bei einem Programm soll die Ausführung von Programmcode nicht vorausgesetzt werden können? Komisch.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

In einem solchen Fall kann man JS als Voraussetzung definieren und kommt hetuzutage nur noch selten drum herum.

Nein. Veto.

Bei einem Programm soll die Ausführung von Programmcode nicht vorausgesetzt werden können? Komisch.

Der Programmcode kann ja auf dem Server ausgeführt werden und dessen Ergebnis als HTML-Dokument an den Client zurückgeschickt werden. Ausführung auf dem Client als progressive enhancement.

Dann kann doppelte Programmiereung bedeuten; muss aber nicht, wenn serverseitig und clientseitig dieselbe Programmiersprache verwendet wird: JavaScript.

LLAP 🖖

[Auge]

Hallo

In einem solchen Fall kann man JS als Voraussetzung definieren und kommt hetuzutage nur noch selten drum herum.

Nein. Veto.

Bei einem Programm soll die Ausführung von Programmcode nicht vorausgesetzt werden können? Komisch.

Der Programmcode kann ja auf dem Server ausgeführt werden und dessen Ergebnis als HTML-Dokument an den Client zurückgeschickt werden.

Kann ja. Bei einem webbasierten Programm, und darum ging es mir bei der ursprünglichen Aussage ^[1], kann ich aber dennoch im Einzelfall voraussetzen, dass JavaScript benutzt wird. Deshalb verstehe ich das Veto von @Der Martin nicht.

Tschö, Auge

---

1. Der ganz oben zitierte und von mir stammende Satz bezog sich auf meine Aussage im Ursprungsposting, dass es in diesem Thread um eine Webapp und nicht um eine Website geht. Das mag durch das im Ursprungsposting dazwischenliegende Zitat von Linuchs verloren gegangen sein. ↩︎

[Der Martin]

Hi,

Bei einem webbasierten Programm, und darum ging es mir bei der ursprünglichen Aussage [^1], kann ich aber dennoch im Einzelfall voraussetzen, dass JavaScript benutzt wird.

nein, du kannst zwar als Entwickler einer Web-App definieren, dass diese wohl Javascript braucht, aber du kannst nicht voraussetzen, dass es tatsächlich zur Verfügung steht.

Deshalb verstehe ich das Veto von @Der Martin nicht.

Deine Aussage, dass man Javascript also veraussetzen könne, stand aber als direkte Antwort auf Linuchs' Feststellung, dass das Deaktivieren von JS in neueren Firefox- und Opera-Versionen nicht mehr so einfach sei wie früher.
Ich habe dich daher so verstanden, als wolltest du sagen: Wenn das Deaktivieren so schwierig geworden ist, kann man folglich davon ausgehen, dass das keiner tut. Dagegen ging mein Veto.

So long,
 Martin

[Auge]

Hallo

Bei einem webbasierten Programm, und darum ging es mir bei der ursprünglichen Aussage [^1], kann ich aber dennoch im Einzelfall voraussetzen, dass JavaScript benutzt wird.

nein, du kannst zwar als Entwickler einer Web-App definieren, dass diese wohl Javascript braucht, aber du kannst nicht voraussetzen, dass es tatsächlich zur Verfügung steht.

Das ist Nitpicking. Vertreibe ich ein Perl-Programm, setze ich voraus, dass zu dessen Ausführung auf dem Zielsystem ein Perl-Interpreter installiert ist. Schreibe ich eine Web-App, für deren Ausführung ich JavaScript als Voraussetzung definiere, ist das natürlich meine Definition. Wo JS nicht ausgeführt werden kann, läuft das Programm eben nicht, wer es ausführen will, dem muss eben JS ausführbar zur Verfügung stehen.

Deshalb verstehe ich das Veto von @Der Martin nicht.

Deine Aussage, dass man Javascript also veraussetzen könne, stand aber als direkte Antwort auf Linuchs' Feststellung, dass das Deaktivieren von JS in neueren Firefox- und Opera-Versionen nicht mehr so einfach sei wie früher.

… und bezog sich, wie ich in der Fußnote meines vorherigen Postings erklärte, auf meinen letzten Satz vor dem von Linuchs stammenden Zitat.

Ich habe dich daher so verstanden, als wolltest du sagen: Wenn das Deaktivieren so schwierig geworden ist, kann man folglich davon ausgehen, dass das keiner tut.

Nee, das wollte ich damit überhaupt nicht aussagen. Abgesehen von den mittlerweile gut versteckten Einstellungsmöglichkeiten in den Browsern gibt es dazu ja das eine oder andere Addon/Plugin, das es sogar einfacher macht, JS selektiv aus- und einzuschalten.

Tschö, Auge

[Der Martin]

Hi,

nein, du kannst zwar als Entwickler einer Web-App definieren, dass diese wohl Javascript braucht, aber du kannst nicht voraussetzen, dass es tatsächlich zur Verfügung steht.

Das ist Nitpicking.

wenn es dir so erscheint, hast du die Aussage missverstanden.

Vertreibe ich ein Perl-Programm, setze ich voraus, dass zu dessen Ausführung auf dem Zielsystem ein Perl-Interpreter installiert ist.

Richtig, das ist dann Voraussetzung für die Nutzung des Programms.

Aber du kannst unabhängig von diesem Projekt nicht voraussetzen, "dass ja sowieso jeder Perl hat". Das war die Art von "voraussetzen", die ich verstanden und gemeint habe. Also voraussetzen im Sinne von "als selbstverständlich annehmen".

Ich habe dich daher so verstanden, als wolltest du sagen: Wenn das Deaktivieren so schwierig geworden ist, kann man folglich davon ausgehen, dass das keiner tut.

Nee, das wollte ich damit überhaupt nicht aussagen. Abgesehen von den mittlerweile gut versteckten Einstellungsmöglichkeiten in den Browsern gibt es dazu ja das eine oder andere Addon/Plugin, das es sogar einfacher macht, JS selektiv aus- und einzuschalten.

Genau. Dann sind wir uns in dem Punkt wenigstens einig.

So long,
 Martin

[Auge]

Hallo

nein, du kannst zwar als Entwickler einer Web-App definieren, dass diese wohl Javascript braucht, aber du kannst nicht voraussetzen, dass es tatsächlich zur Verfügung steht.

Das ist Nitpicking.

wenn es dir so erscheint, hast du die Aussage missverstanden.

Vertreibe ich ein Perl-Programm, setze ich voraus, dass zu dessen Ausführung auf dem Zielsystem ein Perl-Interpreter installiert ist.

Richtig, das ist dann Voraussetzung für die Nutzung des Programms.

Aber du kannst unabhängig von diesem Projekt nicht voraussetzen, "dass ja sowieso jeder Perl hat".

Hier geht es aber nicht um Web-Apps im Allgemeinen, sondern um den konkreten Fall. Ich weiß nicht, ob @Christian Wansart in seinem Programm JS zwingend voraussetzen wird. Die Beschreibung der gewünschten Funktionen lässt mich das nur vermuten. Wenn er für sein Programm JS voraussetzen sollte, ist daran nichts auszusetzen, auch wenn Linuchs schreibt, hier würde soetwas ungern gesehen oder sogar abgelehnt, was nicht stimmt.

Das war die Art von "voraussetzen", die ich verstanden und gemeint habe.

Gut, das wollte ich aber nicht aussagen.

Also voraussetzen im Sinne von "als selbstverständlich annehmen".

Naja; eben nicht. Ich doch nicht!

Tschö, Auge

[Christian Wansart]

Guten Abend,

Hier geht es aber nicht um Web-Apps im Allgemeinen, sondern um den konkreten Fall. Ich weiß nicht, ob @Christian Wansart in seinem Programm JS zwingend voraussetzen wird. Die Beschreibung der gewünschten Funktionen lässt mich das nur vermuten. Wenn er für sein Programm JS voraussetzen sollte, ist daran nichts auszusetzen, auch wenn Linuchs schreibt, hier würde soetwas ungern gesehen oder sogar abgelehnt, was nicht stimmt.

Da ich im Projekt WebSockets verwende, bin ich darauf angewiesen, insofern ist JavaScript eine Voraussetzung zum Ausführen.

Freundliche Grüße
Christian

[Gunnar Bittersmann]

@@Auge

Bei einem webbasierten Programm […] kann ich aber dennoch im Einzelfall voraussetzen, dass JavaScript benutzt wird.

Im Einzelfall, ja. Oft wird das aber unnötigerweise zur Regel gemacht.

dass es in diesem Thread um eine Webapp und nicht um eine Website geht.

Bei Webapps wird clientseitiges Rendering überbewertet, IMHO. Auch interaktive Webanwendungen kommen mitunter auch gut mit serverseitigem Rendering aus.

Klar gibt es Anwendungen, die ausschließlich clientseitig laufen können. Das wären die o.g. Einzelfälle.

LLAP 🖖

[1unitedpower]

Bei Webapps wird clientseitiges Rendering überbewertet, IMHO. Auch interaktive Webanwendungen kommen mitunter auch gut mit serverseitigem Rendering aus.

Exklusiv serverseitges Rendering hat einige Nachteile, die sich nicht so einfach unter den Teppich kehren lassen:

• Man erzielt damit keine guten Reaktionszeiten. Je nach Umfang des Projekts ist es schon eine Herausforderung die Antwortzeiten unter 100ms zu halten. Bei besonders interaktiven Anwendungen summiert sich das schnell auf.
• Netzwerk-Fehler werden in der Regel zu spät erkannt. Wenn ich ein Formular absende und keine bestehende Internetverbindung habe, erhalte ich nur eine unzufriedenstellende Browser-Fehlermeldung. Mit einer Manifest-Datei kann man dem zugegebenermaßen entgegen wirken.
• Für jede Zustandsänderung des GUI eine eigene Seite anzufordern ist Verschwendung von Energie und Datenvolumen. Insbesondere, weil man nur schwer Gebrauch von HTTP-Caching machen kann.

In so manchen Fällen würde ich das nicht „modern“ nennen, sondern Bequemlichkeit der Entwickler wird über Bedürfnisse der Nutzer gestellt. WTF :-(

Das gilt imho. auch für clientseitiges Rendering ;) Bei interaktiven Seiten kommt man weder ohne das Eine noch ohne das Andere aus. Server- und clientseitiges Rendering ist die (idealtypische) Devise.

[1unitedpower]

Noch vor zwei, drei Jahren hat man hier regelmäßig die Mahnung eingefangen, dass der Leser Javascript (JS) abgeschaltet haben könnte. Also (auch) AJAX als luxuriöses "nice to have".

Es gab eine JavaScript-Blase, da wurde sehr hitzig diskutiert, ob serverseitiges Rendering wirklich noch gebraucht wird. Es ist dann aber ziemlich schnell eine Phase der Ernüchterung eingetreten, weil die Argumente, die dafür sprechen, einfach zu stark wiegen: Suchmaschinen-Freundlichkeit, Page-Speed, Tor-Browser... Es hat sich hier also im Wesentlichen ein Konsens eingestellt. Das Hauptargument der Verweigerer waren enorme Entwicklungszeiten und -kosten. Mit den Werkzeugen, die wir heute haben, verliert dieses Argument immer mehr an Bedeutung. Die Debatte hat sich verlagert, die Frage ist nicht mehr ob serverseitiges Rendering, sondern wie. Und am einfachsten geht es mit isomorphen JavaScript. Mit einem Redux/React-Stack kann man beispielsweise den selben Code für server- und clientseitges Template-Rendering wiederverwenden – fast ohne Mehraufwand.

[Frameworknutzer]

Noch vor zwei, drei Jahren hat man hier regelmäßig die Mahnung eingefangen, dass der Leser Javascript (JS) abgeschaltet haben könnte. Also (auch) AJAX als luxuriöses "nice to have".

JavaScript ist aus versch. Gründen "unzuverlässig". Dass JavaScript komplett abgeschaltet ist, ist mittlerweile zu vernachlässigen. Die damals wie heute relevante Frage ist wie sich die Seite verhält, wenn JavaScript zwar aktiviert ist sich darin aber Fehler verstecken oder Teile im verwendeten Browser nicht funktionieren.

Ich als "uralter Hase" habe noch die uralten Hemmungen und Warnungen in den Knochen und verwende Javascript als Luxus für geschlossene Benutzergruppen.

Eine komplexe Logik mit JS zu bauen und zu erwarten, dass diese auch komplett fehlerfrei funktioniert: Das ist Luxus.

Früher wurden hier auch Warnungen gegen das angeblich abschaltbare CSS ausgestoßen. Also nicht immer zukunfstorientiert und sehr furchtsam, die Ratschläge hier...

Da ging es weniger darum dass viele User CSS abschalten. Das war nur in einigen Browsern für Poweruser möglich.

Es ging es eher darum HTML und CSS "richtig" einzusetzen. Semantische Informationen im HTML unterzubringen. Zum Beispiel eine Überschrift mit <H1> zu markieren als bloß ein <DIV> mit font-weight und font-size größer zu machen.

Hat sich inzwischen extrem gewandelt, die neuesten Features werden empfohlen.

Man kann (und sollte wie ich finde) die neuesten Features verwenden -- wenn der Browser sie unterstützt.

Nach meinem "uralten" Empfinden wäre ja die Übertragung von möglichst wenig traffic zu bevorzugen. Scheint aber - trotz Funk-Engpässe - kein Kriterium mehr zu sein.

Das ist immer noch ein wichtiges Kriterium. Nur wächst die Größe von Websites aus verschiedenen Gründen immer weiter an. Das sind letztlich Fehler in Konzept, Design und Umsetzung einer Site.

Ein Frameworknutzer

[Gunnar Bittersmann]

@@Frameworknutzer

Hat sich inzwischen extrem gewandelt, die neuesten Features werden empfohlen.

Man kann (und sollte wie ich finde) die neuesten Features verwenden -- wenn der Browser sie unterstützt.

Man kann (und sollte wie ich finde) die neuesten Features verwenden – auch wenn noch kaum ein Browser sie unterstützt.

„Wenn man [die Grundfunktionalität erstellt] hat, kann man seine Zeit damit verbringen, mit den neusten und großartigsten Browsertechnologien zu experimentieren; sicher in dem Wissen, dass selbst wenn diese noch nicht weitgehend unterstützt werden, man den Fallback ja bereits hat. […]
Webseiten müssen nicht in jedem Browser gleich aussehen.
Wenn man das so akzeptiert, […] kann man seine Zeit darin investieren sicherzustellen, dass die Kernfunktion dessen, was man baut, überall funktioniert, und gleichzeitig in fähigeren Browsern die bestmögliche Nutzungserfahrung zu bieten.“
—Jeremy Keith

LLAP 🖖

[Gunnar Bittersmann]

@@Christian Wansart

Beiträge von Gunnar Bittersmann zu lesen, da er mir auf eine andere Frage sehr kompetent geantwortet hat.

Oh, danke für die Blumen.

Nehmen wir an, ich entwickle eine REST-Webanwendung und ich möchte eine moderne Webseite entwickeln, dann wird heutzutage ja gerne nach Frameworks wie Angular gegriffen.

Ja, *seufz*. In so manchen Fällen würde ich das nicht „modern“ nennen, sondern Bequemlichkeit der Entwickler wird über Bedürfnisse der Nutzer gestellt. WTF :-(

Seiten werden beim Klicken eines Links nicht vollständig neu geladen, sondern immer nur Teile, in dem die gewünschten Daten per AJAX über die REST-Schnittstelle abgefragt werden und anschließend in den DOM eingefügt.

Das kann etwas schneller sein. An einer Stelle, wo man die Schnelligkeit evtl. gar nicht mal braucht. Das erkauft man sich damit, dass man den Nutzer beim initialen Aufruf der Webseite ewig lange warten lässt, bis das ganze Framework geladen ist. Für mich oft keine gute Abwägung.

Im Übrigen denke ich hier wie Peter-Paul Koch, dass Angular u.ä. nichts für Frontend-Entwickler ist; „one could describe it as a front-end framework by non-front-enders for non-front-enders.“

Aber dir ging es ja um Barrierefreiheit. Eine single page application kann durchaus barrierefrei sein – wenn sie denn richtig implementiert wird. Bspw. Bereiche mit aria-live gekennzeichnet werden, wo sich Inhalte dynamisch ändern. Es fließt auch zunehmend Wissen über Barrierefreiheit in solche Frameworks ein.

Angular mit entsprechender Erweiterung fügt anderen Elementen, die nicht in der tab order sind, aber ein ng-click-„Attribut“ haben, tabindex="0" hinzu. Wie auch immer andere Elemente als button oder a o.a., die nativ per Tastatursteuerung zugänglich sind, zu ng-click kommen … Nun ja, Angular-Entwickler sind eben keine Frontend-Entwickler.

LLAP 🖖

[dedlfix]

Tach!

Im Übrigen denke ich hier wie Peter-Paul Koch, dass Angular u.ä. nichts für Frontend-Entwickler ist; „one could describe it as a front-end framework by non-front-enders for non-front-enders.“

Meinst du, wenn man Angular meidet und auf herkömmlichem Weg - oder vielleicht einem Angular-Konkurrenten - das gleiche Ergebnis erstellt, ist das besser?

Oder liegt es nicht viel mehr an den Menschen, die größtenteils zu unperfekt sind, um Ideal-Lösungen zu erstellen, egal welches Werkzeug auch immer sie in die Hand nehmen?

Wie auch immer andere Elemente als button oder a o.a., die nativ per Tastatursteuerung zugänglich sind, zu ng-click kommen … Nun ja, Angular-Entwickler sind eben keine Frontend-Entwickler.

Wer mit Angular ng-clicks verteilt, hätte ohne Angular onclicks genommen. Das ist sicher keine Marotte, die Angular anzulasten ist.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Im Übrigen denke ich hier wie Peter-Paul Koch, dass Angular u.ä. nichts für Frontend-Entwickler ist; „one could describe it as a front-end framework by non-front-enders for non-front-enders.“

Meinst du, wenn man Angular meidet und auf herkömmlichem Weg - oder vielleicht einem Angular-Konkurrenten - das gleiche Ergebnis erstellt, ist das besser?

An der Stelle ging es nicht um besser oder schlechter, sondern darum, dass Angular-Programmierung ($Framework-Programmierung) andere Kenntnisse erfordert als das, was ich unter Frontend-Entwicklung verstehe.

Zu letzterem gehört neben semantischem HTML und CSS auch Design, UX, IA, IxD, Usability, Accessibility, Typografie, …

S.a. Über Frontender und Programmierer

LLAP 🖖

[dedlfix]

Tach!

Im Übrigen denke ich hier wie Peter-Paul Koch, dass Angular u.ä. nichts für Frontend-Entwickler ist; „one could describe it as a front-end framework by non-front-enders for non-front-enders.“

Meinst du, wenn man Angular meidet und auf herkömmlichem Weg - oder vielleicht einem Angular-Konkurrenten - das gleiche Ergebnis erstellt, ist das besser?

An der Stelle ging es nicht um besser oder schlechter, sondern darum, dass Angular-Programmierung ($Framework-Programmierung) andere Kenntnisse erfordert als das, was ich unter Frontend-Entwicklung verstehe.

Ja, aber ich verstehe nicht, warum du da nur Angular erwähnst und fragte deshalb, ob andere Dinge, mit denen ein nach "Nicht-Frontender" Anwendungen im Browser erstellt in der Hinsicht Frontend ein besseres Ergebnis erzielen. Um mal zwei Werkzeuge konkret zu nennen: jQuery und nackiges Javascript.

dedlfix.

[Frameworknutzer]

An der Stelle ging es nicht um besser oder schlechter, sondern darum, dass Angular-Programmierung ($Framework-Programmierung) andere Kenntnisse erfordert als das, was ich unter Frontend-Entwicklung verstehe.

Das sehe ich ganz anders. Ein Framework wie Angular erfordert selbstverständlich Frontend-Kenntnisse. Man baut damit schließlich Web-Frontends!

Zu letzterem gehört neben semantischem HTML und CSS auch Design, UX, IA, IxD, Usability, Accessibility, Typografie, …

Wie kommst du auf die Idee, dass eine Seite mit Angular das alles NICHT hat oder braucht? Wie kommst du auf die Idee, dass Angularentwickler das alles NICHT AUCH können und anwenden? Wie kommst du darauf, dass in einem Team das Angular-Apps entwickelt KEINE Spezialisten für diese Themen sind?

Frameworks wie Angular sind bloß zusätzliche Werkzeuge in unserem Werkzeugkasten. Damit baut man immer noch Websites/Webapps. Und was für die seit eh und je gilt, gilt grundsätzlich auch für jede Angular-App.

Schlechte Seiten mit schlechter Usability und fehlerhaftem HTML kann man hervorragend mit oder ohne Angular bauen.

Ein Frameworknutzer

[marctrix]

Hej Frameworknutzer,

Zu letzterem gehört neben semantischem HTML und CSS auch Design, UX, IA, IxD, Usability, Accessibility, Typografie, …

Wie kommst du auf die Idee, dass eine Seite mit Angular das alles NICHT hat oder braucht?

Brauchen schon, haben ganz selten. Liegt wohl am zusätzlichen Lernaufwand. Was @Gunnar Bittersmann wohl meinte: Angular benötigt andere Kenntnisse, die eher in den Bereich Programmierung gehen.

HTML, CSS und die anderen von ihm genannten Aspekte (hatte er SEO, SEM usw erwähnt?) kommen halt noch oben drauf. Meine Erfahrung zeigt, dass nur ganz wenige Menschen beide Welten beherrschen. Auch wenn es viele gibt, die von sich behaupten, zusätzlich noch ein As in allen möglichen weiteren Sprachen und Techniken zu sein. Meist verstehen Sie dann alles, was sie angeben zu beherrschen, bestenfalls halb und sie sind froh, wenn ihre komplexen Projekte, zusammengesetzt aus einem Mischmasch an Frontend- und Backend-Techniken irgendwie laufen, weil sie jedes Problem so gelöst haben, wie es am schnellsten ging - nicht wie es konzeptionell am besten gewesen wäre...

Ich habe so etwas jedenfalls weit öfter gesehen, als solche, die wirklich alles können.

Wenn sie intelligent sind, was oft der Fall ist, lassen sich solche Menschen übrigens oft gerne mit zusätzlichem Wissen füttern und werden dann in diesem Teilgebiet schnell besser. Leider veraltet unser Wissen schnell. Wer kann schon in allen Techniken am Ball bleiben? Dann kommt man ja nicht mehr zum umsetzen...

Schlechte Seiten mit schlechter Usability und fehlerhaftem HTML kann man hervorragend mit oder ohne Angular bauen.

In der Regel sollte gerade ein größeres Projekt immer im Team umgesetzt werden, mit mindestens einem Spezialisten für Design, UX, IA, IxD, Usability und Typografie inklusive Konzept hierfür (Designer), einem Spezialisten für HTML und CSS, Acessibility injlusive Konzept hierfür und mindestens Grundkenntnissen in JS, SEO, SEM (sonst ist hierfür ein weiterer Spezialist nötig) und einem Spezialisten für die serverseitige Technik (z. B. ein CMS und Grundlagen in der Sprache, in der das CMS geschrieben wurde oder einen Programmierer für z. B. php).

Klar gehören noch Leute dazu, die das dann organisieren, Kontakt zum Kunden pflegen usw.

Ich kennen keinen, der all das in sich vereint!

Marc

PS: Ach ja: und SVG sollte ein Frontender auch noch - zumindest in Grundzügen - kennen. Steht auf meiner Leseliste ganz oben. Practical SVG

PPS: Manche Techniken muss man beherrschen, um andere nicht zu benötigen. Wer die Cscade und Vererbung geschickt nutzt, braucht Preprozessoren nur noch selten für DRY Code (Don't repeat yourself), setzt Js nicht für Animationen ein, oder um Texte ein- und auszublenden, benötigt weniger media-queries, und setzt SVG wesentlich seltener ein. Alles aber dann, wenn es Sinn macht! - Heißt ggfs auch weniger CSS, wenn eine der anderen Techniken besser geeignet sind, um (ohne Barrieren) ans Ziel zu kommen!

[Frameworknutzer]

Was @Gunnar Bittersmann wohl meinte: Angular benötigt andere Kenntnisse, die eher in den Bereich Programmierung gehen.

Ja, verstehe! Im Frontend muss man aber schon länger programmieren. Ajax gibt es seit über 10 Jahren und wenn ein Frontender glaubt er käme ohne "richtiges" Programmieren aus dann ist er im falschen Geschäft.

Frontend heißt für mich das Entwickeln von Code der im Browser läuft. Der "sichtbare" Teil der WebApp. Oder Webclient, wie mans nennen will. Früher war Frontend noch stark von "Programmieren" und Backend getrennt. Das ist heute nicht mehr so. Deshalb halt ich auch "Angular ist nichts für Frontendentwickler" für falsch. Das ist ein veraltetes Bild des Berufs!

Auch wenn es viele gibt, die von sich behaupten, zusätzlich noch ein As in allen möglichen weiteren Sprachen und Techniken zu sein. Meist verstehen Sie dann alles, was sie angeben zu beherrschen, bestenfalls halb und sie sind froh, wenn ihre komplexen Projekte, zusammengesetzt aus einem Mischmasch an Frontend- und Backend-Techniken irgendwie laufen, weil sie jedes Problem so gelöst haben, wie es am schnellsten ging - nicht wie es konzeptionell am besten gewesen wäre...

Klar hat nicht jeder den vollen Durchblick aber das ist in der heutigen Zeit auch gar nicht mehr möglich. Aber ich würde für mich NIE behaupten dass ich irgendwelche Probleme löse "wie es konzeptionell am besten gewesen wäre". Dazu gibt es viel zu viele Einschränkungen. Meine Fähigkeiten, Zeit, Budget, bestehender Code usw.

Leider veraltet unser Wissen schnell. Wer kann schon in allen Techniken am Ball bleiben? Dann kommt man ja nicht mehr zum umsetzen...

Ja. deswegen finde ich eine Anti Framework Haltung auch unangebracht.

Ein Frameworknutzer

[Gunnar Bittersmann]

@@Frameworknutzer

Frontend heißt für mich das Entwickeln von Code der im Browser läuft. Der "sichtbare" Teil der WebApp.

Das widerspricht sich. Nicht alles, was im Browser läuft, ist „sichtbar“, also Frontend (wie ich den Begriff verstehe).

Models und ViewModels laufen bspw. bei Angular-Webapps im Browser, sind aber nicht sichtbar. Gehören die mit zum Frontend, weil sie im Browser laufen?

Für mich nicht. Für mich heißt Frontend nicht alles, nur weil es im Browser läuft.

Für andere vielleicht schon. Der Begriff „Frontend“ wurde dermaßen überdehnt, dass er kaum noch für irgendwas steht. Es ist wohl an der Zeit, neue Begriffe einzuführen. Ich nenne mich dann nicht mehr Frontend-Entwickler, sondern UI-Entwickler. (Womit nicht UI-Designer gemeint ist.)

Deshalb halt ich auch "Angular ist nichts für Frontendentwickler" für falsch. Das ist ein veraltetes Bild des Berufs!

Mein Punkt ist, dass das, was du und andere als Frontend-Entwickler bezeichnest, mittlerweile nicht mehr ein Beruf ist, sondern aufgeteilt werden kann/sollte: in UI und … – ich würde es Backend nennen, auch wenn es im Browser läuft.

Auch wenn es viele gibt, die von sich behaupten, zusätzlich noch ein As in allen möglichen weiteren Sprachen und Techniken zu sein. Meist verstehen Sie dann alles, was sie angeben zu beherrschen, bestenfalls halb

Ja. Viele Backend-Entwickler (JavaScript-Entwickler eingeschlossen) haben so gut wie keine Ahnung von HTML und sehen bspw. keinen Unterschied in <button ng-click="…"> und <div ng-click="…">.

Deshalb halte ich es ja für erforderlich, in JavaScript-Tutorials Grundkenntniss in HTML mit zu vermitteln. (Höre höre, @Felix Riesterer! ;-))

---

Ja. deswegen finde ich eine Anti Framework Haltung auch unangebracht.

Anti Framework bin ich vor allem dann, wenn ein Framework einzig und allein deshalb eingesetzt wird, weil es den Entwicklern vermeintliche Vorteile bringt, ohne zu bedenken, was das für die Nutzer für Nachteile mit sich bringt.

LLAP 🖖

[marctrix]

Hej Frameworknutzer,

Was @Gunnar Bittersmann wohl meinte: Angular benötigt andere Kenntnisse, die eher in den Bereich Programmierung gehen.

Ja, verstehe! Im Frontend muss man aber schon länger programmieren. Ajax gibt es seit über 10 Jahren und wenn ein Frontender glaubt er käme ohne "richtiges" Programmieren aus dann ist er im falschen Geschäft.

Ach, was ich nicht alles schon für derartige Behauptungen gehört habe: Wer den CMS-Zug verpasst hat, sei raus aus dem Geschäft, wer kein Flash kann, ist raus aus dem Geschäft, wer kein ASP kann ist raus aus dem Geschäft, JavaScript ist tot (mindestens ein dutzend Mal)...

Diese Sprüche sagen höchstens etwas darüber aus, wie derjenige tickt, der sie loslässt.

Wer sagt denn, dass ein Autodesigner Motoren konstruieren können soll, nur weil seit hundert Jahren Autos Motoren haben?

Ich bin ganz froh, dass unterschiedliche Spezialisten an einem Auto arbeiten. Ich würde mich nicht in einen Wagen setzen, der zweihundert fährt und von einem einzelnen Tüftler stammt (ohne zugekaufte Komponenten versteht sich).

Frontend heißt für mich das Entwickeln von Code der im Browser läuft. Der "sichtbare" Teil der WebApp. Oder Webclient, wie mans nennen will. Früher war Frontend noch stark von "Programmieren" und Backend getrennt. Das ist heute nicht mehr so. Deshalb halt ich auch "Angular ist nichts für Frontendentwickler" für falsch. Das ist ein veraltetes Bild des Berufs!

UI-Entwickler ist ein treffender Begriff von @Gunnar Bittersmann. CSS und HTMl haben erst einmal nichts mit Programmierung zu tun, auch SASS nicht.

Dabei ist allein CSS bereits so umfangreich, dass selbst "Stars" wie Lea Verou zugeben, nicht mehr alles im Kopf haben zu können.

Das ganze Wissen muss dann auch noch auf aktuellem Stand gehalten werden und letztendlich will man auch noch das letzte Quentchen aus den Möglichkeiten rausquetschen, um zum Beispiel Änderungen am Backend vermeiden zu können. Alles was man über das Frontend sinnvoll erledigen kann, ist billiger umgesetzt, als das Hinzuziehen eines Backenders.

Allein über "das letzte Quentchen aus CSS rausholen" gibt es ganze Bücher wie zum Beispiel das Buch, aus dem der obige Ausspruch von Lea Verou stammt.

Das ist nicht nur eine andere Denke, ich kenne niemanden, der neben Frontend auch noch (gut) in der Programmierung von Backends ist.

Zum Frontend gehören IMHO viele andere Dinge, die sich prima von der Programmierung trennen lassen und hier bereits benannt wurden. Es ist eben nicht "nur" HTML und CSS (obwohl selbst das schon nur von wenigen beherrscht wird - es gibt schließlich Frameworks, die es einem abnehmen, Dinge verstehen zu müssen - SCNR)

Auch wenn es viele gibt, die von sich behaupten, zusätzlich noch ein As in allen möglichen weiteren Sprachen und Techniken zu sein. Meist verstehen Sie dann alles, was sie angeben zu beherrschen, bestenfalls halb und sie sind froh, wenn ihre komplexen Projekte, zusammengesetzt aus einem Mischmasch an Frontend- und Backend-Techniken irgendwie laufen, weil sie jedes Problem so gelöst haben, wie es am schnellsten ging - nicht wie es konzeptionell am besten gewesen wäre...

Klar hat nicht jeder den vollen Durchblick aber das ist in der heutigen Zeit auch gar nicht mehr möglich.

Man benötigt aber mindestens den Überblick über das was geht und sollte wissen, was wo zu finden ist. Selbst das gelingt heute nur noch, wenn man sich auf etwas spezialisiert. Nur weil man was mit Computern macht, kennt man sich nicht mit den Vor- und Nachteilen aller Betriebssysteme im Detail aus, kann einschätzen, welcher Web-Server für welchen Dienst ideal ist, welche DB die speziellen Anforderungen eines Projektes am besten abdeckt usw.

Im Großen und Ganzen wird jede Anwendung mit fast jeder DB (oder Excel-Dateien), mit jeder Programmiersprache auf jedem Web-Server irgendwie ans laufen zu kriegen sein - dabei können Bootstrap, Angular und weiß nicht was zum Einsatz kommen.

Aber das wird niemals ideal sein - nicht einmal sinnvoll (und auf keinen Fall performant oder gar sicher).

Darum braucht man Datenbanker, SysAdmins (btw: Happy SysAdmin-Day!), Programmierer, Designer und eben Frontender in Projekten, die einen gewissen Qualitätsanspruch haben (auch wenn sie dennoch scheitern können - aber das ist ein anderes Thema).

Und Frontender sind in der Regel keine guten Programmierer. Ein bisschen JS um den Code DRY zu machen (don't repeat yourself), ein bisschen SVG, XML - kommt schon was zusammen.

Aber ich würde niemals eine komplette JavaScript-Anwendung selber programmieren - egal ob Framework oder nicht - es sei denn ich wechsle meinen Beruf. Ja, das ist mMn ein komplett anderes Berufsbild!

Aber ich würde für mich NIE behaupten dass ich irgendwelche Probleme löse "wie es konzeptionell am besten gewesen wäre". Dazu gibt es viel zu viele Einschränkungen. Meine Fähigkeiten, Zeit, Budget, bestehender Code usw.

Gerade weil man aus von dir genannten Gründen Abstriche machen oder Kompromisse eingehen muss, sollte man Leute haben, die ihr Handwerk verstehen.

Schuster bleib bei deinen Leisten!

Leider veraltet unser Wissen schnell. Wer kann schon in allen Techniken am Ball bleiben? Dann kommt man ja nicht mehr zum umsetzen...

Ja. deswegen finde ich eine Anti Framework Haltung auch unangebracht.

Um Anti-Framework ging es mir nicht. Eher um den Unterschied zwischen den einzelnen Fachbereichen, die an dem Aufbau einer Website im Idealfall beteiligt sind.

Ich kann nur zu so was wie Bootstrap Stellung beziehen, von Angular verstehe ich zu wenig.

Natürlich gibt es den Idealfall nicht im echten Leben, aber das ist kein Grund, ihm nicht jeden Tag einen Schritt näher zu kommen!

Marc

[Gunnar Bittersmann]

@@marctrix

CSS und HTMl haben erst einmal nichts mit Programmierung zu tun, auch SASS nicht.

Nicht? ;-) ^[1]

Es ist eben nicht "nur" HTML und CSS (obwohl selbst das schon nur von wenigen beherrscht wird - es gibt schließlich Frameworks, die es einem abnehmen, Dinge verstehen zu müssen - SCNR)

Die nehmen es einem schließlich auch ab, das DOM mit HTML zu generieren. JavaScript ist ja so hip. HTML ist überbewertet. – SCNR2.

LLAP 🖖

---

1. Bei Interesse s.a. das Video dazu. Und den Artikel. ↩︎

[marctrix]

Hej Gunnar,

@@marctrix

CSS und HTMl haben erst einmal nichts mit Programmierung zu tun, auch SASS nicht.

Nicht? ;-) [^1]

HTML ist dank Canvas, output, data- und diverser anderer Elemente und Techniken wie dem Speichern von Daten natürlich auch Teil von Programmen - aber in erster Linie doch immer noch eine Auszeichnungssprache.

Auch CSS arbeitet ja mit Bedingungen und das Bestimmen von einer bestimmten Anzahl von Kindelementen mittels geschickter nth-child und nth-last-child Kombinationen ist nichts anderes als if-else Anweisungen, die für eine bestimmbare Menge von Elementen wiederholt wird wie in einer Schleife - nur eben ausschließlich um das Aussehen einer Webseite anzupassen. Aber kombiniert mit CSS-generiertem Contentent ist man doch auch hier nahe am Programmieren. Aber eben doch nicht so richtig und Code from Hell ist es allemal, wenn man Inhalte zum Beispiel für Screenreader unzugänglich mittels CSS generiert...

Sassematics und der Rest von bittersmann.de sind es freilich wert beachtet zu werden!

Es ist eben nicht "nur" HTML und CSS (obwohl selbst das schon nur von wenigen beherrscht wird - es gibt schließlich Frameworks, die es einem abnehmen, Dinge verstehen zu müssen - SCNR)

Die nehmen es einem schließlich auch ab, das DOM mit HTML zu generieren. JavaScript ist ja so hip. HTML ist überbewertet. – SCNR2.

;-)

Bei Interesse s.a. das Video dazu. Und den Artikel.

Interesse? Aber immer!

Marc

[1unitedpower]

HTML ist dank Canvas, output, data- und diverser anderer Elemente und Techniken wie dem Speichern von Daten natürlich auch Teil von Programmen - aber in erster Linie doch immer noch eine Auszeichnungssprache.

Die Unterscheidung ist bei genauerem Hinsehen auch nicht ganz korrekt: Auszeichnungssprache und Programmiersprache schließen sich nicht aus - siehe XSLT. HTML ist eine domänespezifische Sprache für semantische Auszeichnung von digitalen Dokumenten. Mit WebComponents kann man die Domäne außerdem um benutzerdefinierte semantische Elemente erweitern - das eröffnet auch die Möglichkeit einer eingebetteten Turing-vollständigen Sprache.

[Gunnar Bittersmann]

@@marctrix

einem Spezialisten für HTML und CSS, Acessibility injlusive Konzept hierfür und mindestens Grundkenntnissen in JS, SEO, SEM (sonst ist hierfür ein weiterer Spezialist nötig)

Was der Frontender auch sein muss: Spezialist für performance. Und da sind wohl mehr als nur Grundkenntniss in JS erforderlich – nur halt andere JavaScript-Kenntnisse als die ein Angular-Backend-Entwickler haben muss.

Versteht mich nicht falsch: Ich bin kein JavaScript-Ablehner. Mit JavaScript kann man tolle moderne Frontends bauen. Service worker, responsive web apps – das sind die Dinge, die mich interessieren, nicht Framworks wie Angular u.dgl.

PS: Ach ja: und SVG sollte ein Frontender auch noch - zumindest in Grundzügen - kennen.

Unbedingt. Er muss SVG vielleicht nicht im Texteditor schreiben können – obwohl auch das nicht schaden kann.

Überhaupt muss er sich in Grafikformaten auskennen (wann JPEG, wann PNG), weil Grafiker sich darin mitunter nicht auskennen.

setzt Js nicht für Animationen ein, oder um Texte ein- und auszublenden

À la Heydon Pickering ;-)

My javascript is shit -> I should learn more javascript
My CSS is shit -> I'll do it with javascript

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Grundkenntniss

Schon zum zweiten mal - also doch kein Vertipper?

Das Suffix -nis hat nur ein s und wurde früher imho auch nicht mit ß geschrieben, obwohl wiktionary von nicht mehr gültigen Schreibweisen schreibt.

Ganz ganz früher musste es aber wohl doch die Schreibweise mit ß gegeben haben, denn Neuärgerniß wird eben doch mit ß geschrieben.

Bis demnächst
Matthias

[Der Martin]

Hallo,

Grundkenntniss

Schon zum zweiten mal - also doch kein Vertipper?

dann sollte man sich Sorgen machen. ;-)

Das Suffix -nis hat nur ein s und wurde früher imho auch nicht mit ß geschrieben

So ist auch mein Kenntnisstand (hier sind die zwei 's' dann doch richtig).

obwohl wiktionary von nicht mehr gültigen Schreibweisen schreibt.

Hmm. Das muss dann lange her sein. Jedenfalls lange bevor ich Lesen und Schreiben gelernt habe.

Ganz ganz früher musste es aber wohl doch die Schreibweise mit ß gegeben haben, denn Neuärgerniß wird eben doch mit ß geschrieben.

Das würde ich nicht unbedingt als hinreichendes Argument sehen, denn Orts- und Eigennamen unterliegen nicht unbedingt der Rechtschreibung.

Sie werden in der Regel aber auch nicht den sich ändernden Rechtschreibregeln angepasst. Verwandte von mir sind beispielsweise 1979 in ihr Eigenheim im Haselnußweg eingezogen; heute heißt der Weg noch genauso, obwohl man die Haselnuss nun mit Doppel-s schreibt.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Schon zum zweiten mal - also doch kein Vertipper?

dann sollte man sich Sorgen machen. ;-)

Ich mache mir schon Sorgen, dass ihr herausbekommt, dass ich Sarah bin. ;-)

So ist auch mein Kenntnisstand (hier sind die zwei 's' dann doch richtig).

Was ist ein Tand?

LLAP 🖖

[Tabellenkalk]

Hallo,

Was ist ein Tand?

Das weiß z.B. Wikipedia, also wird Kenntnistand wohl nur mit einem s geschrieben!

Gruß
Kalk

[1unitedpower]

einem Spezialisten für HTML und CSS, Acessibility injlusive Konzept hierfür und mindestens Grundkenntnissen in JS, SEO, SEM (sonst ist hierfür ein weiterer Spezialist nötig)

Was der Frontender auch sein muss: Spezialist für performance. Und da sind wohl mehr als nur Grundkenntniss in JS erforderlich – nur halt andere JavaScript-Kenntnisse als die ein Angular-Backend-Entwickler haben muss.

Im Gegenteil Frameworks sind eine große Hilfe dabei häufige Performance-Engpässe zu vermeiden. Die Herausforderung beim Optimieren liegt darin, die Unterschiede des eigenen intuitiven Verständnis der JavaScript-Semantik mit den internen Vorgehensweisen der JIT-Compiler zu überbrücken. Dass es verschiedene JS-Engines gibt, gegen die man profilen muss, erleichtert die Sache nicht gerade. Da ist es äußerst von Vorteil auf das Know-How der Framework-Entwickler(innen) zurückgreifen zu können. Ich möchte zwei Beispiele für solche Engpässe geben, deren Vorkommen von einem Framework (exemplarisch an React) gemindert werden.

• JavaScript hat eine automatische Müllsammlung, die dafür sorgt, dass nicht mehr benötigte Objekte aus dem Speicher entfernt werden. Dadurch werden Speicher-Leaks vermieden, aber natürlich kann das nicht ohne Overhead geschehen - wenn die Garbage-Collection arbeitet, muss die Code-Ausführung zeitweise unterbrochen werden. Bei ungünstigen Umständen wird die Garbage-Collection vom Browser sehr oft angestoßen und die Unterbrechungen werden spürbar. React implementiert sogenanntes Object-Pooling: Das ist eine Strategie, die die Umstände so zum besseren wendet, dass die Garbage-Collection seltener ausgeführt wird.
• Mein zweites Beispiel bezieht sich auf DOM-Manipulationen. DOM-Updates sind ein Standard-Beispiel für Performance-Engpässe. Die API ist historisch immer weiter angewachsen und zu einem irre komplexen Gebilde geworden. Kritisch dabei ist, dass DOM-Updates sehr häufig synchron mit dem JavaScript-Prozess ausgeführt werden. Fügt man einem Element nur eine Klasse hinzu, pausiert die Code-Ausführung und die Rendering-Enginge zeichnet (vereinfacht ausgedrückt) einen neuen Frame. Danach kann die JavaScript-Engine weiter arbeiten. React batcht deshalb DOM-Manipulationen und versucht vor der Anwendung eine minimale Menge an DOM-Operationen zu finden, die tatsächlich ausgeführt werden müssen, um das gewünschte Ergebnis zu erzielen.

Beide Optimierungsstrategien erfordern außerordentliches Detailwissen über die Funktionsweise eines Browsers. Ein(e) React-Anwendungsentwickler(in) muss diese Details allerdings nicht kennen, um von den Performance-Boosts effektiven Gebrauch zu machen, weil das Framework es transparent vor ihm oder ihr regelt.

[Gunnar Bittersmann]

@@Frameworknutzer

Zu letzterem gehört neben semantischem HTML und CSS auch Design, UX, IA, IxD, Usability, Accessibility, Typografie, …

Wie kommst du auf die Idee, dass eine Seite mit Angular das alles NICHT hat oder braucht?

Das war nicht meine Idee.

Wie kommst du auf die Idee, dass Angularentwickler das alles NICHT AUCH können und anwenden?

Entwickler, die das alles können, wäre eierlegende Wollmichsäue. Siehe mein Posting Über den Frontent-Entwickler.

Wie kommst du darauf, dass in einem Team das Angular-Apps entwickelt KEINE Spezialisten für diese Themen sind?

Das wäre genau meine Rede. Diese Spezialisten sind die Frontend-Entwickler. Die entwickeln die Views = das Frontend.

Die anderen im Team, die Models und ViewModels entwickeln, würde ich nicht als Frontend-Entwickler bezeichnen. Sondern als Angular-Programmierer.

In dem Sinne war das gemeint:

… dass Angular-Programmierung ($Framework-Programmierung) andere Kenntnisse erfordert als das, was ich unter Frontend-Entwicklung verstehe.

LLAP 🖖

[Christian Wansart]

Guten Morgen Gunnar,

Oh, danke für die Blumen.

Du hast mich mit deinen Posts auf neue Themenfelder gebracht. Das fand ich sehr praktisch. Auch deine Aussagen bzgl. Angular und Bootstrap fand ich sehr interessant, was mich dann eben auch auf deine bittersmann.de-Webseite brachte. Ich habe selten so einen sauberen Quellcode gesehen! (Du scheinst da keine minifier oder servseitiges Zusammenfügen zu nutzen – gut, bei einer einzigen Seite würde das auch nicht so viel Sinn ergeben.)

Du hast im übrigen „tote Links“ unten bei den Workshops. Die Slides von „Frontend Development in-company, 2014-01-28“ existieren wohl nicht mehr.

Ja, *seufz*. In so manchen Fällen würde ich das nicht „modern“ nennen, sondern Bequemlichkeit der Entwickler wird über Bedürfnisse der Nutzer gestellt. WTF :-(

Ist es denn nicht manchmal sinnvoller, wenn nur ein Teil sich ändert? Sagen wir ich habe ein Imageboard unter dem der Nutzer einen Kommentar schreiben will. Nichts großes, einfach nur reinen Text. Ist es dann nicht sinnvoller, die Daten einfach per Framework (hier z. B. jQuery) an den Server zu schicken und den Text bei einem 200-Status-Code in den DOM einzupflegen. Damit müsste die gesamte Seite weder neu geladen noch gerendert werden. Ich denke, dass das für den Endnutzer bequemer wäre, anstatt für jeden Schritt eine neue Seite. Allerdings muss ich gestehen, dass ich nicht weiß, wie es für eingeschränkte Nutzer aussieht, die z. B. mittels Screenreader diese Seite nutzen.

Das kann etwas schneller sein. An einer Stelle, wo man die Schnelligkeit evtl. gar nicht mal braucht. Das erkauft man sich damit, dass man den Nutzer beim initialen Aufruf der Webseite ewig lange warten lässt, bis das ganze Framework geladen ist. Für mich oft keine gute Abwägung.

Da stimme ich dir grundsätzlich zu, aber nehmen wir mal meine Applikation. Dort wird auf der Client-Seite das jQuery-Framework einmalig geladen. Wichtig ist, dass die Nutzer möglichst zeitgleich die Information per WebSocket bekommen, dass eine neue Frage verfügbar ist. Würde ich da jedes mal die Seite vollständig neu laden, wäre es eine Katastrophe. Da nehme ich das längere Laden lieber in Kauf. (0,55 Sekunden Ladezeit.)

Im Übrigen denke ich hier wie Peter-Paul Koch, dass Angular u.ä. nichts für Frontend-Entwickler ist; „one could describe it as a front-end framework by non-front-enders for non-front-enders.“

Genau diese Aussage finde ich interessant. Denn speziell das Laden und Verwalten von Daten ist damit so simpel gemacht. Zugegeben, für das Projekt haben wir Angular im Frontend auch verworfen, weil es einfach viel zu groß war und weit über das hinaus ging, was wir brauchten. Die SPA lies sich mit jQuery sehr gut und effizient umsetzen -- lediglich die Sauberkeit des Codes ist nicht so gut, da die jeweiligen Studenten in der Gruppe Anfänger im Umgang mit JavaScript und speziell jQuery sind.

Aber dir ging es ja um Barrierefreiheit. Eine single page application kann durchaus barrierefrei sein – wenn sie denn richtig implementiert wird. Bspw. Bereiche mit aria-live gekennzeichnet werden, wo sich Inhalte dynamisch ändern. Es fließt auch zunehmend Wissen über Barrierefreiheit in solche Frameworks ein.

Und hier verstehe ich nicht, warum du mit Bootstrap so ein Problem hast. Sie haben in ihren Beispielen verschiedene aria-Attribute genutzt. Gut, der Code ist mit divs aufgebaut, anstelle von den jeweiligen HTML5-Elementen, aber ich schätze mal, dass die Entscheidung so aufgrund der Abwärtskompatibel gefallen ist. Allerdings verwendest du im Vergleich zu eigentlich jedem anderen den ich kenne, kaum bis gar keine Klasse, sondern nutzt die entsprechenden Elemente im CSS selbst. Hier ist Bootstrap ja auch so, dass es für jede Kleinigkeit eigene Klassen gibt.

Vielen Dank für deine Antwort.
Lebe lang und in Frieden!

[dedlfix]

Tach!

Ist es denn nicht manchmal sinnvoller, wenn nur ein Teil sich ändert? Sagen wir ich habe ein Imageboard unter dem der Nutzer einen Kommentar schreiben will. Nichts großes, einfach nur reinen Text. Ist es dann nicht sinnvoller, die Daten einfach per Framework (hier z. B. jQuery) an den Server zu schicken und den Text bei einem 200-Status-Code in den DOM einzupflegen. Damit müsste die gesamte Seite weder neu geladen noch gerendert werden. Ich denke, dass das für den Endnutzer bequemer wäre, anstatt für jeden Schritt eine neue Seite.

Ja, in bestimmten Fällen. Beispielsweise wenn man ein Video auf einer der Plattformen kommentieren möchte, wäre es nicht schön, wenn nach dem Absenden die Seite neu geladen und damit das Video unterbrochen würde. Dann doch lieber im Hintergrund zum Server senden und den Text ins DOM einschieben. Aber wenn man zu einem anderen Video wechselt, wird eine neue Seite aufgerufen und nicht nur das neue Video in die bereits geladene eingefügt. An der Stelle wäre das Vorgehen mit mehr Nachteilen als Nutzen verbunden.

Das kann etwas schneller sein. An einer Stelle, wo man die Schnelligkeit evtl. gar nicht mal braucht. Das erkauft man sich damit, dass man den Nutzer beim initialen Aufruf der Webseite ewig lange warten lässt, bis das ganze Framework geladen ist. Für mich oft keine gute Abwägung.

Das passiert ja nur beim erstmaligen Aufruf. Und wenn man die Frameworks nicht selber hostet, sondern eines der bekannteren CDNs verwendet, ist die Chance nicht unbedingt niedrig, dass die Ressourcen bereits im Cache sind.

Die SPA lies sich mit jQuery sehr gut und effizient umsetzen -- lediglich die Sauberkeit des Codes ist nicht so gut, da die jeweiligen Studenten in der Gruppe Anfänger im Umgang mit JavaScript und speziell jQuery sind.

Und das ist ein klassisches Beispiel, wo die Schuld nicht im Framework zu suchen ist.

Und hier verstehe ich nicht, warum du mit Bootstrap so ein Problem hast. Sie haben in ihren Beispielen verschiedene aria-Attribute genutzt. Gut, der Code ist mit divs aufgebaut, anstelle von den jeweiligen HTML5-Elementen, aber ich schätze mal, dass die Entscheidung so aufgrund der Abwärtskompatibel gefallen ist. Allerdings verwendest du im Vergleich zu eigentlich jedem anderen den ich kenne, kaum bis gar keine Klasse, sondern nutzt die entsprechenden Elemente im CSS selbst. Hier ist Bootstrap ja auch so, dass es für jede Kleinigkeit eigene Klassen gibt.

Bootstrap muss für einen breiten Anwenderkreis verwendbar sein. Das CSS der Bittersmannseite muss lediglich zu dieser einen passen und kann deshalb darauf optimiert werden. Wenn Bootstrap nicht auf universell verwendbare Klassen sondern konkrete Elemente setzen würde, wäre man bei der Verwendung auf diese Elemente beschränkt. Es ist immer eine Abwägungssache. Mache ich etwas zu Fuß, bin ich frei, alles so zu machen, wie ich mir das vorstelle. Das kostet dann aber unter Umständen eine Menge Entwicklungsarbeit für Dinge, die vielleicht nicht direkt zum Kern der Geschäftslogik gehören, aber trotzdem als Verbindung zwischen den Teilen notwendig sind. Verwende ich ein Framework, dass große Teile des nebensächlichen Krams bereits gelöst hat, bin ich in der Regel schneller am Ziel (unter der Voraussetzung, ich kenne mich mit beiden Vorgehensweisen einigermaßen gut aus und habe keinen grundsätzlichen Lernaufwand mehr). Aber ich sollte dann gemäß dessen Philosophie arbeiten, sonst steht es mir möglicherweise mehr im Weg als dass es ihn mir ebnet. Das Framework muss nun jedoch nicht nur mich zufriedenstellen, sondern einen breiteren Anwenderkreis, und deshalb muss es allgemeiner entworfen werden. Das hat auch zur Folge, dass es eine Menge Funktionen mitbringt, die ich gar nicht brauche. Das passiert aber auch, wenn ich aus einem vorhergehenden Projekt meine dort für die allgemeinen Zwecke erstellte Funktionssammlung mitbringe. Da sind überflüssige Teile drin und manche fehlen. Aber dafür gibts ja bei den Frameworks mit der Modularität eine zumindest entgegenkommende Lösung. Man lädt eben die Module nicht mit, die man gar nicht verwendet.

Wenn man es genau nimmt, hat man dieses angebliche Dilemma auch schon im Browser an sich. Der hat auch eine Menge Zeugs an Bord, dass nicht jede Webseite benötigt, und trotzdem musste man das alles mitinstallieren. Genauso wie beim Betriebssystem (von einfach so mitinstallierten Anwendungen ganz zu schweigen).

dedlfix.

[Christian Wansart]

Guten Morgen,

Ja, in bestimmten Fällen. Beispielsweise wenn man ein Video auf einer der Plattformen kommentieren möchte, wäre es nicht schön, wenn nach dem Absenden die Seite neu geladen und damit das Video unterbrochen würde. Dann doch lieber im Hintergrund zum Server senden und den Text ins DOM einschieben. Aber wenn man zu einem anderen Video wechselt, wird eine neue Seite aufgerufen und nicht nur das neue Video in die bereits geladene eingefügt. An der Stelle wäre das Vorgehen mit mehr Nachteilen als Nutzen verbunden.

Da hast du natürlich absolut Recht.

Das passiert ja nur beim erstmaligen Aufruf. Und wenn man die Frameworks nicht selber hostet, sondern eines der bekannteren CDNs verwendet, ist die Chance nicht unbedingt niedrig, dass die Ressourcen bereits im Cache sind.

CDN nutze ich grundsätzlich nicht. Ich lade die Sachen immer auf den eigenen Server, da die Ladezeiten einfach deutlich geringer sind. :) Vor allem wenn dann mal einer der CDN-Server ausfällt, hat man ein echtes Problem.

Und das ist ein klassisches Beispiel, wo die Schuld nicht im Framework zu suchen ist.

Oh, ich habe mich vermutlich falsch ausgedrückt, das wollte ich nicht tun. Mit reinem JavaScript wäre es vermutlich noch chaotischer. :-)

Bootstrap muss für einen breiten Anwenderkreis verwendbar sein. Das CSS der Bittersmannseite muss lediglich zu dieser einen passen und kann deshalb darauf optimiert werden. Wenn Bootstrap nicht auf universell verwendbare Klassen sondern konkrete Elemente setzen würde, wäre man bei der Verwendung auf diese Elemente beschränkt. Es ist immer eine Abwägungssache. Mache ich etwas zu Fuß, bin ich frei, alles so zu machen, wie ich mir das vorstelle. Das kostet dann aber unter Umständen eine Menge Entwicklungsarbeit für Dinge, die vielleicht nicht direkt zum Kern der Geschäftslogik gehören, aber trotzdem als Verbindung zwischen den Teilen notwendig sind. Verwende ich ein Framework, dass große Teile des nebensächlichen Krams bereits gelöst hat, bin ich in der Regel schneller am Ziel (unter der Voraussetzung, ich kenne mich mit beiden Vorgehensweisen einigermaßen gut aus und habe keinen grundsätzlichen Lernaufwand mehr). Aber ich sollte dann gemäß dessen Philosophie arbeiten, sonst steht es mir möglicherweise mehr im Weg als dass es ihn mir ebnet. Das Framework muss nun jedoch nicht nur mich zufriedenstellen, sondern einen breiteren Anwenderkreis, und deshalb muss es allgemeiner entworfen werden. Das hat auch zur Folge, dass es eine Menge Funktionen mitbringt, die ich gar nicht brauche. Das passiert aber auch, wenn ich aus einem vorhergehenden Projekt meine dort für die allgemeinen Zwecke erstellte Funktionssammlung mitbringe. Da sind überflüssige Teile drin und manche fehlen. Aber dafür gibts ja bei den Frameworks mit der Modularität eine zumindest entgegenkommende Lösung. Man lädt eben die Module nicht mit, die man gar nicht verwendet.

Auch hier stimme ich dir natürlich zu. Da wäre es natürlich gut, es möglichst modular zu machen. Oder gar ein Programm, dass überprüft was ich überhaupt nutze und alles ungenutzte rauswerfen, quasi Vorkompilieren – gibt es da etwas in der Art?

Wenn man es genau nimmt, hat man dieses angebliche Dilemma auch schon im Browser an sich. Der hat auch eine Menge Zeugs an Bord, dass nicht jede Webseite benötigt, und trotzdem musste man das alles mitinstallieren. Genauso wie beim Betriebssystem (von einfach so mitinstallierten Anwendungen ganz zu schweigen).

Beim Browser ist das aber nicht das große Problem, da dieser ja nur einmal geladen werden muss. Es wäre natürlich schön, wenn mein Firefox etwas schneller starten würde, aber er ist nun nicht so langsam, dass ich das als störend empfinden würde. Es bleibt dahingehend spannend, wenn Mozilla Firefox-Komponenten gegen in Rust geschriebene Komponenten austauscht und die UI möglicherweise mit Webtechnologien gebaut wird – meine Befürchtung ist aber, dass das Aufsetzen auf JavaScript in der Firefox-Benutzeroberfläche ein Fehler ist und den Browser unnötig verlangsamen wird.

Freundliche Grüße
Christian

[Matthias Apsel]

Hallo Christian Wansart,

Das passiert ja nur beim erstmaligen Aufruf. Und wenn man die Frameworks nicht selber hostet, sondern eines der bekannteren CDNs verwendet, ist die Chance nicht unbedingt niedrig, dass die Ressourcen bereits im Cache sind.

CDN nutze ich grundsätzlich nicht. Ich lade die Sachen immer auf den eigenen Server, da die Ladezeiten einfach deutlich geringer sind. :) Vor allem wenn dann mal einer der CDN-Server ausfällt, hat man ein echtes Problem.

Das „N“ in „CDN“ steht für „Network“ ;-)

Bis demnächst
Matthias

[Christian Wansart]

Guten Morgen Matthias,

Das „N“ in „CDN“ steht für „Network“ ;-)

![So you're telling me "N" stands for network?](http://i.imgur.com/hnfLboz.jpg "So you're telling me "N" stands for network?")

Gutes Argument, aber wenn die DNS-Auflösung wegen irgendwelcher Probleme nicht funktioniert, ist das schlecht. Ich hatte ein solches Problem vor einigen Monaten mal bei einem jQuery-CDN. Zu der Zeit hatte die Telekom hier allerdings Probleme, weswegen es natürlich nicht unbedingt die Schuld des CDN sein muss.

Freundliche Grüße
Christian

[dedlfix]

Tach!

CDN nutze ich grundsätzlich nicht. Ich lade die Sachen immer auf den eigenen Server, da die Ladezeiten einfach deutlich geringer sind. :) Vor allem wenn dann mal einer der CDN-Server ausfällt, hat man ein echtes Problem.

Gegen Ausfälle gibts Lösungen, à la: wenn nach dem Laden aus dem CDN das jQuery-Objekt nicht vorhanden ist, lädt man eben vom eigenen Server nach.

Und das ist ein klassisches Beispiel, wo die Schuld nicht im Framework zu suchen ist.

Oh, ich habe mich vermutlich falsch ausgedrückt, das wollte ich nicht tun. Mit reinem JavaScript wäre es vermutlich noch chaotischer. :-)

Auch dann wäre nicht die Programmiersprache schuld.

[...] Da wäre es natürlich gut, es möglichst modular zu machen. Oder gar ein Programm, dass überprüft was ich überhaupt nutze und alles ungenutzte rauswerfen, quasi Vorkompilieren – gibt es da etwas in der Art?

Aufwand und Nutzen. Beim Modularisieren wacht der Mensch darüber, dass die Komponenten sauber getrennt geschrieben werden und definiert eventuelle Abhängigkeiten. Natürlich kann man dem Compiler oder wem auch immer auftragen, ungenutzte Teile zu erkennen und zu entfernen. Das ist aber nur bei den Systemen einfach möglich, wo der Compiler genau sagen kann, worauf sich ein Ausdruck bezieht. Wenn man Magic Strings verwenden kann, um irgendwelche Funktionalität zu referenzieren, dann wirds sehr schwierig.

Beim Browser ist das aber nicht das große Problem, da dieser ja nur einmal geladen werden muss.

Genau deshalb versucht man, dass Bibliotheken auch nur einmal geladen werden müssen.

dedlfix.

[Christian Wansart]

Guten Morgen,

Gegen Ausfälle gibts Lösungen, à la: wenn nach dem Laden aus dem CDN das jQuery-Objekt nicht vorhanden ist, lädt man eben vom eigenen Server nach.

Meine Lösung: gleich auf dem eigenen Server laden. Wenn mein Server nicht erreichbar ist, ist die Webseite sowieso nicht erreichbar. Scheint für mich am sinnvollsten, anstatt sich auf andere verlassen zu müssen.

Auch dann wäre nicht die Programmiersprache schuld.

Das kann ich nur bedingt unterschreiben. Speziell Sprachen wie JavaScript oder Perl lassen sehr seltsame und unsaubere Konstrukte zu. Letztlich ist natürlich der Entwickler, der damit am Ende programmiert verantwortlich, aber ich denke, wenn die Sprache versucht da entgegen zu wirken, kann das durchaus sinnvoll sein. Ich glaube aber, dass bestimmte Programmiergruppen eher dazu neigen, unsauber zu programmieren, sodass mir das in JavaScript stärker auffällt, als beispielsweise in C++. (Das ist natürlich subjektiv aus den Projekten, die ich bisher gesehen habe.)

Und nein, ich bin kein Python-Freund, deren Syntax mag ich persönlich genauso wenig.

Aufwand und Nutzen. Beim Modularisieren wacht der Mensch darüber, dass die Komponenten sauber getrennt geschrieben werden und definiert eventuelle Abhängigkeiten. Natürlich kann man dem Compiler oder wem auch immer auftragen, ungenutzte Teile zu erkennen und zu entfernen. Das ist aber nur bei den Systemen einfach möglich, wo der Compiler genau sagen kann, worauf sich ein Ausdruck bezieht. Wenn man Magic Strings verwenden kann, um irgendwelche Funktionalität zu referenzieren, dann wirds sehr schwierig.

Gut, dynamisches Laden habe ich nicht beachtet. Für den statischen Teil wäre ein Abdeckungstest sicherlich möglich. Hm, schwierig..

Freundliche Grüße
Christian

[Christian Kruse]

Hallo Christian,

Das kann ich nur bedingt unterschreiben. Speziell Sprachen wie JavaScript oder Perl lassen sehr seltsame und unsaubere Konstrukte zu. Letztlich ist natürlich der Entwickler, der damit am Ende programmiert verantwortlich, aber ich denke, wenn die Sprache versucht da entgegen zu wirken, kann das durchaus sinnvoll sein. Ich glaube aber, dass bestimmte Programmiergruppen eher dazu neigen, unsauber zu programmieren, sodass mir das in JavaScript stärker auffällt, als beispielsweise in C++. (Das ist natürlich subjektiv aus den Projekten, die ich bisher gesehen habe.)

Ausgerechnet C++ als Beispiel anzubringen, die weniger unsaubere Konstrukte zulässt, ist aber sehr ironisch ;-)

• drei Turing-Vollständige Sprachen in einem Compiler (Templates sind seit C++11 Turing-Vollständig, der Preprozessor ist es schon länger)
• #define TRUE FALSE (happy debugging…)
• malloc vs new
• Pointer-Arithmetik
• Mehrfachvererbung

Mir fallen noch jede Menge mehr Beispiele ein, soll ich weiter machen? ;-)

LG,
CK

[Christian Wansart]

Hallo Christian,

Ausgerechnet C++ als Beispiel anzubringen, die weniger unsaubere Konstrukte zulässt, ist aber sehr ironisch ;-)

nun ja, wie gesagt, subjektiv habe ich C++-Projekte bisher als sauberer empfunden als JavaScript-Projekte. Das kann aber auch ein glücklicher Zufall sein.

Im Hochschulbereich programmiere ich zum Großteil in Java und bin damit bestens zufrieden, gerade weil es anders als C++ einige Sachen eben nicht zulässt, wie GOTO. Aber ich erkenne bei C++ an, dass es durchaus nützlich ist, wenn man ordentlich damit programmiert.

• drei Turing-Vollständige Sprachen in einem Compiler (Templates sind seit C++11 Turing-Vollständig, der Preprozessor ist es schon länger)

Ist das nun ein Für- oder Gegenargument?

• #define TRUE FALSE (happy debugging…)

Auch wenn ich das Beispiel sehr lustig finde, ist es unrealistisch. Wieso sollte man so etwas in den Quellcode schreiben? Zumal es seit C++ true und false als Schlüsselwörter gibt. :-)

Bjarne Stroustrup selbst warnt immer wieder vor der Nutzung von #define. Sie sind Bestandteil von C++ und können genutzt werden, aber außer für Header-Guards sehe ich da kaum einen vernünftigen Nutzungsgrund.

• malloc vs new

new in C++, malloc in C. Nach meinem Wissen nach ist new Typsicher, was malloc() eben nicht ist. Abgesehen davon sieht new optisch im Codefluss einfach sauberer aus, vor allem beim Arrays.

• Pointer-Arithmetik

Eine wunderbare Sache – wen man damit umgehen kann. :-) Ich glaube aber, dass das Verständnis hilfreich ist zum Allgemeinen Verständnis. Aber auch hier bietet C++11 und neuer schöne Konstrukte um Zeiger zum Großteil zu umgehen.

• Mehrfachvererbung

Ach komm, eine Raute braucht man doch tagtäglich in der Programmierung! :P

Mir fallen noch jede Menge mehr Beispiele ein, soll ich weiter machen? ;-)

Ich werde dich nicht aufhalten. :-)

Freundliche Grüße
Christian

[Christian Kruse]

Hallo Christian,

• drei Turing-Vollständige Sprachen in einem Compiler (Templates sind seit C++11 Turing-Vollständig, der Preprozessor ist es schon länger)

Ist das nun ein Für- oder Gegenargument?

Da KISS gilt: ein starkes Gegenargument.

• #define TRUE FALSE (happy debugging…)

Auch wenn ich das Beispiel sehr lustig finde, ist es unrealistisch. Wieso sollte man so etwas in den Quellcode schreiben? Zumal es seit C++ true und false als Schlüsselwörter gibt. :-)

#define true false ist auch möglich. Und es geht ja auch nicht darum, warum man das tun sollte, sondern dass man es tun kann. Du sprachst ja davon, dass die Sprache unsaubere Konstrukte zulässt.

• malloc vs new

new in C++, malloc in C. Nach meinem Wissen nach ist new Typsicher, was malloc() eben nicht ist. Abgesehen davon sieht new optisch im Codefluss einfach sauberer aus, vor allem beim Arrays.

Möglich ist es aber beides zu benutzen, und darum ging es mir hier.

• Pointer-Arithmetik

Eine wunderbare Sache – wen man damit umgehen kann. :-)

Niemand kann zuverlässig mit Pointer-Arithmetik umgehen. Der Nachweis wird seit 40 Jahren geführt: Out-Of-Bound-Fehler, Buffer Overflows und ähnliche Fehler sind zuverlässige Fehlerquellen und sorgen immer wieder für Remote-Execution-Lücken. Und das sage ich mit etwa 10 Jahren aktiver C-Erfahrung. Nicht umsonst sind Go und Rust entstanden.

LG,
CK

[Christian Wansart]

Hallo Christian,

#define true false ist auch möglich. Und es geht ja auch nicht darum, warum man das tun sollte, sondern dass man es tun kann. Du sprachst ja davon, dass die Sprache unsaubere Konstrukte zulässt.

Gut, da hast du natürlich recht.

Möglich ist es aber beides zu benutzen, und darum ging es mir hier.

Stimmt wohl.

Niemand kann zuverlässig mit Pointer-Arithmetik umgehen. Der Nachweis wird seit 40 Jahren geführt: Out-Of-Bound-Fehler, Buffer Overflows und ähnliche Fehler sind zuverlässige Fehlerquellen und sorgen immer wieder für Remote-Execution-Lücken. Und das sage ich mit etwa 10 Jahren aktiver C-Erfahrung. Nicht umsonst sind Go und Rust entstanden.

Da kann ich dir auch nicht Widersprechen. Mir ging es um das grundsätzliche Verständnis, wie Adressen und co. funktionieren, was mir programmiertechnisch mit Zeigern sehr gut abgebildet und gezeigt werden kann.

In der Hochschule gibt es einige Studenten die schon mit einfachen int[] zahlen = new int[42]; in Java Probleme haben, da sie das Konzept der Speicherallokierung nicht verstehen. Ich denke, eine Einführung in frühen Semestern in C wäre durchaus sinnvoll.

Ich freue mich aber über Entwicklungen wir Rust – es bleibt nur abzuwarten, wie stark sie in Zukunft genutzt werden.

Freundliche Grüße
Christian

[1unitedpower]

Ausgerechnet C++ als Beispiel anzubringen, die weniger unsaubere Konstrukte zulässt, ist aber sehr ironisch ;-)

• drei Turing-Vollständige Sprachen in einem Compiler (Templates sind seit C++11 Turing-Vollständig, der Preprozessor ist es schon länger)
• #define TRUE FALSE (happy debugging…)
• malloc vs new
• Pointer-Arithmetik
• Mehrfachvererbung

Mir fallen noch jede Menge mehr Beispiele ein, soll ich weiter machen? ;-)

Ja bitte, ich wollte auch schon einen Rant starten.

• Schlechtes Tooling
• Wuchernder Sprachkern (wenn man überhaupt sowas wie einen Kern identifizieren kann)
• Wuchernder Compiler
• Pointer-Arithmetik (kann man nicht oft genug sagen)
• verboses und viel kompliziertes Typsystem

[Christian Wansart]

• Schlechtes Tooling
• Wuchernder Sprachkern (wenn man überhaupt sowas wie einen Kern identifizieren kann)
• Wuchernder Compiler

Das kann ich so unterschreiben, weshalb ich mit C oder Java deutlich glücklicher bin.

• Pointer-Arithmetik (kann man nicht oft genug sagen)

Das halt ich nicht für grundsätzlich schlecht. Ich halte die Nutzung aber selbst auf ein Minimum.

• verboses und viel kompliziertes Typsystem

Du meinst wegen der Ausgaben bei Fehlern? Insgesamt ziehe ich starke Typisierung einer dynamischen Typisierung vor.

Freundliche Grüße
Christian

[Christian Kruse]

Hallo Christian,

• verboses und viel kompliziertes Typsystem Du meinst wegen der Ausgaben bei Fehlern? Insgesamt ziehe ich starke Typisierung einer dynamischen Typisierung vor.

Das sehe ich auch so, aber das Typ-System ist einfach zu komplex; wie gesagt, Templates sind in C++11 Turing-Vollständig. Das Typ-System(!) ist Turing-Vollständig. Mal abgesehen davon, dass das Typ-System nicht viel wert ist, wenn ich jederzeit ein (int *)(void *) machen kann:

➜ ckruse@vali ~  % cat test.cpp

#include <iostream>

int main(void) {
  float a = 1.0;
  int *b = (int *)(void *)&a;
  std::cout << *b << "\n";
  return 0;
}

➜ ckruse@vali ~  % g++ -Wall -o test test.cpp
➜ ckruse@vali ~  % ./test
1065353216
➜ ckruse@vali ~  %

Der Umweg über (void *) um zu verdeutlichen, dass ich wirklich beliebige Objekte casten kann.

Beispiele für gute Typ-Systeme sind IMHO Haskell und Rust (wobei sich Rust sehr stark bei Haskell bedient hat).

LG,
CK

[Christian Wansart]

Hallo Christian,

Dankeschön für das Beispiel.

Absolut, Haskell ist da sehr interessant, allerdings sehe ich dafür kaum eine relevante Stellung in der Zukunft, was sehr schade ist. Den Ansatz von Rust mag ich auch sehr, und würde mir sehr wünschen, dass die Sprache eine einigermaßen nennenswerte Verbreitung erreichen könnte!

Freundliche Grüße
Christian

[1unitedpower]

Absolut, Haskell ist da sehr interessant, allerdings sehe ich dafür kaum eine relevante Stellung in der Zukunft, was sehr schade ist. Den Ansatz von Rust mag ich auch sehr, und würde mir sehr wünschen, dass die Sprache eine einigermaßen nennenswerte Verbreitung erreichen könnte!

Haskell, oder allgemeiner funktionale Sprachen, haben sehr interessante Einsatzgebiete. Etwa in allen Bereichen, in denen Software-Fehler unfassbaren finanziellen oder humanitären Schaden anrichten können. Naturkatastrophen-Frühwarnsysteme nutzen zum Beispiel oft funktionale Sprachen, weil damit eine formale Verifikation sicherheitskritischer Software-Systeme besser möglich ist als mit uneingeschränkten Programmiersprachen.

Facebook benutzt Haskell interessanterweise für seinen Spamfilter. Bei der Spam-Bekämpfung gibt es ein Kopf-an-Kopf-Rennen mit den Spam-Verteilern, das unglücklicherweise zu Gunsten der Verteiler abläuft. Die Entwickler eines Spamfilters können immer nur nachziehen, da ist es also umso wichtiger schnell agieren zu können, also die Entwicklungszeit neuer Filter-Strategien möglichst kurz zu halten, und gleichzeitig keine neuen Fehler ins Programm einzuführen. Da liegen genau Haskells Stärken.

Ich sehe die Sprache auch nicht als vielversprechenden Kandidaten auf eine einen Stammplatz im Establishment. Das Vermächtnis von Haskell ist der Einfluss, den es auf die Entwicklung moderner Sprachen ausübt. Ohne Haskell kein Rust oder Swift.

[1unitedpower]

• verboses und viel kompliziertes Typsystem Du meinst wegen der Ausgaben bei Fehlern?

Nein, das meine ich nicht. Die Fehlererkennung vor der Laufzeit ist ja gerade der Clue bei Typsystemen, und je mehr Fehler man auf diese Weise aufdecken kann, desto besser.

Insgesamt ziehe ich starke Typisierung einer dynamischen Typisierung vor.

C++ ist schwach und statisch typisiert, das heißt das einige Typfehler zwar vom Compiler erkannt werden können (das ist die statische Komponenten), aber dass zur Laufzeit trotzdem noch Typfehler auftreten können (das ist die schwache Komponente).

Worauf ich eigentlich hinaus wollte: Das C++ Typsystem ist irre kompliziert und sehr langatmig, mindestens auf zwei Weisen: Es gibt nur wenige Typinferenz-Regeln, das heißt Typannotationen müssen in den meisten Fällen ausgeschrieben werden. Und zweitens werden Typannotationen oft über Teilausdrücke fragmentiert, das macht sie schlechter lesbar. Ein Beispiel aus der Wikipedia.

vector<int> pick_vector_with_biggest_fifth_element(
    vector<int> left,
    vector<int> right
)

Der Rückgabewert der Funktion wird vor der Definition notiert, die Typen für die Parameter innerhalb der formalen Parameterliste. Ich bevorzuge da Typannotationen wie in funktionalen Sprachen. In PureScript würde man diesen Typen zum Beispiel so angeben:

pick_vector_with_biggest_fifth_element :: (Vector Int, Vector Int) -> Vector Int

(Mit Haskell-Syntax-Highlighting, weil 's besser aussieht).

Darüber hinaus finde ich das Typsystem kompliziert in dem Sinne, dass ihm kein formales Schema zugrunde liegt und seine Regeln deshalb schwer zu erfassen sind. Es kann nicht mit mathematischen Theorien auf diesem Gebiet (Typtheorie, Beweistheorie oder Kategorientheorie) erklärt werden. Das mag ziemlich realitätsverdrossen klingen, aber es führt in der Praxis einfach dazu, dass man viele Datentypen immer wieder neu definiert anstatt sie durch geeignete Spezialisierungen abstrakterer Typen zu definieren (Functor, Monoid, Monad, Comonad etc.). Algebraische Typsysteme sind insofern simpler, als dass ihre Regeln sehr transparent und nachvollziehbar sind – nicht simpler im Sinne von "einfacher zu erlernen".

[Christian Wansart]

Dankeschön für deine ausführliche Antwort. Ich denke, ich kann nachvollziehen was du meinst.

Es ist aber interessant, dass sich trotz deiner Argumentation, sich Sprachen wie C++ durchgesetzt haben. Hmm…

Freundliche Grüße
Christian

[Christian Kruse]

Hallo Christian,

Es ist aber interessant, dass sich trotz deiner Argumentation, sich Sprachen wie C++ durchgesetzt haben. Hmm…

Naja, die Typen-Theorie ist eine Sache der „Neuzeit” (haha!) in der Computer-Technik. Damals[tm] konnte man das erstens gar nicht umsetzen (mangels Rechenzeit) und zweitens waren die theoretischen Grundlagen noch nicht vorhanden. Dazu kommt, dass man noch nicht so viel Erfahrung in komplexer Software-Entwicklung hatte.

LG,
CK

[Christian Wansart]

Hallo Christian,

das leuchtet mir ein. Na dann bin ich mal gespannt, was sich in den nächsten Jahren tun wird. Laut TIOBE-Index erfreut sich Java einer neuen Beliebtheit – wobei man diese Indizes natürlich nur mit Vorsicht genießen sollte. :-)

Freundliche Grüße
Christian

[dedlfix]

Tach!

Meine Lösung: gleich auf dem eigenen Server laden. Wenn mein Server nicht erreichbar ist, ist die Webseite sowieso nicht erreichbar. Scheint für mich am sinnvollsten, anstatt sich auf andere verlassen zu müssen.

Ja, in Punkto Ausfallsicherheit, aber nicht in Punkto Ladeoptimierung.

Auch dann wäre nicht die Programmiersprache schuld.

Das kann ich nur bedingt unterschreiben. Speziell Sprachen wie JavaScript oder Perl lassen sehr seltsame und unsaubere Konstrukte zu.

Zeig mir das Werkzeug, das universell einsetzbar ist und keine Unsauberkeit zulässt. Abgesehen davon, dass man sich erstmal auf Unsauberkeit einigen müsste.

Und nein, ich bin kein Python-Freund, deren Syntax mag ich persönlich genauso wenig.

Das hilft auch nur, Disziplin beim Einrücken zu halten.

dedlfix.

[Christian Wansart]

Guten Tag,

Ja, in Punkto Ausfallsicherheit, aber nicht in Punkto Ladeoptimierung.

Du meinst, dass es schneller geht, wenn ich einen fremden Server erst anfragen muss?

Zeig mir das Werkzeug, das universell einsetzbar ist und keine Unsauberkeit zulässt. Abgesehen davon, dass man sich erstmal auf Unsauberkeit einigen müsste.

Gutes Argument, du hast da recht.

Freundliche Grüße
Christian

[dedlfix]

Tach!

Ja, in Punkto Ausfallsicherheit, aber nicht in Punkto Ladeoptimierung.

Du meinst, dass es schneller geht, wenn ich einen fremden Server erst anfragen muss?

Der Punkt ist ja, dass der Browser weder im CDN noch bei dir anfragen muss, weil er es wegen anderer Gelegenheiten schon im Chache hat. Die Wahrscheinlichkeit beim CDN ist dabei vergleichsweise hoch.

Die Ladezeit beim Cache-Miss ist auch nicht mit Sicherheit vorhersagbar.

dedlfix.

[Christian Wansart]

Guten Tag,

Der Punkt ist ja, dass der Browser weder im CDN noch bei dir anfragen muss, weil er es wegen anderer Gelegenheiten schon im Chache hat. Die Wahrscheinlichkeit beim CDN ist dabei vergleichsweise hoch.

Die Ladezeit beim Cache-Miss ist auch nicht mit Sicherheit vorhersagbar.

Ach so, du meinst weil dieses Framework aufgrund großer Verbreitung häufig auf vielen verschiedenen Seiten eingebunden wurde. Das macht schon Sinn.

Nach meinen Tests war das Laden vom eigenen Server schneller. Aber dazu muss ich natürlich auch sagen, dass ich bei den Lade-Tests den Cache geleert habe.

Danke für den Einwand, ich muss das unbedingt mal testen.

Freundliche Grüße
Christian

[Matthias Apsel]

Hallo Christian Wansart,

Ja, in Punkto Ausfallsicherheit, aber nicht in Punkto Ladeoptimierung.

Du meinst, dass es schneller geht, wenn ich einen fremden Server erst anfragen muss?

Nein. Die Wahrscheinlichkeit, dass sich eine bestimmte Ressource schon im Cache des Browsers befindet, ist recht hoch. Zugegeben, das betrifft nur die Erstbesuche. Danach ist ja auch deine Ressource gecached.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Nein. Die Wahrscheinlichkeit, dass sich eine bestimmte Ressource schon im Cache des Browsers befindet, ist recht hoch.

Genau genommen stimmt das nicht. Da gab es mal eine Statistik… such ah ja:

40-60% of Yahoo!'s users have an empty cache experience and ~20% of all page views are done with an empty cache.

Diese Zahlen sind enorm.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

40-60% of Yahoo!'s users have an empty cache experience and ~20% of all page views are done with an empty cache.

Diese Zahlen sind enorm.

Aber auch neun Jahre alt. Und auch diese Nutzer hätten keinen Nachteil bei Verwendung eines CDN. Aber ich will hier auch niemandem etwas aufquatschen, dazu habe ich zu wenig Erfahrung in solchen Dingen.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Aber auch neun Jahre alt.

Das mag sein, aber es gibt meines Wissens nach keine neueren Daten, die diese Statistik widerlegen.

Und auch diese Nutzer hätten keinen Nachteil bei Verwendung eines CDN.

Ich wollte nicht gegen ein CDN argumentieren, CDNs ergeben aus Performance-Sicht Sinn. Ich wollte nur darauf hinweisen, dass deine Argumentation nicht notwendigerweise richtig ist.

LG,
CK

[Christian Wansart]

Hallo Matthias, hallo Christian,

Ich wollte nicht gegen ein CDN argumentieren, CDNs ergeben aus Performance-Sicht Sinn. Ich wollte nur darauf hinweisen, dass deine Argumentation nicht notwendigerweise richtig ist.

Wie schon geschrieben, habe ich das anders erfahren. Ich bin mir gerade nicht ganz sicher, ich meine dazu gestern im Wiki etwas dazu gelesen zu haben, also verzeiht meine naive Frage: Wäre es dann nicht sinnvoll, einfach den CSS-Code in den head einzubetten? Dann spare ich mir jede unnötige Anfrage und habe den einzubindenden Code auch schon.

Fefes Blog zum Beispiel: 1 Anfrage, 0,24 s zum Laden mit leeren Cache.

Wie gesagt, nur eine naive Frage. :-)

Herzlichen Dank.

Freundliche Grüße
Christian

[Matthias Apsel]

Hallo Christian Wansart,

Wäre es dann nicht sinnvoll, einfach den CSS-Code in den head einzubetten? Dann spare ich mir jede unnötige Anfrage und habe den einzubindenden Code auch schon.

Nein, das wäre nicht sinnvoll, weil du dann den CSS-Code für jede Seite deiner Webpräsenz wieder und wieder überträgst und das Caching wirkungsvoll behinderst.

Bis demnächst
Matthias

[Christian Wansart]

Hallo Matthias,

ja stimmt, das war das, was ich gestern im Wiki las.

Ich muss gestehen, dass ich zuvor nicht davor darüber nachgedacht habe. Macht aber Sinn. Danke.

Freundliche Grüße
Christian

[Gunnar Bittersmann]

@@Christian Wansart

Wäre es dann nicht sinnvoll, einfach den CSS-Code in den head einzubetten? Dann spare ich mir jede unnötige Anfrage und habe den einzubindenden Code auch schon.

Ja, das ist aus Performanz-Sicht durchaus sinnvoll. Deshalb machen das etliche Websites auch.

Allerdings nicht das gesamte Stylesheet, sondern nur diejenigen Regeln, die zum Rendern des ursprünglich sichtbaren Teils der Homepage (alles above the fold) nötig sind.

„CSS critical path“ ist der Suchbegriff.

Das ganze Stylesheet wird als externe Ressource geladen, asynchron mit JavaScript, damit das Rendern der Seite nicht geblockt wird. (Oder mit link-Element im body?)

LLAP 🖖

[dedlfix]

Tach!

Nein. Die Wahrscheinlichkeit, dass sich eine bestimmte Ressource schon im Cache des Browsers befindet, ist recht hoch.

Genau genommen stimmt das nicht. Da gab es mal eine Statistik… such ah ja:

Other reasons include:

• The user visited the page previously but cleared the browser cache.
• The browser cache was automatically cleared, based on the browser's settings.
• The user reloaded the page in a way that caused the cache to be bypassed. For example, the browser will bypass the cache if you hold down the control-shift key while clicking the Refresh button in Internet Explorer.

Wenn der Anwender meine Cache-Bemühungen auf einer der obigen Weisen torpediert, kann ich nicht viel machen. Dann dauert aber das Laden in jedem Fall.

Dass trotzdem noch die anderen Methoden, wie Reduzierung der Requests und Traffic durch Zusammenfassen und Komprimieren, angewendet werden, setze ich mal voraus.

40-60% of Yahoo!'s users have an empty cache experience and ~20% of all page views are done with an empty cache.

Diese Zahlen sind enorm.

Leider kann bei der verwendeten Messmethode nicht aufgeschlüsselt werden, welche Gründe für den leeren Cache konkret vorlagen. Die obig zitierten sind ja nur Möglichkeiten.

dedlfix.

[Auge]

Hallo

Es wäre natürlich schön, wenn mein Firefox etwas schneller starten würde, aber er ist nun nicht so langsam, dass ich das als störend empfinden würde. Es bleibt dahingehend spannend, wenn Mozilla Firefox-Komponenten gegen in Rust geschriebene Komponenten austauscht und die UI möglicherweise mit Webtechnologien gebaut wird – meine Befürchtung ist aber, dass das Aufsetzen auf JavaScript in der Firefox-Benutzeroberfläche ein Fehler ist und den Browser unnötig verlangsamen wird.

Die Firefox-UI wird seit jeher mit Webtechniken (XUL) gerendert und auch von JavaScript wird reichlich Gebrauch gemacht (mindestens die Addons). Aber ja, schneller und flüssiger dürfte er gerne sein. Er sollte auch den Arbeitsspeicher nicht auffressen, was ja ein, wenn nicht der Grund für das hakelige Verhalten ist.

Mal sehen, was sich in dieser Hinsicht tut.

Tschö, Auge

[Christian Wansart]

Hallo Auge,

Die Firefox-UI wird seit jeher mit Webtechniken (XUL) gerendert und auch von JavaScript wird reichlich Gebrauch gemacht (mindestens die Addons). Aber ja, schneller und flüssiger dürfte er gerne sein. Er sollte auch den Arbeitsspeicher nicht auffressen, was ja ein, wenn nicht der Grund für das hakelige Verhalten ist.

Ja gut, das stimmt schon, aber ich frage mich, ob das Austauschen der einen Sprache durch eine andere mehr Performance bringt. Ich bin da doch sehr skeptisch.

Was das Aufressen des Arbeitsspeichers angeht, kann ich deine Haltung nicht nachvollziehen. Firefox frisst laut aktuellen Tests deutlich weniger. Auch in einem Selbsttest konnte ich das bestätigen. Chrome hingegen frisst den RAM auf.

Freundliche Grüße
Christian

[Auge]

Hallo

Die Firefox-UI wird seit jeher mit Webtechniken (XUL) gerendert und auch von JavaScript wird reichlich Gebrauch gemacht (mindestens die Addons). Aber ja, schneller und flüssiger dürfte er gerne sein. Er sollte auch den Arbeitsspeicher nicht auffressen, was ja ein, wenn nicht der Grund für das hakelige Verhalten ist.

Ja gut, das stimmt schon, aber ich frage mich, ob das Austauschen der einen Sprache durch eine andere mehr Performance bringt. Ich bin da doch sehr skeptisch.

Die Ausführungsgeschwindigkeit von Code in verschiedenen Sprachen unterscheidet sich schon. Rust soll ja recht schnell sein.

Was das Aufressen des Arbeitsspeichers angeht, kann ich deine Haltung nicht nachvollziehen. Firefox frisst laut aktuellen Tests deutlich weniger. Auch in einem Selbsttest konnte ich das bestätigen. Chrome hingegen frisst den RAM auf.

Der von dir verlinkte Test arbeitet mit gerade einmal fünf offenen Tabs.

„… one window with a Facebook page, a YouTube video, a BBC News article, the Microsoft Outlook web app and the IT Pro homepage open in separate tabs.“

Das halte ich für Pillepalle**[edit]** und auch 412 MB RAM-Verbrauch sind kein Pappenstiel**[/edit]**.

Ich benutze von den getesteten Diensten bestenfalls gelegentlich Youtube und noch viel gelegentlicher die BBC-News. Es ist für mich aber normal, weitaus mehr als fünf Tabs offen zu haben. Momentan sind es z.B. 20 Tabs, manchmal aber auch mehr. Performanceprobleme habe ich momentan nicht. Bis auf das SelfHTML-Forum (mit vier Tabs) und Github (ein Tab) befinden sich momentan in allen anderen Tabs auch nur statische Inhalte mit wenigen Grafiken.

Manchmal verreckt mit der Firefox schon bei fünf bis sieben Tabs, gerne bei Tabs mit JS- und/oder Multimedia-Gebamsel, manchmal bei 25 oder mehr Tabs, manchmal garnicht. Schön – und vor allem zuverlässig – ist anders. Ob andere Browser, die ich nicht nutze, noch ineffektiver mit RAM umgehen, interessiert mich als Nutzer des Firefox allerdings überhaupt nicht.

Tschö, Auge

[Gunnar Bittersmann]

@@Christian Wansart

Du hast im übrigen „tote Links“ unten bei den Workshops. Die Slides von „Frontend Development in-company, 2014-01-28“ existieren wohl nicht mehr.

Ich hatte die einzelnen Teile zu einem Ganzen zusammengesetzt und vergessen, den Link zu ändern. Danke fürs Bescheidgeben.

LLAP 🖖

[pl]

Wenn ich mir die Beiträge zu Herzen nehme, ist dann eine solche Umsetzung überhaupt möglich? Habt ihr Tipps und Anregungen, wie man da vorgehen kann?

Es sei eine Anwendung gegeben derart, dass Einträge einer langen Liste editierbar gemacht werden sollen.

Herkömmlich: Klick drauf und eine neue Seite wird geladen die ein Formular enthält. Klick dann auf Speichern, wird wieder die Liste geladen und wenns gut gemacht ist mit dem Anker, landest Du wieder auf dem zuletzt bearbeiteten Listeneintrag.

Modern: Das Formular zum Bearbeiten liegt bereits unter der Liste. Es wird erst sichtbar gemacht, wenn ein Eintrag zum Bearbeiten angeklickt wurde. Der Speichervorgang wird in 2 Prozesse aufgeteilt, ein einfaches Speichern schickt die Daten nur zum Server ohne das Formular neu zu laden. Erst der Fertig-Button schickt das Formular wieder in den Hintergrund und blendet die Liste ohne Änderung der Scrollposition ein.

So ich denke es ist klar, was benutzerfreundlicher ist und es gibt wohl einige Dinge die bereits im Browser erledigt werden können infolge sinnvoller Verwendung von JS ohne ganze Seiten via HTTP hinundher zu schicken. Wer unbedingt ein Submit haben will, sollte sich den HTTP Status 204 mal angucken. Damit bleibt ein Formular auch im Browser stehen und nur die Daten gehen raus zum Server.

[Gunnar Bittersmann]

@@pl

Modern: Das Formular zum Bearbeiten liegt bereits unter der Liste. Es wird erst sichtbar gemacht, wenn ein Eintrag zum Bearbeiten angeklickt wurde.

Oder es wird erst dann mit JavaScript generiert. Wie wolltest du festzuhalten, welcher Beitrag zum Bearbeiten angeclickt wurde? Nicht auch mit JavaScript? Oder mit Radiobutton an jedem Beitrag?

Der Speichervorgang wird in 2 Prozesse aufgeteilt, ein einfaches Speichern schickt die Daten nur zum Server ohne das Formular neu zu laden. Erst der Fertig-Button schickt das Formular wieder in den Hintergrund und blendet die Liste ohne Änderung der Scrollposition ein.

Zwei Buttons – „Speichern“ und „Fertig“ – dürften die Nutzer verwirren. Weg mit dem einen!

“Design isn’t crafting a beautiful, textured button. It’s figuring out if there’s a way to get rid of the button altogether.” —Edward Tufte

Ein „Speichern“-Button reicht. Wenn man doch noch nicht fertig war, drückt man halt noch mal „Beitrag bearbeiten“ und öffnet das Formular erneut.

Und „modern“ geht noch etwas anders: „Speichern“ schickt die Daten erstmal nicht zum Server, sondern speichert sie lokal und aktualisiert die Anzeige. Wenn Verbindung zum Internet besteht, werden die Daten mit dem Server synchronisiert. Wenn nicht, passiert das später, sobald wieder Internetverbindung da ist – im Hintergrund, ohne dass sich der Nutzer darum kümmern müsste. Offline first.

LLAP 🖖

[Der Martin]

Hallo,

Der Speichervorgang wird in 2 Prozesse aufgeteilt, ein einfaches Speichern schickt die Daten nur zum Server ohne das Formular neu zu laden. Erst der Fertig-Button schickt das Formular wieder in den Hintergrund und blendet die Liste ohne Änderung der Scrollposition ein.

Zwei Buttons – „Speichern“ und „Fertig“ – dürften die Nutzer verwirren. Weg mit dem einen!

ja, unbedingt.

Und „modern“ geht noch etwas anders: „Speichern“ schickt die Daten erstmal nicht zum Server, sondern speichert sie lokal und aktualisiert die Anzeige. Wenn Verbindung zum Internet besteht, werden die Daten mit dem Server synchronisiert. Wenn nicht, passiert das später, sobald wieder Internetverbindung da ist – im Hintergrund, ohne dass sich der Nutzer darum kümmern müsste.

Klingt gut, nur ... später, wenn die Verbindung zum Server wieder steht, hat der Nutzer den Browser längst geschlossen. In dem beruhigenden Glauben, dass er die Änderungen ja gespeichert hatte.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Klingt gut, nur ... später, wenn die Verbindung zum Server wieder steht, hat der Nutzer den Browser längst geschlossen. In dem beruhigenden Glauben, dass er die Änderungen ja gespeichert hatte.

Der Service Worker sollte sich das merken, was beim nächsten Aufruf der Seite noch zu synchronisieren ist.

Aber ja, eine Anzeige, ob die Daten gerade mit dem Server aktualisiert sind, könnte durchaus nützlich sein.

LLAP 🖖

[Christian Wansart]

Zwei Buttons – „Speichern“ und „Fertig“ – dürften die Nutzer verwirren. Weg mit dem einen!

Und was machst du bei einer Übersicht, also im Backend wo ein angemeldeter Nutzer Elemente für das Frontend für die Endnutzer erstellt? Wie zum Beispiel in einem Forum, wo der Administrator Kategorien und Foren erzeugt, braucht er ja eine gewisse Liste. Zeigst du da einfach alle Buttons für jede Kategorie und jedes Forum an?

In meinem Projekt hatten wir das zu Anfang, sind jedoch zu einem einfachen Dropdown-Menü (verzeih mir, auf Bootstrap-Basis) gewechselt, da es – zumindest optisch – einfacher zu handhaben ist, aber wenn man durch die vielen Buttons „erschlagen“ wird.

Die Änderungen gehen aus den Befragungen des „Kunden“ hervor.

Und „modern“ geht noch etwas anders: „Speichern“ schickt die Daten erstmal nicht zum Server, sondern speichert sie lokal und aktualisiert die Anzeige. Wenn Verbindung zum Internet besteht, werden die Daten mit dem Server synchronisiert. Wenn nicht, passiert das später, sobald wieder Internetverbindung da ist – im Hintergrund, ohne dass sich der Nutzer darum kümmern müsste. Offline first.

Ein interessanter Ansatz, der aber voraussetzt, dass der PC aktiviert, der Browser sowie der Tab geöffnet bleibt, oder sehe ich das falsch? Gut, man könnte natürlich die Daten auch mit local storage zwischenspeichern und beim erneuten Laden der Seite prüfen, ob sich noch nicht gesendete Daten im local storage befinden.

Besten Dank.
Lebe Lang und in Frieden!

[dedlfix]

Tach!

Zwei Buttons – „Speichern“ und „Fertig“ – dürften die Nutzer verwirren. Weg mit dem einen!

Und was machst du bei

Jeder Fall muss für sich individuell betrachtet werden. Eine allgemeine Antwort darauf zu geben oder haben zu wollen läuft quasi auf das Framework-vs-Individualität-Problem hinaus. Entweder es passt vielen, ist aber einigen zu groß oder zu klein, oder es passt wie angegossen, aber anderen gar nicht. Und dazwischen noch jede Menge Grautöne.

einer Übersicht, also im Backend wo ein angemeldeter Nutzer Elemente für das Frontend für die Endnutzer erstellt? Wie zum Beispiel in einem Forum, wo der Administrator Kategorien und Foren erzeugt, braucht er ja eine gewisse Liste. Zeigst du da einfach alle Buttons für jede Kategorie und jedes Forum an?

Kommt drauf an. Vielleicht wäre die bessere Lösung statt alles gleichzeitig oder alles erstmal versteckt ein Mittelweg wie beim Menü vom Mediawiki. Die hauptsächlich verwendeten Funktionen sind gleich da, der Rest nach dem Aufklappen.

(verzeih mir, auf Bootstrap-Basis)

Du musst dich dafür bei keinem Evangelisten entschuldigen. Allein mit deinem eigenen Gewissen und/oder deinem Auftraggeber musst du grün sein. Evangelisten können nicht mehr als einer von mehreren Ratgebern sein, denn sie kennen in der Regel auch nicht alle deine Gegebenheiten.

Und „modern“ geht noch etwas anders: „Speichern“ schickt die Daten erstmal nicht zum Server, sondern speichert sie lokal und aktualisiert die Anzeige. Wenn Verbindung zum Internet besteht, werden die Daten mit dem Server synchronisiert. Wenn nicht, passiert das später, sobald wieder Internetverbindung da ist – im Hintergrund, ohne dass sich der Nutzer darum kümmern müsste. Offline first.

Ein interessanter Ansatz, der aber voraussetzt,

... dass der Anwendungsfall das zulässt. Das ist meist nur dann gegeben, wenn man allein an einem Dokument/System arbeitet. Sobald man etwas gemeinsam oder in Konkurrenz zueinander erledigen muss, ist das nicht unbedingt eine gescheite Vorgehensweise.

dedlfix.

[Christian Wansart]

Guten Morgen,

Jeder Fall muss für sich individuell betrachtet werden. Eine allgemeine Antwort darauf zu geben oder haben zu wollen läuft quasi auf das Framework-vs-Individualität-Problem hinaus. Entweder es passt vielen, ist aber einigen zu groß oder zu klein, oder es passt wie angegossen, aber anderen gar nicht. Und dazwischen noch jede Menge Grautöne.

Ja, natürlich. Diese Frage geht bei mir aus einer Projektwoche über die Projekte bis zu jetzigen Zeit zurück. Dort haben wir eine Webseite für einen Kulturverein auf Basis von Wordpress erstellt und es hatte mich so unglaublich frustriert, dass das Backend mit den genutzt Plugins am Smartphone schlichtweg nicht nutzbar war, dabei wäre genau das sehr praktisch gewesen.
In meinem aktuellen Projekt ist das weniger nützlich, da solche Quiz eher am PC erstellt werden, da hier Grafiken, Quellcode als auch LaTeX genutzt wird. Schön wäre es allerdings trotzdem, aber mit dem aktuellen HTML/CSS ist das nicht möglich ohne hin- und herzuscrollen.

Kommt drauf an. Vielleicht wäre die bessere Lösung statt alles gleichzeitig oder alles erstmal versteckt ein Mittelweg wie beim Menü vom Mediawiki. Die hauptsächlich verwendeten Funktionen sind gleich da, der Rest nach dem Aufklappen.

Du meinst das auf der linken Seite?

Du musst dich dafür bei keinem Evangelisten entschuldigen. Allein mit deinem eigenen Gewissen und/oder deinem Auftraggeber musst du grün sein. Evangelisten können nicht mehr als einer von mehreren Ratgebern sein, denn sie kennen in der Regel auch nicht alle deine Gegebenheiten.

Ich habe mich einige Zeit mit verschiedenen Themen hier im Forum auseinandergesetzt, und speziell bei Gunnar fiel auf, dass er aufgrund sicherlich guter Gründe kein Freund von diesen Frameworks ist. Ich finde diese Haltung interessant und versuche sie zu verstehen, da ich glaube, ohne gleich zu 100 % ihm nachzureden, Vorteile und Verbesserungen für mich selbst daraus herausziehen kann. :-)

Ich denke also, dass ich ihn verstehe und habe mich entsprechend daraufhin entschuldigt. Ich meine, vielleicht irrt er sich und die aktuelle Entwicklung führt dahin, dass neue Reader auch den „unsauberen Code“ interpretieren können. Oder aber vielleicht irrst du dich und in ein paar Jahren bekommt man keinen Arbeitsplatz mehr, wenn man nicht versucht es so zu machen wir er – gut, das Beispiel ist sicherlich übertrieben, aber worauf ich hinaus will: ich nehme einfach alles mit und versuche für mich das beste davon mitzunehmen.

Danke für deine Einsicht! :-)

... dass der Anwendungsfall das zulässt. Das ist meist nur dann gegeben, wenn man allein an einem Dokument/System arbeitet. Sobald man etwas gemeinsam oder in Konkurrenz zueinander erledigen muss, ist das nicht unbedingt eine gescheite Vorgehensweise.

Machbar schon, beim Mediawiki geht es ja auch. Da wird, wenn ich mich nicht täusche, dann ein diff angezeigt. (Angabe ohne Gewähr.)

Freundliche Grüße
Christian

[dedlfix]

Tach!

Kommt drauf an. Vielleicht wäre die bessere Lösung statt alles gleichzeitig oder alles erstmal versteckt ein Mittelweg wie beim Menü vom Mediawiki. Die hauptsächlich verwendeten Funktionen sind gleich da, der Rest nach dem Aufklappen.

Du meinst das auf der linken Seite?

Das in der oberen Leiste, in der die Bearbeitungsfunktionen sitzen.

Ich habe mich einige Zeit mit verschiedenen Themen hier im Forum auseinandergesetzt, und speziell bei Gunnar fiel auf, dass er aufgrund sicherlich guter Gründe kein Freund von diesen Frameworks ist. Ich finde diese Haltung interessant und versuche sie zu verstehen, da ich glaube, ohne gleich zu 100 % ihm nachzureden, Vorteile und Verbesserungen für mich selbst daraus herausziehen kann. :-)

Ich glaube eher, er ist generell kein Freund von Dingen, die nicht seinem Ideal entsprechen, egal ob die von einem Werkzeug oder per Hand erzeugt wurden. Er ist sicher auch kein Freund von Webseiten, die auf Bootstrap verzichten und dann ein noch schlechteres Ergebnis entsteht. Diverse Zwänge erfordern, dass Ideale zugunsten von Kompromissen aufgegeben werden müssen. Ich versuche deshalb nicht nur das Ideal zu kennen, sondern auch die Zwänge. Denn auch wenn ich eigentlich perfektionistisch veranlagt bin, weiß ich auch, dass es nicht perfekt ist, wenn man immer nur zu gewinnen versucht und das Umfeld dabei auf der Strecke bleibt.

Ich verwende Bootstrap, weil es mir hilft, ein angenehmes Aussehen zu erzeugen, obwohl ich in gestalterischer Hinsicht Mägel habe, die sich auch mit intensivem Lernen nicht ausgleichen lassen. Da nützen mir auch keine markigen Sprüche vom verlorenen Designerherzen, wenn ich nie eins hatte und haben werde. Gleichwohl kann ich aber auch Dinge technisch so umsetzen, wie es künstlerisch eher Begabte entworfen haben und kann dann auch meine Meinung sagen, wenn ich Mängel im Konzept oder der Bedienung zu erkennen meine.

ich nehme einfach alles mit und versuche für mich das beste davon mitzunehmen.

Danke für deine Einsicht! :-)

Mach dir mal nicht zu viele Gedanken um meine Einsicht. Es gibt Dinge, da sollte man weiterhin in der Sache argumentieren, auch wenn man die Hoffnung auf Einsicht beim Gegenüber aufgegeben hat.

dedlfix.

[Christian Wansart]

Guten Tag,

Das in der oberen Leiste, in der die Bearbeitungsfunktionen sitzen.

ah danke!

Ich glaube eher, er ist generell kein Freund von Dingen, die nicht seinem Ideal entsprechen, egal ob die von einem Werkzeug oder per Hand erzeugt wurden. Er ist sicher auch kein Freund von Webseiten, die auf Bootstrap verzichten und dann ein noch schlechteres Ergebnis entsteht. Diverse Zwänge erfordern, dass Ideale zugunsten von Kompromissen aufgegeben werden müssen.

Möglicherweise hast du Recht, aber selbst wenn, dann hat seine Art dazu geführt, dass ich mich nun in die Themen, speziell Barrierefreiheit einlese. Er wird ja vermutlich nicht hinter dir mit einer Axt auftauchen, wenn du seine Meinung nicht zu 100 % teilst.

Ich versuche deshalb nicht nur das Ideal zu kennen, sondern auch die Zwänge. Denn auch wenn ich eigentlich perfektionistisch veranlagt bin, weiß ich auch, dass es nicht perfekt ist, wenn man immer nur zu gewinnen versucht und das Umfeld dabei auf der Strecke bleibt.

Das kenne ich sehr gut. Ich bessere gerne nach und versuche möglichste das Optimale herauszuholen. Leider fehlt mir da häufig noch die Einsicht etwas „unperfekt“ zu belassen.

Ich verwende Bootstrap, weil es mir hilft, ein angenehmes Aussehen zu erzeugen, obwohl ich in gestalterischer Hinsicht Mägel habe, die sich auch mit intensivem Lernen nicht ausgleichen lassen. Da nützen mir auch keine markigen Sprüche vom verlorenen Designerherzen, wenn ich nie eins hatte und haben werde. Gleichwohl kann ich aber auch Dinge technisch so umsetzen, wie es künstlerisch eher Begabte entworfen haben und kann dann auch meine Meinung sagen, wenn ich Mängel im Konzept oder der Bedienung zu erkennen meine.

Gut, das kann ich nachvollziehen. Ich nutze es grundsätzlich um mir Anfangs Zeit zu ersparen, da ich mich bei dem aktuellen Projekt zuerst auf das Backend konzentrierte. Grundsätzlich finde ich Bootstrap aber eher hässlich und monoton, wenn man es auf zig Webseiten vorfindet.

Mach dir mal nicht zu viele Gedanken um meine Einsicht. Es gibt Dinge, da sollte man weiterhin in der Sache argumentieren, auch wenn man die Hoffnung auf Einsicht beim Gegenüber aufgegeben hat.

Nun ja, man muss bei einer Diskussion ja nicht zu einem einzigen Schluss kommen. Ich denke es hilft aber um über sich selbst und seinen Aussagen zu reflektieren. Ich irre mich häufig und bin froh, wenn man mich entsprechend auf meine Fehler hinweist. Ich denke aber auch, dass andere durch Diskussionen, ähnlich wie ich profitieren können. Da hilft es, wenn man versucht sein Gegenüber zu verstehen, auch ohne dass man seine Meinung unbedingt teilen muss.

Freundliche Grüße
Christian

[pl]

Hier ist ein Beispiel, wo Differenzen angezeigt werden, bspw., wenn Daten im Browser geändert wurden. So kann der Anwender entscheiden, ob er die Änderungen übernimmt oder ohne Speichern rausgeht. Bei herkömmlichen Desktop-Programmen ist eine solche Benutzerführung seit Urzeiten gang und gäbe: Niemand würde bei einem Schreibprogramm erwarten, dass bei jedem Speichervorgang der Client neu geladen wird. Warum also sollte das bei einem Backend so sein!? Die Anwort musst Du freilich selber finden, ich geb hier nur ein paar gute Ideen weiter. Keine Ursache.

[MudGuard]

Hi,

Und „modern“ geht noch etwas anders: „Speichern“ schickt die Daten erstmal nicht zum Server, sondern speichert sie lokal und aktualisiert die Anzeige. Wenn Verbindung zum Internet besteht, werden die Daten mit dem Server synchronisiert. Wenn nicht, passiert das später, sobald wieder Internetverbindung da ist – im Hintergrund, ohne dass sich der Nutzer darum kümmern müsste. Offline first.

und damit werden dann später durch andere User getätigte Änderungen überbügelt ...

(was man natürlich auch abfangen könnte, aber das macht noch mehr Aufwand ...)

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

und damit werden dann später durch andere User getätigte Änderungen überbügelt ...

Das ist kein Problem von offline first. Das kann immer passieren, wenn mehrere Personen gleichzeitig Änderungen vornehmen.

(was man natürlich auch abfangen könnte,

Sollte.

aber das macht noch mehr Aufwand ...)

Oder man verwendet ein Versionskontrollsystem wie git.

LLAP 🖖

[Frameworknutzer]

Wenn ich mir die Beiträge zu Herzen nehme, ist dann eine solche Umsetzung überhaupt möglich?

Ja!

Habt ihr Tipps und Anregungen, wie man da vorgehen kann?

Mit WAI ARIA gibt es einen eigenen Accessibility Standard, der sich mit JavaScript Apps beschäftigt. Noch stärker als bei einer klassischen Site muss man User bei einer JS-App "führen". Focus Management ist wichtig für die Accessibility einer JS-App. Auswählbare/aktivierbare Elemente sollten auch anspringbar/fokusierbar sein. Formulare sollten sich wie üblich bedienen lassen. Teile der Seite haben "Rollen" zugeordnet um Orientierung zu bieten. Für die üblichen JS Widgets gibt es schon passende Rollen und Beipsielumsetzungen. Um User auf Änderungen hinzuweisen kann man mit JS den Fokus auf ein geändertes Element setzen. Oder sogar "Live Regions" einsetzen. Damit sollte man aber vorsichtig sein weil es Screenreaderuser auch nerven kann. ;o)

Ein Frameworknutzer

[marctrix]

Hej Frameworknutzer,

Habt ihr Tipps und Anregungen, wie man da vorgehen kann?

Mit WAI ARIA gibt es einen eigenen Accessibility Standard, der sich mit JavaScript Apps beschäftigt.

Warum sollte das nur für JS (oder gar nur für JS-Apps) gelten?

Übrigens braucht man vergleichsweise wenige WAI-Attribute, wenn man die richtigen HTML-Elemente verwendet, denn diese haben die Rollen "eingebaut", sind klickbar und was sonst so wichtig ist. Gerade mit dem role- und tabindex-attribut repariert man oft nur, was man von Anfang an hätte richtig machen können - wenn man einen Frontender gefragt hätte ;-)

Trotzdem ein Plus von mir, weil abgesehen von der unnötigen Einschränkung hast du natürlich recht und du hättest auch recht, wenn du darauf hingewiesen hättest, dass die WAI-ARIA-Attribute in JS-Anwendungen besonders nützlich sind. Nur die Aussage, dass sich um einen Standard handelt, der sich mit Accessibility-Standards beschäftigt, führt leicht in die Irre. Die WCAG sind generell technik-neutral... - Hauptsache, was rauskommt, ist für alle nutzbar. Wie es entsteht - im Client oder auf dem Server und ob es am Ende HTML ist oder ein PDF - das ist alles Wurscht! ;-)

Marc

[marctrix]

Hej marctrix,

Achtung, Verwirrungsgefahr, hatte mich verschrieben. Falsch ist:

Nur die Aussage, dass sich um einen Standard handelt, der sich mit Accessibility-Standards beschäftigt, führt leicht in die Irre. Die WCAG sind generell technik-neutral...

Korrekt sollte es heißen stattdessen:

Nur die Aussage, dass es sich um einen Standard handelt, der sich mit JavaScript-Apps beschäftigt, führt leicht in die Irre. Die WCAG sind generell technik-neutral...

Marc

[pl]

Beim Zwischenspeichern wär's unfreundlich, wenn da jedesmal das Formular verschwinden und ein Neuladen der Seite stattfinden würde. Screenshot untenstehend für meine Lösung mit AJAX und eine Shortcut gibt es auch. Das Formular bleibt beim Speichern wackelfrei im Browser ohne störendes Mausgefummel.

[dedlfix]

Tach!

Beim Zwischenspeichern wär's unfreundlich, wenn da jedesmal das Formular verschwinden und ein Neuladen der Seite stattfinden würde. Screenshot untenstehend für meine Lösung mit AJAX und eine Shortcut gibt es auch. Das Formular bleibt beim Speichern wackelfrei im Browser ohne störendes Mausgefummel.

Der Screenshot zeigte lediglich ein Formular mit ein paar allgemeinen Eingabeelementen und Buttons. Der Inhalt in den Eingabeelementen hatte keinen Bezug zum Thema, weswegen ich ihn entfernt habe.

dedlfix.