• Der Technologiewandel

      The change of technology

      Der Technologiewandel

    • Wir waren stets auf GWT spezialisiert. Mit der Zeit wuchs unsere Firma und somit wuchs auch die Heterogenität der einzelnen Projektbeteiligten. Wir hatten nun nicht mehr nur Hardcore-Java-Programmierer, sondern eben auch Grafiker, die auf Frontendseite sehr viel HTML und CSS schreiben.

      Bei GWT gibt es hierbei ein grundliegendes Problem:

      Die von GWT generierte DOM Struktur passte nicht zu der Struktur vom Grafiker. Hier mussten stets zeitaufwendige Anpassungen durchgeführt werden. Im Grunde sollte der Grafiker eigentlich das komplette UI entwickeln können und dabei nicht auf den von GWT generierten Code abhängig sein.

      Klingt logisch, aber einem Grafiker Java beizubringen, die Entwicklungsumgebungen aufzusetzen und grundlegende Programmierkenntnisse zu vermitteln wäre ein Overhead gewesen. Die Grafiker hätten somit mehr Zeit verbracht mit Java, als sich ihrer Kernkompetenz zu widmen.

      Durch einen Tipp von einem befreundeten Software Architekten und Mitbegründer des Reiseportals GoEuro, enstand die Idee Server und Client komplett zu trennen und beide über eine Rest API kommunizieren zu lassen.

      Auf dem Server entschieden wir uns für Spring. Beim Thema Client entschieden wir uns für Angular, ein Framework - ebenfalls aus dem Hause Google - welches wir schon im Zuge von diversen vorigen Projekten einsetzen. Die Grafiker konnten so ihre gewohnten DOM Strukturen bauen und direkt ins Projekt integrieren. Wir mussten lediglich noch die API-Endpunkte und Backend-Logik auf dem Server schreiben und diese mit dem Frontend-Code verbinden.

      Seither setzen wir viele unserer Projekte auf diesem Stack um. Spring & Angular FTW.


      Mehr von uns über das Das Google Web Toolkit gibt es hier.

      Wir waren stets auf GWT spezialisiert. Mit der Zeit wuchs unsere Firma und somit wuchs auch die Heterogenität der einzelnen Projektbeteiligten. Wir hatten nun nicht mehr nur Hardcore-Java-Programmierer, sondern eben auch Grafiker, die auf Frontendseite sehr viel HTML und CSS schreiben.

      Bei GWT gibt es hierbei ein grundliegendes Problem:

      Die von GWT generierte DOM Struktur passte nicht zu der Struktur vom Grafiker. Hier mussten stets zeitaufwendige Anpassungen durchgeführt werden. Im Grunde sollte der Grafiker eigentlich das komplette UI entwickeln können und dabei nicht auf den von GWT generierten Code abhängig sein.

      Klingt logisch, aber einem Grafiker Java beizubringen, die Entwicklungsumgebungen aufzusetzen und grundlegende Programmierkenntnisse zu vermitteln wäre ein Overhead gewesen. Die Grafiker hätten somit mehr Zeit verbracht mit Java, als sich ihrer Kernkompetenz zu widmen.

      Durch einen Tipp von einem befreundeten Software Architekten und Mitbegründer des Reiseportals GoEuro, enstand die Idee Server und Client komplett zu trennen und beide über eine Rest API kommunizieren zu lassen.

      Auf dem Server entschieden wir uns für Spring. Beim Thema Client entschieden wir uns für Angular, ein Framework - ebenfalls aus dem Hause Google - welches wir schon im Zuge von diversen vorigen Projekten einsetzen. Die Grafiker konnten so ihre gewohnten DOM Strukturen bauen und direkt ins Projekt integrieren. Wir mussten lediglich noch die API-Endpunkte und Backend-Logik auf dem Server schreiben und diese mit dem Frontend-Code verbinden.

      Seither setzen wir viele unserer Projekte auf diesem Stack um. Spring & Angular FTW.


      Mehr von uns über das Das Google Web Toolkit gibt es hier.

      We had been specialized steadily in GWT. As time went by our company grew and in the course of this process the heterogeneity grew of one single stakeholder, too. Back then we had`nt only the hardcore-java-programmer, we also had graphic designer who have made the frontend with HTML and CSS.

      There was a fundamental problem with GWT:

      The generated DOM structure of GWT didn't fit with the structure of the graphic artist. Therefor time-consuming adjustments were made. Basically, the graphic artist should develop the complete UT without being depending on the generated code from the GWT.

      It sounds logical but it would be too much if we teach java to the graphic artist, set up the development environment and to teach basic programming knowledge. Besides this, the graphic artist would spend more time on java than on their core competence.

      A friends software-architecture and cofounder of the traveling-portal GoEuro gave us a hint. Thus the idea originated to split the server and the client. Both sides communicate by API with each other.

      We used different technologies. We decided to use Spring on the server, for the client-side we used Angular (a framework from google) which we used successfully in other projects. The graphic artists could build their usual DOM structures and integrate them directly into their projects. We only had to program the API-termini and the backend-logic on the server and these to connect with the frontend-code.

      Since then we implement many of our projects with these stack.

      Spring & Angular FTW.


      More about GWT from us: klick here.