© Yurii Andreichyn/Shutterstock.com
Ein grundlegendes Set-up für die Entwicklung

Symfony und Vue.js: der Stack der Zukunft


Jedes Webprojekt ist einzigartig: in Design, Funktionalität, User Experience und Gamification. Die Anforderungen haben sich in den letzten Jahren stark verändert. Bei einem Projekt ist es nicht einfach, sich für das richtige Set-up zu entscheiden. Abgesehen von den nahezu unendlichen Möglichkeiten wird gefühlt jeden Tag ein neues Tool oder Framework vorgestellt, das verspricht, die Welt zu verändern.

Diese Umstände sorgen oft dafür, dass man beim Set-up etwas Neues ausprobiert. Das behält man sich dann – meiner Erfahrung nach – lieber für kleine Nebenprojekte auf. Damit ich bei wichtigen Projekten nicht Samstagmittag einen Hotfix einspielen muss (auch hier spreche ich leider aus Erfahrung), habe ich viel Zeit und Aufwand in ein grundlegendes Set-up investiert, das es erlaubt, ohne viel Zusatzaufwand mit der Entwicklung zu starten. Gleichzeitig bleibt die Flexibilität hoch genug, um jede Website oder Web-App individuell aufbauen zu können. Ich habe mich dabei mit Symfony und Vue.js für zwei starke Frameworks entschieden, die beide in ihrem Segment Großartiges leisten und meiner Meinung nach sehr gute Partner sind, wenn man sie richtig verwendet. Alles in diesem Artikel Beschriebene kann im Repository auf GitHub [1] im Detail inspiziert werden.

Deshalb Symfony

Symfony selbst hat sechs gute Gründe verfasst, warum man sich für das Framework entscheiden sollte. Für mich persönlich zählt vor allem, dass es ein unvoreingenommenes Framework ist, das mir erlaubt, zu bauen, was ich möchte und wie ich es möchte. Man bekommt mit Symfony eine leere Vorlage, die mächtige Features und starke Helferlein enthält. Die kann man ohne Aufwand verwenden, wenn man sie braucht. Es gibt nahezu für jeden Anwendungsfall ein Bundle, das bereits alles kann, was man braucht. So muss man nur noch die Businesslogik bauen und alles zusammenführen, um zum gewünschten Ergebnis zu kommen.

Darum Vue.js

Im Gegensatz zu vielen anderen sehr populären JS Frameworks, lässt sich Vue.js sehr einfach auch in bestehende Projekte integrieren. Vue.js bietet zum Beispiel die Möglichkeit, mit Custom Directives die Funktionalität von HTML-Elementen zu erweitern, ohne dazu eine ganze Komponente schreiben zu müssen. Eine der besten Funktionen von Vue.js ist meiner Meinung nach, dass man Templates, die vom Server als HTML gerendert wurden, nach Bedarf kompilieren und verwenden kann. Vue.js erlaubt uns somit, Funktionalität durch JavaScript sehr flexibel zu erweitern. Gleichzeitig erfordert es nicht zwingend, den Inhalt anzuzeigen, und schränkt auch sonst in keiner Weise ein. Außerdem lassen sich mit Vue.js auch große Single Page Applications bauen. Vue.js liefert dafür den Router und das Store-Management als optionale Core-Erweiterung mit. Es wird also nicht – wie bei React.js – auf Erweiterungen Dritter, wie zum Beispiel Redux und MobX, gesetzt. Dadurch werden einige mögliche Schwierigkeiten bereits präventiv ausgeschlossen.

Der Kiel des Eisbergs

Leider ist die Auswahl der Frameworks meist nur die Spitze des offensichtlichen Aufwands. Die Zusammenführung der dazugehörigen sowie meist notwendigen Build-Tools ist oftmals abschreckend und überwältigend, wenn man sich nicht regelmäßig und in angemessener Detailtiefe damit auseinandersetzt. Dazu zählen vor allem der Aufbau der Dateistruktur, des Frontend Source Codes und der Assets, sowie die Auswahl und Notwendigkeitsabschätzung diverser Prä- und Postprozessoren.

Zuerst gehört geklärt, wo nun die Dateien abgelegt und geordnet werden, denn im public-Verzeichnis haben Source-Files natürlich nichts zu suchen. Deshalb gibt es in meinen Projekten im Root immer einen assets-Ordner, in dem die Sass(SCSS)-, TypeScript- und Bilddateien abgelegt werden. Das Ganze könnte dann etwa wie in Listing 1 aussehen.

Listing 1

├── qassets │ ├── images │ │ └── logo.svg │ ├── scss │ │ ├── _atoms │ │ ├── _blocks │ │ ├── _components │ │ └── main.scss │ └── typescript │ ├── components │ ├── services │ ├── store │ ├── utility │ └── main.ts ├── bin ├── config ├── public │ ├── images │ │ └── logo.svg │ ├── main.css │ ├── main.js │ └── manifest.json ├── src ├── …

Damit liegen alle relevanten Dateien, egal ob Front- oder Backend, schön beieinander und fügen sich nahtlos in die vorhandene Symfony-Struktur ein. Für mich ist dabei sehr wichtig, dass ich im Symfony-src-Verzeichnis nicht nach irgendwelchen Style- oder Skriptdateien suchen muss, wie ich es leider schon bei vielen – hauptsächlich älteren – Projekten gesehen habe.

Im nächsten Schritt geht es darum, die Assets für den Browser aufzubereiten. Dafür gibt es allerhand Build-Tools, wie zum Beispiel Grunt, Gulp, webpack etc. Jedes hat natürlich seine Vor- und Nachteile. Ich verwende webpack. Es begleitet mich jetzt schon seit einigen Jahren und ich hatte bisher noch keinen Fall, bei dem ich ein anderes Tool gebraucht hätte. Außerdem kenne ich mich damit inzwischen so gut aus, dass ich es bedenkenlos in großen und langfristigen Projekten einsetzen kann. Niemand hat Spaß dabei, wenn man in solch einem Projekt zu experimentieren beginnt un...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang