Frontend

Frontend: il front dei gestionali, senza perdere il controllo del backend

Fare frontend oggi vuol dire decidere quanta complessità client serve davvero a un'applicazione, prima ancora di scegliere un framework. Su gestionali e piattaforme aziendali il front deve servire il dominio, senza diventare un secondo backend fragile da mantenere. In questa categoria scrivo di frontend applicato a un backend PHP, con il taglio di chi il backend lo conosce a fondo.

Spesso si tratta di scegliere la giusta dose di client. React e Vue 3 con TypeScript, Inertia.js per l'esperienza da single-page senza costruire e mantenere un'API REST separata, Next.js in SSR per le pagine marketing che devono essere indicizzate, Livewire con Volt e Folio quando il JavaScript si può evitare del tutto. Ogni approccio ha un costo, e bisogna saper riconoscere quando una SPA risolve un problema reale e quando aggiunge solo overhead che qualcuno dovrà manutenere.

Poi c'è l'allineamento con il backend. Un front costruito senza capire il dominio genera duplicazione, disallineamenti e debito tecnico che rallenta ogni rilascio. Scrivo di come tenere il frontend al servizio dell'applicazione, di come si ottimizza davvero (senza cospargere il codice di memoizzazioni inutili) e di come chi arriva da vent'anni di PHP può adottare TypeScript senza traumi, tenendo il controllo dell'insieme.

Se stai progettando il front di un gestionale o di un sito su misura, vedi la realizzazione siti ed e-commerce o scrivimi.

Un buon frontend si nota da quello che non fa: niente complessità inutile, solo l'interfaccia che serve al problema.