© best_vector/Shutterstock.com
Windows Developer
Desktopanwendungen sind tot, es leben die Desktopanwendungen!

Totgesagte leben länger!

Vor fünfzehn Jahren war alles anders und vor allem so viel einfacher: Wir wollen eine Desktopanwendung entwickeln. Plattform? Frontend- oder Backend-Technologie? Portabilität und Unit-Testfähigkeit? Die Frage nach diesen und anderen Dingen stellte sich dabei wenig bis gar nicht. Heute sieht das aber ganz anders aus. Dieser Artikel zeigt auf, wie sich die Entwicklung von Desktopanwendungen gewandelt hat.

Klaus Löffelmann


Ach was war das Leben eines Entwicklers vor fünfzehn Jahren doch einfach: Wollte man eine Anwendung entwickeln, dann stellte sich nicht die Frage nach der Plattform, nach Frontend- oder Backend-Technologie, nach Portabilität, nach Unit-Testfähigkeit oder sonstigen Dingen. Da war klar: Für Desktopanwendungen (Rich-Client-Anwendungen würde man heute sagen) im Businessbereich standen Entwicklungssysteme wie etwa Delphi oder VB6 zur Verfügung. Extrem Performancebedürftige, Puristen oder auch Masochisten entschieden sich für C++. Vielleicht noch mit ein wenig Hilfestellung durch die Foundation Classes, aber das war es im Grunde genommen.

In 95 Prozent aller Fälle hatten die Anwendungen unter Windows 95 oder NT4 zu laufen, und das taten sie damit – mehr oder weniger zuverlässig, je nach Fähigkeit der Entwickler. Es gab keine Diskussionen darüber, in welchen Umgebungen die Anwendungen zu funktionieren hatten, es gab einfach nix zu diskutieren. Und es gab nur Microsoft als beachtenswerte Plattform. Kein Apple, kein Android.

Verstehen Sie mich nicht falsch, ich sage nicht, dass das gut war! Nein, nein – prinzipiell finde ich ernstzunehmende Mitbewerber immer sinnvoll, denn sie beschleunigen die Evolution. Und die brauchte Windows nach Vista mehr als dringend. Ich sage nur: Heute ist das anders. Auf bestimmte Unternehmensdaten muss man auch von iPads und Android-Tablets aus zugreifen können. Windows-Tablets spielen im Moment noch keine Rolle, sagen viele, obwohl das meiner Meinung nach nicht stimmt: Hybride Geräte mit Windows 8 Pro und Touch-Funktionalität sind auf dem Vormarsch, und Anwender erwarten, dass man Anwendungen sowohl per Touch als auch herkömmlich bedienen kann. Und: Anwendungen, die eigentlich für den Desktopbetrieb konzipiert waren, also klassische Smart-Client-Anwendungen, müssen unbedingt im Browser laufen – logischerweise, wo denn sonst?

Dabei werden die Frontends einer jeden zu migrierenden Applikation natürlich browsergerecht mit JavaScript und HTML5 verfasst. Man gilt ja direkt als wunderlich, überhaupt die Frage nach der richtigen Frontend-Technologie zu stellen. Gibt es denn überhaupt noch eine Alternative zu JavaScript und HTML5? Schließlich leben wir in einer Welt der Tablets, des Überall-verfügbar-Internets, des Bring Your Own Devices, oder kurz BYOD (sprich: Baiott), und natürlich des Cloud Computings. Internetanwendungen sind vor allen Dingen soooo einfach zu deployen. Ja, es macht überhaupt keinen Aufwand. Man braucht nichts auf dem Ziel...

Windows Developer
Desktopanwendungen sind tot, es leben die Desktopanwendungen!

Totgesagte leben länger!

Vor fünfzehn Jahren war alles anders und vor allem so viel einfacher: Wir wollen eine Desktopanwendung entwickeln. Plattform? Frontend- oder Backend-Technologie? Portabilität und Unit-Testfähigkeit? Die Frage nach diesen und anderen Dingen stellte sich dabei wenig bis gar nicht. Heute sieht das aber ganz anders aus. Dieser Artikel zeigt auf, wie sich die Entwicklung von Desktopanwendungen gewandelt hat.

Klaus Löffelmann


Ach was war das Leben eines Entwicklers vor fünfzehn Jahren doch einfach: Wollte man eine Anwendung entwickeln, dann stellte sich nicht die Frage nach der Plattform, nach Frontend- oder Backend-Technologie, nach Portabilität, nach Unit-Testfähigkeit oder sonstigen Dingen. Da war klar: Für Desktopanwendungen (Rich-Client-Anwendungen würde man heute sagen) im Businessbereich standen Entwicklungssysteme wie etwa Delphi oder VB6 zur Verfügung. Extrem Performancebedürftige, Puristen oder auch Masochisten entschieden sich für C++. Vielleicht noch mit ein wenig Hilfestellung durch die Foundation Classes, aber das war es im Grunde genommen.

In 95 Prozent aller Fälle hatten die Anwendungen unter Windows 95 oder NT4 zu laufen, und das taten sie damit – mehr oder weniger zuverlässig, je nach Fähigkeit der Entwickler. Es gab keine Diskussionen darüber, in welchen Umgebungen die Anwendungen zu funktionieren hatten, es gab einfach nix zu diskutieren. Und es gab nur Microsoft als beachtenswerte Plattform. Kein Apple, kein Android.

Verstehen Sie mich nicht falsch, ich sage nicht, dass das gut war! Nein, nein – prinzipiell finde ich ernstzunehmende Mitbewerber immer sinnvoll, denn sie beschleunigen die Evolution. Und die brauchte Windows nach Vista mehr als dringend. Ich sage nur: Heute ist das anders. Auf bestimmte Unternehmensdaten muss man auch von iPads und Android-Tablets aus zugreifen können. Windows-Tablets spielen im Moment noch keine Rolle, sagen viele, obwohl das meiner Meinung nach nicht stimmt: Hybride Geräte mit Windows 8 Pro und Touch-Funktionalität sind auf dem Vormarsch, und Anwender erwarten, dass man Anwendungen sowohl per Touch als auch herkömmlich bedienen kann. Und: Anwendungen, die eigentlich für den Desktopbetrieb konzipiert waren, also klassische Smart-Client-Anwendungen, müssen unbedingt im Browser laufen – logischerweise, wo denn sonst?

Dabei werden die Frontends einer jeden zu migrierenden Applikation natürlich browsergerecht mit JavaScript und HTML5 verfasst. Man gilt ja direkt als wunderlich, überhaupt die Frage nach der richtigen Frontend-Technologie zu stellen. Gibt es denn überhaupt noch eine Alternative zu JavaScript und HTML5? Schließlich leben wir in einer Welt der Tablets, des Überall-verfügbar-Internets, des Bring Your Own Devices, oder kurz BYOD (sprich: Baiott), und natürlich des Cloud Computings. Internetanwendungen sind vor allen Dingen soooo einfach zu deployen. Ja, es macht überhaupt keinen Aufwand. Man braucht nichts auf dem Ziel...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang