Perché uso Flask e htmx: il framework non fa l’ingegnere
Uso Flask e htmx per lavorare con strumenti che conosco, non perché siano migliori in assoluto. Come ragiono su requisiti, manutenzione e cambi di stack.
"Perché usi Flask e htmx? Perché non FastAPI? Perché non Next.js?"
Risposta breve: perché per certi progetti mi trovo bene così.
Risposta lunga: questo articolo. Che però ho cercato di tenere corto.
Non penso che Flask sia meglio di tutto. Ma non cambio stack se prima non so rispondere a una domanda: che problema risolvo cambiandolo? "Sembra più moderno" non vale.
Il framework non fa l'ingegnere
Scegliere un framework non vuol dire aver progettato il sistema.
Prima vengono le domande:
- cosa deve fare il prodotto?
- chi lo usa e come?
- chi può vedere o modificare cosa?
- cosa succede quando qualcosa va storto?
- quanto tempo e budget ci sono?
Poi scelgo gli strumenti.
Mettere FastAPI non risolve da solo sicurezza e prestazioni. Scegliere Flask non mi autorizza a ignorarle.
Il framework mi aiuta. Ma alla riunione, quando qualcosa non va, ci vado io.
Perché Flask e htmx
Mi piace un flusso che riesco a seguire: arriva una richiesta, faccio quello che serve, rispondo.
Per tante interfacce preferisco generare l'HTML sul server e usare htmx per aggiornare solo i pezzi che cambiano. Una tabella filtrata, un form, lo stato di un'attività.
Un frontend separato? Solo se riesco a spiegare cosa ci guadagno.
Non vuol dire zero JavaScript, zero complessità o zero problemi. Magari. Avrei già finito parecchie cose.
Conoscerlo bene conta
Se uno strumento lo conosco bene, so dove guardare quando si rompe. E questo pesa.
Tra lavoro, università e progetti, il tempo non è un dettaglio. Imparare, integrare e mantenere una tecnologia nuova costa.
Studiare mi piace, eh. Ma sono due cose diverse:
- imparare una tecnologia nuova;
- consegnare un lavoro con dei vincoli.
A volte coincidono. Spesso no.
La familiarità non cancella un limite tecnico. Ma se quel limite non dà fastidio al progetto, cambiare stack non è obbligatorio. La lista delle cose da fare è già abbastanza creativa così.
Non è una classifica
FastAPI e Next.js li ho usati. Non sono nemici da battere per difendere Flask.
"Flask contro Next.js" non è nemmeno una domanda completa. Sto scegliendo il backend? L'API? L'interfaccia? Tutta l'app? Sono decisioni diverse.
Stessa cosa per Flask e Quart: se la concorrenza conta, ne parlo apertamente, non la nascondo sotto un'etichetta.
Non devo dimostrare che il mio stack vince sempre. Devo saper spiegare perché l'ho scelto quella volta.
Quando cambierei
Con Flask non ho firmato un contratto di fedeltà.
Cambio se:
- ci sono tante operazioni concorrenti, connessioni persistenti o aggiornamenti in streaming;
- devo esporre un'API a più client;
- l'interfaccia ha tanta logica lato browser;
- entro in un team che lavora già in un altro modo;
- i numeri dicono che non regge.
E a quel punto la domanda non è "come difendo Flask?". È "cosa devo cambiare?". Magari una query, magari la configurazione, magari il framework. Prima trovo il problema, poi decido.
Semplice non vuol dire sciatto
Semplice non vuol dire tutto in un file sperando che nessuno prema due pulsanti insieme.
Restano da fare comunque:
- validazione degli input e permessi;
- protezione dei dati e dei segreti;
- gestione di errori e timeout;
- test sulle cose importanti;
- deploy, aggiornamenti, backup;
- documentazione.
Se dico "meno complessità" e salto questi punti, non sto semplificando. Sto rimandando i problemi.
E chiamarlo debito tecnico non lo rende rateizzabile senza interessi.
La scelta la spiego
"Perché mi piacciono" non basta come risposta. Voglio saper dire:
- che requisiti ci sono;
- perché questa soluzione va bene;
- cosa ho scartato;
- che limiti accetto;
- come verifico che funziona;
- cosa mi farebbe cambiare idea.
Non serve una tesi per ogni progetto. Serve un ragionamento che si legge.
Il nome dello stack è l'inizio della spiegazione, non la fine.
Non seguo la moda. Seguo il problema
Quindi sì, uso Flask e htmx quando hanno senso. Non perché siano i migliori. Non perché il resto sia inutile. Ma anche perché li conosco, e quello ha un valore.
Se cambiano i requisiti, cambio anch'io. Quello che non faccio è cambiare attrezzo solo per sentirmi più "professionale".
Il framework non fa l'ingegnere.
E purtroppo non risponde nemmeno alle email dei clienti.
Tu con che criterio scegli lo stack?