Webtechnologien der Zukunft

[Balu der Bär]

Moin,

nachdem ich in den letzten zwei Jahren mich fast gar nicht mehr mit der Programmierung beschäftigt habe, werde ich versuchen diesen Zustand langsam und nebenbei wieder zu ändern.

Hauptsächlich geht es um Webentwicklung und leider bin ich etwas unschlüssig, in welche Sprache bzw. Technologie es sich lohnt einzuarbeiten. Wie steht es um die Zukunft im Webentwicklungs-Bereich? Ist es lohnenswert sich in Sachen wie Flash (mit ActionScript), MS Visual Studio (Sprache entfallen) Web Developer oder gar Silverlight einzuarbeiten oder wird man auch weiterhin mit PHP, AJAX und HTML auf der sicheren Seite sein?

Würde mich über Antworten und Tipps freuen. :)

[Bernhard Geyer]

Ich denke es ist unstrittig das auf Clientseite man mit AJAX viel erreichen kann. Welche der vielen AJAX-Frameworks mann einsetzt ist eine anderes Thema. Hier wird vermutlich in den nächsten Jahren einiges an Bereinigung erfolgen.

Welche der "Rich-Browser-Client"-Techniken sich durchsetzt (Silverlight, RIA, Google-*irgendwas*, Yahoo-*irgendwas*) ist m.E. noch sehr offen. Denn bei vielen der Techniken ist es noch fraglich ob man bei zu großer Marktakzeptanz doch wieder von den Plattformen eingeschränkt wird (wer sagt das MS mit Silverlightin 5 Jahren nur noch für IE unter Windows das Plugin anbietet oder entsprechende Windows-Abhängigkeiten ala J++ einbaut).

[mkinzler]

Als Alternative für Silverlight gäbe es noch Moonlight ( vom Mono-Projekt).
Aber RIA kann man auch durch Js-Frameworks wie Dojo o.ä. erreichen

[3_of_8]

Nennt mich altmodisch, aber ich bin immer noch der Meinung, dass (X)HTML, CSS und eine serverseitige Sprache wie PHP am wichtigsten sind. JavaScript, AJAX, Flash und der ganze andere Kram sind manchmal unumgänglich (Wenn man aus irgendeinem Grund Musik oder Videos einbinden will oder BB-Code-Schaltflächen für ein Forum braucht) und manchmal auch ganz nützlich, aber sie haben alle ihre Probleme. JavaScript damit, dass es in jedem Browser anders unterstützt wird, Flash isr größtenteils nicht barrierefrei...

[bluesbear]

Wenn man mich fragt, was ich in meiner Kristallkugel sehe - Googel's Andriod hat großes Potential.

[mkinzler]

Android ist allerdings ein Betriebssystem für Mobiletelefone u.ä.

[bluesbear]

Zitat:

Zitat von mkinzler

Android ist allerdings ein Betriebssystem für Mobiletelefone u.ä.

Jepp, gemessen an der Ausgangsfrage habe ich mal über den Tellerrand geguckt.

[Alexander]

Ich denke auch in Zukunft lässt sich viel mit den üblichen verdächtigen PHP/JS/CSS/HTML machen. Aber wenn du dir einmal ASP.NET angeschaut hast und selbst vielleicht auch schon das einige mit .NET gemacht hast, wird es vermutlich dein Favorit werden und PHP gänzlich ergänzen.
Ich jedenfalls war sehr begeistert, wie produktiv man doch mit ASP.NET arbeiten kann (im Vgl. zu PHP). Viele Standardprobleme sind bereits sehr gut gelöst (z.B. Membership etc) und lassen sich einfach durch neue Provider-Modelle anpassen. Trennung von Code und HTML ist eh kein Problem. Ein Template-System aller Smarty (oder gar ein eigenes) für PHP ist völlig unnötig... Ajax ist Dank Erweiterung für VS05 auch kein Problem. Im neuen VS ist es eh schon drin. Auch ohne JS-Kenntnisse kann man da schon sehr viel mit dem Ajax Framework machen (eigentlich fast alles).

Weiterer Vorteil: Du kennst dich vllt. schon mit .NET und dem VS aus und hast weniger Einarbeitungszeit. Oder umgekehrt: Du lernst es dadurch kennen und hast später evtl. keine Probleme, wenn du .NET Apps (also keine Web-Apps) schreiben willst.

Von Silverlight, Flash etc. halte ich dagegen nicht ganz so viel. Man kann zwar auch sehr viel damit machen, aber eigentlich m.M sind es eher Spielereien :duck: .

[mkinzler]

Wobei es auch für PHP mächtige Bibliotheken gibt, die ASP.Net sehr ähnlich sind.

[Phoenix]

Also Erfahrungsgemäß (ich hab ja viel PHP gemacht bevor ich zu ASP.NET gewechselt bin) braucht man midnestens 1/3 weniger Code in ASP.NET als in PHP, das Debugging (sowohl vom Serverseitigen Code als auch vom Javascript!) ist im neuen Visual Studio genial gelöst. Intellisense in Javascript, als ich das das erste mal gesehen hab bin ich fast vor Freude wild onanierend durch die Gegen gehüpft ;-) Der Produktivitätsunterschied ist einfach übelst groß.

Was wahrscheinlich auch eine Zukunft hat sind dynamische Sprachen in der CLR wie IronRuby / IronPython. Wenn man sich z.B. Rails als mächtiges Webframework vorstellt und dort dann so Scherze wie die schon vorhandene ASP.NET Infrastruktur (Usermanagement / Rechteverwaltung, Webparts etc.) kombiniert denke ich hat man eine solide Basis auf der man sehr Effizient neue Webanwendungen bauen kann.

Silverlight (auch weiterhin Flash) wird eher für Web-Guis eine Lösung sein, bei der man sich sonst Ajaxtechnisch auf dem Client echt alles abbrechen würde. Ein Browser ist halt nunmal ein Browser und kein Delphi-Form, auf dem man alles so zeichnen und bewegen und tun und machen könnte wie man will. Ich rede hier aber eher von User Experience -Elementen(Animationen, Videos, live Charts etc.), was sich in das das Gesamtbild einer Webanwendung integriert und nicht zwingend von 100% Silverlight / Flash Anwendungen, in denen alles auf dem Client gemacht wird. Für sowas nimmt man dann doch lieber eine echte Desktop-Anwendung (imho).

[Khabarakh]

Der größte Trend derzeit ist wohl eindeutig MVC. Ruby on Rails hat es vorgemacht, Microsoft und andere ziehen nach.
Natürlich ist es am Anfang nett, in ASP.Net wie bei Desktop-Apps einfach ein paar Elemente auf den Designer zu hauen und noch ein DataSet drüber zu stulpen, aber man (ich ;) ) merkt doch schnell, dass diese Art von RAD doch lieber auf dem Client bleiben sollte.
Ich verspreche mir von ASP.Net MVC nur eines: Mehr Spaß :zwinker: .

Zitat:

Zitat von bluesbear

Zitat:

Zitat von mkinzler

Android ist allerdings ein Betriebssystem für Mobiletelefone u.ä.

Jepp, gemessen an der Ausgangsfrage habe ich mal über den Tellerrand geguckt.

"Hinausgeschossen" trifft es wohl eher :mrgreen: :duck: . Bis jetzt habe ich jedenfalls noch nichts Revolutionäres über Androids Webbrowser gehört, das sich auch auf den PC auswirken könnte.

[Phoenix]

MVC ist Kacke ;-)
Aber mal im Ernst: MVC hat ein paar massive Nachteile gegenüber MVVM. Du warst ganz offensichtlich nicht auf der letzten EKON Spring in meinem Vortrag über Designpatterns :zwinker:

Das ist übrigens auch der Grund warum ich Rails nicht so sehr mag. Imho hat eine Datenquelle nix auf dem UI (Webform) zu suchen.

Das, und der Umstand, dass Rails so dermassen enge Vorgaben an die Verzeichnis- und Datenbankstruktur stellt. Das bedeutet nämlich, dass man Rails eigentlich nur für Neuentwicklungen benutzen kann. Eine bestehende Datenbank Rails-Kompatibel zu machen lohnt sich einfach nicht. Da greift man dann lieber auf ein anderes Framework zurück, dass einem ermöglicht die alten Strukturen beizubehalten.

[Balu der Bär]

Hai ihr,

es wäre super wenn ihr für die Nicht-Experten unter uns statt den Abkürzungen vlt. den richtigen Namen nennen könntest. :stupid:

MVC? Google meint dazu Model View Controller? :gruebel:

[mkinzler]

Genau. Bedeutet Trennung von Daten (Model) Anzeige (View) und Logik (Controller)

[Khabarakh]

Zitat:

Zitat von Balu der Bär

es wäre super wenn ihr für die Nicht-Experten unter uns statt den Abkürzungen vlt. den richtigen Namen nennen könntest. :stupid:

MVC? Google meint dazu Model View Controller? :gruebel:

Also, geht doch :mrgreen: . Aber gerade ASP.Net MVC steht für mich nicht nur für das Pattern, sondern für eine Abkehr von diesem Mammut-RAD-Framework, einfach alles besser :mrgreen:² . Routing (wird's ja dann auch für Webforms (das "alte" ASP.Net) geben), Unit Tests, Mocking, ... Außerdem passt es perfekt zu den anderen 3.5-Sachen wie Linq und davon kann ich nicht genug bekommen :-D .
Vielleicht sagt dir dieses Video etwas mehr, wenn es ohne Vorwissen nicht doch etwas zu kurz ist. Ich muss ja auch zugeben, dass ich bis jetzt selbst noch nichts damit gemacht habe :stupid: , aber vor allem wegen der Trennung von Oberfläche und Daten hört sich das ganze für mich genauso genial an wie der Umstieg WinAPI -> Windows Presentation Foundation. In beiden Fällen werde ich nicht wieder zurück wollen.

Zitat:

Zitat von Phoenix

Imho hat eine Datenquelle nix auf dem UI (Webform) zu suchen.

Ich bin mir nicht sicher, was du meinst, hört sich aber nicht wirklich nach Model-View-Trennung an :gruebel: .

Zitat:

Eine bestehende Datenbank Rails-Kompatibel zu machen lohnt sich einfach nicht. Da greift man dann lieber auf ein anderes Framework zurück, dass einem ermöglicht die alten Strukturen beizubehalten.

Jo, beim Migrieren ist mit Convention over Configuration Schluss. In der Hinsicht würde ich von Microsoft aber auch mehr erwarten als von Rails.