Μετάβαση στο περιεχόμενο
leeveel
← Ευρετήριο
Nº 001 · 30 Ιαν · 8 λεπτά ανάγνωσης#frontend

Γιατί σταματήσαμε να χρησιμοποιούμε component libraries

Τρία χρόνια μετά, έχουμε λιγότερο κώδικα δικό μας και κάνουμε ship πιο γρήγορα. Να τα μαθηματικά.

από Νεφέλη Κ.

++++

Ήμασταν χρήστες Material UI. Μετά Chakra. Μετά Radix. Μετά headless συν wrapper γύρω από το headless. Σταματήσαμε τα wrappers το 2025, και το codebase είναι πιο ήρεμο από τότε. Αυτό είναι το post που θα θέλαμε να υπήρχε όταν το συζητούσαμε.

Το κόστος μιας component library εμφανίζεται σε δύο προβλέψιμες στιγμές: την πρώτη φορά που το design αποκλίνει από τα defaults της library, και την πρώτη φορά που η library βγάζει major version. Και τα δύο είναι εγγυημένα. Και τα δύο συμβαίνουν σε deadline. Τα μαθηματικά που δεν έκανες από πριν εμφανίζονται ως επείγον στην όγδοη εβδομάδα.

Τι χρησιμοποιούμε αντί γι' αυτό: Tailwind πάνω σε κώδικα, με δικά μας primitives όπου τα χρειαζόμαστε. Κάθε project βγαίνει με περίπου δέκα components — Button, Card, Field, Modal, Toast, Table — γραμμένα από το μηδέν, δικά μας, μεταφερόμενα από project σε project όπου έχει νόημα. Δεν είναι τέλεια. Είναι ακριβώς αυτό που χρειαζόμαστε.

Τα μαθηματικά: ένας engineer, ένα απόγευμα ανά primitive, μοιρασμένο σε δύο χρόνια projects. Λιγότερο από τον χρόνο που ξοδεύαμε διαβάζοντας changelogs library, debug-άροντας αλυσιδωτά version bumps και διαφωνώντας με τις API αποφάσεις κάποιου άλλου. Δεν θα εγκαταστήσουμε νέα component library φέτος, ούτε του χρόνου.

Το grid παραπάνω είναι η πραγματική λίστα. Δέκα components, καθένα δικό μας και κατανοητό από όλη την ομάδα. Σύγκρινε με τα 240 components που έρχονται σε μια generic library — πραγματικά δεν χρειαστήκαμε ποτέ Stepper, TreeView, ή το 80% αυτών που εκθέτει το Material. Το 90% που έμοιαζε με συντόμευση αποδείχθηκε μουσείο για το οποίο πληρώναμε ενοίκιο.

Το περιστατικό που μας έσπρωξε: ένα major bump library το 2025. Τρία projects στην ίδια έκδοση, όλα να χρειάζονται peer-dep update για νέα React. Η μετάβαση δεν ήταν δύσκολη — αλλά ήταν τρεις μεταβάσεις, συντονισμένες σε τρεις πελάτες, μια εβδομάδα που δεν την είχαμε προϋπολογίσει. Το κουβαλήσαμε δύο μέρες. Γράψαμε τα δικά μας primitives το επόμενο τρίμηνο. Δεν έχουμε ξανά έκτακτο συντονισμένο peer-dep από τότε.

Πότε θα κάναμε πίσω: σε project όπου η ομάδα είναι δύο junior engineers και το deadline είναι έξι εβδομάδες. Πιάσε Mantine ή shadcn/ui, βγάλε, παράδωσε. Το επιχείρημα εδώ είναι για οικονομικά κλίμακας studio, όχι για απόλυτη ορθότητα. Αν πληρώνεις δέκα engineers να συντηρούν custom primitives αντί να χτίζουν το πραγματικό προϊόν, δεν έχεις γλιτώσει χρήματα.