Blog

Javascript Wiederbelebung

Gerard van de Glind

Aktualisiert Oktober 22, 2025
4 Minuten

Letzten Freitag, vor einer Woche, fand der Tag der Softwareentwicklung war bei Xebia, die erste für mich, da ich dieses Jahr bei Xebia angefangen habe. Wie von Iwein geschrieben, gab es eine Diskussion über die Verwendung von Javascript, die von meiner Wenigkeit angestoßen wurde. Sollten wir alle UI-bezogenen Funktionen in Javascript ausführen? Werfen wir unser Wissen, unsere Tools und bewährten Verfahren weg, wenn wir mit der Programmierung beginnen? Javascript? Warum sollten wir in Javascript programmieren und den Browser als eine Art virtuelle Maschine verwenden, wenn wir doch eigentlich eine Desktop-Anwendung erstellen wollen?

Nun, um ein paar Fragen zu beantworten: Es gibt eine ganze Reihe von Frameworks, mit denen man ausgereiftere Javascript-Programmierung betreiben kann. Frameworks wie JQuery, Prototyp und YUI ermöglichen es Ihnen, plattformübergreifende Benutzeroberflächen ohne viel Ballast zu erstellen. Verwendung eines Templating Frameworks Reines können Sie eine Benutzerschnittstelle aufbauen, indem Sie einfach JSON-Daten. Es gibt auch eine Vielzahl von (Unit-)Test-Frameworks für Javascript. Die Programmierung in Javascript bedeutet also nicht unbedingt, dass wir in die Steinzeit der Programmierung zurückkehren müssen. Ein Argument gegen die Verwendung von Javascript: Es gibt eine Menge hässlichen Code, der in Javascript geschrieben wurde, mit dem Sie zurechtkommen müssen. Es besteht jedoch die Möglichkeit, guten Code in Javascript zu schreiben: Es ist eine ausgereifte, dynamische Programmiersprache - wenn auch ganz anders als Java. Schließlich noch ein Argument dafür: Wir wollten eine Blogging-Seite entwickeln - keine Desktop-Anwendung. Ob Javascript für eine Desktop-Anwendung am besten geeignet ist oder nicht, war nicht relevant. Obwohl ich denke, dass das immer noch eine interessante offene Frage für Desktop-ähnliche Anwendungen ist. Es gab eine ganze Reihe von Entwicklern und einen Projektmanager, der sich dem Website-Team anschloss. Wir hatten zwar keine vakante Projektleiterrolle, aber zum Glück beherrschte er auch HTML und Design :-). Wir bildeten drei Unterteams, die jeweils zusammenarbeiteten: eines für die Übersichtsseite (mit allen Blog-Einträgen), eines für die Blog-Einträge (einzelne Einträge) und eines für das Javascript-'Backend' (der Backend-Code läuft natürlich auch im Browser). Arjan hatte die stärksten Argumente gegen meine Einwände gegen Javascript auf der Mailingliste, also schlossen wir uns als Subteam zusammen, um das Javascript-'Backend' zu programmieren. Wir beschlossen, Pure nicht zu verwenden, da uns nicht gefiel, dass man im Grunde die gesamte UI-Struktur in JSON übertragen musste. Es würde keinen großen Unterschied machen, HTML zu senden und die Benutzeroberfläche vom Browser rendern zu lassen. Unser Projektmanager hat zusammen mit seinem Team ein schönes Design erstellt. Das andere Team erstellte eine gute Übersicht über die Artikel. Schon bald hatten wir ein gut aussehendes Design, das die Nachricht aus dem Stubbed REST-Service anzeigte. Die gesamte UI-bezogene Logik lief innerhalb des Browsers. Mithilfe von Regeln zum Umschreiben von URLs konnten wir die URLs schön halten - so kann die Javascript-Anwendung von Suchmaschinen indiziert werden. Um 17:00 Uhr begann der REST-Dienst mit der Anzeige einer echten Nachricht, anstatt einer Stubbed-Meldung. Keine Sekunde zu spät, denn wir mussten mit der Demo beginnen. Xebia Blogr Wie bereits in einem früheren Eintrag erwähnt, war die Demo ein großer Erfolg! Die Anwendung, die die Einträge unserer speziellen Mailbox anzeigte, lief vollständig innerhalb eines Webbrowsers, ohne jegliche Plugins (ein moderner, aktueller Browser ist allerdings erforderlich ), und griff über JSON auf die Spring-basierte Backend-Webanwendung zu. Ohne ein ordentliches Frontend gäbe es nicht viel zu demonstrieren ;-) - Natürlich kann jedes andere Team dasselbe über seinen Beitrag sagen. Hätten wir mehr tun können? Nun, wir hatten keine Unit-Tests erstellt. Wenn unsere Anwendung größer werden würde, wäre das sicherlich ein Muss. Eine Herausforderung ist, dass es noch keinen guten Standard zu geben scheint. In Java ist der De-facto-Standard für Unit-Tests JUnit. Für Javascript hat sich noch kein 'Marktführer' herauskristallisiert, so dass ich mich für einen entscheiden müsste. Möglicherweise wäre so etwas wie ein automatischer Build für die Javascript-Anwendung (wie er bereits für den gesamten Java-Code eingerichtet wurde) ebenfalls praktisch, damit all diese Tests automatisch ausgeführt werden. Test Swarm sieht vielversprechend aus. Und gibt es so etwas wie Maven für Javascript? Abschließend möchte ich sagen, dass es noch mehr zu erforschen und auszuprobieren gibt.

Verfasst von

Gerard van de Glind

Contact

Let’s discuss how we can support your journey.