Web-Technologien 2013

[Kristof]

Hallo allerseits,

das letzte Jahr war ja recht spannend was die Einführung/Verbreitung neuer Web-Technologien anbelangt.

• Mit Node.js hat sich JavaScript auf dem Server durchgesetzt
• Composer bietet Dependency-Management unter PHP
• ORM ala Doctrine wird immer ausgereifter
• D3 hat sich etabliert
• Ruby On Rails ist immer mehr am kommen
• JavaScript Frameworks sprießen aus dem Boden Meteor, Backbone, Ember, Angular..
• Zend hat die 2. Versionsnummer erreicht, so auch Symfony
• JSON als Datenhaltung hat sich etabliert (CouchDB, allg. No-SQL)
• Google's GO verdient auch eine detailliertere Betrachtung
• Das Grails-Framework ist erwachsen geworden
• Mit Stripe steht einem eine sehr vereinfachte Payment-Anbindung-Solution zu Verfügung
• Continuous Integration etabliert sich nun auch außerhalb der Java-Welt (Travis-CI, Jenkins)
• Viele Architekturen werden modularisiert (bsp RESTful-BackendAPI + JS-Frontend)
• Responsive-Design ist nicht mehr ein Fremdwort

und und und.. die Liste kann man noch beliebig erweitern.

Ich verfolge die Entwicklung relativ begeistert, muss aber auch eingestehen, dass ich - als jahrelanger Java-Entwickler - die ganzen Hypes auch recht kritisch betrachte. Ich wäre zum Beispiel bisher nicht auf die Idee gekommen node.js als Backend-Solution zu nutzen. Dafür ist mir das noch viel zu frisch. Auch würde ich mich nur selten für RubyOnRails entscheiden, wenn man ähnliches mit Grails auch im Enterprise-Sektor haben kann. Auch weiß ich die No-SQL-Datenbanken noch nicht so recht zu deuten - sehe aber auch ein, dass man sich in Bezug auf die oben erwähnte stark zunehmende Modularisierung der Web-Architekturen evtl. auch von alten Denkmustern befreien muss.

Nun die Frage, wie es wohl in 2013 aussehen wird.

In den nächsten Wochen steht bei mir die Planung der Architektur für ein doch recht großes Projekt an.
Und nun bin ich das erste Mal an dem Punkt angelangt, nicht reflexgebunden J2EE in den Raum zu schreien.
Habe auf der anderen Seite jedoch auch meine Zweifel was eben den Enterprise-Sektor der neuen Technologien anbelangt.

Im Falle der SPA-Frameworks (Single Page Applications) bin ich zum Beispiel gut abgeschreckt, da sich grundlegende APIs selbst in Minor-Versionen geändert haben. Und ich habe den Eindruck, dass man zwar die Notwendigkeit solcher Frameworks erkannt hat, aber noch nicht so recht weiß, wohin genau die Entwicklung eigentlich gehen soll.

Node.js. JavaScript auf dem Server. Als Web-Entwickler, der noch aus den Zeiten stammt, in denen es jQuery noch gar nicht gab -
bereitet mir der Gedanke - wenn ich ehrlich bin - doch etwas das Bauchschmerzen. Und ich kann mich nicht so wirklich von dem Gefühl trennen, dass das nicht der richtige Weg ist bzw. dass es sich hierbei eben um einen Hype handelt.

Grails ist mitterweile sehr ausgereift, man stößt aber leider immernoch an Performance-Probleme, wenn man mit einer nicht geringen Menge von Domain-Instanzen arbeitet. Aber im Gegenzug bekommt man eben die Vorzüge von J2EE gepaart mit einem sehr flexiblen und gutem Framework.

PHP/Zend. Dank der Annotations-Interpretierungen der gängigen IDEs kann mitterweile die Typenlosigkeit gut umgangen werden. Auch dank Tools wie Doctrine hat sich das ORM vereinfacht - auch wenn man noch Welten von den in anderen Sprachen etablierten Pendants (LinQ, Hibernate, etc) entfernt ist.
Symfony2. Das macht mitterweile einen doch recht sauberen Eindruck auf mich - zumal auch Doctrine von Haus aus integriert ist (Component). Und Unit-Testing auch ausreichend unterstützt wird.
Über Laravel 4 hört man auch einiges Gutes in letzter Zeit.

Nun denn, was die Architekt angeht, so werde ich wohl weiterhin an dem Aufbau
RESTful Backend-API <-> Clients
festhalten.
Welche Technologien ich jedoch verwenden werde, da bin ich mir eben noch nicht sicher.

Vielen Dank fürs Lesen,
würde ich mich über ein paar Eindrücke/Erfahrungen eurerseits freuen.

Kristof

[dave]

Hi,

In den nächsten Wochen steht bei mir die Planung der Architektur für ein doch recht großes Projekt an.

Bei großen Projekten etwas neues auszuprobieren halte ich für sehr riskant. Außer dem "das ist neu, haben will"-Argument glaube ich gibt es keinen Grund sich bei so etwas von bekannten Wegen zu entfernen.

Lieber erst mal bei kleinen Projekten Erfahrung damit sammeln. Egal welche neue Technologie du in deine Arbeitsumgebung einführen möchtest.

~dave

[dedlfix]

Tach!

Ich gehe mal nur auf zwei kleine Aspekte ein.

PHP/Zend. Dank der Annotations-Interpretierungen der gängigen IDEs kann mitterweile die Typenlosigkeit gut umgangen werden.

Das können Zend-Produkt aber schon seit Jahren, sowohl PHPDoc-Kommentare vor Klassen und Methoden, also auch mitten im Code, wenn es nicht eindeutig ist, welcher Klasse der Inhalt einer Variable angehört.

• Zend hat die 2. Versionsnummer erreicht, so auch Symfony

Nach langer Zeit hatte ich neulich ich mal wieder ein Blick auf das ZF geworfen und mich entsetzt abgewandt, obwohl ich es zu seiner Anfangszeit ziemlich gut fand. Nachdem ich mir das aktuelle Quasi-Hello-World-Tutorial angeschaut habe, fand ich darin eine "neue Form" der Anwendungsentwicklung: AOP - was in dem Falle für Array orientierte Programmierung steht. Was man da an ineinander verschachtelten Arrays erstellen muss, geht auf keine Kuhhaut (zweimal Next Topic, bei Modules geht's los). Das Problem dabei ist hauptsächlich, dass man die Struktur lernen oder nachschlagen muss, nebst der Key-Namen. Das sind alles Strings, die da notiert werden müssen. Und bei stringly-typed (ja, mit i) Geschichten kann einem keine IDE dafür Unterstützung bieten. Was ein Wert in einem String für eine Bedeutung hat, kann die IDE nicht wissen und deshalb keine sinnvolle Autovervollständigung anbieten. Bei Variablen-, Konstanten-, Property-, Methoden- und Klassennamen geht das hingegen problemlos.

Symfony machte (gemäß seiner Dokumentation) einen deutlich besseren Eindruck. Und dann lief mir dieser Tage das YiiFramework über den Weg, das mir auf den ersten Blick noch besser gefiel. Leider hab ich noch keine Zeit gefunden, tiefergehende Blicke draufzuwerfen.

Nun die Frage, wie es wohl in 2013 aussehen wird.

Das wirst du 2014 wissen.

dedlfix.

[molily]

Hallo,

Ich wäre zum Beispiel bisher nicht auf die Idee gekommen node.js als Backend-Solution zu nutzen. Dafür ist mir das noch viel zu frisch.

Node.js ist auch keine generische Backend-Lösung, sondern für die Anwendungsfälle gedacht, wo das eventbasierte, asynchronone I/O auf Basis einer äußerst schnellen JIT-VM Vorteile bringt. Z.B. bei vielen parallelen Requests oder WebSockets-Verbindungen.

Auch würde ich mich nur selten für RubyOnRails entscheiden, wenn man ähnliches mit Grails auch im Enterprise-Sektor haben kann.

Ruby on Rails gehört eher schon zu den etablierten Frameworks und Ruby hat mit MRI, Rubinius und jRuby starke Interpreter. Welchen Vorteil bietet da Grails, eine noch bessere Einbindung in ein Java-Umfeld?

Auch weiß ich die No-SQL-Datenbanken noch nicht so recht zu deuten

Schemafreie dokumentbasierte Datenbanken, Key-Value- und In-Memory-Datenbanken schließen erst einmal eine Lücke, die SQL-Datenbanken vorher nur schlecht abdecken konnten. SQL-Datenbanken haben immer noch eigentümliche Vorteile, die NoSQL vor allem ergänzt.

Im Falle der SPA-Frameworks (Single Page Applications) bin ich zum Beispiel gut abgeschreckt, da sich grundlegende APIs selbst in Minor-Versionen geändert haben. Und ich habe den Eindruck, dass man zwar die Notwendigkeit solcher Frameworks erkannt hat, aber noch nicht so recht weiß, wohin genau die Entwicklung eigentlich gehen soll.

Man weiß es schon, die Ziele, Anforderungen und Geschmäcker sind allerdings sehr verschieden. Daher haben die SPA-Frameworks auch unterschiedliche Ausrichtungen und Schwerpunkte. Starke Bewegung und damit API-Brüche ist bei vielen dieser Frameworks zu beobachten, aber alle stabilisieren und differenzieren sich gerade.

Node.js. JavaScript auf dem Server. Als Web-Entwickler, der noch aus den Zeiten stammt, in denen es jQuery noch gar nicht gab - bereitet mir der Gedanke - wenn ich ehrlich bin - doch etwas das Bauchschmerzen.

Wieso?

Grüße,
Mathias

[tron]

Hi,

Node.js. JavaScript auf dem Server. Als Web-Entwickler, der noch aus den Zeiten stammt, in denen es jQuery noch gar nicht gab -
bereitet mir der Gedanke - wenn ich ehrlich bin - doch etwas das Bauchschmerzen. Und ich kann mich nicht so wirklich von dem Gefühl trennen, dass das nicht der richtige Weg ist bzw. dass es sich hierbei eben um einen Hype handelt.

Unterschätzt du vielleicht Javascript?

[hotti]

hi,

Vielen Dank fürs Lesen,
würde ich mich über ein paar Eindrücke/Erfahrungen eurerseits freuen.

Danke auch!
Deine Aufstellung habe ich mit Interesse gelesen. War auch nicht untätig und habe das Verfahren zum Aushandeln von Content (bekannt ist Language-Negotiation) auf ACLs erweitert. D.h., dass einem URL zugeordnete Inhalte nur ausgeliefert werden, wenn dem eine Authentification vorausgegangen ist. Damit ergeben sich ein paar Vorteile:

• AccesControl (ACL) ist vom Code vollständig getrennt
• die Diskriminierung erfolgt über den Namen der Controller-Class infolge codeunabhängiger Konfiguration
• der Programmierer muss sich um ACLs nicht kümmern
• es können beliebig viele Benutzer/Gruppen angelegt werden
• Requests auf einunddenselben URL liefern (unterschiedliche) Inhalte aus, die der Autorisierung entsprechen

Hotti

[Jens Holzkämper]

Tach,

D.h., dass einem URL zugeordnete Inhalte nur ausgeliefert werden, wenn dem eine Authentification vorausgegangen ist.

ich hoffe du meinst Authorization.

Damit ergeben sich ein paar Vorteile:

• AccesControl (ACL) ist vom Code vollständig getrennt
• der Programmierer muss sich um ACLs nicht kümmern
• es können beliebig viele Benutzer/Gruppen angelegt werden
• Requests auf einunddenselben URL liefern (unterschiedliche) Inhalte aus, die der Autorisierung entsprechen

Ich weiß, es ist ein Fehler, aber:

1. Wo unterscheidet sich deine Lösung jetzt nochmal von dem was schon tausende andere getan haben?

2. Was hat das mit dem Thema des Threads zu tun?

• die Diskriminierung erfolgt über den Namen der Controller-Class infolge codeunabhängiger Konfiguration

WTH? Der Name der Klasse?

mfg
Woodfighter