Vor ziemlich genau fünf Jahren bin ich zum ersten Mal mit Spring (damals noch Interface21 auch in den Packagenamen) in Kontakt gekommen. Damals noch ein ziemlich unbeschriebenes Blatt hatte Spring in Kunden-evaluationen /-situationen kaum eine Chance gegen Struts. Da musste man schon fast einen Liebhaber von "progressiven" Neuerungen auf der Gegenseite haben, um von Struts wegzukommen. Wie auch Struts war Spring damals vorallem auf die serverseitige Webprogrammierung ausgerichtet - um einiges besser schon damals als Struts aber auch um einiges unbekannter... :-)
Während bei Struts das "Benzin" ausging und seid damals keine wirklich nennenswerte Neuentwicklung mehr zustande kam, ging bei Spring so richtig die Post ab. Die drei Standbeine "dependency injection" mit Bean-Container, "portable service abstraction" für die Abstraktion der diversen Java-API's und Unterstützung von aspektorientierter Programmierung wurden schnell ziemlich gut ausgebaut und in den neuesten Versionen mit Möglichkeiten von AspectJ und Annotationen ergänzt. Damit hat sich Spring serverseitig im Markt behaupten können, erleichtert täglich dem Entwickler vieles und ist heute Quasi-Standard im Enterprise Java-Markt.

... und alles wurde gut... wohlgemerkt, serverseitig... wenn da nicht der Client wäre... :-)

Ich habe mich ehrlicherweise bislang nie so richtig wohl gefühlt im Html-, CSS- und JavaScript-Dschungel... zu unstrukturiert und launisch war mir diese Welt. Die unterschiedlichen Browser und ihre Eigenheiten haben das ihrige dazu beigetragen. Seid 2005 und der "neuen alten" Technologie AJAX und dem Buzzword Web 2.0 hat sich jedoch einiges verändert. Der Client ist nicht mehr als reine Anzeigemaschinerie da sondern erhält - je nach Gewichtung - immer wie mehr Logik (Stichwort hier RIA). Und ein neuer riesiger Zoo von AJAX-Frameworks war die Folge. Ich mag sie gar nicht erwähnen, so viele sind es mittlerweile (auch sehr gute, keine Frage).

Glücklicherweise hat dies auch Springsource erkannt und hat ihr altbewährtes "portable service abstraction"-Prinzip nun bis auf den Client ausgebreitet. Was bedeutet das? Nun, ganz einfach. Ich erhalte als Entwickler ein einheitliches clientseitiges Prgrammiermodel mit dem ich arbeiten kann. Ich muss mich nicht mit Dojo oder JQuery Eigenheiten auskennen sondern es reicht, wenn ich das SpringJS-API kenne. Schematisch sieht das folgendermassen aus:

Als erste Bridge und Implementierung wird Dojo unterstützt. Als weitere Bridge geplant ist zudem JQuery. Damit sind sicher die aktuell am meist verbreiteten JavaScript-Libraries unterstützt.
Mit SpringJS wird die HTML-Seite mit "progressivem" JavaScript ergänzt... was heisst, die Funktionalität ist auch dann gewährleistet, wenn der Client JavaScript ausgeschaltet hat. Das fühlt sich dann ungefähr so an:

Die HTML-Elemente werden mit sogenannten Dekorationen (siehe Decoration-Pattern) erweitert. Im Beispiel wird einfach ein OnClick-Handler dem Html-Element findFormUrl "hinzugefügt".

So einfach... oder? Und das ganze portabel... hoffentlich... :-)