Tach! > Da habe ich in der letzten Zeit einige Rants gelesen, in denen vor *Over-Engineerung* etc gewarnt wurde: > > * shiftedup: [Is a Single-Page Application what you really need?](http://www.shiftedup.com/2014/10/15/is-a-single-page-application-what-you-really-need) Ich greif da mal nur den einen raus, denn der spricht recht konkret Dinge an, die bei einer SPA problematisch werden: Verlinkungen von extern, SEO, Performance, nicht vorhandener Javascript-Support. Das wären (außer Performance) alles Dinge, die ich für eine SPA nicht bräuchte. Oder anders gesagt, wenn das nicht gegeben ist, dann muss man sich die Frage aus der Überschrift des Artikels stellen. Dann will der Probleminhaber vermutlich eher eine schicke Website als eine Web-Anwendung. Web-Anwendungen haben für mich dann ihre Berechtigung, wenn es um etwas geht, wofür man früher Programme geschrieben hat, und man sich nun das Ausrollen und Aktuell-Halten der Software sparen will. Vor allem betrifft sowas Intranet-Anwendungen, die als Arbeitspferde fungieren und Hilfsmittel sind, mit denen irgendwelche konreten Aufgaben erledigt werden können, und die nicht nicht nur mehr oder weniger den informativen Charackter einer Mein-Haus-mein-Auto-mein-Boot-Website haben. Solche Anwendungen können aber auch im Internet angesiedelt sein, beispielsweise, wenn es sich um ein Berechnungsprogramm für ein Spiel handelt. Mal angenommen, in dem Spiel geht es darum, eine Gegend zu versorgen und dafür muss man je Einwohner bestimmte Dinge herstellen. Das Programm rechnet nun aus, wieviel Produzenten und Zulieferer man betreiben muss, damit alles rund läuft. Natürlich kann man solche Spiele auch nach Bauchgefühl oder durch Reaktion auf Missstände meistern, aber die Planer haben lieber solche Tools. Für solche Anwendungen jedenfalls ist es nicht wichtig, dass die Suchmaschinen den Inhalt durchforsten, weil sie ins Intranet nicht reinkommen oder weil der Inhalt der Seiten nicht suchrelevant ist. Es muss lediglich der Rechner als solcher gefunden werden, und dafür gibt es eine statische Seite, die ihn vorstellt und seine Funktionen anpreist. Auch Verlinkungen auf andere Seiten als die Startseite ergeben dann meist keinen gesteigerten Sinn. Wohl aber die Navigation vor und zurück, wenn man sich innerhalb der Anwendung bewegt. Bleibt noch nicht vorhandener Javascript-Support. Den kann man im Intranet ausschließen, indem eine Systemvoraussetzung definiert und mit dem Arbeitgeber abgestimmt ist. Wenn die Mitarbeiter meinen, Javascript ausschalten zu müssen, dann müssen sie halt sehen, wie sie ihre Aufgaben ohne es erledigt bekommen. Natürlich kann man die Anwendung auch herkömmlich erstellen, so dass lediglich statische Formulare auf dem Client zu sehen sind und alles per Roundtrips zum Server geschickt und dort berechnet wird. Aber warum sollte man das auch für die Teile tun wollen, die der Client problemlos selbst berechnen kann? Da kommt dann auch die Performance-Frage wieder aufs Tapet und Laufzeiten zwischen den Systemen, die vermeidbar sind. Der Artikel wettert ja auch nicht generell gegen SPAs. Der Autor hat salopp gesagt lediglich erkannt, dass es keine problemlosen eierlegenden Wollmilchsäue gibt und man sich überlegen soll, welches Werkzeug am besten zu welchem Zweck passt. Nachdem ich jetzt mit meinem Geschreibsel fertig bin, hab ich auch mal die Conclusion des Artikels gelesen und stelle fest, dort steht ja im Wesentlichen das, was ich auch gesagt habe. dedlfix.

Tach! > Da habe ich in der letzten Zeit einige Rants gelesen, in denen vor *Over-Engineerung* etc gewarnt wurde: > > *shiftedup: [Is a Single-Page Application what you really need?](http://www.shiftedup.com/2014/10/15/is-a-single-page-application-what-you-really-need) Ich greif da mal nur den einen raus, denn der spricht recht konkret Dinge an, die bei einer SPA problematisch werden: Verlinkungen von extern, SEO, Performance, nicht vorhandener Javascript-Support. Das wären (außer Performance) alles Dinge, die ich für eine SPA nicht bräuchte. Oder anders gesagt, wenn das nicht gegeben ist, dann muss man sich die Frage aus der Überschrift des Artikels stellen. Dann will der Probleminhaber vermutlich eher eine schicke Website als eine Web-Anwendung. Web-Anwendungen haben für mich dann ihre Berechtigung, wenn es um etwas geht, wofür man früher Programme geschrieben hat, und man sich nun das Ausrollen und Aktuell-Halten der Software sparen will. Vor allem betrifft sowas Intranet-Anwendungen, die als Arbeitspferde fungieren und Hilfsmittel sind, mit denen irgendwelche konreten Aufgaben erledigt werden können, und die nicht nicht nur mehr oder weniger den informativen Charackter einer Mein-Haus-mein-Auto-mein-Boot-Website haben. Solche Anwendungen können aber auch im Internet angesiedelt sein, beispielsweise, wenn es sich um ein Berechnungsprogramm für ein Spiel handelt. Mal angenommen, in dem Spiel geht es darum, eine Gegend zu versorgen und dafür muss man je Einwohner bestimmte Dinge herstellen. Das Programm rechnet nun aus, wieviel Produzenten und Zulieferer man betreiben muss, damit alles rund läuft. Natürlich kann man solche Spiele auch nach Bauchgefühl oder durch Reaktion auf Missstände meistern, aber die Planer haben lieber solche Tools. Für solche Anwendungen jedenfalls ist es nicht wichtig, dass die Suchmaschinen den Inhalt durchforsten, weil sie ins Intranet nicht reinkommen oder weil der Inhalt der Seiten nicht suchrelevant ist. Es muss lediglich der Rechner als solcher gefunden werden, und dafür gibt es eine statische Seite, die ihn vorstellt und seine Funktionen anpreist. Auch Verlinkungen auf andere Seiten als die Startseite ergeben dann meist keinen gesteigerten Sinn. Wohl aber die Navigation vor und zurück, wenn man sich innerhalb der Anwendung bewegt. Bleibt noch nicht vorhandener Javascript-Support. Den kann man im Intranet ausschließen, indem eine Systemvoraussetzung definiert und mit dem Arbeitgeber abgestimmt ist. Wenn die Mitarbeiter meinen, Javascript ausschalten zu müssen, dann müssen sie halt sehen, wie sie ihre Aufgaben ohne es erledigt bekommen. Natürlich kann man die Anwendung auch herkömmlich erstellen, so dass lediglich statische Formulare auf dem Client zu sehen sind und alles per Roundtrips zum Server geschickt und dort berechnet wird. Aber warum sollte man das auch für die Teile tun wollen, die der Client problemlos selbst berechnen kann? Da kommt dann auch die Performance-Frage wieder aufs Tapet und Laufzeiten zwischen den Systemen, die vermeidbar sind. Der Artikel wettert ja auch nicht generell gegen SPAs. Der Autor hat salopp gesagt lediglich erkannt, dass es keine problemlosen eierlegenden Wollmilchsäue gibt und man sich überlegen soll, welches Werkzeug am besten zu welchem Zweck passt. Nachdem ich jetzt mit meinem Geschreibsel fertig bin, hab ich auch mal die Conclusion des Artikels gelesen und stelle fest, dort steht ja im Wesentlichen das, was ich auch gesagt habe. dedlfix.

Tach! > Da habe ich in der letzten Zeit einige Rants gelesen, in denen vor *Over-Engineerung* etc gewarnt wurde: > > *shiftedup: [Is a Single-Page Application what you really need?](http://www.shiftedup.com/2014/10/15/is-a-single-page-application-what-you-really-need) Ich greif da mal nur den einen raus, denn der spricht recht konkret Dinge an, die bei einer SPA problematisch werden: Verlinkungen von extern, SEO, Performance, nicht vorhandener Javascript-Support. Das wären (außer Performance) alles Dinge, die ich für eine SPA nicht bräuchte. Oder anders gesagt, wenn das nicht gegeben ist, dann muss man sich die Frage aus der Überschrift des Artikels stellen. Dann will der Probleminhaber vermutlich eher eine schicke Website als eine Web-Anwendung. Web-Anwendungen haben für mich dann ihre Berechtigung, wenn es um etwas geht, wofür man früher Programme geschrieben hat, und man sich nun das Ausrollen und Aktuell-Halten der Software sparen will. Vor allem betrifft sowas Intranet-Anwendungen, die als Arbeitspferde fungieren und Hilfsmittel sind, mit denen irgendwelche konreten Aufgaben erledigt werden können, und die nicht nicht nur mehr oder weniger den informativen Charackter einer Mein-Haus-mein-Auto-mein-Boot-Website haben. Solche Anwendungen können aber auch im Internet angesiedelt sein, beispielsweise, wenn es sich um ein Berechnungsprogramm für ein Spiel handelt. Mal angenommen, in dem Spiel geht es darum, eine Gegend zu versorgen und dafür muss man je Einwohner bestimmte Dinge herstellen. Das Programm rechnet nun aus, wieviel Produzenten und Zulieferer man betreiben muss, damit alles rund läuft. Natürlich kann man solche Spiele auch nach Bauchgefühl oder durch Reaktion auf Missstände meistern, aber die Planer haben lieber solche Tools. Für solche Anwendungen jedenfalls ist es nicht wichtig, dass die Suchmaschinen den Inhalt durchforsten, weil sie ins Intranet nicht reinkommen oder weil der Inhalt der Seiten nicht suchrelevant ist. Es muss lediglich der Rechner als solcher gefunden werden, und dafür gibt es eine statische Seite, die ihn vorstellt und seine Funktionen anpreist. Auch Verlinkungen auf andere Seiten als die Startseite ergeben dann meist keinen gesteigerten Sinn. Wohl aber die Navigation vor und zurück, wenn man sich innerhalb der Anwendung bewegt. Bleibt noch nicht vorhandener Javascript-Support. Den kann man im Intranet ausschließen, indem eine Systemvoraussetzung definiert und mit dem Arbeitgeber abgestimmt ist. Wenn die Mitarbeiter meinen, Javascript ausschalten zu müssen, dann müssen sie halt sehen, wie sie ihre Aufgaben ohne es erledigt bekommen. Natürlich kann man die Anwendung auch herkömmlich erstellen, so dass lediglich statische Formulare auf dem Client zu sehen sind und alles per Roundtrips zum Server geschickt und dort berechnet wird. Aber warum sollte man das auch für die Teile tun wollen, die der Client problemlos selbst berechnen kann? Da kommt dann auch die Performance-Frage wieder aufs Tapet und Laufzeiten zwischen den Systemen, die vermeidbar sind. Der Artikel wettert ja auch nicht generell gegen SPAs. Der Autor hat salopp gesagt lediglich erkannt, dass es keine problemlosen eierlegenden Wollmilchsäue gibt und man sich überlegen soll, welches Werkzeug am besten zu welchem Zweck passt. Nachdem ich jetzt mit meinem Geschreibsel fertig bin, hab ich auch mal die Conclusion des Artikels gelesen und stelle fest, dort steht ja im Wesentlichen das, was ich auch gesagt habe. dedlfix.