Architecture Before Syntax — Why I Never Reach for the Framework First
When someone starts a new project, the first question is usually: "Which framework should we use?" React? Next.js? Vue? The framework gets declared as the architecture before any problem has even been understood.
My approach is different. I start with questions, not tools.
What's the actual problem?
When I built this portfolio, I could have used React. It would have been faster — components, state management, everything ready-made. Instead, I chose Vanilla TypeScript. Not out of principle, but as a deliberate decision: I wanted to understand how things work, not just how to use them.
The result? I now know exactly how an IntersectionObserver works, how Web Components are structured, how to build an i18n engine from scratch. No framework magic. Just code I fully understand.
The foundation decides everything
With StudyNexus, my SaaS platform for students, the first question wasn't "React or Vue" either. It was: What data do we need? How does it relate? What happens when a user changes their schedule — which other parts of the system need to react?
Only once those questions are answered does the technology choice make sense. FastAPI for the async API, PostgreSQL for the relational structure, Docker Compose so development and production are identical. Every decision follows from the problem, not from the trend.
When do I reach for a framework?
Whenever the problem demands it. The admin panel for this portfolio is built with Next.js — because Server Components, auth middleware, and API routes make sense there. That wasn't a default choice, it was a reasoned one.
The difference: I choose tools deliberately, not reflexively.
The paradox
Those who choose the framework first only learn the framework. Those who understand the problem first learn computer science.
And in the end, a framework is just a tool. Tools change. Understanding stays.
Architektur vor Syntax — warum ich nie zuerst nach dem Framework greife
Wenn jemand ein neues Projekt startet, ist die erste Frage meistens: „Welches Framework nehmen wir?" React? Next.js? Vue? Das Framework wird zur Architektur erklärt, bevor irgendein Problem überhaupt verstanden wurde.
Mein Ansatz ist anders. Ich fange mit Fragen an, nicht mit Tools.
Was ist das eigentliche Problem?
Als ich dieses Portfolio gebaut habe, hätte ich React nehmen können. Es wäre schneller gegangen — Komponenten, State Management, alles fertig. Stattdessen habe ich Vanilla TypeScript gewählt. Nicht aus Prinzip, sondern aus einer bewussten Entscheidung: Ich wollte verstehen, wie Dinge funktionieren, nicht nur wie man sie benutzt.
Das Ergebnis? Ich weiß heute genau, wie ein IntersectionObserver funktioniert, wie Web Components aufgebaut sind, wie eine i18n-Engine von Grund auf gebaut wird. Kein Framework-Magic. Nur Code, den ich vollständig verstehe.
Das Fundament entscheidet alles
Bei StudyNexus, meiner SaaS-Plattform für Studierende, war die erste Frage auch nicht „React oder Vue". Sondern: Welche Daten brauchen wir? Wie hängen sie zusammen? Was passiert, wenn ein Nutzer seinen Stundenplan ändert — welche anderen Teile des Systems müssen reagieren?
Erst wenn diese Fragen beantwortet sind, ergibt die Technologiewahl Sinn. FastAPI für die async API, PostgreSQL für die relationale Struktur, Docker Compose damit Entwicklung und Produktion identisch sind. Jede Entscheidung folgt aus dem Problem, nicht aus dem Trend.
Wann greife ich dann zum Framework?
Immer dann, wenn das Problem es verlangt. Das Admin Panel für dieses Portfolio ist in Next.js gebaut — weil Server Components, Auth Middleware und API Routes dort Sinn ergeben. Das war keine Standardwahl, das war eine begründete Wahl.
Der Unterschied: Ich wähle Tools bewusst, nicht reflexartig.
Das Paradoxe
Wer zuerst das Framework wählt, lernt nur das Framework. Wer zuerst das Problem versteht, lernt Informatik.
Und am Ende ist ein Framework nur ein Werkzeug. Werkzeuge wechseln. Verständnis bleibt.
البنية قبل البناء — لماذا لا أبدأ بالإطار البرمجي أولاً
عندما يبدأ أحدهم مشروعاً جديداً، يكون السؤال الأول عادةً: «أيّ إطار برمجي سنستخدم؟» React؟ Next.js؟ Vue؟ يُعلَن الإطار معماريةً للمشروع قبل أن تُفهم أي مشكلة أصلاً.
نهجي مختلف. أبدأ بالأسئلة، لا بالأدوات.
ما هي المشكلة الحقيقية؟
حين بنيتُ هذه المحفظة، كان بإمكاني استخدام React. كان سيكون أسرع — مكونات جاهزة، إدارة حالة، كل شيء مُهيَّأ. بدلاً من ذلك، اخترت Vanilla TypeScript. ليس من باب المبدأ، بل كقرار واعٍ: أردتُ أن أفهم كيف تعمل الأشياء، لا كيف أستخدمها فحسب.
النتيجة؟ أعرف اليوم تماماً كيف يعمل IntersectionObserver، وكيف تُبنى Web Components، وكيف يُنشأ محرك i18n من الصفر. لا سحر للأطر. فقط كود أفهمه بالكامل.
الأساس يحدد كل شيء
في StudyNexus، منصتي كخدمة للطلاب، لم يكن السؤال الأول «React أم Vue» هنا أيضاً. بل كان: ما البيانات التي نحتاجها؟ كيف ترتبط ببعضها؟ ما الذي يحدث حين يُغيِّر مستخدم جدوله الدراسي — أيّ أجزاء من النظام يجب أن تستجيب؟
فقط حين تُجاب هذه الأسئلة يصبح اختيار التقنية منطقياً. FastAPI للـ API غير المتزامن، PostgreSQL للبنية العلائقية، Docker Compose لضمان تطابق بيئتَي التطوير والإنتاج. كل قرار ينبثق من المشكلة، لا من الصيحة السائدة.
متى أتناول إطاراً برمجياً إذن؟
في كل مرة يستدعيها المشكلة. لوحة الإدارة لهذه المحفظة مبنية بـ Next.js — لأن Server Components ومتوسط المصادقة ومسارات API منطقية هناك. لم يكن ذلك اختياراً افتراضياً، بل كان اختياراً مُسبَّباً.
الفارق: أختار الأدوات بوعي، لا بشكل انعكاسي.
المفارقة
من يختار الإطار أولاً لا يتعلم سوى الإطار. من يفهم المشكلة أولاً يتعلم علم الحاسوب.
وفي النهاية، الإطار البرمجي مجرد أداة. الأدوات تتغير. الفهم يبقى.