Το Αόρατο Κόστος της Ενοποίησης

Υπάρχει κάτι που εκνευρίζει κάθε developer που προσπάθησε να στήσει μια σοβαρή εφαρμογή web: το αόρατο κόστος της ενοποίησης.

Ξέρεις αυτή την αίσθηση. Διάλεξες το server framework σου, το ORM σου, τη βιβλιοθήκη validation, το frontend σου, το build tool σου. Όλα φαίνονται τέλεια στα χαρτιά. Και μετά αρχίζεις να χτίζεις πραγματικές λειτουργίες και ανακαλύπτεις ότι η βιβλιοθήκη validation δεν καταλαβαίνει ακριβώς τη δομή που επιστρέφει το ORM σου. Το SSR του frontend framework σου δεν παίζει καλά με το middleware του server. Το session handling κάνει υποθέσεις που σπάνε όταν πας να κάνεις deploy στο edge.

Κάθε εργαλείο ξεχωριστά είναι εξαιρετικό. Οι αρμοί είναι εφιάλτης.

Πώς Φτάσαμε Εδώ

Το JavaScript οικοσύστημα πάντα προτιμούσε τη συνθεσιμότητα από τη συνοχή. Αυτό δεν είναι απαραίτητα λάθος — η UNIX φιλοσοφία μας εξυπηρέτησε καλά για δεκαετίες. Το πρόβλημα είναι ότι οι web εφαρμογές δεν είναι pipelines μεμονωμένων data transformations. Είναι μπερδεμένα δίκτυα κοινών υποθέσεων: σχήματα requests, όρια validation, ροές authentication, rendering contexts, deployment targets.

Όταν εμφανίστηκε το Django το 2005, έκανε ένα στοίχημα: οι developers θα αντάλλασσαν κάποια ευελιξία για ένα συνεκτικό σύστημα. Μπορούσες ακόμα να βγεις έξω από το stack όταν χρειαζόταν, αλλά μέσα σε αυτό, όλα ήταν σχεδιασμένα να δουλεύουν μαζί. Αυτή η ιδιοκτησία σήμαινε λιγότερες εκπλήξεις.

Τα PHP frameworks το κατάλαβαν επίσης. Laravel, Symfony, Yii — όλα παρείχαν αυτή την αίσθηση του "ενός συνεκτικού συστήματος". Ήξερες πού ήταν επίσημο έδαφος και πού χρειαζόταν εξερεύνηση.

Μετά το JavaScript κατάπιε τον server, και χάσαμε σε μεγάλο βαθμό αυτό.

Η Παγίδα των Meta-Frameworks

Τα σύγχρονα meta-frameworks βελτίωσαν τα πράγματα σε κάποιους τομείς. Next.js, Nuxt, SvelteKit — σου έδωσαν ξανά ένα συνεκτικό stack. Αλλά το έκαναν περιορίζοντας τις επιλογές σου αντί να τις διευρύνουν.

Να τι εννοώ: Το Next.js είναι ένα εξαιρετικό React stack. Αλλά αν ερωτευτείς τα performance characteristics του Solid ή την απλότητα του Svelte, δεν αλλάζεις απλά το view layer. Υιοθετείς ένα διαφορετικό meta-framework με διαφορετικές συμβάσεις, διαφορετικά routing patterns, διαφορετικές backend υποθέσεις. Ξαναμαθαίνεις τα ίδια προβλήματα που έχεις ήδη λύσει, απλά με διαφορετική σύνταξη.

Αυτό δημιουργεί μια παράξενη κατάσταση. Το frontend οικοσύστημα συνεχίζει να καινοτομεί, αλλά η μετάβαση μεταξύ προσεγγίσεων απαιτεί σχεδόν να ξεκινήσεις από την αρχή. React developers και Svelte developers λύνουν τα ίδια backend προβλήματα ανεξάρτητα, με ελαφρώς διαφορετικούς τρόπους, για πάντα.

Η Λοταρία του Runtime

Και μετά υπάρχει η κατάτμηση του runtime. Node.js, Deno, Bun — είναι όλα ικανές πλατφόρμες, αλλά τα περισσότερα frameworks είναι ουσιαστικά runtime-specific. Όταν ένα framework δηλώνει υποστήριξη Deno, συχνά εννοεί απλά ότι "το Deno μπορεί να τρέξει τον Node κώδικά μας." Αυτό δεν είναι το ίδιο με το να είναι το framework σχεδιασμένο γύρω από τα native APIs και το execution model του Deno.

Αυτό έχει μεγαλύτερη σημασία από όσο φαίνεται. Το runtime που επιλέγεις επηρεάζει performance characteristics, deployment targets και security models. Το να κλειδώνεις τον εαυτό σου σε ένα framework που δουλεύει πραγματικά σε ένα μόνο runtime περιορίζει τις επιλογές σου καθώς το οικοσύστημα εξελίσσεται.

Τι Πραγματικά Χρειαζόμαστε

Να τι ισχύει: οι web εφαρμογές έχουν φυσικά layers που δεν χρειάζεται να είναι coupled.

Τα Frontends περιγράφουν browser UI. Τα Backends χειρίζονται requests, δεδομένα και application logic. Τα Runtimes είναι execution targets. Αυτές οι ανησυχίες θα έπρεπε να μπορούν να ποικίλλουν ανεξάρτητα.

Φαντάσου να χτίζεις ένα route με React επειδή χρειάζεσαι το οικοσύστημα component. Ένα άλλο με Svelte επειδή εκεί έχει μεγαλύτερη σημασία το performance. Τα Node.js routes σου να τρέχουν σήμερα, αλλά τα TypeScript routes σου να κάνουν deploy σε Bun όταν χρειάζεσαι την ταχύτητα. Όλα στην ίδια εφαρμογή, με το ίδιο backend model, το ίδιο validation, τα ίδια sessions.

Αυτό δεν είναι μαγική σκέψη. Είναι να αντιμετωπίζεις τις ανησυχίες ως ξεχωριστές ανησυχίες, που είναι ο τρόπος που πάντα χτίζονταν καλά software.

Το Framework Πρέπει να Αναλάβει τους Αρμούς

Δεν υποστηρίζω ένα framework για να τα κυβερνήσει όλα. Υποστηρίζω ότι ένα framework θα έπρεπε να αναλαμβάνει την ευθύνη να κάνει τα κομμάτια του να δουλεύουν μαζί. Θα έπρεπε ακόμα να μπορείς να βγεις έξω από το official stack όταν χρειάζεται — κανείς δεν στέλνει τέλεια defaults για κάθε use case. Αλλά όταν μένεις μέσα στο framework, οι αρμοί θα έπρεπε να είναι πρόβλημα του framework να λύσει, όχι δικό σου.

Ένα framework που σε αναγκάζει να σκέφτεσαι routing, validation, data access και rendering ως ξεχωριστά προβλήματα που πρέπει να κολλήσεις μαζί δεν είναι framework. Είναι μια πρόταση.

Τα καλύτερα frameworks σου δίνουν ιδιοκτησία του business logic σου ενώ αναλαμβάνουν τα πάντα τα υπόλοιπα.

Στην NameOcean, έχουμε δει πώς η πολυπλοκότητα του hosting μπορεί να πολλαπλασιαστεί όταν το stack σου είναι κατακερματισμένο. Η επιλογή ενός framework που σέβεται τον διαχωρισμό των αρμοδιοτήτων — που σε αφήνει να αλλάζεις κομμάτια χωρίς να ξαναγράφεις τα πάντα — κάνει το deployment, το scaling και τη συντήρηση δραματικά απλούστερα.

Το ερώτημα δεν είναι αν θα χρησιμοποιήσεις framework. Είναι αν το framework σου δουλεύει ή απλά προσθέτει ένα ακόμα layer αποφάσεων που δεν χρειαζόσουν να πάρεις.

Τι θα σήμαινε να χτίσεις την επόμενη εφαρμογή σου με ένα εργαλείο που αναλαμβάνει τους αρμούς; Αυτό αξίζει να το σκεφτείς πριν στήσεις το επόμενο project σου.