Uso Laravel come base per lo sviluppo di applicazioni web, HTMX per gli aggiornamenti dal server e Alpine.js per le interazioni locali. L’intelligenza artificiale mi affianca su una base di codice che cerco di mantenere semplice da leggere, modificare e verificare.
Partiamo dagli strumentiRegole, dati e HTML
Richieste e aggiornamenti
Pagina e interazioni locali
L’AI mi affianca nello sviluppo, nella lettura del codice e nelle verifiche.
Qui organizzo la logica del prodotto, l’accesso ai dati, la validazione e i permessi. Blade, il sistema di template di Laravel, mi permette di comporre l’HTML in viste riutilizzabili.
Le convenzioni del framework danno una struttura al lavoro: è più semplice sapere dove cercare una regola e dove intervenire.
Un filtro, una ricerca o un modulo possono inviare una richiesta e aggiornare una parte della pagina con l’HTML ricevuto dal server.
Descrivo queste azioni con attributi HTML. Nei flussi adatti posso evitare molto JavaScript dedicato a richieste, trasformazione dei dati e aggiornamento dell’interfaccia.
Lo uso per comportamenti locali: aprire un pannello, cambiare una scheda o gestire lo stato di un menu, senza contattare il server per ogni gesto.
Il comportamento resta vicino all’elemento che lo usa. HTMX gestisce gli aggiornamenti dal server; ad Alpine assegno le interazioni locali, coordinando le parti di pagina che possono essere sostituite.
Per molti gestionali, portali e flussi basati su moduli, una parte della complessità nasce dal collegamento tra backend e frontend. Usare HTML anche per gli aggiornamenti può eliminare molto codice dedicato solo a quel collegamento.
Il vantaggio che cerco è avere meno logica duplicata, meno stato condiviso da sincronizzare e meno punti da modificare per aggiungere una funzione.
| Da gestire | Frontend separato con API JSON | Laravel + HTMX + Alpine.js |
|---|---|---|
| Risposta del server | Dati JSON da rappresentare nell’interfaccia. | HTML già composto da Blade. |
| Aggiornamento della vista | Il frontend riceve i dati e aggiorna i componenti. | HTMX inserisce l’HTML nella parte prevista. |
| Stato nel browser | Può includere una copia dei dati del server e la relativa sincronizzazione. | Posso limitare lo stato locale alle interazioni che ne hanno bisogno. |
| Una modifica al flusso | Può coinvolgere il contratto API e il codice che lo usa. | Può restare vicina alla logica server e alla vista interessata. |
| Test | Possono servire verifiche distinte per API, componenti e integrazione, con più strumenti e simulazioni da coordinare. | Con PHPUnit verifico logica e HTML restituito nella stessa suite PHP. Per le interazioni JavaScript aggiungo test nel browser. |
Il confronto riguarda queste due architetture. Anche React e Vue possono essere usati con rendering sul server: la quantità di codice dipende dalle scelte e dai requisiti del progetto.
Con Laravel e HTMX posso verificare con PHPUnit una parte molto ampia dell’applicazione: regole, permessi, validazione e HTML generato per l’interfaccia. Anche i frammenti restituiti alle richieste HTMX si possono controllare nella stessa suite di test PHP.
Con un frontend separato e API JSON possono servire verifiche distinte per backend, componenti e integrazione, con più strumenti e simulazioni da coordinare. Generare l’HTML sul server mi permette di concentrare molti di questi controlli nei test Laravel: meno preparazione e meno codice di supporto da mantenere.
L’esecuzione di JavaScript, gli aggiornamenti effettivi della pagina con HTMX e le interazioni Alpine richiedono test nel browser.
Per aiutarmi su una modifica, l’AI deve capire codice, regole e dipendenze coinvolte: questo è il suo contesto. Se una funzione è distribuita tra molti strati, deve ricostruire più collegamenti prima di poter intervenire.
La mia scelta è ridurre questa dispersione. Un flusso più raccolto può rendere più semplice preparare il contesto e controllare la proposta dell’AI. È un beneficio che cerco attraverso l’architettura e l’organizzazione del codice.
Con PHPUnit controllo regole e HTML generato anche dopo una modifica proposta dall’AI. I test automatici mi aiutano a individuare regressioni; li affianco alla revisione del codice e alle verifiche nel browser.
Una modifica circoscritta può richiedere meno file da leggere. Mantengo nel contesto le regole, le dipendenze e i test rilevanti.
Ridurre il codice di collegamento significa anche ridurre quello che devo chiedere all’AI, leggere e mantenere.
Immagina di aggiungere il filtro “Stato” a un elenco di richieste. Posso organizzare il comportamento in questo modo:
Il controllo del filtro è nella pagina. Alpine può gestire l’apertura di un eventuale pannello.
Il valore selezionato arriva alla rotta Laravel che gestisce l’elenco.
Verifico input e permessi, filtro i dati e compongo i risultati con Blade.
HTMX sostituisce l’area dei risultati con l’HTML ricevuto.
Preparo richieste con stati diversi e simulo la chiamata alla rotta Laravel, con il filtro e gli header usati da HTMX. Verifico che l’HTML restituito contenga i risultati pertinenti ed escluda quelli con altri stati.
Controllo anche i permessi: ogni persona deve ricevere solo i dati che può consultare e l’accesso alla rotta deve essere negato a chi non è autorizzato. Con un test nel browser verifico poi che la selezione del filtro aggiorni davvero l’elenco.
La richiesta, la rotta e il codice che filtra i dati, la vista interessata, le regole di accesso e i test del flusso. Aggiungo altro codice quando le dipendenze lo richiedono.
Parto dal risultato atteso, dai vincoli e dai criteri con cui verificheremo la modifica. Seleziono il codice e le informazioni utili al compito.
Uso l’AI per esplorare il codice, valutare alternative, proporre implementazioni e preparare test. Rivedo le proposte nel contesto del prodotto.
Leggo le modifiche, eseguo i controlli pertinenti e provo i flussi coinvolti. Le decisioni tecniche e la revisione del lavoro restano sotto la mia responsabilità.
Gestionali, aree riservate, cataloghi, moduli e flussi di lavoro in cui i dati vengono dal server e le interazioni sono circoscritte. Qui cerco il massimo beneficio dalla semplicità.
Editor complessi, esperienze offline o interfacce con molto stato condiviso nel browser possono richiedere un frontend più articolato. Scelgo in base alle funzioni, al team e al prodotto esistente.
Raccontami cosa stai costruendo e dove si accumula la complessità. Partiamo da lì per capire quali strumenti e interventi hanno senso.